General question about shaping

[Peter Paluch]

Dear friends,

This discussion relates to IOS-based software routers.

It has been my implicit assumption that a configured shaping mechanism always works in conjuction with the current queueing policy on an egress interface, i.e. it merely allows or disallows to dequeue a packet from whatever software queue it is in (FIFO, PQ queues, CQ queues, WFQ conversation queues, CBWFQ conversation queues, etc.) if the shaper's token bucket has been exhausted.

However, a colleague of mine is very adamant that if a shaper is configured on an interface or in a policy-map, it creates its own separate queue in which it stores the delayed packets. At first, I considered this idea ridiculous because of the obvious scheduling problems if yet another queue(s) popped up in the system. However, the existing documentation on the topic is so vague that I am no longer sure.

Can anyone shed more light on this? Every help is very much appreciated! Thank you!

Best regards,

Peter

[Edison Ortiz]

Peter,

The shaper on pre-HQF works in similar fashion as the GTS illustration we are discussing.

Once the classes are processed (middle section of the diagram), the shaper will use WFQ before sending

the packets to the transmit queues. We put the shaper in the parent class so in effect is the last step

from the order of operations the router will perform before hitting the transmit queue.

You can't guarantee bandwidth you don't have. Once you apply a shaper to an interface or a class,

the available bandwidth get recalculated.

If you have a 10Mbps physical link and the Shaper is 5Mbps, all the bandwidth calculation will be

made based on 5Mbps. If the aggregate of all classes is greater than the bandwidth available by

the shaper, you will likely receive an error.

I suggest you settle down because we are definitely running around in circles here

[Peter Paluch]

Hi Edison,

Yeah, some time off would do good. I already feel dull enough You have had a great patience with me, and I appreciate that immensely. Thank you!

Best regards,

Peter

[Kishore Chennupati]

Wow. I am loving this post. So much knowledge been put in here. I wish I could give 10 stars to each but im only limited to 5+ so I give that to ya'll.

Will continue to monitor this thread closely.

[bcoverstone]

I have been using HQF for a while now and I have been using shapers inside of shapers.  You can define the queue size for each class, and each class can contain an entire policy.  So in essence you are limiting that sub-policy to that queue size.

For example, let's say that I have 50Mbits of bandwidth for everything (that's the top level shaper) that is set for 32768 as a queue size.  Both the shaper and queue size apply to the sub-policy-map.

Here's a sample snippet config demonstrating the HQF shapers:

policy-map INCOMING_ISP
 class class-default
  set qos-group 1

class-map match-any FROM_ISP
 match qos-group 1

policy-map OUTGOING_INTERIOR
 class FROM_ISP
  shape average 50000000
  queue-limit 32768 packets  <-- this is the TOTAL amount of packets that can be queued for this class
   service-policy TRAFFIC_SHAPE_OUT

policy-map TRAFFIC_SHAPE_OUT
 class ACK
  bandwidth percent 5
  fair-queue 1024
  queue-limit 1024 packets
 class RDP
  bandwidth percent 10
  fair-queue 1024
  queue-limit 1024 packets
 class HTTPS
  bandwidth percent 20
  fair-queue 1024
  queue-limit 1024 packets
 class MESSAGING
  bandwidth percent 10
  fair-queue 1024 <-- by doing fair queueing, each flow will get their own
  queue-limit 1024 packets <-- this class is limited to 1024 packets total, which is part of the 32768 limit of the parent policy
  shape average 10000000 <-- this limits our email messaging class to 10Mbits
...

Also, don't forget to set the interface's maximum queue size, or it won't do much good. 

interface gi0/1

 service-policy output OUTGOING_INTERIOR

 hold-queue 32768 out

You can see how many packets that are sitting/dropped in the shaper queue at every level using the following command:

show policy-map int gi0/1 output

Keep in mind when the shaper kicks in, the CPU can go up quite a bit because a lot of packets have to be determined if they need to be delayed or dropped, which apparently CEF can't do by itself?  I don't know, haven't found much documentation on the effects of a high Mbps shaper.  I just know the CPU can spike when limits are hit.  So be careful, especially if you are shaping high bandwidth in both directions.