| 1 | <!--startmeta |
| 2 | custom_edit_url: "https://github.com/netdata/netdata/edit/master/docs/network-flows/quick-start.md" |
| 3 | sidebar_label: "Quick Start" |
| 4 | learn_status: "Published" |
| 5 | learn_rel_path: "Network Flows" |
| 6 | keywords: ['quick start', 'netflow', 'sflow', 'ipfix', 'getting started', 'setup'] |
| 7 | endmeta--> |
| 8 | |
| 9 | <!-- markdownlint-disable-file --> |
| 10 | |
| 11 | # Quick Start |
| 12 | |
| 13 | Get flow monitoring running in 15 minutes. The path: install the plugin, configure your first router, open the dashboard, and read it correctly. |
| 14 | |
| 15 | ## Before you start |
| 16 | |
| 17 | - The Netdata Agent is running on the host that will collect flow data. |
| 18 | - The [netflow plugin is installed](/docs/network-flows/installation.md) on that host. |
| 19 | - You can configure flow export on at least one router or switch. |
| 20 | - The router can reach the agent's IP on UDP port 2055. |
| 21 | |
| 22 | If the plugin isn't installed yet, follow the [Installation page](/docs/network-flows/installation.md) first. |
| 23 | |
| 24 | ## Step 1 — Configure your router |
| 25 | |
| 26 | Pick the closest match to your platform. The configurations below set sensible defaults: 60-second active timeout (industry best practice), a quick template refresh where the platform supports tuning it (so a collector restart recovers in under a minute), and monitoring on the appropriate direction(s) of an interface. softflowd and Arista sFlow do not expose a template-refresh knob; they ship reasonable internal defaults. |
| 27 | |
| 28 | ### Cisco IOS / IOS-XE (Flexible NetFlow, v9) |
| 29 | |
| 30 | ``` |
| 31 | flow exporter NETDATA |
| 32 | destination 10.0.0.10 ! Netdata agent IP |
| 33 | source GigabitEthernet0/0/0 ! source interface |
| 34 | transport udp 2055 |
| 35 | export-protocol netflow-v9 |
| 36 | template data timeout 60 |
| 37 | ! |
| 38 | flow record NETDATA-RECORD |
| 39 | match ipv4 source address |
| 40 | match ipv4 destination address |
| 41 | match transport source-port |
| 42 | match transport destination-port |
| 43 | match ipv4 protocol |
| 44 | match interface input |
| 45 | collect interface output |
| 46 | collect counter bytes |
| 47 | collect counter packets |
| 48 | collect timestamp sys-uptime first |
| 49 | collect timestamp sys-uptime last |
| 50 | ! |
| 51 | flow monitor NETDATA-MONITOR |
| 52 | record NETDATA-RECORD |
| 53 | exporter NETDATA |
| 54 | cache timeout active 60 |
| 55 | cache timeout inactive 15 |
| 56 | ! |
| 57 | interface GigabitEthernet0/0/1 |
| 58 | ip flow monitor NETDATA-MONITOR input |
| 59 | ip flow monitor NETDATA-MONITOR output |
| 60 | ``` |
| 61 | |
| 62 | ### Juniper JunOS (J-Flow v9) |
| 63 | |
| 64 | ``` |
| 65 | set chassis fpc 0 sampling-instance NETDATA |
| 66 | set forwarding-options sampling instance NETDATA input rate 1000 |
| 67 | set forwarding-options sampling instance NETDATA family inet output flow-server 10.0.0.10 port 2055 |
| 68 | set forwarding-options sampling instance NETDATA family inet output flow-server 10.0.0.10 version9 template ipv4-template |
| 69 | set services flow-monitoring version9 template ipv4-template flow-active-timeout 60 |
| 70 | set services flow-monitoring version9 template ipv4-template flow-inactive-timeout 15 |
| 71 | set services flow-monitoring version9 template ipv4-template template-refresh-rate seconds 60 |
| 72 | set interfaces ge-0/0/1 unit 0 family inet sampling input |
| 73 | set interfaces ge-0/0/1 unit 0 family inet sampling output |
| 74 | ``` |
| 75 | |
| 76 | Notes: |
| 77 | |
| 78 | - The `set chassis fpc <slot> sampling-instance NETDATA` line is mandatory; without it the sampling instance is defined but never bound to a forwarding card and no flows are produced. |
| 79 | - `input rate 1000` sets a 1-in-1000 sampling rate. Adjust to match your traffic; the netflow plugin handles per-flow sampling-rate multiplication automatically. |
| 80 | - Replace `fpc 0`, `ge-0/0/1`, and `1000` with the FPC slot, interface, and sampling rate that match your platform. |
| 81 | |
| 82 | ### Arista EOS (sFlow) |
| 83 | |
| 84 | ``` |
| 85 | sflow run |
| 86 | sflow source-interface Loopback0 |
| 87 | sflow destination 10.0.0.10 2055 |
| 88 | sflow polling-interval 30 |
| 89 | sflow sample dangerous 2000 |
| 90 | ! |
| 91 | interface Ethernet1 |
| 92 | sflow enable |
| 93 | ``` |
| 94 | |
| 95 | EOS treats sample rates below 16 384 as "aggressive" — the `dangerous` keyword is required to opt in. For higher-rate interfaces, drop the `dangerous` keyword and use 16 384 or above. |
| 96 | |
| 97 | ### Linux host (`softflowd`, NetFlow v9) |
| 98 | |
| 99 | For Linux servers, hypervisors, or any host that doesn't natively speak NetFlow: |
| 100 | |
| 101 | ```bash |
| 102 | sudo softflowd -i eth0 -n 10.0.0.10:2055 -v 9 -t maxlife=60 -t expint=15 |
| 103 | ``` |
| 104 | |
| 105 | `maxlife` caps a flow's wall-clock lifetime at 60 seconds; `expint` controls how often softflowd scans the flow table for expired entries (it is not a template-refresh knob — softflowd's NetFlow v9 template interval is a compile-time default of 16 packets and is not exposed on the command line). |
| 106 | |
| 107 | For more vendors and details, see [Flow Protocols / NetFlow](/src/crates/netflow-plugin/integrations/netflow.md), [IPFIX](/src/crates/netflow-plugin/integrations/ipfix.md), and [sFlow](/src/crates/netflow-plugin/integrations/sflow.md). |
| 108 | |
| 109 | ## Step 2 — Open the dashboard |
| 110 | |
| 111 | In your browser, open the Netdata UI, click the **Live** tab in the top navigation, and select **Network Flows** from the Functions list. |
| 112 | |
| 113 | By default you'll see: |
| 114 | |
| 115 | - A Sankey diagram on top, with a sortable table beneath |
| 116 | - The default time range — last 15 minutes (Netdata's global picker) |
| 117 | - Top-25 flows by bytes |
| 118 | - Aggregated as **Source AS Name → Protocol → Destination AS Name** |
| 119 | |
| 120 | Within 60-90 seconds of the router being configured, flow records should start appearing. |
| 121 | |
| 122 | ## Step 3 — Read the dashboard correctly |
| 123 | |
| 124 | Before drawing any conclusion, read this. It's the single biggest source of confusion when people first look at flow data. |
| 125 | |
| 126 | ### Traffic looks doubled |
| 127 | |
| 128 | When a router is configured to export both ingress and egress flow records on every monitored interface — a common configuration — a packet that enters interface A and leaves interface B produces **two** records: one ingress on A, one egress on B. Vendor best practice is to export ingress-only to avoid this; if you can't change the exporter, the dashboard view has to compensate. |
| 129 | |
| 130 | If you look at total bandwidth without filtering, you see roughly **2× the real traffic**. Add a second router on the same path and you see 4×. |
| 131 | |
| 132 | **To see real bandwidth on a specific link**, filter to one exporter and one interface: |
| 133 | |
| 134 | 1. In the filter ribbon: `Exporter Name = <your router>`. |
| 135 | 2. Add: `Ingress Interface Name = <the interface>` **or** `Egress Interface Name = <the interface>` — pick one, not both. Each packet then appears in exactly one record on that interface. |
| 136 | |
| 137 | That's the actual traffic on that link. |
| 138 | |
| 139 | ### Bidirectional traffic shows both directions |
| 140 | |
| 141 | Every conversation has packets going both ways: requests / uploads in one direction, responses / downloads in the other. These are real, separate packets and produce separate flow records. The Sankey, country map, and time-series all show both directions when you don't filter by direction. |
| 142 | |
| 143 | Volumes in the two directions are usually asymmetric — for example, a video download produces large B→A flows and small A→B ACKs. A "Country X to Country Y" entry and a "Country Y to Country X" entry refer to the same conversations but typically have very different byte counts. That's correct per-direction accounting, not duplication. |
| 144 | |
| 145 | To see only one direction, filter by `Source AS Name` (your network) for outbound or `Destination AS Name` (your network) for inbound. |
| 146 | |
| 147 | ## Step 4 — Verify it's working |
| 148 | |
| 149 | If the Sankey is empty after 60-90 seconds, work through this: |
| 150 | |
| 151 | 1. **Datagrams arriving at the host.** |
| 152 | |
| 153 | ```bash |
| 154 | sudo tcpdump -i any -nn -c 20 'udp port 2055' |
| 155 | ``` |
| 156 | |
| 157 | If you see packets, the network path is fine. If not, check the router's exporter status, the firewall, and the source IP the router uses. |
| 158 | |
| 159 | 2. **Listener bound on the host.** |
| 160 | |
| 161 | ```bash |
| 162 | sudo ss -unlp | grep 2055 |
| 163 | ``` |
| 164 | |
| 165 | Should show `netflow-plugin` listening. If not, see [Troubleshooting](/docs/network-flows/troubleshooting.md). |
| 166 | |
| 167 | 3. **Plugin actually decoding.** |
| 168 | |
| 169 | Open the standard Netdata charts page and find `netflow.input_packets`. If `udp_received` is rising but `parsed_packets` isn't, datagrams are arriving but failing to decode. Check `parse_errors` and `template_errors` to narrow down. See [Plugin Health Charts](/docs/network-flows/visualization/dashboard-cards.md). |
| 170 | |
| 171 | 4. **Plugin log lines.** |
| 172 | |
| 173 | ```bash |
| 174 | sudo journalctl --namespace netdata --since "5 minutes ago" | grep -i netflow |
| 175 | ``` |
| 176 | |
| 177 | ## What's next |
| 178 | |
| 179 | You now have flow data flowing in. The natural next steps: |
| 180 | |
| 181 | - [Configuration](/docs/network-flows/configuration.md) — Tune retention after first validation; production retention should be sized from observed flow rate. |
| 182 | - [Static Metadata integration card](/src/crates/netflow-plugin/integrations/static_metadata.md) — Give your routers and your internal networks friendly names and labels. Without this, dashboards show raw IPs. |
| 183 | - [Investigation Playbooks](/docs/network-flows/investigation-playbooks.md) — Concrete recipes for the questions flow data is good at answering. |
| 184 | - [Anti-patterns](/docs/network-flows/anti-patterns.md) — Mistakes to avoid as you develop confidence with the data. |
| 185 | - [Validation and Data Quality](/docs/network-flows/validation.md) — How to confirm your numbers are correct. |
| 186 | |
| 187 | For more sources or vendors: |
| 188 | |
| 189 | - [NetFlow](/src/crates/netflow-plugin/integrations/netflow.md) — More vendor configurations, sampling caveats. |
| 190 | - [IPFIX](/src/crates/netflow-plugin/integrations/ipfix.md) — When and why to prefer IPFIX over NetFlow v9. |
| 191 | - [sFlow](/src/crates/netflow-plugin/integrations/sflow.md) — Different protocol, different semantics. |