Documente Academic
Documente Profesional
Documente Cultură
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
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
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
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:
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
© 2010 Internetwork Expert, Inc., All Rights Reserved
pdfcrowd.com