I'm a little confused as to what some of the fields on the output of a 'show interfaces' for an ethernet interface. Am I right in thinking that:
'overruns' would show frames dropped that are coming in from a server (or other device) physically connected to the switch interface ( and are coming in too fast (i.e. the interface is being overrun with traffic)
'underruns' are similar but opposite, i.e. traffic is coming into the switch from other interfaces or VLANs and is queued up to be output from the interface in question and there's too much traffic for the buffer on the interface to handle so some of it gets dropped before it can be output to the connected server
If this is the case then what exactly is 'output drops'? I've pasted the output from a 'show interface' command below. There's no underruns or overruns but there's 111157 'Total output drops'. This seems strange in itself but I've also noticed that there's no corresponding 'Total input drops'. How come?
Can anyone shed any light on this for me please?
Switch#sh int fa3/7
FastEthernet3/7 is up, line protocol is up (connected)
Hardware is C6k 100Mb 802.3, address is 000b.bfa7.f40a (bia 000b.bfa7.f40a)
Description: Link to Derbyshire House
Internet address is 10.162.254.77/30
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 66/255, rxload 63/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 4d22h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 111157
Output drops are occuring when an output buffer cannot hold the data long enough to be transmitted or when it is not able to accept more packets (i.e. buffer=full)
Another very common cause for buffer drops is qos. Lower priority traffic gets dropped while higher priority traffic is forwarded. This is not necessarily an indication of a problem but merely a mechanism for the device to regulate traffic flows.
This is a confusing one but let me see if I can help you out.
Output drops are the Count of packets dropped on the output interface.
When packets are processed, they are sent to the output queue of the outgoing interface. Output drops are caused by a congested interface. For example, the traffic rate on the outgoing interface cannot accept all packets that should be sent out.
overrun - The number of times the receiver hardware was unable to hand received data to a hardware buffer because the input rate exceeded the receiver's ability to handle the data.
underruns - The number of times the transmitter has been running faster than the router can handle.
As you can see the Output drops is oriented to the switch/router internal process of handling the packets while the overruns and the underruns is showing the number of times one side was faster that the other.
Thanks both for the replies. The thing is I've read the Cisco definition of overrun and underrun but they're not very clear, and the definition of underrun seems to conflict with what Leo sent in the Wikipedia link. In fact reading them again the Cisco definitions just create confusion. The definitions for overrun and underrun actually appear to say the same thing but with different words. And what's the receiver hardware? Would that be a server physically connected to the switch interface in question? It does seem that Cisco like to create confusion :o) Thanks.
With underruns and overruns, you're dealing with the hardware at low level, similar to CRC errors.
Only Cisco could document what would make for either a overrun or underrun error on a particular piece of hardware, however in general . . .
As an Ethernet interface receives the frame's bits, it constructs the received Ethernet frame. It needs to store the frame while it is being received and constructed. Usually the received frame is stored in some special location within the hardware of the Ethernet interface or memory reserved to it. Either is usually a very finite and limited resource.
When the whole frame is received, the Ethernet hardware usually signals the rest of the system to take the received frame so that the receivign resource can be reused. Since additional frames may continue to be received by the Ethernet inteface, if the already received frame is not extracted in a timely manner, releasing the resource being used, a later received frame will "overrun" it. Such received frames that could not be received, due to lack of Ethenet receiving resources, are lost.
"Underruns" normally indicate hardware that requires data within certain time constraints, but did not receive it when it needed it.
Of the two, both might be caused by an overly busy device, but underruns, for sending data, are often especially uncommon even then because normally the effective transmission rates just falls (e.g. increased time between frames).
I see you are posing this question given the output of a Cat6k - so I'm going to try to tailor my response to that platform.
Output drops happen when a link is congested. Imagine you have two 100MB server connections, and a 100MB uplink. (200MB -> 100MB). The 100M connection just simply won't be able to push the data if the servers are operating at capacity, and will be forced to drop whatever packets the interface is unable to serialize on the wire. These will manifest as output drops.
Underruns are exceedingly rare on hardware-based platforms. The output is a throwback from IOS, which was developed originally for SW platforms. I've yet to see a customer run into underruns on the 6k. That being said, Joseph's explanation of them is accurate. Underruns will occur when the low level transceiver tries to send data, but the buffer is still empty because the device hasn't serviced the packets yet.
Overruns often happen when an internal link between ASICs on board a module becomes congested. For example, on a WS-X6148-GE-TX, each sequential 8 ports share a 1GB pipe up to an ASIC. If two (or more) interfaces on this link are pushing an aggregate 1GB+, the system will start dropping these packets. This will manifest as overruns on the interfaces in question.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...