cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2112
Views
5
Helpful
5
Replies

MX200 QoS settings not marking packets

tomphoenix
Level 1
Level 1

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

Software version:TC5.1.0.280662

Anybody run into this issue?

TJP

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

5 Replies 5

Garvan Long
Level 1
Level 1

Where are you taking the sniffer trace from ? could it be remarked in the path to your sniffer

tomphoenix
Level 1
Level 1

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.

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:

  1. Enable root mode on the codec by logging into the admin cli via ssh and entering the command systemtools rootsettings on
  2. Log into the root shell using the password you just created.
  3. While a call is active enter the command tcpdump -i eth0  -c 1 -v udp and src xx.xx.xx.xx (replace the x's with the source IP of the mx200)

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

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.

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