Ask the Expert: QoS on Catalyst Switches. - Page 5

ciscomoderator · ‎05-18-2012

With Shashank Singh and

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn from Cisco experts Shashank Singh and Sweta Morga about implementation and working and troubleshooting QoS on Cisco Catalyst 2960, 3650, 3750, 4500 and 6500 switches.

Shashank Singh graduated in 2009 with a bachelor's degree in Computer Science and Engineering from VIT University, Vellore India. Prior to joining Cisco he worked at General Electric as a software engineer. Later on he joined the Cisco Technical Assistance Center as an engineer in October of 2009. He has been working on LAN Switching technologies in TAC since then. Shashank also holds a CCNP certificate. QoS on Catalyst switches is one of the areas of his interest.

Sweta Mogra is a Computer Science & Engineering graduate from VIT University, India. She has worked as a consultant with Tata Consultancy Services before joining Cisco's Technical Assistance Center (TAC) in 2011. She is currently working on LAN Switching technologies and QoS as one of her areas of expertise.

Remember to use the rating system to let Shashank and Sweta know if you have received an adequate response.

Shashank and Sweta might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Network Infastructure sub-community Lan Switching forum shortly after the event. This event lasts through June 1, 2012. Visit this forum often to view responses to your questions and the questions of other community members.

steakandeggs · ‎05-23-2012

I've got a 6509 IOS based switch, and some 3560 switches. I'd like to mark DSCP values on the access ports using the MQC. The problem I've found is that, in some cases, when I apply the "service-policy input " to the layer two access port, it appears to take but doesn't actually.

I think I narrowed the problem down to the fact that the ACLs used to classify the traffic: if the ACL has IP addresses in it the switch will not take it. Am I right? And if so, is there a way to apply an IP based ACL on either platform?

Shashank Singh · ‎05-23-2012

As far as I know ACL based MQC should be supported on a 3560. Could you please share your interface level, policy map, class-map and access list config along with the IOS image name?

Regards,

Shashank

steakandeggs · ‎05-23-2012

Sure.

Switch Ports Model SW Version SW Image

------ ----- ----- ---------- ----------

* 1 52 WS-C3560G-48PS 12.2(50)SE3 C3560-IPSERVICESK9-M

Also tried it with LAN base.

class-map match-any bulkdata
match access-group name exchange
class-map match-any interactive
match access-group name scimitar
match access-group name velocity
match access-group name synergy
match access-group name telnet
!
!
policy-map mark-access
class interactive
   set dscp af21
class bulkdata
   set dscp af11
class class-default
   set dscp default

interface GigabitEthernet0/1

description ACCESS

switchport access vlan 30

switchport mode access

spanning-tree portfast

service-policy input mark-access <---- this command doesn't stick

!

ip access-list extended exchange
permit ip any any
permit ip any host 1.2.3.4
permit ip any host 1.2.3.5
ip access-list extended scimitar
permit ip any host 1.2.3.6
permit ip any host 1.2.3.7
ip access-list extended synergy
permit ip any host 1.2.3.8
ip access-list extended telnet
permit tcp any any eq telnet
ip access-list extended velocity
permit ip any host 1.2.3.9

Shashank Singh · ‎05-23-2012

Hi,

One ACL per class map is a limitation on 3560 platform. We are matching more than one ACL in class-map interactive which is not letting us use this class-map in the service policy. Alternative is to have separate class maps for each ACL or summarize all four ACLs into one.

Hope that helps.

Regards,

Shashank

Jason Dance · ‎05-23-2012

Thanks Sweta! I'll give it a try and see how it pans out.

dahua.huang · ‎05-23-2012

Hi, Shashank

I have some QoS questions for our current qos migration from 4500 sup 2+ platform to 4500E sup 6 platform because renew our lease.

4500 act as a pure L2 Access switch and port-channel trunk to L3 6509 VSS. so all L3 done on the 6509 side.

Looks after sup 6, Cisco changed QoS structure and we need redesign our QoS tempalte.

Here is our questions:

1. we use "qos vlan-base" on current etherent interface and "service-policy input QOSMARK" on the Vlan xxx in sup2 platform.

sup 6 does not have "qos vlan-based" on etherent interface. only allow "service-policy output xxx"

If we apply "service-policy output xxx", is that means from outside traffic into server get market only? this confused me.

if we apply "service-policy output xxx" to all etherent interfaces, does it will cause tcam out of resources issue?

2. for the 1p7q1t, how can I assign the class to that Q? or each class is a Q and the class with priority CLI will be P?

what about if we have more than 8 classes?

3. we usually set "qos trust dscp" on the interface connect to another switch, call-manager and mangaged router.

sup 6 does not have that command, is that means no CLI menas sup6 turst it?

Thanks a lot.

Shashank Singh · ‎05-23-2012

Hi,

Please find the answers inline.

If we apply "service-policy output xxx", is that means from outside traffic into server get market only? this confused me.if we apply "service-policy output xxx" to all etherent interfaces, does it will cause tcam out of resources issue?

service-policy output xxx will affect traffic that is going out of that interface(egress traffic). Applying the same service policy on all interfaces should not cause your TCAM to run out of space.

for the 1p7q1t, how can I assign the class to that Q? or each class is a Q and the class with priority CLI will be P?

what about if we have more than 8 classes?

Please check the medianet design guide for sample config for queueing on sup6 for the 1p7q1t model .

http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampuscat4500aag.html

On supervisor 6E, number of queues/port are not limited. Queues are dynamically generated based on the classes configured within the policy. (for example, 8 classes equates to 8 queues if shaping or other queuing command is configured). If my interested traffic is classified under class-map voice, I can make this traffic go to a tx queue which has 10% of the bandwidth and has a buffer size of 8184 packets as below:

Policy Map QUEUEING

Class voice

bandwidth percent 10

queue-limit 8184

we usually set "qos trust dscp" on the interface connect to another switch, call-manager and mangaged router.

sup 6 does not have that command, is that means no CLI menas sup6 turst it?

By default all interfaces trust DSCP; as such, no explicit configuration is required to enable this model.

Hope that helps.

Regards,

Shashank

cisco.plus · ‎05-24-2012

Hi, Shashank

We are terminating ISP Link 10MB on a 2960 switch and need to distribute among different floor

ISP Link terminated on Fa 0/24 - 10MB

Port fa 0/1 connects to floor 1 Router - needed 2MB (in/out) max

Port fa 0/2 connects to floor 2 Router - needed 3MB (in/out ) max

Port fa 0/3 connects to floor 3 Router - needed 5MB (in/out) max

1st floor is off on Saturday/Sunday

2nd floor is off by 5pm daily

3rd floor is 24/7 working

Possible to configure QOS as above requirement and allow 3rd floor to use all the available bandwidth on Saturday/Sunday and share 2nd floor bandwidth between 1st & 3rd floor after 5pm till 6am

Hope to get some feedback

cheers

CP

Shashank Singh · ‎05-24-2012

Hi,

For rate limiting ingress traffic, we can police it to the required CIR. On 2960, policing is supported only on ingress and it cannot be used for rate limiting egress traffic.

srr-queue bandwidth limit would have been an option to rate limit egress traffic if required CIR was more than 10% of interface speed which is not the case.

For managing bandwidth alloction as per time of the day/day of week you will to club MQC and time based ACLs to come up with a time-of-day QoS policy as suggested at link below:

http://www.cisco.com/en/US/tech/tk543/tk759/technologies_tech_note09186a00801aa69d.shtml

Hope this helps.

Regards,

Shashank

cisco.plus · ‎05-24-2012

Hi Shashank

Thanks for updating. which access switch model supports ingress and egress.

Our internet provider is the same floor and we connect to them over copper media.

I terminate the UTP on 2960 and have noticed the other end at ISP is also terminated on a 2960.

Then how do they manage to restrict the internet pipe to 10MB ( upload and download )

Shashank Singh · ‎05-24-2012

Egress policing support starts only from Catalyst 4500 series switches onwards.

Though egress policing is not supported on a 2960, different packet flows can be mapped into queues. These queues can then be shaped. This will limit the amount of traffic on those flows, similar to that of egress policing. This is the only way to acheive policing in both directions if you have a single 2960 switch.

If however you have a couple of switches in the data path, you can restrict traffic in both directions using ingress policing at appropriate places. Please see below:

LAN-----XX-2960A---------2960B-YY-------ISP

LAN----->ISP traffic can be rate limited by ingress policing at XX

ISP----->LAN traffic can be rate limited by ingress policing at YY

Maybe your ISP folks do this

Regards,

Shashank

Matthew Hall · ‎05-24-2012

If the documentation in the SRND is to be believed (docs are known to be wrong), then the ingress trust model on 3750-E determines the egress queue mapping, so mls qos trust cos means that all egress mapping with take place using cos. I'm reading between the lines and making a few assumptions that I need clarified.

1. Does this mean traffic inbound from port g1/0/1 with trust cos will be classified on outbound port g2/0/1 using cos...not dscp. Is this true? Or does it mean that port g1/0/1 with trust cos also uses cos for it's egress mapping, but the above traffic from g1/0/1 to g2/0/1 will still use internally produced dscp?

2. All said refrences to 3750-E series apply to 3750-X? Is this true...it generally is.

Finally I need clarification on the application of a service policy.

3. If I have trust cos on an interface in combination with a service policy, the cos it trusted...except for classes in my service policy which trust specified DSCPs (match) for profiled traffic and override the trust COS. In such cases how does the above point apply? Do the service policy packets ingressing on the port use DSCP to determine egress queue mapping, while the other packets ingressing on the same port use COS?

Finally the auto qos trust cisco-phone profile seems a bit silly to trust cos, while service policy is based on dscp. Shouldn't you use cos in your service policy for the policers. Trusting dscp means you are overriding the trust cos on the port and therefore your trust ef and cs3 statements are also trusting ef and cs3 from the PC!! Cisco IP phones cannot rewrite DSCP and simply have to trust what comes from the PC, so it makes more sense to extend cos at 0 and simply conditionally trust cos only in this scenario. That being said, it would be nice to know what devices can rewrite DSCP (vaguely referenced in the SRND but not documented ANYWHERE I can find), so that I know when I can use the the trust DSCP facility on a device, but this probably isn't your department.

The only scenario I can see where the autoqos policy makes sense would be dependant on your answer to question 3 above. If indeed the service policy of match dscp ef (which is basically trusting dscp) is indeed causing the egress mapping using dscp instead of cos, then I guess you are using it to ensure dscp egress queue mapping. I'm not sure if it is that big of an issue however to use cos if you are only utilizing 2 markings as you are in auto qos trust cisco-phone, but then again I guess that depends on your answer to question 2 above. This whole setup seems wonky and is confusing to qos neophites who could be using the examples in auto qos to better understand the platform...and it confuses experts such as myself when the documentation and recommendations are often at odds with each other and full of exceptions or holes.

Thanks for your time and clarification.

Shashank Singh · ‎05-24-2012

Hi Matthew,

Please find the answers inline.

Does this mean traffic inbound from port g1/0/1 with trust cos will be classified on outbound port g2/0/1 using cos...not dscp. Is this true? Or does it mean that port g1/0/1 with trust cos also uses cos for it's egress mapping, but the above traffic from g1/0/1 to g2/0/1 will still use internally produced dscp?

On 3750 platform, if you are trusting cos on ingress, egress queueing wil happen based on cos-output-q map. Though internal dscp is calulated to internally apply QoS, it is not directly used for egress queueing. if ingress trust state is cos.

All said refrences to 3750-E series apply to 3750-X? Is this true...it generally is.

Yes, all references should apply to 3750-X as these switches are similar in design. If there are any corner cases where something works a little different, I am not aware of it.

Do the service policy packets ingressing on the port use DSCP to determine egress queue mapping, while the other packets ingressing on the same port use COS?

Your understanding is correct, packets not matching the policy map will depend on port trust state for QoS label generation. This is because ACLs ar considered prior to the trust state in the process of label generation. I hope this answer helps you with point 3 above.

Regards,

Shashank

Matthew Hall · ‎05-25-2012

Does this mean traffic inbound from port g1/0/1 with trust cos will be classified on outbound port g2/0/1 using cos...not dscp. Is this true? Or does it mean that port g1/0/1 with trust cos also uses cos for it's egress mapping, but the above traffic from g1/0/1 to g2/0/1 will still use internally produced dscp?

On 3750 platform, if you are trusting cos on ingress, egress queueing wil happen based on cos-output-q map. Though internal dscp is calulated to internally apply QoS, it is not directly used for egress queueing. if ingress trust state is cos.

I think I still need more clarification.

Which of the following is true (if not all):

Scenario1:

Ingress port g1/0/1 set for mls qos trust cos.

Egress port g2/0/1 set for no mls qos trust

Packets entering g1/0/1 and exiting g2/0/1 will utilize ONLY cos-output-q map for egress queueing decisions on g2/0/1

Scenario2:

Egress port g1/0/1 set for mls qos trust cos

Packets entering any switch port and exiting g1/0/1 will utilize ONLY cos-output-q map for egress queueing decisions on g1/0/1

Scenario3:

Ingress port g1/0/1 set for mls qos trust cos and a service policy trusting some DSCP.

Egress port g2/0/1 set for no mls qos trust

Packets entering g1/0/1 and exiting g2/0/1 will utilize ONLY cos-output-q map for egress queueing decisions on g2/0/1 unless those packets were matched in the port g1/0/1 service policy as DSCP trusted.

Scenario4:

Egress port g1/0/1 set for mls qos trust cos and a service policy trusting some DSCP.

Packets entering any switch port and exiting g1/0/1 will utilize ONLY cos-output-q map for egress queueing decisions on g1/0/1 unless those packets were matched in the port g1/0/1 service policy as DSCP trusted.

Thanks

Matt

Shashank Singh · ‎05-28-2012

Hi Matthew,

Please find answers inline.

Scenario1:

Ingress port g1/0/1 set for mls qos trust cos.

Egress port g2/0/1 set for no mls qos trust

Packets entering g1/0/1 and exiting g2/0/1 will utilize ONLY cos-output-q map for egress queueing decisions on g2/0/1

>> True.

Scenario2:

Egress port g1/0/1 set for mls qos trust cos

Packets entering any switch port and exiting g1/0/1 will utilize ONLY cos-output-q map for egress queueing decisions on g1/0/1

>>False. Trust is an ingress concept, trust state on egress port is not used.

Scenario3:

Ingress port g1/0/1 set for mls qos trust cos and a service policy trusting some DSCP.

Egress port g2/0/1 set for no mls qos trust

Packets entering g1/0/1 and exiting g2/0/1 will utilize ONLY cos-output-q map for egress queueing decisions on g2/0/1 unless those packets were matched in the port g1/0/1 service policy as DSCP trusted.

>>True.

Scenario4:

Egress port g1/0/1 set for mls qos trust cos and a service policy trusting some DSCP.

Packets entering any switch port and exiting g1/0/1 will utilize ONLY cos-output-q map for egress queueing decisions on g1/0/1 unless those packets were matched in the port g1/0/1 service policy as DSCP trusted.

>>False. Trust is an ingress concept, trust state on egress port is not used.

Regards,

Shashank