Layer 3 QoS on 6500

Unanswered Question
Jun 22nd, 2007
User Badges:
  • Bronze, 100 points or more

We have a small campus network, 3560/3570s used at the access level, 6500s w/ SUP720s at the core level. I've used a configuration as follows:


Access switches:


mls qos map cos-dscp 0 8 16 24 32 46 48 54

mls qos

!

interface range fa0/1-48

description End user port

autoqos voip cisco-phone

!

interface range gig0/1-4

description Uplink to Core 6500

mls qos trust cos

!


Core Switches:


mls qos map cos-dscp 0 8 16 24 32 46 48 54

mls qos

!

no mls flow ip

no mls flow ipv6

!

interface GigabitEthernet1/10

description Uplink to Access Switch

mls qos trust cos

!

interface PortChannel1

description Uplink to CoreB

mls qos trust cos

!


If I place a call between two phones on the same VLAN, I can verify the both DSCP and CoS values are being passed accordingly by using the "show mls qos interface <int> statistics" command. This works even when the phones are on two different access switches. So QoS at the Layer 2 happening just fine.


However, when I look at a call between two VLANs, I don't see the CoS or DSCP values making it from destination port. I'm concluding the Core 6500 is resetting these values to 0 when it does the Layer 3 translation.


To debug, I tried a simple MQC config:


class-map match-any VoIP

match ip dscp ef

match ip precedence 5

!

policy-map QoS-Test

class VoIP

trust dscp

!

interface Vlan110

description Layer 3 Interface for Phones in Building 1

service-policy input QoS-Test

!


#show policy-map interface Vlan110


Service-policy input: QoS-Test

class-map: VoIP (match-any)

Match: ip dscp ef

Match: ip precedence 5

trust dscp

Earl in slot 5 :

0 bytes

5 minute offered rate 0 bps

aggregate-forwarded 0 bytes

Class-map: class-default (match-any)

40 packets, 3860 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any


So it looks almost like the DSCP values are never hitting the 6500. Couple questions:


1) Should I be trusting just DSCP rather that CoS in this case?


2) Could "no mls flow" be interfering with QoS?


3) Are the empty stats in "show policy-map interface" simply because the interface isn't heavily loaded?


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
chrihussey Mon, 06/25/2007 - 10:04
User Badges:
  • Silver, 250 points or more

Are you running HSRP across the core switches for the VLANs?


How does the routing between the VLANs take place?


Is the port channel between the core switches configured as a trunk, if so what is the native VLAN and are you routing across this VLAN?



johnnylingo Tue, 06/26/2007 - 11:33
User Badges:
  • Bronze, 100 points or more

We do run HSRP, and routing between the VLANs takes place on the Core switches via SVIs. OSPF is the IGRP used. The port channel interfaces are 802.1Q trunks.


In any case, I found out my problems. On the trunk interfaces, I should have used "mls qos trust dscp" instead of "mls qos trust cos" to make sure QoS was working at the layer 3 level. I corrected this, and also found out one of the server distribution switches was missing "mls qos" from its global config. Once corrected, End to End QoS works perfectly.


I still get empty stats when doing the test Policy-Map on the SVI interface, but get plenty of numbers when applied to the physical interface. I vaguely remember reading that this is normal, but am not 100% sure on this.

Actions

This Discussion