Configuring DLSw

Problem

You want to set up DLSw to allow Token Ring bridging through an IP network.

Solution

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 Front End Processor (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 central router, which is the one that connects directly to the ring that holds the FEP:

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)#exit
dlsw-central(config)#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)#exit
dlsw-branch(config)#end
dlsw-branch#

 

Discussion

These configurations will work well for situations when 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 to ready to send through this connection.

The peers

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 must also point 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 added and deleted frequently. 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, for example. 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-branch(config)#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, 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, 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 Service Access Points in the "Introduction" section of this chapter.

Ring groups, ring numbers, and bridge numbers

Notice 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 different ring-groups, you can simply include several of them 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 line 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 14,095, 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. It is important to note that 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 as follows:

Router(config)#interface Tokenring0
Router(config-if)#source-bridge 70 5 71
Router(config-if)#exit
Router(config)#interface Tokenring1
Router(config-if)#source-bridge 71 5 70
Router(config-if)#exit
Router(config)#interface Tokenring2
Router(config-if)#source-bridge 72 6 73
Router(config-if)#exit
Router(config)#interface Tokenring3
Router(config-if)#source-bridge 73 6 72
Router(config-if)#exit

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 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 only pick up packets from the ring if they have the source address shown in the access-list. Notice that this is the same MAC address that we used in the dlsw icanreach command, which we discuss in a moment:

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 bridges a potentially large number of rings, 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.

Explorer options

As mentioned in the Introduction to this chapter, the Logical Link Control protocol (LLC) used in most Token Ring networks uses packets called explorers to build Routing Information Fields (RIF) 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 appears 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 among themselves, however. In 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 the only MAC address that a remote device can reach through DLSw is the one that we have configured4000.3745.AAAA, in this case. This would usually correspond 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 nobody can use DLSw to bridge from one remote site to another.

It is important to 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.

Other features

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. Because 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.

And, 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 would be 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 allow IP to use the interface, but not another routed protocol such as IPX.