Traffic analysis (NetFlow)

Interface traffic tells you how much went over a link. Traffic analysis tells you who used it: which host, to which destination, over which port, in which AS and which region.

Visualization → Traffic analysis.

What it actually stores

No raw flows. None.

An edge router running 10G unsampled exports thousands to tens of thousands of flow records per second — hundreds of millions of rows a day. No single-box database survives that, and if it did, you could not query it. So the collector aggregates in memory per time window and stores only two things per window:

• totals: bytes, packets and flows for that minute;
• the top N per dimension: source IP, destination IP, conversation, source/destination port, protocol, source/destination AS, country, province.

Which gives you one boundary worth knowing up front:

The rankings answer "who is using the bandwidth". They cannot answer "who did this particular IP talk to yesterday afternoon" if it never made the top N — that traffic was never stored.

For that, use targeted capture at the bottom of the page: open a window on one IP or a small prefix, record only that target's raw flows, and it stops on its own. Storing everything is impossible; storing one target is easy.

Turning it on

1. Traffic analysis → Collector settings → Enable collection, and check the collector port (udp/2055 by default; NetFlow v5/v9, IPFIX and sFlow all share this one port and are told apart by the packet header; collection is off by default).
2. Open those UDP ports on the firewall; container installs also need them published on the host (the one-click installer does this by default — see the install guide).
3. Configure export on the devices, pointing at the vConfig host.

Device-side examples (adjust interfaces and versions to your kit):

Cisco IOS / IOS-XE

ip flow-export version 9
ip flow-export destination <vConfig-IP> 2055
ip flow-sampling-mode packet-interval 1000
interface GigabitEthernet0/0/1
 ip flow ingress
 ip flow egress

Huawei VRP

ip netstream export version 9
ip netstream export host <vConfig-IP> 2055
ip netstream sampler fix-packets 1000 inbound
interface GigabitEthernet0/0/1
 ip netstream inbound
 ip netstream outbound

H3C Comware

ip netstream export version 9
ip netstream export host <vConfig-IP> 2055
ip netstream sampler fix-packets 1000
interface GigabitEthernet1/0/1
 ip netstream inbound
 ip netstream outbound

Juniper Junos

set services flow-monitoring version9 template ipv4 template-refresh-rate seconds 60
set forwarding-options sampling instance FLOW family inet output flow-server <vConfig-IP> port 2055
set forwarding-options sampling instance FLOW input rate 1000

Sampling rate: get it wrong and nothing looks wrong

This is the one number most likely to bite you. At 1:1000, each flow we receive stands for a thousand on the wire, and every byte count is multiplied accordingly. Get it wrong and the charts still render — they are simply off by an order of magnitude, invisibly.

So:

• when a device reports its sampling rate in v9/IPFIX, the device wins;
• for devices that report none, set it by hand in the Exporters table — the UI always shows whether a value came from the device, from a person, or from the default;
• if you change sampling on the device, come back and change it here. A manually entered value does not follow the device.

Region, AS and organisation

An IP's identity is resolved in this order, entirely offline:

1. Your IPAM records — internal addresses are looked up in your own data, which yields "which customer, which service". No public database has that layer; it is the main thing this differs in from a standalone NetFlow tool.
2. Local cache table.
3. Built-in prefix database (prefix → ASN / organisation / country).
4. A MaxMind GeoLite2 file you supply yourself (it needs an account, so we do not ship it).
5. Otherwise: unknown. It does not guess.

Databases live under data/netflow/. After updating one, hit Collector settings → Reload IP database — no restart needed. Without a database, the AS and region columns read unknown and everything else works as before.

Retention

Granularity	Default	For
1 minute	24 hours	troubleshooting detail
5 minutes	7 days	this week
1 hour	90 days	trends

A background job rolls buckets up every 5 minutes and drops expired data. Longer retention means bigger, slower tables — tune it in Collector settings.

Watch the drop counter

"Dropped" in the status bar counts packets we did not take in. When the receive thread is saturated it drops rather than blocks — blocking would slow the whole box down. So a non-zero value means the traffic you see is understated; do not read it as a drop in network traffic. Sustained drops mean the devices send faster than we ingest: raising the sampling rate (1:1000 → 1:5000) usually fixes it immediately.

Alerting

Two rules under Alert settings relate to flow analysis, both off by default:

• New talker: a source that never appeared in the last 24 hours of rankings but is suddenly near the top this hour. Unannounced new services, config changes and hosts phoning home all look like this.
• Traffic on a suspicious port: meaningful volume on Telnet, SMB, RDP, Redis and friends — ports that have no business on a wide-area link.

Both build on the rankings: anything anomalous is, by definition, big enough to reach them.