The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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.
This chapter describes how to apply QoS policies and includes the following sections:
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 supported by the ASA and includes the following topics:
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, the regulator might be a traffic policer or a traffic shaper. 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 either waits until the bucket has enough tokens (in the case of traffic shaping) or the packet is discarded or marked down (in the case of policing). 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.
Note that the token bucket mechanism used for traffic shaping has both a token bucket and a data buffer, or queue; if it did not have a data buffer, it would be a policer. For traffic shaping, packets that arrive that cannot be sent immediately are delayed in the data buffer.
For traffic shaping, a token bucket permits burstiness but bounds it. It guarantees that the burstiness is bounded so that the flow will never send faster than the token bucket capacity, divided by the time interval, plus the established rate at which tokens are placed in the token bucket. See the following formula:
(token bucket capacity in bits / time interval in seconds) + established rate in bps = maximum flow speed in bps
This method of bounding burstiness also guarantees that the long-term transmission rate will not exceed the established rate at which tokens are placed in 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 flow or 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.
The ASA supports two types of priority queuing:
– Priority packets are always queued at the head of the shape queue so they are always transmitted ahead of other non-priority queued packets.
– Priority packets are never dropped from the shape queue unless the sustained rate of priority traffic exceeds the shape rate.
– For IPsec-encrypted packets, you can only match traffic based on the DSCP or precedence setting.
– IPsec-over-TCP is not supported for priority traffic classification.
Traffic shaping is used to match device and link speeds, thereby controlling packet loss, variable delay, and link saturation, which can cause jitter and delay.
Note Traffic shaping is only supported on the ASA 5505.
– The queue size is calculated based on the shape rate. The queue can hold the equivalent of 200-milliseconds worth of shape rate traffic, assuming a 1500-byte packet. The minimum queue size is 64.
– When the queue limit is reached, packets are tail-dropped.
– Certain critical keep-alive packets such as OSPF Hello packets are never dropped.
– The time interval is derived by time_interval = burst_size / average_rate. The larger the time interval is, the burstier the shaped traffic might be, and the longer the link might be idle. The effect can be best understood using the following exaggerated example:
In the above example, the time interval is 1 second, which means, 1 Mbps of traffic can be bursted out within the first 10 milliseconds of the 1-second interval on a 100 Mbps FE link and leave the remaining 990 milliseconds idle without being able to send any packets until the next time interval. So if there is delay-sensitive traffic such as voice traffic, the Burst Size should be reduced compared to the average rate so the time interval is reduced.
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.
See the following supported feature combinations per interface:
You cannot configure priority queuing and policing for the same set of traffic.
You cannot configure traffic shaping and standard priority queuing for the same interface; only hierarchical priority queuing is allowed. For example, if you configure standard priority queuing for the global policy, and then configure traffic shaping for a specific interface, the feature you configured last is rejected because the global policy overlaps the interface policy.
Typically, if you enable traffic shaping, you do not also enable policing for the same traffic, although the ASA does not restrict you from configuring this.
The following table shows the licensing requirements for this feature:
|
|
---|---|
This section includes the guidelines and limitations for this feature.
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
This section includes the following topics:
To determine the priority queue and TX ring limits, use the worksheets below.
Table 21-1 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 the Configuring the Standard Priority Queue for an Interface.
Outbound bandwidth (Mbps or Kbps)1 |
|
|
||||||
|
|
|||||||
|
Average packet size (bytes)2 |
|
Delay (ms)3 |
|
Table 21-2 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.
Outbound bandwidth (Mbps or Kbps)4 |
|
|
||||||
|
|
|||||||
|
Maximum packet size (bytes)5 |
|
Delay (ms)6 |
|
If you enable standard 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.
Note The standard priority queue is not required for hierarchical priority queuing with traffic shaping; see Information About Priority Queuing for more information.
Step 1 Go to Configuration > Device Management > Advanced > Priority Queue, and click Add.
The Add Priority Queue dialog box displays.
Step 2 From the Interface drop-down list, choose the physical interface name on which you want to enable the priority queue, or for the ASA 5505 or ASASM, the VLAN interface name.
Step 3 To change the size of the priority queues, in the Queue Limit field, enter the number of average, 256-byte packets that the specified interface can transmit in a 500-ms interval.
A packet that stays more than 500 ms in a network node might trigger a timeout in the end-to-end application. Such a packet can be discarded in each network node.
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 this option to increase the queue buffer size.
The upper limit of the range of values for this option is determined dynamically at run time. 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 4 To specify the depth of the priority queues, in the Transmission Ring Limit field, enter the number of maximum 1550-byte packets that the specified interface can transmit in a 10-ms interval.
This setting guarantees that the hardware-based transmit ring imposes no more than 10-ms of extra latency for a high-priority packet.
This option 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.
The upper limit of the range of values is determined dynamically at run time. The key determinants are the memory needed to support the queues and the memory available on the device.
The Transmission Ring Limit that you specify affects both the higher priority low-latency queue and the best-effort queue.
You can configure standard 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 To configure priority queuing, configure a service policy rule in the Configuration > Firewall > Service Policy Rules pane according to Chapter1, “Service Policy”
You can configure QoS as part of a new service policy rule, or you can edit an existing service policy.
Step 2 In the Rule Actions dialog box, click the QoS tab.
Step 3 Click Enable priority for this flow.
If this service policy rule is for an individual interface, ASDM automatically creates the priority queue for the interface (Configuration > Device Management > Advanced > Priority Queue; for more information, see Configuring the Standard Priority Queue for an Interface). If this rule is for the global policy, then you need to manually add the priority queue to one or more interfaces before you configure the service policy rule.
Step 4 Click Finish. The service policy rule is added to the rule table.
Step 5 To configure policing, configure a service policy rule for the same interface in the Configuration > Firewall > Service Policy Rules pane according to Chapter1, “Service Policy”
For policing traffic, you can choose to police all traffic that you are not prioritizing, or you can limit the traffic to certain types.
Step 6 In the Rule Actions dialog box, click the QoS tab.
Step 7 Click Enable policing, then check the Input policing or Output policing (or both) check boxes to enable the specified type of traffic policing. For each type of traffic policing, configure the following fields:
Step 8 Click Finish. The service policy rule is added to the rule table.
Step 9 Click Apply to send the configuration to the device.
You can configure traffic shaping for all traffic on an interface, and optionally hierarchical priority queuing for a subset of latency-sensitive traffic.
Step 1 Configure a service policy on the Configuration > Firewall > Service Policy Rules pane according to Chapter1, “Service Policy”
You can configure QoS as part of a new service policy rule, or you can edit an existing service policy.
Step 2 In the Rule Actions dialog box, click the QoS tab.
Step 3 Click Enable traffic shaping, and configure the following fields:
Step 4 (Optional) To configure priority queuing for a subset of shaped traffic:
a. Click Enforce priority to selected shape traffic .
b. Click Configure to identify the traffic that you want to prioritize.
You are prompted to identify the traffic for which you want to apply priority queuing.
c. After you identify the traffic (see Adding a Service Policy Rule for Through Traffic), click Next.
d. Click Enable priority for this flow.
Step 5 Click Finish. The service policy rule is added to the rule table.
Step 6 Click Apply to send the configuration to the device.
To monitor QoS in ASDM, you can enter commands at the Command Line Interface tool. This section includes the following topics:
To view the QoS statistics for traffic policing, use the show service-policy command with the police keyword:
The following is sample output for the show service-policy police command:
To view statistics for service policies implementing the priority command, use the show service-policy command with the priority keyword:
The following is sample output for the show service-policy priority command:
Note “Aggregate drop” denotes the aggregated drop in this interface; “aggregate transmit” denotes the aggregated number of transmitted packets in this interface.
To view statistics for service policies implementing the shape command, use the show service-policy command with the shape keyword:
The following is sample output for the show service-policy shape command:
The following is sample output of the show service policy shape command, which includes service policies that include the shape command and the service-policy command that calls the hierarchical priority policy and the related statistics:
To display the priority-queue statistics for an interface, use the show priority-queue statistics command in privileged EXEC mode. 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, and the command output.
In this statistical report, the meaning of the line items is as follows:
Table 21-3 lists each feature change and the platform release in which it was implemented. ASDM is backwards-compatible with multiple platform releases, so the specific ASDM release in which support was added is not listed.