cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
655
Views
0
Helpful
2
Replies

Management traffic while shaping

Alex Mac
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

Joseph W. Doherty
Hall of Fame
Hall of Fame
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

Joseph W. Doherty
Hall of Fame
Hall of Fame
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.

Thank you Joseph
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco