Using Windows to verify DSCP

In today’s converged networks Voice over IP (or VoIP) is a way to provide voice services over packet switched networks, replacing traditional circuit switched networks. While voice communications (as in audio) is a real-time application IP networks have inherent latency and operate in a “best efforts” model. As a result, configuring end-to-end Quality of Service (or QoS) is not only essential but even when done 100% correctly you can still have poor results.

Whether installing a new VoIP system or changing manufactures you should ALWAYS test the network(s) where voice traffic will traverse prior to deployment. Troubleshooting QoS related issues is a complicated task and REQUIRES a solid understanding of many variables. Most commonly you’ll read about latency, jitter, packet loss and their acceptable thresholds. While true there are many other variables to consider so this is just a starting point for testing QoS.

Today, DSCP or Differentiated Services Code Point is a popular model used to classify and prioritize traffic in the network.  Typically the application (in this case an IP phone or voice switch) will mark the DSCP value in the IP header while QoS on the routers/switches will give preferential treatment to packets based on the DSCP value(s) when congestion occurs.  Please be aware there are many ways to implement QoS such as using ToS, IP Precedence, and CoS values and/or incorporating techniques such as ACLs and VLANs to classify traffic.

The industry standard is to use a DSCP value of 46 (aka Expedited Forwarding or EF) to mark/classify real-time applications such as voice.  This test will verify the DSCP value is being preserved between endpoints.  IF the DSCP value is being stripped (typically set to 0) or re-marked to a different value then the traffic will not be classified properly.  This is a simple but effective method of verifying DSCP integrity using readably available software.  For this test you’ll need an OS and NIC that support marking DSCP/ToS bits on the local and remote ends, use of a protocol analyzer, and the trusty ping command. I’ll be using Microsoft Windows XP for the OS and Wireshark as the protocol analyzer.  For XP you’ll need to make a registry change to allow this marking but is easy to do .You can visit http://support.microsoft.com/kb/248611 for more information on this.

To start open the command prompt and type “ping /?”

In the output you will notice an option “-v <value>” to mark a ping packet’s ToS (Type of Service) byte.  While this is not the aforementioned DSCP value, the ToS byte (or 8-bits) encompasses DSCP as DSCP only uses the FIRST 6-bits of the ToS byte and ignores bits 7 and 8.  Thankfully with some simple binary math you can translate a ToS value into a DSCP value and via versa.  For this example, we’ll be using a ToS value of 184 (10111000 in binary), which translates into a DSCP value of 46 (101110 in binary).

To generate ping traffic with DSCP of 46 set the ping -v option to 184 as show below.  I also like to use the “-t” option which runs the ping command continuously.  REMEMBER whatever you ping it too must support marking its ToS/DSCP bits.

ping –v 184 <ip-address> -t

Example in the Windows XP command prompt

Now open Wireshark and select the network interface that is generating the ping traffic.

For this test I prefer to filter/limit Wireshark output to ICMP traffic (ping is a type of ICMP traffic) so I only see the traffic I’m interesting in. Also, in Wireshark I recommend creating a column displaying DSCP values. As you can see below the ping packets are both leaving and returning with a DSCP of 46.

If you don’t setup a column for DSCP values then you will need to examine the IP header in each packet to verify the DSCP value. As you can see below the bits in the DSCP field is 101110 which translates into 46… or 2e if your into reading hex.

If you receive the same output in Wireshark as above, then you have just SUCCESSFULLY verified DSCP is being preserved between endpoints. It is HIGHLY recommended to test all paths in which VoIP will traverse the network. Also, it’s a best practice to separate voice and data traffic onto separate VLANs and IP Networks. As such, the endpoints for this test reside on the voice network. Whether you segment voice and data or not the main point is to test the network where voice traffic will travel.

Below is an example where DSCP is being stripped, leaving as a 46 and returning with a value of 0. There could be many reasons for this such as the carrier stripping the value or misconfiguration on a routers/switch. Keep in mind that DSCP stripping might only be occurring in ONE direction or BOTH directions over a particular link.

In the example above, there’s a good chance the remote endpoint (10.0.0.96) is not seeing a DSCP value of 46. This means somewhere between your computer and remote end the DSCP is being stripped. If this is the case, I recommend stopping the test and trying it in the opposite direction to see if you get the same results. Once establishing which direction(s) the stripping occurs move the endpoints closer and closer together over the IP network and retest along the way until you determine where the DSCP value is being stripped and in which direction.

While this test does not perform any type of QoS testing per say, it DOES verify DSCP integrity and should be performed BEFORE using any QoS test tool. Remember if DSCP is being stripped or remarked to an unexpected value then QoS will effectively be meaningless and voice traffic will most likely get “best effort” treatment.

Below are some examples of real voice traffic, captured via port mirroring or SPAN in the Cisco world.

Example of audio traffic’s DSCP being stripped both ways (using G.711u codec)

Example of audio traffic’s DSCP being preserved both ways (using G.711u codec)