|
|
This chapter explains how to solve Ethernet problems and contains the following sections:
The term Ethernet refers to all carrier sense multiple access collision detect (CSMA/CD) LANs that conform to Ethernet specifications, including Institute of Electrical and Electronics Engineers (IEEE) 802.3.
Both Ethernet and IEEE 802.3 LANs are broadcast networks. In other words, all stations see all frames, regardless of whether they represent an intended destination. Each station must examine received frames to determine whether the station is a destination. If it is a destination, the frame is passed to a higher protocol layer for appropriate processing.
The maximum distances for Ethernet and Fast Ethernet network segments and connections depend on the type of transmission cable being used. The terms 10BaseT and 100BaseT are industry terms for the following:
Ethernet is most similar to IEEE 802.3 10Base5. Both of these protocols specify a bus topology network with a connecting cable between the end stations and the network medium. In the case of Ethernet, that cable is called a transceiver cable. The transceiver cable connects to a transceiver device attached to the physical network medium. The IEEE 802.3 configuration is much the same, except that the connecting cable is referred to as an attachment unit interface (AUI), and the transceiver is called a media attachment unit (MAU). In both cases, the connecting cable attaches to an interface board (or interface circuitry) within the end station.
Stations on a CSMA/CD LAN can access the network at any time. Before sending data, CSMA/CD stations listen to the network to see if it is already in use. If it is, the station waits to transmit. If the network is not in use, the station transmits. A collision occurs when two stations transmit simultaneously. In this case, both transmissions are damaged, and the stations must retransmit at some later time. Backoff algorithms determine when the colliding stations retransmit. CSMA/CD stations can detect collisions, so they know when they must retransmit.
When you are troubleshooting Ethernet media, the show interfaces ethernet and show interfaces fastethernet privileged EXEC commands provide several key fields of information that can help you isolate problems related to Ethernet interfaces.
show interfaces ethernet [slot | interface] [accounting]
show interfaces fastethernet [slot | interface] [accounting]
where:
If you do not provide values for the slot and interface arguments, the command displays statistics for all Ethernet interfaces on the network. The optional keyword accounting displays the number of packets of each protocol type that has been sent through the interface (or all interfaces).
Example 9-1 shows sample output from the show interfaces ethernet command for the Ethernet 0 interface. For a description of the most significant fields as indicated by the callouts—the numbers in square brackets—see Table 9-1.
Cisco ICS 7750# show interfaces ethernet 0 [1] Ethernet 0 is up, line protocol is up Hardware is MCI Ethernet, address is aa00.0400.0134 (via 0000.0c00.4369 Internet address is 131.108.1.1, subnet mask is 255.255.255.0 [2] MTU 1500 bytes, [3] BW 10000 Kbit, [4] DLY 1000 usec, [5] rely 255/255, [6] load 1/255 Encapsulation ARPA, loopback not set, keepalive set (10 sec) ARP type: ARPA, PROBE, ARP Timeout 4:00:00 [7] Last input 0:00:00, output 0:00:00, [8] output hang never [9] Output queue 0/40, 0 drops; input queue 0/75, 2 drops Five minute input rate 61000 bits/sec, 4 packets/sec Five minute output rate 1000 bits/sec, 2 packets/sec [10]2295197 packets input, 305539992 bytes, 0 no buffer Received 1925500 broadcasts, 0 runts, 0 giants 3 input errors, 3 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 input packets with dribble condition detected 3594664 packets output, 436549843 bytes, 0 underruns [11]8 output errors, [12]1790 collisions, [13]10 interface resets, [14]0 restarts
| Callout | Field | Description |
|---|---|---|
1 | Interface and line protocol status | Indicates whether the interface hardware is currently active or if it has been disabled by an administrator. If the interface is shown as "disabled," the device has received more than 5,000 errors in a keepalive interval, which is 10 seconds by default. If the line protocol is shown as "down" or "administratively down," the software processes that handle the line protocol consider the interface unusable (because of unsuccessful keepalives) or the interface has been disabled by an administrator. |
2 | MTU1 | Maximum packet size, in bytes, that an interface can handle. |
3 | BW2 | Interface bandwidth, in kilobits per second. |
4 | DLY3 | Interface delay, in microseconds. |
5 | rely | Reliability of the interface as a fraction of 255 (255/255 is 100 percent reliability), calculated as an exponential average over 5 minutes. |
6 | load | Load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over 5 minutes. |
7 | Last input and last output | Number of hours, minutes, and seconds since the last packet was successfully received (input) and transmitted (output) by an interface. Last input can help you determine how much time has passed since the failure of a particular interface. |
8 | Output hang | Number of hours, minutes, and seconds (or never) since the interface was last reset because of a transmission that took too long. |
9 | Output queue, input queue, drops | Number of packets in the 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. |
10 | Input errors, including CRC errors and framing errors | Total number of errors related to no buffer4, runt5, giant6, CRC7, frame8, overrun9, ignored10, and abort. Other input-related errors can also increment the count, so this sum might not balance with the other counts. |
11 | Output errors | Number of times that 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. |
12 | Collisions | Number of messages retransmitted because of an Ethernet collision. This is usually the result of an overextended LAN. LANs can become overextended when an Ethernet or transceiver cable is too long or when there are more than two repeaters between stations. |
13 | Interface resets | Number of times an interface has been completely reset. This can happen if packets queued for transmission were not sent within several seconds. |
14 | Restarts | Number of times that an Ethernet controller has been restarted because of errors. |
Possible causes of ethernet media problems are as follows:
Table 9-2 describes ways to solve these problems.
| Media Problem | Solution | |
|---|---|---|
Excessive noise | Step 1 | Use the show interfaces ethernet exec command to determine the status of the device's Ethernet interfaces. The presence of many CRC errors but not many collisions is an indication of excessive noise. |
| Step 2 | Inspect the cables for damage. |
| Step 3 | Look for badly spaced taps1, which could cause reflections. |
| Step 4 | If you are using 100BaseTX, make sure you are using Category 5 cabling.2 |
Excessive collisions | Step 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 0.1 percent or less. |
| Step 2 | Use a TDR3 to find any unterminated Ethernet cables. |
| Step 3 | Look for a jabbering4 transceiver attached to a host. This might require host-by-host inspection or the use of a protocol analyzer.5 |
Excessive runt frames | Step 1 | In a shared Ethernet environment, runt frames are almost always caused by collisions. If the collision rate is high, refer to the problem "Excessive collisions" earlier in this table. |
| Step 2 | If runt frames occur when collision rates are not high or in a switched Ethernet environment, then they are the result of underruns6 or bad software on a network interface card. |
| Step 3 | Use a protocol analyzer to try to determine the source address of the runt frames. |
Late collisions | Step 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. |
| Step 2 | Verify that the diameter of the network is within specification. |
No link integrity on 10BaseT, 100BaseT4, or 100BaseTX | Step 1 | Make sure you are not using 100BaseT4 when only two pairs of wire are available. 100BaseT4 requires four pairs. |
| Step 2 | Look for a 10BaseT, 100BaseT4, or 100BaseTX mismatch (such as a card that does not work with a particular interface). |
| Step 3 | Determine whether there is cross-connect (for example, be sure straight-through cables are not being used between a station and the hub). |
| Step 4 | Check for excessive noise (see the problem "Excessive noise" earlier in this table). |
| 1The link between a bus and a drop cable that connects a workstation to the bus. 2Category 5 (CAT5) cables support frequencies up to 100 MHz, while Category 3 (CAT3) cables support frequencies no higher than 16 MHz. For this and other reasons, CAT5 is an increasingly popular choice, especially in networks that carry both data and voice traffic. 3TDR = time domain reflectometer. A device that sends signals through a network medium to check cable continuity and other attributes. (See the section "Using Third-Party Troubleshooting Tools" in Chapter 4, "System Troubleshooting Guidelines.") 4Jabber occurs when a device that is experiencing circuitry or logic failure continuously sends random (garbage) data. 5A specialized computer or program that analyzes the traffic on a LAN. For more information about protocol analyzers (also known as network analyzers), see the section "Using Third-Party Troubleshooting Tools" in Chapter 4, "System Troubleshooting Guidelines." 6Each time that a transmitter is running faster than a routing device can handle, the routing device reports an underrun. |
Posted: Mon Oct 2 13:44:21 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.