09-25-2013 09:51 AM - edited 03-07-2019 03:40 PM
4510 info:
License Information for 'WS-X45-SUP7-E'
License Level: entservices
Version 03.03.01.SG RELEASE SOFTWARE (fc2)
I have a packet shaper on one of my ports that connects to our service provider for all our remote branches. 13.5 mpbs is dedicated to real-time traffic and 37.5 is left for everything else. I know we are over utilizing the link for best effort traffic and are working on getting more bandwidth. We are seeing dropped packets (for best effort traffic, real time traffic is fine). I believe this is caused by our queue filling up on our shaper and the queue limit is just the default 1688 packets. My question is should I increase the queue? Is that recommended? or is just resending traffic that gets dropped better?
Service policy:
policy-map VOIP
class voice
priority
class class-default
shape average 39321600
Viewing the policy-map over one morning.
#show policy-map interface gi3/31
#show policy-map interface gi3/31
GigabitEthernet3/31
Service-policy output: VOIP
queue stats for all priority classes:
Queueing
queue limit 400 packets
(queue depth/total drops) 0/10
(bytes output) 4647901573
Class-map: voice (match-any)
29172429 packets
Match: ip dscp ef (46)
29172429 packets
Priority: Strict, b/w exceed drops: 10
Class-map: class-default (match-any)
1151446829 packets
Match: any
1151446829 packets
Queueing
queue limit 1688 packets
(queue depth/total drops) 197/43009 <----- queue depth fluctuates and total drops slowly increases over days
(bytes output) 1174686093970
shape (average) cir 39321600, bc 157287, be 157287
target shape rate 39321600
Solved! Go to Solution.
09-25-2013 04:30 PM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Answer depends on the service needs of your traffic.
Realize TCP was originally designed to use up to host's interface's full bandwidth. TCP "discovers" available bandwidth by increasing its transmission rate until it "sees" an issue (like packet drops). I.e. this means, if you have TCP traffic, some drops are perfectly normal.
What you want to avoid is dropping packets from non-rate adaptive traffic or excessively dropping ordinary TCP traffic.
PS:
BTW, creating extremely large queues may decrease drop rate, but then creates queuing latency, which can also detrimental to some traffic types.
09-25-2013 04:30 PM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Answer depends on the service needs of your traffic.
Realize TCP was originally designed to use up to host's interface's full bandwidth. TCP "discovers" available bandwidth by increasing its transmission rate until it "sees" an issue (like packet drops). I.e. this means, if you have TCP traffic, some drops are perfectly normal.
What you want to avoid is dropping packets from non-rate adaptive traffic or excessively dropping ordinary TCP traffic.
PS:
BTW, creating extremely large queues may decrease drop rate, but then creates queuing latency, which can also detrimental to some traffic types.
09-26-2013 12:16 PM
Thanks for the reply. I'll probably leave the queue limit alone till we get more bandwidth.
Jeremy
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide