Support

Table Of Contents

Troubleshooting Token Ring

Token Ring/IEEE 802.5 Comparison

Token Passing

Physical Connections

The Priority System

Fault Management Mechanisms

Frame Formats

Tokens

Data/Command Frames

Troubleshooting Token Ring

Media Problems: Token Ring

show interfaces tokenring

Syntax Description

Command Mode

Usage Guidelines

Sample Display

Troubleshooting Token Ring

---

The Token Ring network was originally developed by IBM in the 1970s. It is still IBM's primary local-area network (LAN) technology, and is second only to Ethernet/IEEE 802.3 in general LAN popularity. The IEEE 802.5 specification is almost identical to, and completely compatible with, IBM's Token Ring network. In fact, the IEEE 802.5 specification was modeled after IBM Token Ring, and continues to shadow IBM's Token Ring development. The term Token Ring is generally used to refer to both IBM's Token Ring network and IEEE 802.5 networks.

Token Ring/IEEE 802.5 Comparison

Token Ring and IEEE 802.5 networks are basically quite compatible, but the specifications differ in relatively minor ways. IBM's Token Ring network specifies a star, with all end stations attached to a device called a multistation access unit (MAU), whereas IEEE 802.5 does not specify a topology (although virtually all IEEE 802.5 implementations also are based on a star). Other differences exist, including media type (IEEE 802.5 does not specify a media type, whereas IBM Token Ring networks use twisted-pair wire) and routing information field size. Figure 6-1 summarizes IBM Token Ring network and IEEE 802.5 specifications.

Figure 6-1 IBM Token Ring Network/IEEE 802.5 Comparison

Token Passing

Token Ring and IEEE 802.5 are the primary examples of token-passing networks. Token-passing networks move a small frame, called a token, around the network. Possession of the token grants the right to transmit. If a node receiving the token has no information to send, it simply passes the token to the next end station. Each station can hold the token for a maximum period of time.

If a station possessing the token does have information to transmit, it seizes the token, alters 1 bit of the token (which turns the token into a start-of-frame sequence), appends the information it wishes to transmit, and finally sends this information to the next station on the ring. While the information frame is circling the ring, there is no token on the network (unless the ring supports early token release), so other stations wishing to transmit must wait. Therefore, collisions cannot occur in Token Ring networks. If early token release is supported, a new token can be released when frame transmission is complete.

The information frame circulates the ring until it reaches the intended destination station, which copies the information for further processing. The information frame continues to circle the ring and is finally removed when it reaches the sending station. The sending station can check the returning frame to see whether the frame was seen and subsequently copied by the destination.

Unlike carrier sense multiple access collision detect (CSMA/CD) networks—such as Ethernet—token-passing networks are deterministic. In other words, it is possible to calculate the maximum time that will pass before any end station will be able to transmit. This feature and several reliability features, which are discussed in the section "Fault Management Mechanisms" later in this chapter, make Token Ring networks ideal for applications where delay must be predictable and robust network operation is important. Factory automation environments are examples of such applications.

Physical Connections

IBM Token Ring network stations are directly connected to MAUs, which can be wired together to form one large ring (as shown in Figure 6-2). Patch cables connect MAUs to adjacent MAUs. Lobe cables connect MAUs to stations. MAUs include bypass relays for removing stations from the ring.

Figure 6-2 IBM Token Ring Network Physical Connections

The Priority System

Token Ring networks use a sophisticated priority system that permits certain user-designated, high-priority stations to use the network more frequently. Token Ring frames have two fields that control priority: the priority field and the reservation field.

Only stations with a priority equal to or higher than the priority value contained in a token can seize that token. Once the token is seized and changed to an information frame, only stations with a priority value higher than that of the transmitting station can reserve the token for the next pass around the network. When the next token is generated, it includes the higher priority of the reserving station. Stations that raise a token's priority level must reinstate the previous priority after their transmission is complete.

Fault Management Mechanisms

Token Ring networks employ several mechanisms for detecting and compensating for network faults. For example, one station in the Token Ring network is selected to be the active monitor. This station, which can potentially be any station on the network, acts as a centralized source of timing information for other ring stations and performs a variety of ring maintenance functions. One of these functions is the removal of continuously circulating frames from the ring. When a sending device fails, its frame may continue to circle the ring. This can prevent other stations from transmitting their own frames and essentially lock up the network. The active monitor can detect such frames, remove them from the ring, and generate a new token.

The IBM Token Ring network's star topology also contributes to overall network reliability. Because all information in a Token Ring network is seen by active MAUs, these devices can be programmed to check for problems and selectively remove stations from the ring if necessary.

A Token Ring algorithm called beaconing detects and tries to repair certain network faults. Whenever a station detects a serious problem with the network (such as a cable break), it sends a beacon frame. The beacon frame defines a failure domain, which includes the station reporting the failure, its nearest active upstream neighbor (NAUN), and everything in between. Beaconing initiates a process called autoreconfiguration, where nodes within the failure domain automatically perform diagnostics in an attempt to reconfigure the network around the failed areas. Physically, the MAU can accomplish this through electrical reconfiguration.

Frame Formats

Token Ring networks define two frame types: tokens and data/command frames. Both formats are shown in Figure 6-3.

Figure 6-3 IEEE 802.5/Token Ring Frame Formats

Tokens

Each token is 3 bytes in length and consists of a start delimiter, an access control byte, and an end delimiter.

The start delimiter serves to alert each station to the arrival of a token (or data/command frame). This field includes signals that distinguish the byte from the rest of the frame by violating the encoding scheme used elsewhere in the frame.

The access control byte contains the priority and reservation fields, as well as a token bit (used to differentiate a token from a data/command frame) and a monitor bit (used by the active monitor to determine whether a frame is circling the ring endlessly).

Finally, the end delimiter signals the end of the token or data/command frame. It also contains bits to indicate a damaged frame and a frame that is the last in a logical sequence.

Data/Command Frames

Data/command frames vary in size, depending on the size of the information field. Data frames carry information for upper-layer protocols; command frames contain control information and have no data for upper-layer protocols.

In data/command frames, a frame control byte follows the access control byte. The frame control byte indicates whether the frame contains data or control information. In control frames, this byte specifies the type of control information.

Following the frame control byte are the two address fields, which identify the destination and source stations. As with IEEE 802.3, addresses are 6 bytes in length.

The data field follows the address fields. The length of this field is limited by the ring token holding time, which defines the maximum time a station may hold the token.

Following the data field is the frame check sequence (FCS) field. This field is filled by the source station with a calculated value dependent on the frame contents. The destination station recalculates the value to determine whether the frame may have been damaged in transit. If damage did occur, the frame is discarded.

As with the token, the end delimiter completes the data/command frame.

Troubleshooting Token Ring

This section provides troubleshooting procedures for common Token Ring media problems. It describes a specific Token Ring symptom, the problems that are likely to cause this symptom, and the solutions to those problems.

Media Problems: Token Ring

Table 6-1 outlines problems commonly encountered on Token Ring networks and offers general guidelines for solving those problems.

Table 6-1 Media Problems: Token Ring 

Media Problem	Suggested Actions
Nonfunctional Token Ring	1. Use the show interfaces token command to determine the status of the router's Token Ring interfaces. 2. If the status line indicates that the interface and line protocol are not up, check the cable from the router to the MAU.1 Make sure that the cable is in good condition. If it is not, replace it. 3. If you are performing a new installation, make sure that the MAU has been properly initialized. For information on initializing your MAU, refer to the manufacturer's documentation.
Ring speed mismatch	1. Check the ring speed specification on all nodes attached to the Token Ring backbone. The ring speed configured for all stations must be the same (either 4 Mbps or 16 Mbps). Use the show running-config privileged exec command to determine which speed is specified on the router. 2. If necessary, modify ring speed specifications for clients, servers, and routers. On routers, use the ring-speed interface configuration command to change the ring speed. Change jumpers as needed for modular router platforms that do not support software speed configuration. For more information about ring speed specifications, refer to the hardware installation and maintenance manual for your system.
Relay open in MAU	1. If an "open lobe fault" message appears on the console at system power up, check the cable connection to the MAU. 2. Use the clear interface privileged exec command to reset the Token Ring interface and reinsert the router into the ring. For all Token Ring cards except the CTR and access routers, you must use the clear interface command to reinitialize the Token Ring interface if the interface is down. 3. Use the show interfaces token exec command to verify that the interface and line protocol are up. 4. If the interface is operational, but the "open lobe fault" message persists and the router still cannot connect to the ring, connect the router to a different MAU port. 5. If the message continues to appear, disconnect all devices from the MAU and reset the MAU's relay with the tool provided by the MAU vendor. 6. Reattach the router and determine whether it can connect to the ring. If resetting the relay does not solve the problem, try replacing the MAU with one that is known to be operational. 7. If the router still cannot connect to the ring, check internal cable connections of the router Token Ring cards. Ensure that cables associated with the respective port numbers are correctly wired and that they are not swapped. 8. If the router still cannot connect to the ring, replace the cables that connect the router to the MAU with working cables. 9. Use the clear interface command to reset the interface and reinsert the router into the ring. Use the show interfaces token command to verify that the interface and line protocol are up. 10. Alternatively, you can connect the router to a spare MAU to which no stations are connected. If the router can attach to the ring, replace the original MAU.
Duplicate MAC2 address	This problem can arise when routers are using locally administered MAC addresses. 1. Use a network analyzer to check the Duplicate Address test frames from a booting station. If the station gets a response, then there is another station already configured with the MAC address of the booting station. 2. If there are two stations with the same MAC addresses, change the MAC address of one of the stations and reinitialize the node.
Congested ring	1. Insert the router during an off-peak period. 2. If insertion is successful during off-peak periods, but unsuccessful during peak load, segment your internetwork to distribute traffic.
RPS3 conflict	1. Use the no lnm rps interface configuration command to disable the RPS function on the router that you are trying to insert into the ring. 2. Try to insert the router into the ring. 3. If you can insert the router with RPS disabled, there is a conflict between RPS implementations. Contact your technical support representative for more information.

1 MAU = multistation access unit 2 MAC = Media Access Control 3 RPS = Ring Parameter Server

show interfaces tokenring

When troubleshooting Token Ring media in a Cisco router environment, you can use the show interfaces tokenring command to provide several key fields of information that can assist in isolating problems. This section provides a detailed description of the show interfaces tokenring command and the information it provides in Table 6-2.

Use the show interfaces tokenring privileged exec command to display information about the Token Ring interface and the state of source route bridging:

show interfaces tokenring unit [accounting]
show interfaces tokenring slot | port [accounting] (for the Cisco 7500 series and
Cisco 7200 series)
show interfaces tokenring [slot | port-adapter | port] (for ports on VIP cards in the
Cisco 7500 series routers)

Syntax Description

•unit—Must match the interface port line number.

•accounting—(Optional) Displays the number of packets of each protocol type that have been sent through the interface.

•slot—Refers to the appropriate hardware manual for slot and port information.

•port—Refers to the appropriate hardware manual for slot and port information.

•port-adapter—Refers to the appropriate hardware manual for information about port adapter compatibility.

Command Mode

Privileged exec

Usage Guidelines

This command first appeared in Cisco IOS Release 10.0.

The command description was modified in Cisco IOS Release 11.3 to account for support on new full-duplex Token Ring port adapters.

If you do not provide values for the parameters slot and port, the command will display statistics for all the network interfaces. The optional keyword accounting displays the number of packets of each protocol type that have been sent through the interface.

Sample Display

The following is sample output from the show interfaces tokenring command:

Router# show interfaces tokenring

TokenRing 0 is up, line protocol is up

Hardware is 16/4 Token Ring, address is 5500.2000.dc27 (bia 0000.3000.072b)

   	 Internet address is 150.136.230.203, subnet mask is 255.255.255.0

	 MTU 8136 bytes, BW 16000 Kbit, DLY 630 usec, rely 255/255, load 1/255

   	 Encapsulation SNAP, loopback not set, keepalive set (10 sec)

   ARP type: SNAP, ARP Timeout 4:00:00

   Ring speed: 16 Mbps

   Single ring node, Source Route Bridge capable

	Group Address: 0x00000000, Functional Address: 0x60840000

   	Last input 0:00:01, output 0:00:01, output hang never

   	Output queue 0/40, 0 drops; input queue 0/75, 0 drops

   	Five minute input rate 0 bits/sec, 0 packets/sec

   	Five minute output rate 0 bits/sec, 0 packets/sec

	   16339 packets input, 1496515 bytes, 0 no buffer

Received 9895 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

        32648 packets output, 9738303 bytes, 0 underruns

        0 output errors, 0 collisions, 2 interface resets, 0 restarts

        5 transitions

Table 6-2 describes the show interfaces tokenring display field.

Table 6-2 show interfaces tokenring Field Descriptions 

Field	Description
Token Ring is { up | down }	Interface is either currently active and inserted into ring (up) or inactive and not inserted (down). On the Cisco 7500 series, gives the interface processor type, slot number, and port number.
Token Ring is Reset	Hardware error has occurred.
Token Ring is Initializing	Hardware is up, in the process of inserting the ring.
Token Ring is Administratively Down	Hardware has been taken down by an administrator.
line protocol is {up | down | administratively down}	Indicates whether the software processes that handle the line protocol believe the interface is usable (that is, whether keepalives are successful).
Hardware	Hardware type. Hardware is Token Ring indicates that the board is a CSC-R board. Hardware is 16/4 Token Ring indicates that the board is a CSC-R16 board. Also shows the address of the interface.
Internet address	Lists the 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.
loopback	Indicates whether loopback is set.
keepalive	Indicates whether keepalives are set.
ARP type:	Type of Address Resolution Protocol assigned.
Ring speed:	Speed of Token Ring— 4 or 16 Mbps.
{Single ring | multiring node}	Indicates whether a node is enabled to collect and use source routing information (RIF) for routable Token Ring protocols.
Group Address:	Interface's group address, if any. The group address is a multicast address; any number of interfaces on the ring may share the same group address. Each interface may have at most one group address.
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 hang	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	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 the elapsed time is too large to be displayed. 0:00:00 indicates the counters were cleared more than 231 ms (and less than 232 ms) ago.
Output queue, drops 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. 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 buffer	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.
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.
giants	Number of packets that are discarded because they exceed the medium's maximum packet size.
CRC	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 a station transmitting bad data.
frame	Number of packets received incorrectly having a CRC error and a noninteger number of octets.
overrun	Number of times the serial receiver hardware was unable to hand receive 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 than the system buffers mentioned previously in the buffer description. Broadcast storms and bursts of noise can cause the ignored count to be increased.
packets output	Total number of messages transmitted by the system.
bytes output	Total number of bytes, including data and MAC encapsulation, transmitted by the system.
underruns	Number of times that the far-end transmitter has been running faster than the near-end router's receiver 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	Because a Token Ring cannot have collisions, this statistic is nonzero only if an unusual event occurred when frames were being queued or taken out of the queue by the system software.
interface resets	The number of times an interface has been reset. The interface may be reset by the administrator or automatically when an internal error occurs.
restarts	Should always be zero for Token Ring interfaces.
transitions	Number of times the ring made a transition from up to down, or vice versa. A large number of transitions indicates a problem with the ring or the interface.