[cisco] show interface 의 error 관련(ethernet)

출처 : http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1904.html

 

Troubleshooting Ethernet

 

Table 4-5 Troubleshooting Procedures for Common Ethernet Media Problems

Media Problem	Suggested Actions
Excessive noise	1. Use the show interfaces ethernet exec command to determine the status of the router's Ethernet interfaces. The presence of many CRC errors but not many collisions is an indication of excessive noise. 2. Check cables to determine whether any are damaged. 3. Look for badly spaced taps causing reflections. 4. If you are using 100BaseTX, make sure you are using Category 5 cabling and not another type, such as Category 3.
Excessive collisions	1. Use the show interfaces ethernet command to check the rate of collisions. The total number of collisions with respect to the total number of output packets should be around 0.1 percent or less. 2. Use a TDR to find any unterminated Ethernet cables. 3. Look for a jabbering transceiver attached to a host. (This might require host-by-host inspection or the use of a protocol analyzer.)
Excessive runt frames	In a shared Ethernet environment, runt frames are almost always caused by collisions. If the collision rate is high, refer to the problem of excessive collisions, earlier in this table. If runt frames occur when collisions are not high or when in a switched Ethernet environment, then they are the result of underruns or bad software on a network interface card. Use a protocol analyzer to try to determine the source address of the runt frames.
Late collisions	1. Use a protocol analyzer to check for late collisions. Late collisions should never occur in a properly designed Ethernet network. They usually occur when Ethernet cables are too long or when there are too many repeaters in the network. 2. Check the diameter of the network, and make sure that it is within specification.
No link integrity on 10BaseT, 100BaseT4, or 100BaseTX	1. Make sure that you are not using 100BaseT4 when only two pairs of wire are available. 100BaseT4 requires four pairs. 2. Check for a 10BaseT, 100BaseT4, or 100BaseTX mismatch (for example, a card different from the port on a hub). 3. Determine whether there is cross-connect. (For example, be sure that straight-through cables are not being used between a station and the hub.) 4. Check for excessive noise (see the problem of excessive noise, earlier in this table).

 

Table 4-6 show interfaces ethernet Field Descriptions 

Field	Description
Ethernet . . . is up . . . is administratively down	Indicates whether the interface hardware is currently active and whether it has been taken down by an administrator. "Disabled" indicates that the router has received more than 5,000 errors in a keepalive interval, which is 10 seconds, by default.
line protocol is {up | down | administratively down}	Indicates whether the software processes that handle the line protocol believe that the interface is usable (that is, whether keepalives are successful) or if it has been taken down by an administrator.
Hardware	Specifies the hardware type (for example, MCI Ethernet, SCI, cBus Ethernet) and address.
Internet address	Specifies the Internet address, followed by the subnet mask.
MTU	Gives the maximum transmission unit of the interface.
BW	Gives the bandwidth of the interface in kilobits per second.
DLY	Gives the delay of the interface in microseconds.
rely	Shows reliability of the interface as a fraction of 255 (255/255 is 100 percent reliability), calculated as an exponential average over 5 minutes.
load	Shows load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over 5 minutes.
Encapsulation	Specifies the encapsulation method assigned to interface.
ARP type	Specifies the type of Address Resolution Protocol assigned.
loopback	Indicates whether loopback is set.
keepalive	Indicates whether keepalives are set.
Last input	Gives the number of hours, minutes, and seconds since the last packet was successfully received by an interface. This is useful for knowing when a dead interface failed.
Last output	Gives the number of hours, minutes, and seconds since the last packet was successfully transmitted by an interface.
output	Gives the number of hours, minutes, and seconds since the last packet was successfully transmitted by the interface. This is useful for knowing when a dead interface failed.
output hang	Gives the number of hours, minutes, and seconds (or never) since the interface was last reset because of a transmission that took too long. When the number of hours in any of the "last" fields exceeds 24 hours, the number of days and hours is printed. If that field overflows, asterisks are printed.
Last clearing	Gives the time at which the counters that measure cumulative statistics (such as number of bytes transmitted and received) shown in this report were last reset to zero. Note that variables that might affect routing (for example, load and reliability) are not cleared when the counters are cleared. "***" indicates that the elapsed time is too large to be displayed. "0:00:00" indicates that the counters were cleared more than 231ms (and less than 232ms) ago.
Output queue, input queue, drops	Gives the number of packets in output and input queues. Each number is followed by a slash, the maximum size of the queue, and the number of packets dropped due to a full queue.
Five minute input rate, Five minute output rate	Gives the average number of bits and packets transmitted per second in the past 5 minutes. If the interface is not in promiscuous mode, it senses network traffic it sends and receives (rather than all network traffic). The 5-minute input and output rates should be used only as an approximation of traffic per second during a given 5-minute period. These rates are exponentially weighted averages with a time constant of 5 minutes. A period of four time constants must pass before the average will be within 2 percent of the instantaneous rate of a uniform stream of traffic over that period.
packets input	Gives the total number of error-free packets re ceived by the system.
bytes input	Gives the total number of bytes, including data and MAC encapsulation, in the error-free packets received by the system.
no buffers	Gives the number of received packets discarded because there was no buffer space in the main system. Compare this with the ignored count. Broadcast storms on Ethernet networks and bursts of noise on serial lines are often responsible for no input buffer events.
Received . . . broadcasts	Shows the total number of broadcast or multicast packets received by the interface.
Runts	Gives the number of packets that are discarded because they are smaller than the medium's minimum packet size. For instance, any Ethernet packet that is less than 64 bytes is considered a runt.
giants	Gives the number of packets that are discarded because they exceed the medium's maximum packet size. For example, any Ethernet packet that is greater than 1518 bytes is considered a giant.
input error	Includes runts, giants, no buffer, CRC, frame, overrun, and ignored counts. Other input-related errors can also cause the input error count to be increased, and some datagrams may have more than one error; therefore, this sum may not balance with the sum of enumerated input error counts.
CRC	Indicates that the cyclic redundancy checksum generated by the originating LAN station or far-end device does not match the checksum calculated from the data received. On a LAN, this usually indicates noise or transmission problems on the LAN interface or the LAN bus itself. A high number of CRCs is usually the result of collisions or a station transmitting bad data.
frame	Shows the number of packets received incorrectly having a CRC error and a noninteger number of octets. On a LAN, this is usually the result of collisions or a malfunctioning Ethernet device.
overrun	Shows the number of times that the receiver hardware was incapable of handing received data to a hardware buffer because the input rate exceeded the receiver's capability to handle the data.
ignored	Shows the number of received packets ignored by the interface because the interface hardware ran low on internal buffers. These buffers are different from the system buffers mentioned previously in the buffer description. Broadcast storms and bursts of noise can cause the ignored count to be increased.
input packets with dribble condition detected	Gives the dribble bit error, which indicates that a frame is slightly too long. This frame error counter is incremented just for informational purposes; the router accepts the frame.
packets output	Shows the total number of messages transmitted by the system.
bytes	Shows the total number of bytes, including data and MAC encapsulation, transmitted by the system.
underruns	Gives the number of times that the transmitter has been running faster than the router can handle. This may never be reported on some interfaces.
output errors	Gives the sum of all errors that prevented the final transmission of datagrams out of the interface being examined. Note that this may not balance with the sum of the enumerated output errors because some datagrams may have more than one error, and others may have errors that do not fall into any of the specifically tabulated categories.
collisions	Gives the number of messages retransmitted due to an Ethernet collision. This is usually the result of an overextended LAN (Ethernet or transceiver cable too long, more than two repeaters between stations, or too many cascaded multiport transceivers). A packet that collides is counted only once in output packets.
interface resets	Gives the number of times that an interface has been completely reset. This can happen if packets queued for transmission were not sent within several seconds. On a serial line, this can be caused by a malfunctioning modem that is not supplying the transmit clock signal, or by a cable problem. If the system notices that the carrier detect line of a serial interface is up, but the line protocol is down, it periodically resets the interface in an effort to restart it. Interface resets can also occur when an interface is looped back or shut down.
restarts	Gives the number of times a Type 2 Ethernet controller was restarted because of errors.