• Skip to main content
  • Skip to footer

NetworkJutsu

Networking & Security Services | San Francisco Bay Area

  • Blog
  • Services
  • Testimonials
  • About
    • About Us
    • Terms of Use
    • Privacy Policy
  • Contact Us

QoS Classification and Marking

03/04/2012 By Andrew Roderos 4 Comments

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

About three or four months ago, we’ve rolled out VoIP to our first remote site and was tasked to implement QoS. At the time, I knew a little about QoS (I still do) and that was the first reason why I had to read the QoS book last year. That was great since it also knocked down one area in my CCIE studies, but I am still not confident enough that what I currently know is enough for CCIE.

In my previous environment, we just copy and paste the QoS template and it should be good to go. That template is great and I am sure it is still being used by other engineers there since there were no issues in call quality using it. From what I was told, the template was just a tweaked version of Auto QoS. Anyway, today I’ll talk about what I learned about one topic in QoS. This post will not cover everything about the classification and marking since there are several ways of doing it.

In the most basic explanation, classification is a way for a router/switch to distinguish regular packets (DSCP value of zero or BE) from “premium” packets (DSCP value 46 or EF). By default, Cisco Catalyst switches do not care about the DSCP markings on the packets received, so no classification occurs. To verify this, let’s issue the command show mls qos int f0/1 using Catalyst 3560.

Switch#show mls qos int f0/1
FastEthernet0/1
QoS is disabled. When QoS is enabled, following settings will be applied
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

As you can see, the switch has QoS disabled and the ports are not trusted by default. To enable classification, QoS must be enabled globally and the command to do this is mls qos. After issuing this command, the show mls qos int f0/1 command will no longer show that QoS is disabled, as shown below.

Switch(config)#mls qos
Switch(config)# do show mls qos int f0/1
FastEthernet0/1
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

As you can see above, the output no longer shows that the QoS is disabled. However, the switch still do not trust the DSCP markings and will be marked zero or BE (best effort). There are several options to trust the DSCP marking and the most basic one is shown below.

Switch(config)#int f0/1
Switch(config-if)#mls qos trust dscp
Switch(config-if)#do show mls qos int f0/1      
FastEthernet0/1
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

Majority, if not all, of Cisco and Avaya phones mark the voice payload packet with DSCP 46 (EF) and COS 5 which is great since we do not have to do anything to mark them and we can just trust it. However, my issue with this command is that it will trust any packet that has an EF tag. That said, if a savvy user or worse a hacker who wants to do a DoS attack can mark their packets with an EF tag and when congestion occurs these unauthorized packets will be prioritized as well as your real time traffic, like VoIP. So, how can we prevent this from happening? Well, there several options that we can do. The very obvious one is by using the command below. However, this command will not help us if the phone isn’t made by Cisco. How does it know to differentiate if the phone is Cisco or not? You know it! By using CDP.

Switch(config-if)#mls qos trust device ?
  cisco-phone  Cisco IP Phone

Since the command above is not a non-Cisco phone friendly, what other options can we use so it’ll work with an Avaya or other IP phones available out there? There are two commands that I use for this depending on the platform. The first one is shown below. I normally use this command on 3560, 3750, and 6500. This command will not work on some platform, if I recall correctly, this will not work with 2950 and for sure on a Catalyst 4500 with Sup 7E. The Sup 7E uses MQC (Modular QoS CLI) to do QoS so no more srr or wrr commands. It basically acts just like a router which is great in my opinion since tweaking srr and wrr commands can be a pain. I honestly still do not know a whole lot about it but I’ll attempt to cover it some time this year.

Switch(config)#int f0/1
Switch(config-if)#mls qos vlan-based
Switch(config-if)#do show mls qos int f0/1
FastEthernet0/1
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: vlan-based

With this command, you will apply the policy on the SVI (Switch Virtual Interface) and not on the physical interface of the switch as shown below.

interface Vlan10
 description Voice VLAN
 ip address 192.168.1.254 255.255.255.0
 service-policy input PRIORITY

The service-policy input PRIORITY command will not work without having a policy map configured as shown below. Without a class map configured, you can’t really match anything under policy map. Having said that, you really need to follow the flow that was covered here.

Switch(config-if)#service-policy input PRIORITY
policy map PRIORITY not configured

Since I referred to my previous blog post, I’ll explain what those commands mean since they’re important part of this topic.

ip access-list extended VOICE-RTP
 permit udp 192.168.1.0 0.0.0.255 any range 16384 32767

16384 – 32767 is the port range that Cisco uses for its voice payload. This ACL will help us out with the classification phase.

ip access-list extended VOICE-SIGNALING
 permit tcp 192.168.1.0 0.0.0.255 any range 2000 2002

2000 – 2002 is what Cisco uses for its proprietary signaling protocol, Skinny Call Control Protocol (SCCP), also known as Skinny. The concept is pretty much the same as above, but signaling gets a lower DSCP value as mentioned in Cisco’s SRND (Solution Reference Network Design) Guide.

class-map match-all VOICE-RTP
 match access-group name VOICE-RTP
class-map match-all VOICE-SIGNALING
 match access-group name VOICE-SIGNALING

These commands create class maps named VOICE-RTP and VOICE-SIGNALING and will be used later for the policy map. These class maps uses the named ACL we created to classify which traffic will be trusted for QoS purposes. If traffic doesn’t match the ACL, then it will not be classified as voice related traffic.

policy-map VOICE
 class VOICE-RTP
  set dscp ef
 class VOICE-SIGNALING
  set dscp cs3

The policy actually tags the traffic that match our class maps with a DSCP EF tag. As mentioned, Cisco or Avaya phones mark their packet with DSCP EF so the set command is unnecessary. Truthfully, if you really want to be very specific in the ACL earlier you can do so as shown below. If I remember correctly, the older Cisco phones do not set their packet to CS3 and according to the revised SRND to remark it to this value. To be safe, let the set command under the voice signaling. Now with Avaya phones, I was told that the phones mark their signaling traffic to DSCP 46 (EF) which isn’t the recommended per SRND. Make sure to remark those packets or they will be competing with the voice payload.

ip access-list extended VOICE-RTP
 permit udp 192.168.1.0 0.0.0.255 any range 16384 32767 dscp ef

As mentioned earlier, the service-policy command is to apply the policy we just created. The direction included in the command works just like ACL – input coming into the interface and output going out of the interface.

interface Vlan10
 description Voice VLAN
 load-interval 30
 service-policy input VOICE

I like the mls qos vlan-based better since I can create separate policy for voice and data, but in the real world sometimes what you like isn’t always going to work. As mentioned earlier, the Sup 7E for Catalyst 4500 will not allow you to issue commands like wrr, srr, and mls qos. Having said that, the other option that I use is the service-policy command, which has been covered already. The only thing why I dislike using this is because I need to combine data and voice policies into one. Not really a big deal, just a preference.

Since we’ve covered the MQC already, then you already know how to combine the data and voice policy. What I like to do with my policy map though is call it something like DATA+VOICE or something to that effect which will definitely help the next guy that touches the network, at least in my opinion. Below is an example of a data and voice policy, but this is not complete by any means.

class-map match-any BULK
 match protocol ftp
 match protocol secure-ftp
class-map match-all MISSION-CRITICAL
 match protocol citrix
class-map match-any SCAVENGER
 match protocol gnutella
 match protocol edonkey
 match protocol kazaa2
 match protocol bittorrent
!
policy-map DATA+VOICE
 class VOICE-RTP
  set dscp ef
 class VOICE-SIGNALING
  set dscp cs3
 class MISSION-CRITICAL
  set dscp af31
 class BULK
  set dscp af11
 class SCAVENGER
  set dscp cs1
!
interface f0/1
 service-policy input DATA+VOICE

If you noticed, I didn’t use ACL for the data part. I used NBAR (Network Based Application Recognition) to classify the traffic. For your information, this is not available with 3560 or 3750 – only subset of NBAR. I only used it to show another way to classify a packet without using ACL. Also if you noticed, I have match protocol bittorrent in there but if you try to use it on router without the bittorrent PDLM (Packet Description Language Module), which is available for download from Cisco, then it will not work.

While I didn’t cover everything there is to know about classification and marking, I believe I’ve covered enough to get someone started with their QoS configuration. I will definitely try to cover srr commands next time since it is recommended to use L2 QoS/CoS even though it is high speed link compared to a typical WAN link.

I hope this has been helpful and thank you for reading!

References

Cisco QoS Exam Certification Guide (IP Telephony Self-Study) (2nd Edition)
End-to-End QoS Network Design: Quality of Service in LANs, WANs, and VPN

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Filed Under: QoS Tagged With: Cisco, IOS

About Andrew Roderos

I am a network security engineer with a passion for networking and security. Follow me on Twitter, LinkedIn, and Instagram.

Footer

WORK WITH US

Schedule a free consultation now!

LET’S TALK

Copyright © 2011–2023 · NetworkJutsu · All Rights Reserved · Privacy Policy · Terms of Use