Understanding Translational and Encapsulation Bridging
Available Languages
Contents
Introduction
Cisco supports all bridging standards, including transparent bridging, Source Route Bridging (SRB), source route transparent bridging, Source Route Translational Bridging (SR/TLB), translational bridging on FCIT cards, and encapsulation bridging. This document discusses the following types of bridging:
-
Translational bridging: bridging between LAN media types that have dissimilar Media Access Control (MAC) sublayer protocols.
-
Encapsulation bridging: bridging that carries Ethernet frames from one router to another across dissimilar media, such as serial and Fiber Distributed Data Interface (FDDI) lines.
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 document is not restricted to specific software and hardware versions.
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.
Translational Bridging
Translational bridging allows you to bridge between dissimilar LANs, commonly Ethernet and Token Ring, or Ethernet and FDDI. In the case of Ethernet and Token Ring bridging, translational bridging only allows connectivity for non-routable protocols such as Local-Area Transport (LAT), Maintenance Operation Protocol (MOP), and Network Basic Input/Output System (NetBIOS).
The translation for bridging between Ethernet/Token Ring and Ethernet/ FDDI requires bit order reversal because the internal representation of MAC addresses is different on Ethernet, Token Ring, and FDDI. Ethernet is little endian (it transmits least order bit first), and Token Ring and FDDI are big endian (transmit high order bit first). For example, address 0000.0cxx.xxxx on Ethernet would appear as 0000.30yy.yyyy on Token Ring since every byte needs to be bit-swapped. Both Ethernet and Token Ring use the first transmitted bit of a frame's destination address to determine whether the frame is unicast or multicast. With no address conversion, a unicast frame (a frame that has only one destination) on one network may appear as multicast address (an address for more than one station) on another network.
Remember that Ethernet and Token Ring bridging is only possible with non-routable protocols. At times, MAC addresses are carried in the data portion of a frame. For instance, Address Resolution Protocol (ARP) places the hardware address in the data portion of the the link-layer frame. It is simple to convert source and destination addresses in the header, but conversion of hardware addresses that may appear in the data portion is more difficult. When performing source route transparent or source route translational bridging between Ethernet and Token Ring, Cisco does not search for instances of hardware addresses in the data portion. Only non-routable protocols work with Ethernet and Token Ring bridging.
Translational bridging between Ethernet and FDDI carries the issue of bit reversal a little further since few protocols work across the FDDI and Ethernet barrier. One reason for this is the concept of a canonical address above the MAC layer - any address that is above the MAC layer on FDDI should be ordered canonically according to Ethernet order. This is how IP is done on FDDI, and it is why Cisco can bridge it when going from Ethernet to FDDI. Unfortunately, other protocols do not do this.
The protocols below can be translationally bridged between Ethernet and FDDI.
-
IP
-
OSI
-
DECnet
-
Non-routable protocols (NetBIOS, MOP, and LAT)
Below are the analyzer traces for an IP ARP request packet from Ethernet to FDDI, and the response from FDDI back to Ethernet. In the ARP header, FDDI always uses the Ethernet MAC address (canonical order).
ARP Request Packet (Ethernet to FDDI)
Ethernet
0000 FF FF FF FF FF FF 00 00 0C 0C 01 4C 08 06 00 01
^------------------^
|source mac address|
0010 08 00 06 04 00 01 00 00 0C 0C 01 4C 83 6C 46 02
^------------------^
|source mac address|
|in ARP header |
0020 00 00 00 00 00 00 83 6C 46 0B 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00
|
|
|
\|/
FDDI
0000- 50 FF FF FF FF FF FF 00 00 30 30 80 32 AA AA 03
^-----------------^
|bit swapped |
|source mac |
|address of |
|0000.0c0c.014c |
0010- 00 00 00 08 06 00 01 08 00 06 04 00 01 00 00 0C
^--------
0020- 0C 01 4C 83 6C 46 02 00 00 00 00 00 00 83 6C 46
--------^
|source mac
|address in
|ARP header
|(ethernet format)
0030- 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040- 00 00 00 F5 8E C1 88
ARP Response Packet (FDDI to Ethernet)
FDDI
0000- 50 00 00 30 30 80 32 00 00 30 C0 E9 D7 AA AA 03
^-----------------^------------------^
|source mac address|destination mac address
|(bit-swapped |(bit-swapped
|0000.0c03.97eb) |0000.0c0c.014c)
0010- 00 00 00 08 06 00 01 08 00 06 04 00 02 00 00 0C
^--------
0020- 03 97 EB 83 6C 46 0B 00 00 0C 0C 01 4C 83 6C 46
--------^ ^-----------------^
|source mac |destination mac |
|address in |address in ARP |
|ARP header |header (ethernet |
|(ethernet format) |format) |
0030- 02 23 B8 7D C2
|
|
|
\|/
Ethernet
0000 00 00 0C 0C 01 4C 00 00 0C 03 97 EB 08 06 00 01
0010 08 00 06 04 00 02 00 00 0C 03 97 EB 83 6C 46 0B
0020 00 00 0C 0C 01 4C 83 6C 46 02 23 B8 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00
Encapsulation Bridging
Encapsulation bridging encloses the Ethernet frame into the FDDI frame, allowing it to be moved from one Ethernet to the other across the FDDI backbone. Once the packet has arrived at the destination bridge, it needs to be de-encapsulated before being forwarded to the host on the destination Ethernet. Cisco supports encapsulation bridging on FDDI interfaces as well as translational bridging.
There is no standard for encapsulation bridging. Each vendor's implementation is proprietary. Encapsulation bridging is a good solution for LAT connectivity issues in DEC environments.
Feedback