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
                                          
_______________________________________________
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

Reply via email to