Oct
30

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 point. 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. It’s 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 MAC addresses, 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 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 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 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.

Sep
15

How do you apply most of your QoS mechanisms on a Cisco router? You use the Modular Quality of Service Command Line Interface (MQC). The approach is similar on the PIX/ASA, but the tool does feature some important differences. Also, Cisco has renamed the tool to the Modular Policy Framework. One reason for this is the fact that it is used for more than just QoS. For example, the MPF is also used for application inspection and Intrusion Prevention configurations on the ASA.

The three steps used by MPF are pretty famous at this point. Here they are:

Step 1: Define the traffic flows that you want to manipulate using what is called a Class Map. Do not confuse this with a Map Class that you might remember from Frame Relay configurations. A nice analogy for the Class Map is a bucket that you are pouring the traffic into that you want to manipulate.

Step 2: Take those buckets of traffic from Step 1 and define the particular policy that will apply. The structure used for this is called a Policy Map. An example might be to police Web traffic (defined in a Class Map) to a particular rate.

Step 3: Assign the Policy Map to an interface or all interfaces on the system using what is called a Service Policy.

Let's examine the syntax for these various commands.

pixfirewall(config)# class-map ?
configure mode commands/options:
  WORD < 41 char  class-map name
  type            Specifies the type of class-map

Notice the Class Map syntax includes a type option on the security appliance, the possible types include inspect, management, and regex and represent the variety of configurations the Modular Policy Framework can carry out.

Something else interesting about the Class Map on the security appliance is the fact that there is no options for match-any or match-all. This is because on the security appliance you can only have one match statement. There are exceptions to this, and that is after using either the match tunnel-group or match default-inspection-traffic commands.

Here you can see the match options on the security appliance to fill these buckets of traffic:

pixfirewall(config-cmap)# match ?
mpf-class-map mode commands/options:
  access-list                 Match an Access List
  any                         Match any packet
  default-inspection-traffic  Match default inspection traffic:
  dscp                        Match IP DSCP (DiffServ CodePoints)
  flow                        Flow based Policy
  port                        Match TCP/UDP port(s)
  precedence                  Match IP precedence
  rtp                         Match RTP port numbers
  tunnel-group                Match a Tunnel Group

Obviously, a powerful option is the ability to match on an access list, since this allows matching on very specific criteria, such as well Web traffic requests from a source to a specific destination. Here is an example:

pixfirewall(config)# access-list AL-EXAMPLE permit tcp any host 10.10.10.200 eq www
pixfirewall(config)# class-map CM-EXAMPLE
pixfirewall(config-cmap)# match access-list AL-EXAMPLE

For step 2, we use the Policy Map. There are also types of these components that can be created. Notice that you are not in Policy Map configuration mode long, you switch immediately to Policy Map Class configuration mode to get your configuration complete.

pixfirewall(config)# policy-map PM-EXAMPLE
pixfirewall(config-pmap)# class CM-EXAMPLE
pixfirewall(config-pmap-c)# police output 56000 10500

Here you can see the third strep. The Service Policy applies the Policy Map. You can assign the Policy Map to an interface or all interfaces with the following syntax:

pixfirewall(config)# service-policy PM-EXAMPLE global

Here is a single interface example:

service-policy PM-EXAMPLE interface inside

Notice that a direction is not specified as you would on a router. Notice the direction of policing was actually specified in the Policy Map.

What happens if there is a global policy and an interface policy? Well the interface policy wins out and controls the interface.

The next blog entry on this subject will focus on the priority queuing tool available on the security appliance.

Sep
11

People are often confused with per-VLAN classification, policing and marking features in the Catalyst 3550 and 3560 models. The biggest problem is lack of comprehensive examples in the Documentation CD. Let's quickly review and compare traffic policing features available on both platforms. The material below is a condensed excerpt of several Catalyst QoS topics covered in the “QoS” section of our IEWB VOL1 V5. You will find more in-depth explanations and large number of simulation-based verifications in the upcoming section of the workbook.

Per-Port QoS ACL based classification in the 3550 and 3560

This feature works the same in both switches. Even though it is common to see this method named as “QoS ACLs” classification, it actually uses MQC syntax with class-maps and policy-maps. The term “QoS ACL” comes from the Catalyst OS PFC-based QoS model where you apply QoS ACLs directly to ports. In IOS-based switches, you use the familiar MQC syntax.

Look at the following example. Here we mark IPX packets (classified based on SNAP Protocol ID) with CoS value of 5, ICMP packets with IP Precedence 2 and ICMP packets with DSCP value of 24 (CS3). All remaining traffic, be it IP or non-IP, matches class-default and the system trusts the CoS values in the frame header. If a packet matches “class-default” but has no CoS value in the header, the system uses the default value from the interface, specified with mls qos cos 1

Example 1:

!
! Access-Lists. IPX SNAP Protocol ID is 0x8137
!
mac access-list extended IPX
permit any any 0x8137 0x0
!
ip access-list extended ICMP
permit icmp any any
!
ip access-list extended TELNET
permit tcp any any eq telnet
permit tcp any eq telnet any

!
! Class Maps
!
class-map match-all TELNET
match access-group name TELNET
!
class-map match-all ICMP
match access-group name ICMP
!
class-map match-all IPX
match access-group name IPX

!
! Note that we set DSCP under non-IP traffic class. The switch computes
! the respective CoS value using DSCP-to-CoS table.
!
policy-map CLASSIFY
class IPX
set dscp ef
class ICMP
set dscp cs3
class TELNET
set precedence 2
class class-default
trust cos

!
! Apply the policy
!
interface FastEthernet 0/6
mls qos cos 1
service-policy input CLASSIFY

Note the use of set dscp command on non-IP packet. You cannot set CoS value directly, with one special case for the 3550 switches. Therefore, you should use the command set dscp for both IP and non-IP packets if you want to change the CoS field.

You may apply the same policy in the 3550 models, but with one special limitation. The “class-default” should be split into two user-defined classes matching IP and non-IP traffic. I never seen "class-default" working properly in the 3550 models, so if you have a working example with verifications, please let me know :). Here is a workaround, that shows how to police both IP and non-IP traffic simultaneously in the 3550 model:

Example 2:

!
! All IP traffic
!
ip access-list standard IP_ANY
permit any
!
! All non-IP traffic
!
mac access-list extended MAC_ANY
permit any any 0x0 0xFFFF
!
class-map IP_ANY
match access-group name IP_ANY
!
class-map MAC_ANY
match access-group name MAC_ANY
!
mls qos aggregate-policer AGG256 256000 32000 exceed-action drop
!
policy-map AGGREGATE_LIMIT
class IP_ANY
police aggregate AGG256
class MAC_ANY
police aggregate AGG256

Per-Port Per-VLAN Classification in the 3550 switches

This feature is unique to the 3550 switches. You may configure traffic classification that takes in account VLAN for input traffic. Unfortunately, you can only apply it at a port-level. There is no option to classify the traffic entering VLANs on any port using a single policy, like there is in the 3560 model. Note that you can apply per-port per-VLAN policy on a trunk or an access port. Of course, in this case the access port must be in a VLAN matched by the policy-map. Here is an example of per-VLAN classification and marking in the 3550 models. What it does, is sets different DSCP and CoS values for IPX and ICMP packets coming from VLAN146 only. Other VLANs on a trunk port will remain intact.

Example 3:

mls qos
!
! Acess-Lists
!
ip access-list extended ICMP
permit icmp any any
!
mac access-list extended IPX
permit any any 0x8137 0x0

!
! Second-level class-maps
!
class-map ICMP
match access-group name ICMP
!
class-map IPX
match access-group name IPX

!
! First-level class-maps
!
class-map VLAN_146_ICMP
match vlan 146
match class-map ICMP
!
class-map VLAN_146_IPX
match vlan 146
match class-map IPX

!
! Policy-maps. Note that we set DSCP for IPX packets
! In fact, this is the internal DSCP value, not the IP DSCP.
! You cannot set CoS directly – only when trusting DSCP.
! DSCP 16 translates to CoS 2 by the virtue of the
! default DSCP-to-CoS table.
!
policy-map PER_PORT_PER_VLAN
class VLAN_146_ICMP
set dscp CS3
class VLAN_146_IPX
set dscp 16

!
! Apply the policy-map
!
interface FastEthernet 0/4
service-policy input PER_PORT_PER_VLAN

Note the special syntax used by this features. All classes in the policy-map must use match vlan statement on their first line and match another class in their second line. The second-level class-map should use only one statement, e.g. match access-group name. The access-group itself may have variable number of entries.

Per-Port Per-VLAN Policing in the 3550

The following example is just a demonstration of applying policing inside VLAN-based policy-map in the 3550. This feature is a regular policer, just the same you can use in a per-port policy-map. You can either drop packet or re-mark the internal DSCP. With the 3550 it is even possible to use aggregate policer shared between several VLANs on a single port.

The example remarks IP traffic exceeding the rate of 128Kbps with DSCP value of CS1. Prior to metering, the policy map marks traffic with AF11. The policy map marks non-IP traffic with a CoS value of three, and drops packets that exceed 256Kbps. All classification and policing procedures apply only to packets in VLAN146.

Example 4:

mls qos
mls qos map policed-dscp 10 to 8

!
! Acess-Lists
!
ip access-list extended IP_ANY
permit IP any any
!
mac access-list extended NON_IP_ANY
permit any any 0x0 0xFFFF

!
! Second-level class-maps
!
class-map IP_ANY
match access-group name IP_ANY
!
class-map NON_IP_ANY
match access-group name NON_IP_ANY

!
! First-level class-maps
!
class-map VLAN_146_IP
match vlan 146
match class-map IP_ANY
!
class-map VLAN_146_NON_IP
match vlan 146
match class-map NON_IP_ANY

!
! Since we are not limited, we use any burst values
! Policy map matches first-level class-maps
!
policy-map POLICE_PER_PORT_PER_VLAN
class VLAN_146_IP
set dscp af11
police 128000 16000 exceed-action policed-dscp-transmit
class VLAN_146_NON_IP
set dscp cs3
police 256000 32000

!
! Apply the policy-map
!
interface FastEthernet 0/4
service-policy input POLICE_PER_PORT_PER_VLAN

Per-VLAN Classification in the 3560

Switch-wide per-VLAN classification is feature specific to the 3560. You can apply a service-policy to SVI, listing class-map and respective mark actions in the policy-map. Note that you cannot usethe police command in a service-policy applied to SVI. All packets in the respective VLAN entering the switch on the ports enabled for VLAN-based QoS are subject to inspection by service-policy on the SVI. The effect is that QoS marking policy is now switch-wide on all ports (trunks or access) having the respective VLAN activated (allowed and STP forwarding state).

The following example sets DSCP EF in the TCP packets entering VLAN146 and CoS 4 in the IPX packet transiting the switch across VLAN 146. Note that all ports with VLAN146 that are configured for VLAN QoS will be affected by this configuration.

Example 5:

mls qos
!
! Enable VLAN-based QoS on interfaces
!
interface FastEthernet 0/1
mls qos vlan-based

!
! Enable VLAN-based QoS on the trunks
!
interface range FastEthernet 0/13 - 21
mls qos vlan-based

!
! Access-Lists
!
ip access-list extended TCP
permit tcp any any
!
mac access-list extended IPX
permit any any 0x8137 0x0

!
! First-level class-maps
!
class-map TCP
match access-group name TCP
!
class-map IPX
match access-group name IPX

!
! VLAN-based policy-map
!
policy-map PER_VLAN
class TCP
set dscp ef
class IPX
set dscp 32

!
! Apply the policy-map to SVI
!
interface VLAN 146
service-policy input PER_VLAN

As mentioned above, you cannot use policing in SVI-level policy map. This eliminates the possibility of having policer aggregating traffic rates for all ports in a single VLAN. However, you can still police per-port per-VLAN in the 3560 using the following feature.

Per-Port Per-VLAN Policing in the 3560

This feature uses second-level policy-maps. The second-level policy-map must list class-maps satisfying specific restrictions. The only “match” criterion supported in those class-maps is match input-interface. You can list several interfaces separated by spaces, or use interface ranges, separating interfaces in a range by hyphen. The only action supported in the second-level policy-map is the police command. As usual, you can drop exceeding traffic or configure traffic remarking using policed DSCP map. The police action applies individually to every port in the range.

You cannot use aggregate policers in the second-level policy-maps. Another restriction – if you apply a second-level policy-map (interface-level map) inside “class-default” it will have no effect. You need to apply the second-level policy-map inside user-defined classes.

The following example restricts IP traffic rate in VLAN146 on every trunk port to 128Kbps and limits the IP traffic in VLAN146 on the port connected to R6 to 256Kbps.

Example 6:

mls qos map policed-dscp 18 to 8

!
! For 2nd level policy you can only match input interfaces
!
class-map TRUNKS
match input-interface FastEthernet 0/13 - FastEthernet 0/21

!
! The second class-map matches a group of ports or a single port
!
class-map PORT_TO_R6
match input-interface FastEthernet 0/6

!
! IP traffic: ACL and class-map
!
ip access-list extended IP_ANY
permit ip any any
!
class-map IP_ANY
match access-group name IP_ANY

!
! Second-level policy-map may only police, but not mark
!
policy-map INTERFACE_POLICY
class TRUNKS
police 128000 16000 exceed policed-dscp-transmit
class PORT_TO_R6
police 256000 32000

!
! 1st level policy-map may only mark, not police
! VAN aggregate policing is not possible in the 3560
!
policy-map VLAN_POLICY
class IP_ANY
set dscp af21
service-policy INTERFACE_POLICY
!
interface Vlan 146
service-policy input VLAN_POLICY

!
! Enable VLAN-based QoS on the ports
!
interface FastEthernet 0/6
mls qos vlan-based

!
! Enable VLAN-based QoS
!
interface range FastEthernet 0/13 - 21
mls qos vlan-based

This is it for the comparison of most common policing features on the 3550 and 3560 platforms. Digging deeper in the areas of Catalyst QoS would probably takes us far beyond the size of a post the a normal human can read :)

Feb
23

QoS features available on Catalyst switch platforms have specific limitations, dictated by the hardware design of modern L3 switches, which is heavily optimized to handle packets at very high rates. Catalyst switch QoS is implemented using TCAM (Ternary Content Addressable Tables) - fast hardware lookup tables - to store all QoS configurations and settings. We start out Catalyst QoS overview with the old, long time available in the CCIE lab, the Catalyst 3550 model.


To begin with, the Catalyst 3550 sees the world as consisting of IP and non-IP (e.g. ARP, IPv6, IPX) packets – the distinction being made based on the Ethertype value in incoming Ethernet frame. This peculiarity is due to the fact that 3550 is a Layer 3 switch, designed to route IP packets in addition to the regular L2 switching. The feature has some impact on QoS classification options of 3550 as we shall see later.

The Catalyst 3550 QoS model is based on Diff-Serv architecture, where each packet is classified and marked, to encode the class value. Packets are given a per-hop treatment at every network node, based on their class (marking). With Diff-Serv architecture, classification and admission control are performed at network (Diff-Serv domain) edges, while network core is used to implement the QoS procedures based on packet classes.

The Catalyst 3550 is capable of performing either Diff-Serv boundary device functions (classification, marking & admission control) or Diff-Serv interior device functions (e.g. queueing & scheduling). Catalyst 3550 understands the following types of marking: 802.1p priority bits (available on trunk ports only) and IP ToS byte (IP packets only) – the latter could be interpreted as either DSCP (64 values) or IP Precedence (8 values). While IP Precedence and DSCP values are naturally applicable to IP packets, CoS is the only possible “transit” (inter-switch) marking available to non-IP packets (in the sense 3550 interprets them).

One may ask, why is the difference between IP Precedence and DSCP when the former seems to be a subset of DSCP classes space? Actually it is true – IP Precedence value x numerically maps directly to CSx under DSCP nomenclature. However, the semantics of IPP and DSCP are different. If we interpret packets under the “Precedence” model (which is old, military based QoS model – Internet begun as a military project, remember?) we should treat it differently then if we were interpreting it under the CSx class of Diff-Serv model. This is why IP Precedence and DSCP marking are usually considered separately.

To finish with marking, keep in mind, that IP packet may come in with both CoS (taken from dot1q/ISL header) and DSCP/IP Precedence values set. Therefore, a Catalyst switch needs a way to handle both markings at the same time. (We’ll discuss this feature in more details later). (Side-note: QoS features on 3550 switch are enabled with the global mls qos command. As soon as you entered this command, all classification settings are set to their default values, and in effect all packets traversing the switch will have their CoS and DSCP values set to zero)

Now, the QoS flowchart for the 3550 Catalyst switch looks as follows:

Stage 1 (Ingress): Classify, Police & Mark.

The goal of this stage is to mark a packet - deduce an internal DSCP value for whatever type of packet (IP or non-IP) has arrived. (Note that we may consider “drop action” as a special kind of “marking” too). Internal DSCP is “unified” marking scheme used inside the switch to perform any QoS-related processing. To deduce the internal DSCP value for non-IP packets (e.g. IPv6), which could only be marked using the CoS field, a special configurable (switch-global) CoS to DSCP translation table is used. This table is applied whether we use CoS to classify an incoming packet, be it IP or non-IP - more on that later.

For IP packets, the new internal DSCP value replaces the original DSCP field in a packet. For non-IP packets, new CoS value is calculated for packets from the internal DSCP using a configurable DSCP to CoS table (which is global to a switch). The latter table is also used on the scheduling stage, to determine egress Queue-ID.

Specifically, to classify non-IP packets a Catalyst switch may either:

a) Trust the CoS value from incoming frame on a trunk link (keep the CoS value encoded in a frame). This option is only applicable to trunk links. (You may consider voice VLAN dot1p option as a rudimentary trunk also).

b) Use the default CoS value assigned to a port. This action is used when no CoS value is present in incoming packet and you configure to trust CoS .You may use this option on either access or trunk links (e.g. 802.1q native VLAN). The default “CoS default” value is zero. You may set it with mls qos cos interface-level command.

A few words on “CoS override mode”. When you configure mls qos cos X override under interface, all packets entering the interfaces are assigned this CoS value, irrespective of any other QoS settings (e.g. trust states). Use this command to quickly assign a “precedence” level to all packets entering an interfaces.

c) Classify and assign CoS value based on QoS ACLs. You may configure and apply QoS ACL (actually, it’s just a regular ACL) using an ingress policy-map on 3550 switch. Packets matching the ACL are then either trusted, assigned CoS value manually, and/or policed. For non-IP packets you may only use MAC extended access-lists for classification. Note that due to 3550 “blindness” you may only use MAC ACLs to classify only the non-IP packets – MAC ACLs won’t work with the IP packets!

After the CoS value has been deduced for non-IP packet, it is then translated into internal DSCP value by using the configurable CoS to DSCP table. Here is an example:

!
! CoS -> DSCP mapping table, define 8 DSCP values here (CoS 0..7)
!
mls qos map cos-dscp 16 8 16 24 32 46 48 56

!
! MAC access-list to match ARP (non IP) packets
!
mac access-list extended ARP
permit any any 0x806 0x0
!
class-map ARP
match access-group name ARP

!
! Assign CoS 3 to ARP packets and police
!
policy-map CLASSIFY
class ARP
set cos 3

!
! Attach service-policy ingress
!
interface FastEthernet 0/4
mls qos trust cos
service-policy input CLASSIFY
mls qos cos 1

More classification options are available for IP packets. First, as mentioned above, an IP packet may arrive encapsulated in Ethernet frame with dot1q or ISL header. That means we may obtain the current marking either from CoS or IP Precedence/DSCP bits. Here is a full list:

a) Trust CoS value for an incoming packet. The CoS to DSCP translation table is then used to deduce the internal DSCP value. You may optionally configure special DSCP pass-through mode with the mls qos trust cos pass-through dscp command. When this mode is active, internal DSCP value is deduced from the CoS field, and all QoS operations are based on it. However, the original DSCP value in packet is not getting overwritten with the new DSCP deduced from CoS field. This feature also works backwards: you may trust DSCP value for an IP packet (discussed later) and leave CoS value untouched, passing it transparently.

b) Use the default CoS value assigned to a port. This option only works if you configure to trust CoS and CoS value is not present in the incoming packet.

c) Trust IP Precedence. Takes the IP Precedence field from the IP packet header, and convert it to internal DSCP value using the configurable IP Precedence to DSCP mapping table. This is pretty straightforward.

d) Trust DSCP value. The DSCP value from an IP packet header is retained and used as internal DSCP. As mentioned above, you may disable CoS rewrite according to DSCP to CoS tables by issuing global-mode command mls qos trust dscp pass-through cos.

d) Use QoS ACLs for classification. You may use standard or extended IP access-list to match incoming packets by applying them with MQC class-maps and policy-maps. Matched packets could be trusted, marked and/or policed. Note that due to TCAM capacity limits you may not be able to fit arbitrary large QoS ACL into hardware.

e) IP packets that did not fall under any of the previous classification options are assigned the DSCP value of zero (best-effort traffic).

!
! IP extended ACL to match ICMP traffic
!
ip access-list extended ICMP
permit icmp any any
!
class-map ICMP
match access-group ICMP

!
! TCP traffic
!
ip access-list extended TCP
permit tcp any any
!
class-map TCP
match access-group TCP

policy-map CLASSIFY
!
! Classification combined with policing
!
class ICMP
set ip dscp 26
police 64000 8000
class TCP
trust ip-precedence

!
! Attach service-policy ingress
!
interface FastEthernet 0/4
mls qos trust dscp
service-policy input CLASSIFY
mls qos cos 1

Ingress Policing

Catalyst 3550 switches allow to apply ingress policing to various traffic classes, using DSCP values or IP/MAC ACLs to classify traffic (the latter option is the only one available to non-IP packets). Policing could be combined with marking, by using the MQC policy-maps syntax (set command). You may apply up to 8 ingress policers on any port and up to 8 egress policers. Note, that egress policers support only DSCP-based classification. On GigabitEtherner interfaces number of ingress policers is bigger, but still limited to 128.

A policer in Catalyst 3550 is defined by its average rate, burst size and exceed action. The larger is the burst size, the more tolerable is policer to accident traffic rate “spikes”. No formula exists for optimal burst size - it’s usually calculated basic on empirical results. However, a common recommendation is to configure the burst size to no less than AverageRate*1,5s bytes, since this parameter is suitable for heavy TCP traffic flows (avoids excessive drops and TCP slow-start behavior). Due to the fact that policers are implemented in hardware, you may find that IOS rounds up your burst size to a value more suited for ASIC based implementation.

Exceed actions include drop and markdown (policed DSCP transmit). When you apply a markdown action under a policer, a special global configurable table is used to map an internal DSCP to it’s policed equivalent. E.g. you may want to police down exceeding user traffic from CS0 (e.g. best-effort) to CS1 (e.g. Scavenger). Default markdown settings are to keep DSCP values the same.

Policer could be of two types – individual or aggregate. Individual policer is configured under a class-map assigned under a policy map, and applies only to a single traffic class. Aggregate policers are defined globally, using special command syntax, and shared among multiple classes, configured under a policy map attached to an interface. That is, traffic under all classes configured to share an aggregate policer is policed under the same policer settings. Note that you can’t share an aggregate policer among different ports.

!
! Global markdown configuration
!
mls qos map policed-dscp 0 46 to 1
!
ip access-list extended ICMP_4
permit icmp any host 150.15.4.4
!
ip access-list extended ICMP_44
permit icmp any host 150.15.44.44
!
class-map ICMP_4
match access-group name ICMP_4
!
class-map ICMP_44
match access-group name ICMP_44
!
!
!
mls qos aggregate-policer AGG1 16000 8000 exceed-action policed-dscp

!
! Set the default DSCP to 0, remark to CS1 on exceed
!
policy-map INGRESS_R3
class ICMP_4
set ip dscp 0
police aggregate AGG1
class ICMP_44
set ip dscp 0
police aggregate AGG1

Per-Port Per-VLAN (PPPV) classification

The classification options we considered so far are “port-wise” - i.e. they apply to all traffic arriving on a port, whether it is trunk or access link. However, 3550 switches have special feature called per-por per-VLAN classification, which allows applying a QoS ACL classification method on a per-VLAN basic to a specific port.

PPPV requires a very strict syntax for its configuration. Failing to obey the order of operations will result in non-working and rejected configuration. First, you need to define a class-map to match traffic “inside” a VLAN. This class-map could be based on an IP/MAC ACL or simply match a range of DSCP values. For example:

class-map VOICE_BEARER
match ip dscp ef

Next you create a second, “parent” class-map, that matches a specific VLAN or VLAN range. The first entry under this class-map must be a match vlan statement. The second (and the last entry) should be match class-map entry, that matches traffic “inside” a VLAN or VLAN range:

class-map match-all VLAN_34_VOICE
match vlan 34
match class-map VOICE_BEARER

You then assign the “parent” classes to a policy-map. Note that all classes under this policy-map must contain match vlan as their first entry, and match class-map as their second entry.

class-map SCAVENGER
match ip dscp 1
!
class-map VLAN_43_SCAVENGER
match vlan 43
match class-map SCAVENGER

!
! Per VLAN policy-map
!
policy-map PER_VLAN_POLICY
class VLAN_34_VOICE
police 128000 32000 exceed policed-dscp
class VLAN_43_SCAVENGER
police 64000 16000 exceed drop

interface FastEthernet 0/3
service-policy input PER_VLAN_POLICY

Stage 2 (Egress): Police, Queue & Schedule

Packets arrive on egress with internal DSCP value assigned. Note that security ACL are matched against the original DSCP value, not the one imposed by classification process – this is due to the fact that QoS and Security ACLS are looked up through TCAM in parallel. Therefore VLAN access-map may block your packet based on it’s DSCP original value, no the one assigned by QoS ACLs. So now that packet has arrived to output port, 3550 performs the following:

a) Police traffic stream, based on DSCP value solely. No other classification option exists for egress policers. Note that you are allowed to mix ingress and egress policers on the same interface.

class-map SCAVENGER
match ip dscp 1
!
policy-map POLICE_SCAVENGER
class SCAVENGER
police 64000 8000
!
interface FastEthernet 0/3
service-policy output POLICE_SCAVENGER

b) Assign a packet to an output queue. 3550 defines 4 output queues (IDs from 1 to 4) for each interface, and packets are assigned to a queue using CoS to Queue-ID interface-level mapping table. Since packet handling is based on internal DSCP value, this value should be mapped to a CoS value, using yet another mapping table (this time global), called DSCP to CoS mapping table (there exists a default mapping, of course). Therefore, to assign a packet to an output queue, two lookups are made: DSCP->CoS & CoS->Queue-ID.

!
! DSCP->CoS global mapping table
!
mls qos map dscp-cos 56 4
!
interface FastEthernet 0/3
!
! CoS to Queue-ID mappings
!
wrr-queue cos-map 1 0 1
wrr-queue cos-map 2 2
wrr-queue cos-map 3 3 6 7
wrr-queue cos-map 4 5

Next, a check is performed to see if a selected queue has enough buffer space to accommodate another packet. If no space is available, packet is dropped. Buffer space is allocated to queues in the following manner:

For FastEthernet ports, you may configure up to 8 global levels - each level has a numeric value assigned, representing the number of packets allowed on a queue. You may then assign a level to a queue-id on per-interface basis. This limits the per-port flexibility, but is more optimized for hardware handling. The default assignment of levels to queue-ids is 1-4 to 1-4.

mls qos min-reserve 1 170
!
interface FastEthernet 0/3
wrr-queue min-reserve 1 4
wrr-queue min-reserve 2 3
wrr-queue min-reserve 3 2
wrr-queue min-reserve 4 1

For GigabitEthernet interface, you may configure the queue sizes directly under the interface configuration mode - no global levels need to be referenced. Simply specify how you want to divide the buffer pool of the gigabit port among the queues, by assigning each queue a relative weight value (not an absolute count of packets in queue!).

interface GigabitEthernet 0/1
wrr-queue queue-limit 20 20 20 40

Packet drop procedure is not as simple as it may seems like. First, for FastEthernet interfaces you are only limited to a simple tail-drop, where the last packet not fitting in a queue is dropped. However, 3550 makes this simple algorithm more flexible – you are allowed to configure to start dropping packets before the queue is actually full. For every queue, it is possible to assign two thresholds – in percents of queue size. If the current queue size exceeds the threshold, new packets are dropped. Why two thresholds? To introduce yet another mapping table! Yes, you can map internal DSCP values to queue-size thresholds – within the interfaces scope - for all queue-ids simultaneously.

This way, you may configure to start dropping “unimportant” packets sooner, say when queue is 80% full, and drop important packets only when the queue is absolutely 100% full (remember you have 64 DSCP classes and just 4 queues - you cant guarantee a queue to every class!). This differentiated drop behavior is actually required per the Diff-Serv model, allowing implementing of different drop precedence for different classes.

interface FastEthernet 0/3
!
! wrr-queue threshold queue-id thresh1% thresh2%
!
wrr-queue threshold 1 80 100
wrr-queue threshold 2 80 100
wrr-queue threshold 3 50 100
!
! wrr-queue dscp-map threshold-id dscp1, … , dscp8
!
wrr-queue dscp-map 2 46 56 48
wrr-queue dscp-map 1 0 8 16 24 34

By default, all DSCP values are mapped to threshold 1 and the threshold value is set to 100% of queue size.

For GigabitEthernet intrefaces (uplinks), you may use the same tail-drop procedure, or configure more advanced WRED (Weighted Random Early Detection) as drop policy. Describing WRED in details is beyond the scope of this document, but in short, it allows starting packet drops randomly, before the queue size reaches the configured threshold. This random behavior is specifically designed to overcome TCP over congestion and synchronization problems on loaded links. As with the tail-drop behavior, you may configure two WRED thresholds for each queue, and then map DSCP values to each threshold on per-interface basis. Packet drop probability increases as the queue size reaches the configured threshold.

interface GigabitEthernet 0/1
!
! wrr-queue random max-thresh queue-id thresh1% thresh2%
!
wrr-queue random-detect max-threshold 1 80 100
wrr-queue random-detect max-threshold 2 70 100
wrr-queue random-detect max-threshold 3 70 100
wrr-queue dscp-map 2 46 56 48
wrr-queue dscp-map 1 0 8 16 24 34

c) Schedule/services packets on queue. Now that the packet has been queued, all the interfaces queues are serviced in a round-robin fashion, which is the simplest approximation to the “ideal” GPS (Generalized Processor Sharing) algorithm. The reason to choose such simple scheduler is the need for wire-speed latency of hardware packet switching. You just can’t implement WFQ or CBWFQ effectively for high-density port devices like a L3 switches due to the algorithms higher complexity. However, the scheduler used is not that primitive. Rather, it uses weighted round robin (WRR) to service interface queues. That means, you can assign up to four weights, one to each of the queues, and the scheduler will then service the queues in accordance to their weights.

Say if you assigned weigh values “10 20 30 40” to queues 1, 2, 3 and 4 then every round scheduler will take up to 10 packets from queue 1, no more than 20 packets from queue 2 etc. This way, all queues are services in a very effective manner, which still allows implementing Assured Forwarding behavior per the Diff-Serv model requirements. Note, that WRR does not limit the upper bound of packet rates – it only ensures it queue is services proportional to it’s weight, when interface is heavily congested. Under normal conditions, a queue could claim more bandwidth, than it’s configured by the use of it’s weight. The default weight values are 25 25 25 25. Side Note: The WRR description given here is not the classic WRR algorithm; the latter requires the average packet size for each queue to be known in ahead, in order to adjust weights and provide fairness. Therefore, per the DocCD description, we may assume that scheduling implemented is not the classic WRR, but rather a simplified form of it.

interface FastEthernet 0/3
wrr-queue bandwdith 10 20 30 40

The last component to interface queue scheduler is priority queue. With each interface, you may configure queue-id 4 to be treated as priority. This means, whether you have any packets on queue-id 4, this queue is always empties first, no matter how many packets are there. Only then the regular WRR queues gets services. Expedite (priority) queue is enabled with priority-queue out command at inerface level:

interface FastEthernet 0/3
!
! With PQ enabled, you may assign any weight to queue-id 4
!
wrr-queue bandwdith 10 20 30 1
priority-queue out

Note that when you have priority-queue enabled, you may configure any WRR weigth for this queue-id (4) – it is not taken in account when servicing WRR queues.

Basically, these are all the important details about 3550 QoS. We did not mention things like DSCP mutations maps, and some other minor features. However, the entire core QoS processing has been described and, hopefully, been made clear to a reader.

Further Reading
Understanding QoS Policing and Marking on the Catalyst 3350

Illustration

Consider the following test topology:

Cat3550-QoS

With the next example we will classify three traffic types on a single port: RIP updates, ICMP packets and IPv6 traffic. We will use policy-map to assign the IP precedence and CoS values to the packets accordingly.

SW3:
ip access-list extended RIP
permit udp any any eq 520
!
ip access-list extended ICMP
permit icmp any any

!
! IPv6 Ethertype is 0x86DD
!
mac access-list extended IPV6
permit any any 0x86DD 0x0

class-map RIP
match access-group name RIP
!
class-map ICMP
match access-group name ICMP
!
class-map VOICE
match ip dscp ef
!
class-map IPV6
match access-group name IPV6

!
! Classify and police ingress traffic on the link to R3
!
policy-map CLASSIFY
class RIP
set ip precedence 3
class ICMP
set ip precedence 4
police 32000 8000 exceed drop
class IPV6
set cos 5
police 32000 8000 exceed drop
!
mls qos map cos-dscp 0 8 16 24 32 46 48 56
!
!
interface FastEthernet 0/3
service-policy input CLASSIFY

Verification: Create an access-list on R4 to match the IP packets

R4:
no ip access-list extended MONITOR_34
ip access-list extended MONITOR_34
permit udp any any eq 520 precedence 3
permit icmp any any precedence 4
permit ip any any
!
interface FastEthernet 0/1.34
ip access-group MONITOR_34 in

Send ICMP packet at a rate enough to kick in the policer exceed action:

Rack15R3#ping 155.15.34.4 repeat 50 size 1000
Type escape sequence to abort.
Sending 50, 1000-byte ICMP Echos to 155.15.34.4, timeout is 2 seconds:
!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!
Success rate is 90 percent (45/50), round-trip min/avg/max = 4/4/9 ms

And verify the access-list at R4:

Rack15R4#show ip access-lists MONITOR_34
Extended IP access list MONITOR_34
10 permit udp any any eq rip precedence flash (18 matches)
20 permit icmp any any precedence flash-override (135 matches)
30 permit ip any any (9 matches)

To check if IPv6 packets are matched by MAC access-list, send highly saturated stream of ICMPv6 echo packets to R4:

Rack15R3#ping 2001:0:0:34::4 repeat 50 size 1000 timeout 1
Type escape sequence to abort.
Sending 50, 1000-byte ICMP Echos to 2001:0:0:34::4, timeout is 1 seconds:
!!!!!!!!!.!!!!.!!!!.!!!!.!!!!.!!!!.!!!!.!!!!.!!!!.
Success rate is 82 percent (41/50), round-trip min/avg/max = 4/7/8 ms
Jan
24

This is a "modern" way to configure FRTS, using MQC commands only to accomplish the task. With MQC approach, an unified interface has been introduced to configure all QoS settings, irrelevant of underlying technology.

In summary:

- Legacy command frame-relay traffic-shaping is incompatible with MQC-based FRTS (you can't mix them)
- Fancy queueing could not be used as a PVC-queueing strategy: CBWFQ is the only option available
- Per-VC CBWFQ is configured via hierarchical policy-maps configuration: Parent policy sets shaping values, while child policy implements CBWFQ
- You may apply policy-map per-interface (subinterface) or per-VC, using match fr-dlci under class-map submode

Example: Shape PVC to 384Kbps and provide LLQ treatment for voice bearer packets on PVC queue

class-map VOICE
match ip dscp ef
!
class-map DATA
match ip dscp cs1

!
! "Child" policy-map, used to implement CBWFQ
!

policy-map CBWFQ
class VOICE
priority 64
class DATA
bandwidth 128
class class-default
fair-queue

!
! "Parent" policy map, used for PVC shaping
!

policy-map SHAPE_384K
class class-default
shape average 384000
shape adaptive 192000
service-policy CBWFQ

interface Serial 0/0/0:0.1
ip address 177.0.112.1 255.255.255.0
service-policy output SHAPE_384K
frame-relay interface-dlci 112

Verification: check out policy map settings

Rack1R1#show policy-map interface serial 0/0/0:0.1

Serial0/0/0:0.1

Service-policy output: SHAPE_384K

Class-map: class-default (match-any)
1942 packets, 1590741 bytes
5 minute offered rate 48000 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
384000/384000 2400 9600 9600 25 1200

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 1936 1581717 0 0 no

Service-policy : CBWFQ

Class-map: VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol rtp
Match: ip dscp ef (46)
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 64 (kbps) Burst 1600 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0

Class-map: DATA (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs1 (8)
Queueing
Output Queue: Conversation 41
Bandwidth 128 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)
1942 packets, 1590741 bytes
5 minute offered rate 48000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 32
(total queued/total drops/no-buffer drops) 0/0/0

The amount of bandwidth, available for allocation to CBWFQ classes, is taken from shape adaptive value. If the latter is not configured, shape average
value is used instead. Note, that as you configure bandwidth settings for classes, their values are not subtracted from remaining bandwidth. This is in contraty with
"classic" CBWFQ, applied to a physical interface (not subinterface or PVC)

Verification (with the example above):

Rack1R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R1(config)#policy-map CBWFQ
Rack1R1(config-pmap)#class class-default
Rack1R1(config-pmap-c)#no fair-queue
Rack1R1(config-pmap-c)#bandwidth 256
I/f shape class class-default requested bandwidth 256 (kbps), available only 192 (kbps)

Note that available bandwidth is set to shape adaptive value, even though we have priority configured under class VOICE and bandwidth
settings under class DATA

- You can't apply FRF.12 fragmentation with MQC commands - it should be applied at physical interface level. By doing so, FRF.12 is effectively enabled for all PVCs
- Physical interface queue could be set to any of WFQ/CQ/PQ or CBWFQ (not restricted to FIFO as with FRTS legacy) - though this is rarely needed

Example: Shape PVC DLCI 112 to 384Kpbs and enable FRF.12 fragmentation for all PVCs

class-map VOICE
match ip dscp ef
!
class-map DATA
match ip dscp cs1

!
! Match the specific DLCI
!
class-map DLCI_112
match fr-dlci 112

!
! "Child" policy-map, used to implement CBWFQ
!

policy-map CBWFQ
class VOICE
priority 64
class DATA
bandwidth 128
class class-default
fair-queue

!
! "Parent" policy map, used for PVC shaping
! With multiple classes, we can match different DLCIs
! all at the same physical interface (where they belongs)
!

policy-map INTERFACE_POLICY
class DLCI_112
shape average 384000
shape adaptive 192000
service-policy CBWFQ

!
! Apply the parent policy map at physical interface level
! Also, configure FRF.12 "global" settings here
!

interface Serial 0/0/0:0
service-policy output INTERFACE_POLICY
frame-relay fragment 640 end-to-end

Verification:

Rack1R1#show policy-map interface serial 0/0/0:0

Serial0/0/0:0

Service-policy output: INTERFACE_POLICY

Class-map: DLCI_112 (match-all)
1040 packets, 95287 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: fr-dlci 112
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
384000/384000 2400 9600 9600 25 1200

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 1040 95287 4 1373 no

Service-policy : CBWFQ

Class-map: VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol rtp
Match: ip dscp ef (46)
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 64 (kbps) Burst 1600 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0

Class-map: DATA (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs1 (8)
Match: fr-dlci 112
Queueing
Output Queue: Conversation 41
Bandwidth 128 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)
1040 packets, 95287 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 32
(total queued/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)
2594 packets, 153695 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

Verify fragmentation settings:

Rack1R1#show interface serial 0/0/0:0
Serial0/0/0:0 is up, line protocol is up
Hardware is GT96K Serial
MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)
LMI enq sent 21224, LMI stat recvd 21224, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
FR SVC disabled, LAPF state down
Fragmentation type: end-to-end, size 640, PQ interleaves 0 <--------- Fragment Size
Broadcast queue 0/64, broadcasts sent/dropped 63160/0, interface broadcasts 56080
Last input 00:00:03, output 00:00:02, output hang never
Last clearing of "show interface" counters 2d10h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 6
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1152 kilobits/sec
5 minute input rate 0 bits/sec, 1 packets/sec
5 minute output rate 0 bits/sec, 1 packets/sec
272202 packets input, 27557680 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
15 input errors, 15 CRC, 8 frame, 0 overrun, 0 ignored, 5 abort
333676 packets output, 42152431 bytes, 0 underruns
0 output errors, 0 collisions, 16 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags

Jan
22

This is the most well-known FRTS method, which has been available for quite a while on Cisco routers. It is now being outdated by MQC configurations.
The key characteristic is that all settings are configured under map-class command mode, and later are applied to a particular set PVCs. The
same configuration concept was used for legacy ATM configuration mode (map-class atm).

Legacy FRTS has the following characteristics:

- Enabled with frame-relay traffic-shaping command at physical interface level
- Incompatible with GTS or MQC commands at subinterfaces or physical interface levels
- With FRTS you can enforce bitrate per-VC (VC-granular, unlike GTS), by applying a map-class to PVC
- When no map-class is explicitly applied to PVC, it's CIR and Tc are set to 56K/125ms by default
- Shaping parameters are configured under map-class frame-relay configuration submode
- Allows to configure fancy-queueing (WFQ/PQ/CQ) or simple FIFO per-VC
- No option to configure fancy-queueing at interface level: interface queue is forced to FIFO (if no FRF.12 is configured)
- Allows for adaptive shaping (throttling down to minCIR) on BECN reception (just as GTS) and option to reflect incoming FECNs as BECNs
- Option to enable adaptive shaping which responds to interface congestion (non-empty interface queue)

Example: Shape PVC to 384Kbps with minimal Tc (10ms) and WFQ as interface queue

map-class frame-relay SHAPE_384K
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
!
! Adaptive shaping: respond to BECNs and interface congestion
!
frame-relay adaptive-shaping becn
frame-relay adaptive-shaping interface-congestion
!
! Per-VC fancy-queueing
!
frame-relay fair-queue
!
interface Serial 0/0/0:0
frame-relay traffic-shaping
!
interface Serial 0/0/0:0.1
ip address 177.0.112.1 255.255.255.0
frame-relay interface-dlci 112
class SHAPE_384K

Verification: Check FRTS settings for the configured PVC

Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0

cir 384000 bc 3840 be 0 byte limit 480 interval 10 <------ Shaping parameters
mincir 192000 byte increment 480 Adaptive Shaping BECN and IF_CONG <---- Adaptive Shaping enabled
pkts 0 bytes 0 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: weighted fair <---- WFQ is the per-VC queue
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 0

The other PVC, with no class configured, has CIR set to 56Kbps and uses FIFO as per-VC queue:

Rack1R1#show frame-relay pvc 113

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 113, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.2

cir 56000 bc 7000 be 0 byte limit 875 interval 125 <---- CIR=56K
mincir 28000 byte increment 875 Adaptive Shaping none
pkts 74 bytes 5157 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: fifo <------------------ FIFO
Output queue 0/40, 0 drop, 0 dequeued

Check the physical interface queue:

Rack1R1#show interfaces serial 0/0/0:0 | inc Queue
Queueing strategy: fifo

- Interface queue could be changed to PIPQ (PVCs are assigned to 4 pririty groups, with PQ being physical interface queue)
- PIPQ stands for PVC Interface Priority queueing

Example: Map PVC 112 traffic to high interface queue, and PVC 113 to low interface queue, with WFQ being per-VC queueing

!
! Shape to 384K an assign to high interface level queue
!
map-class frame-relay SHAPE_384K_HIGH
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
!
! Per-VC fancy-queueing
!
frame-relay fair-queue
frame-relay interface-queue priority high

!
! Shape to 256k an assign to low interface level queue
!
map-class frame-relay SHAPE_256K_LOW
frame-relay cir 256000
frame-relay bc 2560
frame-relay be 0
!
! Per-VC fancy-queueing
!
frame-relay fair-queue
frame-relay interface-queue priority low

!
! Enable PIPQ as interface queueing strategy
!
interface Serial 0/0/0:0
frame-relay traffic-shaping
frame-relay interface-queue priority
!
interface Serial 0/0/0:0.1
ip address 177.0.112.1 255.255.255.0
frame-relay interface-dlci 112
class SHAPE_384K_HIGH
!
interface Serial 0/0/0:0.2
ip address 177.0.113.1 255.255.255.0
frame-relay interface-dlci 113
class SHAPE_256K_LOW

Verfication: Check PVC interface-level priorities

Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.1

cir 384000 bc 3840 be 0 byte limit 480 interval 10
mincir 192000 byte increment 480 Adaptive Shaping none
pkts 1687 bytes 113543 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 0
priority high
^^^^^^^^^^^^^

Rack1R1#show frame-relay pvc 113

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 113, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.2

cir 256000 bc 2560 be 0 byte limit 320 interval 10
mincir 128000 byte increment 320 Adaptive Shaping none
pkts 1137 bytes 79691 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 0
priority low
^^^^^^^^^^^^

Verify interface-level queue:

Rack1R1#show interfaces serial 0/0/0:0 | inc (Output|high)
Output queue (queue priority: size/max/drops):
high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0

- With FRF.12 fragmentation configured per any PVC, physical interface queue is changed to dual-FIFO
- This is due to the fact that fragmentation is ineffective without interleaving
- Fragment size is calculated based on physical interface speed to allow minimum serialization delay

Example: Enable FRF.12 fragmentation for PVC DLCI 112 and physical interface speed 512Kbps

!
! PVC shaped to 384Kbps, with physical interface speed 512Kbps
!
map-class frame-relay SHAPE_384K_FRF12
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
!
! Per-VC fancy-queueing
!
frame-relay fair-queue

!
! Enable FRF.12 per VC. Fragment size = 512Kbps*0,01/8 = 640 bytes
!
frame-relay fragment 640
!
!
!
interface Serial 0/0/0:0
frame-relay traffic-shaping
!
interface Serial 0/0/0:0.1
ip address 177.0.112.1 255.255.255.0
frame-relay interface-dlci 112
class SHAPE_384K_FRF12

Verfication: Check PVC settings

Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0.1

fragment type end-to-end fragment size 640
cir 384000 bc 3840 be 0 limit 480 interval 10
mincir 192000 byte increment 480 BECN response no IF_CONG no
frags 1999 bytes 135126 frags delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 0

Look at physical interface queue:

Rack1R1#show interfaces serial 0/0/0:0 | inc Queu|Output q
Queueing strategy: dual fifo
Output queue: high size/max/dropped 0/256/0
Output queue: 0/128 (size/max)

- You can map up to 4 priority queues to 4 different VCs (inverse PIPQ)
- This scenario usually implies multiple PVCs running between two sites (e.g. PVC for voice and PVC for data)

Example: Map voice packets to high interface-level priority queue and send them over PVC 112

!
! Voice bearer
!
access-list 101 permit udp any any range 16384 32767

!
! Simple priority list to classify voice bearer to high queue
!
priority-list 1 protocol ip high list 101

interface Serial 0/0/0:0
ip address 177.1.0.1 255.255.255.0
!
! We apply the priority group twice: first to implement queueing
!
priority-group 1
!
! Next to map priority levels to DLCIs
!
frame-relay priority-dlci-group 1 112 112 113 113

Verfication:

Rack1R1#show queueing interface serial 0/0/0:0
Interface Serial0/0/0:0 queueing strategy: priority

Output queue utilization (queue/count)
high/217 medium/0 normal/1104 low/55

Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0

pvc create time 3d01h, last time pvc status changed 3d01h
Priority DLCI Group 1, DLCI 112 (HIGH), DLCI 112 (MEDIUM)
DLCI 113 (NORMAL), DLCI 113 (LOW)

- You can change per-VC queue to CBWFQ/LLQ, and still shape with FRTS
- Note that available bandwidth will be calculated from minCIR value, which is CIR/2 by default

Example: Implement CBWFQ Per-VC

!
! Classify voice using NBAR
!
class-map VOICE
match protocol rtp

!
! Simple LLQ
!
policy-map CBWFQ
class VOICE
priority 64
class class-default
bandwidth 64

!
! Use CBWFQ as queueing strategy
! Note that MinCIR = 384/2=192Kbps
!
map-class frame-relay SHAPE_384K_CBWFQ
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
service-policy output CBWFQ
!
!
!
interface Serial 0/0/0:0
frame-relay traffic-shaping
!
interface Serial 0/0/0:0.1
ip address 177.0.112.1 255.255.255.0
frame-relay interface-dlci 112
class SHAPE_384K_CBWFQ

Verfication: Check PVC queueing strategy

Rack1R1#show frame-relay pvc 112

PVC Statistics for interface Serial0/0/0:0 (Frame Relay DTE)

DLCI = 112, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0:0

cir 384000 bc 3840 be 0 byte limit 480 interval 10
mincir 192000 byte increment 480 Adaptive Shaping none
pkts 0 bytes 0 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
service policy CBWFQ
Serial0/0/0:0: DLCI 112 -

Service-policy output: CBWFQ

Class-map: VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol rtp
Queueing
Strict Priority
Output Queue: Conversation 40
Bandwidth 64 (kbps) Burst 1600 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0

Class-map: class-default (match-any)
32 packets, 2560 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
Output Queue: Conversation 41
Bandwidth 128 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Output queue size 0/max total 600/drops 0

To verify that only MinCIR of bandwidth is allocated to CBWFQ under map-class do the following:

Rack1R1(config)#policy-map CBWFQ
Rack1R1(config-pmap)# class VOICE
Rack1R1(config-pmap-c)# priority 64
Rack1R1(config-pmap-c)# class class-default
Rack1R1(config-pmap-c)# bandwidth 192
I/f Serial0/0/0:0 DLCI 112 Class class-default requested bandwidth 192 (kbps) Only 128 (kbps) available

Subscribe to INE Blog Updates

New Blog Posts!