blog
    QoS on the PIX/ASA – Part ...
    16 September 08

    QoS on the PIX/ASA – Part 2:The Modular Policy Framework

    Posted byINE
    facebooktwitterlinkedin
    news-featured

    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.

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo