Classification and Marking on Cisco Switch


(Rene Molenaar) #1

This topic is to discuss the following lesson:


(system) #2

Hi Rene, i like your blog and web gns3vault
I’ve a question because i’m doing troubleshooting with qos in switches and when i look at the policy i don’t see what i expect to see.

i have applied a policy fa0/1 input. i inject traffic but i don’t see ever increasing packet. Could it be because it is a switch ? when is a router i see increases

C3560-24TS_1#sh policy-map interface

FastEthernet0/1

Service-policy input: QoS_In

Class-map: Clase_Gestion (match-all)

  0 packets, 0 bytes

   offered rate 0 bps, drop rate 0 bps

  Match: ip precedence 7 

Class-map: Clase_Voz (match-all)

  0 packets, 0 bytes

   offered rate 0 bps, drop rate 0 bps

  Match: access-group 112

Class-map: Clase_Oro (match-all)

  0 packets, 0 bytes

   offered rate 0 bps, drop rate 0 bps

  Match: access-group 111

     

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

  0 packets, 0 bytes

   offered rate 0 bps, drop rate 0 bps

  Match: any 

    0 packets, 0 bytes

     rate 0 bps

thanks


(Rene Molenaar) #3

Hi Cat,

This is really confusing but the output on the 3560 will never show any hits. I’m not sure if it is IOS-specific but I’ve seen it on multiple switches.

Rene


(Moayad T) #4

Hello Rene,

thanks a lot for your efforts . I am on of your fans

regarding it is always shows 0 packets . a limitation of the platform (same for almost all the fixed configuration Catalysts). the counters don’t work and there is no tweak you can perform to make them work. The only command that shows you any half-useful statistics is ‘show mls qos interface statistics’. This will show you counters for the incoming & outgoing DSCP & CoS values, plus two counters for ‘Inprofile’ and ‘Outprofile’. These last two counters show you what traffic has adhered to its configured bandwidth within a policy and what hasn’t. It doesn’t show you individual counters for each class, nor does it show you whether the action was to drop or mark-down.

regards,


(ALFREDO V) #5

Hi Rene,

I have a question and may not be related to this section but it is to switches. I have been having latency issues with all my users in one location. We install a new 3560x switch with Access to shares, printing and voip and they are very very slow. I called cisco in regards to checking QOS on my switch, spoke to 2 different Engineers and I got different opinions, I have mls qos statements but QOS never enable so one opinion recommended these settings on the interface:

srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust cos
auto qos trust

and the second opinion was:

srr-queue bandwidth share 1  30  35  5
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
service-policy input AUTOQOS-SRND4-CISCOPHONE-POLICY
auto qos voip cisco-phone

I also have this command enable: auto qos srnd4 and I have cisco phones.

What is your opinion on this one?

 


(Rene Molenaar) #6

Hi Alfredo,

QoS on switches can be a pain…first of all, if you don’t have “mls qos” enabled then it won’t do any packet rewriting but it will still be queuing.

Take a look at this post, there I explain how queuing works and there’s a great video that explains QoS on the switches:

Here’s an example of a production 3560 switch here without “mls qos” enabled, you can see it’s queuing:

SWITCH#show mls qos interfac GigabitEthernet 0/1 statistics
GigabitEthernet0/1 (All statistics are in packets)

dscp: incoming
-------------------------------

0 - 4 : 178414745 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 0 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
dscp: outgoing
-------------------------------

0 - 4 : 14636069 0 0 0 17401786
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 59194045 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 44 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 0 0 275 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
cos: incoming
-------------------------------

0 - 4 : 349353181 0 0 0 0
5 - 7 : 0 0 0
cos: outgoing
-------------------------------

0 - 4 : 471256874 0 0 0 0
5 - 7 : 532 0 51009
output queues enqueued:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 0 0 0
queue 1: 0 1135332 8306773
queue 2: 0 0 0
queue 3: 0 0 461977806

output queues dropped:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 0 0 0
queue 1: 0 0 0
queue 2: 0 0 0
queue 3: 0 0 0

Policer: Inprofile: 0 OutofProfile: 0

Before you make any changes, you should figure out a couple of things:

  1. Are there any drops? If so, which interfaces?
  2. What packets are being dropped? what queue and what threshold?

Here you can see the drops:

SWITCH#show platform port-asic stats drop g0/1

Interface Gi0/1 TxQueue Drop Statistics
Queue 0
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 1
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 2
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 3
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 4
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 5
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 6
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 7
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0

This interface isn’t dropping anything but perhaps on your switch, you do see drops. If you see them then you need to figure out what kind of traffic goes into what queues:

SWITCH#show mls qos maps cos-output-q
Cos-outputq-threshold map:
cos: 0 1 2 3 4 5 6 7
------------------------------------
queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1
SWITCH#show mls qos maps dscp-output-q
Dscp-outputq-threshold map:
d1 :d2 0 1 2 3 4 5 6 7 8 9
------------------------------------------------------------
0 : 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01
1 : 02-01 02-01 02-01 02-01 02-01 02-01 03-01 03-01 03-01 03-01
2 : 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01
3 : 03-01 03-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01
4 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 04-01 04-01
5 : 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01
6 : 04-01 04-01 04-01 04-01

With the drops in the queues and the tables above, you can figure out what is being dropped. For example, COS 0 and DSCP 0 (unmarked packets) go to Queue 2 Threshold 1. Here are the default values on the switch:

SWITCH#show mls qos interface g0/1 queueing
GigabitEthernet0/1
QoS is disabled. When QoS is enabled, following settings will be applied
Egress Priority Queue : disabled
Shaped queue weights (absolute) : 25 0 0 0
Shared queue weights : 25 25 25 25
The port bandwidth limit : 100 (Operational Bandwidth:100.0)
The port is mapped to qset : 1

When there is congestion, by default each queue gets 25% of the bandwidth. Here you can find the buffers and thresholds:

SWITCH#show mls qos queue-set 1
Queueset: 1
Queue : 1 2 3 4
----------------------------------------------
buffers : 25 25 25 25
threshold1: 100 200 100 100
threshold2: 100 200 100 100
reserved : 50 50 50 50
maximum : 400 400 400 400

Now let’s look at your configurations:

srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust cos
auto qos trust

Your queues will get:

Q1 = 10%
Q2 = 20%
Q3 = 60%
Q4 = 20%

Unmarked traffic goes to Q2 by default and I’m guessing the ‘bulk’ of your traffic is untagged (printing / file sharing) so if you see drops there, reducing the queue isn’t going to help. Your voice traffic goes to Q1 by default, enabling the priority queue is a good idea. Depending on what you see in your output, I think you probably need to increase Q2, not Q3.

srr-queue bandwidth share 1 30 35 5
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
service-policy input AUTOQOS-SRND4-CISCOPHONE-POLICY
auto qos voip cisco-phone

 

Enabling the priority queue is a good idea, by default Q1 will be the priority queue. COS 5 and DSCP 46 packets go to Q1 by default.

You also want to think about the threshold/buffers. This is the ‘storage space’ of your queue. If you increase it then you can store more in the queue…when it’s full, it will drop packets. Let’s say you have a lot of unmarked traffic, in this case I would remap it from T1 to T3.

Also when you test this, use queue-set 2…by default all interfaces are mapped to queue-set 1.

You need to figure out your traffic pattern, your drops and then come up with a ‘plan’ for your queues and buffers. Implement it and then check if things have improved or not.

Rene


(Abhishek D) #7

Hi Rene,

with First policy-map you gave a value of dscp 40 but in second policy-map you gave DSCP cs6 ? what is the reason for this ?

Thanks
Abhishek


(Rene Molenaar) #8

Hi Abhishek,

No particular reason, these are just two random values I picked.

Rene


(Mark S) #9

Rene,

I am a new member. I like what I see. Great job!

One question. I have a customer with a server that has a telnet based app. I am about to use what is basically the exact same config you have above for SSH, only for telnet. That covers the server. Is anything truly required for clients? In my case all of the clients are wireless tablets running a client that simply opens a telnet session to the server. The example above classifies and marks SSH traffic at the server switch port. Once that traffic is marked, is there a requirement to also mark traffic at the client side going to the server? By requirement I mean if I want true end-to-end QoS for the app do I need to classify and mark traffic at the server switch port and client switch ports, or should I be covered by taking care of the server side only?

Thank you.

Sincerely,

Mark


(Andrew P) #10

Mark,
First of all–welcome to the site, we are glad to meet you.

As far as marking traffic, you should mark it in both directions to ensure both sides of the conversation get the same preferred treatment. As an example, for telnet, here’s the gist of what you would want. In the policy below, I am guaranteeing a certain bandwidth and marking the traffic to use best practice transactional DSCP markings.

Create your access-lists

ip access-list extended ACL_TELNET
 permit tcp any any eq telnet
 permit tcp any eq telnet any

Create your Class-Map

class map match-any CM_TELNET
 match access-group ACL_TELNET

Create your Policy-Map

policy-map PM_TELNET
 class CM_TELNET
  bandwidth 4096
  set ip dscp af31

Apply Your Policy-Map to an Interface

interface gig0/1
 service-policy output PM_TELNET

(Mark S) #11

Andrew,

Thank you for the reply, but now I am confused. “service-policy output PM_TELNET”

Output? I thought I am marking the traffic at the server side switch port in the inbound (input)
direction. I would expect to do the same at the client side.

What changed? Or maybe I should be asking why did it change?

Also, and this is admittedly a minor clarification, could I not split your access-list ACL-TELNET
into two separate ACL’s, one on the server side and one on the switch side? (I understand that your ACL could be
used on the server side and client side switches as it covers the ‘conversation’ in both directions).

Switch attached to the server:

ip access-list ACL_TELNET_SERVER
 permit tcp host 10.1.1.1 eq telnet any   <-- assume server IP is 10.1.1.1

Switch attached to the client:

ip access-list ACL_TELNET_CLIENT
 permit tcp any host 10.1.1.1 eq telnet

I am still thinking that both of these ACL’s would be applied inbound on the switch ports.

I will await your answer as to why you used outbound.

*NOTE* As I am typing this I had a thought. Are you applying the service policy in the outbound direction because
your ACL covers the conversation from both directions?

If yes then if I used two ACL’s (as above) then I would apply them in the inbound direction because my ACL’s each only cover
one side of the conversation.

Again, thank you very much.


(Andrew P) #12

Mark,
I was giving you an example, not necessarily the solution in your situation. Of course, you will need to modify as necessary for your environment. In many QoS deployments, it is the slower speed links, as opposed to the LAN, where QoS has the greatest impact. An outbound policy set on a router that leads to a VPN connection, for example, gives you more options–like queueing and shaping. It was this type of model that lead me both to set an outbound policy and to have bi-directional marking of relevant telnet traffic. .


(Abhishek D) #13

Hi Team,

My doubt is with respect to some advance platforms such as 4500/6500/6800 -

  1. I understand that there are significant difference compare to MLS. these platform just do not support MLS anymore. and lot of things are enabled by default.
    Can you just help me understand some high level concepts (a few lines) regarding QOS on these platforms like what has changed ?

  2. More specifically - when any marked packet comes at ingress of these platform - will they trust by default ? or we need to do anything ?

or ex: cisco phone-----3850-----4500----6500

In above example : do I need to trust marking on ingress of 3850 done by cisco phone or its by default trusted?

also How ingress interface of 4500/6500 will treat packets marked by cisco phone ?

Thanks
Abhishek


(Stefanio L) #14

Hi, Cat

This is an expected behavior, because the QoS markings on the switch are made in hardware and how the show policy-map command is in software the values will always be at zero. More details at the link below:


(AZM U) #15

Hello Laz,
Sorry for asking you too many questions. Still lot of things in QoS are blurred to me. If you like to help, hopefully I will get there.
A few questions.
I was going over a configuration guide for 3850 to turn on auto qos(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/3se/qos/configuration_guide/b_qos_3se_3850_cg/b_qos_3se_3850_cg_chapter_0100.html#d5298e1455a1635). This document is referrencing a few commands to turn on auto qos such as auto qos trust dscp , auto qos trust cos, auto qos video cts, auto qos video ip-camera etc. First question is why does one of these commands have auto qos trust dscp? I thought only COS value is used for layer 2 marking. Second question is what are those various commands for? What is the standard command to turn on auto qos? Once auto qos is turned on, what is the marking scheme that switch uses to mark frames? Is there any way to check it? The reason why I am asking these questions is let’s say in a network scenario, all the access switches are using auto qos for marking and the distribution layer 3 device is using manual policy map configuration for qos. How would I match the marking of the access switch with the layer 3 distro switch to configure policy map if I do not know how the access switches are marking frames?

I know it’s too many questions. However, your help is always highly appreciated.

Best Regards,
Azm


(Lazaros Agapides) #16

Hello Azm!

Always happy to answer questions!

It is true that COS functions at layer 2 and DSCP functions at layer 3. However, switches can be configured to use the COS or the DSCP for the reference to QoS. It really depends on what you want and how you have configured the switch. The trust parameters will essentially tell the switch to trust COS or DSCP. It’s really up to you.

The purpose and functionality of Auto-QoS is well described in the document you linked to. This description can be found here. Essentially, Auto-QoS “determines the network design and enables QoS configurations so that the switch can prioritize different traffic flows.”

There is no one standard command that enables auto-QoS. Although it is automatic, you still have to indicate what the specific port is connected to such as an IP phone, an IP camera or if you want to configure it as trusted or not. These commands are all explained in detail here.

You can monitor and view the auto-QoS configurations using the various show and debug commands described in the document.

Also, once the auto-qos commands are applied, specific class maps are created with specific parameters. All of these can be found in the document you linked to. These specific commands are added to the running configuration and you can view it to see exactly what parameters have been configured so you can manually conform the rest of your network to that.

I hope this has been helpful!

Laz


(AZM U) #17

Hello Laz,
It’s always exciting to get your reply. It seems like I have made some progress in the QoS track. Need some clarifications.

  1. By default, a switch does not trust anything and whenever it receives any frame with marking, it erases the marking and put the best effort tag(00) on it before it sends the frame out to a different device. When a switch receives a frame with no tag on it, it does not do anything to that frame meaning tag will be eventually 00/best effort. Please validate that statement.
  2. In order to have a switch trust another device’s marking, the switch needs to be told to trust that. It is enabled by using auto qos trust command. This action can be device specific by using auto qos voip cisco-phone or auto qos video ip-camera command. Needs validation.
  3. Is there any command to enable qos in a switch globally in MQC model that will analyze the traffic and create class-maps, policies etc. automatically to optimize traffic flow?
  4. When Cisco Phones mark traffic, do they mark traffic in the frame level, packet level or in both?
  5. What does a router(no qos configuration) do when it receives a packet with marking before it send the packet out to a different device? Does it strip off the QoS marking or it send the packet out as is?
  6. If QoS is enabled on an access switch to mark traffic, Do the trunk link going to the distribution switch have to have any qos configuration to forward the marked traffic to the upstream distribution switch or it will do automatically?
  7. Does a cisco switch recognize third party vendors’ phones’ marking?
  8. mls qos is an old method to configure qos. The modern platform is MQC and it does not support mls qos. Needs validation.

Thank you again.

best regards,
Azm


(Lazaros Agapides) #18

Hello Azm

Yes, you are correct.

Yes. The auto qos trust command will configure the CoS-to-DSCP map while the auto qos voip and auto qos ip-camera (and others) will create detailed class maps and policy maps based on best practices. You can find out more in this excellent Cisco documentation.[quote=“azmuddincisco, post:17, topic:857”]

  1. Is there any command to enable qos in a switch globally in MQC model that will analyze the traffic and create class-maps, policies etc. automatically to optimize traffic flow?
    [/quote]
    As far as I know, there is no “silver-bullet” QoS solution for Cisco devices where traffic is analysed and QoS is automatically and dynamically configured. You must specify something (like auto classify, auto qos voip cisco-phone or similar commands) to more specifically indicate to the switch how to implement QoS for specific ports.

A Cisco phone will mark traffic using both CoS (Layer2) and DSCP (Layer3).

Because CoS information is found in Layer 2 and DSCP information is found in Layer 3, in the scenario that you describe, the CoS information will be stripped away along with the Layer 2 header. The Layer 3 header however will retain the DSCP information and thus will retain the related QoS markings.

In order for the access switch to send QoS info to a trusted device on the other end of the trunk, you must apply QoS configuration on the trunk. For example, if you are configuring QoS for VoIP, you need to apply QoS throughout the path that VoIP travels.

A Cisco switch will recognise QoS markings of 3rd party phones as long as they are using QoS standard markings. However, configurations such as auto qos voip cisco-phone will NOT work correctly because the QoS labels of incoming packets are trusted ONLY when the telephone’s presence is detected using CDP. In order to make non-cisco IP phones function, the ports must be configured manually as if connecting to a trunk port to a switch, and then the command auto qos voip trust must be used as if configuring the QoS on a trunk.

This really depends on the IOS version being used. Some will support both for the purposes of interoperability with older devices, however I’m not sure from which version on the old method is still supported. You will have to check for each IOS version that you are using.

I hope this has been helpful!

Laz


(AZM U) #19

Hello Laz,
Great help once again…SPECTACULAR !!!


One confusion.
Does the auto qos trust command work on the inbound traffic or outbound traffic or both?

SWITCH B-(fa 2/2)<<<-----trunk---------(fast10/10)–SWITCH A-(fa 1/1)<<<<---------VOIP PHONE

Let’s say Switch A is connected to a VOIP phone through fast 1/1 interface. If auto qos trust is enabled under fast1/1 interface, it will accept all the standard marking from the VOIP phone as long as it shows up in the cdp. Is that correct? In the configuration guide, it says only router or switch.

When Switch A sends the marked traffic to the Switch B, where does auto qos trust need to be enabled to have Switch B trust all the inbound traffic from Switch A? Is it under the fast 10/10 on Switch A or it is under fast 2/2 on Switch B? It is kind of confusing to me because the configuration guide says that enabling auto qos trust will tell the switch port to trust the router or switch on the other end. That means in this scenario, if auto qos trust is enabled under fast 10/10 on switch A, Switch A will trust all the marking from Switch B. Similarly if I want Switch B to trust all the marked traffic from Switch A, I can enable auto qos trust under fa2/2 on Switch B, but Switch A will set best effort to every single packet though. Need some help…

Thank you so much.

Best Regards,
Azm


(Lazaros Agapides) #20

Hello again AZM. Great to hear that you’re pleased with my help! Happy to be here!

QoS mechanisms work on an interface in both directions, both inbound and outbound. When inbound, the switch port is instructed to trust the QoS marking (DSCP/CoS) in the packet. When outbound, the switch port needs to give specific packets, such as voice, “front of queue” priority.

The auto qos trust command will accept all the standard markings from ANY device connected to that port. It is the auto qos voip cisco-phone command that will further refine the QoS mechanisms for a Cisco IP phone ONLY IF it detects a Cisco phone using CDP.

QoS should be enabled on both ends of the trunk so that both inbound and outbound QoS functionalities can take place on both ends.

I hope this has been helpful!

Laz