I use a number of 3560Gs as distribution switches in my co-lo farm, with 4G uplinks to 4948s. The load is fin-svcs, and can be quite bursty, tends to be a lot of small packets, but with a mix of larger stuff and standard file transfer etc.
I've been seeing a number of output drops on the etherchannel ports to the 4948s, as well as to the servers themselves. What's an output drop mean, in a 3560 context? Queue to the host is full? Host interface already maxed out, "there was a packet on the wire being transmitted to the host, so sorry I'll drop the packet"? Or can it be an ingress/switching decision of some sort? How deep is the individual buffer/ring on a gig PHY? Or is it buffered per-ASIC? (Doesn't seem to be) Is there a way to tell the 3560 to buffer more aggressively? The 4948s don't really have any of these problems, and when I moved some of the hosts to the 4948s which were showing output drops (to the server from the switch), the problems went away, so either the 4948 buffers better, transmits better, or just doesn't log as well. (Yes, the 4948 is a better switch. But it's not like the 3560s are oversubscribed either - if they're doing 1Mpps at peak it'd be a miracle. It's a finsvcs load but it's not THAT intense, just bursty.) Then there's this mysterious output from "sh cont eth port-asic stat" wherein I get a number (not huge) of "RxBuffer Drop DestIndex Cou". Huh? Not documented anywhere; trying to pull info out of TAC but it's a slow process. Thanks, -bacon _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
