Blog Home | INE Home | Members | Contact Us 

Free Resources View Archives Training Products CCIE Bloggers

30 Traffic Classification in the 3550/3560 Switches
Oct visistat
Posted by Petr Lapukhov, 4xCCIE/CCDE in QoS,Switching 7 Comments Search  

In this post we will look at the basic classification and marking features available in the 3550 and 3560 switches. Submit

Basic features include packet marking using port-level settings and port-level policy-maps. Discussing Per-VLAN
classification is outside the scope of this document. Categories
Select Category
The Catalyst QoS implementation bases on Differentiated Services model. In a few words, the ideas of this model
could be outlined as follows:
Current Poll
1) Edge nodes classify ingress packets based on local policy and QoS label found in packets.
How did you first hear about
2) Edge nodes encode traffic classes using a special field (label) in packets to inform other nodes of the
INE?
classification decision.
 Friend
3) Core and edge nodes allocate resources and provide services based on the packet class.
 Google
 Forum/Mailing List
Note that each node acts independently on its own, as instructed by the local policy. In order for the QoS policy to  Blog
be consistent end-to-end, the network administrator must ensure that all nodes use the same classification and  Facebook/Twitter
 Youtube
resource allocation policy.  Other
   Vote   
The following are the marking types found in IP/Ethernet networks: View Results

1) ToS byte in IP packet or Traffic Class byte in IPv6 packet. The switch may interpret this field in two different Polls Archive

ways:
1.1) Interpret the topmost six bits of the byte as DSCP code point. This is in full compliance with Diff-Serv model.
CCIE Bloggers
1.2) Interpret the topmost three bits of the byte as IP Precedence value. This complies with the old, â€œmilitary-
styleâ€​ QoS model, where higher precedence traffic preempts the lower precedences. Note that IP Precedence Brian Dennis CCIE #2210

numbers form a â€œsubspaceâ€​ of DSCP numbers. Routing & Sw itching

ISP Dial
2) The CoS bits (three bits) in 802.1q/ISL header of a tagged Ethernet frame. These bits are also known as
Security
802.1p priority bits, and should be interpreted as relative traffic priorities. Service Provider
Voice

As we can see, the marking types could be either Layer 3 (IP/IPv6 fields) or Layer 2 (802.1p bits). Naturally, the Brian McGahan CCIE #8593

latter option is only applicable on trunk links. Routing & Sw itching

Security
Service Provider
The Catalyst switches have no special intelligence to implement any of these QoS models by themselves. It’s
Petr Lapukhov CCIE #16379
up to you to define policy and encode classes using any marking you find more suitable for your task. Due to
Routing & Sw itching
numerous markings types, Catalyst switches assign a special internal QoS label to all packets and use this label Security
for internal QoS processing. In the 3550 this label is simply a special â€œinternalâ€​ DSCP value. However, in the Service Provider
Voice
3560 the QoS label format is more complicated, and allows storing either CoS or DSCP information.
Anthony Sequeira CCIE #15626
Routing & Sw itching
Now recall the distinction made by the multilayer switches between IP and non-IP packets. As we know, Layer 3
Mark Snow  CCIE #14073
switches are hardware optimized to route IP or IPv6 packets using their ASICs for optimum performance. This
Voice
results in differences of handling the IP and non-IP packets. You may use MAC-based ACLs (matching MAC
Security
addresses, Ether-types or LSAPs) only with non-IP packets (e.g. ARP, DECNet, IPX). The MAC ACLs will not match
Josh Finke CCIE #25707
any of IP packets, even if you specify a matching MAC addresses. Also, note that the 3560 models treats IPv6 as â
Voice
€œIPâ€​ traffic, while the 3550 treats IPv6 packets as â€œnon-IPâ€​ and matches them with MAC ACLs.

QoS processing pipeline Bootcamps
November 15 - 19 
The following diagram displays stages of QoS processing in a typical Catalyst switch.
MockLab Workshop 

Location: London, UK

Enroll Now

December 5 - 10

Mock Lab Workshop 

Location: London, UK

Enroll Now

December 6 - 17

12-Day Bootcamp

Location: Reno, NV

Enroll Now

We are now considering the Classification and Marking stage. The switch uses local policy configuration to classify
input packets. The local policy may be as simple as port QoS settings or more complicated, such as policy-maps Popular Posts
with QoS ACLs. The result of classification stage is the internal QoS label (e.g. internal DSCP value with the
Understanding Inter-Area Loop
3550). At this stage, the switch uses special globally configurable QoS mapping tables. The tables map one QoS
marking â€œtypeâ€​ to another, e.g. CoS values to DSCP, or DSCP to CoS. You can display the tables using the Prevention Caveats in OSPF

command show mls qos map. Protocol

The EIGRP Composite Metric -
The switch uses these tables for two major purposes: Part 1

Announcing INE's CCDE Practical
a) To â€œsynchronizeâ€​ different types of QoS markings present in a packet. For example, if you instruct the
Bootcamp
switch to set CoS field to â€œ3â€​, the switch will look up through the CoS-to-DSCP mapping table and rewrite the
DSCP value in the IP packet header accordingly. The Basics of EIGRP

Follow  Anthony of INE on Tw itter

b) To translate the ingress marking (e.g. CoS, or IP Precedence) into the values used in the QoS label. For
example with the 3550 switch, the CoS to DSCP mapping table is used when you trust ingress CoS marking to find
the resulting internal DSCP value.

You may classify using either interface level settings or by applying a pre-configured policy-map to the interface.
These two options are mutually exclusive: that is, if you configure interface level classification settings and later
apply a service-policy, then the latter removes interface-level QoS classification settings (there are some
exceptions though).

Classification Options

1) Trust one of the marking types already present in packet (mls qos trust {dscp|ip-precedence|cos}). For IP
packets, it is possible to trust either IP Precedence or DSCP value. Of course, doing so makes sense only for IP
packets. If the switch trust IP marking and incoming packet is non-IP, the switch will attempt to classify based on
CoS value in the Ethernet header. If there is a CoS value in the packet (i.e. the port is trunk) the switch uses this
value to build the QoS label. However, if the packets bears no CoS field, the switch will look at the default CoS
value configured on the interface (mls qos cos x). The switch computes corresponding DSCP value for the label
using the CoS to DSCP table. When you trust IP precedence, the switch builds DSCP value using the IP-
Precedence to DSCP mapping table and the CoS value using the DSCP to CoS mapping table.

2) Trusting CoS (mls qos trust cos) is a bit different. First, it works for both IP and non-IP packets, since they
both may bear CoS bits in the Ethernet header. Thus, when the switch trusts CoS on interface, it attempts to build
the QoS label based on the CoS bits. If there is no 802.1q/ISL header, the default CoS value from the interface
settings is used instead (not the IP/DSCP value from the packet header!). This procedure works for both IP and
non-IP packets: the switch does not take in account the IP Precedence/DSCP values. The corresponding mapping
table allows the switch to compute the internal DSCP value/QoS lable and rewrite the DSCP values in the IP/IPv6
packet header.

3) You may explicitly assign a specific CoS value to all packets, either marked or not, entering the interface using
the mls qos cos override command. This command will force the use of CoS value specified by the mls qos
cos x command for all IP and non-IP packets. Note that this feature only works with CoS values, and the switch
deduces actual DSCP marking using the CoS to DSCP mapping table. Also, note that any â€œtrustâ€​
configuration on an interface conflicts with the â€œoverrideâ€​ settings and thus the switch removes the former
commands.

4) The most flexible option is to use QoS ACLs to perform classification and we are going to discuss the use of
QoS ACLs in a separate topic below.

A special type of trust is conditional trust. That means trusting QoS marking only if the switch detects certain
device connected to the port – for example, if the switch senses Cisco IP Phone CDP announces. The command
for conditional trust is mls qos trust device and it instructs the switch to trust the packet marking only if the
certain device reports itself via CDP.

The automatic rewrite feature ensures the uniform marking – that is, it takes care of synchronizing L2 and L3 code
points. Is it possible to trust DSCP and built the internal QoS label based on its value, but retain the CoS bits in the
packet? Alternatively â€“ trust CoS bits and retain the DSCP values? You may need this capability occasionally, if
you want to â€œtunnelâ€​ one type of QoS marking through your network, while using the other type for your
needs.

QoS Pass-Through feature

In the Catalyst 3550, you may set one type of marking as â€œpass-throughâ€​. For example, when you trust CoS
you may enable DSCP pass-through with the interface-level command mls qos trust cos pass-through dscp.
The command with reverse logic is naturally mls qos trust dscp pass-through cos.

On the 3560 switches, you only have option to disable DSCP rewrite in IP headers, when you trust the CoS values,
using the global command no mls qos rewrite ip dscp

Classification using QoS ACLs

Even though they are called QoS ACLs (the term borrowed from CatOS) you actually apply these using MQC
syntax by configuring class-maps and policy-maps. You may define MQC traffic classes by matching one of the
following:

1) MAC or IP/IPv6 access-list. The MAC access-list matches non-IP packets and IP/IPv6 matches IP or IPv6
packets respectively. Of course, you can only match IPv6 packets on the 3560. As mentioned above, you cannot
use MAC ACLs to match IP traffic (though you can use MAC ACLs on the 3550 to match IPv6 traffic).

2) DSCP and IP Precedence values. Note that you cannot match CoS value in Ethernet headers (like you can do
in routers).

3) Additional platform-specific matches like match input-interface and match vlan. These are used by the 3560
hierarchical policy maps or the 3550 per-port per-VLAN classification.

The classification criteria are very limited, compared to IOS routers. You cannot match packet size or packet
payload. Additionally, you cannot do hierarchical matching, with exception for per-VLAN classification feature.
These limitations are result of tight hardware optimization in the Layer 3 switches.

Pay attention to the behavior of the class â€œclass-defaultâ€​ with the Catalyst QoS. This class works fine in the
3560 switches, matching both IP and non-IP traffic. However, it seems to work inconsistently or does not work at all
with the 3550 switches. In the latter model, as a workaround, create special classes to match either all IP or all
non-IP traffic using IP/MAC ACLs:

ip access-list standard ALL_IP

permit any
!
mac access-list extended ALL_MAC
permit any any 0x0 0xFFFF
!
class-map ALL_IP
match access-group ALL_IP
!
class-map ALL_MAC
match access-group ALL_MAC

Under a class in the policy-map you can either trust (CoS, DSCP, IP Precedence) or set (DSCP, IP Precedence)
the respective QoS marking. Note that you cannot set CoS value directly in the 3560 switches, but you can set
DSCP for non-IP packets. The switch translates DSCP into CoS using the DSCP-to-CoS mapping table. The same
holds true for the 3550 switches â€“ you can set DSCP on the non-IP packets and it is translated to the CoS. Note
the special feature of the 3560 switches: the QoS marking you trust or set is later used to look up the DSCP or
CoS to queue/threshold mapping tables. This is because the 3560 defines two egress mapping tables: one for
DSCP and other for CoS values, based on the complex structure of the QoS label.

In the 3550 switches you can set CoS value directly in one special case. First, you need the global command mls
qos cos policy-map. Using this feature, you must trust DSCP marking and set Layer 2 marking using the set cos
command. This simulates the behavior of â€œCoS pass-throughâ€​ feature available at the interface-level settings.
The set cos feature only works when you trust DSCP. Furthermore, the 3550 performs all QoS processing and
deduces internal DSCP based on the trusted dscp value, not the CoS value set with the policy map.

With both switch models, you can either configure set dscp or set ip precedence but not at the same time, of
course â€“ the one configured later erases the previous one. Also, if a class contains â€​trustâ€​ and â€œsetâ€​
statements for the same type of marking (e.g. L3 or L2) the trust statement takes precedence over explicit set.

Aside from that, trust feature works the same way as it works on the interface but has scope limited to the class
defined by ACL.

Remember that applying a service-policy will remove any interface-level QoS settings on the interface, with
exception to the default CoS (which is used by the policy map when you trust CoS inside a class). If the input
packet doest not match any class in the service-policy, the switch will set all marking to zero. If you trust CoS for IP
or non-IP packets and there is no 802.1q/ISL header the switch will take the default CoS value from the interface
settings or use zero markings.

Tags: 3550, 3560, classification, cos, diff-serv, dscp, marking, mqc

Download this page as a PDF

About Petr Lapukhov, 4xCCIE/CCDE:
Petr Lapukhov's career in IT begain in 1988 w ith a focus on computer programming, and progressed into netw orking
w ith his first exposure to Novell NetWare in 1991. Initially involved w ith Kazan State University's campus netw ork
support and UNIX system administration, he w ent through the path of becoming a netw orking consultant, taking part in
many netw ork deployment projects. Petr currently has over 12 years of experience w orking in the Cisco netw orking
field, and is the only person in the w orld to have obtained four CCIEs in under tw o years, passing each on his first
attempt. Petr is an exceptional case in that he has been w orking w ith all of the technologies covered in his four CCIE
tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing
self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied
Mathematics.
Find all posts by petr | Visit Website

You can leave a response, or trackback from your own site.

7 Responses to “Traffic Classification in the 3550/3560 Switches”
 
October 30, 2008 at 3:26 pm
Joshua Walton

Thanks again for the awesmome post, Petr. As always, you do a wonderful job.

November 13, 2008 at 5:43 am
TheGrave

Mind blowing!!! Another GREAT post Petr, awesome work!

September 7, 2009 at 6:15 pm
Alexei Monastyrnyi

Hey Petr.
Long time no talk to.

I just don’t have any spare switches handy to verify the folowing. What would be a trust behavior on an L3 interface, i.e. with “no
switchport”?

Cheers.

September 7, 2009 at 7:37 pm
Petr Lapukhov, CCIE #16379

Hey Alexey,

AFAIR there is no difference between L3 and L2 ports as far as QoS goes. By default, all incoming packets are untrusted and you
may apply the same “mls qos” commands to the interface for classification/remarking. You cannot, of course, do per-VLAN QoS and
everything L2-based, as the only supported protocol is IP.

September 8, 2009 at 2:41 pm
Alexei Monastyrnyi

Fair enough. Cheers.

February 18, 2010 at 3:23 am
Non-Military Bootcamp

Great post. Very informative. I’ve certainly come away knowing more than i did before.

Great post. Thanks

September 24, 2010 at 3:08 am
Blog Post Catalogue | CCIE Blog

[...] Traffic Classification Options in 3550/3560 switches [...]

Leave a Reply

  Name (required)

  Mail (will not be published) (required)

  Website

Submit Comment

Congratulations Avinash Rai, CCIE Report: Cisco could capitalize on Anthony Sequeira Interview ed

#26766 for passing the CCIE SP Lab increased IT spending: According to http://bit.ly/fK6Mn0
Exam. Share in his success w ith a recent report from Raymond James
twitter.com/inetraining 30% off! http://t.co/zWZQkJ3 & Assoc... http://bit.ly/hYpjgm

© 2010 Internetwork Expert, Inc., All Rights Reserved

pdfcrowd.com