Token Ring

Document ID: 29964

Contents

Introduction
Before You Begin
      Conventions
      Prerequisites
      Components Used
Problem
Solution(s)
      Solution 1
      Solution 2
      Solution 3
Related Information

Introduction

When the same IP subnet is required to reside on a Token Ring and Ethernet subnet, pings may not work. The bitswap-layer3-addresses command is required for this to work because of canonical/non-canonical MAC addressing. This document provides solutions and sample configurations using the bitswap-layer3-addresses command.

Before You Begin

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Prerequisites

There are no specific prerequisites for this document.

Components Used

This bridge x bitswap-layer3-addresses command is available in the Enterprise feature set only and was introduced in the 11.3.5T IOS.

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Problem

Ethernet and Token Ring topologies read MAC addresses differently. For example, a MAC address of 4040.4040.4040 on Ethernet is read as 0202.0202.0202 on Token Ring. When a device on one media pings to a device on the other media and the Cisco device is acting as a transparent bridge, the Address Resolution Protocol (ARP) response has data in the higher layer of the response that is not bitflipped.

For example, PC-A's MAC address is 4040.4040.4040 on Ethernet, and pings to PC-B with a MAC address of 1234.5678.9abc. On Token Ring, the ARP request is read leaving PC-A on Ethernet sourced from 4040.4040.4040 and destination to FFFF.FFFF.FFFF. The Cisco device will bitflip the MAC addresses and send the ARP request to the Token Ring, and the frame will be read as sourced from 0202.0202.0202 to destination FFFF.FFFF.FFFF.

PC-B will now reply with the ARP reply sourcing the frame from 1234.5678.9abc to destination 0202.0202.0202 and will add into the data portion of the frame the IP address of PC-B, as associated with MAC address 1234.5678.9abc. The ARP reply will be bridged through the Cisco device and delivered onto the Ethernet with a source MAC address of 482c.6a1e.593d, and to a destination of 4040.4040.4040.

The problem resides in the fact the data returned in the ARP reply indicates to PC-A that the MAC address of PC-B is 1234.5678.9abc. PC-A believes it knows the MAC address of PC-B and sends the Internet Control Message Protocol (ICMP) to the 1234.5678.9abc MAC address and not to the bitflipped version of PC-B's address, which would be 482c.6a1e.3d.

Solution(s)

The bridge x bitswap-layer3-addresses command resolves this inconsistency by changing the ARP reply data to match the bitflipping at the source and destination MAC addressing. When this command is issued, the router will change the ARP reply's data indicating PC-B's MAC address is 1234.5678.9abc to the Ethernet version of 482c.6a1e.593d. PC-B will reply normally, but the Cisco device will alter the packet as it is delivered onto the Ethernet so that the source MAC address matches the data portion of the ARP reply. The bitswap-layer3-addresses command only resolves IP ARP.

Since Dynamic Host Configuration Protocol (DHCP) / Bootstrap Protocol (BOOTP) requests usually include MAC addressing in the data portion of the requests, this implementation does not accommodate DHCP or BOOTP requests through the Cisco router. The IPX protocol suffers from the same issue as described above with MAC addressing, however bitswap-layer3-addresses do not include IPX. Therefore, IPX should be routed on the Cisco device and is an independent configuration. For Layer 2 (L2) protocols, such as Netbios not encapsulated into IP, Systems Network Architecture (SNA), and DLC, a Source-Route Bridging (SRB) configuration should be used. The IPX is an independent protocol configuration.

Solution 1

In the most simple case, the configuration below on the router allows IP communication for devices through the router.

no ip routing 

interface ethernet0 
    bridge-group 1 
interface tokenring0 
    bridge-group 1 

bridge 1 protocol ieee 
bridge 1 bitswap-layer3-addresses

Solution 2

IPX routing is added to the configuration. Novell server(s) on the respective media will have different external network numbers and these numbers will be configured on the Cisco device to match these external network numbers. Networks 1 and 2 are used as examples. Of course, the internal network numbers must be unique in the network.

no ip routing 
ipx routing 

interface ethernet0 
    bridge-group 1 
    ipx network 1 
interface tokenring0 
    bridge-group 1 
    ipx network 2 

bridge 1 protocol ieee 
bridge 1 bitswap-layer3-addresses

Solution 3

For solutions requiring IP connectivity for IP and SNA/DLC/NetBIOS connectivity, the bitswap-layer3-addresses command is issued to pass the IP traffic, and a SRTLB configuration is used to bridge the L2 protocols. Again, the numbers used are arbitrary and are used for the sample configurations. In most cases, the most important number in this sample configuration is the ring-number used on the Token Ring interface. It is vital that all devices are configured to indicate the same physical ring number. In this configuration, the ring number is configured to be 10 or hexadecimal 0xA.

no ip routing 
source-bridge ring-group 999 
source-bridge transparent 999 998 2 1 
interface Ethernet0 
    bridge-group 1 
interface tokenring0 
    bridge-group 1 
    source-bridge 10 1 999 
    source-bridge spanning 

bridge 1 protocol ieee 
bridge 1 bitswap-layer3-addresses

Related Information

• Bitswapping Tool (registered customers only)
• Technology Support
• Product Support
• Technical Support - Cisco Systems