4.2Traffic visibility and measurement (NetFlow, SPAN, IP SLA)

The job of visibility and measurement is to turn vague reports like "it is slow" or "it drops sometimes" into reproducible numbers. The key point is that the three methods answer different kinds of question. NetFlow answers the aggregate--"which host pairs consumed how much bandwidth"--but never shows packet contents. SPAN/ERSPAN shows per-packet facts--"what is the DSCP or the TCP flags on that packet actually set to"--but eats bandwidth if left running. IP SLA actively measures "what the latency, jitter, and reachability of this path are continuously, including hours with no users," and can tie a threshold breach to an action such as switching the path. The heart of this section is not mismatching the method to the question.

4.2.1The three components of Flexible NetFlow

• A flow record defines what identifies a flow (the keys) and what is accumulated (non-keys). match statements such as match ipv4 source address, match ipv4 destination address, and match transport destination-port are the keys, while collect statements such as collect counter bytes, collect counter packets, and collect interface output are the accumulated values. Packets sharing the same match values are folded into one flow, so the granularity of your matches is exactly the granularity of your analysis (to break down by DSCP you need match ipv4 dscp).
• A flow exporter defines where collected flows are sent: destination 10.50.0.20, transport udp 2055, source Loopback0, and export-protocol netflow-v9 (or IPFIX). Note that defining an exporter does nothing on its own.
• A flow monitor binds a record and an exporter and holds the cache: under flow monitor MON you specify record REC, exporter EXP, and cache timeout active 60. Measurement begins only when it is finally applied to an interface--ip flow monitor MON input (and output if needed) under interface GigabitEthernet0/1. The overwhelmingly common cause of "configured but the cache is empty" is this missing application. Verify with show flow monitor MON cache and show flow exporter statistics.

4.2.2The scope of SPAN, RSPAN, and ERSPAN

• SPAN (local SPAN) copies frames from source ports/VLANs to a destination port within the same device: monitor session 1 source interface GigabitEthernet0/1 both plus monitor session 1 destination interface GigabitEthernet0/24. The destination port stops functioning as a normal switch port (by default it discards received frames and does not participate in STP), so you must set aside a dedicated analyzer port.
• RSPAN carries the mirror over a dedicated RSPAN VLAN (vlan 900 plus remote-span) when source and destination are on different switches. Every switch and trunk along the way must permit and propagate that RSPAN VLAN--so it works only within L2 reach. It cannot cross an L3 boundary with a router in between.
• ERSPAN encapsulates the mirrored frames in GRE, so it can deliver them to a remote analyzer across a routed (L3) network. Under monitor session 1 type erspan-source you configure source interface ... and, under destination, erspan-id 101, ip address 10.50.0.30, and origin ip address 10.10.0.1; the receiver matches the same ERSPAN ID under type erspan-destination. Mismatched IDs and insufficient path MTU (for the GRE header) are the typical reasons it fails.

4.2.3IP SLA and object tracking

• IP SLA has the device itself generate synthetic traffic to actively measure reachability, latency, jitter, and packet loss. The minimal configuration is ip sla 1, icmp-echo 203.0.113.10 source-interface GigabitEthernet0/0, frequency 10, and ip sla schedule 1 life forever start-time now. Results are read with show ip sla statistics.
• The operation type determines what question you can answer: icmp-echo for reachability and round-trip delay; udp-jitter for jitter and one-way delay (used to evaluate VoIP quality, requiring ip sla responder on the far end); http and dns for application-layer response time; tcp-connect for whether a specific port accepts connections. Choosing icmp-echo when the question is about VoIP jitter is the wrong method for the question.
• Object tracking: track 1 ip sla 1 reachability turns the measurement into an object, and binding it to a static route with ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1 means that even while the link stays physically up, the route is withdrawn the moment the far side becomes unreachable and traffic fails over to the backup. Lowering HSRP priority with standby 1 track 1 decrement 30 to move the active role is another standard use. This is the proper answer to failures that black-hole traffic while the link stays up.

A branch reports that VoIP quality degrades only between 10:00 and 11:00 on weekdays, and the branch router is separated from the head-office analyzer by a routed (L3) WAN. The key is to separate three questions. First, you must objectify "is quality really degrading, and by how much," and the proper approach is to run an IP SLA udp-jitter operation continuously on the branch router (with ip sla responder on the far end) and take a time series of jitter and one-way delay via show ip sla statistics; icmp-echo yields only round-trip delay and is insufficient for jitter. Second, you need to know "who is consuming bandwidth during that window," which is the job of Flexible NetFlow: build a flow record keyed on match ipv4 source address, match ipv4 destination address, and match transport destination-port, a flow exporter aimed at the collector, and a flow monitor binding them, then apply it to the WAN interface with ip flow monitor MON input (forgetting this application leaves show flow monitor MON cache empty, the classic reason people conclude "NetFlow is not working"). Third, there remains the per-packet fact of "is the DSCP on voice packets being rewritten in transit," which an aggregate like NetFlow cannot answer--you need a method that copies packets. Choosing RSPAN here is wrong, because RSPAN presumes L2 reachability of the RSPAN VLAN and cannot cross the WAN. ERSPAN encapsulates the mirror in GRE, crosses L3, and delivers it to the head-office analyzer (given matching erspan-id values and enough path MTU for the GRE header). And if the cause turns out to be "a 10 a.m. backup transfer saturating the WAN while QoS is unconfigured, so voice is dropped," the permanent fix is correcting QoS--though as an interim measure, binding track to ip sla to shift to a secondary circuit on degradation is also an option. Choosing the method per question is the essence of measurement design.

4.2.4Section summary

• Flexible NetFlow has three parts--a flow record (match = keys, collect = accumulated values), a flow exporter (destination), and a flow monitor (binding them and holding the cache)--and measurement starts only on application to an interface. It answers aggregates, not payloads
• To see packets themselves, choose by distance: SPAN (same device), RSPAN (via an RSPAN VLAN within L2 reach), or ERSPAN (across L3 with GRE). A SPAN destination port cannot double as a normal switch port
• IP SLA actively measures reachability, latency, and jitter with synthetic traffic (jitter needs udp-jitter plus a responder), and binding track to a static route or HSRP fails over automatically even when the link stays up but traffic is black-holed