Have you ever participated in a long-distance phone call that involved a satellite connection? The conversation might be interrupted with brief, but perceptible, gaps at odd intervals. Those gaps are the time, called the latency, between the arrival of packets being transmitted over the network. Some network traffic, such as voice and video, cannot tolerate long latency times. Quality of service (QoS) is a feature that lets you give priority to critical traffic, prevent bandwidth hogging, and manage network bottlenecks to prevent packet drops.
Note For the ASASM, we suggest performing QoS on the switch instead of the ASASM. Switches have more capability in this area. In general, QoS is best performed on the routers and switches in the network, which tend to have more extensive capabilities than the ASA.
You should consider that in an ever-changing network environment, QoS is not a one-time deployment, but an ongoing, essential part of network design.
This section describes the QoS features available on the ASA.
The ASA supports the following QoS features:
A token bucket is used to manage a device that regulates the data in a flow, for example, a traffic policer. A token bucket itself has no discard or priority policy. Rather, a token bucket discards tokens and leaves to the flow the problem of managing its transmission queue if the flow overdrives the regulator.
A token bucket is a formal definition of a rate of transfer. It has three components: a burst size, an average rate, and a time interval. Although the average rate is generally represented as bits per second, any two values may be derived from the third by the relation shown as follows:
average rate = burst size / time interval
Here are some definitions of these terms:
In the token bucket metaphor, tokens are put into the bucket at a certain rate. The bucket itself has a specified capacity. If the bucket fills to capacity, newly arriving tokens are discarded. Each token is permission for the source to send a certain number of bits into the network. To send a packet, the regulator must remove from the bucket a number of tokens equal in representation to the packet size.
If not enough tokens are in the bucket to send a packet, the packet waits until the packet is discarded or marked down. If the bucket is already full of tokens, incoming tokens overflow and are not available to future packets. Thus, at any time, the largest burst a source can send into the network is roughly proportional to the size of the bucket.
Policing is a way of ensuring that no traffic exceeds the maximum rate (in bits/second) that you configure, thus ensuring that no one traffic class can take over the entire resource. When traffic exceeds the maximum rate, the ASA drops the excess traffic. Policing also sets the largest single burst of traffic allowed.
LLQ priority queuing lets you prioritize certain traffic flows (such as latency-sensitive traffic like voice and video) ahead of other traffic. Priority queuing uses an LLQ priority queue on an interface (see Configure the Priority Queue for an Interface), while all other traffic goes into the “best effort” queue. Because queues are not of infinite size, they can fill and overflow. When a queue is full, any additional packets cannot get into the queue and are dropped. This is called tail drop. To avoid having the queue fill up, you can increase the queue buffer size. You can also fine-tune the maximum number of packets allowed into the transmit queue. These options let you control the latency and robustness of the priority queuing. Packets in the LLQ queue are always transmitted before packets in the best effort queue.
You can configure each of the QoS features alone if desired for the ASA. Often, though, you configure multiple QoS features on the ASA so you can prioritize some traffic, for example, and prevent other traffic from causing bandwidth problems. You can configure:
Priority queuing (for specific traffic) + Policing (for the rest of the traffic).
You cannot configure priority queuing and policing for the same set of traffic.
DSCP (DiffServ) markings are preserved on all traffic passing through the ASA. The ASA does not locally mark/remark any classified traffic. For example, you could key off the Expedited Forwarding (EF) DSCP bits of every packet to determine if it requires “priority” handling and have the ASA direct those packets to the LLQ.
Supported in single context mode only. Does not support multiple context mode.
Supported in routed firewall mode only. Does not support transparent firewall mode.
Additional Guidelines and Limitations
Use the following sequence to implement QoS on the ASA.
Step 1 Determine the Queue and TX Ring Limits for a Priority Queue.
Step 2 Configure the Priority Queue for an Interface.
Step 3 Configure a Service Rule for Priority Queuing and Policing.
Use the following worksheets to determine the priority queue and TX ring limits.
The following worksheet shows how to calculate the priority queue size. Because queues are not of infinite size, they can fill and overflow. When a queue is full, any additional packets cannot get into the queue and are dropped (called tail drop). To avoid having the queue fill up, you can adjust the queue buffer size according to Configure the Priority Queue for an Interface.
|
|
|||||||
|
|
|||||||
|
|
|
The following worksheet shows how to calculate the TX ring limit. This limit determines the maximum number of packets allowed into the Ethernet transmit driver before the driver pushes back to the queues on the interface to let them buffer packets until the congestion clears. This setting guarantees that the hardware-based transmit ring imposes a limited amount of extra latency for a high-priority packet.
|
|
|||||||
|
|
|||||||
|
|
|
If you enable priority queuing for traffic on a physical interface, then you need to also create the priority queue on each interface. Each physical interface uses two queues: one for priority traffic, and the other for all other traffic. For the other traffic, you can optionally configure policing.
Step 1 Create the priority queue for the interface.
The interface_name argument specifies the physical interface name on which you want to enable the priority queue, or for the ASASM, the VLAN interface name.
Step 2 Change the size of the priority queues.
The default queue limit is 1024 packets. Because queues are not of infinite size, they can fill and overflow. When a queue is full, any additional packets cannot get into the queue and are dropped (called tail drop). To avoid having the queue fill up, you can use the queue-limit command to increase the queue buffer size.
The upper limit of the range of values for the queue-limit command is determined dynamically at run time. To view this limit, enter queue-limit ? on the command line. The key determinants are the memory needed to support the queues and the memory available on the device.
The queue-limit that you specify affects both the higher priority low-latency queue and the best effort queue.
Step 3 Specify the depth of the priority queues.
The default tx-ring-limit is 128 packets. This command sets the maximum number of low-latency or normal priority packets allowed into the Ethernet transmit driver before the driver pushes back to the queues on the interface to let them buffer packets until the congestion clears. This setting guarantees that the hardware-based transmit ring imposes a limited amount of extra latency for a high-priority packet.
The upper limit of the range of values for the tx-ring-limit command is determined dynamically at run time. To view this limit, enter tx-ring-limit ? on the command line. The key determinants are the memory needed to support the queues and the memory available on the device.
The tx-ring-limit that you specify affects both the higher priority low-latency queue and the best-effort queue.
The following example establishes a priority queue on interface “outside” (the GigabitEthernet0/1 interface), with the default queue-limit and tx-ring-limit:
The following example establishes a priority queue on the interface “outside” (the GigabitEthernet0/1 interface), sets the queue-limit to 260 packets, and sets the tx-ring-limit to 3:
You can configure priority queuing and policing for different class maps within the same policy map. See How QoS Features Interact for information about valid QoS configurations.
Step 1 Create a class map to identify the traffic for which you want to perform priority queuing.
Step 2 Specify the traffic in the class map.
See Identify Traffic (Layer 3/4 Class Maps) for more information.
Step 3 Create a class map to identify the traffic for which you want to perform policing.
Step 4 Specify the traffic in the class map.
See Identify Traffic (Layer 3/4 Class Maps) for more information.
Tip If you use an ACL for traffic matching, policing is applied in the direction specified in the ACL only. That is, traffic going from the source to the destination is policed, but not the reverse.
Step 5 Add or edit a policy map.
Step 6 Identify the class map you created for prioritized traffic.
Step 7 Configure priority queuing for the class.
Step 8 Identify the class map you created for policed traffic.
Step 9 Configure policing for the class.
Step 10 Activate the policy map on one or more interfaces.
The global option applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
To view the QoS statistics for traffic policing, use the show service-polic y police command.
To view statistics for service policies implementing the priority command, use the show service-policy priority command.
“Aggregate drop” denotes the aggregated drop in this interface; “aggregate transmit” denotes the aggregated number of transmitted packets in this interface.
To display the priority-queue statistics for an interface, use the show priority-queue statistics command. The results show the statistics for both the best-effort (BE) queue and the low-latency queue (LLQ). The following example shows the use of the show priority-queue statistics command for the interface named test.
The following sections provide examples of configuring priority queuing and policing.
In the following example, the class-map command classifies all non-tunneled TCP traffic, using an ACL named tcp_traffic:
hostname(config)#
access-list tcp_traffic permit tcp any any
hostname(config)#
class-map tcp_traffic
hostname(config-cmap)#
match access-list tcp_traffic
In the following example, other, more specific match criteria are used for classifying traffic for specific, security-related tunnel groups. These specific match criteria stipulate that a match on tunnel-group (in this case, the previously-defined Tunnel-Group-1) is required as the first match characteristic to classify traffic for a specific tunnel, and it allows for an additional match line to classify the traffic (IP differential services code point, expedited forwarding).
hostname(config)#
class-map TG1-voice
hostname(config-cmap)#
match tunnel-group tunnel-grp1
hostname(config-cmap)#
match dscp ef
In the following example, the class-map command classifies both tunneled and non-tunneled traffic according to the traffic type:
hostname(config)#
access-list tunneled extended permit ip 10.10.34.0 255.255.255.0
hostname(config)#
access-list non-tunneled extended permit tcp any any
hostname(config)#
tunnel-group tunnel-grp1 type IPsec_L2L
hostname(config)#
class-map browse
hostname(config-cmap)#
description "This class-map matches all non-tunneled tcp traffic."
hostname(config-cmap)#
match access-list non-tunneled
hostname(config-cmap)#
class-map TG1-voice
hostname(config-cmap)#
description "This class-map matches all dscp ef traffic for
hostname(config-cmap)#
match dscp ef
hostname(config-cmap)#
match tunnel-group tunnel-grp1
hostname(config-cmap)#
class-map TG1-BestEffort
hostname(config-cmap)#
description
"This class-map matches all best-effort traffic for
hostname(config-cmap)#
match tunnel-group tunnel-grp1
hostname(config-cmap)#
match flow ip destination-address
The following example shows a way of policing traffic within a tunnel, provided the classed traffic is not specified as a tunnel, but does go through the tunnel. In this example, 192.168.10.10 is the address of the host machine on the private side of the remote tunnel, and the ACL is named “host-over-l2l”. By creating a class-map (named “host-specific”), you can then police the “host-specific” class before the LAN-to-LAN connection polices the tunnel. In this example, the “host-specific” traffic is rate-limited before the tunnel, then the tunnel is rate-limited:
The following example builds on the configuration developed in the previous section. As in the previous example, there are two named class-maps: tcp_traffic and TG1-voice.
hostname(config)#
class-map TG1-best-effort
hostname(config-cmap)#
match tunnel-group Tunnel-Group-1
hostname(config-cmap)#
match flow ip destination-address
Adding a third class map provides a basis for defining a tunneled and non-tunneled QoS policy, as follows, which creates a simple QoS policy for tunneled and non-tunneled traffic, assigning packets of the class TG1-voice to the low latency queue and setting rate limits on the tcp_traffic and TG1-best-effort traffic flows.
In this example, the maximum rate for traffic of the tcp_traffic class is 56,000 bits/second and a maximum burst size of 10,500 bytes per second. For the TC1-BestEffort class, the maximum rate is 200,000 bits/second, with a maximum burst of 37,500 bytes/second. Traffic in the TC1-voice class has no policed maximum speed or burst rate because it belongs to a priority class.
hostname(config)#
access-list tcp_traffic permit tcp any any
hostname(config)#
class-map tcp_traffic
hostname(config-cmap)#
match access-list tcp_traffic
hostname(config)#
class-map TG1-voice
hostname(config-cmap)#
match tunnel-group tunnel-grp1
hostname(config-cmap)#
match dscp ef
hostname(config-cmap)#
class-map TG1-BestEffort
hostname(config-cmap)#
match tunnel-group tunnel-grp1
hostname(config-cmap)#
match flow ip destination-address
hostname(config)#
policy-map qos
hostname(config-pmap)#
class tcp_traffic
hostname(config-pmap-c)#
police output 56000 10500
hostname(config-pmap-c)#
class TG1-voice
hostname(config-pmap-c)#
priority
hostname(config-pmap-c)#
class TG1-best-effort
hostname(config-pmap-c)#
police output 200000 37500
hostname(config-pmap-c)#
class class-default
hostname(config-pmap-c)#
police output 1000000 37500
hostname(config-pmap-c)#
service-policy qos global