master
md 191 lines 9.03 KB
Rendered Raw
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.