Posts Tagged ‘llq’
This publication discusses the spectrum of problems associated with transporting Constant Bit Rate (CBR) circuits over packet networks, specifically focusing VoIP services. It provides guidance on practical calculation for voice bandwidth allocation in IP networks, including the maximum bandwidth proportion allocation and LLQ queue settings. Lastly, the publication discusses the benefits and drawbacks of transporting CBR flows over packet switched networks and demonstrates some effectiveness criteria.
Historically, the main design goal of Packet Switched Networks (PSNs) was optimum bandwidth utilization for low-speed links. Compared to their counterpart, circuit-switched networks (CSNs such as SONET/SDH networks), PSNs use statistical as opposed to deterministic (synchronous) multiplexing. This feature allows PSNs to be very effective for bursty traffic sources, i.e. those that send traffic sporadically. Indeed, with many sources this allows the transmission channel to be optimally utilized by sending traffic only when necessary. Statistical multiplexing is only possible if every node in the network implements packet queueing, because PSNs introduce link contention. One good historical example is ARPANET: the network theoretical foundation has been developed in Kleinrock’s work on distributed queueing systems (see ).
Computing voice bandwidth is usually required for scenarios where you provision LLQ queue based on the number of calls and VoIP codec used. You need to account for codec rate, Layer 3 overhead (IP, RTP and UDP headers) and Layer 2 overhead (Frame-Relay, Ethernet, HDLC etc. headers). Accounting for Layer 2 overhead is important, since the LLQ policer takes this overhead in account when enforcing maximum rate.
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 pixfirewall(config-priority-queue)#
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 ! policy-map PM-VOICE-TRAFFIC class CM-VOICE priority class CM-VOICE-SIGNAL priority class class-default policy-map PM-ALL-TRAFFIC-SHAPE class class-default shape average 2000000 16000 service-policy PM-VOICE-TRAFFIC !
pixfirewall# show run class-map ! class-map CM-VOICE-SIGNAL 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 Priority: Interface outside: aggregate drop 0, aggregate transmit 0 Class-map: CM-VOICE-SIGNAL Priority: 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!
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: privilege pixfirewall/CUSTA# changeto context system pixfirewall# conf t pixfirewall(config)# pr? configure mode commands/options: privilege
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.
Try assessing your understanding of Cisco’s CBWFQ by looking at the following example:
class-map match-all HTTP_R6 match access-group name HTTP_R6 ! policy-map CBWFQ class HTTP_R6 bandwidth remaining percent 5 ! interface Serial 0/1 bandwidth 128 clock rate 128000 service-policy output CBWFQ
and answering a question on the imaginable scenario: Two TCP flows (think of them as HTTP file transfers) are going across Serial 0/1 interface. One of the flows matches the class HTTP_R6, and another flow, marked with IP Precedence of 7 (pretty high), does not match any class. The traffic flow overwhelms the interface, so the system engages CBWFQ. Now the question is: how CBWFQ will share the interface bandwidth among the flows.