MikroTik NetFlow and Traffic Analysis with ntopng

MikroTik RouterOS can export flow records to a collector, while ntopng turns those records into searchable traffic views, conversations, hosts, and protocol-level summaries. The important implementation detail is that RouterOS Traffic-Flow and ntopng do not always form a direct, supported pairing: MikroTik’s documentation notes that ntopng deployments require nProbe, ntop’s flow probe/collector component. Plan the exporter, collector, and licensing before changing the router.

How MikroTik Traffic-Flow and ntopng work

MikroTik Traffic-Flow is RouterOS’s flow-export feature. It aggregates packet activity into flow records and sends those records to a remote collector using a NetFlow-compatible format. ntopng is the traffic-analysis interface that presents network activity in terms of hosts, conversations, protocols, and historical views. Depending on the chosen ntop deployment and supported input, nProbe may be needed between the RouterOS exporter and ntopng.

A flow record is metadata about traffic, not a full packet capture. It commonly describes source and destination addresses, ports, protocol, packet and byte counts, and timing. Flow data is useful for answering “who communicated with whom, using what protocol, and how much traffic was involved?” It generally cannot reveal full payload contents like a packet capture can.

The data path is:

MikroTik RouterOS
  └─ Traffic-Flow exporter (NetFlow v9 or IPFIX)
       └─ UDP flow packets
            └─ nProbe / compatible flow collector
                 └─ ntopng web interface and analysis

NetFlow v9 uses templates to describe record fields. IPFIX is the IETF-standardised flow information export protocol and is based on the v9 model. The receiver must understand the format and retain current templates to decode data correctly. See the NetFlow v9 specification (RFC 3954) and the MikroTik Traffic-Flow manual.

Prerequisites and design decisions

Before configuring the router, identify the exact RouterOS version, the collector host address, and which interfaces should be observed. Commands below use RouterOS CLI syntax and are an illustrative baseline; verify them against the documentation for the RouterOS release running on your device.

• A MikroTik router running RouterOS with Traffic-Flow available.
• A Linux or other supported host for nProbe and ntopng, sized for expected flow volume and retention.
• IP connectivity from the router to the collector and a firewall rule permitting the selected UDP destination port.
• A compatible nProbe/ntopng deployment and any required commercial licence. MikroTik’s documentation specifically states that nProbe is required for ntopng integration; confirm current licensing and supported configurations with official ntop documentation.
• Time synchronisation on the router and collector, preferably through a trusted NTP source, to make event timelines useful.

Choose a flow format supported by both ends. NetFlow v9 is a practical starting point for many RouterOS deployments; IPFIX is also available. Do not assume every field or protocol version is interpreted identically by every collector build. Confirm the nProbe input mode and port in the documentation for your installed version before enabling export.

Configure RouterOS Traffic-Flow

1. Choose the observation interfaces

Traffic-Flow observes traffic processed by the router CPU. MikroTik documents an important limitation: hardware-offloaded traffic, including certain bridged flows, is not visible to Traffic-Flow. If your goal is to account for all traffic switched or routed in hardware, validate visibility on the specific device and forwarding path before relying on the results.

To inspect the current settings, run:

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

2. Enable Traffic-Flow and add a target

In this example, the collector is 192.0.2.20 and receives NetFlow v9 on UDP port 2055. Replace the documentation-only address with the real, reachable collector IP. Use a source address that the collector can route back to or reliably identify, where appropriate.

/ip/traffic-flow/set enabled=yes interfaces=all
/ip/traffic-flow/target/add dst-address=192.0.2.20 port=2055 version=9
/ip/traffic-flow/target/print

These commands enable export for all eligible interfaces and add a NetFlow v9 target. In a production router, consider restricting interfaces to the interfaces that actually need measurement rather than exporting everything by default. If a target already exists, inspect it first to avoid duplicate exports.

3. Tune flow timeouts only after a baseline

RouterOS exposes cache and timeout settings. The documented defaults include a 30-minute active-flow timeout and a 15-second inactive-flow timeout. Shorter inactive timeouts can make records appear sooner but may increase export volume; longer timeouts can delay visibility for quiet or short-lived conversations. Start with defaults, measure collector behaviour, and tune only when the use case warrants it.

Packet sampling is available in RouterOS v7. Sampling reduces the amount of packet activity observed and changes how representative the exported counters are. Do not treat sampled byte and packet counts as exact totals unless your collector and analysis account for the sampling configuration.

Configure the collector and ntopng

The exact commands for nProbe depend on the installed version, package, licence, and deployment mode. Avoid copying a generic command line without checking the options supported by your binary. Configure nProbe to listen for the same NetFlow v9 or IPFIX format and UDP port configured on the MikroTik target, then configure ntopng to consume the data using the supported integration method for that nProbe release.

1. Install from official packages. Follow the current ntop documentation for your operating system and release. Record the installed versions and licence status.
2. Configure the flow input. Set nProbe’s collector/listener input to match the RouterOS exporter format and port. Confirm whether your architecture uses a local socket, a configured endpoint, or another documented hand-off to ntopng.
3. Permit only the required traffic. Allow the chosen UDP port from the MikroTik management or transit address to the collector. Do not expose the collector port to the public internet.
4. Open the ntopng interface. Restrict the web interface to a trusted management network or VPN, enable authentication, and use TLS through a suitable reverse proxy when access crosses an untrusted network.
5. Confirm the exporter is recognised. Look for the router as a flow source and check whether hosts, conversations, and protocol counters begin to populate.

Do not confuse the flow-export UDP port with ntopng’s web UI port. They serve different purposes and should have separate firewall policies. Use the actual listening ports configured in your deployment rather than assuming defaults.

Validate exported flows

Validate each hop independently. A working web interface does not prove that flow packets are arriving, and a UDP packet arriving at the host does not prove that its templates and records are being decoded.

1. Check RouterOS state. Run /ip/traffic-flow/print and /ip/traffic-flow/target/print. Confirm the feature is enabled, the target address is correct, and the intended format and port are set.
2. Generate test traffic. From a client behind the router, open a few websites or transfer a modest file. Allow for the inactive-flow timeout before expecting a record.
3. Inspect packets on the collector. On a Linux collector, a command such as the following can confirm that UDP packets reach the host:

sudo tcpdump -ni any host ROUTER_IP and udp port 2055

Replace ROUTER_IP with the exporter’s actual source address and adjust the port if you selected another one. Packet capture may expose internal addressing and metadata; store or share captures carefully.

4. Check nProbe logs and counters. Look for received packets, template decoding errors, unexpected exporter addresses, or permission/licensing errors.
5. Check ntopng. Confirm the expected interface or flow source appears and that timestamps and counters advance when test traffic is generated.

Use ntopng for traffic analysis

Once records are arriving, use the views available in your installed ntopng edition to investigate operational questions rather than treating a dashboard as an end in itself.

• Top talkers: identify hosts accounting for the largest byte or packet totals during a chosen period.
• Conversations: inspect source/destination pairs and service ports to understand which systems exchange the most traffic.
• Protocol distribution: compare expected application mix with observed flow classifications. A port number is only a hint; it does not prove what application generated the traffic.
• Time-based changes: correlate increases in traffic with scheduled backups, software deployments, user activity, or suspected incidents.
• Unexpected destinations: investigate new external peers or unusual outbound volumes using endpoint, DNS, firewall, and security telemetry as corroborating evidence.

For example, if a WAN link becomes saturated, start with the busiest hosts and conversations for the affected time window. Determine whether the volume is expected (such as a backup) or anomalous, then correlate with interface counters, queue statistics, DNS logs, firewall events, or packet captures. Flow records are a strong triage signal, but they are not by themselves proof of compromise or a complete record of every packet.

Troubleshooting common problems

Symptom	Likely cause	What to check
No packets at collector	Wrong destination, routing, firewall, or target disabled	RouterOS target, route to collector, UDP ACLs, and packet capture on the collector
Packets arrive but no decoded flows	Wrong format, missing/stale templates, or incompatible input mode	Match v9/IPFIX settings, inspect nProbe logs, and verify template refresh settings
Flows appear after a delay	Inactive/active timeout behaviour	Allow for configured timeouts before concluding export is broken
Traffic totals are lower than interface counters	Hardware offload, sampling, observation point, or directionality	Check forwarding path, sampling settings, and which interfaces are monitored
Some devices or VLANs are missing	Traffic bypasses CPU flow processing or is not included in selected interfaces	Test the specific bridge, VLAN, routed, and offloaded path on the model in use
Collector load grows unexpectedly	Too many observed interfaces, aggressive timeouts, or high flow churn	Review exporter scope, cache settings, packet sampling, and collector capacity

NetFlow v9 and IPFIX rely on templates. If a collector starts receiving data records before it has the relevant template, or if templates expire without refresh, the collector may be unable to decode the records. This is a protocol-level issue, not necessarily a RouterOS fault. RFC 3954 describes template refresh and collector behaviour.

Security and performance considerations

• Keep flow export private. Flow metadata can reveal internal hosts, communication patterns, and service usage. Restrict the exporter destination and collector listener to trusted networks.
• Use firewall allow-lists. Permit UDP flow traffic only from known router addresses. Restrict management access to ntopng and nProbe separately.
• Account for privacy and retention. Define who can access traffic metadata, how long it is retained, and when it should be deleted according to organisational policy and applicable law.
• Monitor router CPU and collector capacity. Flow generation consumes resources and can increase exported data volume. Establish a baseline and avoid changing cache or timeout values without measuring the effect.
• Understand visibility gaps. Traffic-Flow does not provide full packet payloads, and hardware-offloaded traffic may not be reported. Validate the design against the network architecture.
• Plan rollback. Record existing configuration before changes. To stop exporting, disable Traffic-Flow with /ip/traffic-flow/set enabled=no; remove a target only after verifying its exact entry and impact.

Alternatives and when to use them

NetFlow-style records are appropriate for traffic accounting and high-level investigation, but they are not the only observability option.

• RouterOS interface counters and SNMP: best for interface utilisation, availability, and long-term device metrics. They do not provide the same per-conversation detail as flow records. See the MikroTik SNMP monitoring with LibreNMS guide.
• Packet capture with Wireshark: best when you need packet-level timing, protocol fields, or payload inspection where legally and technically appropriate. It captures packets rather than summarising conversations. See the Wireshark DNS troubleshooting guide.
• RouterOS Traffic-Flow with ntopng: best when you need searchable flow records and host/conversation analysis in a dedicated interface, subject to the platform’s visibility limits and the required collector architecture.

Frequently asked questions

Can ntopng receive MikroTik NetFlow directly?

MikroTik’s Traffic-Flow documentation states that nProbe is required to use ntopng with MikroTik. Confirm the current supported architecture and licence terms in the official ntop documentation for your version rather than assuming direct ingestion is available in every edition.

Which NetFlow version should I use on MikroTik?

NetFlow v9 is a reasonable starting point when the receiver supports it, and RouterOS also offers IPFIX. Choose the format supported by your exact RouterOS and nProbe versions, and verify template handling end to end.

Why does ntopng show less traffic than the router interface counters?

Traffic-Flow can miss hardware-offloaded traffic, and interface counters may measure a different point or direction. Sampling, selected interfaces, flow timeouts, and aggregation also affect comparisons. Check these differences before assuming the collector is losing records.

Does NetFlow show the contents of network packets?

No. NetFlow and IPFIX provide flow metadata and counters, not a full packet capture. Use an authorised packet-capture tool when packet-level detail is required.

Which UDP port should I open?

Use the port configured on both the RouterOS target and the collector. MikroTik documents UDP port 2055 as the target default, but your actual configuration may differ. Restrict the firewall rule to the exporter and collector addresses.

Is the setup free?

RouterOS Traffic-Flow is built into RouterOS, but MikroTik’s documentation says nProbe is required for the ntopng integration. Check ntop’s current licensing and edition requirements before planning a production deployment.

Conclusion

MikroTik Traffic-Flow and ntopng can provide useful network visibility when the exporter, flow collector, and analysis interface are configured as a compatible pipeline. Start with a limited observation scope, confirm that UDP packets and templates are decoded, and validate the results against known traffic. Most importantly, account for hardware-offload blind spots, flow metadata sensitivity, and the nProbe requirement before treating the dashboard as a complete picture of network activity.

References

• MikroTik documentation: Traffic-Flow
• RFC 3954: Cisco Systems NetFlow Services Export Version 9
• ntop official documentation guides
• MikroTik documentation: L3 Hardware Offloading

---

Check our list of MikroTik guides