Trail Drops with non-congested link

[pc_varanda]

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

[lgijssel]

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

[pc_varanda]

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

[lgijssel · Accepted solution]

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

[pc_varanda]

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.

[lgijssel · Accepted solution]

Yes, the traffic shaping must be configured on the WAN link.

regards,

Leo

[Joseph W. Doherty]

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.

[Joseph W. Doherty]

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.