Cart
I have often wondered why the Catalyst 3750 QoS section is one of the most feared items on the CCIE Voice lab blueprint (the same might be said of the Catalyst 3560 with respect to the R&S blueprint) and I always come to the conclusion that it is due to the lack of validation which would prove that what you have configured is correct. Whereas in other areas of the lab one is able to make a call through a selected gateway or call voicemail and hear the appropriate greeting or possibly see changes in the routing table, with QoS nothing really changes! There is no tangible difference when comparing the before and after. The calls don’t sound any better and the ping tests are not improved since there is no actual need for QoS, as congestion on any interface in the lab does not exist (unless you are doing something really wrong!). A blog on this site discussing the QoS features has been a long time coming, mainly because it has taken me so long to work everything out! This is the first in a series of blog’s that will discuss all of the QoS features that are available in the Catalyst 3750 and 3560 switches.
Documentation
The first thing to point out is where to find information. There are two documents that I would like to reference- the Catalyst 3750 Configuration guide and the Catalyst 3750 configuration example (document 91862) which can be found here and are available to you in the lab.
http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml
Incidentally the 3750 and 3560 are identical from a QoS perspective- the 3750 does contain Cisco Stackwise technology which allows for up to 9 switches to function as a single logical unit but this is largely irrelevant given the scope of our discussion.
Overview of QoS Features
The software-based QoS features are summarized in the picture below.
We have QoS features (classification/marking, WTD, queuing and scheduling) on the ingress side that ultimately determine the makeup of the traffic that is placed onto the shared bus or internal ring of the switch. We also have a similar set of QoS features on the egress side (without the classification and marking). The QoS features on the egress side are much more important since the likelihood of the link to the endpoint connected to the egress interface becoming over-subscribed is far greater than the likelihood of the shared bus (32Gbps bandwidth) becoming over-subscribed.
In this particular blog we will focus on Classification and Marking- subsequent blogs released on this site will deal with the other QoS features on the Catalyst 3750.
Classification & Marking
By default, when multilayer switching has not been enabled on the Catalyst 3750, the incoming layer 2 and layer 3 markings (COS, DSCP) are honored- in effect the port is trusted. For example, a router receiving traffic originating from an IP Phone connected to the Catalyst 3750 will see DSCP set to 46/24 for RTP and SCCP/SIP traffic respectively.
When “mls qos” has been enabled the opposite is true- all markings are set to Best Effort. The DSCP and COS value for all traffic is set to 0. The output shows the default COS- the DSCP is derived from the COS in this instance.
You are able to change the default COS value per interface using the commands below:
In this case the port is not trusted but all traffic is marked with a value of COS 5.
The DSCP for all traffic originating from Fastethernet 1/0/23 will now be marked to DSCP 46 as the COS-DSCP map tables will determine the markings in the Layer 3 header.
You can trust the Layer 2 markings (COS) as shown below:
This is only going to be effective for 801.1Q trunks since the COS (802.1p) is an extension of 802.1Q which is used for VLAN tagging. It would be effective for phone ports which use the command “switchport voice vlan xx” since this is a pseudo-trunk in that the 802.1Q (and 802.1p) extension is used specifically for phone traffic (on vlan xx).
Trusting layer 2 is not the correct strategy for access ports and for 802.1Q trunks between a WAN router and a switch (traffic coming in from the WAN does not contain the COS since typically Layer 2 is different over the WAN e.g. Frame Relay). In this instance trusting the layer 3 is the way forward- configuration shown below:
Which trust option you have used will affect other QoS features of the Catalyst 3750. Mapping traffic to the appropriate queue (for ingress and egress) will be dependent on whether the frame’s QoS label was set at layer 2 (trust cos) or layer 3 (trust dscp). If an interface has been configured with the command “mls qos trust cos” then all traffic originating from this specific port will be placed into ingress and egress queues based on Layer 2 (cos-input-q and cos-output-q). Similarly if an interface has been configured with the command “mls qos trust dscp” then all traffic originating from this specific port will be placed into ingress and egress queues based on Layer 3 (dscp-input-q and dscp-output-q). Queuing will be discussed in further detail in a subsequent blog.
An additional command that can run in tandem with either “mls qos trust cos” or “mls qos trust dscp” is the “mls qos trust device cisco-phone” command which sets a conditional trust boundary on a specific interface. In other words the Layer 2 or Layer 3 setting for the particular interface will only be trusted if the endpoint connected directly into the switchport is a Cisco IP Phone (discovered using CDPv2 or LLDP-Med).
Rather than rely on the endpoint connected to the switch for marking L2/L3, it is possible to use MQC on the actual switch for this purpose. In other words, rather than trust cos/dscp, you have the option to use a service-policy in tandem with ACL or some other classification mechanism. Service-policy’s can only be applied for incoming traffic- traffic being received on an interface as opposed to traffic being sent to an interface.
Before discussing MQC as a tool for classification and marking, let’s take a look at what happens when you run AutoQos.
When auto qos voip cisco-phone has been configured on a specific interface, QoS is enabled and a bunch of QoS-related commands (deemed to be best-practice) are configured on the switch. Specifically you will see the following configuration within the interface that was configured with the autoqos command:
By looking at the interface you can see that the policy-map “AutoQoS-Police-CiscoPhone” is applied to all traffic being received from the endpoint connected to Fa1/0/2. Upon closer inspection you can see that traffic with DSCP 46 (RTP) and DSCP 24 or 26 (SCCP/SIP) is being policed:
The AutoQoS macro classifies RTP and Control traffic based on the incoming DSCP value from the endpoint (a phone in this case). Notice that for Control traffic we are matching on the old (af31) as well as the newer DSCP value (cs3) that control traffic should use as per the QoS baseline. This has to be done within a single match statement- multiple match statements within a class is not allowed.
Within the policy-map we must either trust or set the layer 2 or 3 markings otherwise the default DSCP/COS (0) will be used. AutoQoS uses “set dscp ef” for the RTP class but “trust dscp” would be equivalent in this case since the incoming DSCP is already ef. As well as MQC-based marking, the policy-map is used for policing RTP and Control traffic to 320k and 32k respectively. Any traffic that is in excess of these thresholds are remarked to DSCP 0 as per the command below (AutoQoS default command shown):
Finally let’s go back and take a look at what AutoQoS did within the interface again:
Notice above that we are trusting DSCP as well as applying a service-policy within the same interface. Well- given that we are also writing / trusting DSCP within MQC, which one out of the trust and service-policy takes effect? The answer is for traffic that matches a particular class-map then the service-policy wins every time. For traffic that does not match a particular class-map then the trust setting takes effect (which assumes there is no class class-default within the policy-map). Based on these facts, it is clear that the “trust dscp” within interface Fa1/0/23 is indeed redundant for RTP and Control traffic since these types of traffic will match classes within the attached policy-map. It is probably simper to use trust or service-policy but not both.
MQC also has the flexibility to classify based on ACL (as opposed to incoming Layer 3 markings). For example in the configuration below we are policing web traffic from a server connected to Fa1/0/4 to 500k.
Anyhow- enough about classification and marking, please lookout for blogs on the other QoS features available on the Catalyst 3750 over the next few days/weeks.
Vik Malhi,
Instructor – IPexpert, Inc.
Tags: campus qos, catalyst 3750, ccie voice, ccie voice 3750, CoS, DSCP
Great article! Just curious but isn’t there really any other way how to check whether QoS is correctly set or not? Only idea I got is using any sort of packet sniffering but it doesn’t seem to me too much ‘handy’…Thank you!
Looks like whole documentation in one page (like cheat sheet). Best documentation I ever saw.
Thanks Vik, it really helps lot of IE aspirants to understand in and out of LAN QoS
Excellent article, thanks for the post!
One quick question: on your 2nd to last config example after “lets go back and take a look at what AutoQoS did with the interface again” (http://blog.ipexpert.com/wp-content/uploads/2011/05/3750-93.png), you note that we are trusting DSCP in the config example.
I see “trust cos” and “trust device cisco-phone” in there. Does the trusting the device “cisco-phone” enable trusting for both DSCP and COS? I see you noted earlier that trusting the cisco-phone device will trust whichever other trust statement is there (when you described the cisco-phone trust command), but that appears to be COS in this case.
Could you clarify that last one for us? Thanks much!
Thank you for the nics post.
I have read the following statements in the Cisco document 91862.
The configuration based on the incoming CoS/DSCP value is achieved in three different ways:
· Port based configuration using the mls qos interface based commands
· MQC based configuration using class-map and policy-map
· VLAN based configuration
You can use either one of these three methods. You cannot use more than one method in a port. For example,
you have configured the mls qos trust cos command on a port. When you configure the port with the
service-policy input command, it removes the mls qos trust cos command
automatically.
How could you configure both service-policy and mls qos trust cos under the same port? do I misunderstand it?
Very Informative post
I have a query regarding “Shared Bus or Internal Ring” Can you please elaborate more and throw some light on this? Thank you
@Raj- I am referencing the backplane of the switch- this allows for transferring of frames between ports…
@Michael- the service policy and mls qos trust command can co-exist- however they could not coexist in earlier IOS releases but I know in 12.2(46) and later it can.
@gnavarrette- the “trust device cisco-phone” trusts whatever is configured and nothing else. So if you have “mls trust cos” then cos is trusted and dscp is built from cos. If you trust dscp dscp is trusted and cos is built from dscp.
“… Notice that for Control traffic we are matching on the old (af31) as well as the newer DSCP value (cs3) that control traffic …”
I always thought that IP-Precedence scheme (3 bits marking -> CS3 in DCSP language) is older than 6 bits AF31 marking, ot the other way round.
@Tomasz- with Cisco implementations they originally used AF31 for control signaling and then they went to CS3 for backwards compatibility with IPPrec.