Posts Tagged ‘classification’


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.

Continue Reading

Tags: , , , , , , ,


In this final part of our blog series on QoS with the PIX/ASA, we examine the remaining two tools that we find on some devices – traffic shaping and traffic policing.

Traffic Shaping

Traffic shaping on the security appliance allows the device to limit the flow of traffic. This mechanism will buffer traffic over the “speed limit” and attempt to send the traffic later. On the 7.x security device, traffic shaping must be applied to all outgoing traffic on a physical interface. Shaping cannot be configured for certain types of traffic. The shaped traffic will include traffic passing though the device, as well as traffic that is sourced from the device.

In order to configure traffic shaping, use the class-default class and apply the shape command in Policy Map Class Configuration mode. This class-default class is created automatically for you by the system. It is a simple match any class map that allows you to quickly match all traffic. Here is a sample configuration:

pixfirewall(config-pmap)#policy-map PM-SHAPER
pixfirewall(config-pmap)# class class-default
pixfirewall(config-pmap-c)# shape average 2000000 16000
pixfirewall(config-pmap-c)# service-policy PM-SHAPER interface outside

Verification is simple. You can run the following to confirm your configuration:

pixfirewall(config)# show run policy-map
policy-map PM-SHAPER
 class class-default
shape average 2000000 16000

Another excellent command that confirms the effectiveness of the policy is:

pixfirewall(config)# show service-policy shape
Interface outside:
 Service-policy: PM-SHAPER
Class-map: class-default
shape (average) cir 2000000, bc 16000, be 16000
     queue limit 64 packets
 (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0

Traffic Policing

With a policing configuration, traffic that exceeds the “speed limit” on the interface is dropped. Unlike traffic shaping configurations on the appliance, with policing you can specify a class of traffic that you want the policing to effect. Let’s examine a traffic policing configuration. In this configuration, we will limit the amount of Web traffic that is permitted in an interface.

pixfirewall(config)# access-list AL-WEB-TRAFFIC permit tcp host eq www any
pixfirewall(config-if)# class-map CM-POLICE-WEB
pixfirewall(config-cmap)# match access-list AL-WEB-TRAFFIC
pixfirewall(config-cmap)# policy-map PM-POLICE-WEB
pixfirewall(config-pmap)# class CM-POLICE-WEB
pixfirewall(config-pmap-c)# police input 1000000 conform-action transmit exceed-action drop
pixfirewall(config-pmap-c)# service-policy PM-POLICE-WEB interface outside

Notice we can verify with similar commands that we used for shaping!

pixfirewall(config)# show run policy-map
policy-map PM-POLICE-WEB
  police input 1000000
pixfirewall(config)# show ser
pixfirewall(config)# show service-policy police
Interface outside:
  Service-policy: PM-POLICE-WEB
    Class-map: CM-POLICE-WEB
      Input police Interface outside:
        cir 1000000 bps, bc 31250 bytes
        conformed 0 packets, 0 bytes; actions:  transmit
        exceeded 0 packets, 0 bytes; actions:  drop
        conformed 0 bps, exceed 0 bps

I hope that you enjoyed this four part series on QoS on the PIX/ASA! Please look for other posts about complex configurations on the security appliances very soon. I have already been flooded with recommendations!

Happy Studies!

Tags: , , , ,


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

Tags: , , , , ,


Catalyst QoS configuration for IP Telephony endpoints is one of the CCIE Voice labs topics. Many people have issues with that one, because of need to memorize a lot of SRND recommendations to do it right. The good news is that during the lab exam you have full access to the QoS SRND documents and UniverCD content. The bad news is that you won’t probably have enough time to navigate the UniverCD with comfort plus the reference configurations often have a lot of typos and mistakes in them.

Continue Reading

Tags: , , , , , ,


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.

Continue Reading

Tags: , , , , , , ,


1. QoS Policy Propagation through Border Gateway Protocol (BGP) (QPPB)
2. Input common classification
3. Input ACLs
4. Input marking (class-based marking or Committed Access Rate (CAR))
5. Input policing (through a class-based policer or CAR)
6. IP Security (IPSec)
7. Cisco Express Forwarding (CEF) or Fast Switching

1. CEF or Fast Switching
2. Output common classification
3. Output ACLs
4. Output marking
5. Output policing (through a class-based policer or CAR)
6. Queueing (Class-Based Weighted Fair Queueing (CBWFQ) and Low Latency Queueing (LLQ)), and Weighted Random Early Detection (WRED)

Tags: , , , , , ,


CCIE Bloggers