Hi Kim, Just a thought, if you look at the order of operations, egress QoS classification happens way before output queuing. It's possible that the packet match counters go up when the packet is classified and has nothing to do with whether it was buffered in software queues or not.
cheers, Ben. From: Kim Pedersen <[email protected]<mailto:[email protected]>> Date: Sat, 25 Feb 2012 09:15:12 +0100 To: George Leslie <[email protected]<mailto:[email protected]>>, IPExpert Study List <[email protected]<mailto:[email protected]>> Subject: Re: [OSL | CCIE_RS] Shaping and shaping queues - OT Hi George, Its a good suggestion, but here's the thing. I have tried a couple of things: 1) make the ICMP ping 36 bytes (288 bits) with my original Bc and Be values and only source 1 echo. With this configuration there should be enough tokens available in Bc to send the packet in the first Tc without putting the packet into the shaping queue. Even with this configuration it _still_ is counted in the shaping queue (please note i say counted, as I'm still not sure that its listing there is a real indication that in fact it went in there). Serial0/1/0 Service-policy output: OVERALL Class-map: class-default (match-any) 1 packets, 36 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: any Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 1/40 shape (average) cir 20000, bc 500, be 500 target shape rate 20000 Service-policy : SUB-POL queue stats for all priority classes: Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 1/40 Class-map: ICMP (match-all) 1 packets, 36 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: protocol icmp Priority: 10 kbps, burst bytes 1500, b/w exceed drops: 0 2) Change the Bc (and Be) to a much larger value, to propagate larger bursts: Service-policy output: OVERALL Class-map: class-default (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: any Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0 shape (average) cir 20000, bc 8000, be 8000 target shape rate 20000 R2#sh policy-map int Serial0/1/0 Service-policy output: OVERALL Class-map: class-default (match-any) 1 packets, 100 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: any Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 1/104 shape (average) cir 20000, bc 8000, be 8000 target shape rate 20000 Service-policy : SUB-POL queue stats for all priority classes: Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 1/104 Class-map: ICMP (match-all) 1 packets, 100 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: protocol icmp Priority: 10 kbps, burst bytes 1500, b/w exceed drops: 0 Even so it is still listed in there! Lets give it some more pings: Service-policy output: OVERALL Class-map: class-default (match-any) 10 packets, 1000 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: any Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 10/1040 shape (average) cir 20000, bc 8000, be 8000 target shape rate 20000 Service-policy : SUB-POL queue stats for all priority classes: Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 10/1040 Class-map: ICMP (match-all) 10 packets, 1000 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: protocol icmp Priority: 10 kbps, burst bytes 1500, b/w exceed drops: 0 So great suggestions but it still doesn't seem to make much practical sense. As a side note, please note i have also tried not using a LLQ as ICMP, and that it still doesn't seem to be correct. Its important to to note at this points, that i stilll know how this works, i am just not sure that IOS counts provides us with numbers we can use. For example, I'm sure that when anyone looking at the output above, and not doing the math behind it, would believe that 10 packets have indeed been in the shaping queues. I just can't see how that should be the case based on the math. Thanks again George. I appreciate the suggestions. Sincerely, Kim Pedersen On Feb 25, 2012, at 12:35 AM, George Leslie wrote: Hi Kim, Right, I've gotcha. you have CIR set to 20000, and Bc to 500. That gives at Tc of 25 ms ( 500 bits / 20000 bps). However, the size of your token bucket is 500/8 = 62.5 bytes, and excess burst the same. So, when a 100 byte ping arrives, it is > Bc so has exceeded the CIR for that timeslot. So shaping is active. It needs to wait for the second Tc for a Be to accumulate before it can be sent. Also, and something I don't know (it would need a sniffer)... I see your round trip time is 12ms. If IOS release the next ping as soon as it gets the previous reply back, it could be releasing pings at t = 0ms, t = 12ms and t = 24 ms. That could be 300 bytes of payload, trying to use 62.5 bytes of Bc. Shaping would definitely be active!! I see you configured just the average shaping rate with no explicit Bc or Be. IOS has picked default of 25ms. If you read Odom, it states that if shaping rate is < 320kbps, then it should default to 8000 bits of Bc and Be. Clearly this did not happen here. I did notice that you have no bandwidth command on the serial. Interesting to see the change in Bc and Be if you put "bandwidth 128" on the interface, so see if IOS is picking up the rate, not from the shape command but from the interface bandwidth command??? Or you try an explicit set of Bc to 8000 bits to see the difference... George. Subject: Re: [OSL | CCIE_RS] Shaping and shaping queues - OT From: [email protected]<mailto:[email protected]> Date: Fri, 24 Feb 2012 23:40:03 +0100 CC: [email protected]<mailto:[email protected]> To: [email protected]<mailto:[email protected]> Hi George, I actually do have the book, and have read it more than once concerning this issue. In the book, it is clearly stated that when shaping is not active (i.e.. you are able to use tokens from your token-bucket to send the packet), your packet bypasses the entire shaping queues and next step is into software queues (only if the hardware queue is full). This is clearly illustrated on page 377. Interface congestion is a another discussion completely, because thats where your software queues comes into place as well as the scheduling mechanism for emptying these. So lets say that my 3 packets arrive at the same time. They are conforming to my shaping policy, so theres no need to put these into shaping queues and invoke that scheduler. Instead, if the hardware queue is full (3-4 packets) the packets would go into the software queues. The two are completely separate queues. My issue with the thing is basically that even if you don't shape anything, Ie. send a packet every 3-4 seconds, it still gets incremented in the output of "show policy-map int" statistics. This is counter-intuitive to me. Hope that clarifies it. Thanks, On Feb 24, 2012, at 11:18 PM, George Leslie wrote: Hi Kim, If you have read the Wendell Odom guide about QoS, then the answer is in there. The issue comes with what "congestion" means in terms of QoS. A lot of people believe, as you state below, that: congestion means offered rate > shaped rate. While this is certainly true, there is another caveat with this. Actually, shaping comes active when there is no room left in the tx-ring (aka hadware queue) of the interface. The imposition of certain queueing techniques makes IOS decrease the number of packets that can be held in the hardware queue to a very low value, something like 2-3 packets (I forget the exact number but it is shown in the Odom guide). So, shaping becomes active when a packet arrives when there is no room left in the very small interface hardware queue. At this point, it is held in the shaping queues and shaping stays active until the queues empty. So, all that needed to happen in your case was 3 packets to arrive at the interface at the same time, and BAM...shaping is active. After that, subsequent packets that arrive are subject to shaping, and held in the shaping queues. While in the shaping queues, the scheduler picks packets for release based on the child policy: so child policy will determine the next packet to get sent, but parent policy selects the shaping rate and when it is released. As the shaping rate is almost certainly less than line speed of the outbound interface, this helps ensure that shaping is active most of the time. This is what you want!!! If you shape traffic at all, it is to get round another issue e.g. central site blocking, speed mismatch between hub and spoke sites, CIR purchased from WAN provider, that sort of thing. You want shaping to be active, so YOU, via the child policy, can determine the packets that get released, their order (i.e priority vs. bandwidth allocation etc). As my old physics teacher used to say, perform a little thought experiment here. Let's say that the same rule applies, that shaping only becomes active when the hardware queue is full (this makes sense, as if the hardware is NOT full, why bother to put a packet through shaping queues when it will get straight through them into the hardware queue anyway). Imagine that the hardware queue could contain 1,000,000,000,000 packets. This would mean that shaping would NEVER become active, the whole queue becomes a FIFO queue, and you have no control over the order of packet release. By setting the size of the hardware queue artificially low, it makes shaping become active much earlier, which gives you the control. HTH, at least this is my understanding. George > Date: Fri, 24 Feb 2012 14:00:46 +0100 > From: [email protected]<mailto:[email protected]> > To: [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]> > Subject: [OSL | CCIE_RS] Shaping and shaping queues - OT > > Hi All, > > When using shaping and shaping queues, i ran into a behavior i didnt expect. > > According to QoS exam guide, packets should only enter shaping queues > when shaping is active. If shaping is not active (packets are > conforming) it should bypass the shaping queues and go directly to > software queues and then TX-ring. > > For example, defining our PARENT policy: > > policy-map OVERALL > class class-default > shape average 20000 > service-policy SUB-POL > > And our "CHILD" policy: > > policy-map SUB-POL > class ICMP > priority 10 > class SSH > bandwidth 8 > class TELNET > > And applying the OVERALL policy outbound on an interface: > > R2(config-if)#do sh run int s0/1/0 > Building configuration... > > Current configuration : 132 bytes > ! > interface Serial0/1/0 > ip address 192.168.25.2 255.255.255.0 > load-interval 30 > no keepalive > clock rate 128000 > service-policy output OVERALL > end > > I would expect my packets NOT to hit any shaping queues unless they > exceed 20kbit > > Doing a ping reveals a different behavior: > R2#ping 192.168.25.5 rep 50 > > Type escape sequence to abort. > Sending 50, 100-byte ICMP Echos to 192.168.25.5, timeout is 2 seconds: > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!! > Success rate is 98 percent (49/50), round-trip min/avg/max = 12/14/16 ms > R2#sh policy-map int > Serial0/1/0 > > Service-policy output: OVERALL > > Class-map: class-default (match-any) > 51 packets, 5324 bytes > 30 second offered rate 3000 bps, drop rate 2000 bps > Match: any > Queueing > queue limit 64 packets > (queue depth/total drops/no-buffer drops) 0/1/0 > (pkts output/bytes output) 50/5420 > shape (average) cir 20000, bc 500, be 500 > target shape rate 20000 > > Service-policy : SUB-POL > > queue stats for all priority classes: > Queueing > queue limit 64 packets > (queue depth/total drops/no-buffer drops) 0/1/0 > (pkts output/bytes output) 49/5096 > > Class-map: ICMP (match-all) > 50 packets, 5000 bytes > 30 second offered rate 2000 bps, drop rate 2000 bps > Match: protocol icmp > Priority: 10 kbps, burst bytes 1500, b/w exceed drops: 1 > > > Class-map: SSH (match-all) > 0 packets, 0 bytes > 30 second offered rate 0 bps, drop rate 0 bps > Match: protocol ssh > Queueing > queue limit 64 packets > (queue depth/total drops/no-buffer drops) 0/0/0 > (pkts output/bytes output) 0/0 > bandwidth 8 kbps > > Class-map: TELNET (match-all) > 0 packets, 0 bytes > 30 second offered rate 0 bps > Match: protocol telnet > > Class-map: class-default (match-any) > 1 packets, 324 bytes > 30 second offered rate 0 bps, drop rate 0 bps > Match: any > > queue limit 64 packets > (queue depth/total drops/no-buffer drops) 0/0/0 > (pkts output/bytes output) 1/324 > > > As can be seen, all packets seems to traverse the Shaping queue ICMP, > even though most of the packets (all near one according to this) > should not be shaped. > > Anyone know if this is an implementation thing in IOS, that the > counters will still be updated even though they in reality bypass the > queues or if something else is going on here? > > Just curious. > > Sincerely, > Kim Pedersen > > -- > // Freedom Matters > // CCIE #29189 > // www.packet-forwarding.net > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com > > http://onlinestudylist.com/mailman/listinfo/ccie_rs // Freedom Matters CCIE #29189 http://www.packet-forwarding.net // Freedom Matters CCIE #29189 http://www.packet-forwarding.net _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com http://onlinestudylist.com/mailman/listinfo/ccie_rs _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com http://onlinestudylist.com/mailman/listinfo/ccie_rs
