cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
319
Views
0
Helpful
1
Replies

SDWAN-Cedge shape average bc and be values are wrong

I want to know why the SDWAN environment uses the minimum value of Tc 4ms on the shape average bc and be calculation in a DIA/ISP interface.

https://sites.google.com/site/amitsciscozone/qos/traffic-shaping

We have several sites degraded and dropping packets because of this condition.

Service-policy output: shape_GigabitEthernet0/0/1.1

Class-map: class-default (match-any)
1608224003 packets, 698930763623 bytes
5 minute offered rate 2112000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 208 packets
(queue depth/total drops/no-buffer drops) 0/689917/0
(pkts output/bytes output) 1607276797/697918742655
shape (average) cir 50000000, bc 200000, be 200000

 

Am I missing some general configuration? is this value configurable ?

I have tried to use Adaptive QoS but is the same result.

 

 

1 Reply 1

Joseph W. Doherty
Hall of Fame
Hall of Fame

As I don't have inside Cisco information, can only but guess why 4 ms Tc is being used.  It more accurately matches a physical interface of the same bandwidth, and better supports the service needs of traffic like VoIP.

As to your drops degrading performance, that's certainly possibly, but your overall drop percentage is only about 0.04%.  Traditional drop percentages up to 1% are considered acceptable, but as that's an overall cumulative stat, we don't know if you might be having micro bursts.

Additionally, if this is a subinterface, other traffic on the port could be causing transient issues.

Basically, insufficient information to say what's the cause of the "degradation", which also isn't clearly defined.

Other causes can be due to your environment.  For example, if you're shaping to match some provider CIR, such often mimics bandwidth of the physical interface, but traditional/older Cisco shapers only counted L3, so to keep from overrunning a provider's CIR, you used to need to shape about 15% slower.