Modular Policy Framework (MPF) configuration defines set of rules for applying firewall features, such as traffic inspection, QoS etc. to the traffic transiting the firewall. MPF has many similarities to MQC (Modular QoS CLI) syntax found in Cisco IOS, but there are some major differences in the flow of operations, even though many commands look the same. The following post assumes basic understanding of ASA firewall and its configuration. It covers the basic logic of the MPF, but does not go over all firewall features in depth.

Traffic Flow through the Firewall

ASA is a complicated piece of hardware and software, just like any stateful firewall. However, for the purpose of understanding the MPF it is enough to use the following simplified packet flow checklist:

  1. See if packet matches a flow in the connection table if so, skip to (4). This means packets matching existing states bypass the ACL checks
  2. Find egress interface, drop packet if egress interface cannot be found. Two options:
    1. Packet’s destination address matches existing XLATE state or STATIC NAT statement. This is common when you use outside NAT. Egress interface is determined from the NAT entry.
    2. Perform route lookup on the destination IP address to find egress interface
  3. Match input access-list on the ingress interface. Use the ORIGINAL destination IP address, not the untranslated IP for matching
  4. Match flow against input QoS policy (interface or global policy, where interface policy takes precedence)
  5. Apply source NAT if XLATE state does not exist and there is matching NAT rule. Use the following order of operations:
    1. NAT exemption, configuration using the command nat (interface) 0 access-list
    2. First matching STATIC NAT or PAT, with NAT taking precedence. If multiple entries match the packet, select the first one.
    3. Dynamic NAT entries configured using the command nat (interface) [ID] access-list
    4. Dynamic NAT entries configured using the command nat (interface) [ID] [network] [mask]. If [ID]=0 then identity XLATEs are created
  6. Apply egress QoS policy (output policing, interface or global)
  7. Create or update flow information
  8. Lookup output egress interface in routing table based on destination IP. Find out the next-hop, which should be on the SAME interface as XLATE points to, if XLATE/STATIC was used at step (2). This route should not necessarily be the LONGEST match, just any matching route out of selected interface.

It is important to notice two important things: firstly, the addresses you should use in the access-lists are supposed to be pre-NAT addresses or in other words just as the packet originator sees them. Secondly, pay attention to the concept of XLATE-based routing that ASA uses. This concept requires special attention.
What is the point of pinning an egress interface to a NAT entry? The reason being the fact that if there exists an XLATE entry, then more likely there are traffic flows using it. Therefore it is desirable pinning traffic to the same interface that was used for XLATE creation – otherwise traffic may match different NAT rule and the connection will be broken. This is why the firewall attempts finding the egress interface using the XLATE first. However, what happens if the route has flapped and the untranslated address is now reachable via a different interface? The firewall will still perform a route lookup using all routes that are bound to the original interface and try finding a match. If a match is found, it is used to find out the next-hop and route packet out. If not, the packet is dropped. Look at the following configuration sample:

static (outside,inside)
route outside 1
route DMZ

Here packets going from “inside” to “outside” toward the IP address are destination untranslated to the IP address This IP is statically routed over the DMZ interface, but the firewall will only check the routes bound to the “outside” interface and use the default route to route the packet to In this situation, even though the specific static route is not correct, the NAT-bound egress interface decision allows traffic to flow correctly.

Traffic Classification

Every MPF rule has a scope - subset of traffic that the rule applies to - and action - feature or a set of features triggered by this rule. In ASA firewall, L3/L4 class-maps are used to specify the traffic for a rule. The following is the list of the mot common classification criteria:

  • Access-List. Most typical and very flexible criterion, allows matching based source/destination IP addresses, port numbers, protocols and so on – everything you can put in an ACL. Example:
    access-list BGP permit tcp host any eq bgp
    access-list BGP permit tcp any eq bgp host
    class-map BGP
    match access-group BGP
  • Port numbers/range. Without configuring an access-list, you can specify TCP/UDP port numbers to be matched by the class map, such as follows:
    class-map PORTS
    match port tcp range 100 200
  • Tunnel Group name. Allows matching the traffic for a particular tunnel group in the firewall. The firewall will dynamically track VPN tunnels created for this group and classify traffic accordingly.
    class-map TUNNEL_GROUP
    match tunnel-group TEST

    In addition to specifying the match tunnel-group criterion, you can also configure one additional match statement. You are allowed any additional criterion with except to match any or match access-list or match default-inspection-traffic. For example the following configuration is supposed to matchVoIP traffic within the VPN tunnel, provided that VoIP packets are marked with DSCP value of EF.

    class-map VPN_VOICE
    match tunnel-group TEST
    match dscp ef
  • Per-flow classification criterion configured using the match flow ip destination-address. This one could be used only along with the match tunnel-group command. When configured, it tracks every VPN connection separately and applies the configured action per-flow, not to all VPN traffic at the same time. This is particularly useful for Remote-Access VPN connections, where multiple users connection to the firewall unit. Notice that you can apply the QoS policing feature only per-flow, when classifying based on tunnel group names. Example:
    class-map VPN_FLOWS
    match tunnel-group TEST
    match flow ip destination-address
  • Matching the default classification traffic. This is special “intelligent” type of classification used exclusively with inspect action. It matches traffic on the default port numbers for ALL available inspection engines. For example it will match FTP traffic on port 21, HTTP on port 80, DNS on port 53 and so on. As mentioned, the only supported feature with this classification type is traffic inspection.
  • Other classification criteria such as match dscp and match rtp. Those allow matching based on the DSCP value in IP packet headers and matching based on RTP port range.

    As you noticed, a typical class map will only support ONE match command. The only exception is the use of match tunnel-group along with some other match commands.

Applying Features in Policy Maps
After you defined traffic classes, you may configure MPF rules using regular policy-map. We call them regular, as there are special inspection policy maps, used to define inspection settings and parameers. Regular policy maps attach actions to L3/L4 classes using the following syntax:

policy-map <NAME>
class <CLASS1>
class <CLASS2>

The list of the applicable firewall features follows:

  1. QoS input policing. Applies to traffic entering the firewall, enforces traffic rate. Configured using the command police input| under the policy-map.
  2. TCP normalization. TCP and UDP connection limits and timeouts, and TCP sequence number randomization. Performs TCP connection modification and monitoring to enforce security settings. Configured using the command set connection and a pre-configured tcp-map with the advanced TCP parameters.
  3. CSC (if installed). Content security.
  4. Application inspection (multiple types). The core of the stateful firewall. Parses traffic streams and detects application protocols and their commands. Allows enforcing per-application security policies. The command to apply inspection is inspect {protocol-name}. Could be fine-tuned using inspection policy-maps.
  5. IPS (if installed). Intrusion prevention – allows the firewall to work as an inline IPS.
  6. QoS output policing. Applies to traffic leaving the firewall, enforces specified rate. The command is police output
  7. QoS interface priority queue. Services traffic using the interface-level low-latency queue. Configured using the command priority. Could not be applied along with policing feature.
  8. QoS traffic shaping, hierarchical priority queue. Mutually exclusive with any other interface-level QoS features. Traffic shaping could be only applied under class-default

There could be a situation when a packet/flow matches multiple classes within the same policy-map. For example, with the following configuration

class-map FTP
match port tcp eq 21
access-list TCP permit tcp any any
class TCP
match access-list TCP
class default-inspection-traffic
inspect ftp
class FTP
set connection conn-max 100
class TCP
set connection conn-max 200
police input 150000

FTP packets would match all three classes at the same time. The question is: what action should the firewall apply to this flow? The rule of thumb to resolve conflicts in situations like that is as follows:

  1. For a given feature type, the flow can match only one class, based on the order the classes are configure in the policy map. In our example, the TCP connection limits are set for classes “FTP” and “TCP”, both matched by the flow in question. Since “FTP” precedes “TCP” the TCP connection limit is set based on “FTP” class.
  2. If the packet flow matches multiple classes with different feature types (e.g. QoS and inspection), then feature actions from all classes are combined provided that they are not conflicting. In our example, FTP flow will be inspected, limited to 100 connections and policed ingress to 150Kbps.

The next question is: if the multiple features are combined together, what is the order they are applied to the flow? It does not depend on the order of the class-map within the policy-map. The actions are applied in sequence, in the same order they are presented in the list above. In our example, the flow is first policed, then normalized and then inspected. Notice that some features may drop packets (such as policing) or modify the traffic contents (e.g. TCP normalization or inspection).

Levels and Directions

Policy map could be applied globally or per interface. There could be only one global policy map and one policy-map applied per interface. The question is: how those maps are combined to build the resulting set of MPF rules? When traffic goes across the firewall, the system determines the ingress and egress interfaces for the flow based on the routing table and xlate entries. The system builds the list of classes matched by the flow based on the feature direction for every class configured under the policy-maps. Here is the table from the Doc CD:

Feature Interface-Level Direction Global Policy Direction
Inspection Bidirectional Ingress
CSC Bidirectional Ingress
IPS Bidirectional Ingress
QoS Input Policing Ingress Ingress
QoS Output Policing Egress Egress
QoS Interface-Level PQ Egress Egress
QoS Shaping, Hierarchical PQ Egress N/A
TCP Normalization, Connection Limits, ISN randomization Bidirectional Ingress

How to read this table? Let’s take the TCP Normalization feature for example. Suppose it is configured at the interface level. Then, based on its bi-directional behavior, packets entering and leaving the interface will be subject to normalization process, provided that they match the respective class-map. Take another example. If you have configured FTP traffic inspection at the interface level like this:

access-list FTP_FROM_INSIDE
permit tcp any eq 21
match access-list FTP
policy-map INSPECTION
set connection max-conn 100
inspect ftp

Then both features apply only to FTP traffic going from the inside network to the outside on port 21. The traffic to the inside network on port 21 is not inspected nor limited, even though features are bi-directional, as it does not match the access-list. To inspect traffic bi-directionally you need the access-list

access-list FTP_FROM_INSIDE
permit tcp any eq 21
permit tcp any 255.255.255 eq 21

OK, that looks reasonable enough. Now what should the firewall do if a packet/flow matches multiple classes in level policy maps applied at different levels (i.e. interface and global)? Here is how the conflicts are resolved:

  1. If there is a feature defined in the interface-level policy map and global policy map, and the flow matches both classes, the interface-level settings take precedence. For example, if the interface-level class-map FTP sets connection-limit to 100 and the global policy set the limit to 200, the resulting limit for FTP traffic is 100.
  2. If the flow matches classes at the interface-level and global policy-maps and the classes have different features configured (e.g. inspect and policing) then actions are combined. The order that the features are applied is per the list provided above.
  3. If the flow matches classes both at ingress and egress interfaces, the resulting effect depends on the type of traffic. Traffic classified “statefully”, such as TCP and UDP flows and ICMP, when ICMP inspection is enabled, triggers the same feature in different policy-maps only once. For example, if the flow enters the firewall and triggers the inspection feature in the ingress interface-level policy-map, the firewall will store this event in the state table. No further attempts to perform traffic inspection or normalization are made for this flow, even if it matches the egress interface policy. Moreover, the returning packets for the flow are not matched against the “flow-aware” features ingress on the returning interface. This is the direct consequence of the firewall stateful behavior. The list of “flow-aware” features includes: application inspection, CSC/IPS, TCP normalization and connection limiting.

What if the packet stream is not treated by the firewall as a single flow? For example, imagine a stream of ICMP packets when ICMP inspection is disabled. In this case, bidirectional features on ingress and egress interfaces will apply twice. Moreover, the returning packets will also be subject to feature actions, such as IPS checks. This behavior is also true with any flow unaware feature, such as QoS policing.

Feature Incompatibilities

As you remember, you can apply multiple actions under the same class. Some actions just can’t go together. Here is the list of the limitations:

  1. You can’t combine policing and interface-level priority queuing for the same class.
  2. You can’t configure shaping in global policy map.
  3. You can only shape ALL traffic leaving the interface, i.e. you can only shape under class-default.
  4. You cannot configure two inspect actions under the same class with except to default-inspection-traffic class.

What if traffic flow matches multiple classes and those classes define different protocol inspection actions? For example, what if the interface policy has two classes configured like the following:

class-map FTP
match port tcp eq 21
class-map HTTP
match port tcp eq 21
policy-map TEST
class FTP
inspect ftp
class HTTP
inspect http

Then the FTP flow will match both classes. However, one applies FTP inspection and another HTTP inspection. To resolve such conflicts, the firewall uses the list of application priorities (from the DocCD):

  2. DNS
  3. FTP
  4. GTP
  5. H323
  6. HTTP
  7. ICMP
  8. ICMP error
  9. ILS
  10. MGCP
  11. NetBIOS
  12. PPTP
  13. Sun RPC
  14. RSH
  15. RTSP
  16. SIP
  17. Skinny
  18. SMTP
  19. SNMP
  20. SQL*Net
  21. TFTP
  22. XDMCP
  23. DCERPC
  24. Instant Messaging

Application priority decreases in descending order, with CTIQBE inspection having highest priority. The inspection action with higher priority will be preferred in case of conflict. In the example described above, FTP is more preferred than HTTP, and thus traffic is inspected for FTP protocol.


As you can see, ASA firewall system implements sophisticated logic for traffic matching and feature application. This is the direct result of combining multiple features for the same set of traffic using the class->action based syntax. Right now the semantic is not very transparent, and it might take time to understand a particular configuration. Here is the list of basic points about MPF:

  1. Service policies could be applied globally or per-interface.
  2. A packet flow can match multiple classes.
  3. In case if two ore more classes specify the same feature, firewall applies the deterministic procedure to resolve the conflict.
  4. In the classes specify different features, they are combined, provided that the features could be used together.
  5. Many firewall features are aware of stateful traffic flows.
  6. The order that the features are applied is fixed and does not depend on the order of classes in the policy-maps.

The security appliance supports two kinds of priority queuing - standard priority queuing and hierarchical priority queuing. Let's configure each in this third part of our blog.

Standard Priority Queuing

This queuing approach allows you to place your priority traffic in a priority queue, while all other traffic is placed in a best effort queue. You can police all other traffic if needed.

Step 1: Create the priority queue on the interface where you want to configure the standard priority queuing. This is done in global configuration mode with the priority-queue interface_name command. Notice this will place you in priority queue configuration mode where you can optionally manipulate the size of the queue with the queue-limit number_of_packets command. You can also optionally set the depth of the hardware queue with the tx-ring-limit number_of_packets command. Remember that the hardware queue forwards packets until full, and then queuing is handled by the software queue (composed of the priority and best effort queues).

pixfirewall(config)# priority-queue outside

Step 2: Use the Modular Policy Framework (covered in Part 2 of these blogs) to configure the prioritized traffic.

pixfirewall(config-priority-queue)# exit
pixfirewall(config)# class-map CM-VOICE
pixfirewall(config-cmap)# match dscp ef
pixfirewall(config-cmap)# exit
pixfirewall(config)# class-map CM-VOICE-SIGNAL
pixfirewall(config-cmap)# match dscp af31
pixfirewall(config-cmap)# exit
pixfirewall(config)# policy-map PM-VOICE-TRAFFIC
pixfirewall(config-pmap)# class CM-VOICE
pixfirewall(config-pmap-c)# priority
pixfirewall(config-pmap-c)# exit
pixfirewall(config-pmap)# class CM-VOICE-SIGNAL
pixfirewall(config-pmap-c)# priority
pixfirewall(config-pmap-c)# exit
pixfirewall(config-pmap)# exit
pixfirewall(config)# service-policy PM-VOICE-TRAFFIC interface outside
pixfirewall(config)# end

Hierarchical Priority Queuing

This queuing approach allows you to shape traffic and allow a subset of the shaped traffic to be prioritized. I have cleared the configuration from the security appliance in preparation for this new configuration. Notice with this approach, you do not configure a priority queue on the interface. Also notice with this approach the nesting of the Policy Maps.

pixfirewall(config)# class-map CM-VOICE
pixfirewall(config-cmap)# match dscp ef
pixfirewall(config-cmap)# exit
pixfirewall(config)# class-map CM-VOICE-SIGNAL
pixfirewall(config-cmap)# match dscp af31
pixfirewall(config-cmap)# exit
pixfirewall(config)# policy-map PM-VOICE-TRAFFIC
pixfirewall(config-pmap)# class CM-VOICE
pixfirewall(config-pmap-c)# priority
pixfirewall(config-pmap-c)# exit
pixfirewall(config-pmap)# class CM-VOICE-SIGNAL
pixfirewall(config-pmap-c)# priority
pixfirewall(config-pmap-c)# exit
pixfirewall(config-pmap)# exit
pixfirewall(config)# policy-map PM-ALL-TRAFFIC-SHAPE
pixfirewall(config-pmap)# class class-default
pixfirewall(config-pmap-c)# shape average 2000000 16000
pixfirewall(config-pmap-c)# service-policy PM-VOICE-TRAFFIC
pixfirewall(config-pmap-c)# exit
pixfirewall(config-pmap)# service-policy PM-ALL-TRAFFIC-SHAPE interface outside
pixfirewall(config)# end

Verifications for Priority Queuing

These verification commands can be used for both forms of priority queuing. Obviously, you can examine portions of the running configuration to confirm your Modular Policy Framework components. For example:

pixfirewall# show run policy-map
 class CM-VOICE
 class class-default
 class class-default
  shape average 2000000 16000
  service-policy PM-VOICE-TRAFFIC

Another example:

pixfirewall# show run class-map
 match dscp af31
class-map CM-VOICE
 match dscp ef

To verify the statistics of the standard priority queuing configuration, use the following:

pixfirewall# show service-policy priority
Interface outside:
  Service-policy: PM-VOICE-TRAFFIC
   Class-map: CM-VOICE
        Interface outside: aggregate drop 0, aggregate transmit 0
    Class-map: CM-VOICE-SIGNAL
        Interface outside: aggregate drop 0, aggregate transmit 0

You can also view the priority queue statistics for an interface using the following:

pixfirewall# show priority-queue statistics outside
Priority-Queue Statistics interface outside
Queue Type         = BE
Tail Drops         = 0
Reset Drops        = 0
Packets Transmit   = 0
Packets Enqueued   = 0
Current Q Length   = 0
Max Q Length       = 0
Queue Type         = LLQ
|Tail Drops         = 0
Reset Drops        = 0
Packets Transmit   = 0
Packets Enqueued   = 0
Current Q Length   = 0
Max Q Length       = 0

To verify the statistics on the shaping you have done with the hierarchical priority queuing, use the following:

pixfirewall# show service-policy shape
Interface outside:
  Service-policy: PM-ALL-TRAFFIC-SHAPE
    Class-map: class-default
      shape (average) cir 2000000, bc 16000, be 16000
      (pkts output/bytes output) 0/0
      (total drops/no-buffer drops) 0/0
      Service-policy: PM-VOICE-TRAFFIC

The next blog entry on this subject will focus on the shape tool available on the PIX/ASA.

Thanks so much for reading!


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.


This blog is focusing on QoS on the PIX/ASA and is based on 7.2 code to be consistent with the CCIE Security Lab Exam as of the date of this post. I will create a later blog regarding new features to 8.X code for all of you non-exam biased readers :-)

NOTE: We have already seen thanks to our readers that some of these features are very model/license dependent! For example, we have yet to find an ASA that allows traffic shaping. 

One of the first things that you discover about QoS for PIX/ASA when you check the documentation is that none of the QoS tools that these devices support are available when you are in multiple context mode. This jumped out at me as a bit strange and I just had to see for myself. Here I went to a PIX device, switched to multiple mode, and then searched for the priority-queue global configuration mode command. Notice that, sure enough, the command was not available in the CUSTA context, or the system context.

pixfirewall# configure terminal
pixfirewall(config)# mode multiple
WARNING: This command will change the behavior of the device
WARNING: This command will initiate a Reboot
Proceed with change mode? [confirm]
Convert the system configuration? [confirm]
pixfirewall> enable
pixfirewall# show mode
Security context mode: multiple
pixfirewall# configure terminal        
pixfirewall(config)# context CUSTA
Creating context 'CUSTA'... Done. (2)
pixfirewall(config-ctx)# context CUSTA
pixfirewall(config-ctx)# config-url flash:/custa.cfg
pixfirewall(config-ctx)# allocate-interface e2 
pixfirewall(config-ctx)# changeto context CUSTA
pixfirewall/CUSTA(config)# pri?     
configure mode commands/options:
pixfirewall/CUSTA# changeto context system
pixfirewall# conf t
pixfirewall(config)# pr?
configure mode commands/options:

OK, so we have no QoS capabilities when in multiple context mode. :-| What QoS capabilities do we possess on the PIX/ASA when we are behaving in single context mode? Here they are:

  • Policing – you will be able to set a “speed limit” for traffic on the PIX/ASA. The policer will discard any packets trying to exceed this rate. I always like to think of the Soup Guy on Seinfeld with this one - "NO BANDWIDTH FOR YOU!" 
  • Shaping – again, this tool allows you to set a speed limit, but it is “kinder and gentler”. This tool will attempt to buffer traffic and send it later should the traffic exceed the shaped rate.
  • Priority Queuing – for traffic (like VoIP that rely hates delays and variable delays (jitter), the PIX/ASA does support priority queuing of that traffic. The documentation refers to this as a Low Latency Queuing (LLQ).

Now before we get too excited about these options for tools, we must understand that we are going to face some pretty big limitations with their usage compared to shaping, policing, and LLQ on a Cisco router. We will detail these limitations in future blogs on the specific tools, but here is an example. We might get very excited when we see LLQ in relation to the PIX/ASA, but it is certainly not the LLQ that we are accustomed to on a router. On a router, LLQ is really Class-Based Weighted Fair Queuing (CBWFQ) with the addition of strict Priority Queuing (PQ). On the PIX/ASA, we are just not going to have that type of granular control over many traffic forms. In fact, with the standard priority queuing approach on the PIX/ASA, there is a single LLQ for your priority traffic and all other traffic falls into a best effort queue.

If you have been around QoS for a while, you are going to be very excited about how we set these mechanisms up on the security appliance. We are going to use the Modular Quality of Service Command Line Interface (MQC) approach! The MQC was invented for CBWFQ on the routers, but now we are seeing it everywhere. In fact, on the security appliance it is termed the Modular Policy Framework. This is because it not only handles QoS configurations, but also traffic inspections (including deep packet inspections), and can be used to configure the Intrusion Prevention and Content Management Security Service Modules. Boy, the ole’ MQC sure has come a long way.

While you might be frustrated with some of the limitations in the individual tools, at least there are a couple of combinations that can feature the tools working together. Specificaly, you can:

  • Use standard priority queueing (for example for voice) and then police for all of the other traffic.
  • You can also use traffic shaping for all traffic in conjunction with hierarchical priority queuing for a subset of traffic. Again, in later blogs we will educate you more fully on each tool.

Thanks for reading and I hope you are looking forward to future blog entries on QoS with the ASA/PIX.

Subscribe to INE Blog Updates

New Blog Posts!