If I am doing this sniffer capture on my pc, when my phone is the source it shows "EF", but when the other end phone is the source sending to me in the same sniffer capture, it shows default. Does that mean that the packet was reclassified somewhere in the network, or is that something within the wireshark program? Does that make sense?

I don't know Wireshark, but that definitely sounds like the packets are getting remarked. Does you MPLS provider allow DSCP markings? Alot of them clear them on the inbound interface of their equipment.

With the rtp media I would ordinarily expect that when your IP Phone is the source address the packets should be marked EF, and the same is applicable when the remote office IP Phone is the source and your IP Phone is the destination.

Packets are certainly being remarked in that case.

Firstly is the MPLS QoS enabled? If it is, the carrier should be able check the service-policy inbound from the remote CE to ascertain whether there are matches within the priority or the LLQ. If there are none, then this suggest a marking issue within the remote office LAN.

Also how are you classifying traffic at the remote office? Are your trusting your IP Phones? Or is the gateway classifying and remarking DSCP accordingly?

HTH

Allan.

1.I need to verify that Verizon has qos enabled for the MPLS circuit

2.I believe my QOS on my lan is correct, so what I would like to do, if what you say is correct, I would like to capture 2 sniffer traces at each of the cores and see how I am sending and receiving DSCP values to MPLS, because right now as it stands when I receive from the remote site, the dscp value is "default" not "EF".

Allan,

So you have captured over mpls and both directions should come out as dscp ef if you are sending it into mpls as ef?

I would certainly expect any carrier to be using IETF defined PHB values, there are essentially four AF (Assured Forwarding)classes and EF (Expedited Forwarding) each with three drop precendences low, medium and high excluding EF.

Therefore depending how the carrier is matching/classifing traffic marked as EF?, it should be treated with strict priority.

However, I would normally expect that the carrier would only provision bandwidth for EF according to your voice requirements for the remote office when QoS was ordered.

This would also be the case for voice signalling and any other traffic classes that are mapped to AF values?

HTH

Allan.

Allan first of all thank you very much for all of your help!

I believe I have figured out most of my qos issues and have fixed them. But I am wondering if someone can comment on another issue.

My Call Manager is plugged into a 6509, when I am watching CM setup (sniffer trace) a call, I noticed that when CM is the source it is not marking the signaling traffic with cs3 or af31. I am running this capture directly on the 6509 so I know there is no chance of a remark. The core is directly connected with our MPLS router. Here is the port the CM is plug into and our mpls router.

6509 CM port

interface GigabitEthernet1/16

description US-Call-1_Eth1

no ip address

mls qos trust cos

switchport

switchport access vlan 720

switchport mode access

spanning-tree portfast

6509 port to MPLS router

interface GigabitEthernet1/1

description Connection to ENG-3845-01 Gi0/0

no ip address

mls qos trust cos

switchport

switchport access vlan 3

The DSCP used by the CallManager in out-going control message packets is configrued in the Service Parameters under the Cluster-Wide QoS section (at least in CCM 4.3, I don't know about CUCM 5.x or 6.x). Check that.

Are you sure the setting is "out-going control message"? Is there something on the 6509 I need to setup?

No problem at all, glad to help.

Configure the ports to trust DSCP and not COS on the CallManager and gateway switchports. You do not need to change any service parameters.

HTH

Allan

Pls rate helpful posts.