QOS tagging, how to verify?

victoriabardy · ‎08-04-2009

We are moving to a different ISP for our MPLS service and we want to double check that the QOS tags are being preserved as the signaling traffic traverses the new MPLS network. Is there a way we can check this just doing a debug on a live call? We discussed setting up wire shark or ethereal to verify but that will be more involved and we are already going to be really busy during the cut.

Any suggestions would be great!

Thank you.

Rgds,

Vicky

Wilson Samuel · ‎08-04-2009

Hi Vicky,

I'm not sure if we can really verify how the Carrier treats once the packet leaves the CE router. Ofcourse we can tag the router at the CE for the MPLS, however once its in the cloud, I guess we have to trust the provider for preserving the QoS values as well as treating them accordingly (Queueing / Congestion Avoidance et al)

Regards

Wilson Samuel

CHRIS CHARLEBOIS · ‎08-04-2009

Is the question about whether the ISP will keep the QoS tagging, or that the ISP respects the QoS tagging and provides the packet handling to support your voice application?

If it's the former, I assume that you are relying on the incoming DSCP settings to mark the incoming WAN packets when placed on the LAN. If that's the case, simply seeing the packets marked correctly on the LAN (using Wireshark) will tell you that. But that doesn't mean the ISP is respecting the QoS setting.

If you want to know that, you need to saturate the link with traffic, then try to make a call and see what the connection sounds like.

Nicholas Matthews · ‎08-04-2009

Hi Vicky,

There are a few ways to test this:

1) Packet captures. Timeless way of capturing it. With the new feature, IP Traffic Export Capture Mode, you can do this right on the router without the need for a PC or SPAN session. I'm attaching a little document on instructions, and you can CCO search for more details. Be aware this is only available on 12.4(20)T and later.

2) Access list debugging:

access 155 permit udp any any range 16384 32767 dscp ef

interface serial 0/0

no ip route-cache

no logging console

no logging monitor

logging buffer 2000000 7

then 'debug ip packet 155', and it will show you will see lots of ip traffic debugs if your DSCP marking is keeping dscp EF throughout the wan.

3) Enable IP accouting:

interface serial0/0

ip accounting precedence input

Then you can check 'show interface precendence' to see how many packets. This only shows precedence, but it still gives you a good idea.

hth,

nick

victoriabardy · ‎08-04-2009

Hi Nick,

This is really helpful!! Our gateway router is running 12.4(15)T so number 1 is out. However number 2 looks like it could work for us. Can you tell me if we can do this particular debug during production hours or will the debug tie it up? Also, you mention an attachment, but there was none. Can you try sending the attachment again?

Thank you again for your input here!

Rgds,

Vicky

Nicholas Matthews · ‎08-04-2009

Hi Vicky,

Attaching the file.

For the second option - it's the most thorough but it requires for the packets to be process switched. You would want to turn on the 'ip route-cache' for a limited time to test them with process switching. The debugs should be fine provided you turn off logging to the console and monitor.

-nick