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.
