<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=2975524&amp;fmt=gif">
BLOG

Network Monitoring with Differentiated Services (DiffServ or SDCP)

November 17, 2016

Blog-375x225-SPAN.png

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.”

Local SPAN port configuration

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.

TAP vs 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.

See Everything. Secure Everything.

Contact us now to secure and optimized your network operations

Heartbeats Packets Inside the Bypass TAP

If the inline security tool goes off-line, the TAP will bypass the tool and automatically keep the link flowing. The Bypass TAP does this by sending heartbeat packets to the inline security tool. As long as the inline security tool is on-line, the heartbeat packets will be returned to the TAP, and the link traffic will continue to flow through the inline security tool.

If the heartbeat packets are not returned to the TAP (indicating that the inline security tool has gone off-line), the TAP will automatically 'bypass' the inline security tool and keep the link traffic flowing. The TAP also removes the heartbeat packets before sending the network traffic back onto the critical link.

While the TAP is in bypass mode, it continues to send heartbeat packets out to the inline security tool so that once the tool is back on-line, it will begin returning the heartbeat packets back to the TAP indicating that the tool is ready to go back to work. The TAP will then direct the network traffic back through the inline security tool along with the heartbeat packets placing the tool back inline.

Some of you may have noticed a flaw in the logic behind this solution!  You say, “What if the TAP should fail because it is also in-line? Then the link will also fail!” The TAP would now be considered a point of failure. That is a good catch – but in our blog on Bypass vs. Failsafe, I explained that if a TAP were to fail or lose power, it must provide failsafe protection to the link it is attached to. So our network TAP will go into Failsafe mode keeping the link flowing.

Glossary

  1. Single point of failure: a risk to an IT network if one part of the system brings down a larger part of the entire system.

  2. Heartbeat packet: a soft detection technology that monitors the health of inline appliances. Read the heartbeat packet blog here.

  3. Critical link: the connection between two or more network devices or appliances that if the connection fails then the network is disrupted.

NETWORK MANAGEMENT | THE 101 SERIES