QoS on the PIX/ASA – Part 2:The Modular Policy Framework
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.
