You want to set up DLSw to allow Token Ring to Ethernet bridging.
DLSw includes the capability to bridge different kinds of media. One common example of this is bridging an Ethernet segment to a Token Ring. In this example, we will suppose that we are connecting an Ethernet branch to the same central Token Ring DLSw router from Recipe 15.2:
dlsw-ether-branch#configure terminal Enter configuration commands, one per line. End with CNTL/Z. dlsw-ether-branch(config)#interface Loopback0 dlsw-ether-branch(config-if)#ip address 10.1.3.5 255.255.255.252 dlsw-ether-branch(config-if)#exit dlsw-ether-branch(config)#access-list 200 permit 0x0000 0x0D0D dlsw-ether-branch(config)#source-bridge ring-group 101 dlsw-ether-branch(config)#dlsw local-peer peer-id 10.1.3.5 dlsw-ether-branch(config)#dlsw timer explorer-wait-time 5 dlsw-ether-branch(config)#dlsw remote-peer 0 tcp 10.1.1.5 lf 1470 lsap-output-list 200 dlsw-ether-branch(config)#dlsw bridge-group 1 dlsw-ether-branch(config)#dlsw transparent switch-support dlsw-ether-branch(config)#dlsw allroute-sna dlsw-ether-branch(config)#interface Ethernet0 dlsw-ether-branch(config-if)#description branch Ethernet dlsw-ether-branch(config-if)#bridge-group 1 dlsw-ether-branch(config-if)#bridge 1 protocol ieee dlsw-ether-branch(config-if)#exit dlsw-ether-branch(config)#end dlsw-ether-branch#
Before looking at this in detail, we need to stress that routable protocols such as TCP/IP always behave better when they are routed. So you should only use bridging between different media, as in this example, when there are unroutable protocols that must communicate between them. Perhaps the most common example is when LLC2 SNA devices must be accessed from an Ethernet segment.
The important differences between this Ethernet branch example and the preceding Token Ring example are highlighted. The first difference is in the remote-peer command, where we added the flag lf 1470. This restricts the MTU of the bridged network to 1470 bytes so that the larger Token Ring frames cannot use the bridge. Token Ring supports much larger frames than Ethernet does. In a bridged network, there is no packet fragmentation facility as there is in routed networks. So if large Token Ring packets cross the bridge to an Ethernet segment, they must be dropped.
Ideally, this MTU restriction should be made on the remote-peer commands at both ends. If your central router must support both Ethernet and Token Ring branches, then it makes sense to configure two remote-peer commands on the central router, one for each type of remote medium. The command that the central router uses for bridging to Ethernet segments should then have the MTU restricted in the same way with the lf 1470 flag. If you like, you could also have a separate statement on the central router for remote Token Ring peers that can use the default value.
The next important difference between this Ethernet branch and the previous Token Ring branch is the presence of the command dlsw transparent switch-support. This is used in cases when the Ethernet segment that the router is connecting to the bridge is itself bridged. This would be the case if the local Ethernet segment contains an Ethernet switch. Remember from the Introduction of this chapter that all Ethernet switches are transparent bridges. This command is particularly important when there are two redundant DLSw routers on this Ethernet segment. In such a case, the switch will become confused by the fact that the same downstream MAC addresses appear from both routers. If you are using Ethernet hubs, this command is not necessary.
The interface configuration for Ethernet is completely different from the Token Ring example. There are three commands in this example that define the bridging characteristics of the Ethernet interface. The first is the bridge-group command, found in the Ethernet interface configuration block. This command tells the router to associate this interface with the first logical bridge group in the router. This number is purely local to the router. You could build a bridge between two Ethernet interfaces on the same router as follows:
Router(config)#interface Ethernet0 Router(config-if)#bridge-group 1 Router(config-if)#exit Router(config)#interface Ethernet1 Router(config-if)#bridge-group 1 Router(config-if)#exit
But in the example, we want to connect this Ethernet port to a Token Ring on another router, so we have associated this bridge group instead with DLSw by using the dlsw bridge-group global configuration command:
dlsw-ether-branch(config)#dlsw bridge-group 1 dlsw-ether-branch(config)#interface Ethernet0 dlsw-ether-branch(config-if)#bridge-group 1
Then the bridging behaviour is defined with the following command:
dlsw-ether-branch(config-if)#bridge 1 protocol ieee
This command tells the router to use the IEEE 802.1d Spanning Tree Protocol for avoiding loops when creating the bridge, instead of the older and incompatible Digital Equipment Corporation (DEC) standard. Unless you are connecting to extremely old equipment that doesn't support the IEEE standard, you should always use this command.
Ethernet II or 802.3 framing
Bridging Ethernet frames to Token Ring frames actually introduces an important ambiguity. There are two different Ethernet framing standards: the older Ethernet II standard that is commonly used for TCP/IP, and the newer IEEE 802.3 standard that is used for many other protocols. The most immediately important difference between 802.3 and Ethernet standards is whether the header field immediately after the destination and source addresses is a length (less than 1500), as in 802.3, or a type (greater than 1500), as in Ethernet II.
The translation for 802.3 Ethernet frames is relatively clean because the Token Ring frames have a similar format, as they both share the same 802.2 header format. So this is the default, and this is what is shown in the example above. However, if you want to use Ethernet II framing for the bridged protocols on the Ethernet side, you have to configure the router to understand this frame type.
As an aside, you should bear in mind that you can run different Ethernet frame types for different protocols running on the same Ethernet segment. For example, it is relatively common to use 802.3 framing for IPX, while IP is always Ethernet II. There is no inherent conflict in running both of these frame types at the same time. It only becomes a problem if, for example, some of the IPX devices used one frame type and some used the other.
The Ethernet II frame type field has a value of 0x80d5 when bridging Ethernet II to Token Ring. This frame type technically refers to SNA traffic, although it applies equally to any traffic bridged from a Token Ring. To tell the router to use Ethernet II framing, you must apply this globally to all source-route bridging as follows:
Note this is a global command affecting all Ethernet interfaces on the router. You cannot have some interfaces using Ethernet II and others using 802.3 framing for bridging.