You want to set up DLSw to allow Token Ring bridging through an IP network.
There are many different ways to configure two routers to allow Token Ring-to-Token Ring bridging through DLSw. The most common reason for doing this is to allow Token Ring SNA LLC2 devices to communicate with a mainframe FEP attached to another Token Ring. It is relatively common to have many remote rings connecting to a single central ring. In cases like this, it is often best to use one or more dedicated DLSw routers at the central location. The CPU overhead required for supporting a large number of DLSw connections can be relatively high, so it is useful to restrict this functionality to special-purpose DLSw routers and keep it off of routers that also need to handle core routing functions.
Here is the DLSw configuration for a central router, which is the one that connects directly to the ring that holds the FEP:
dlsw-central#configure terminal Enter configuration commands, one per line. End with CNTL/Z. dlsw-central(config)#interface Loopback0 dlsw-central(config-if)#ip address 10.1.1.5 255.255.255.252 dlsw-central(config-if)#exit dlsw-central(config)#access-list 701 permit 4000.3745.AAAA 8000.0000.0000 dlsw-central(config)#source-bridge ring-group 101 dlsw-central(config)#dlsw local-peer peer-id 10.1.1.5 promiscuous dlsw-central(config)#dlsw timer explorer-wait-time 5 dlsw-central(config)#dlsw icanreach mac-exclusive dlsw-central(config)#dlsw icanreach mac-address 4000.3745.AAAA mask ffff.ffff.ffff dlsw-central(config)#dlsw cache-ignore-netbios-datagram dlsw-central(config)#dlsw allroute-sna dlsw-central(config)#interface TokenRing0 dlsw-central(config-if)#description Ring number 0x00A (10) dlsw-central(config-if)#source-bridge 10 5 101 dlsw-central(config-if)#source-bridge spanning dlsw-central(config-if)#source-bridge input-address-list 701 dlsw-central(config-if)#end dlsw-central#
And the remote routers are configured like this:
dlsw-branch#configure terminal Enter configuration commands, one per line. End with CNTL/Z. dlsw-branch(config)#interface Loopback0 dlsw-branch(config-if)#ip address 10.1.2.5 255.255.255.252 dlsw-branch(config-if)#exit dlsw-branch(config)#access-list 200 permit 0x0000 0x0D0D dlsw-branch(config)#source-bridge ring-group 101 dlsw-branch(config)#dlsw local-peer peer-id 10.1.2.5 dlsw-branch(config)#dlsw timer explorer-wait-time 5 dlsw-branch(config)#dlsw remote-peer 0 tcp 10.1.1.5 lsap-output-list 200 dlsw-branch(config)#dlsw allroute-sna dlsw-branch(config)#interface TokenRing0 dlsw-branch(config-if)#description branch Token Ring 0x047 (71) dlsw-branch(config-if)#multiring all dlsw-branch(config-if)#source-bridge 71 5 101 dlsw-branch(config-if)#source-bridge spanning dlsw-branch(config-if)#end dlsw-branch#
These configurations will work well for situations in which a large number of remote routers need to make DLSw connections to a central router. However, if you only need to connect two routers, you can still use the same pair of configurations. In that case, you simply need to decide which router will initiate the session. The initiating router will use the dlsw-branch configuration, and the receiving router will be dlsw-central. The initiating router will start trying to establish the connection as soon as it boots, and will continue periodically until it succeeds. This is true whether or not there is any traffic ready to be sent through this connection.
The first things to notice about these two configurations are the dlsw local-peer and dlsw remote-peer statements. These statements must match. In this case the branch router uses the address 10.1.1.5 to specify the remote peer. This address corresponds to the Loopback0 interface on the central router. So, on the central router, it is critically important that the local-peer statement points to this same IP address.
The central router does not have a dlsw remote-peer statement. This is because the central router will not establish DLSw connections. The promiscuous keyword in the local-peer statement allows this router to simply accept incoming connections from other routers. In this example we expect to have many remote branch routers connecting to the same central router. Configuring a separate remote peer on the central router for every branch would be an onerous task, particularly if branch routers are frequently added and deleted. When building a many-to-one type bridge, it is generally preferable to configure the central router to simply accept all remote peers.
This means that the central router will accept a DLSw connection from anybody. Naturally it doesn't make sense to configure promiscuous on both routers because one of them has to initiate the connection. So the branch router is configured with normal point-to-point local-peer and remote-peer commands.
When configuring the local and remote DLSw peers, you can specify the IP address for any interface on the router, as long as both routers agree on which address is to be used. In these configuration files both local peers point to the respective Loopback0 interfaces on each router. This is because the Loopback0 interface is a purely internal software port that can never become unavailable due to an external failure. If the router is reachable at all through any path, then the Loopback0 interface is reachable, and consequently the DLSw peer relationship will be kept alive. In the case of Token Ring to Token Ring bridging, it may make sense to bring down the peer relationship when one of the rings fails. In this case, you can configure the local peers to point to an IP address on the Token Ring interface itself. However, if either router supports more than one SNA interface, such as a second Token Ring or an SDLC serial port, then you will probably not want your SDLC traffic to fail just because of a Token Ring failure.
There are only two routers in this example, but it is relatively common to have a backup router on the central ring. Each router can have many remote peers, each configured with a separate dlsw remote-peer statement.
There are two other pieces of information in the dlsw remote-peer command on the branch router:
dlsw remote-peer 0 tcp 10.1.1.5 lsap-output-list 200
The number 0 in the third field is a list number. The value of 0 is the default, and is sufficient for most applications. If any other value is specified, it tells DLSw that you want to set up ring lists or port lists. You would do this if you wanted to bridge traffic from one ring to one remote DLSw peer and traffic from another ring to a different peer. For example, if your router has four different rings, and you only want rings 1, 2, and 4 (but not 3) to use this particular DLSw peer, then you would configure a port list as follows, arbitrarily calling this port list number 5:
Router(config)#dlsw port-list 5 tokenring 1 tokenring 2 tokenring 4 Router(config)#dlsw remote-peer 5 tcp 10.1.1.5
An alternative way of doing this would be to use the ring numbers. If, for example, the ring number associated with these Token Ring interfaces were 70, 95, and 142 (all of these ring numbers are in decimal rather than the more conventional hexadecimal notation, which would be 46, 5F, and 8E, respectively), you could accomplish the same thing with a dlsw ring-list command:
Router(config)#dlsw ring-list 5 rings 70 95 142 Router(config)#dlsw remote-peer 5 tcp 10.1.1.5
Note that, in general, if you are working with physical rings, there is usually less danger of confusion when using the port-list version of this command. It is easy to become confused by virtual ring numbers and bridge numbers and so forth when constructing a ring list, particularly because most devices will represent these values in hexadecimal notation, while the router uses decimal.
In both versions, if there are other Token Ring interfaces that do not appear in any ring list, then they will not take part in any DLSw bridging. Alternatively, you could create more port lists or ring lists representing these other rings, and create more dlsw remote-peer statements for them, as follows:
Router(config)#dlsw port-list 5 tokenring 1 tokenring 2 tokenring 4 Router(config)#dlsw port-list 6 tokenring 3 Router(config)#dlsw remote-peer 5 tcp 10.1.1.5 Router(config)#dlsw remote-peer 6 tcp 10.1.1.9
These list numbers only have local significance to the router they are set on. So, if you are sending port list 5 to 10.1.1.5 and 6 to 10.1.1.9 (as in this example), there is nothing special required to complete that relationship on the remote peer routers. The other router doesn't know or care that it isn't getting all of this router's DLSw traffic.
The last parts of the remote-peer command on the branch router define an lsap-output-list, and associate it with access list 200. This is optional, but useful. To understand what it does, please refer to the discussion of SAPs in the introduction to this chapter.
Note the ring groups on both routers. Each router has several different ring and bridge numbers that define what connects to what. Nothing will work if you don't get these right.
Both routers have the global configuration statement that looks like this:
Router(config)#source-bridge ring-group 101
This specifies a virtual ring number that can be easily compared to a VLAN number. This ring group number is also a ring number, so it appears in RIFs. If the router has interfaces in multiple ring groups, you can simply include several of these configuration lines, one for each ring group that the router holds:
Router(config)#source-bridge ring-group 101 Router(config)#source-bridge ring-group 557 Router(config)#source-bridge ring-group 4031
This ring group number appears in the configuration of each interface that takes part in the bridge. For example, the branch Token Ring port configuration includes the following statement:
dlsw-branch(config)#interface TokenRing0
dlsw-branch(config-if)#source-bridge 71 5 101
The first number in the source-bridge interface configuration command is the local ring number, the second number is an internal bridge number, and the last number is the destination ring number. DLSw will bridge packets received on this interface to the other Token Rings around the network that are also members of this ring group.
In this case, the local ring number is 71, which would be 0x047 in the more conventional hexadecimal notation for Token Ring numbers. This local ring number is the value that appears in RIFs generated for this ring. It is essentially a network number for this ring, similar to the TCP/IP concept of a network number. The range of possible values is from 1 to 4095, and each ring number must be globally unique. So no other ring in this ring group, anywhere in the network, can have the same number. And remember also that the ring group number is itself a ring number, so no ring can have the same number as the ring group. If you configure a local ring number like this that is in conflict with a pre-existing ring number, the router will detect the error and shut down the port to prevent further communication problems on the ring.
The bridge number is an integer value expressed as a decimal number between 1 and 15. In this case the target ring number is the virtual ring number representing the entire DLSw ring group. However, this same command could be used to simply bridge two rings on the same router:
Router(config)#interface Tokenring0 Router(config-if)#source-bridge 70 5 71 Router(config-if)#interface Tokenring1 Router(config-if)#source-bridge 71 5 70 Router(config-if)#interface Tokenring2 Router(config-if)#source-bridge 72 6 73 Router(config-if)#interface Tokenring3 Router(config-if)#source-bridge 73 6 72
The bridge number is simply a locally unique identifier that the router uses to specify how it will connect these rings. In this little example, there are four rings. The first two rings are connected together through bridge number 5 and the second pair connects via bridge number 6. In the larger DLSw example, the target ring is the ring group number. The bridge number is unique only to the router it is configured on, and is particularly useful when you want to have different rings connected to different destinations.
Another important source-bridge feature shown in the example is the input-address-list keyword:
dlsw-central(config)#access-list 701 permit 4000.3745.AAAA 8000.0000.0000 dlsw-central(config)#interface TokenRing0 dlsw-central(config-if)#source-bridge input-address-list 701
This ensures that the bridge will pick up packets from the ring only if they have the source address shown in the access list. Note that this is the same MAC address that we used in the dlsw icanreach command:
dlsw-central(config)#dlsw icanreach mac-address 4000.3745.AAAA mask ffff.ffff.ffff
This is the MAC address of the FEP in our example. The reason for the input filter on the source-bridge command is simply to ensure that the router only forwards packets that originate with the FEP. Bear in mind that DLSw potentially bridges a large number of rings together, so there could be a lot of strange and unexpected packets floating around on the FEP ring. In particular, we want to prevent our branch routers from talking directly to one another and wasting bandwidth.
As mentioned in the introduction to this chapter, the LLC protocol used in most Token Ring networks uses packets called explorers to build RIFs for source-routing packets. DLSw+ includes several options for improving the efficiency of this process.
The first of these options appears in this line, which is in both of the example router configurations:
dlsw-central(config)#dlsw allroute-sna
This command simply tells the router to use all routes explorers, rather than single route (or spanning tree) explorers when trying to find an SNA device. This command appears to be contradicted by the use of source-bridge spanning on the Token Ring interfaces of both routers, but it isn't actually a contradiction. In fact, this provides an important advantage. The source-bridge spanning command simply prevents end devices on the Token Ring from using all routes explorers. The routers themselves are still allowed to use all routes explorers when communicating between themselves, however. This way, the routers maintain control over network routing, while at the same time preventing end devices from wasting network resources by sending out all route explorers unnecessarily.
The second important explorer configuration command also appears on both routers:
dlsw-central(config)#dlsw timer explorer-wait-time 5
This statement tells the routers to wait for five seconds after sending an explorer, to ensure that it has received the results from all of the possible DLSw peers. This helps to ensure that it will always pick the best path. The default value if this command is not present is zero seconds, meaning that the router will always use the first path it sees. Clearly, this is only important when using all routes explorers.
At the host router we have configured two icanreach statements:
dlsw-central(config)#dlsw icanreach mac-exclusive dlsw-central(config)#dlsw icanreach mac-address 4000.3745.AAAA mask ffff.ffff.ffff
This tells the router to restrict inbound traffic so that the only MAC address that a remote device can reach through DLSw is the one that we have configured (4000.3745.AAAA). This usually corresponds to the mainframe's FEP address. You can easily include several MAC address definitions in the same way if there are other devices to which you want to allow access.
This helps to prevent unwanted traffic from being bridged across your WAN. In particular, it ensures that DLSw will not bridge from one remote site to another.
Note that the end devices on the Token Ring only need the RIF representing the local DLSw router. DLSw is said to "terminate the RIF," meaning that it effectively creates three regions of RIF tables, from end device A to Router A, from Router A to Router Z, and from Router Z to end device Z. This is different from RSRB, for example, which passes RIF information through the network so that end devices can specify their paths. In DLSw, however, the routers take over path selection. This allows the router to respond to local RIF requests without passing them through the network. It also drastically reduces the storage required for RIF tables on all devices.
There are a couple of other small commands in these examples that allow specific functionality or improve efficiency. On the central router you will see the command dlsw cache-ignore-netbios-datagram. This simply tells the router to ignore NetBIOS names that it receives through DLSw. This is useful in large networks because it allows the central router to avoid having to maintain a large NetBIOS name cache. Since all connections are inbound anyway, the NetBIOS names of remote devices are never used in such a configuration, so this command allows you to ignore them.
Finally, on the branch router, we have included the line multiring all in the configuration of the Token Ring interface. There are actually several different options besides all for this command. The most common one is multiring ip. The all option allows all routable protocols such as TCP/IP and IPX to use the interface for routing, while purely bridged protocols like SNA are permitted to use it for bridging. Specifying multiring ip allows IP to use the interface, but not another routed protocol such as IPX.
|
|
|
| Top |