There is a bug in most of SEs for all stackable models, which makes drop statistics unusable (see CSCso81660 for example - there are lots of BugIDs with same diagnostics and keep in mind "Fixed-in is a lie). Reported numbers aren't realistic and often go both ways - increase and decrease in what appears to be a random manner. sh platform port-asic stats drop should report right value though. So, before you start tweaking, you may want to look further into it and just wait for the sane IOS release. Our SE reported it's fixed in 15.2, which isn't available for download yet.
On Thu, Dec 22, 2011 at 4:41 AM, John Elliot <[email protected]> wrote: > > Hi Guys, > > Have a pair of 2960's in a stack, one port(trunk) connects to another DC and > we are seeing ~5% packet-lossand large output drops to this DC. > > > #sh interfaces gigabitEthernet 1/0/17 counters errors > > Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize > OutDiscards > Gi1/0/17 0 0 0 0 0 > 182867 > > GigabitEthernet1/0/17 is up, line protocol is up (connected) Hardware is > Gigabit Ethernet, address is a0cf.5b87.ec11 (bia a0cf.5b87.ec11) > Description: QinQ_to_DC2 MTU 1998 bytes, BW 100000 Kbit, DLY 100 usec, > reliability 255/255, txload 41/255, rxload 23/255 Encapsulation ARPA, > loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, media type is > 10/100/1000BaseTX input flow-control is off, output flow-control is > unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 6d13h, output > 00:00:00, output hang never Last clearing of "show interface" counters > 04:02:15 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: > 183592 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second > input rate 9047000 bits/sec, 2075 packets/sec 30 second output rate 16324000 > bits/sec, 2309 packets/sec > > > As you can see, 30sec rate isnt excessive, but as the drops are outdiscards > it would appear we are getting hit by the small buffers/microburst issue. > > Done a bit of reasearch, and as we have mls qos configured(Need to as we have > to trust dscp markings), we needto look at "tweaking" the buffer allocations > on the switch to hopefully mitigate these drops. > > There appears to be a range of recommendations when it comes to these tweaks > - Hoping someone has some suggestions on what to set with "mls qos queue-set > output" to alleviate the drops?(start conservative, then apply more > aggressive if needed)....and also, does adjusting the buffers require an > outage window? > > Our traffic is primarily backup(replication which is very bursty), and > Internet > > Thanks in advance. > _______________________________________________ > 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/
