Configuring Quality of Service

The QoS configuration on Cisco ASA is broken down into the following four simple steps:

Step 1.	Set up a class map.
Step 2.	Configure a policy map.
Step 3.	Apply the policy map on the interface.
Step 4.	Tune the priority queue (optional).

Step 1: Set Up a Class Map

A traffic class identifies packets on which you want to apply the QoS policies. In the security appliance, there are many ways to classify traffic, as shown in Example 12-2. Use of an ACL is the most robust method available for setting up a class map. You can specify the Layer 3 and Layer 4 information in the packets when ACLs are used. The security appliance can also match based on the DSCP and IP precedence bits in the IP header.

A traffic class is created by using the class-map command, followed by the name of the class. As shown in Example 12-2, a traffic class named traffic-class is created. Packet classification is done by using the match statements along with the appropriate option, described in Table 12-3.

Note

You cannot configure multiple match statements under one class map, with one exception: one additional match statement is allowed when you have match tunnel-group or default-inspect-traffic commands configured in a class map.

 

Example 12-2. Available Options in Class Maps

Chicago(config)# class-map traffic-class

Chicago(config-cmap)# match ?

 access-list Match an Access List

 any Match any packet

 default-inspection-traffic Match default inspection traffic:

 ctiqbe----tcp--2748 dns-------udp--53

 ftp-------tcp--21 gtp-------udp--2123,3386

 h323-h225-tcp--1720 h323-ras--udp--1718-1719

 http------tcp--80 icmp------icmp

 ils-------tcp--389 mgcp------udp--2427,2727

 netbios---udp--137-138 rpc-------udp--111

 rsh-------tcp--514 rtsp------tcp--554

 sip-------tcp--5060 sip-------udp--5060

 skinny----tcp--2000 smtp------tcp--25

 sqlnet----tcp--1521 tftp------udp--69

 xdmcp-----udp--177

 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

Table 12-4 defines all the methods available in the class-map command.

Table 12-4. Definition of match Options in the class-map Command

Feature	Description
access-list	Packet classification is done based on an ACL. The ACL can have source and destination addresses and can optionally contain Layer 4 port information.
any	Any keyword is used to classify all packets flowing through the security appliance.
default-inspection-traffic	This option is used by the inspection engines, discussed in Chapter 8.
dscp	Packet classification is done based on the IETF-defined DSCP value in the IP header.
flow	Packets are classified using the destination IP address of the flow. This option is used along with the tunnel-group option.
port	Packets are classified based on the TCP or UDP destination ports for any source or destination address.
precedence	The security appliance classifies packets based on the ToS byte in the IP header.
rtp	Using RTP (real-time protocol) as the keyword, packets are matched based on the RTP stream on the even UDP port number. This even ports acts as a starting point for a range of UDP ports to identify the RTP streams.
tunnel-group	Packet classification is done based on the tunnel group. This is used for site-to-site and remote-access VPN tunnels.

In Figure 12-5, SecureMe, a fictional company, has Cisco ASA set up to classify traffic sourced from the 192.168.10.0/24 subnet and destined to the mail server, 209.165.201.1. The administrator of the security appliance also prefers to identify the Voice over IP (VoIP) traffic passing through the security appliance.

Figure 12-5. Packet Classification in an Appliance

Example 12-3 shows how to configure a class map for identifying mail and VoIP packets. An ACL named mail-traffic is configured to specify the source and destination IP addresses and the TCP destination port 25 (SMTP). This ACL is mapped to a class map called mail. Two additional class maps, voip-sig and voip-rtp, are set up to identify VoIP packets. VoIP uses DSCP values af31 and ef for voice signaling and RTP streams, respectively. Class map voip-sig is set up to match the packets that have a DSCP value of af31 to identify voice signaling, and class map voip-rtp is set up to identify the RTP streams using DSCP value of ef.

Example 12-3. Class Maps to Identify Mail and VoIP Traffic

Chicago(config)# access-list mail-traffic extended permit tcp 192.168.10.0

 255.255.255.0 host 209.165.201.1 eq smtp

 Chicago(config)# class-map mail

 Chicago(config-cmap)# match access-list mail-traffic

 Chicago(config-cmap)# exit

 Chicago(config)# class-map voip-sig

 Chicago(config-cmap)# match dscp af31

 Chicago(config-cmap)# exit

 Chicago(config)# class-map voip-rtp

 Chicago(config-cmap)# match dscp ef

Note

If you configure two classes with overlapping traffic and then apply policies to rate-limit traffic, the security appliance applies the most stringent traffic policy.

The security appliance can also match traffic destined to go over a tunnel. By using the match tunnel-group command, you can identify packets if they match against a VPN connection. In Example 12-4, the administrator has configured a class map called tunnel-traffic to identify traffic destined to go over a VPN group called SecureMeGroup. The administrator also matches traffic using destination-based IP flow.

Note

The use of match flow ip destination-address along with tunnel-group is mandatory if the VPN traffic needs to be rate-limited. You do not need to use match flow ip destination-address if the VPN traffic needs to be prioritized.

 

Example 12-4. Class Maps to Identify Tunnel Traffic

Chicago(config)# class-map tunnel-traffic

Chicago(config-cmap)# match flow ip destination-address

Chicago(config-cmap)# match tunnel-group SecureMeGroup

Note

If you configure two classes with overlapping traffic, and apply priority to one class and rate limiting to the other class, the security appliance matches traffic to the priority queue and does not apply the rate-limited policies.

 

Step 2: Configure a Policy Map

The configured class maps are bound to a policy map that defines the action to be applied on the identified traffic. You can apply the priority and the rate-limit QoS functions under the policy-map sub-configuration mode. Example 12-5 shows a policy map called traffic-map configured to apply actions to the class maps, defined in the previous step. The class map, such as voip-sig, voip-rtp, and/or tunnel-traffic, is linked to the policy map by using the class command. The security appliance also provides a way to apply actions to traffic not matched by the configured class maps. This is done by using the class-default command.

Example 12-5. Configuration of Policy Maps in the Security Appliance

Chicago(config)# policy-map traffic-map

Chicago(config-pmap)# class ?

 WORD class-map name

 class-default System default class matching otherwise unclassified packets

Chicago(config-pmap)# class voip-sig

Chicago(config-pmap-c)#

After mapping the class and the policy maps, Cisco ASA needs to be configured for an action that can be applied to the identified traffic. The two supported actions, as discussed earlier, are traffic prioritization and traffic policing. In Example 12-6, the security appliance is configured to prioritize VoIP traffic by using the priority statement.

Example 12-6. Traffic Prioritization for the VoIP Traffic

Chicago(config)# policy-map traffic-map

Chicago(config-pmap)# class voip-sig

Chicago(config-pmap-c)# priority

Chicago(config-pmap)# exit

Chicago(config-pmap)# class voip-rtp

Chicago(config-pmap-c)# priority

Cisco ASA uses the police command to define the rate-limiting actions on the identified traffic. If traffic falls in the police rate and burst size, the security appliance can transmit traffic. The police rate is the actual rate that can pass through the QoS engine. It ranges from 8000 bps (bits per second) to 2 billion bps.

The burst size is the amount of instantaneous burst that the security appliance can send at any given time without applying the exceed action. The burst size can be configured by using the following formula:

Burst size = (Policing Rate) * 1.5 / 8

For example, if traffic needs to be limited to a police rate of 56,000 bps, the burst size will be 10,500 bytes. The valid range for burst size is from 1000 to 512,000,000 bytes.

Note

The policing rate is in bits per second while the burst size is in bytes.

In Example 12-7, the security appliance is configured to rate-limit the tunnel traffic to 56 kbps, with a burst size of 10,500 bytes. If traffic falls within this range, the security appliance transmits it as it conforms to the configured policy. Otherwise, traffic that exceeds these rates will be dropped.

Example 12-7. Rate-Limiting of Tunnel Traffic

Chicago(config)# policy-map traffic-map

Chicago(config-pmap)# class tunnel-traffic

Chicago(config-pmap-c)# police 56000 10500 conform-action transmit exceed-action

 drop

The default conform action is to transmit traffic, while the default exceed action is to drop it.

Step 3: Apply the Policy Map on the Interface

The next step in completing the QoS configuration is the association of the policy map to an interface. This is achieved by using the service-policy command along with the policy name and the interface that the policy needs to be applied on. Example 12-8 demonstrates how to apply a policy map called traffic-map to the outside interface.

Example 12-8. Applying QoS on the Outside Interface

Chicago(config)# service-policy traffic-map interface outside

Note

Cisco ASA supports policing and prioritizing traffic only in the outbound direction. That means that if the service policy is applied to the outside interface, then all the packets leaving the security appliance on the outside interface will be inspected for QoS.

Note

An interface-based QoS policy overrides a global QoS policy. The global QoS policy is applied to all the interfaces.

 

Step 4: Tune the Priority Queue (Optional)

When the QoS engine has processed the packets, they are queued to the interface for transmission on the wire. The security appliance implements the priority queue at the interface to ensure that prioritized packets are preferred over nonprioritized packets. You can fine-tune the transmit ring and the depth of the priority queues to minimize the delay for the high-priority packets. The transmit ring, tx-ring-limit, specifies the number of packets allowed into the transmit queue of the interface driver.

Additionally, the security appliance allows you to set the depth of the priority queues by using the queue-limit command. When both queues are full, and the QoS engine forwards more traffic, the security appliance simply drops the received data. Moreover, it processes the transmit ring first before servicing the priority queues. In Example 12-9, the administrator of the security appliance has fine-tuned the priority queue parameters on the outside interface. The transmit-ring limit is changed to hold up to 100 packets in the queue, while the high- and low-priority queue depth is set up to hold 200 packets. This allows the priority queue to be processed efficiently with minimum latency caused by the transmit ring.

Example 12-9. Configuration of Priority Queue

Chicago(config)# priority-queue outside

Chicago(priority-queue)# tx-ring-limit 100

Chicago(priority-queue)# queue-limit 200

Note

The security appliance transmits the priority queue packets before servicing the nonpriority queue.