Blog Ine Com 2008-10-30 Traffic Classification in the 3550-3560

8/8/2019 Blog Ine Com 2008-10-30 Traffic Classification in the 3550-3560

1/1

pdfcrowd.com

Oct

30 7 CommentsTraffic Classification in the 3550/3560 SwitchesPosted by Petr Lapukhov, 4xCCIE/CCDE in QoS,Switching

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's c areer in IT begain in 1988 w ith a foc us on c omputer 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 sy stem 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 y ears 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 f irst

attempt. Petr is an exc eptional case in that he has been w orking with all of the tec hnologies cov ered 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

Joshua Walton

October 30, 2008 at 3:26 pm

TheGrave

November 13, 2008 at 5:43 am

Alexei Monastyrnyi

September 7, 2009 at 6:15 pm

Petr Lapukhov, CCIE #16379


Alexei Monastyrnyi


Non-Military Bootcamp

February 18, 2010 at 3:23 am

Blog Post Catalogue | CCIE Blog

September 24, 2010 at 3:08 am

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

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.

The Catalyst QoS implementation bases on Differentiated Services model. In a few words, the ideas of this model

could be outlined as follows:

1) Edge nodes classify ingress packets based on local policy and QoS label found in packets.

2) Edge nodes encode traffic classes using a special field (label) in packets to inform other nodes of the

classification decision.

3) Core and edge nodes allocate resources and provide services based on the packet class.

Note that each node acts independently on its own, as instructed by the local policy. In order for the QoS policy to

be consistent end-to-end, the network administrator must ensure that all nodes use the same classification and

resource allocation policy.

The following are the marking types found in IP/Ethernet networks:

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

ways:

1.1) Interpret the topmost six bits of the byte as DSCP code po int. This is in full compliance with Diff-Serv model.

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

numbers form a subspace of DSCP numbers.

2) The CoS bits (three bits) in 802.1q/ISL header of a tagged Ethernet frame. These bits are also known as

802.1p priority bits, and should be interpreted as relative traffic priorities.

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

latter option is only applicable on trunk links.

The Catalyst switches have no special intelligence to implement any of these QoS models by themselves. Its

up to you to define policy and encode classes using any marking you find more suitable for your task. Due to

numerous markings types, Catalyst switches assign a special internal QoS label to all packets and use this label

for internal QoS processing. In the 3550 this label is simply a special internal DSCP value. However, in the

3560 the QoS label format is more complicated, and allows storing either CoS or DSCP information.

Now recall the distinction made by the multilayer switches between IP and non-IP packets. As we know, Layer 3

switches are hardware optimized to route IP or IPv6 packets using their ASICs for optimum performance. This

results in differences of handling the IP and non-IP packets. You may use MAC-based ACLs (matching MACaddresses, Ether-types or LSAPs) only with non-IP packets (e.g. ARP, DECNet, IPX). The MAC ACLs will not match

any of IP packets, even if you specify a matching MAC addresses. Also, note that the 3560 models treats IPv6 as

IP traffic, while the 3550 treats IPv6 packets as non-IP and matches them with MAC ACLs.

QoS processing pipeline

The following diagram displays stages of QoS processing in a typical Catalyst switch.

We are now considering the Classification and Markingstage. 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

with QoS ACLs. The result of classification stage is the internal QoS label (e.g. internal DSCP value with the

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

command show mls qos map.

The switch uses these tables for two major purposes:

a) To synchronize different types of QoS markings present in a packet. For example, if you instruct the

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.

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 maybear 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

cosxcommand for all IP and non-IP packets. Note that this feature only works with CoS values, and the switchdeduces 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 codepoints. 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 switc hes.

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 cl asses 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) o r 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 fornon-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 andset Layer 2 marking using the set cos

command. This simulates the behavior of CoS pass-through feature available at the interface-levelsettings.

The set cos feature only works when you trust DSCP. Furthermore, the 3550 performs all QoS processing and

deduces internal DSCP based on the trusteddscp value, not the CoS value set with the policy map.

With both switch models, you can either configure set dscp orset 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

You can leave a response, ortrackback from your own site.

7 Responses to Traffic Classification in the 3550/3560 Switches

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

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

Hey Petr.

Long time no talk to.

I just dont 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.

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.

Fair enough. Cheers.

Great post. Very informative. Ive certainly come a way knowing mo re than i did be fore.

Great post. Thanks

[...] Traffic Class ification Options in 3550/3560 switches [...]

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website

Submit Comment

visistat

Search

Submit

Categories

Select Category

Current Poll

How did you first hear about

INE?

Friend

Google

Forum/Mailing List

Blog

Facebook/Twitter

Youtube

Other

Vote

View Results

Polls Archive

CCIE Bloggers

Brian Dennis CCIE #2210

Routing & Sw itching

ISP Dial

Security

Service ProviderVoice

Brian McGahan CCIE #8593


Security

Service Provider

Petr Lapukhov CCIE #16379


Security

Service Provider

Voice

Anthony Sequeira CCIE #15626


Mark Snow CCIE #14073

Voice

Security

Josh Finke CCIE #25707

Voice

Bootcamps

November 15 - 19

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

Popular Posts

Understanding Inter-Area Loop

Prevention Caveats in OSPF

Protocol

The EIGRP Composite Metric -

Part 1

Announcing INE's CCDE Practical

Bootcamp

The Basics of EIGRP

Follow Anthony of INE on Tw itter

twitter.com/inetraining

Congratulations Avinash Rai, CCIE

#26766 for passing the CCIE SP Lab

Exam. Share in his suc cess w ith

30% off! http://t.co/zWZQkJ3

Report: Cisco could capitalize on

increased IT spending: According to

a recent report from Raymond James

& Assoc... http://bit.ly/hYpjgm

Anthony Sequeira Interview ed

http://bit.ly/fK6Mn0

Blog Home | INE Home | Members | Contact Us

2010 Internetwork Expert, Inc., All Rights Reserved

Free Resources View Archives Training Products CCIE Bloggers
http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/comment-page-1/#comment-94706http://www.internetworkexpert.com/http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/comment-page-1/#comment-12533http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/comment-page-1/#comment-11110http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/comment-page-1/#comment-11110http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/#respondhttp://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/trackback/http://blog.ine.com/2010/12/25/follow-anthony-ine-twitter/http://blog.ine.com/2010/12/28/announcing-ine-ccde-practical-bootcamp/http://blog.ine.com/2011/01/01/understanding-inter-area-loop-prevention-caveats-ospf-protocol/http://blog.ine.com/2011/01/01/understanding-inter-area-loop-prevention-caveats-ospf-protocol/http://www.ine.com/schedule.htm#RoutingSwitchinghttp://blog.internetworkexpert.com/wp-content/uploads/2008/10/switch-qos-stages.jpghttp://blog.internetworkexpert.com/wp-content/uploads/2008/10/switch-qos-stages.jpghttp://blog.internetworkexpert.com/wp-content/uploads/2008/10/switch-qos-stages.jpghttp://www.ine.com/schedule.htm#RoutingSwitchinghttp://blog.internetworkexpert.com/wp-content/uploads/2008/10/switch-qos-stages.jpghttp://www.ine.com/schedule.htm#RoutingSwitchinghttp://blog.internetworkexpert.com/wp-content/uploads/2008/10/switch-qos-stages.jpghttp://www.ine.com/schedule.htm#RoutingSwitchinghttp://blog.internetworkexpert.com/wp-content/uploads/2008/10/switch-qos-stages.jpghttp://www.ine.com/about-brian-mcgahan.htmhttp://www.ine.com/about-brian-dennis.htmhttp://blog.ine.com/?author=5http://www.ine.com/resources/http://blog.ine.com/archiveshttp://blog.ine.com/training-products/http://www.ine.com/about-instructors.htmhttp://blog.ine.com/http://blog.ine.com/http://blog.ine.com/http://twitter.com/inetraininghttp://t.co/zWZQkJ3http://bit.ly/hYpjgmhttp://pdfcrowd.com/http://blog.ine.com/http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/#commentshttp://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/http://blog.ine.com/?author=5http://blog.ine.com/category/ccie-routing-switching/qos/http://blog.ine.com/category/ccie-routing-switching/switching/http://blog.ine.com/?author=5http://blog.ine.com/?author=5http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/comment-page-1/#comment-11110http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/comment-page-1/#comment-12533http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/comment-page-1/#comment-64680http://www.internetworkexpert.com/http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/comment-page-1/#comment-64683http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/comment-page-1/#comment-64859http://www.bordersbootcamp.com/http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/comment-page-1/#comment-94706http://blog.ine.com/2010/09/21/blog-post-catalogue-2/http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/comment-page-1/#comment-140678http://blog.internetworkexpert.com/wp-content/uploads/2008/10/switch-qos-stages.jpghttp://blog.ine.com/tag/3550/http://blog.ine.com/tag/3560/http://blog.ine.com/tag/classification/http://blog.ine.com/tag/cos/http://blog.ine.com/tag/diff-serv/http://blog.ine.com/tag/dscp/http://blog.ine.com/tag/marking/http://blog.ine.com/tag/mqc/http://pdfcrowd.com/url_to_pdf/?height=-1http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/#respondhttp://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/trackback/http://blog.ine.com/2008/10/30/traffic-classification-in-the-35503560-switches/#ViewPollResultshttp://blog.ine.com/pollsarchivehttp://www.ine.com/about-brian-dennis.htmhttp://www.ine.com/about-brian-mcgahan.htmhttp://www.ine.com/about-petr.htmhttp://www.ine.com/about-anthony-sequeira.htmhttp://www.ine.com/about-mark-snow.htmhttp://www.ine.com/about-josh-finke.htmhttp://www.ine.com/schedule.htm#RoutingSwitchinghttp://www.ine.com/schedule.htm#RoutingSwitchinghttp://www.ine.com/schedule.htm#RoutingSwitchinghttp://blog.ine.com/2011/01/01/understanding-inter-area-loop-prevention-caveats-ospf-protocol/http://blog.ine.com/2010/12/30/eigrp-composite-metric-part-1/http://blog.ine.com/2010/12/28/announcing-ine-ccde-practical-bootcamp/http://blog.ine.com/2011/01/03/basics-eigrp/http://blog.ine.com/2010/12/25/follow-anthony-ine-twitter/http://twitter.com/inetraininghttp://twitter.com/inetraininghttp://t.co/zWZQkJ3http://bit.ly/hYpjgmhttp://bit.ly/fK6Mn0http://twitter.com/inetraininghttp://www.facebook.com/inetraininghttp://www.youtube.com/INEtraininghttp://feeds.feedburner.com/ine/http://www.linkedin.com/companies/144650http://blog.ine.com/http://www.ine.com/http://members.ine.com/http://www.ine.com/contact.htmhttp://feeds.feedburner.com/ine/http://www.ine.com/resources/http://blog.ine.com/archiveshttp://blog.ine.com/training-products/http://www.ine.com/about-instructors.htm

Documents

Blog Ine Com 2008-10-30 Traffic Classification in the 3550-3560