Most network engineers are familiar with how to configure a SPAN port on a switch. This is a common way to get access to the network data to perform network analysis and connect various packet capturing monitoring tools to it.
When considering packet capture and monitoring of voice-over-IP (VoIP) traffic, it is important to keep in mind that VoIP is highly susceptible to packet loss, latency and jitter and is a frequent area of network troubleshooting.
So let me ask you. Besides configuring a SPAN port, do you know the importance of the mirrored data quality in packet analysis?
Packet Analysis is Only as Good as the Traffic Source
If you are only relying on the data coming from the switch – it is critical to understand that any change on the Ethernet packets during the regular switch operation will impact the integrity of the mirrored data. That’s why when I work with clients using an Ethernet Switch to perform mirroring everyone must understand how an Ethernet switch works and performs mirroring.
Differentiated Services (DiffServ) or Differentiated Services Code Point (DSCP) is a common feature in order to implement quality of service (QoS) for certain network applications such as VoIP and many others.
Cisco describes in regards to DSCP in conjunction with a SPAN port the following;
“Packets that are modified because of routing or quality of service (QoS)—for example, modified Differentiated Services Code Point (DSCP)—are copied before modification.”
Example of Local SPAN Configuration on a Single Device.
Additionally, Cisco describes documented reasons for dropped packets when using SPAN ports:
Switch congestion can cause packets to be dropped at ingress source ports, egress source ports, or SPAN destination ports. In general, these characteristics are independent of one another. For example:
- A packet might be forwarded normally but dropped from monitoring due to an oversubscribed SPAN destination port.
- An ingress packet might be dropped from normal forwarding, but still appear on the SPAN destination port.
- An egress packet dropped because ofswitch congestion is also dropped from egress SPAN.
When troubleshooting an egress port on a switch, it can occur that due to the nature of SPAN and switch operation mode that you will not see the real DSCP value going out on the egress port.
Seeing the real DSCP value is critical; otherwise you could be led to incorrect analysis!
To ensure that DSCP has been configured properly on your switch you must see the modified DSCP value of the egress interface. Otherwise you would only see the DSCP value of the source port and usually SPAN sessions would give you the copy of the packets before modification.
We have experienced serious problems because of this and - keep in mind that different switch vendors behave differently in the way they copy the traffic.
Let’s revisit my original statement, “do you understand the SPAN technology and the quality of mirrored data in packet analysis?”
Because close and careful attention is required when using a SPAN port with DSCP configured.
Achieving 100% Network Packet Capture
When using network TAPs, you would see the real packet including the original DSCP value transmitted over the wire – no doubt! Learn more about the differences of using network TAPs vs a SPAN/mirror port.
Still looking for more comparison? Please check out our TAP vs SPAN Infographic.