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.
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)
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.
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:
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.
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?
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.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...