NetFlow for ISPs: Real-Time Traffic Analysis & DDoS Detection

Why ISPs Need Flow Visibility

Most ISPs only learn about a problem when subscribers call. By the time the support queue lights up, the upstream link has already been saturated for fifteen minutes, the queue tree is melting, and nobody knows whether the cause is an ONU loop, a single subscriber on a torrent, or a 4 Gbps UDP reflection attack hitting a customer IP.

NetFlow fixes this gap. Instead of guessing, you see exactly which source and destination pairs are producing the traffic, on which protocols and ports, in near real time — without an inline packet inspector and without slowing down your edge.

For ISP operators, that visibility is the difference between a one-line incident report and a three-hour outage.

What NetFlow Actually Records

NetFlow does not capture packet payloads. Each flow record summarises a unidirectional conversation between two IPs — source address, destination address, source port, destination port, protocol, ToS, packet count, byte count, and start/end timestamps. Routers and switches that support NetFlow batch these records into UDP datagrams and ship them to a collector at fixed intervals.

ISPbills runs the collector for you, decodes NetFlow v5, v9 and IPFIX, joins the source IP back to the subscriber that owns it, and presents the data through the Monitoring → NetFlow dashboard.

Exporting Flows From the Edge

NetFlow is only useful if your edge devices are actually exporting. The collector address and UDP port are shown in Monitoring → NetFlow → Sources.

MikroTik (RouterOS)

MikroTik calls the feature Traffic Flow. The following enables NetFlow v9 export to your ISPbills collector:

/ip traffic-flow
set enabled=yes interfaces=ether1-wan,bridge-lan cache-entries=4k active-flow-timeout=1m

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

For routers handling more than 1 Gbps of mixed subscriber traffic, enable sampling so the CCR does not spend cycles on every packet:

/ip traffic-flow
set packet-sampling=yes sampling-interval=1000 sampling-space=128

A 1-in-1000 sample is more than accurate enough for DDoS detection and top-talker reporting.

Cisco IOS

ip flow-export version 9
ip flow-export destination 10.10.0.20 2055
ip flow-export source Loopback0
interface GigabitEthernet0/0
 ip flow ingress
 ip flow egress

For modern IOS-XE / IOS-XR, prefer Flexible NetFlow (flow exporter / flow monitor) which supports IPFIX and richer fields.

Juniper

set services flow-monitoring version-ipfix template ispbills template-refresh-rate seconds 30
set services flow-monitoring version-ipfix template ispbills option-refresh-rate seconds 30
set forwarding-options sampling instance ispbills family inet output flow-server 10.10.0.20 port 2055 version-ipfix template ispbills
set forwarding-options sampling instance ispbills input rate 1000

Linux Edges and Softflowd

For Linux-based shapers, MPLS-PE boxes or NAT64 gateways without native NetFlow:

apt install softflowd
softflowd -i eth0 -n 10.10.0.20:2055 -v 9

Verify the export is reaching ISPbills under Monitoring → NetFlow → Sources — every active exporter shows up within roughly 30 seconds with its current flow rate.

Spotting a DDoS in the Flow Stream

DDoS traffic looks different from organic traffic, and NetFlow records make those differences obvious. Train your eyes on these signatures in the dashboard:

The single most useful view during an incident is Top Destinations by Bytes filtered to the last 5 minutes. If one subscriber IP dominates the chart by an order of magnitude, you have your target and you can mitigate immediately.

Building DDoS Detection Rules

Manual dashboard watching only gets you so far. ISPbills lets you turn flow patterns into alerts:

1. In Monitoring → NetFlow → Detectors, add a rule.
2. Pick a metric — inbound bps per destination IP, packets per second per destination, or unique sources per destination.
3. Set the threshold based on a reasonable multiple of your normal peak (start at 5× and tune downward).
4. Set the evaluation window — 60 seconds is a sensible default for volumetric attacks.
5. Choose the action — open a ticket, email the on-call rotation, post to a webhook, or trigger a remote-trigger black hole (RTBH) BGP update.

A typical starter set:

For mitigation, NetFlow pairs naturally with MikroTik address-list rules. A webhook receiver can drop the offending IP into an address-list named ddos-blackhole, and an existing firewall rule (/ip firewall raw add chain=prerouting src-address-list=ddos-blackhole action=drop) absorbs the attack before it ever hits the queue tree.

If you operate your own ASN, the same webhook can issue a BGP RTBH announcement to your transit provider for the targeted /32, taking the floods off the wire entirely.

Turning Flows Into Capacity Decisions

Beyond DDoS, the same flow data is the cleanest input for capacity planning:

• Per-package consumption — average and peak Mbps per subscriber, broken down by tariff. Useful when deciding whether to bump a 30 Mbps plan to 50 Mbps without buying more upstream.
• Protocol mix — the ratio of TCP-443 (TLS / streaming) to UDP-443 (QUIC) to gaming and torrent traffic. A growing UDP-443 share is a good sign you should test QUIC handling on your shapers.
• Peer evaluation — bytes per upstream interface and per remote ASN. If 60% of your evening traffic is going to one CDN, peering directly with them is a measurable cost saving.
• Anomaly baselines — week-over-week comparison of the same hour exposes slow leaks, like a customer running a poorly-secured open recursive DNS server.

Export the report as CSV, drop it into your finance review, and you have an evidence-based case for the next upstream upgrade.

Sampling, Retention and Performance

For ISPs above a few Gbps of edge traffic, three knobs matter:

• Sampling rate — 1-in-1000 is enough for security and capacity. Use unsampled NetFlow only on interfaces below 200 Mbps if you need exact byte accounting per flow.
• Active flow timeout — 60 seconds is the right balance. Lower values bloat collector load; higher values delay detection.
• Retention — ISPbills keeps high-resolution flow data for 7 days and rolled-up summaries for 90 days. Long-term archival can be exported via the /api/netflow/export endpoint to your own object storage.

Properly configured, NetFlow export adds well under 1% CPU on a CCR2004 carrying a gigabit of mixed PPPoE traffic.

Pricing and Trial

NetFlow is a paid add-on in ISPbills, priced at half your active subscription fee, with a 15-day free trial. The trial gives you the full collector, all detectors, all reports, and unlimited flow sources — long enough to run it through a real evening peak and a weekend traffic pattern before deciding.

Activate the trial from Account → Plans → Add-ons → NetFlow. Existing customers on the Mid-tier (up to 2,000 subscribers) and Large-tier (2,001+) plans see the add-on automatically.

Putting It All Together

Edge devices already know what is happening on your network — NetFlow is just the channel that lets them tell you. Once you have flows landing at the collector, every other capability stacks on top: DDoS detection, abuse handling, capacity planning, peering analysis, and post-incident forensics all share the same data source.

For a working ISP that today learns about traffic events from angry phone calls, switching that loop to a NetFlow-driven dashboard is one of the highest-leverage upgrades available. Configure your edge, point it at the collector, set a couple of detectors, and let the next attack announce itself before your subscribers do.