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.
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 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 Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0
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 192.168.1.110 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 class CM-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!
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.
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.
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.
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)