Wrapping Up DLSw

Peter J. Welcher

Introduction

The last two articles have briefly introduced Data Link Switching, DLSw.

Recall that DLSw provides remote bridging of IBM and Microsoft Token Ring LLC2 traffic across data layer links or across a TCP/IP network. DLSw can also translate Ethernet traffic to Source Route Bridged Token Ring traffic. It can also protocol translate SDLC SNA into Token Ring, but we're not going to go into that.

For scaling up NetBIOS traffic, either in large corporate nets (1000 or more nodes) or for efficient use of WAN links, you'll probably want to get to running NetBIOS over TCP/IP (NBT) rather than NetBIOS over LLC2. Controlling broadcast/explorer traffic is the name of the game. But even if you can't do this, the DLSw name and reachability caching may help performance as you increase the scale of your network.

To wrap up our discussion of DLSw, I'd like to look at an important scaling feature that's easily missed in reading the Cisco documentation -- unless you look at the examples. This feature is two items you can configure that work together: peer groups and border peers. Both are options on the DLSw local-peer command:

dlsw local-peer [peer-id ip-address] [group group] [border] [cost cost] [lf size] [keepalive seconds] [passive] [promiscuous] [biu-segment]

In this article I'm introducing Lab Experiments, things I wish I knew but can't find in the documentation (and don't have the time to explore). If you do any of these experiments and send me your results, I'd be glad to put your name and answer in this column.

Peer Groups and Border Peers

If we use the group option with a number, we've identified which group of routers the local router belongs to. So for example, configuring the following puts the local router into peer group 100:

dlsw local-peer peer-id 145.1.2.3 group 100 promiscuous

I've added the keyword promiscuous (peer-on-demand). It was discussed in the last article. We'll see why it's appropriate here below.

We then configure at least one member of the group as a border peer, by adding the word border:

dlsw local-peer peer-id 145.1.2.3 group 100 border promiscuous

The idea is for the group members to send explorers (or the CANUREACH moral equivalents) to this border peer. It then forwards it to border peers in other peer groups, as well as to the other group members.

Lab Experiment: What effect does setting up a peer group have if no border peer is configured? Do explorers find their way between peers in the group? Outside the group (I'd expect not)? You'll probably need a Sniffer and a couple of routers to try all this out.

Well, now we know roughly how to configure it. Why would we want to?

The idea here is the old "divide-and-conquer" approach. Hierarchical networking is perhaps another suitable phrase.

The point is that duplication of explorers in RSRB is a scalability limitation. DLSw uses a slightly different mechanism, but the idea is the same. Setting up peer groups means that the access routers in the peer group do not have to communicate directly with each other. They contact the border peer, which handles reachability query replication for them, both inside and outside the group. This reduces the CPU burden on the group.

Furthermore, when the reachability query is resolved, the originating access router knows the IP address of the peer it needs to communicate with, to reach the specified MAC address. At that point, the peer-on-demand features (see the last article), allow direct transmission of data to the correct peer, without involving the border peer. In other words, the border peer helps the access router find out which other router the desired MAC address lies behind. But at that point, the two routers may talk directly, not through the border peer(s).

It's almost like asking your manager, "who's in charge of hardware specifications for the XYZ project?". The manager gets the word out to your group and other managers, who contact their workgroups. When you hear that John Doe is in charge, you then contact John Doe directly. (This analogy is perhaps a bit weak unless you're a Dilbert fan: it assumes your manager doesn't know whether someone reporting to him or her is responsible for hardware specs for the XYZ project). This certainly scales better than sending email to everyone in the company or business unit! (Grin).

Example

Let's look at setting up peer groups and border peers in the following setting (see the drawing).

The network is broken into two regions, Regions A and B. We're going to set up peer groups along the regional lines, since the WAN links match this organizational scheme rather well. (And by using border peers, we have the opportunity to reduce WAN traffic as well as CPU loading on the access routers, the 2500's).

The sample configuration for router C2500-A1 follows. The other 2500's are very similar.

hostname C2500-A1
source-bridge ring-group 1000

dlsw local-peer peer-id 131.108.17.1 group 1 promiscuous

dlsw remote-peer 0 tcp 131.108.16.1

interface serial 0

ip address 131.108.17.1 255.255.255.0

Note that C2500-A1 only refers to the border peer address as a remote peer, it does not list the other members of its peer group. (Lab Experiment: What happens if it does?)

Router C2500-B1 is in another peer group, but the configuration is otherwise very similar:

hostname C2500-B1
source-bridge ring-group 1000

dlsw local-peer peer-id 131.108.33.1 group 2 promiscuous

dlsw remote-peer 0 tcp 131.108.32.1

interface serial 0

ip address 131.108.33.1 255.255.255.0

The border peers do need to know the other routers in their peer group. So the configuration on BigRouter1 might look like:

hostname BigRouter1
source-bridge ring-group 1000

dlsw local-peer peer-id 131.108.16.1 group 1 promiscuous border

! List as peers, the peers in the peer group

dlsw remote-peer 0 tcp 131.108.17.1

dlsw remote-peer 0 tcp 131.108.18.1

dlsw remote-peer 0 tcp 131.108.19.1

! and the other border peer(s)

dlsw remote-peer 0 tcp 131.108.32.1

interface loopback 0

ip address 131.108.16.1 255.255.255.0

Note that the remote peers include both the routers in the peer group BigRouter1 belongs to, as well as the other border peer. (If you omit the other border peer, BigRouter2, BigRouter1 doesn't know to ask it for reachability information).

By the way, I've used local-peer addresses of serial interfaces on the 2500's since there is no alternative route to them. If you have dial backup or some alternative route, you'll probably want to use a loopback address, because the up/down state of the serial interface might affect our ability to route DLSw packets to the router. Loopback interfaces never go down. Assuming we're advertising the subnet the loopback interface is in, if we have any possible path to the router, we'll be able to maintain our DLSw session.

Summary

That wraps up our coverage of DLSw. There's much more to be said in the way of features and technical fine points, but I suspect we've reached the point of diminishing returns. So I'll refer the DLSw die-hards to the Cisco documentation.

Netsys

Cisco has announced the new Netsys System Manager Consultant Certification program (NSMCC). This certification requires a CCIE as pre-requisite, with a Sylvan Prometric test requiring extensive knowledge of the Netsys product. There is a four-day advanced course to prepare for the NSMCC (currently available directly from Netsys, although Mentor Technologies is considering offering it). Pre-requisite for this course is the four-day Netsys course offered by Mentor Technologies. Contact netsys-advocate@cisco.com for information.

Netsys is getting extensive use in Enterprise and Service Provider environments, supporting large-scale operational deployment. The NSMCC program is intended to insure availability of people who can effectively use the Netsys Service-Level Management product in planning and operating such large networks.

Obtaining the NSMCC gives access to a 40% discount on the Netsys product, and access to a private email list for NSMCC direct interaction, with each other and with staff within Cisco.

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .