05-16-2012 11:54 AM - edited 03-17-2019 11:11 PM
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?
TJP
Solved! Go to Solution.
05-17-2012 08:26 AM
Paul Anholt wrote:
Have you verified that the switchport is trusting DSCP?
That's where I'd look first; a switch that has QoS activated, but is not configured to Trust DSCP from the codec port, will remark all packets as DSCP 0.
05-16-2012 09:49 PM
Where are you taking the sniffer trace from ? could it be remarked in the path to your sniffer
05-17-2012 04:20 AM
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.
05-17-2012 07:48 AM
Hi Tom,
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?
Thanks,
Paul
05-17-2012 08:26 AM
Paul Anholt wrote:
Have you verified that the switchport is trusting DSCP?
That's where I'd look first; a switch that has QoS activated, but is not configured to Trust DSCP from the codec port, will remark all packets as DSCP 0.
05-18-2012 05:11 AM
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.
TJP
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide