interface output drops and speed

[tedauction]

Hello, I have a switch interface connected via 100Mbps to a client PC.

I see there is a very percentage of output drops occurring on this port. There is no outbound QoS on this port so I am wondering why the drops are occurring. I also see that the 5 min output rate is only approx. 58000bps. Why is this the case if the PC has a 100Mbps NIC ?

Thanks kindly for any help.

GigabitEthernet2/0/4 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 006c.bcc6.4f04 (bia 006c.bcc6.4f04)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/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 00:00:24, output never, output hang never
Last clearing of "show interface" counters 02:55:56
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 526778  (526778 / 698304 packets output = 75.4% drop rate)
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 58000 bits/sec, 29 packets/sec
285141 packets input, 84105398 bytes, 0 no buffer
Received 4209 broadcasts (3909 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 3909 multicast, 0 pause input
0 input packets with dribble condition detected
698304 packets output, 563056520 bytes, 0 underruns
526778 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

[Georg Pauwen]

Hello,

not sure what switch you have and which IOS you are running, but this might be the bug below. Unless you really experience issues on that port other than the fact that the counters are high...

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtq86186

[pwwiddicombe]

From the output you have shown

5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 58000 bits/sec, 29 packets/sec

this looks more like whatever is connected to the port isn't actually using it, and that you have 58k worth of broadcast traffic on the network side being sent to that port.  Either the device connected to the port is just a switch or repeater with no other connected device, or the connected device has another path (i.e. second nic or running wireless) for its return traffic.

[tedauction]

Hello, thanks for all the replies. The switch is a stack of 2 x WS-C3850-48P running 03.06.04.E.

There are about 10 different ports including a port channel all experiencing a high level of output drops between 10& and 80%. There are only PC and phones connected to those ports.

Just to confirm - the output traffic/drops refer to traffic leaving the switch output buffer headed to the connected PC/Phone - and the input traffic is traffic coming in to the switch interface input buffer - is that correct ? 

Here is an example of another port that is doing the same thing:

GigabitEthernet2/0/2 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 006c.bcc6.4f02 (bia 006c.bcc6.4f02)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/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 00:00:19, output never, output hang never
Last clearing of "show interface" counters 19:14:57
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 1421069   (1421069 / 1741010 = 81.6% dropped)
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 9000 bits/sec, 10 packets/sec
723068 packets input, 207989017 bytes, 0 no buffer
Received 9025 broadcasts (8564 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 8564 multicast, 0 pause input
0 input packets with dribble condition detected
1741010 packets output, 858029806 bytes, 0 underruns
1421069 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

Thank you kindly.

[Mark Malone]

Hi

The device attached to the port could be sending burst traffic from an application that's temporarily flooding the buffer on the 3750 which are very low buffers , this will cause traffic to be dropped as there is no where for it to be stored to be sent , its difficult to capture it if you don't have specific software that can do it but you can do it through wireshark , couple of examples below how to below, you could span the port as well to see if there is corrupted traffic coming from the nic or anything irregular ? 

http://www.cisco.com/c/en/us/support/docs/lan-switching/switched-port-analyzer-span/116260-technote-wireshark-00.html

https://notalwaysthenetwork.com/tag/output-drops/

[Joseph W. Doherty]

BTW, on many Cisco switches, QoS is often all or nothing regarding whether its active on ports, even when they don't have specific port QoS commands.  On some switches, like the 3750 series, its default QoS settings often increase drop rates.