MetricSplit › Guides › Cisco Catalyst SD‑WAN
How to send flow data from Cisco Catalyst SD‑WAN to a collector (cflowd and IPFIX)
Catalyst SD‑WAN routers can export a record of every conversation they forward (addresses, ports, application, bytes) to a flow collector. Cisco calls this cflowd; the records travel as IPFIX over UDP. You set it up once, centrally, in SD‑WAN Manager, and it reaches every router you choose. This guide works for any IPFIX collector; where MetricSplit is mentioned, that's what we do with it.
Before you start
- Access to SD‑WAN Manager with rights to edit and activate a centralized policy.
- The collector's address and UDP port, for example
192.0.2.10, UDP2055. - A firewall rule that lets UDP from your routers out to that address and port. Behind NAT, the collector sees the address after NAT, so that's the one that counts.
- With MetricSplit: send us your routers' public addresses before you start. We register them, so their flow data is accepted.
1. Create a cflowd template (where the records go)
In SD‑WAN Manager, under Configuration › Policies › Centralized Policy › Custom Options › Cflowd, add a cflowd template. Menu names differ by release (newer releases may use policy groups).
- Collector: the address and port, transport UDP. The collector VPN is the VPN the router uses to reach the collector: VPN 0 for direct internet breakout, or a service VPN when exports go through a data centre or firewall (common with central internet breakout; this is also how several routers end up behind one public address). We receive both: routers exporting from their own public address, and routers whose exports reach us through a data centre's internet exit.
- Export protocol: IPFIX. NetFlow v9 is also offered by some releases.
- Active flow timeout: 30 seconds, the shortest the cflowd template allows (Cisco: 30 - 3600 seconds, default 600). Cisco IOS XE Catalyst SD‑WAN routers use a fixed 60 seconds whatever is set, which is fine. Why: MetricSplit works in 5-minute readings, so a long-running flow has to be reported at least every minute to land in the right reading.
- Template refresh: a collector can only read records once it has the matching template, so a shorter template refresh means a faster recovery after a router restart or a template change.
- Sampling: routers sampling 1 in 10 packets work: they also send a sampler table, and the collector scales the counts back up.
- Collect options, if your release offers them: application ID, DSCP. The routers we receive from also send a table of application names and one of interface names, which turn numbers into readable names.
2. Turn it on with a data policy (which traffic is reported)
In the same centralized policy, add a traffic data policy with a sequence that matches the traffic to report (usually all of it), action Accept, with Cflowd enabled.
- Apply it to a site list and a VPN list: the sites whose routers should export, and the service VPNs whose traffic you want reported.
- Warning: a centralized data policy's default action is Drop. Set the default action to Accept, or make the sequence match all traffic. If the sites already have a data policy, add the cflowd action to it instead of creating a new one: only one data policy applies per site list, VPN and direction.
- Try one site first, in a change window, then widen the site list.
3. Check the records are leaving the router
On a router's command line (Cisco's commands):
show sdwan app-fwd cflowd collector # the collector is listed
show sdwan app-fwd cflowd statistics # export counters are increasing
show sdwan app-fwd cflowd flows # active flows4. Check they're arriving at the collector
On a Linux collector, a short packet capture shows whether anything arrives at all:
sudo tcpdump -ni any udp port 2055 -c 20Seeing packets from your routers' public addresses means the path is open; the collector then needs each router's templates (sent within the template refresh time) before it can read the records. In MetricSplit, each router then appears in Settings, where you name it, put it in a site and enter its circuit speeds.
What the records contain
What Catalyst SD‑WAN routers send us, per flow:
| Field | Used for |
|---|---|
| Source and destination IPv4 address and port, protocol, TCP flags | who talked to which service |
| Bytes and packets (sampled, scaled back up) | how much traffic |
| Flow start and end time | when, down to the 5-minute reading |
| Ingress and egress interface (with the interface-name table) | which circuit and direction |
| Application ID (with the application-name table) | which application |
| DSCP marking, VPN ID | traffic class and segment |
No packet contents. IPv6 flows:
Troubleshooting
- Nothing arrives: check the firewall rule and the address after NAT. With MetricSplit, also check we've registered that address.
- Records arrive, but no application names: turn on application ID in the cflowd template's collect options.
- Records arrive but can't be read yet (after a router restart or a template change): the collector needs the router's current templates, which arrive within one template-refresh interval. MetricSplit keeps the templates it has learned across its own restarts.
- Several routers behind one public address (for example sites that reach the internet through a data centre): each router's export is a separate stream, and MetricSplit will show them as separate routers.
What MetricSplit does with flow records
MetricSplit receives flow records (metadata only, no packet contents) and is never in your traffic path. It classifies your traffic as business, neutral or non-business, by application and by site, and gives each circuit a decision (rebalance, right-size, restrict or upgrade) with the evidence.
Other vendors: How to send NetFlow or IPFIX to a flow collector