Table Of Contents
Solving Ethernet Problems
Ethernet Overview
Types of Connections
Collisions
Using show interface Commands
Syntax
Understanding Command Output
Troubleshooting Ethernet Media Problems
Solving Ethernet Problems
This chapter explains how to solve Ethernet problems and contains the following sections:
•
Ethernet Overview
•
Using show interface Commands
•
Troubleshooting Ethernet Media Problems
Note
For a description of the features, modifications, and caveats for the
Cisco Integrated Communications System 7750 (Cisco ICS 7750) release 2.6.0, refer to the Release Notes for System Software Release 2.6.0 on the
Cisco ICS 7750.
Note
Refer to Ethernet Technologies for additional information on Ethernet network elements, topologies, and structures. For additional information about troubleshooting Ethernet collisions, refer to Troubleshooting Ethernet Collisions.
Ethernet Overview
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.
Types of Connections
The maximum distances for Ethernet and Fast Ethernet network segments and connections depend on the type of transmission cable being used. The terms 10Base-T and 100Base-T are industry terms for the following:
•
10-Mbps transmission rate (10), or 100-Mbps transmission rate (100)
•
Using baseband technology (Base)
•
By means of twisted pair wires (T)
Ethernet is most similar to IEEE 802.3 10Base-5. 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.
Collisions
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.
Collisions are far less frequent in full-duplex mode Ethernet networks.
Using show interface Commands
When you are troubleshooting Ethernet media, the show interface ethernet and show interface fastethernet privileged EXEC commands provide several key fields of information that can help you isolate problems related to Ethernet interfaces.
Syntax
Following are the syntax for the show interface ethernet command and the syntax for the show interface fastethernet command:
show interface ethernet [slot | interface] [accounting]
show interface fastethernet [slot | interface] [accounting]
where:
•
slot (optional) identifies the slot of a particular card in the Cisco ICS 7750 (legal slot values are 1 through 7).
•
interface (optional) identifies a particular interface, such as Ethernet 0.
•
accounting (optional) displays the number of packets of each protocol type that has been sent through the interface.
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).
Understanding Command Output
Example 7-1 shows sample output from the show interface 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 7-1.
Example 7-1 Output of show interface ethernet Command
Cisco ICS 7750#show interface 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
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,
[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
Table 7-1 Descriptions for the show interface ethernet Command Example
Callout
|
Field
|
Description
|
1
|
Interface and line protocol status
|
Indicates whether the interface hardware is currently active or whether 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 that 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.
|
Troubleshooting Ethernet Media Problems
The following are possible causes of Ethernet media problems:
•
Excessive noise
•
Excessive collisions
•
Excessive runt frames
•
Late collisions
•
No link integrity on 10Base-T, 100Base-T4, or 100Base-TX
Table 7-2 describes ways to solve these problems.
Table 7-2 Ethernet Media Problems and Solutions
Media Problem
|
Solution
|
|
Excessive noise
|
Step 1
|
Use the show interface 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 100Base-TX, make sure you are using Category 5 cabling.2
|
Excessive collisions
|
Step 1
|
Use the show interface 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, see the "Excessive collisions" problem 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 10Base-T, 100Base-T4, or 100Base-TX
|
Step 1
|
Make sure that you are not using 100Base-T4 when only two pairs of wire are available. 100Base-T4 requires four pairs.
|
| |
Step 2
|
Look for a 10Base-T, 100Base-T4, or 100Base-TX 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 that 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).
|