No. Drops are happening even when its not under load. Has nothing to do with bandwidth.
On Fri, Jan 14, 2011 at 9:25 PM, Klementina Miloslava <[email protected]> wrote: > 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 <[email protected]> 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 >>> [email protected] >>> fax: +49-89-35655025 >>> [email protected] >>> >> >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
