cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
223
Views
0
Helpful
2
Replies
Highlighted
Beginner

Management traffic while shaping

Hi folks,

 

while talking of shaping outgoing traffic with a network architect I was told that limiting it, for instance to the 80% of the declared bandwidth of an interface (it might be a tunnel), is not only advantageous because we limit the packet drops (with regard to this the longer the queue the better) but also because we make space for management traffic.

 

Just to give an idea the policy should be defined in this way

policy-map GRE_OUT
 class class-default
  queue-limit 512 packets
!
policy-map Shape_GRE_OUT
 class class-default
  shape average 80000000 account user-defined 24
   service-policy GRE_OUT

 

I was not completely convinced but then I tried to find an explanation for myself and I wonder if shaping is only applied to traffic that is forwarded by a router and doesn't apply to self-originated traffic. Of course forwarded packets and self-originated ones then do compete to get out of an interface.

 

May anybody validate my reasoning, am I wrong? Am I right? And why?

 

Sorry for such a basic question but I could not find a clear answer on the web or on the community.

 

Thanks,

 

Alex

Everyone's tags (2)
1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
VIP Expert

Re: Management traffic while shaping

Either your network architect is misinformed or something got lost in the "translation" when your architect was talking with you.

That said, when and where a shaper is useful/necessary, setting it to a bandwidth slower that nominal bandwidth can be important if the shaper doesn't account for L2 overhead (and I suspect many of Cisco's shaper implementations do not). In such cases shaping somewhere between 10 to 20% "slower" usually allows for the typical/average L2 overhead.

As to shaping being beneficial, for something like management traffic, again when otherwise not really needed, might be due to the fact that I believe some of Cisco's shapers actually create a FQ or WFQ for shaped packets that are being queued. Generally for queued congestion, FQ/WFQ is much, much better for light bandwidth flows competing with heavy bandwidth flows (like a large data transfer) when queued using the typical/default FIFO.

I believe interface QoS, including shaping, applies to all traffic on the interface, including device self-originated traffic.

View solution in original post

2 REPLIES 2
Highlighted
VIP Expert

Re: Management traffic while shaping

Either your network architect is misinformed or something got lost in the "translation" when your architect was talking with you.

That said, when and where a shaper is useful/necessary, setting it to a bandwidth slower that nominal bandwidth can be important if the shaper doesn't account for L2 overhead (and I suspect many of Cisco's shaper implementations do not). In such cases shaping somewhere between 10 to 20% "slower" usually allows for the typical/average L2 overhead.

As to shaping being beneficial, for something like management traffic, again when otherwise not really needed, might be due to the fact that I believe some of Cisco's shapers actually create a FQ or WFQ for shaped packets that are being queued. Generally for queued congestion, FQ/WFQ is much, much better for light bandwidth flows competing with heavy bandwidth flows (like a large data transfer) when queued using the typical/default FIFO.

I believe interface QoS, including shaping, applies to all traffic on the interface, including device self-originated traffic.

View solution in original post

Highlighted
Beginner

Re: Management traffic while shaping

Thank you Joseph