Understanding Token Ring Switching

The traditional method of connecting multiple Token Ring segments is to use a source-routing bridge. For example, bridges are often used to link workgroup rings to the backbone ring. However, the introduction of the bridge can significantly reduce performance at the user's workstation. Further problems may be introduced by aggregate traffic loading on the backbone ring.

To maintain performance and avoid overloading the backbone ring, you can locate servers on the same ring as the workgroup that needs to access the server. However, dispersing the servers throughout the network makes them more difficult to back up, administer, and secure than if they are located on the backbone ring and limits the number of servers that particular stations can access.

Collapsed backbone routers offer greater throughput than bridges, and can interconnect a larger number of rings without becoming overloaded. Routers provide both bridging and routing function between ring and have sophisticated broadcast control mechanisms. These mechanisms become increasingly important as the number of devices on the network increase.

The main drawback of using routers as the campus backbone is the relatively high price-per-port and the fact that the throughput typically does not increase as ports are added. A Token Ring switch is designed to provide wire speed throughput regardless of the number of ports in the switch. In addition, the switch can be configured to provide very low latency between Token Ring ports by using cut-through switching.

As a local collapsed backbone device, a Token Ring switch offers a lower per-port cost and can incur lower interstation latency than a router. In addition, the switch can be used to directly attach large numbers of clients or servers, thereby replacing concentrators. Typically, a Token Ring switch is used in conjunction with a router, providing a high-capacity interconnection between Token Ring segments while retaining the broadcast control and wide-area connectivity provided by the router.

Clients or servers that support source routing typically send an explorer frame to determine the path to a given destination. There are two types of explorer frames: all-routes explorer and spanning-tree explorer. All SRB bridges copy all-routes explorer frames and add their own routing information. For frames that are received from or sent to ports that are in the spanning-tree forwarding state, bridges copy spanning-tree explorer frames and add their own routing information. Because all-routes explorer frames will traverse all paths between two devices, they are used in path determination. Spanning-tree explorer frames are used to send datagrams because the spanning tree will ensure that only one copy of an spanning-tree explorer frame is sent to each ring.

The SRT bridge only runs the IEEE Spanning-Tree Protocol. It does not support the IBM Spanning Tree Protocol.

The key difference between SRB and source-route switching is that while a source-route switch looks at the RIF, it never updates the RIF. Therefore, all ports in a source-route switch group have the same ring number.

Source-route switching provides the following benefits:

• The switch does not need to learn the MAC addresses of the devices on the other side of a source-route bridge. Therefore, the number of MAC addresses that the switch must learn and maintain is significantly reduced.
  
  
• The switch can support parallel source-routing paths.
  
  
• An existing ring can be partitioned into several segments without requiring a change in the existing ring numbers or the source-route bridges.
  
  
• The switch can support duplicate MAC addresses if the stations reside on LAN segments with different LAN IDs (ring numbers).
  
  

While store-and-forward reduces the amount of error traffic on the LAN, it also causes a delay in frame forwarding that is dependent upon the length of the frame.

In accordance with specification ISO/IEC 10038, the Catalyst 3920 uses Access Priority 4 to gain priority access to the token on the output ring if the outgoing port is operating in half-duplex mode. This increases the proportion of packets that can be cut through and makes it possible for the Catalyst 3920 to reduce the average interstation latency.

In certain circumstances, however, the cut-through technique cannot be applied and the Catalyst 3920 must buffer frames into memory.

For example, buffering must be performed in the following circumstances:

• The Catalyst 3920 has two packets to transmit to the same ring.
  
  
• A packet is switched between 4- and 16-Mbps rings.
  
  
• The destination ring is beaconing.
  
  

Dedicated Token Ring, developed by the IEEE, defines a method in which the switch port can emulate a concentrator port, thereby eliminating the need for an intermediate concentrator. In addition, dedicated Token Ring defines a new full-duplex data passing mode called Transmit Immediate, which eliminates the need for a token and allows the adapter to transmit and receive simultaneously.

Dedicated Token Ring is particularly useful for providing improved access to servers. A server can be attached directly to a switch. This allows the server to take advantage of the full 16 Mbps available for sending and receiving and results in an aggregate bandwidth of 32 Mbps.

The ring number of the TrCRF can be defined or learned from external bridges. Within the TrCRF, source-route switching is used for forwarding based on either MAC addresses or route descriptors. If desired, the entire VLAN can operate as a single ring.

Frames can be switched between ports within a single TrCRF.

On boot up, the Catalyst switch with a trunk port sends out periodic requests for VTP configuration on all of its trunks until it receives a summary advertisement from a neighbor. It uses that summary advertisement to determine whether its currently stored configuration is obsolete. If the stored configuration is obsolete, the Catalyst switch requests all VTP information from the neighbor.

The Catalyst switch transmits VTP frames on its trunk ports, advertising its management domain name, configuration revision number, and VLAN information that it has learned. Other Catalyst switches in the domain use these advertisements to learn about any new VLANs that are configured in the transmitting switch. This process of advertising and learning allows a new VLAN to be created and configured on only one switch in the management domain. This information is then learned automatically by all of the other devices in the domain.

• In server mode, the switch will permit changes to the administrative domain's global VLAN configuration from the local device. Redundancy in a network domain can be created by using multiple VTP servers.
  
  
• In client mode, the switch will accept configuration changes from other devices in the administrative domain, but will not permit local changes to the database.
  
  
• In transparent mode, the switch will pass on any VTP packets received on the default VLANs of any trunk onto the default VLANs of all other trunks.
  
  

  Use VTP transparent mode to have a Catalyst switch not participate in VTP and yet not have it cut off VTP configuration from propagating beyond it. In transparent mode, VTP packets received on one trunk are automatically propagated unchanged to all other trunks on the device but are ignored on the device itself.

VTP Start Up

When a Catalyst switch is booted for the first time (and when it is rebooted after a nonvolatile random-access memory [NVRAM] reset), it comes up in no-domain mode. The no-domain mode means there is no domain name configured in the switch. While in no-domain mode, a switch will not attempt to advertise its own current configuration. If and when it receives an advertisement from any neighbor on any trunk, it will immediately accept the management domain name from the neighbor's advertisement as its own. After receiving all of the neighbor's configuration data, it will begin advertising this data regularly (after a reboot) on all of its trunks.

Security

A checksum is calculated using an arbitrary security value that is appended to the front end and the back end of the data in a VTP configuration. When a VTP device has received all of the parts of the VTP configuration, it recalculates the checksum using its own security value derived from the password that has been configured locally. The device will not accept the new configuration if the checksums do not match.

On all Cisco VTP devices, the default initial configuration of the security value is all zeroes. Therefore, VTP devices will always accept one another's VLAN configurations as long as none of the security values on any of the devices have been modified. To make use of the security feature, a password needs to be set. The password must be the same for the management domain on all devices in the domain. Neither the password nor the security value itself is ever advertised over the network.

Caution If passwords are set, a management domain does not function properly if the same management domain password is not assigned to each Catalyst switch in the domain.

To accomplish this, the Spanning-Tree Protocol blocks ports that, if active, would create bridging loops. If the primary link fails, it activates one of the blocked bridge ports to provide a new path through the network.

In a traditional bridged network, there is one Spanning-Tree Protocol for each bridge connection. Each bridge maintains its own database of configuration information and transmits and receives only on those ports belonging to the bridge. The type of Spanning-Tree Protocol that runs on a bridge depends on the transmission mode of the bridge connection (whether the connection is transparent, SRB, source-route switching, or SRT).

  The first 2 bytes are a priority field, and the last 6 bytes contain one of the bridge's MAC addresses. The bridge with the lowest bridge identifier among all bridges on all LAN segments is the root bridge. The network administrator can assign a lower bridge priority to a selected bridge to control which bridge becomes the root, or the administrator can use default bridge priorities and allow the Spanning-Tree Protocol to determine the root.

  The path cost represents the cost of transmitting a frame to a bridged segment through that port. A network administrator typically configures a cost for each port based on the speed of link (for example, the cost of a port connected to a 16-Mbps LAN could be assigned a lower path cost than a port connected to a 4-Mbps LAN).

3. Each bridge determines its root port and root path cost.

  The root port is the port that represents the shortest path from itself to the root bridge. The root path cost is the total cost to the root. All ports on the root bridge have a zero cost.

4. All participating bridges elect a designated bridge from among the bridges on that LAN segment.

  A designated bridge is the bridge on each LAN segment that provides the minimum root path cost. Only the designated bridge is allowed to forward frames to and from that LAN segment toward the root.

5. All participating bridges select ports for inclusion in the spanning tree.

  The selected ports will be the root port plus the designated ports for the designated bridge. Designated ports are those where the designated bridge has the best path to reach the root. In cases where two or more bridges have the same root path cost, the bridge with the lowest bridge identifier becomes the designated bridge.

6. Using the preceding steps, all but one of the bridges directly connected to each LAN segment are eliminated, thereby removing all multiple LAN loops.

BPDUs are exchanged between neighboring bridges at regular intervals (typically 1 to 4 seconds) and contain configuration information that identifies the:

• Bridge that is presumed to be the main bridge or root (root identifier)
  
  
• Distance from the sending bridge to the root bridge (called the root path cost)
  
  
• Bridge and port identifier of the sending bridge
  
  
• Age of the information contained in the configuration message
  
  

If a bridge fails and stops sending BPDUs, the bridges detect the lack of configuration messages and initiate a spanning-tree recalculation.

BPDU Configuration Message Fields

Protocol Identifier—Identifies the protocol. This field contains the value zero.

Version—Identifies the version. This field contains the value zero.

Message Type—Identifies the message type. This field contains the value zero.

Flags—1-byte field, of which only the first two bits are used. The topology change (TC) bit signals a topology change. The topology change acknowledgment (TCA) bit is set to acknowledge receipt of a configuration message with the TC bit set.

Root ID—Identifies the root bridge by listing its 2-byte priority followed by its 6-byte ID.

Root Path Cost—Cost of the path from the bridge sending the configuration message to the root bridge.

Bridge ID—Priority and ID of the bridge sending the message.

Port ID—Port number (IEEE or Cisco Spanning-Tree Protocol BPDU) or the ring and bridge number (IBM Spanning-Tree Protocol BPDU) from which the configuration message was sent. This field allows loops created by multiple attached bridges to be detected and corrected.

Message Age—Indicates the amount of time that has elapsed since the root sent the configuration message on which the current configuration message is based.

Maximum Age—Indicates when the current configuration message should be deleted.

Hello Time—Indicates the time between root bridge configuration messages.

Forward Delay—Indicates the length of time that bridges should wait before transitioning to a new state after a topology change. If a bridge transitions too soon, it is possible that not all network links will be ready to change their state, and loops can result.

• Transparent Bridging
  
  
• Source-Route Switching
  
  
• Source-Route Transparent Bridging
  
  

The IEEE 802.1d Spanning-Tree Protocol BPDU format is:

Transparent Bridging

When a bridge connection is transparent mode:

• The bridge connection learns the source MAC addresses.
  
  
• Frames are forwarded based upon the destination address.
  
  

Source-Route Switching

When a bridge connection is source-route switching:

• The bridge connection learns route descriptors for frames that contain a RIF and learns the source MAC addresses for frames that do not contain a RIF.
  
  
• Source-route frames are forwarded based on the route descriptor.
  
  
• Non-source-route frames are forwarded based on the destination address.
  
  

Source-Route Transparent Bridging

When a bridge connection is source-route transparent:

• Transparent bridging and source-route bridging modes are combined.
  
  
• The bridge connection learns route descriptors for frames that contain a RIF and learns the source MAC addresses for frames that do not contain a RIF.
  
  
• Non-source-route frames are forwarded based on the destination address.
  
  
• Source-route frames are forwarded based on the route descriptor.
  
  
• All-routes explorer and spanning-tree explorer frames are issued and forwarded.
  
  
• The IEEE Spanning-Tree Protocol is used to eliminate loops for non-source-route and spanning-tree explorer frames.
  
  

Source-Route Bridging

When a bridge connection is source-route:

• The bridge connection learns the source MAC address for frames that originate from the local ring and the route descriptor for frames that originate on the other side of a source-route bridge.
  
  
• Non-source-route frames are not forwarded.
  
  
• Source-route frames are forwarded based on the route descriptor.
  
  
• All-routes explorer and spanning-tree explorer frames are issued and forwarded.
  
  
• The IBM Spanning-Tree Protocol is used to eliminate loops only for spanning-tree explorer frames.
  
  

The IBM Spanning-Tree Protocol BPDU format is:

One of the rules in processing source-route traffic is that a source-route frame should never be forwarded to a ring that it has previously traversed. If the RIF of a source-route frame already contains the ring number for the next hop, the bridge assumes that the frame has already been on that ring and drops the frame.

With Token Ring VLANs, however, this rule can cause a problem. With the existing Spanning-Tree Protocol, a frame that originated on one physical ring of a Token Ring VLAN and is processed by an external SRT bridge would not be forwarded to another physical ring of the same Token Ring VLAN. Therefore, the IEEE 802.1d Spanning-Tree Protocol was used as a basis to create the Cisco Spanning-Tree Protocol. The Cisco Spanning-Tree Protocol ensures that traffic from one physical ring of a VLAN is not blocked from the other physical rings that comprise the VLAN.

The Cisco Spanning-Tree Protocol BPDU format is: