06-08-2012 08:56 AM - edited 03-04-2019 04:37 PM
Hy guys,
I'm having trouble with an ASR 1002 router. The WAN connection never exceeds the 196/255 on txload, and at this point the taildrops becomes a real problem.
There is no QOS configured. The remaining 25% of the bandwidth is sealed for some reason. Does someone have seen something like this before?
Regards
Solved! Go to Solution.
06-08-2012 09:36 AM
This may not be the only router in the path.?
Drops may also be caused by large speed diffs like from 1GE to 100M.
Routers do not buffer all traffic but start dropping packets to adjust for this.
The effect is that you are unable to fully utilize your WAN link.
Some improvement can be realized by configuring traffic shaping.
regards,
Leo
06-08-2012 09:56 AM
Yes, the traffic shaping must be configured on the WAN link.
regards,
Leo
06-08-2012 09:12 AM
What type of queueing is configured on the router?
If this is fair queueing you may have all traffic in one queue.
In this case the stated behavior sounds somehow plausible.
Try to set it to fifo instead.
However, you are not really providing much info.
Please note there might be other reasons for this and they may lie elsewhere in the network.
Consider packet drops and latency for example.
regards,
Leo
06-08-2012 09:19 AM
Hi Leo,
The queueing strategy is fifo.
The wan connection provides 100mbps of bandwidth. The load processing of the router is about to 2%.
What could cause these packet drops? I don't see a reason to so if there is 25% of bandwidth remaining.
regards
06-08-2012 09:36 AM
This may not be the only router in the path.?
Drops may also be caused by large speed diffs like from 1GE to 100M.
Routers do not buffer all traffic but start dropping packets to adjust for this.
The effect is that you are unable to fully utilize your WAN link.
Some improvement can be realized by configuring traffic shaping.
regards,
Leo
06-08-2012 09:52 AM
Hi Leo,
You're right. This router receives all traffic from the LAN because it is the active member of the HSRP group, however, he will balance some traffic to the standby router because the wan connections are BGP full multihomed with two different ISPs. If the as_path of the standby router is prefered, active router will send this traffic to it. In peak times the traffic on LAN side exceeds the 100M.
The traffic shaping must be done on the wan link, right?
Thanks for your replies. You were right on both.
regards.
06-08-2012 09:56 AM
Yes, the traffic shaping must be configured on the WAN link.
regards,
Leo
06-09-2012 04:15 AM
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
The traffic shaping must be done on the wan link, right?
Normally, shaping is only useful if the logical bandwidth exceeds physical bandwidth. For example, if your WAN vendor is providing your 100 Mbps on a gig connection. If the connection were 100 Mbps, shaping should not be needed.
06-08-2012 10:10 AM
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
What causes taildrops is interface congestion and overflowing the egress interface's queue. Your 75% is an average rate. In fact, a TCP flow that keeps trying to push pass available bandwidth might show an average rate about 75% as it hits 100%, has drops, slows to 50%, and works its way back to 100% to repeat the cycle.
If your TCP is ECN aware, in theory you could use WRED to optimize transmission rate without packet drop. Or, if your TCP sender was extremely sensitive to increased RTT, increasing queue depth might signal the sender to slow its flow before it overflows the egress queue.
Older TCP flows can also have their flow rate managed by selectively dropping packets using WRED. Done optimally, you can push a higher rate with fewer drops.
You can also optimize TCP transmission rates by tuning TCP rwin, either on the receiving host or with an appliance that can modify the value within the TCP packets "in flight" (the latter isn't available on an Cisco device, at least that I'm aware of).
The foregoing are different approaches to fully optimize bandwidth usage, but you might be able to improve your bandwidth usage just by increasing queue depth and/or using flow based FQ.
PS:
If your traffic congestion is caused by non-adaptive flows (most non-TCP), for those you need to control their sourcing application or provide the the bandwidth they require.
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