LEARN. PRACTICE. GROW.Concept and mechanism
Flexible NetFlow separates record, monitor, and exporter. The record defines fields, the monitor associates cache and content, and the exporter sends information. Observation requires attachment to a supported interface and direction; creating objects does not guarantee traffic collection. A migration can leave the monitor on the old path and produce an empty dashboard while service works. SPAN has another limit: a saturated destination port can lose copies without equivalent loss in original forwarding. Before turning capture absence into an application conclusion, confirm capacity, scope, and direction of the observation point.
Guided application
IP SLA also needs representative source, destination, and routing context. A global-table echo does not automatically measure an application in another VRF, and ICMP does not demonstrate a transaction commit. For programmable reading, NETCONF distinguishes get-config from get: the former reads configuration from the specified datastore, while the latter can include operational state. Check capabilities before assuming candidate or confirmed commit. These are not guarantees arising merely from a NETCONF session. In a fictional RUN handover, retain collection points, criteria, and limitations. The team should know what was measured, when, and under which context so it does not investigate a service failure where instrumentation has failed.
The collector is empty because the monitor stayed on the old interface, not because batch stopped.
Common pitfalls
Created object as active collection; incomplete capture as loss proof; ICMP as functional success; NETCONF as every capability.
Related topics: Architecture and surviving capacity · Virtualization, VRFs, and overlays · Switching and adjacency formation
Retain observation limits alongside results.
Reference: Flexible NetFlow IPv4 flows · 350-401 ENCOR v1.2, effective 2026-03-19; core component of CCNP Enterprise