MikroTik Traffic Flow Export to a DDoS Collector (RouterOS v7)

MikroTik Traffic Flow export on RouterOS v7 is configured with /ip traffic-flow plus a target that points to your DDoS detection collector. To make it useful for attack detection, you need short flow timeouts, the right interfaces, and a clear check that flows actually arrive.

This guide covers a working RouterOS v7 configuration, how to think about sampling, how to verify each hop, and the mistakes that most often leave a collector blind during an attack. Example addresses use documentation ranges: the router is 198.51.100.1 and the collector is 192.0.2.10.

What a DDoS collector needs from the router

Detection is only as good as the flow data. For volumetric and packet-rate attacks the collector needs:

• Timely records. Flows must be exported within seconds, not at the end of a 30-minute active timeout.
• Correct direction. You want traffic entering your network from upstreams and IXPs, tied to destination IPs inside your prefixes.
• Consistent exporter identity. The collector usually maps flows to a router by source IP, so it should not change.
• Known sampling. If you sample, the collector must scale counters back up.

For background on thresholds and baselines, see our earlier article on NetFlow DDoS detection. Here we stay on the MikroTik side.

Step 1: Pick the protocol version

RouterOS v7 supports several export versions in the target definition:

If you carry IPv6 (and you probably do), use 9 or 10. v5 has no IPv6 fields. Check that your collector supports the version you choose. NixMon accepts NetFlow v5/v9, IPFIX and sFlow, so either works there.

Step 2: Enable Traffic Flow on RouterOS v7

/ip traffic-flow
set enabled=yes \
    interfaces=ether1-transit,ether2-ix \
    cache-entries=128k \
    active-flow-timeout=30s \
    inactive-flow-timeout=10s

/ip traffic-flow target
add dst-address=192.0.2.10 port=2055 \
    src-address=198.51.100.1 \
    version=9

For IPFIX, change version=9 to version=10.

What the key settings do:

• interfaces: Only the interfaces listed are monitored. Use upstream-facing interfaces rather than all (see mistakes below).
• active-flow-timeout: The default is 30 minutes. A long-lived UDP flood would be reported far too late. 30 seconds or lower is a sensible starting point for detection. Lower values increase export volume and CPU use.
• inactive-flow-timeout: How long an idle flow stays in cache before export. 10–15 seconds is typical.
• cache-entries: Size of the flow cache. During a spoofed-source flood the number of unique flows explodes. If the cache fills, new flows can be dropped, so size this to your RAM and test under load.
• src-address on the target: Pin it to a stable address, such as a loopback or management IP, so the exporter identity doesn't change if routing does.

The v9 template refresh settings (v9-template-refresh, v9-template-timeout) are also available on the target. If your collector starts after the router, a shorter refresh interval means it learns templates sooner. Run /ip traffic-flow target print detail to see the exact options on your RouterOS build.

Step 3: Think about sampling

By default, MikroTik Traffic Flow is not a sampled export: the router tracks connections in its flow cache and exports records for them. That gives accurate counters, but it costs CPU and memory on small routers, especially under floods with many unique sources.

Recent RouterOS v7 releases also expose packet sampling options under /ip traffic-flow (packet-sampling, sampling-interval, sampling-space). Availability and exact semantics depend on the version, so check /ip traffic-flow print and the MikroTik documentation for your release before relying on them.

Practical guidance:

• Start unsampled on low-throughput edge routers if CPU allows, and watch the load during a test.
• If you sample, write the rate down. Many collectors need the sampling rate configured manually to scale bps and pps. If MikroTik doesn't advertise the rate in a way your collector reads, a 1:N sample will look like 1/N of the real traffic and your thresholds will never fire.
• Don't mix sampled and unsampled routers under the same threshold without correcting for it.
• Remember what sampling hides. Low-rate attacks and short bursts are harder to see at aggressive sampling ratios.

For a deeper discussion of rates and trade-offs, see our article on sFlow vs NetFlow vs IPFIX.

Step 4: Allow the export through your firewall

If you filter traffic leaving the router, allow UDP to the collector. A minimal example:

/ip firewall filter
add chain=output action=accept protocol=udp \
    dst-address=192.0.2.10 dst-port=2055 \
    comment="traffic-flow export"

Place it above any rule that would drop it. Also confirm the collector host (or the network in front of it) accepts inbound UDP/2055:

# Linux collector, nftables example
nft add rule inet filter input ip saddr 198.51.100.1 udp dport 2055 accept

Step 5: Verify, hop by hop

Troubleshoot in order. Most "no data" problems are found in the first two checks.

1. On the router: is Traffic Flow active?

/ip traffic-flow print
/ip traffic-flow target print

Confirm enabled=yes, the right interfaces and the right collector address and port.

2. On the router: are packets leaving?

/tool sniffer quick ip-address=192.0.2.10 port=2055

You should see UDP packets to the collector every few seconds when there is traffic on the monitored interfaces. If you see none, check that the monitored interfaces carry routed traffic and that the flow isn't bypassing the router's flow accounting (see mistakes).

3. On the collector: are packets arriving?

tcpdump -ni eth0 'udp port 2055 and host 198.51.100.1'

If the router sends and the collector doesn't receive, look at upstream ACLs, host firewall rules and asymmetric paths to the management network.

4. On the collector: are records decoded?

An independent decoder is a good sanity check. With nfdump:

nfcapd -w -D -p 2055 -l /var/cache/nfdump
nfdump -R /var/cache/nfdump -s dstip/bytes -n 10

This shows the top destination IPs by bytes. Compare with a known value, such as a test download to a host in 203.0.113.0/24, or with interface counters (/interface monitor-traffic ether1-transit). Large unexplained differences point to a sampling, direction or double-counting problem. Stop nfcapd before pointing the real collector at the same port, since two listeners can't share it.

5. In the detection platform: do thresholds work end to end?

Generate a controlled burst toward a test IP, for example with iperf3 UDP or hping3 from a lab host you own, and confirm the per-IP bps/pps counters rise and an alert fires. Test with a low temporary threshold rather than a real attack.

Common mistakes

• Monitoring all interfaces. A packet crossing the router in and out can be counted on more than one interface, which inflates bps/pps and creates false alerts. Monitor only the edge interfaces that matter, and let the collector use the input interface to focus on inbound traffic.
• Leaving the 30-minute active timeout. Detection becomes slow and bursty. Lower it.
• Hardware offload and FastTrack. Traffic switched in the switch chip, or accelerated by FastPath/FastTrack, may not be visible to flow accounting the way routed traffic is. Test with real traffic and compare to interface counters.
• Changing exporter IP. If the source address follows the outgoing interface, the collector sees "new routers" after a routing change. Set src-address.
• Undersized cache. Spoofed floods create huge numbers of unique flows. Watch CPU and memory during a lab test, not for the first time during an incident.
• Wrong sampling scale. Thresholds set for full traffic won't trigger on 1:N samples unless the collector multiplies counters.
• Template issues. With v9/IPFIX, if the collector misses templates (restart, packet loss), records can't be decoded until the next refresh. Keep the refresh interval short.
• Forgetting that detection isn't mitigation. Flow export tells you about an attack. You still need an action, such as RTBH, FlowSpec or scrubbing, ready to go.

From flows to action

Once flows are arriving, the collector can compare per-IP and per-prefix rates against thresholds and trigger a response. NixMon traffic monitoring and DDoS detection ingests NetFlow v5/v9, IPFIX and sFlow, analyzes traffic with sub-second analytics, and can announce BGP blackhole (RTBH) or BGP FlowSpec routes, or trigger the on-prem NixGuard firewall. Networks with their own ASN and at least one /24 can also use NixGuard Edge, where clean traffic returns over a GRE tunnel with a BGP session inside.

You can test the full path from MikroTik to alert with the 15-day free trial, which doesn't require a credit card.