QOS on 6509 Etherchannel

Lee Marson · ‎04-30-2010

Hi All,

I am wondering if anyone else has come across this issue and may have some insight as to why it is happening?

I have a QOS policy set up beween a core site and a remote site over a 1GB MPLS link which prioritises Citrix traffic from a cluster of servers.
We have classifed the traffic captured in an access list and set the dscp value to 34 at each end of the link.

At the remote site the QOS policy is configured on 3560s as Vlan based and works fine and when I take a trace using wireshark I can see the packets from the filtered addresses being marked as DSCP 34.

However at the core the traffic is being captured on a 6509 etherchanneled link to another access layer switch.

Ip access-list extended citrix-acl

Permit ip any host 192.168.XX.X1

Permit ip host 192.168.XX.X1 any

Permit ip any host 192.168.XX.X2

Permit ip host 192.168.109.X2 any

Permit ip any host 192.168.XX.X3

Permit ip host 192.168.XX.X3 any

Class-map match-any citrix-class

Match access-group name citrix-acl

policy-map citrix-policy

class citrix-class

set dscp af41

class class-default

set dscp default

I have applied the service policy inbound on the portchannel interface?

     interface Port-channel12
      switchport
      switchport trunk encapsulation dot1q
      switchport trunk allowed vlan 109,111,112
      switchport trunk pruning vlan 109,111,112
      switchport mode trunk
      no ip address
      mls qos trust dscp
      service-policy input citrix-policy
    end

When I issue the show policy-map int poxx input command I can see the traffic being matched and incrementing as expected.

#sho policy-map int po12 input
Port-channel12

Service-policy input: citrix-policy

    class-map: citrix-class (match-any)
      Match: access-group name citrix-acl
      set dscp 34:
      Earl in slot 5 :
        85572580 bytes
        5 minute offered rate 36416 bps
        aggregate-forwarded 85572580 bytes

    class-map: class-default (match-any)
      Match: any
      set dscp 0:
      Earl in slot 5 :
        171121773666 bytes
        5 minute offered rate 9786432 bps
        aggregate-forwarded 171121773666 bytes

#sho policy-map int po12 input
Port-channel12

Service-policy input: citrix-policy

    class-map: citrix-class (match-any)
      Match: access-group name citrix-acl
      set dscp 34:
      Earl in slot 5 :
        85572644 bytes
        5 minute offered rate 35176 bps
        aggregate-forwarded 85572644 bytes

    class-map: class-default (match-any)
      Match: any
      set dscp 0:
      Earl in slot 5 :
        171127950546 bytes
        5 minute offered rate 9623080 bps
        aggregate-forwarded 171127950546 bytes

However when I capture SPAN traffic at the portchannel the traffic from the ACL list is marked as the default dscp value of 0.

Has anyone come across a similar issue or have any ideas please?

The version of code on the 6509 is 12.2(18)SXF7.

The QOS is working fine for the rest of the network and end-to-end from the remote site the markings are reaching the core intact.

The only way I can see around this is to mark the traffic closer to the ingress i.e at the access switches however I was hoping to avoid having to do this as it takes more config.

Thanks

Many thanks

Edison Ortiz · ‎04-30-2010

The SPAN process is taking place before the QOS marking and that's why you are seeing DSCP 0 on the incoming flow.

I recommend SPAN the port downstream the etherchannel (closer to the destination) and see if the markings were applied at the Port-Channel.

Regards

Edison

Lee Marson · ‎05-04-2010

Hi Edison,

Thanks for the reply. You are right I did think of this however, I have taken traces at the WAN link which is on the same switch but has still have the same issue.

WAN LINK CONFIG

interface GigabitEthernet6/8

bandwidth 1000000
ip address 192.168.XX.XX 255.255.255.252
wrr-queue bandwidth 20 100 200
priority-queue queue-limit 5
wrr-queue queue-limit 65 15 15
wrr-queue random-detect min-threshold 1 70 100 100 100 100 100 100 100
wrr-queue random-detect min-threshold 2 70 100 100 100 100 100 100 100
wrr-queue random-detect min-threshold 3 40 40 50 50 60 60 70 70
wrr-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100
wrr-queue random-detect max-threshold 2 100 100 100 100 100 100 100 100
wrr-queue random-detect max-threshold 3 70 70 80 80 90 90 100 100
wrr-queue cos-map 2 1 1 2
wrr-queue cos-map 3 5 3 4
wrr-queue cos-map 3 7 6 7
rcv-queue cos-map 1 2 1
rcv-queue cos-map 1 3 2
rcv-queue cos-map 1 4 3
rcv-queue cos-map 1 5 4
rcv-queue cos-map 1 6 5
rcv-queue cos-map 1 7 6
rcv-queue cos-map 1 8 7
mls qos trust dscp
storm-control broadcast level 10.00
storm-control multicast level 10.00
service-policy output image-policy - This is a different policy which should not affect the citrix traffic

Traffic from the server ACL filter is marked as DSCP 0 however traffic coming back to the servers in the other direction is marked correctly.

Is there anywhere else it could be being remarked? E.g at the vlan interface?

Thanks

Edison Ortiz · ‎05-04-2010

Can you check one hop away? Perhaps the switch is marking the packet while it's leaving the switch.

Also, do not trust the 'show policy-map interface' commands in the switch. That command is mostly useful in routers where QoS is done in software.

QoS in switches is done in hardware and software counters will provide false positive information.

Regards

Edison

Lee Marson · ‎05-04-2010

Thanks,

I have taken traces at the other end of the WAN link and the output is the same i.e no markings on the citrix traffic from the 6509.

Edison Ortiz · ‎05-04-2010

Then I recommend applying the markings closer to the source.

With 6500s, I recommend going with Vlan based QoS. It seems the trunk is not matching on the IP so the packet is going to the class class-default on which you are setting the dscp to default which is 0.

Regards

Edison