Quality of Service

Architectural Overview

Cisco ASA supports two types of QoS:

• Traffic policing
• Traffic prioritization

Both of these methods are configured by using the robust Modular Policy Framework (MPF), discussed briefly in Chapter 8, "ASA Application Inspection."

Note

Cisco ASA supports QoS only in the single-mode firewall. QoS will not work if the security appliance is configured in multiple-mode security contexts, discussed in Chapter 9, "Security Contexts."

The following sections discuss the two supported types of QoS, the packet flow sequence in the security appliance, the packet-classification process, and the QoS features with respect to VPNs.

Traffic Policing

Traffic policing, also known as traffic rate-limiting, allows you to control the maximum rate of traffic eligible to pass through an interface. Traffic that falls within the configured parameters is allowed to pass, whereas traffic that exceeds the limit is dropped.

In Cisco ASA, if traffic is not classified as "priority," as discussed in the following "Traffic Prioritization" section, it is processed through the rate limiter. The security appliance tries to look for an existing flow and tags the packet for QoS. Thereafter, it sends the packet to the QoS engine for processing. The packet passes through the rate limiter, which determines if the packet conforms to the configured rate. If it does not, then the packet can be forwarded for additional processing or can be dropped based on the policies. If it conforms to the configured rate, the packet is flagged to take the nonpriority queue. Figure 12-1 illustrates how a packet is processed in the security appliance when it passes through the QoS engine.

Figure 12-1. Packet Flow Through the QoS Engine

When traffic leaves the QoS engine, it is forwarded to the egress interface for physical transmission. The security appliance implements another level of QoS processing at the interface to guarantee traffic with a non-priority flag gets proper handling. Packet processing at the interface depends on the depth of the low-priority queue and the conditions of the transmit ring. Transmission ring is the buffer space used by the security appliance to hold packets before transmitting them at the driver level. If the ring is congested, the packet is queued to the low-priority queue. If the transmit ring has room, the packet is sent immediately after ensuring that the high-priority queue is empty. If the high-priority queue has traffic to send, the transmit ring will service it first.

With QoS rate limiting, the security appliance implements a tail drop mechanism when a packet does not conform to the configured profile. The tail drop mechanism drops the packets at the end of the queue if the queue is already full. Cisco ASA logs this event through syslog locally in the buffer or to an external server.

Traffic Prioritization

Traffic prioritization, also known as class of service (CoS) or low-latency queue (LLQ), is used to give important network traffic precedence over normal or unimportant network traffic. It assigns different priority levels or classes (such as high, medium and low) to traffic. The lower the packet's importance, the lower its priority, and thus the greater its chances of getting dropped in case of network congestion.

In the current implementation of Cisco ASA, two classes of traffic prioritization are supported: priority QoS and nonpriority QoS. Priority QoS means that packets are prioritized over regular traffic, whereas nonpriority QoS means that packets are processed by the rate limiter, as discussed earlier.

When traffic is classified as priority, it will be express-forwarded without passing through the rate limiter. The traffic is then flagged to take the priority queue at the egress interface level.

To ensure priority forwarding of traffic at the interface, the security appliance looks at the flag for priority queue and sends the packet for immediate transmission unless the transmit ring is congested. In that case, traffic is queued to the high-priority queue. As soon as the transmit ring has room available, the security appliance services the high-priority queue and transmits the packet.

Note

Traffic prioritization and traffic policing are the two mutually exclusive methods for setting up QoS. You cannot prioritize some traffic and simultaneously police it in same class map configuration, discussed in the section, "Configuring Quality of Service." If you try to configure traffic policing while priority is configured, you will receive an error as follows:

ERROR: Must deconfigure priority in this class before issuing this command

Table 12-1 displays QoS compatibility on the security appliance when other features, such as a transparent firewall, are implemented.

Table 12-1. Support of QoS with Other Features

Feature	Support Under QoS
ToS byte preservation	Yes
Packet prioritization	Yes
Packet policing	Yes
Class-based weighted fair queuing (CBWFQ)	No
QoS for the VPN tunnels	Yes
Security contexts	No
Transparent firewall	No
Routed firewall	Yes
Packet marking	No

The next section discusses the packet flow sequence in the security appliance when QoS is applied on the interface.

Packet Flow Sequence

When a packet passes through a security appliance configured for QoS, the following sequence of events occurs, as illustrated in Figure 12-2:

1. The packet arrives at the ingress interface. If it is the first packet of the flow, the security appliance attempts to route the packet out to the proper interface and creates a flow for the subsequent packets. The flow contains the rules and actions associated with the packets.
2. Based on the QoS rules, the security appliance takes one of the following two actions:

   - If the packet matches the priority queue, it is directed to the high-priority queue for express handling. For the high-priority queue, there is no rate limiting on the packets.

   - If rate limiting is configured on the security appliance, the packet is checked to see if a flow for QoS is already established. If there is none, a flow is created based on the source and destination IP address, source and destination ports, IP protocol, and the interfaces forwarding the packets. The security appliance checks that it conforms to the configured rate-limiting parameters. If the flow exceeds the threshold, the security appliance drops the packet.

3. At this point, the QoS flow is up and the packet is forwarded to the egress interface for physical transmission.
4. The egress interface has two allocated queues for QoS. One is used for the prioritized traffic and the other is used for the rate-limited traffic. If traffic is rate-limited and there are packets to be sent in the high-priority queue, the security appliance services the high-priority queue first and then processes the rate-limited queue.
5. The security appliance transmits the packet over the physical interface.

Figure 12-2. Packet Flow Through the Security Appliance

Note

If a packet does not match traffic priority or traffic rate limiting, it is forwarded to the nonpriority queue without applying the rate-limiting policies.

 

Packet Classification

Packet classification is a way to identify packets on which QoS policies need to be applied. This can range from simple functions such as IP precedence and DSCP fields to complicated methods such as complex access lists. The following subsections discuss the supported packet-classification methods.

IP Precedence Field

IP packets contain a type of service (ToS) byte, which is used to indicate the priority in which the packets should be processed. In the ToS byte, the leftmost 3 bits set the IP precedence, as shown in Figure 12-3. The network devices use the next 4 bits, known as the ToS bits, to determine how a packet should be handled by looking at delay (D), throughput (T), reliability (R), and cost (C). However, these bits are not currently used in the IP network infrastructures. The last bit in the ToS byte is typically referred as MBZ (abbreviation for "must be zero"). This bit is not used either.

Figure 12-3. ToS Byte Displaying IP Precedence Bits

Table 12-2 lists all the IP precedence bits along with their IP precedence names as defined in RFC 791.

Table 12-2. IP Precedence Bits and IP Precedence Names

Precedence Value	Precedence Bit	Precedence Name
0	000	Routine
1	001	Priority
2	010	Immediate
3	011	Flash
4	100	Flash Override
5	101	Critical
6	110	Internetwork Control
7	111	Network Control

 

IP DSCP Field

Differentiated Services Code Point (DSCP) is intended to replace the definitions of the IP ToS byte. It uses the 6 most significant bits for packet classification. The 2 least significant bits are currently unused, as shown in Figure 12-4. By using the 6 bits in DSCP, you can classify up to 64 streams of packets.

Figure 12-4. DSCP Field

DSCP provides backward compatibility to IP precedence. Table 12-3 lists the IP precedence values with the corresponding DSCP values.

Table 12-3. Correlation of IP Precedence Bits to DSCP Bits

Precedence Value	Precedence Bit	DSCP Bit
0	000	000 000
1	001	001 000
2	010	010 000
3	011	011 000
4	100	100 000
5	101	101 000
6	110	110 000
7	111	111 000

While DSCP offers packet classification similarly to IP precedence, it also offers fine granularity to packet identification by using the additional 3 bits. The Internet Engineering Task Force (IETF) has divided the DSCP bits into four service concepts:

• Default DCSP, defined as 000 000, offers the best-effort packet switching through the network devices.
• Class selector provides backward-compatibility bits, shown in Table 12-3. All the DSCP bits shown in the table belong to this service.
• Expedited Forwarding (EF) per-hop behavior (PHB), with the DSCP bit of 101 110, defines the premium service for the IP packets.
• Assured Forwarding (AF) PHB, with four different classes and three different class levels, defines a total of 12 code points for packet classification.

Example 12-1 lists the well-known DSCP bits supported by Cisco ASA.

Example 12-1. Available DSCP Options in Class Maps

Chicago(config-cmap)# match dscp ?

 <0-63> Differentiated services codepoint value

 af11 Match packets with AF11 dscp (001010)

 af12 Match packets with AF12 dscp (001100)

 af13 Match packets with AF13 dscp (001110)

 af21 Match packets with AF21 dscp (010010)

 af22 Match packets with AF22 dscp (010100)

 af23 Match packets with AF23 dscp (010110)

 af31 Match packets with AF31 dscp (011010)

 af32 Match packets with AF32 dscp (011100)

 af33 Match packets with AF33 dscp (011110)

 af41 Match packets with AF41 dscp (100010)

 af42 Match packets with AF42 dscp (100100)

 af43 Match packets with AF43 dscp (100110)

 cs1 Match packets with CS1(precedence 1) dscp (001000)

 cs2 Match packets with CS2(precedence 2) dscp (010000)

 cs3 Match packets with CS3(precedence 3) dscp (011000)

 cs4 Match packets with CS4(precedence 4) dscp (100000)

 cs5 Match packets with CS5(precedence 5) dscp (101000)

 cs6 Match packets with CS6(precedence 6) dscp (110000)

 cs7 Match packets with CS7(precedence 7) dscp (111000)

 default Match packets with default dscp (000000)

 ef Match packets with EF dscp (101110)

Note

The QoS implementation in Cisco ASA observes and honors the DSCP and IP precedence bits in the packet. For the IPSec VPN tunnels, the security appliance preserves the ToS byte from the inner header to the outer header. By doing so, the security appliance and the devices along the VPN tunnel can correctly prioritize traffic.

 

IP Access Control List

Access control lists (ACLs) are the most commonly used form of packet classification. They can identify traffic based on many Layer 3 as well as Layer 4 headers of the packet. Please consult Chapter 5, "Network Access Control," for more information about ACL.

IP Flow

Classification based on IP flow is usually done by looking at the following five tuples:

• Destination IP address
• Source IP address
• Destination port
• Source port
• IP Protocol field

In Cisco ASA, flow-based classification is done based on the destination IP address. That means that if the traffic is destined to an IP address, an IP flow is created and the appropriate policies are applied to it.

VPN Tunnel Group

Cisco ASA can also classify packets destined to an IPSec tunnel. When a packet is received by the security appliance and matches a particular tunnel group (whether site-to-site or remote-access), the security appliance applies the configured QoS policies before transmitting the packet.

Note

The security appliance restricts one match command in the class map. However, you can have two match commands when setting up QoS for the VPN tunnels. Use the match tunnel-group <tunnel-group-name> command in the class map first before specifying a second qualifying match statement in the class map. Currently, match flow ip destination-address is the only supported second match command.

 

QoS and VPN Tunnels

Cisco ASA supports full QoS implementation on both the site-to-site and remote-access VPN tunnels. For the best-effort method, the site-to-site QoS implementation rate-limits traffic for the entire tunnel. This means that all hosts within the tunnel share the same bandwidth. However, for the remote-access VPN tunnels, the QoS implementation rate-limits traffic per remote-access peer. This means that each and every VPN tunnel within a remote access group gets the configured data throughput.

Note

Even though there is a static ACL for each site-to-site tunnel, the QoS rules will not be inserted into the database until there is an active VPN tunnel. This ensures that the security appliance does not allocate bandwidth for the IPSec security associations (SAs) that are not being used.

When both QoS and VPN engines are set up on the security appliance, the following events can occur during device configuration:

• New QoS policy is setup for existing tunnels If a QoS policy is applied to an interface with an active VPN tunnel, the security appliance invokes the IPSec engine to apply the appropriate QoS parameters to the IPSec SAs.
• Tunnel goes down for QoS-enabled group When a VPN tunnel goes down (whether a user deletes the connection or the administrator clears the established SA), the security appliance invokes the QoS process to delete the appropriate QoS parameters for that particular IPSec SA.
• QoS policy is removed for the group When the VPN commands are removed from the QoS configuration, the security appliance invokes the QoS engine to clear up relevant parameters. The security appliance also makes sure not to call the QoS engine for the future VPN tunnels.