Posts Tagged ‘shaping’
In this final part of our blog series on QoS with the PIX/ASA, we examine the remaining two tools that we find on some devices – traffic shaping and traffic policing.
Traffic shaping on the security appliance allows the device to limit the flow of traffic. This mechanism will buffer traffic over the “speed limit” and attempt to send the traffic later. On the 7.x security device, traffic shaping must be applied to all outgoing traffic on a physical interface. Shaping cannot be configured for certain types of traffic. The shaped traffic will include traffic passing though the device, as well as traffic that is sourced from the device.
In order to configure traffic shaping, use the class-default class and apply the shape command in Policy Map Class Configuration mode. This class-default class is created automatically for you by the system. It is a simple match any class map that allows you to quickly match all traffic. Here is a sample configuration:
pixfirewall(config-pmap)#policy-map PM-SHAPER pixfirewall(config-pmap)# class class-default pixfirewall(config-pmap-c)# shape average 2000000 16000 pixfirewall(config-pmap-c)# service-policy PM-SHAPER interface outside
Verification is simple. You can run the following to confirm your configuration:
pixfirewall(config)# show run policy-map ! policy-map PM-SHAPER class class-default shape average 2000000 16000 !
Another excellent command that confirms the effectiveness of the policy is:
pixfirewall(config)# show service-policy shape Interface outside: Service-policy: PM-SHAPER Class-map: class-default shape (average) cir 2000000, bc 16000, be 16000 Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0
With a policing configuration, traffic that exceeds the “speed limit” on the interface is dropped. Unlike traffic shaping configurations on the appliance, with policing you can specify a class of traffic that you want the policing to effect. Let’s examine a traffic policing configuration. In this configuration, we will limit the amount of Web traffic that is permitted in an interface.
pixfirewall(config)# access-list AL-WEB-TRAFFIC permit tcp host 192.168.1.110 eq www any pixfirewall(config-if)# class-map CM-POLICE-WEB pixfirewall(config-cmap)# match access-list AL-WEB-TRAFFIC pixfirewall(config-cmap)# policy-map PM-POLICE-WEB pixfirewall(config-pmap)# class CM-POLICE-WEB pixfirewall(config-pmap-c)# police input 1000000 conform-action transmit exceed-action drop pixfirewall(config-pmap-c)# service-policy PM-POLICE-WEB interface outside
Notice we can verify with similar commands that we used for shaping!
pixfirewall(config)# show run policy-map ! policy-map PM-POLICE-WEB class CM-POLICE-WEB police input 1000000 ! pixfirewall(config)# show ser pixfirewall(config)# show service-policy police Interface outside: Service-policy: PM-POLICE-WEB Class-map: CM-POLICE-WEB Input police Interface outside: cir 1000000 bps, bc 31250 bytes conformed 0 packets, 0 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: drop conformed 0 bps, exceed 0 bps
I hope that you enjoyed this four part series on QoS on the PIX/ASA! Please look for other posts about complex configurations on the security appliances very soon. I have already been flooded with recommendations!
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.
Note: The following post is an excerpt from the full QoS section of IEWB-RS VOL1 version 5.
Peak shaping may look confusing at first sight; however, its function becomes clear once you think of oversubscription. As we discussed before, oversubscription means selling customers more bandwidth than a network can supply, hoping that not all connections would use their maximum sending rate at the same time. With oversubscription, traffic contract usually specifies three parameters: PIR, CIR and Tc – peak rate, committed rate and averaging time interval for rate measurements. The SP allows customers to send traffic at rates up to PIR, but only guarantees CIR rate in case of network congestion. Inside the network SP uses any of the max-min scheduling procedures to implement bandwidth sharing in such manner that oversubscribed traffic has lower preference than conforming traffic. Additionally, the SP generally assumes that customers respond to notifications of traffic congestion in the network (either explicit, such as FECN/BECN/TCP ECN or implicit such as packet drops in TCP) by slowing down sending rate.
This may seem to be a basic topic, but it looks like many people are still confused by the difference between those two concepts. Let us clear this confusion at once!
The goal of this article is to discuss how would the following configuration work in the 3560 series switches:
interface FastEthernet0/13 switchport mode access load-interval 30 speed 10 srr-queue bandwidth shape 50 0 0 0 srr-queue bandwidth share 33 33 33 1 srr-queue bandwidth limit 20
Before we begin, let’s recap what we know so far about the 3560 egress queuing:
1) When SRR scheduler is configured in shared mode, bandwidth allocated to each queue is based on relative weight. E.g. when configuring “srr-queue bandwidth share 30 20 25 25″ we obtain the weight sum as 30+20+25+25 = 100 (could be different, but it’s nice to reference to “100”, as a representation of 100%). Relative weights are therefore “30/100”, “20/100”, “25/100”, “25/100” and you can calculate the effective bandwidth *guaranteed* to a queue multiplying this weight by the interface bandwidth: e.g. 30/100*100Mbps = 30Mbps for the 100Mbps interface and 30/100*10Mbps=3Mbps for 10Mbps interface. Of course, the weights are only taken in consideration when interface is oversubscribed, i.e. experiences a congestion.
2) When configured in shaped mode, bandwidth restriction (policing) for each queue is based on inverse absolute weight. E.g. for “srr-queue bandwidth shape 30 0 0 0” we effectively restrict the first queue to “1/30” of the interface bandwidth (which is approximately 3,3Mbps for 100Mbps interface and approximately 330Kbps for a 10Mbps interface). Setting SRR shape weight to zero effectively means no shaping is applied. When shaping is enabled for a queue, SRR scheduler does not use shared weight corresponding to this queue when calculating relative bandwidth for shared queues.
3) You can mix shaped and shared settings on the same interface. For example two queues may be configured for shaping and others for sharing:
interface FastEthernet0/13 srr-queue bandwidth share 100 100 40 20 srr-queue bandwidth shape 50 50 0 0
Suppose the interface rate is 100Mpbs; then queues 1 and 2 will get 2 Mbps, and queues 3 and 4 will share the remaining bandwidth (100-2-2=96Mbps) in proportion “2:1”. Note that queues 1 and 2 will be guaranteed and limited to 2Mbps at the same time.
4) The default “shape” and “share” weight settings are as follows: “25 0 0 0” and “25 25 25 25”. This means queue 1 is policed down to 4Mbps on 100Mpbs interfaces by default (400Kbps on 10Mbps interface) and the remaining bandwidth is equally shared among the other queues (2-4). So take care when you enable “mls qos” in a switch.
5) When you enable “priority-queue out” on an interface, it turns queue 1 into priority queue, and scheduler effectively does not account for the queue’s weight in calculations. Note that PQ will also ignore shaped mode settings as well, and this may make other queues starve.
6) You can apply “aggregate” egress rate-limitng to a port by using command “srr-queue bandwidth limit xx” at interface level. Effectively, this command limits interface sending rate down to xx% of interface capacity. Note that range starts from 10%, so if you need speeds lower than 10Mbps, consider changing port speed down o 10Mbps.
How will this setting affect SRR scheduling? Remember, that SRR shared weights are relative, and therefore they will share the new bandwidth among the respective queues. However, shaped queue rates are based on absolute weights calculated off interface bandwidth (e.g. 10Mbps or 100Mbps) and are subtracted from interface “available” bandwidth. Consider the example below:
interface FastEthernet0/13 switchport mode access speed 10 srr-queue bandwidth shape 50 0 0 0 srr-queue bandwidth share 20 20 20 20 srr-queue bandwidth limit 20
Interface sending rate is limited to 2Mbps. Queue 1 is shaped to 1/50 of 10Mps, which is 200Kbps of bandwidth. The remaining bandwidth 2000-200=1800Kbps is divided equally among other queues in proportion 20:20:20=1:1:1. That is, in case on congestion and all queues filled up, queue 1 will get 200Kbps, and queues 2-4 will get 600Kbps each.
This is a “modern” way to configure FRTS, using MQC commands only to accomplish the task. With MQC approach, an unified interface has been introduced to configure all QoS settings, irrelevant of underlying technology.
- Legacy command frame-relay traffic-shaping is incompatible with MQC-based FRTS (you can’t mix them)
- Fancy queueing could not be used as a PVC-queueing strategy: CBWFQ is the only option available
- Per-VC CBWFQ is configured via hierarchical policy-maps configuration: Parent policy sets shaping values, while child policy implements CBWFQ
- You may apply policy-map per-interface (subinterface) or per-VC, using match fr-dlci under class-map submode
Example: Shape PVC to 384Kbps and provide LLQ treatment for voice bearer packets on PVC queue
class-map VOICE match ip dscp ef ! class-map DATA match ip dscp cs1 ! ! "Child" policy-map, used to implement CBWFQ ! policy-map CBWFQ class VOICE priority 64 class DATA bandwidth 128 class class-default fair-queue ! ! "Parent" policy map, used for PVC shaping ! policy-map SHAPE_384K class class-default shape average 384000 shape adaptive 192000 service-policy CBWFQ interface Serial 0/0/0:0.1 ip address 18.104.22.168 255.255.255.0 service-policy output SHAPE_384K frame-relay interface-dlci 112
Verification: check out policy map settings
Rack1R1#show policy-map interface serial 0/0/0:0.1 Serial0/0/0:0.1 Service-policy output: SHAPE_384K Class-map: class-default (match-any) 1942 packets, 1590741 bytes 5 minute offered rate 48000 bps, drop rate 0 bps Match: any Traffic Shaping Target/Average Byte Sustain Excess Interval Increment Rate Limit bits/int bits/int (ms) (bytes) 384000/384000 2400 9600 9600 25 1200 Adapt Queue Packets Bytes Packets Bytes Shaping Active Depth Delayed Delayed Active - 0 1936 1581717 0 0 no Service-policy : CBWFQ Class-map: VOICE (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: protocol rtp Match: ip dscp ef (46) Queueing Strict Priority Output Queue: Conversation 40 Bandwidth 64 (kbps) Burst 1600 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 Class-map: DATA (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp cs1 (8) Queueing Output Queue: Conversation 41 Bandwidth 128 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class-default (match-any) 1942 packets, 1590741 bytes 5 minute offered rate 48000 bps, drop rate 0 bps Match: any Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 32 (total queued/total drops/no-buffer drops) 0/0/0
The amount of bandwidth, available for allocation to CBWFQ classes, is taken from shape adaptive value. If the latter is not configured, shape average
value is used instead. Note, that as you configure bandwidth settings for classes, their values are not subtracted from remaining bandwidth. This is in contraty with
“classic” CBWFQ, applied to a physical interface (not subinterface or PVC)
Verification (with the example above):
Rack1R1#conf t Enter configuration commands, one per line. End with CNTL/Z. Rack1R1(config)#policy-map CBWFQ Rack1R1(config-pmap)#class class-default Rack1R1(config-pmap-c)#no fair-queue Rack1R1(config-pmap-c)#bandwidth 256 I/f shape class class-default requested bandwidth 256 (kbps), available only 192 (kbps)
Note that available bandwidth is set to shape adaptive value, even though we have priority configured under class VOICE and bandwidth
settings under class DATA
- You can’t apply FRF.12 fragmentation with MQC commands – it should be applied at physical interface level. By doing so, FRF.12 is effectively enabled for all PVCs
- Physical interface queue could be set to any of WFQ/CQ/PQ or CBWFQ (not restricted to FIFO as with FRTS legacy) – though this is rarely needed
Example: Shape PVC DLCI 112 to 384Kpbs and enable FRF.12 fragmentation for all PVCs
class-map VOICE match ip dscp ef ! class-map DATA match ip dscp cs1 ! ! Match the specific DLCI ! class-map DLCI_112 match fr-dlci 112 ! ! "Child" policy-map, used to implement CBWFQ ! policy-map CBWFQ class VOICE priority 64 class DATA bandwidth 128 class class-default fair-queue ! ! "Parent" policy map, used for PVC shaping ! With multiple classes, we can match different DLCIs ! all at the same physical interface (where they belongs) ! policy-map INTERFACE_POLICY class DLCI_112 shape average 384000 shape adaptive 192000 service-policy CBWFQ ! ! Apply the parent policy map at physical interface level ! Also, configure FRF.12 "global" settings here ! interface Serial 0/0/0:0 service-policy output INTERFACE_POLICY frame-relay fragment 640 end-to-end
Rack1R1#show policy-map interface serial 0/0/0:0 Serial0/0/0:0 Service-policy output: INTERFACE_POLICY Class-map: DLCI_112 (match-all) 1040 packets, 95287 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: fr-dlci 112 Traffic Shaping Target/Average Byte Sustain Excess Interval Increment Rate Limit bits/int bits/int (ms) (bytes) 384000/384000 2400 9600 9600 25 1200 Adapt Queue Packets Bytes Packets Bytes Shaping Active Depth Delayed Delayed Active - 0 1040 95287 4 1373 no Service-policy : CBWFQ Class-map: VOICE (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: protocol rtp Match: ip dscp ef (46) Queueing Strict Priority Output Queue: Conversation 40 Bandwidth 64 (kbps) Burst 1600 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 Class-map: DATA (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp cs1 (8) Match: fr-dlci 112 Queueing Output Queue: Conversation 41 Bandwidth 128 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class-default (match-any) 1040 packets, 95287 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 32 (total queued/total drops/no-buffer drops) 0/0/0 Class-map: class-default (match-any) 2594 packets, 153695 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any
Verify fragmentation settings:
Rack1R1#show interface serial 0/0/0:0 Serial0/0/0:0 is up, line protocol is up Hardware is GT96K Serial MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY, loopback not set Keepalive set (10 sec) LMI enq sent 21224, LMI stat recvd 21224, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE FR SVC disabled, LAPF state down Fragmentation type: end-to-end, size 640, PQ interleaves 0 <--------- Fragment Size Broadcast queue 0/64, broadcasts sent/dropped 63160/0, interface broadcasts 56080 Last input 00:00:03, output 00:00:02, output hang never Last clearing of "show interface" counters 2d10h Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 6 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/1/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 1152 kilobits/sec 5 minute input rate 0 bits/sec, 1 packets/sec 5 minute output rate 0 bits/sec, 1 packets/sec 272202 packets input, 27557680 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 15 input errors, 15 CRC, 8 frame, 0 overrun, 0 ignored, 5 abort 333676 packets output, 42152431 bytes, 0 underruns 0 output errors, 0 collisions, 16 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions Timeslot(s) Used:1-24, SCC: 0, Transmitter delay is 0 flags