|
|
Ethernet was developed by Xerox Corporation's Palo Alto Research Center (PARC) in the 1970s. Ethernet was the technological basis for the IEEE 802.3 specification, which was initially released in 1980. Shortly thereafter, Digital Equipment Corporation, Intel Corporation, and Xerox Corporation jointly developed and released an Ethernet specification (Version 2.0) that is substantially compatible with IEEE 802.3. Together, Ethernet and IEEE 802.3 currently maintain the greatest market share of any local-area network (LAN) protocol. Today, the term Ethernet is often used to refer to all carrier sense multiple access collision detect (CSMA/CD) LANs that generally conform to Ethernet specifications, including IEEE 802.3.
When it was developed, Ethernet was designed to fill the middle ground between long-distance, low-speed networks and specialized, computer-room networks carrying data at high speeds for very limited distances. Ethernet is well suited to applications where a local communication medium must carry sporadic, occasionally heavy traffic at high peak data rates.
Ethernet and IEEE 802.3 specify similar technologies. Both are CSMA/CD LANs. 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 wishing to transmit waits. If the network is not in use, the station transmits. A collision occurs when two stations listen for network traffic, "hear" none, and 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.
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.
IEEE 802.3 specifies several different physical layers, whereas Ethernet defines only one. Each IEEE 802.3 physical layer protocol has a name that summarizes its characteristics. The coded components of an IEEE 802.3 physical-layer name are shown in Figure 4-1.
A summary of Ethernet Version 2 and IEEE 802.3 characteristics appears in Table 4-1.
Characteristic | Ethernet Value | IEEE 802.3 Values | ||||
10Base5 | 10Base2 | 1Base5 | 10BaseT | 10Broad36 | ||
Data rate | 10 | 10 | 10 | 1 | 10 | 10 |
Signaling | Baseband | Baseband | Baseband | Baseband | Baseband | Broadband |
Maximum | 500 | 500 | 185 | 250 | 100 | 1800 |
Media | 50-ohm | 50-ohm | 50-ohm | Unshielded | Unshielded | 75-ohm |
Topology | Bus | Bus | Bus | Star | Star | Bus |
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 actual 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.
Ethernet and IEEE 802.3 frame formats are shown in Figure 4-2 .
Both Ethernet and IEEE 802.3 frames begin with an alternating pattern of ones and zeros called a preamble. The preamble tells receiving stations that a frame is coming.
The byte before the destination address in both an Ethernet and an IEEE 802.3 frame is a start-of-frame (SOF) delimiter. This byte ends with two consecutive one bits, which serve to synchronize the frame reception portions of all stations on the LAN.
Immediately following the preamble in both Ethernet and IEEE 802.3 LANs are the destination and source address fields. Both Ethernet and IEEE 802.3 addresses are 6 bytes long. Addresses are contained in hardware on the Ethernet and IEEE 802.3 interface cards. The first three bytes of the addresses are specified by the IEEE on a vendor-dependent basis, and the last three bytes are specified by the Ethernet or IEEE 802.3 vendor. The source address is always a unicast (single node) address, whereas the destination address may be unicast, multicast (group), or broadcast (all nodes).
In Ethernet frames, the 2-byte field following the source address is a type field. This field specifies the upper-layer protocol to receive the data after Ethernet processing is complete.
In IEEE 802.3 frames, the 2-byte field following the source address is a length field, which indicates the number of bytes of data that follow this field and precede the frame check sequence (FCS) field.
Following the type/length field is the actual data contained in the frame. After physical-layer and link-layer processing are complete, this data will eventually be sent to an upper-layer protocol. In the case of Ethernet, the upper-layer protocol is identified in the type field. In the case of IEEE 802.3, the upper-layer protocol must be defined within the data portion of the frame, if at all. If data in the frame is insufficient to fill the frame to its minimum 64-byte size, padding bytes are inserted to ensure at least a 64-byte frame.
After the data field is a 4-byte FCS field containing a cyclic redundancy check (CRC) value. The CRC is created by the sending device and recalculated by the receiving device to check for damage that might have occurred to the frame in transit.
Table 4-2 provides troubleshooting procedures for common Ethernet media problems.
| Media Problem | Suggested Actions |
|---|---|
Step 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. Step 2 Check cables to determine whether any are damaged. Step 3 Look for badly spaced taps causing reflections. Step 4 If you are using 100BaseTX, make sure you are using Category 5 cabling and not another type, such as Category 3. | |
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 around 0.1 percent or less. Step 2 Use a TDR to find any unterminated Ethernet cables. Step 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 | 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 collisions are not high or in a switched Ethernet environment, then they are the result of underruns 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 collisions1 | 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 Check the diameter of the network and make sure it is within specification. |
No link integrity on 10BaseT, | Step 1 Make sure you are not using 100BaseT4 when only two pairs of wire are available. 100BaseT4 requires four pairs. Step 2 Check for 10BaseT, 100BaseT4, or 100BaseTX mismatch (for example, a card different from the port on a hub). 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). |
| 1A late collision is a collision that occurs beyond the first 64 bytes of an Ethernet frame. |
When you're troubleshooting Ethernet media in a Cisco router environment, the show interfaces ethernet command provides several key fields of information that can assist with isolating problems. The following section provides a detailed description of the show interfaces ethernet command and the information it provides.
Use the show interfaces ethernet privileged exec command to display information about an Ethernet interface on the router:
show interfaces ethernet unit [accounting]Privileged exec
This command first appeared in Cisco IOS Release 10.0. If you do not provide values for the argument unit (or slot and port on the Cisco 7200 series or slot and port-adapter on the Cisco 7500 series), the command will display statistics for all network interfaces. The optional keyword accounting displays the number of packets of each protocol type that have been sent through the interface.
The following is sample output from the show interfaces command for the Ethernet 0 interface:
Router# show interfaces ethernet 0
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
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
ARP type: ARPA, PROBE, ARP Timeout 4:00:00
Last input 0:00:00, output 0:00:00, output hang never
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
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
8 output errors, 1790 collisions, 10 interface resets, 0 restarts
| 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 | Indicates whether the software processes that handle the line protocol believe the interface is usable (that is, whether keepalives are successful) or if it has been taken down by an administrator. |
Hardware | Hardware type (for example, MCI Ethernet, SCI, cBus Ethernet) and address. |
Internet address | Internet address followed by subnet mask. |
MTU | Maximum transmission unit of the interface. |
BW | Bandwidth of the interface in kilobits per second. |
DLY | Delay of the interface in microseconds. |
rely | Reliability of the interface as a fraction of 255 (255/255 is 100 percent reliability), calculated as an exponential average over five minutes. |
load | Load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over five minutes. |
Encapsulation | Encapsulation method assigned to interface. |
ARP type: | Type of Address Resolution Protocol assigned. |
loopback | Indicates whether loopback is set. |
keepalive | Indicates whether keepalives are set. |
Last input | Number of hours, minutes, and seconds since the last packet was successfully received by an interface. Useful for knowing when a dead interface failed. |
Last output | Number of hours, minutes, and seconds since the last packet was successfully transmitted by an interface. |
output | Number of hours, minutes, and seconds since the last packet was successfully transmitted by the interface. Useful for knowing when a dead interface failed. |
output hang | |
Last clearing | 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. |
Output queue, input queue, drops | 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 | Average number of bits and packets transmitted per second in the past five minutes. If the interface is not in promiscuous mode, it senses network traffic it sends and receives (rather than all network traffic). The five-minute input and output rates should be used only as an approximation of traffic per second during a given five-minute period. These rates are exponentially weighted averages with a time constant of five 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 | Total number of error-free packets received by the system. |
bytes input | Total number of bytes, including data and MAC encapsulation, in the error-free packets received by the system. |
no buffers | Number of received packets discarded because there was no buffer space in the main system. Compare with ignored count. Broadcast storms on Ethernet networks and bursts of noise on serial lines are often responsible for no input buffer events. |
Received...broadcasts | Total number of broadcast or multicast packets received by the interface. |
runts | 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. |
Number of packets that are discarded because they exceed the medium's maximum packet size. For example, any Ethernet packet that is greater than 1,518 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 | 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 | 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 | 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. |
ignored | 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 | Dribble bit error 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 | Total number of messages transmitted by the system. |
bytes | Total number of bytes, including data and MAC encapsulation, transmitted by the system. |
underruns | Number of times the transmitter has been running faster than the router can handle. This may never be reported on some interfaces. |
output errors | 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, as 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 | |
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. 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 | Number of times a Type 2 Ethernet controller was restarted because of errors. |
Posted: Tue May 16 15:00:11 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.