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 di d 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] Date: Fri, 24 Feb 2012 23:40:03 +0100 CC: [email protected] To: [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] > To: [email protected]; [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 MattersCCIE #29189http://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
