[c-nsp] Constant output drops on etherchannel

Klementina Miloslava kmiloslava at tacorp.us
Fri Jan 14 22:25:34 EST 2011


I'm guesing that your problem is less of a buffer problem and more of a 
bandwidth problem.  I bet you are using etherchanel so that you can have 
more than 1Gbps of bandwidth.

However, what you didn't expect is that the etherchannel isn't evenly load 
balanced.  In fact, it's not load balancing at all, it's load sharing. 
So, as a result you have one interface approaching the 1Gbps mark.  As 
others have already pointed out, you begin to drop when you fill the 
buffers.

So, instead of adding bandwidth (faking it) with etherchannels you should 
consider adding true bandwidth by increasing the interface speed. Consider 
10Gbps instead.

I can only assume that the buffers on a 10Gbps interface will be a little 
deeper.  But I'd ask other to comment on this.

So, if you can't add bandwidth, then you should consider re-engineering 
the traffic patterns to reduce bandwidth requirements.  So, since you are 
trunking multilpe vlans over you etherchannel, you should consider 
carrying each vlan over it's one dedicated interface.  This may or may not 
working depending on what's happening on those vlans, but the idea is to 
reduce the load on each of the circuits.

In the end you may be asking too much out of that switch.

Klementina

On Fri, 14 Jan 2011, Dan Letkeman wrote:

> So is there any way to increase the buffers without causing more
> damage?  Or is this a hardware limitation?
>
>
> On Fri, Jan 14, 2011 at 3:54 PM, Gert Doering <gert at greenie.muc.de> wrote:
>> Hi,
>>
>> On Fri, Jan 14, 2011 at 12:28:03PM -0600, Dan Letkeman wrote:
>>> 3560 or 3560G.
>>
>> Lame switches with too-small buffers.
>>
>> [..]
>>> I do have auto qos enabled for some of the phones I have connected to
>>> the switches, but I don't have any qos on the etherchannel trunks.
>>
>> Turning *off* qos will reduce the amount of drops you see (what qos does
>> is "take tiny buffers, spread over 4 different queues, and all of a
>> sudden your traffic only has 1/4th the buffer space available").
>>
>> Alternatively, you could fiddle with qos to give all buffers to
>> a single queue, and put all traffic in that queue, but that's
>> effectively turning it off...
>>
>> gert
>> --
>> USENET is *not* the non-clickable part of WWW!
>>                                                           //www.muc.de/~gert/
>> Gert Doering - Munich, Germany                             gert at greenie.muc.de
>> fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
>>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list