Hi Ben, Exactly. Thats what I'm thinking too. However if thats the case, its extremely misleading. Unless this is a proven fact and common knowledge, one would look at these counters and deduct that shaping must have been occurring, even though thats probably not the case. Do you agree?
I am fairly certain that this has to do with some internal IOS structure/classification as all packets gets matched no matter what you do with your shaping queues. To confirm the process thats outlined in the QoS exam book (page 377), Ivan Pepelnjak also has a diagram, acknowledging the process as previously described. So, is it safe to assume, that we have a consensus that this is IOS related and not related to actual shaping queues? Thanks! Kim On Feb 25, 2012, at 12:05 PM, Ben Hughes wrote: > 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 > // 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
