2960 and QoS Problem

[richmnn]

I have a 2960 that I'm having some QoS issues with.  An example of my config is listed below.

Extended IP access list IP_Audio

    10 permit udp any any range 50000 50019

    20 permit tcp any any range 50000 50019

Extended IP access list IP_Video

    10 permit udp any any range 57501 57519

    20 permit tcp any any range 57501 57519

Class Map match-any class-default (id 0)

   Match any

Class Map match-all Client-Video (id 1)

   Match access-group name IP_Video

Class Map match-all Client-Audio (id 2)

   Match access-group name IP_Audio

  Policy Map Client_Policy

    Class Client-Audio

      set dscp ef

    Class Client-Video

      set dscp af41

    Class class-default

      set ip dscp default

I have the service policy applied to ports fa0/1 along with the following configuration and the gig uplink port trusting dscp and it's configuration:

interface FastEthernet0/1

switchport access vlan 40

switchport mode access

switchport voice vlan 91

switchport port-security maximum 2

switchport port-security

switchport port-security aging time 3

switchport port-security aging type inactivity

priority-queue out

no cdp enable

spanning-tree portfast

spanning-tree bpduguard enable

service-policy input Client_Policy

ip dhcp snooping limit rate 50

end

interface GigabitEthernet0/2

switchport trunk native vlan 999

switchport trunk allowed vlan 40,91,450

switchport mode trunk

switchport nonegotiate

ip arp inspection trust

priority-queue out

mls qos trust dscp

ip dhcp snooping trust

end

I have used WireShark to monitor fa0/1 and I see DSCP marking off the phone coming into the switch port  I then used WireShark to monitor the gig uplink port gig0/2.  At that point the UDP voice packets (that are in the specified port range of the access list) from the source IP address of the phone/softphone appears to have dropped the DSCP marking.  Packets coming in from the 4507 that the 2960 is connected to are still marked correctly though.  I'm at a loss as to what I'm missing to get this DSCP marking to work correctly.  I'd prefer not to set all the ports on the switch to trust dscp on the edge ports but so far that is the only thing that has been successful in testing.  Any help is appreciated.

[paul driver]

Hello

By default voice media traffic is marked with a cos 5 and dscp EF = 46

On cisco switches the cos to dscp marking defaults to for cos 5 = 40

sh mls qos maps cos-dscp
   Cos-dscp map:
        cos:   0  1  2  3  4 5  6  7
     --------------------------------
       dscp:   0  8 16 24 32 40 48 56

Can you try changing this default?

conf t
mls qos map cos-dscp  0  8 16 24 32 46 48 56

SW1#sh mls qos maps cos-dscp
   Cos-dscp map:
        cos:   0  1  2  3  4  5 6  7
     --------------------------------
       dscp:   0  8 16 24 32 46 48 56

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[richmnn]

I went ahead and changed the COS-DSCP mapping on the switch so that COS 5 maps to 46 as you suggested.  After doing some more testing, this unfortunately did nothing to solve the problem I'm seeing on the switch.  I should have stated before, that the phones & softphones are set up to mark voice traffic with a value of 46 and not a COS value of 5.  Thanks for the quick response and let me know if you have any other suggestions.

[paul driver]

Hello

Okay so you are saying the dscp values comes into the fa0/1 and before it goes out of gig0/1 they are dropped?

int fa0/1

mls qos trust dscp

sh mls qos

sh mls qos inter fa0/1

sh mls qos inter gig0/1

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[richmnn]

Yeah, that's what it is looking like to me.  If I monitor fa0/1 I will see the DSCP value set for both incoming and outgoing packets.  If I then monitor gig0/2 I will see the DSCP value set to EF for packets destined for the phone/softphone.  However the packets headed out of the switch to the server have the DSCP marking of 0.

Output of sh mls qos, sh mls qos int fa0/1, and sh mls qos gig0/1

#sh mls qos
QoS is enabled
QoS ip packet dscp rewrite is enabled

#sh mls qos int fa0/1

FastEthernet0/1

Attached policy-map for Ingress: Lync_Client_Policy

trust state: not trusted

trust mode: not trusted

trust enabled flag: ena

COS override: dis

default COS: 0

DSCP Mutation Map: Default DSCP Mutation Map

Trust device: none

qos mode: port-based

sh mls qos int gig0/2

GigabitEthernet0/2

trust state: trust dscp

trust mode: trust dscp

trust enabled flag: ena

COS override: dis

default COS: 0

DSCP Mutation Map: Default DSCP Mutation Map

Trust device: none

qos mode: port-based

I would prefer not to just trust the DSCP values coming off the edge devices if possible.  I would prefer that the service policy sets the DSCP value for the UDP packets in those port ranges if at all possible.

[paul driver]

Hello

When the traffic heads outs of the switch its subject to whatever device it traverses and if that is another cisco switch then by default the switch will rewrite the dscp value to zero if qos is enabled also.

QoS is enabled

QoS ip packet dscp rewrite is enabled

Sh policy-map int fa0/1 & gig0/1

What is connected to gig0/1?

Can you provide a simple toplogy?

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[richmnn]

It's your basic hub and spoke design. Clients and phones connect to the 24 Ethernet ports. Int gig0/2 is up linked to 4507 that is the main core switch for the building and the IP telephony server is plugged into the 4507. The service policy is applied to the 24 ports used for client access that was shown in the previous example configuration. The gig port 0/2 trusts dscp values with the mls qos trust dscp command.

When I monitor the port fa0/1 that the client phone is connected to, I see the correct dscp value. The phone is set to use the dscp value of 46. When I monitor the uplink port gig0/2 the dscp value is dropped on packets leaving the 2960. This is before it even hits the 4507 that it is connected to. During testing I tried trusting dscp values on fa0/1 using mls qos trust dscp. When that was set on port fa0/1, the dscp value would then be passed onto the gig0/2 uplink port for traffic destined for the 4507. It appears that the service policy is not setting the dscp value I have assigned like it should be. The phone is using the correct udp port ranges I have specified in the access list. I could just set the port fa0/1 to trust any dscp value coming off the clients, but it is not really and optimal solution in our environment.

Sent from Cisco Technical Support iPad App

[paul driver]

Hello Again

Okay given that it works when you trust the interface try and trust the policy-map instead.

Policy Map Client_Policy

    Class Client-Audio

     trust dscp

      set dscp ef

    Class Client-Video

      trust dscp

      set dscp af41

     Class class-default

      trust dscp

      set ip dscp default

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[richmnn]

I see the same result when trusting dscp in the policy-map as I do when assigning dscp in the policy map.  When monitoring the fa0/1 port that the phone is connected to I see the DSCP EF value.  When I monitor gig0/2 uplink port the dscp value is set again to 0. 

[richmnn]

I figured out my problem.  The problem was with my access list.  The access list in my configuration were the following:

Extended IP access list IP_Audio

    10 permit udp any any range 50000 50019

    20 permit tcp any any range 50000 50019

Extended IP access list IP_Video

    10 permit udp any any range 57501 57519

    20 permit tcp any any range 57501 57519

However, I'm looking for the source port ranges for TCP and UDP packets.  I changed the access list to the following and it cleared up my problem.

Extended IP access list IP_Audio

    10 permit udp any range 50000 50019 any

    20 permit tcp any range 50000 50019 any

Extended IP access list IP_Video

    10 permit udp any range 57501 57519 any

    20 permit tcp any range 57501 57519 any

Thanks for your help with this problem.