I am trying to set QoS values on an MX200 endpoint to AF41 (decimal 34) for audio/video packets. I entered the values in the GUI and it saved OK. A sniffer trace shows the packets still marked as Best Effort DSCP=0. I tried a system restart from the maintenance tab but no help. Command line seems to show the correct values:
*c xConfiguration Network 1 QoS Mode: Diffserv
*c xConfiguration Network 1 QoS Diffserv Audio: 34
*c xConfiguration Network 1 QoS Diffserv Data: 22
*c xConfiguration Network 1 QoS Diffserv Signalling: 26
*c xConfiguration Network 1 QoS Diffserv Video: 34
Anybody run into this issue?
Solved! Go to Solution.
Good point Garvan... the sniffer is at the HQ site and the MX200 is behind a remote WAN router that is not supposed to be marking the traffic.
I verified the sniffer trace with a tcpdump behind the remote router (remote LAN side) with the same results.
I also set the QoS markings to AF41 on a Polycom VSX7000e that is the other half of the video test calls. The packets sourced from the Polycom are marked correctly in the trace but the MX200 are not.
I opened a TAC case and sent them xconfig, xstatus and the sniffer trace but no help so far.
I was not able to replicate the issue with my mx200 on TC5.1. One thing you can do is a tcpdump from root to check the TOS value being sent out. The steps are as follows:
This tcpdump command will capture 1 UDP packet, which should hopefully be a video packet, and print out the TOS value as seen below:
[tandberg:~] $ tcpdump -i eth0 -c 1 -v udp and src xx.xx.xx.xx
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:37:59.010587 IP (tos 0x88, ttl 64, id 43727, offset 0, flags [none], proto UDP (17), length 214)
xx.xx.xx.xx.2326 > xx.xx.xx.xx.16464: UDP, length 186
1 packets captured
40 packets received by filter
2 packets dropped by kernel
You can use this table to conver the hex value to DSCP: http://blog.webdir.bg/tos-to-dscp-mapping/ in this case the hex value of 0x88 converts to DSCP 34.
Try running the command a few times to ensure that the data is correct, you can also adjust the number of packets captured by adjusting the number after the -c flag.
If you find that the MX200 is properly marking the packets on egress then you'll need to start looking at the network path to ensure that DSCP is trusted. Have you verified that the switchport is trusting DSCP?
BIngo. The remote is a VoIP site with auto-QoS enabled on the 3750 switch where the MX200 connects.
I added the trust DSCP to the port config and traffic gets back to HQ marked properly.
I was capturing between the switch and router.
Thanks to all who responded.