Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.
Interface counters tell you how much traffic crossed a link. They do not tell you which prefix, port, or customer produced it. Flow telemetry fills that gap: the router, switch, or a Linux host summarises traffic as flows and exports records to a collector. For a small ISP or hosting network it answers the practical questions of who is using the bandwidth, what an attack looked like, and where capacity is going. This article compares the main formats, shows a small Linux setup, and covers IPv6-specific points. Examples use 2001:db8:100::/48 and 203.0.113.0/24.
What a flow is
A flow is a set of packets sharing key fields, typically the source and destination address, protocol, and source and destination ports, observed within a time window. The exporter keeps a cache of active flows and sends a record when a flow ends or after a timeout. Each record holds the key fields plus counters for packets and bytes, timestamps, interfaces, and often TCP flags, AS numbers, and next hop. This is metadata; there is no payload.
The formats
| Format | Model | Notes |
|---|---|---|
| NetFlow v5 | Fixed-format records | IPv4 only, so it cannot describe IPv6 traffic |
| NetFlow v9 (RFC 3954) | Template-based records | Supports IPv6 and flexible fields |
| IPFIX (RFC 7011) | Template-based, IETF standard, derived from NetFlow v9 | Registered fields; the vendor-neutral choice |
| sFlow | Samples packets and interface counters | Does not keep a flow cache; the collector builds flows from samples |
The IPv6 point matters: if your exporter only speaks NetFlow v5, IPv6 traffic will be missing from your picture. Use v9, IPFIX, or sFlow. Template-based formats first send a template that describes the record layout, followed by data records, so collectors must receive the templates; a collector restarted mid-stream may discard records until the next template arrives.
By convention NetFlow is often sent to UDP port 2055, though this is not a standard for NetFlow. IANA registers port 4739 for IPFIX and 6343 for sFlow.
Sampling and what it costs
Exporting every flow is expensive on busy links, so most devices sample, examining one packet in N. The collector then multiplies byte and packet counts by the sampling rate to estimate totals. Consequences:
- Large flows are estimated well. Small and short flows may be missed completely.
- A sampled record is evidence that traffic existed, not an exact count.
- Mixing devices with different sampling rates without recording the rate gives wrong totals.
Record the sampling rate in your documentation and make sure your collector uses it. sFlow is built around this idea, since its samples are packet headers taken at a defined rate, while NetFlow and IPFIX exporters can run either sampled or unsampled, depending on the hardware.
A small Linux setup
On a Linux router without hardware flow export, a software exporter can read traffic from an interface. One option is softflowd, which can export NetFlow v9 or IPFIX, and another is pmacctd. For sFlow on a host, hsflowd is common. A collector can be nfdump with nfcapd, or pmacct's nfacctd.
A sketch with softflowd and nfdump:
softflowd -i eth0 -n 127.0.0.1:2055 -v 9
nfcapd -l /var/cache/nfdump -p 2055 -D
nfdump -R /var/cache/nfdump -s srcip/bytes -n 10
The first command exports flows from eth0 as NetFlow v9; the second receives and stores them; the third prints the top ten source addresses by bytes. Add a filter for the IPv6 family using the syntax your nfdump version documents. Option names differ between tools and versions, so check the manual pages. Keep the collector on a separate machine or at least a separate volume for any real network, because flow storage grows steadily.
IPv6 considerations
- Aggregate by /64. As in the logging article, one subscriber can use many addresses within a /64. Ranking individual IPv6 addresses by bytes will mislead you, so most tools let you group by prefix length. Use /64, and widen to /48 for delegations.
- Extension headers. Some exporters classify packets with extension headers poorly, so ports may be zero.
- Dual-stack views. Report IPv4 and IPv6 separately before combining them.
- Fragments. Non-first fragments have no port information, so they appear as port zero or in separate flows.
Useful questions to ask the data
- Top talkers: which destination prefixes or customers use the most bytes in the last hour.
- Attack triage: packets per second by destination address and protocol, to see whether a spike is a flood aimed at one host.
- Capacity planning: daily peaks by upstream, peer, or customer.
- Peering decisions: which origin ASes carry the most traffic, if your records include AS numbers, to judge whether a direct peering would be worthwhile.
- Abuse and complaints: whether a host did contact a destination at a stated time, with timestamps that you should verify against NTP-synced clocks.
Operational notes
Make sure router and collector clocks are synchronised. Choose flow timeouts deliberately, since active timeouts break long flows into several records and short inactive timeouts split idle connections. Flow records are personal data in some jurisdictions, so set retention, and restrict access. Finally, protect the collector: it receives unauthenticated UDP, so accept exports only from known router addresses.
Summary
Use NetFlow v9, IPFIX, or sFlow, because NetFlow v5 cannot carry IPv6. Know your sampling rate and apply it, aggregate IPv6 by /64, keep clocks and timeouts sane, and treat flow data as an estimate that answers "who and how much" rather than an exact bill of every packet.
About IPYE
IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.
Disclosure: I run IPYE
Top comments (0)