RouterOS 7 Traffic Flow: Replace /ip accounting and Rebuild Your HTTP Endpoint

What happened to /ip accounting in RouterOS 7

MikroTik removed /ip accounting entirely when RouterOS 7 shipped. No compatibility layer, no migration path built in. If your tooling polled http://<router>/accounting/ip.cgi to pull a per-flow table in plain text, that endpoint is simply gone.

The old feature had a genuinely useful design: enable it, hit the URL, get a snapshot of SRC, DST, BYTES, PACKETS accumulated since your last request. Clean, pull-based, no external dependencies. RouterOS 7’s replacement — Traffic-Flow — flips that model completely. The router pushes flow records out as UDP datagrams. You need something external to catch them.

Traffic-Flow: what it actually is

Traffic-Flow is MikroTik’s implementation of Cisco’s NetFlow protocol. It tracks per-flow statistics as packets pass through the router and exports those records to a collector you specify. RouterOS supports NetFlow v1, v5, v9, and IPFIX.

  • v5 — fixed-field format, simple, reliable. Exports source IP, destination IP, source port, destination port, protocol, bytes, packets. Widely supported by every collector out there. Best starting point.
  • v9 — template-based, more flexible. MikroTik’s implementation has had reported timestamp field issues in some RouterOS 7 versions, so test it before depending on it in production.
  • IPFIX — IETF-standardized evolution of v9. Most capable, but collector support varies more than v5 or v9.

For a direct replacement of what /ip accounting gave you, v9 is generally the right pick — just verify your collector handles it cleanly on the specific RouterOS build you’re running.

Enabling Traffic-Flow on RouterOS 7

Two CLI commands are all it takes. Enable the feature and choose which interfaces to monitor:

/ip traffic-flow
set enabled=yes interfaces=all

Then add a collector target:

/ip traffic-flow target
add dst-address=192.168.1.100 port=2055 version=9

Replace 192.168.1.100 with the IP of your collector machine. Port 2055 is the most common convention; 9995 and 9996 are also frequently used. The router begins sending UDP datagrams immediately after you add the target.

On newer RouterOS 7 builds you may also need to set a source address so your collector can identify the sender:

/ip traffic-flow
set src-address=<router-LAN-IP>

Tuning the flow timeouts

Two settings control export frequency. active-flow-timeout forces an export for flows that never go idle (default 30 minutes). inactive-flow-timeout triggers export when a flow goes quiet (default 15 seconds).

For near-real-time accounting close to what /ip accounting gave you, tighten both:

/ip traffic-flow
set active-flow-timeout=1m inactive-flow-timeout=15s

This trades a slight increase in export volume for much fresher data at your collector.

Choosing a collector

The collector is a daemon that listens on a UDP port and stores or processes incoming flow records. Several solid open-source options exist for self-hosted use.

nfdump

nfdump is the workhorse choice on Linux. It ships with two main pieces: nfcapd, which listens for flow datagrams and writes them to binary files, and the nfdump query tool that reads those files and formats output however you need.

Install on Debian or Ubuntu:

apt install nfdump

Start the capture daemon:

nfcapd -w -D -l /var/flows -p 2055

Query the last recorded interval:

nfdump -R /var/flows -o 'fmt:%sa %da %byt %pkt %sp %dp' -q

That output maps directly to the SRC DST BYTES PACKETS SRC_PORT DST_PORT format the OP wants. You can wrap the query in a small HTTP handler to reconstruct the pull-based interface.

GoFlow2

If you want a streaming pipeline rather than file-based storage, netsampler/goflow2 handles NetFlow v5, v9, sFlow, and IPFIX at high throughput. It emits flow records as JSON to stdout, Kafka, or a file. Cloudflare originally wrote GoFlow; the maintained community fork is goflow2. Good fit for feeding into InfluxDB, Prometheus, or a custom processor.

Rebuilding the plain-text HTTP endpoint

The original goal — serve SRC DST BYTES PACKETS SRC_PORT DST_PORT over HTTP, with each response showing only the delta since the previous request — needs two things: a collector accumulating flows, and a small HTTP handler doing the diff. Here is a minimal Python implementation using nfdump under the hood:

#!/usr/bin/env python3
import subprocess
from http.server import HTTPServer, BaseHTTPRequestHandler

FLOW_DIR = '/var/flows'
last_snapshot = {}

def read_flows():
    out = subprocess.check_output([
        'nfdump', '-R', FLOW_DIR,
        '-o', 'fmt:%sa %da %byt %pkt %sp %dp',
        '-q'
    ], text=True)
    flows = {}
    for line in out.strip().splitlines():
        parts = line.split()
        if len(parts) == 6:
            key = (parts[0], parts[1], parts[4], parts[5])
            flows[key] = (int(parts[2]), int(parts[3]))
    return flows

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        global last_snapshot
        current = read_flows()
        lines = []
        for key, (b, p) in current.items():
            prev_b, prev_p = last_snapshot.get(key, (0, 0))
            db, dp = b - prev_b, p - prev_p
            if db > 0:
                lines.append(f'{key[0]} {key[1]} {db} {dp} {key[2]} {key[3]}')
        last_snapshot = current
        body = '\n'.join(lines).encode()
        self.send_response(200)
        self.send_header('Content-Type', 'text/plain')
        self.end_headers()
        self.wfile.write(body)
    def log_message(self, *args): pass

HTTPServer(('0.0.0.0', 8080), Handler).serve_forever()

This is intentionally minimal. In a production setup you would want to track which nfdump capture files have already been processed rather than re-reading the full directory each poll, handle counter wraparound for long-lived flows, and daemonize the process properly. But the structure maps directly onto what /ip accounting used to do on the router side.

Where to run the collector

The router sends UDP, so the collector can live on any reachable machine — a Raspberry Pi, a VM, a Docker container on your NAS. Running it off the router is actually better: the router’s CPU stays uninvolved in parsing, and you can store weeks of flow history without touching RouterOS’s limited storage.

A small container running nfdump works fine for home-lab scale. Point Traffic-Flow at the container’s IP, open port 2055 UDP in whatever firewall sits between them, and you’re collecting flows within a few minutes of enabling the feature.

Sources

Related Articles

Similar Posts