--------- Forwarded message ---------- From: "Chris Lewis \(chrlewis\)" To: "B Kim" , "CCIE Study Group" Date: Wed, 27 Jul 2005 11:51:38 -0400 Subject: RE: CB Policing - police vs police cir To get the Doc CD explanation, you need to lookup the 12.3 command reference for both police and police (two rates) Policing can take multiple forms. One rate two color or three color (RFC 2697) Two rate three color (RFC 2698) Two color refers to confrm and exceed actions as a result of policing, Three color means there is confrom, exceed and violate actions. The straight police command refers to the single rate system, the police cir to the two rate system Single rate 3 color is configured with police cir Bc Be conform exceed violate For single rate, Be need not be specified if there is no violate action. When you configure the violate action, separate Bc and Be buckets are used. Two rate three color config: police cir Bc pir Be conform exceed violate Policing is enforced according to 2 separate rates. Default Bc and Be value is (configured rate/8)*1.5 The idea here is that there is a normal rate under which packets conform, which is the CIR, above that rate and up to the PIR, packets have the exceed action, and abover the PIR, packets take the violate action. If police percent is required, the reference bandwidth that is used to form the basis of percent is important. For example if there is a police percent in a child policy, and the parent is shaped to 512, 512 is the rate that percent uses. If bandwidth is used instead of shape in the parent policy, there is no upper limit on the amount of traffic the class can send if there is no congestion, so the operation is to look one level higher to the interface level bandwidth command. This is a very short summary, it takes lots of practice to become anywhere near familiar with this topic IMHO. Chris ---- ---------- Forwarded message ---------- From: "Arun Arumuganainar" To: "san" Date: Wed, 27 Jul 2005 22:08:04 +0530 Subject: Re: Queue with GTS It works like this .When a packet is being forwarded If Shaping is not configured then 1) If Hardware Queue is not full than it will enqueued directly toHardware Queue . Software Queue will be inactive . 2) If Hardware Queue is full , Packet will be enqueued to Software Queue . However if shaping is turned on ( via CBTS , GTS or FRTS ) then Packet will be enqueued in Shaping Queue first . When it is de-queued from Shaping Queue, then rule 1 and Rule 2 will apply . Network Design Note : ~~~~~~~~~~~~~~~~ 1) On Low bandwidth line turn on fair queue( infact it is the Cisco default for line bandwidth less than T1/E1) . This is because hardware will get filled up easily and often you will have to use software queues . Pls. Note : In such a scenario fair queues give fair treatment to packet by punishing aggressive flows more than other flows . 2) On high bandwidth line say Fast Ethernet or Gig Ethernet ,leave software queue in FIFO mode ( Cisco Default when BW > T1/E1 ) . As HW queue rarely get full and Queuing will not be active at all ( Memory allocated for fancy-queuing is wasted ) Pls. Note : Its generally not recommended to use PQ or CQ . In case you need priority treatment to real time traffic ,then resort to CBWFQ . This has LLQ option( "priority " command under policy-map) and internally uses fair queue. Configuration Note : ============== 1) To change Software queue , use interface specific command ( ex : fair-queue , priority-queue on the interface ) 2) To change Shaping Queue configure queuing in Frame Relay map class commands . Cisco Implementation Note : ==================== 1) For GTS , Shaping queue can not be changed...uses only ( no cli exists and software does not support it ) 2) For FRTS , Software Queue can not be changed ( You will not be allowed to change Queuing on the interface on while frame relay map is applied ) Hope this helps . Thanks and Regards Arun ----- ---------- Forwarded message ---------- From: "Arun Arumuganainar" To: "toonsh dosh" , Date: Wed, 27 Jul 2005 22:27:57 +0530 Subject: Re: FRTS query Cool today seems to be QoS field Day ...Too many question on Shaping. & Policing !!!! Let me explain . Say you are in a central office and You and big leased line say of E1 bandwidth ( 2.04MBPS ) .You have 10 remote sites who has wan bandwidth of 128KBPS each . In such as case you may choose to employ Nested policies . Some FAQs Why Shaping is needed here ?: Because if you don't shape at the central office then, there may be a situation where central office may pump more than 128KBPS . This would result in dropped packets at the remote end . So you will have to resort to shaping . Why Nested Shaping ? So we got the traffic shaped via CBTS . Once the traffic is shaped we wanted to give priority to real time traffic flowing to the remote end . Hence u need to employ LLQ over shaped traffic .This is achieved via nesting LLQ policy over CBTS. Note : This is a typical case study of Nested Policy .Great that you got it !!!! Thanks and Regards Arun ----- Original Message ----- From: "toonsh dosh" To: Sent: Wednesday, July 27, 2005 8:18 PM Subject: FRTS query > Hi > > I have a question with this sample configuration below take from MQC-Based > Frame-Relay configuration doc: > > > class-map voice > > match ip dscp ef > > policy-map llq > > class voice > > priority 32 > > policy-map shape > > class class-default > > shape average 64000 > > shape adaptive 32000 > > service-policy llq <---------------------------------- Why do > they nest this LLQ policy > > > > interface serial0/0 > > encapsulation frame-relay > > interface serial0/0.1 point-to-point > > ip address 192.168.1.1 255.255.255.0 > > frame-relay interface-dlci 100 > > class shape > > > Why is it that they create a LLQ policy and then nest it under the default > class. What would have been the difference if the did it in the following > manner: > > policy-map shape > class llq > priority 32 > > class class-default > > shape average 64000 > > shape adaptive 32000 > > > So have two seperate classes under the "policy-map shape". ----- More clear now. This is from Wendell: "In some cases, IOS does not place the packets into a shaping queue as they arrive, but instead the packets are placed into the Software queue or TX Queue. When the shaping features knows that a newly arrived packet does not exceed the shaping rate, there is no need to delay the packet. In that case, a queuing tool used for managing the shaping queue would also have no effect on that particular packet. " [Arun] This is absolutely true and this is how Shaping works . When a packet arrives , it will check the token bucket if credit available it will be sent to Software queue ( or directly to H/W queue if it is not full ) . If credits are not available then this will be placed in the shapping queue ( Read more about token bucket algorithm for Details ). [Arun] But, could you think about an example using a tool for queue created by shaping and a tool queue for the main interface used at the same time? I remember that when we configure fragmentation, IOS creates two queues on the main interface, and we can still use other tools (LLQ, CQ, PQ, IP RTP Priority) on the queue created by shaping. Then, correcting my last post, this would occur: |shaping queue|------->|software queue|-------->|hardware queue| LLQ Dual-Fifo Fifo [Arun] See What queueing technique does shaping and software queues uses is implementation specific . For Cisco with GTS the scenario look like this |shaping queue|------->|software queue|-------->|hardware queue| WFQ CQ or PQ or Fifo Fifo For Cisco with FRTS th scenario look like this |shaping queue|------->|software queue|-------->|hardware queue| CQ or PQ or Fifo WFQ Fifo Note :LLQ belong to different category . LLQ = Strict Priority Queue + Policing . An Standalone LLQ can not be used for shapping ( A PQ can be used instead of this ). Certainly you can verify this by configuring this in your lab Hope it is clear now ---- The output from the show policy seems to be as expected. The only issue I see here is the throughput you are seeing, and I would bet heavily that it is related to the test method being used (pings won't do it and a single TCP flow has other dependencies). I accept there are plenty of bugs in IOS, but the shape accuracy has been pretty good for a long period of time. But in any case, during the exam you are not given any traffic generators at this time, so it should not be a concern for this list. I believe you accurately represent the difference in theory between shape peak and shape average, and the target rate is as you would expect for the burst parameters you put in for the two options. As you point out, with shape average, Be is available for transmission during the first time interval only, whereas for shape peak, it is available for each time period. For shape peak settings of shape peak 64000 8192 8192 Means that during each time interval you can send 8192 of Bc and 8192 of Be, yielding a Target rate of 128000, shape pea 64000 8192 16384 gives you a target rate of 192000 as expected, as you can send a total of 8192 plus 16384 per time interval. Besides the observed throughput rate, what is not clear? --- I tested it again, this time using 'timeout 3' and 'frequency 3' (tested using SAA) and the rate was the specified for 'shape average 64000': Rack2R4#sh int e 0/1 | i output rate 1 minute output rate 63000 bits/sec, 107 packets/sec Rack2R4#sh pol int e 0/1 | i offered rate 1 minute offered rate 133000 bps, drop rate 69000 bps For 'shape peak 64000 8192 8192', the rate grows up until it reach target rate: Rack2R4#sh int e0/0 | i output rate 5 minute output rate 127000 bits/sec, 193 packets/sec Rack2R4#sh policy-map int e 0/0.46 | i offered rate 5 minute offered rate 305000 bps, drop rate 194000 bps --- ubject: RE: bandwidth remaining percentage Here is one example; policy-map pm1 class traffic bandwidth remaining percent 90 class voice priority percent 20 class class-default bandwidth remaining percent 10 The show policy-map output looks like this Router1(config-if)#service-pol out pm1 Router1(config-if)#do sho policy-map int Serial3/0 Service-policy output: pm1 Class-map: traffic (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: protocol ip Queueing Output Queue: Conversation 265 Bandwidth remaining 90 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: voice (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip rtp 16383 16383 Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 20 (%) Bandwidth 308 (kbps) Burst 7700 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 Class-map: class-default (match-any) 1 packets, 24 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Queueing Output Queue: Conversation 266 Bandwidth remaining 10 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 1/365 (depth/total drops/no-buffer drops) 0/0/0 So voice gets 308K, which is 20% of 1544Kbits as expected, and we are not told what the other classes get, which is in contrast to what we see when we use bandwidth percent. policy-map pm3 class voice priority percent 20 class traffic bandwidth percent 30 class class-default bandwidth percent 25 Router1(config-if)#do sho policy-map int Ethernet0/0 Service-policy output: pm3 Class-map: voice (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip rtp 16383 16383 Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 20 (%) Bandwidth 2000 (kbps) Burst 50000 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 Class-map: traffic (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: protocol ip Queueing Output Queue: Conversation 265 Bandwidth 30 (%) Bandwidth 3000 (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) 1 packets, 60 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Queueing Output Queue: Conversation 266 Bandwidth 25 (%) Bandwidth 2500 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 1/390 (depth/total drops/no-buffer drops) 0/0/0 The reason is that bandwidth remaining will allocate available bandwidth in the percentage defined in the configuration, so in the example given, the worst case for the class traffic is it gets 90% of 1544-308 (1112) if the priority traffic fills the priority queue, if the priority traffic uses less than that, class traffic gets something more than 1112, but only in the proportion of 90% of whatever the priority traffic is not using. In terms of wording, you could be asked to configure a given amount for priority, then be told to use a percentage scheme for allocating bandwidth to the other classes, where the allocation must total 100% (which you could not do using just bandwidth percent). Maybe they would reference something about the difference in the output of the show policy map display, maybe showing you this policy map and telling you to make the router display that (as they do with BGP tables sometimes). Alternatively they could ask about unused bandwidth being assigned in the proportion of its allotment, but that I think would be hard to word precisely, but you never know :) Chris -- --------- Forwarded message ---------- From: "Chris Lewis \(chrlewis\)" To: , , "simon hart" Date: Tue, 6 Sep 2005 22:41:33 -0400 Subject: RE: 3550- "bandwidth & Priority" Policy-map commands Shun and Simon, I believe your questions are in fact resulting from the same issue. Before MQC came about, each platfrom had its own QoS configuration. MQC is an attempt over time to bring a common method of configuration to all Cisco platforms. The idea is that if for example you want to assign bandwidth to a class, you can use the bandwidth command in MQC on all platforms. Some platfotms may use different mechanisms to ensure that the bandwidth is assigned. The 3550 uses WRR, the 12K uses MDRR, others use something else, but the result is intended to be the same, whatever actual mechanism the platfrom uses to assign bandwidth is transparent to the one configuring MQC, just the bandwidth command needs to be configured and all the rest gets worked out under the hood. However some platfroms (like the 3550) do not have the hardware necessary to complete these migrations. Also software gets re-used from platform to platform and some things can be configured that are not actually supported on a per platfrom basis. So we get to this situation, where you can use MQC to configure say a policer on the 3550 and it works, but not bandwidth allocation, that is still by the legacy wrr-queue configuration. By configuring different weights for the different queues, and assigning the traffic you want to the queues (with wrr-queue cos-map), you can effectively give different bandwidth guarantees to different traffic types. Chris -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of kumara.shunmugam@wipro.com Sent: Tuesday, September 06, 2005 6:11 AM To: ccielab@groupstudy.com Subject: 3550- "bandwidth & Priority" Policy-map commands Hi Can any one comment on the above two command support on Cat3550. Many forums say that the 3550 will not properly support bandwidth command under policy-map (egress queue). If we want to change the bandwidth, the only way is to go is by using "wrr-queue bandwidth command. But I think the wrr-queue bandwidth command is the mechanism to assign weights to each queue. Where as the policy-map will provide minimum bandwidth guarantee for an identified traffic during time of congestion. Can anyone discuss the policy-map limitations in 3550? Regards Shun --- --------- Forwarded message ---------- From: "Chris Lewis \(chrlewis\)" To: "Niche" , "toonsh dosh" Date: Fri, 9 Sep 2005 13:06:47 -0400 Subject: RE: Setting ingress DSCP value on 3550 L2 port Here is what I was able to determine in the lab regarding MQC to do this and setting up the 3550 to use priority queueing for voice traffic (I had received a unicast question on that). Before starting, please be aware of the following restrictions for QoS on the 3550 QoS Unsupported Global Configuration Commands policy-map policy-map-name bandwidth policy-map policy-map-name set mpls Unsupported Class-Map Configuration Commands match any match destination-address match input-interface match mpls match not match protocol match source-address This is taken from http://www.cisco.com/en/US/products/hw/switches/ps646/products_configura tion_guide_chapter09186a0080211d4f.html#wp1010072 The simple setup is as follows: R1 (F0/0; 10.1.1.1) | | (F0/1) Sw-3550A (F0/2) | | R2(F0/0; 10.1.1.2) I setup the following access list on R2, inbound on F0/0 access-list 100 permit icmp any any dscp cs2 If I ping 10.1.1.2 from R1 I get U.U.U as expected. I now set the dscp to 2 for ICMP traffic on R1 with the following: ! class-map match-all icmp match access-group 110 ! ! policy-map dscp class icmp set dscp cs2 ! interface FastEthernet0/0 ip address 10.1.1.1 255.255.255.0 service-policy output dscp duplex auto speed auto ! Access-list 110 permit icmp any any Now if I ping 10.1.1.2 from R1 the ping works and I get hits in the show access-list on R2. R2(config)#do sho access-list 100 Extended IP access list 100 10 permit icmp any any dscp cs2 (20 matches) So far so good, I have a tested base to work from to see how the 3550 operates, I now remove the service policy from R1 F0/0 and see if I can get the 3550 to mark the traffic. Now I put the following configuration on the switch and test class-map match-all icmp match access-group 100 ! policy-map dscp class icmp set ip dscp 16 ! interface FastEthernet0/1 switchport access vlan 12 switchport mode access service-policy input dscp ! access-list 100 permit icmp any any Note that I entered set ip dscp cs2, but the parser changed it to 16. I ping 10.1.1.2 from R1 and it fails. If I add mls qos to the global configuration of the switch, it works. So to reply to Toonsh's original question, was mls qos globally enabled? Also the Set dscp command does not seem to be there, you need set ip dscp, at least in the IOS on my switch. However, the basic functionality works. Now to the question of setting a priority queue for the 3550 for voice traffic. MQC will not work for this, if I try, I get the following: SW-3550A(config-pmap-c)#? QoS policy-map class configuration commands: bandwidth Bandwidth exit Exit from QoS class action configuration mode no Negate or set default values of a command trust Set trust value for the class police Police set Set QoS values This is running 12.1(20)EA, the release I'd expect to see on the exam. There is no option. Now I admit this is tricky, some commands appear in here that are listed as not supported, so I suspect if you use them, you will lose points on the exam. It is easy here though, as the priority keyword is not even listed, so we have to resort to the legacy commands. Now the short cut to doing this is as follows: SW-3550A(config-if)#auto qos voip ? cisco-phone Trust the QoS marking of Cisco IP Phone cisco-softphone Trust the QoS marking of Cisco IP SoftPhone trust Trust the DSCP/CoS marking I was in F0/1 and after selecting the csico-phone option, the autoqos voip macro runs and I get this configuration mls qos map cos-dscp 0 8 16 26 32 46 48 56 mls qos min-reserve 5 170 mls qos min-reserve 6 85 mls qos min-reserve 7 51 mls qos min-reserve 8 34 mls qos ! interface FastEthernet0/1 switchport access vlan 12 switchport mode access mls qos trust device cisco-phone mls qos trust cos auto qos voip cisco-phone wrr-queue bandwidth 10 20 70 1 wrr-queue min-reserve 1 5 wrr-queue min-reserve 2 6 wrr-queue min-reserve 3 7 wrr-queue min-reserve 4 8 wrr-queue cos-map 1 0 1 wrr-queue cos-map 2 2 4 wrr-queue cos-map 3 3 6 7 wrr-queue cos-map 4 5 priority-queue out Now this typically will not be enough to meet the requirements, and you'll probably want to run no auto qos voip cisco phone on the interace to remove this once you've copied it for further use, but it is a great start to look at the commands you need to configure. So what should we try to accompish here? The auto qos script has created configurations that affect things inbound and outbound. Inbound it is trusting cos from the cisco phone, however the rest is for outbound traffic from the port to the phone, which is where we'll focus here. Each 3550 port has 4 hardware queues, only one of them can be used for priority queuing, queue 4. The interface command priority-queue out sets transmit queue 4 as the priority queue. However, to use priority queuing, you would have to make sure that the CoS value for the packets you want priority queued ended up in transmit queue 4 by some means. The auto qos voip script assumes packets going through the switch to be egressed out interface Fa0/1 will be marked with precedence 5 and places them in queue 4 with the command Wrr-queue cos-map 4 5 So how much bandwidth is assign to the priority queue? The documentation gives us this example: Switch(config)# interface gigabitethernet0/1 Switch(config-if)# wrr-queue bandwidth 1 2 3 4 "The ratio of the bandwidth allocated for each queue is 1/(1+2+3+4), 2/(1+2+3+4), 3/(1+2+3+4), and 4/(1+2+3+4), which is 1/10, 1/5, 3/10, and 2/5 for queues 1, 2, 3, and 4. " This suggests that the auto qos script has assigned 1/101 to the priority queue, however, the documentation also tells us "All four queues participate in the WRR unless the expedite queue (queue 4) is enabled, in which case weight4 is ignored (not used in the ratio calculation). The expedite queue is a priority queue, and it is serviced until empty before the other queues are serviced" So you never need to set a bandwidth level for the priority queue on the 3550. Chris ---- Hello Stefan and Shun, You have both asked similar questions, so I'm posting the two mails here and trying to respond in one rather than 2 mails. I've also copied GS as my last post had an error in it. If you're not interested in this topic my apologies, this is a long post, but the delete button works just as well :) First of all I have to say I incorrectly commented on the Bc value for policing and have provided a corrected response below. We have a new baby in the house and I should probably not post until I get proper rest! I think a lot of the detail here will not help you explicitly on the exam, but may make you more comfortable with the technology in general (I hope :) Anyway, dealing with the issue of the Bc and Be on police command first. Both shaping and policing use a token bucket, which means traffic is conforming or exceeding based of whether enough tokens are in the bucket. However, one of the fundamental differences between shaping and policing is that with shaping, tokens are added to the bucket at pre-defined intervals, the Tc. This is not the case with policing. The police method adds tokens as traffic arrives, so any concept of using Tc to define policing behavior is meaningless to me, and that was my error in responding to Stefan's post yesterday, I got shaping and policing mixed up when calculating Tc. One does not calculate Tc for policing. For policing, token replenishment is based upon [(T1-T) * target rate], where T1 is the arrival time of the current packet and T is the arrival time of the previous packet, the target rate is what you specify in the police command. The token bucket is replenished on receipt of a packet based on this formula and not based upon periodic (every Tc interval) refresh. Looking at an example, we see how this operates. If the target rate (CIR) is say 64kbps and the time elapsed between the arrival of the current packet and last packet is say 250mS, then T1-T = 250mSec T1-T * CIR = 250 mSec * 64000 / 8 = 1000bytes will be used to replenish the token bucket. This happens with all subsequent packets. The amount of replenishment on the receipt of each packet will be dependent upon the above formula. What you are doing when you set Bc, is to set the depth of the token bucket to which these tokens are added, once you reach the maximum defined by Bc, no more tokens are let in until some have been taken out by packet arrival. Where does Be fit in? For CAR (the legacy rate-limit command) a single token bucket for Bc and Be is used. In the example above, if the replenishment of tokens did not leave enough tokens in the bucket, (and here is where we start to leave the realms of applicable information), it means tokens have to be borrowed from future allocation. One cannot borrow tokens indefinitely, so the router keeps track with a value called Debt (which splits in to actual and compound debt). But basically, when compound debt is greater than Be, the packet is dropped. Actual debt is the number of tokens borrowed by the current stream of packets. Compound debt = sum of all preceeding actual debt Initially, the compounded debt = actual debt when you borrow tokens for the first time. This is simpler to understand with an example. Let's say you have three packets come along and each needs to borrow 100 tokens in order to be transmitted. Actual debt = 100 after one packet, 200 after packet 2 and 300 after packet 3. The compound debt at these stages are 100, 300, 600 respectively. The Compund debt is reset to 0 if a packet is dropped. Actual debt is not forgiven after a packet drop. If actual debt is greater than the Be value, all packets are dropped until actual debt is reduced by the accumulation of tokens. This is a simplified discusion, but even this I believe is unnecessary for the exam, in terms of configuration, if you get in to thinking about debt in the lab, you are off base IMO. So what should you set the police burst parameters to? Well, the values for Bc and Be in the police command really depend on the nature of your traffic. For example, if your traffic stream is bursty and prone to large intervals of silence and then a huge burst, it would probably be best to configure a high extended burst value. So for the exam, I would not configure Bc and Be for the police command unless the question expressly required it. Something like saying burst must be half the default, or something like that would trigger this configuration in the question. For single rate Class based policing as used in the MQC construct, Be and Bc have separate buckets. In this case Bc sets the depth of the confirm bucket and Be sets the depth of the exceed bucket. Excess tokens from the Bc bucket flow over in to the Be bucket if new tokens arrive that don't fit in the Bc bucket. Allocation of tokens is still driven by packet arrival rather than the regular filling up as in the shaping model. However, all this should be transparaent for what can actually be tested under exam conditions. Unless the question expressly requires it, leave the Bc and Be police values at the default. With a two rate MQC configuration, the Bc and Be buckets are updated separately with each arriving packet, based on the CIR or PIR value. Now to the specific QoS question posted by Stefan. I think it is a bogus question. It does not make sense to me. Either it comes from a poorly wrritten workbook question (there are some on QoS out there believe it or not), or IMO it is being mis-quoted from an actual exam. This topic is confusing enough without dealing with questions that don't have answers! If the question related to a frame relay connection, I might interpret the lower rate as the mincir value and the upper rate as the cir value, this would allow the rate transmitted at to fluctuate between these two values depending on the presence of BECNs (if the map-class is configured with adaptive shaping), but on ethernet, I can't see what the question wants you to achieve. Now I'll try my best with a couple of Stefan's specific questions. Stefan wrote: 4. I will ask another question about 3550 queuing. a) How we can limit the input traffic some some rate say 64000. How we can limit input traffic to 64000 and if the link is totally free and it is needed to 256000 also. Probably I mixed up the police command for input and output traffic. But as I ramember for output traffic we could do this for sure am I wright?? (ON the link about quos on 3550 I found just police (cir) (bc) ) [Chris replies] I can't work with the concept of transmitting at 64000, then 256 at other times on ethernet, I don't know how to address that. Either you target the transmit rate at 64 or 256k, I don't know how both can be done at once. One can use the two rate policer to say transmit below 64K, then mark differently between 64 and 256, then after 256 drop. On the 3550 for ingress policing you can classify on an ACL and police the classified traffic. On egress, you can only classify on DSCP for policing. Stefan wrote: 5. As I thought about your suggestion about 2 rate policer. Did you mean that?? : police cir 64000 conform-action transmeed exceed-action transmeat pir 256000 conformation transmeet exceed-action drop [Chris replies] You would configure a 2 rate policer to allow sub 64K traffic, then mark between 64 and 256K ro DSCP 2, then drop above 256k Like this policy-map testpm2 class test police cir 64000 pir 256000 conform-action transmit exceed-action set-dscp-transmit 2 violate-action drop Chris --- -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Tom Lijnse Sent: Thursday, June 30, 2005 4:04 AM To: Chris Lewis (chrlewis); ccie2be; Rajib Khan; ccielab@groupstudy.com Subject: RE: Police with random detect Hi all, Let's try to summarize and clarify this. To start with I am not 100% sure what the intention of the original question was, but I'm assuming the following: - SMTP must be strictly limited to 1 Mbps. No burst is allowed. - Any SMTP traffic above 1 Mbps must be acted on by RED (random-detect). - Other traffic is not to be affected. Obviously, if the question is different we'll arrive at a different answer. As has been mentioned before RED can only be used as an add-on to a queuing mechanism. It replaces the normal tail-dropping for a queue with the RED random-drop mechanism. Therefore you need some queuing mechanism. This immediately rules out Rajib's original example, as queues can only be formed at egress. Rajib's example has 'service-policy input' which does not allow for any form of queuing and therefore does not allow for RED to be used. Now let's suppose we can move the service-policy to the outbound interface. (If this is a valid assumption again depends on the wording of the original question). On the egress interface a queue can be created in two different ways. As Chris remarked this could be the queuing on the physical interface, but in order for that to kick in, the interface needs to be congested. Only when there's enough non-SMTP traffic to load the interface up to 100% the RED mechanism will be used. In this example though I want the queuing to kick in when the 1 Mbps limit for SMTP is reached. The key to this is to use shaping instead of policing. Policing simply throws away any packets above a certain threshold, whereas shaping delays the packets above a certain threshold. This creates a queue where all the delayed packets are waiting to be sent, so now we have a queue that random-detect could act on: the shaping queue. Now how do we translate this into IOS code? Basically we need to set up a service-policy that shapes SMTP to 1 Mbps and then apply a queuing policy (using RED as a dropping mechanism) to the shaping queue. This is accomplished by setting up a hierarchical policy. I'd say the following will do what's required: policy-map SHAPE-SMTP class SMTP shape average 1000000 10000 0 service-policy RANDOM-DETECT This sets the shaping to 1 Mbps, no burst and a 10 msec Tc interval. policy-map RANDOM-DETECT class SMTP bandwidth 1000 random-detect This specifies the queuing for the shaping queue. The bandwidth setting is pretty irrelevant, as we only have one class anyway, but 1 Mbps is the most intuitive setting. The shaping queue for SMTP will use RED as the dropping mechanism. interface Serial0 service-policy output SHAPE-SMTP This applies the shaping to the outbound interface. I think that the key to this question is to really understand the difference between policing and shaping. I hope this helps, Tom Lijnse CCIE #11031 Global Knowledge -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Chris Lewis (chrlewis) Sent: woensdag 29 juni 2005 22:09 To: ccie2be; Rajib Khan; ccielab@groupstudy.com Subject: RE: Police with random detect Depends what you are trying to achieve, marking down instead of dropping excess traffc would form a queue if there is congestion on the interface. Settign random detect on the interface would do it also if the interface itself got congested, which depending on what else had to be done would need a hierarchical policy. The basic technicque for a queue to form is more traffic coming in to something (either a constrained class or a physical interface) than it can transmit :) I know this is too obvious, but that's what it is! Chris -----Original Message----- From: ccie2be [mailto:ccie2be@nyc.rr.com] Sent: Wednesday, June 29, 2005 3:01 PM To: Chris Lewis (chrlewis); 'Rajib Khan'; ccielab@groupstudy.com Subject: RE: Police with random detect Thanks Chris for getting back to me. Given Rajib config, what techniques are available to allow a queue to form? Tim -----Original Message----- From: Chris Lewis (chrlewis) [mailto:chrlewis@cisco.com] Sent: Wednesday, June 29, 2005 3:47 PM To: ccie2be; Rajib Khan; ccielab@groupstudy.com Subject: RE: Police with random detect Police and bandwidth for the same class do not appear in commonly deployed service provider QoS models, so it would not be considered a best practice, however as we know, lab questions can ask anything they want :) Any technique that allows a queue to form, gives WRED the opportunity to function. Chris -----Original Message----- From: ccie2be [mailto:ccie2be@nyc.rr.com] Sent: Wednesday, June 29, 2005 2:02 PM To: Chris Lewis (chrlewis); 'Rajib Khan'; ccielab@groupstudy.com Subject: RE: Police with random detect Hey Chris, Is it appropriate to configure both BANDWIDTH and POLICE under one policy map and would it be considered a best practice? I know that bandwidth guarantees a minimum and police sets a maximum but I wonder if this would be redundant. Also, you point out that for WRED to have any affect, there's needs to be a queue for it to work on. How should Rajib's config be modified so that a queue can form? My guess is if the exceed-action didn't drop packets, a queue would form. Do you agree? TIA, Tim -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Chris Lewis (chrlewis) Sent: Wednesday, June 29, 2005 2:45 PM To: Rajib Khan; ccielab@groupstudy.com Subject: RE: Police with random detect Hi Rajib, Looking at your policy-map, the first entry is a bandwdith command that says that under interface congestion, give class smtp 1 Mbits/sec. This implies to me that there is other traffic on this interface. Then you specify random detect, so far so good, so that if other traffic contributes to congestion and more than 1Mbit/sec of classs smtp traffic comes in, a queue will form for traffic from this class and random detect will take effect on that queue. Next however, policing is configured with no burst above the committed rate of 1 Meg allowed, and excess traffic is dropped. Random detect needs a queue to form for it to do anything. If you are policing to the rate at which you start to form a queue (as is done here when the policed rate is the same as the bandwidth assured rate) no queue is formed for this class and hence random detect has nothing to work upon. Chris -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Rajib Khan Sent: Wednesday, June 29, 2005 1:19 PM To: ccielab@groupstudy.com Subject: Police with random detect Hi I want to police smtp traffic to 1mb and no burst allowed, with policing can I configure random detect or not. Would following config achive my goal. Your help will be highly appreciated class-map smtp match access-group 120 access-list 120 permit tcp any any eq smtp Policy-map smtp class smtp bandwidth 1000 random-detect police cir 1000000 bc 187500 be 187500 conform-action transmit exceed-action drop Int s0 service-policy input smtp Thanks is advance Rajib --- Subject: Re: MQC bandwidth We are not allowed to do queuing on a Subinterface, but we can shape on a Subinterface/ so doing nested CBWFQ Policies to cheat requirements. class-map match-all Trafico_VOZ match access-group 100 policy-map HIJA class Trafico_VOZ priority 12 on sub int we are not allowed to apply it so we create another policy name parent policy-map PAPA class class-default shape average 1000000 service-policy HIJA interface Ethernet0/0.50 encapsulation dot1Q 50 ip address X.X.X.X service-policy output PAPA Victor-. simon hart wrote: >Stefan, > >What type of subinterface? > >For example if it is a frame relay subinterface you will need to configure >frame relay traffic shaping in order to assign CBWFQ. By doing so you will >either set CIR or min CIR within a Map-class Frame-relay. > >In such a case then the MQC will take half of the configured CIR or the >configured minCIR. > >CBWFQ is not supported on Ethernet subinterfaces ---- Bob: The Shape average command does not use either Bc or Be so they're irrelevant. Shape average shapes traffic to CIR. Older version of IOS (12.1) used to shape average traffic to CIR + Bc (even though IOS documentation showed something different. 12.2 T code trains will shape average traffic to CIR. Where this does apply is with the Shape Peak command. The shape peak command uses both Bc and Be using the formula "average rate (CIR) * Bc / Be". Since Bc and Be default to 8000, the formula is CIR * 2 which results in twice the effective bandwidth over time (assuming wire rate traffic at CIR * 2. -Dennis Hartmann -----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Bob Sinclair Sent: Wednesday, June 15, 2005 1:23 PM To: Thomwin Chen; ccielab@groupstudy.com Subject: Re: MQC-Based FRTS Thomwin, No, do not configure the command "frame-relay traffic-shaping" when doing MQC-based shaping. When doing MQC-based shaping remember that the "shape average" command automatically sets Be equal to Bc, so set Be explictly to 0 if the task does not require an excess burst. Also remember that if you want to shape at the DLCI level, using a map-class frame-relay, then you must shape class class-default. HTH, ---- Subject: RE: rate-limit vs. police Hi They use different policing algorithms. CAR first The CAR method uses only one token bucket, it also uses actual and compound debt to decide when traffic is in our out of contract. The following link in the Doc CD describes the CAR algorithm: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos _c/fqcprt4/qcfpolsh.htm#wp1000920 Lets explore the following command rate-limit output 1000000 187500 375000 conform-action transmit exceed-action drop This statement will limit the average throughput to 1Mbps. The Token Bucket is 187500 bytes (bc) which can extend burst (be) to 375000 bytes - it is important to remember that we are defining just one bucket here, therefore the figures are accumulative - different from MQC Police!!. By doing the maths on this one can work out that the Time interval is 1.5 second as per Cisco recommendation for CAR ( 187500*8)/1000000 = 1.5. Also the Cisco recomendation is that the extended burst be twice the standard burst. Packets that conform will be transmitted, and those that do not will be dropped. The Actual Debt and Compound Debt algorithm explained in the above link describes the behaviour of the policer once packets are exhausted from the Token bucket. The values of bc and be are used to regulate this action. Effectively the CAR policer does not aggressively police non conforming packets but behaves in a RED like fashion until a point when all non-conforming packets are dropped. Police within MQC The police command within MQC is based upon an IETF algorithm - Single Rate Three Colour Marker - rfc 2697 This policer has two token buckets, one is defined by Bc and the other by Be, therefore the figures for Bc and Be do not have to be accumulative. police 1000000 31250 1000 conform-action transmit exceed-action set-dscp 16 violate-action drop With this command we are againg shaping at a throughput of 1000000. The first token bucket is define as 31250 bytes, again by doing the math you will notice that the Tc is now 250ms. In fact if you just put the command police 1000000 this is what the IOS will default too. The exceed bucket is defined as 1000 bytes. Using the statement above the algorithm works in this fashion Time interval = 250ms Time interval 1 - Bytes offered 20000 Bc full therefore transmit 2000 bytes Time interval 2 - Bytes offered 32250 Bc full therefore transmit the first 31250 bytes (remember Bc = 31250). Be full transmit the remaining 1000 bytes and take exceed action - set dscp 16. Time interval 3 - Bytes offered 32250. Bc full therefore transmit the first 31250 bytes. Be exhausted in last time interval, therefore take violate action - drop on remaining bytes Time interval 4 - No Bytes offered. Bc full. Be still exhausted Time interval 5 - No Bytes offered. Bc full and overfilling!! Refresh Be with 1000 bytes Time interval 6 - 40000 Bytes offered. Bc full therefore transmit the first 31250 bytes. Be full transmit following 1000 bytes with exceed action of set dscp 16. Remaining 81250 bytes take violate action - drop There are also some other differences that you need to cogniscent of!! The IOS allows you to set the Be in the following command police 1000000 31250 1000 conform-action transmit exceed-action drop In this situation there really is no burst capability. As you can see anything offered in excess of 31250 bytes per interval is going to get dropped. Therefore the Be makes little sense. In fact if you do a show policy interface, you will see that the Be does not appear. Also in this way the policer is far more aggressive than CAR!! This command can be confusing as well police 1000000 31250 1000 conform-action transmit exceed-action set-dscp 16 Again, the sames as above, any packets above 31250 in any interval will have the set-dscp 16 applied, not just the Be of 1000!! Therefore if you want the algorithm to work as a 2 bucket policer you have to add the violate-action command. When to use the one of the other will vary much depend on the wording of the question I am afraid, but if you understand the subtle differences you should be able to pick the most appropriate command. Now that is explained, I let you try and work out: police cir 1000000 bc 31250 pir 2000000 conform-action transmit exceed-action set-dscp-transmit af11 violate-action drop Hope that Helps Simon ---- Good explanation Simon. However, there is no Tc in policing as there is in shaping. Tc in shaping defines the interval at which tokens are replenished in the bucket. In policing tokens are replenished at the rate of (T-T1)CIR, where T is the curent time and T1 is the time of last packet arrival. In shaping Bc defines the bits transmitted per interval to reach CIR, and therefore does not really specify any burst at all. In policing Bc does specify a burst, as you define below. This detail I think though is largely irrelevant for practical applications, however I can imagine a question on the lab that could say use a rate limiting mechanism that replemishes tokens at regular intervals (calling for shaping), or one that calls for a rate limiting mechanism that replaces tokens based off packet arrival time (calling for policing). This is my only reason for mentioning it here. ---- Mike, Changing the Bc in policing affects how often you are enforcing the policed rate. A lower Bc means that you are policing to a smaller rate more often over the second, while a higher Bc means the opposite. In either case you will still police to the same aggregate rate over the second, but how traffic bursts are propagated will be different. Remember that 1 second to the router is a huge amount of time. On a Gigabit interface you have the capability to encapsulate 1 billion bits in that single second. Suppose that you're sending 100 Megabits worth of traffic in one second on this interface. If you send 1 Megabit in the first 500ms and then 99 Megabits in the last 500ms the policing interval would affect this differently than if you had sent 1 Megabit evenly every 10ms. ---- ---------- Forwarded message ---------- From: Chris Lewis To: "Venkataramanaiah.R" , Cisco certification Date: Sun, 27 Nov 2005 09:20:13 -0800 (PST) Subject: Re: RED w/o bandwidth... Venkat, There are several concepts represented in your mail that need to be separated in order for a full understanding to be possible. I also think that some of this is not relevant to the R&S exam, but anyway, here is what I can tell you right now. First, in terms of deciding which packet to drop, FIFO is mutually exclusive from RED. One either decides to tail drop packets in the case of FIFO, or randomly drop packets before the tail drop case is reached via RED. If your question is why do I need to configure bandwidth in order to configure RED the answer is you dont J RED can be applied to an interface or a class. Looking at the interface application first interface Serial0/0 no ip address random-detect dscp-based end Then looking at the interface gives the following: sho int s0/0 Queueing strategy: random early detection(RED) So here we have no bandwidth or fair queueing defined in the configuration and RED can be applied. So the next question is, what happens when I try to apply RED to a class class-map match-all map1 match protocol icmp Router(config)#policy-map test1 Router(config-pmap)#class map1 Router(config-pmap-c)#random-detect bandwidth on the class is required to issue this command So now we have different behavior. The reason for the difference is that an interface has a given throughput capability, and when that is reached, a queue will build up and RED can act upon that queue. By contrast, a class can have any throughput capability configured on it, so there is no natural throughput level (other than the interface capability) that will build a queue to enable RED to act. So think of a class as something virtual within the router that you need to define the capabilities of in order for RED to do its thing. Now the situation changes slightly for the default class. Router(config-pmap)#class class-default Router(config-pmap-c)#rand Router(config-pmap-c)#random-detect fair-queue or bandwidth on the class is required to issue this command The difference here is that the default class uses the remaining unallocated bandwidth (unallocated to other classes), so it does not strictly need the bandwidth statement, as it knows the amount of bandwidth left and can work with that. Now RED is in fact a dropping mechanism, and it needs a queue to operate on. As classes are virtual within the router (as opposed to a physical interface) some queueing strategy needs to be defined for the class to define how to build these queues, and for the class-default you are given the additional option of defining fair-queueing. There are two other RED options to be familiar with. Flow based (for interfaces only) and the ECN option. Flow based was created for non-TCP flows that do not back off in the presence of dropped packets. The ECN option is where you can set ECN in the packet instead of dropping it, so that you do not have to rely upon the dropping of a packet to signal congestion (and by implication hosts will know to back off without experiencing packet loss). Chris "Venkataramanaiah.R" wrote: Read the last but one para as, "Why can't random detect work on a FIFO queue. What i mean here is why i cant configure RED on a FIFO queue (w/o bandwidth statement, assuming bw command changes the queue to WFQ)." --- ---------- Forwarded message ---------- From: Anthony Sequeira To: John Caronilli Date: Thu, 1 Dec 2005 19:10:09 -0500 Subject: Re: mls qos map ip-prec-dscp The switch looks at the three left most bits of the incoming ToS field to determine IP Precedence. Notice it is the FIRST THREE BITS ONLY. It then remaps to DSCP based on your map (or the default map). The possible values for IP Precedence are: 000 = 0 001 = 1 010 = 2 ... 111 = 7 The possible values for DSCP are much wider: 000000 = 0 000001 = 1 ..... 111111 = 63 Notice that the first three bits overlap between the two values as you pointed out....this is NO PROBLEM. DSCP values are fully backward compatible with IP Precedence. For example - you should give voice an IP Precedence of 5 (101). You should give it a DSCP of 46 (101110). Notice that the first three bits are the same in each case!!! This is what is meant by backwards compatible. When you are operating within a class (for example - the assured forwarding classes (AF)) - you need to be careful about bigger numbers are better. This is not true as you found out. Bigger numbers within the class indicate a higher drop priority. This is a bit counter intuitive, but it is how it works. Notice this is only WITHIN a class, however. Notice something really strange in the default IP-DSCP map? Look at IP Precedence 5 - they remark it to DSCP 40!!!! What the hell? Voice is supposed to be marked with a DSCP value of 46 per Cisco. Who knows why they picked 40 in the default map? On 12/1/05, John Caronilli wrote: > > But doesn't the DSCP bits occupy the same field as the > IP Precedence bits? The precedence bits are bits 765 > of the ToS field and the DSCP bits are 765432. So how > does the switch know if the ToS field of 00100000 is > an IP Precedence of 1 of a DSCP code of 8. ---- Edmundo, The Class-Based policer calculates burst as RATE/32. Which represents 1/4 seconds worth of traffic, converted to bytes. Odom discusses this in his book, but I do not know of any good Cisco docs on it. This is VERY different from CAR, which has a rule of thumb which suggests that Bc should be 1.5 seconds worth and Be should be twice that. The theory behind police burst values suggests that the bursts should allow a full TCP window at the configured rate. The window is calculated as RATE times Round Trip Time / 8 to convert to bytes. This would suggest that by default Cisco assumes a 250 ms RTT. What should you configure in real life? The value that best permits your flow to approximate the desired profile. This will be determined empirically. What should you configure in the lab? You should could configure precisely what is asked. If burst values are not specified, then use the defaults. If you have any doubt, ask the proctor. HTH, Bob Sinclair CCIE #10427, CCSI 30427 www.netmasterclass.net ----- Original Message ----- From: Edmundo Bodero To: ccielab@groupstudy.com Sent: Friday, December 02, 2005 2:24 PM Subject: police command values Hi group, A quick question, When we use the police command under a policy map, is the bc and be recommended formula for CAR still valid?. I mean, if we use police 256000 48000 96000 is that correct?, and if that is so, why Cisco chooses different default values (they don't follow their own rule!). I checked the archives and found one mention to it (Brian), but I could not find any definitive document in the Cisco documentation. Thanks for your help, Edmundo --- ---------- Forwarded message ---------- From: Chris Lewis To: Anwar Chalamannil , Paresh Khatri Date: Wed, 7 Dec 2005 06:07:44 -0800 (PST) Subject: Re: MQC: Using 'shape' with 'bandwidth' Taken out of context and in isolation, this is misleading. Slightly further on, that doc states the following: CBWFQ is supported in both the primary-level (parent) policy map and the secondary-level (child) policy map. However, to use CBWFQ at the secondary-level (child) policy map, traffic shaping must be configured in the primary-level (parent) policy map. You need to chape before allocating bandwidth if you are trying to use CBWFQ on a sub-interface. However on a physical interface, configuring shpaing first is not needed. Does that clear it up? Chris Anwar Chalamannil wrote: Hi Paresh ,Chris and all According to the docCD Traffic shaping and policing are not currently supported with CBWFQ. (http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt2/qcfconmg.htm If you want to use CBWFQ with the Class-Based Traffic Shaping mechanism, the following conditions must be met: A secondary-level (child) policy map must be created. This secondary-level (child) policy map is then used to configure CBWFQ by enabling the bandwidth command. Traffic shaping must be configured in the primary-level (parent) policy map. (http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hqos_c/part20/ch10/qsbcbts.htm#wp1027188 But As Paresh showed the configuration commands are well accepted on the router . Any explanations ?? Thanks Anwar ----- From: my-ccie-test@libero.it To: ccielab@groupstudy.com Date: Mon, 19 Dec 2005 04:16:59 -0500 Subject: Re: Re: Rate-limit question Hi Chris, thank you for your answer, it was very helpful!!! after your words I cheked the continue option having following result: interface ATM0/0.1 point-to-point ip address 10.10.10.1 255.255.255.252 rate-limit input access-group 199 16000 4470 4470 conform-action continue exceed-action drop rate-limit input access-group 198 32000 4470 4470 conform-action transmit exceed-action drop access-list 198 permit icmp any any access-list 199 permit icmp any any precedence immediate in this case I want to limit icmp traffic with precedence immediate to 16K while entire icmp traffic is limited to 32K. I configured rate-limit with continue option and after pinging interface with icmp packets with ip precedence 2 this is the output of show interface rate-limit. sh int rate-limit ATM0/0.1 Input matches: access-group 199 params: 16000 bps, 4470 limit, 4470 extended limit conformed 490 packets, 54880 bytes; action: continue exceeded 10 packets, 1120 bytes; action: drop last packet: 601ms ago, current burst: 2782 bytes last cleared 00:01:30 ago, conformed 4000 bps, exceeded 0 bps matches: access-group 198 params: 32000 bps, 4470 limit, 4470 extended limit conformed 490 packets, 54880 bytes; action: transmit exceeded 0 packets, 0 bytes; action: drop last packet: 605ms ago, current burst: 1792 bytes last cleared 00:01:30 ago, conformed 4000 bps, exceeded 0 bps as you can see icmp packets matched both access-group 198 and 199 as expected, confirming your words. Chris, thank you again for your explanation. I was very confused with this option in CAR!!! ---- ---------- Forwarded message ---------- From: Chris Lewis To: Scott Morris Date: Thu, 5 Jan 2006 10:47:56 -0600 Subject: Re: QoS AF priorities Hello Scott; I disagree with my undestanding of your post, although I may be misinterpreting what has been said :) With no specific drop policy configured, AF13 is no more likely to be dropped than AF41, or vice versa. Just as no specific bandwidth or preference is given to these DSCP values if no queuing policy is defined. If a drop policy is configured, the likelyhood of a packet being dropped will be defined by that policy. If random detect dscp is configued as the drop policy with no further customization the previous link describes the default behavior. But in summary, each marking has the same probaility of being dropped, but some become eligible for being dropped at different queue depths. As an example if the average queue depth in a class for af31 traffic reaches 32 packets, all further af31 packets are eligible to be randomly dropped. Whereas for af3, packets are eligible to be dropped when the average queue depth is 24 packets. WRED tuning is a complex problem that depends upon many factors, including: The offered traffic load and profile The ratio of load to available capacity The behaviour of traffic in the presence of congestion These factors vary network by network and are dependent upon services offered and on customers using those services Having said that tuning WRED is a nasty and difficult task, it does get used in production networks. The way this has been used in production provider networks has been to use different drop profiles for traffic that conforms to the SLA the customer has signed up to, compared to traffic they send that exceeds the SLA. The thinking here is that one does not mark traffic exceeding the contract to a different class (so don't re-mark a packet exceeding the SLA for business data to best efforts for example), as that introduces out of sequence issues, what one does is mark exceeding packets with a different drop probability and configure the drop policy such that all exceeding packets will be dropped prior to conforming packets in the presence of congestion. This is realised in CLI if we design things such that DSCP 32 is the conforming traffic, and exceeding traffic is marked with DSCP 8 (just taking those values as examples). random-detect dscp 8 11 33 1 random-detect dscp 32 550 600 1 A large gap between the maximum threshold for exceeding packets compared to the minimum threshold for conforming packets is there to ensure that the instantaneous queue depth will never reach the minimum threshold of the conforming traffic and hence exceeding packets will be dropped ahead of conforming packest at all times. Chris ---