[c-nsp] C2960G and output drops

Gert Doering gert at greenie.muc.de
Wed Oct 1 04:19:04 EDT 2008


Hi,

one of our switches is misbehaving, and I'm wondering whether this is a
configuration thing, or a hardware limitation.

(It's not actually a QoS thing, but it's bordering on it)

Setup: WS-C2960G-24TC-L, effectively only 4 ports active:

This is where stuff comes in (UDP audio streaming servers):

GigabitEthernet0/8 is up, line protocol is up (connected) 
  5 minute input rate 26179000 bits/sec, 3819 packets/sec
  5 minute output rate 3492000 bits/sec, 3295 packets/sec
GigabitEthernet0/12 is up, line protocol is up (connected) 
  5 minute input rate 334588000 bits/sec, 41069 packets/sec
  5 minute output rate 14453000 bits/sec, 26859 packets/sec
GigabitEthernet0/16 is up, line protocol is up (connected) 
  5 minute input rate 27730000 bits/sec, 2940 packets/sec
  5 minute output rate 1507000 bits/sec, 1976 packets/sec

And this is where it leaves the switch:

GigabitEthernet0/10 is up, line protocol is up (connected) 
  5 minute input rate 19432000 bits/sec, 32108 packets/sec
  5 minute output rate 380792000 bits/sec, 46406 packets/sec

As you see, the ports are far from saturated, and even the load from all
"ingress" ports (380 Mbit + 27 Mbit + 26 Mbit) is far from the capacity
of the "egress" port (G0/10).

But still...

GigabitEthernet0/10 is up, line protocol is up (connected) 
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 8731686

... and this is of course affecting the audio quality.

(The output port goes to a Juniper SSG550 firewall, which has no problem
keeping up with the load to about 950 Mbits/s - and if only one ingress port
is active on the switch, we can see much higher egress load without noticeable
drops)


IOS version on the switch is 12.2(46)SE, but I had (25)SEE on it before
that, and observed the same symptoms (except that (25)SEE does not 
display the output drops in the counters).

Right now, "mls qos" is *deactivated*, because we actually don't want
QoS as in "drop specific packets" here - we want "move ahead all packets!".

If I enable "mls qos", the packet drops go way up - which I read as "the
existing buffers, that are already not really huge, are split into 4 
smaller queues, and thus microbursts are causing much higher drops".


My theory is that the streaming servers are micro-bursting (send out
packets with full wire rate for 1/100s, and then do nothing for 99/100s),
and that the switch has too small buffers to join the 4 ingress ports
towards the egress ports.  But I'm not sure how to validate that.


So, here comes the questions:

 - how much buffer space per port does the 2960G have?

 - how can I find out why the switch is dropping packets?

 - what L2 switches are other people using in environments with 
   continuous high load that has "microbursts"?

 - any other tricks that people are using to make servers more well-behaved
   regarding packet sending rate?  Like "shaping traffic on the servers"
   (to distribute the packets more evenly along the time scale)?


We have other streaming customers, and they are directly connected to 
6408A or 6724 ports on 7600s, and not displaying anything unusual, at 
even higher loads (multiple ingress ports running at >800 Mbit/s for
hours, egress via port-channels).  So it's something with this 2960G...

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20081001/02168c09/attachment-0001.bin>


More information about the cisco-nsp mailing list