shape average and CBWFQ - understanding question

[thecky]

Hi,

I have a question about the "shape average" command in combination with BC, BE values and CBWFQ.

It's maybe more an understanding question. Assume I have the following config:

policy-map TUN-QOS-CHILD
class VOICE
priority percent 10
class WEB
bandwidth percent 40
class DATA
bandwidth percent 45
class SCAVENGER
bandwidth percent 5
!
policy-map TUNNEL-WITH-QOS
class class-default
shape average 40000000 400000 400000
service-policy TUN-QOS-CHILD
!
interface Tunnel1
bandwidth 40000
service-policy output TUNNEL-WITH-QOS

As far as I know, in each TC is the BC send and the BE (if the BC tokens are less than the configured value). But when I have also a CBWFQ in the configuration - how is the right processing? Is it like as in the following image?

Shape average

Or I'm totally wrong?

Thanks for explaining.

[Joseph W. Doherty]

Unless there's been changes in later IOS versions, shape average doesn't use BE.

If shaper queues traffic, it would be dequeued based on your child policy.

If your looking for more information, let us know.

[M02@rt37]

Hello @thecky,

When the traffic passes through the interface, the "shape average" command will shape the overall traffic to the configured average rate of 40 Mbps. Any excess traffic beyond the shaping rate will be queued or dropped based on the shaping parameters.

The CBWFQ policy-map will then prioritize and allocate bandwidth to the different classes of traffic based on their assigned percentages. The VOICE class, being assigned a priority, will receive preferential treatment and will be sent first. The remaining bandwidth will be shared among the WEB, DATA, and SCAVENGER classes based on their assigned percentages.

[Joseph W. Doherty]

"Any excess traffic beyond the shaping rate will be queued or dropped based on the shaping parameters."

Just to add a few points to further clarify how the shaper operates . . .

"the shaping rate"

Actually, transmission rate is whatever the medium supports.  The shaper measures the volume being transmitted during Tc, and if the volume exceeds what the "shaped rate" would provide, during the same Tc, the excess is not transmitted.

"Any excess traffic beyond. . . will be queued or dropped"

It's a bit more complicated, because there can be currently arriving traffic and/or earlier traffic already queued.  Again, the shaper works to insure the "shaped rate's" (volume, during a Tc) is not exceeded.

When new traffic exceeds the "shaped rate" volume capacity, that excess cannot be transmitted, so it will be queued or dropped, but often there are various queue resources and various drop management approaches.  For example, with everything else being equal, new web traffic might be queued where otherwise new scavenger traffic might be dropped.  Some platforms have additional specific queue space management configuration options, some don't.  Additionally, Cisco doesn't fully document exactly how it all works (I suspect, sometimes a shaper might have its own "queue" distinct from the child policy queues - which, if true, might have somewhat a similar impact as between the CBWFQ policy queues and the hardware interface FIFO queue).