And just as in monitoring traffic, there can be different sources for very similar data. The
few sections discuss various sources of fault and error data.
for Ethernet Errors
The following list shows the MIB objects you can poll to collect the statistics on Ethernet interface errors:
ifInErrors from RFC 2233 For an Ethernet interface, this counter is the sum of three error conditions: alignment, giants, and FCS errors.
dot3StatsAlighnmentErrors, dot3StatsFrameTooLongs, dot3StatsFCSErrors from RFC 2358 These three variables summed together equal ifInErrors.
etherStatsCRCAlignErrors, etherStatsJabbers from RFC 1757 These variables are only available on the 2500 routers and Catalyst switches. Summed together, they equal ifInErrors.
For Ethernet, any framing error or data corruption is bad because it causes the MAC layer to discard the frame. Any request for retransmission of the lost frame must come after timeouts from the upper-layer protocols. Even very small
of framing errors can cause major degradation in performance.
Most framing errors and data corruptions are due to a physical layer problem such as a faulty interface or bad cable. In general, it is best to monitor ifInErrors because it is the sum of the main types of framing errors.
MIB Variables for Ethernet Collisions
The following list shows the MIB objects you can poll to collect the statistics on Ethernet collisions:
dot3StatsSingleCollisionFrames, dot3StatsMultipleCollisionFrames from RFC 2358 These counters are available on either switches or routers. As their
indicate, they are the number of frames that
either a single collision or multiple collisions before transmission was possible.
etherStatsCollisions from RFC 1757 The total number of collisions (single or multiple) on a given interface.
The RMON collision counter is easier to monitor because it is one object with the complete count of all collisions, but it is available only on 2500 routers and Catalyst switches. However, for the 2500 routers, the lance Ethernet chip used will detect collisions only when transmitting. Do not use this counter on the 2500 router to get collision counts for the whole segment. For other routers, the dot3 MIB objects are the best choice. Remember that collisions are natural on shared Ethernet or half-duplex Ethernet. The presence of collisions does not mean there is a problem. It is important to baseline the collision rate on a given segment and then watch for sudden inexplicable
However, on a full-duplex segment, you should see no collisions. The presence of collision on a full-duplex segment often means that one interface on the link is configured for half-duplex transmission and the other is for full-duplex transmissions.
CLI Commands for Ethernet Errors
For routers, the best show command for examining Ethernet interface errors is the
command. It gives in details the current state of the interface. Example 13-4 provides sample output for
Example 13-4 Using
to get error information on a router's Ethernet interfaces.
sh int fa0/0
FastEthernet0/0 is up, line protocol is up
Hardware is cyBus FastEthernet Interface, address is 0060.5490.f800 (bia
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec), fdx, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:01, output hang never
Last clearing of "show interface" counters 00:43:40
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 2376 bits/sec, 27 packets/sec
5 minute output rate 1000 bits/sec, 7 packets/sec
3653980 packets input, 269895525 bytes, 0 no buffer
Received 3499 broadcasts, 0 runts,
1119 input errors,
,0 overrun,0 ignored,0 abort
0 watchdog, 744 multicast
0 input packets with dribble condition detected
1507771 packets output, 161101301 bytes, 0 underruns
0 output errors, 0 collisions
, 2 interface resets
0 babbles, 0 late collision
, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
The annotated information in Example 13-4 is as
runts: The number of input packets discarded because they were less than 64 bytes long.
giants: Equivalent to jabbers, the number of packets discarded because they were greater that 1518 bytes long.
CRC: The number of input frames where the checksum calculated by the router does not match the checksum at the end of the frame.
input error: The total number of errors.
collisions: The number of frames that had to be retransmitted because of a collision.
interface resets: The number of times the interface has been reset—either by an internal error condition or through an administrative shutdown.
frame: The number of frames received with a CRC error and a non-integral number of octets. Could be the result of a collision or a faulty interface.
dribble condition: The device received a frame that was slightly too long, but the frame is accepted and forwarded. The counter is for information only.
late collision: An error indicating that something in the Ethernet is out of specification. Either the cable is too long or perhaps there are too many repeaters.
deferred: A packet has not been transmitted due to excessive number of collisions.
For Catalyst switches, the best command to examine Ethernet interface errors is the
show port counters
in Example 13-5.
Example 13-5 Using
show port counters
to get error information for a switch's Ethernet interfaces.
show port counters 1/1
----- ---------- ---------- ---------- ---------- ---------
1/1 0 0 0 0 0
----- ---------- ---------- ---------- ---------- --------- --------- ---------
1/1 0 0 0 0 0 0 -
Thu Jan 21 1999, 16:55:02
Align-Err: The number of frames that do not have an integer number of octets and have an incorrect frame check sequence.
FCS-Err: The number of frames with an incorrect frame check sequence.
Xmit-Err: The internal transmit buffer is full.
Rcv-Err: The internal receive buffer is full.
UnderSize: Frames smaller than 64 bytes with a good FCS.
Single-Col: The number of times the port had a single collision before transmitting the frame.
Multi-Coll: The number of times the port had more than one collision before transmitting the frame. Note that this counter does not count how many actual collisions occurred trying to transmit the frame—only that it was more than once.
Late-Coll: An error indicating that the Ethernet is out of specification. A cable is too long or there are too many repeaters.
Excess-Col: The number of frames that were dropped because the port saw 16 sequential collisions attempting to transmit that one frame.
Runts: Frames less than 64 bytes long and with a bad FCS.
Giants: Frames greater than 1518 bytes long and with a bad FCS—the same as a jabber.
Syslog Messages Relating to Ethernet Errors
Table 13-2 outlines several common System Error messages and their general causes. Each message is specific to the chipset used on the Ethernet interface. Please refer to the "Cisco IOS Software System Error Messages" guide for details on each individual message.
Table 13-2. Ethernet System Error Messages
This list of messages usually indicates a problem on the device—such as faulty interface hardware, software problems, or memory problems.
These types of messages are most likely the result of a duplex mismatch or just general congestion on the line. A sudden flurry of these messages may also indicate cabling problems.