Local source-route bridging, or SRB, is an IBM feature that bridges packets from one interface on a router to another interface on the same router. There are two basic scenarios for using it: bridging only two rings together, and either bridging more than two rings or combining SRB with other IBM features such as RSRB, SDLLC, and QLLC.
The configurations depicted here are partial configurations - they portray only that part of the configuration required for source-route bridging support, and none of the IP or other protocol support. In addition, depending on your topology and traffic type, you may need to use the source-bridge spanning interface command or the IBM Automatic Spanning Tree support available in IOS 10.2 or later. See the document on IBM Spanning Tree to determine whether this is a requirement for you.
Token T0 ---------- T1 Token Ring 1------| ROUTER |------Ring 2 ----------
With this topology, simple SRB is the best solution. In order to use simple SRB, each of these rings must have a ring number. If there are any other source-route bridges on these rings, then ring numbers have already been assigned, and those defined to the routers must agree with the other bridges on the rings. Otherwise, any unique ring number can be used.
interface tokenring 0 source-bridge 1 1 2 source-bridge spanning
interface tokenring 1 source-bridge 2 1 1 source-bridge spanning
In this example, since there are no other Source-Route Bridges in the network, we can pick our own ring numbers. We have assigned ring number 1 to the ring attached to interface Token Ring 0, and ring number 2 to the ring attached to interface Token Ring 1. The middle number is the bridge number - this must be defined to be the same number on both interfaces. We are telling interface Token Ring 0 that it is attached to ring 1, and it is to send source-route bridged traffic over bridge 1 to ring 2. Similarly, interface Token Ring 1 is attached to ring 2, and it is to send source-route bridged traffic over bridge 1 to ring 1.
If the source ring on one interface did not match the destination ring on the other, or if the bridge numbers were not set to the same value, no source-route bridged traffic would flow between these two interfaces.
In this case, we have to do some planning before we can configure the router interface. Let's assume that there is another Cisco router doing SRB on the same ring as interface Token Ring 0. Further, there's an IBM bridge on the same ring as interface Token Ring 1. The other Cisco router is defined to be on ring 100, and the IBM bridge is defined to be on ring 200. The router needs to be configured as follows:
interface tokenring 0 source-bridge 100 1 512 source-bridge spanning
interface tokenring 1 source-bridge 512 1 100 source-bridge spanning
Even though the IBM bridge claims that the ring is 200, we are configuring the router as if it resides on ring 512. While Cisco routers define the ring as a decimal value, IBM bridges use hex values to represent their rings. So in order to match the definition on the IBM, use ox {decimal} and the conversion will be done auromatically.
If there are other source-route bridging devices besides Cisco routers and IBM bridges, you will need to determine whether those devices use decimal or hexadecimal values to represent ring numbers in order to determine how to configure the Cisco router interfaces.
Before installing any source-route bridging device between two existing bridged environments, you should always check to make sure that you will not have duplicate ring numbers within your source-route bridging network. In this case, ring numbers need to be changed before the installation of the new router/bridge. It is possible that bridge number 1 was in use in both the source-route bridging network behind the existing Cisco and the network behind the IBM bridge.
With the previous example, there is another configuration option that involves creating a ring-group, also known as a virtual ring. Here's a configuration example:
source-bridge ring-group 4095
interface tokenring 0 source-bridge 1 1 4095 source-bridge spanning
interface tokenring 1 source-bridge 2 1 4095 source-bridge spanning
The net effect of this configuration seems the same as that of the first configuration sample - interface Token Ring 0 is defined to be on ring 1, interface Token Ring 1 is defined to be on ring 2, and traffic is bridged between these two interfaces. However, there is a slight difference, in that end stations think they are sending traffic from ring 1 to ring 4095 (the virtual ring), from which it is sent to ring 2. The traffic takes an extra hop onto the virtual ring before reaching its destination.
Even though there is a limit (of seven) to the number of hops source-route bridged traffic can take, sometimes it is helpful to force the extra hop. Consider the following scenario:
Token Ring 2 | |T1 Token T0 ---------- T2 Token Ring 1------| ROUTER |------Ring 3 ----------
Assume we wanted to bridge traffic from any ring to any other ring. Trying to extend the prior configuration, you might think that the configuration would look like this:
interface tokenring 0 * INCORRECT configuration * source-bridge 1 1 2 * INCORRECT configuration * source-bridge 1 1 3 * INCORRECT configuration *
interface tokenring 1 * INCORRECT configuration * source-bridge 2 1 1 * INCORRECT configuration * source-bridge 2 1 3 * INCORRECT configuration *
interface tokenring 2 * INCORRECT configuration * source-bridge 3 1 1 * INCORRECT configuration * source-bridge 3 1 2 * INCORRECT configuration *
However, each interface supports only one source-bridge command - attempting to configure a second one will simply overwrite the first. The virtual ring gives us a mechanism to get around this limitation:
source-bridge ring-group 4095
interface tokenring 0 source-bridge 1 1 4095 source-bridge spanning
interface tokenring 1 source-bridge 2 1 4095 source-bridge spanning
interface tokenring 2
source-bridge 3 1 4095
source-bridge spanning
This will do the trick - each ring will be able to bridge traffic to the other two interfaces. Even if you are only bridging two interfaces together, use the virtual ring if you ever expect to be adding additional interfaces on the router to the source-route bridged network, or if you plan on adding remote source-route bridging to the router.
In the case above, the bridge numbers do not have to match, unlike simple SRB. This would work just as well if the router were configured like this:
source-bridge ring-group 4095
interface tokenring 0 source-bridge 1 1 4095 source-bridge spanning
interface tokenring 1 source-bridge 2 4 4095 source-bridge spanning
interface tokenring 2 source-bridge 3 9 4095 source-bridge spanning
Any number of Token Ring interfaces on a router can be source-route bridged together in this manner. The configuration above would simply be extended as follows:
interface tokenring 3 source-bridge 4 1 4095 source-bridge spanning
interface tokenring 4
source-bridge 5 1 4095
source-bridge spanning
[...and so on]
Now take a look at this environment, where two separate Token Ring interfaces are on the same ring for redundancy.
T0 ---------- T2 Token ------| ROUTER |------Token Ring 1------| | Ring 2 T1 ----------
This can be supported. The key thing to remember is that in the case of parallel bridges - two separate bridges connecting ring x and ring y - each of the bridges must have a unique bridge number. In order to support this environment, the router configuration could be as follows:
source-bridge ring-group 4095
interface tokenring 0 source-bridge 1 1 4095 source-bridge spanning
interface tokenring 1 source-bridge 1 2 4095 source-bridge spanning
interface tokenring 2
source-bridge 2 1 4095
source-bridge spanning