Diving Into DLSw

Peter J. Welcher

One of the questions we're often asked is "what should I study to prep for the CCIE exam?" The best answer is "what you are weak in". There are also various rumors going around about revised contents to the CCIE lab test, and you shouldn't assume the Cisco Web page is current.

The traditional prep courses have been ICRC, IMCR, ACRC, and CIT, plus our CITO lab day. I'd suggest you also consider some other courses: SNAM (SNA networking), CMTD (dial-up and ISDN), and perhaps CATV (the CAT 5000 course -- soon expanding from 2 to 4 days). ATMS (3-4 days of ATM) might also be relevant. I like the Cisco CID Design course, but it perhaps is more appropriate for budding network designers (VAR's?) than for CCIE lab prep.

This month I'd like to take a look at DLSw, which is important not only for IBM networking but for NetBIOS networks as well. The topics below are covered in much more depth in the SNAM course, along with extensive hands-on labs.

What's DLSw?

DLSw stands for "Data Link Switching".

DLSw is a multi-vendor standard developed by the AIW (APPN Implementors' Workshop). Cisco, IBM, 3Com, Bay, and other vendors have implemented DLSw. There is now an enhanced version, version 2, which incorporates some (but not all) of the scalability features Cisco has been calling "DLSw+". We won't have time to really get into this in this article (maybe a later one).

DLSw allows us to interconnect Token Ring networks running IBM Source Route Bridging (SRB) over a WAN (or other) TCP/IP network. The predecessor to DLSw is perhaps Cisco's RSRB (Remote SRB) technology.

Design Decisions

There's a choice here, if you have Cisco routers. You could go with either RSRB or DLSw. Or, if you have the choice, you might consider routing gateway traffic over IPX or IP. In addition, if you're doing NetBIOS, instead of NetBIOS over NetBEUI, you could implement NetBIOS over IPX or NetBIOS over TCP/IP (NBT). The general thought here is that it's a good idea to plan to convert to a situation where as much traffic as possible is routed.

Let's examine these in turn.

RSRB

Pro: Stable code. Possibly less work for the router, for small numbers of peers. Supports legacy SNA networking.

Con: Possible lack of future development and quick bug fixes.

DLSw

Pro: Scales better in situations with large numbers of peers. Receiving most of the current development effort. More flexible than RSRB. Supports legacy SNA networking.

Con: Depending on what else you're doing, you may expend some effort tracking down a recent IOS version where all the features work reasonably well at the same time.

DLSw+

Pro: Scales even better than DLSw. And if you're contemplating any-to-any peering in a NetBIOS network, you'll need the scaling features.

Con: Uses Cisco-proprietary extensions to DLSw.

NB/IPX

Pro: Datagrams get routed.

Con: Yes, but type-20 propagation floods NetBIOS broadcasts. This doesn't scale well. If you're going to a routed solution, why not go all the way to NBT?

NBT

Pro: Datagrams get routed.

Con: Yes, but you still need to control NetBIOS broadcasts. With a little due caution, this scales, perhaps better than the SRB-based techniques..

How Does DLSw Work?

Recall that in SRB networks, two computers that want to talk must locate each other using explorer packets. The explorers provide the source computer with a RIF (Routing Information Field), recording the sequence of Token Rings and IBM bridges between source and destination. The source computer typically caches this RIF for use during its session.

In DLSw, the WAN peer routers run a TCP/IP application to pass data back and forth. TCP transport provides reliability and flow control. Running on top of IP allows for dynamic rerouting around outages, somewhat of a novelty in IBM networks. This makes your WAN more reliable, which is always a Good Thing!

The SRB RIF is locally terminated. So acknowledgements travel locally between the router and the local device, as opposed to across your WAN. This helps keep sessions from timing out due to WAN delays. In addition, RIF's are terminated, so they don't go across your WAN. That is, before putting a frame out on the WAN (or IP network), the sending router does a RIF-ectomy. The receiving router consults a cache and inserts the RIF needed for the frame to travel the rest of the way to its destination.

Sending RIF-less traffic across the WAN or TCP/IP network makes more efficient use of bandwidth. It also means that instead of the typical 7 hop limit in IBM SRB networks, you can now have 7 hops on each side of the WAN.

Caching RIF's also allows the participating routers to be smarter about not sending explorers (or the moral equivalent) across the WAN. That's exactly what's needed when scaling up such a network! And DLSw also caches NetBIOS names, which helps in larger NetBIOS environments.

Tech Tip: In RSRB and DLSw, the routers use a virtual ring number for the WAN or TCP/IP network, making it look like a Token Ring to the SRB network devices. Since DLSw removes the RIF, the two routers need not agree on the number for this virtual Token Ring -- but it's good style and less confusing to be consistent. In addition, the physical Token Ring numbers on each end are never transmitted to the other side, so they no longer have to be unique. However, it's good style to use different, unique, ring numbers, for all real (physical) Token Rings and for virtual rings as well. A couple of weeks ago I found one good reason for doing this: a site was using the same ring number on all remote Token Rings. Netsys therefore thought the rings were one and the same, and complained mightily about the differing ring speeds. Since network management software may use the ring number to understand the network layout, please don't confuse your network management software!

Configuring DLSw

Let's say we want to configure Router1 above to talk to c2500. Below are the minimal DLSw configurations to accomplish this. Often, routers are peered to addresses on loopback interfaces (which never go down), so we'll show that in the configurations.

Router1:

interface loopback 0
ip address 10.1.1.1 255.255.255.0
!
source-bridge ring-group 10
dlsw local-peer peer-id 10.1.1.1
dlsw remote-peer 0 tcp 10.5.5.5
!
interface tokenring 0
no ip address
ring-speed 16
source-bridge active 20 1 10

This configuration references the local and remote addresses of the peers. It sets up a virtual ring 10, the imaginary Token Ring around the WAN ("ring around the cloud"). And it specifies that the physical Token Ring out interface TokenRing 0 is ring number 20, connected via SRB bridge 1 to the virtual ring 10.

c2500:

interface loopback 0
ip address 10.5.5.5 255.255.255.0
!
source-bridge ring-group 10
dlsw local-peer peer-id 10.5.5.5
dlsw remote-peer 0 tcp 10.1.1.1
!
interface tokenring 0
no ip address
ring-speed 4
source-bridge active 30 1 10

This configuration is very similar to the above, but the physical Token Ring is now ring number 30.

Troubleshooting DLSw

One of my favorite commands for troubleshooting DLSw is "show dlsw reachability". If it doesn't show anything, there's a problem! It shows cached RIF's, whether they're local, and if not, what peer they're reached by. It also shows the NetBIOS name cache contents.

There's also "show dlsw peers". If you don't have peers in the CONNECT state, chances are that something's mis-configured.

Networking Microsoft: Links

I'll admit, I'm still learning about networking Microsoft. There's starting to be some good information out on the net on scaling issues, and on how to manage large numbers of networked Microsoft hosts. WINS and broadcast control are known issues with some solutions. TCP window size is a performance tuning issue. Policy and procedures and browser control are something people are still learning about, as is DHCP. I've run into domain controllers and Microsoft security as possible issues once or twice. Anyway, I'm collecting links that look useful (to me and others). See http://www.netcraftsmen.net/welcher/misc/windows.htm . And if you have some other handy URL's I can add to this page, please let me know!

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 .