CNC Logo

Diving Deeper Into DLSw

Peter J. Welcher

Last month, we looked at basic DLSw. This month, let's look into some of the other tricks DLSw can do.

Review: 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 normally 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. Normally, DLSw provides local termination, where the Source Route Bridging (SRB) Routing Information Fields (RIF's) are added or removed by the DLSw routers.

Alternative Transports

There are other choices for DLSw transport than TCP/IP, the standard choice. They are: The direct transports just use data layer headers to carry traffic across the Frame Relay cloud or serial link. Data layer traffic is not routable; you must have a direct connection to the peer router. The advantage is, direct transport has lower overhead associated with it.

FST uses IP with sequence numbers added to the IP headers. It is routable but not reliable. It is suggested for use across backbones, e.g. to carry LLC2 Token Ring traffic across a FDDI or ATM backbone (without using the newer code to do SRB onto FDDI, for which there is no standard). The other choice is to use 11.2 code and do DLSw right onto FDDI (same source-bridge statement as for Token Ring).

TCP/IP or Frame Relay direct transport is required if you want local acknowledgement. In the other cases, the acknowledgements are carried end-to-end.

To configure Frame Relay with no local acknowledgements, set up the Frame Relay serial port with commands such as the following:

interface serial 0
encapsulation frame-relay
frame-relay map dlsw 123
To instead configure to allow local acknowledgements over Frame Relay, change that last line to:
frame-relay map llc2 123
Of course, in both cases you'll also have a line somewhere that references the remote peer by DLCI (123 in this example):
dlsw remote-peer 0 frame-relay interface serial 0 123
Warning: Direct and FST transports are Cisco-only, proprietary mechanisms.

DLSw and Redundancy

The backup-peer option on the dlsw remote-peer statement allows an alternative peer router to be specified. It is used only if the primary router is unreachable. Note that session loss will take place if the primary router becomes unreachable.

DLSw can load balance if there are multiple paths to a destination MAC address or NetBIOS name. The default is to just use the first path chosen, or lowest configured cost (another option on the remote-peer statement). This is referred to as fault tolerance mode. But if you configure 

dlsw duplicate-path-bias load-balance
then DLSw will load balance sessions across the duplicate paths instead.

DLSw and Ethernet

DLSw can translationally bridge onto Ethernet segments. After all, part of its normal operation is doing RIF insertion and removal.

All that's required to configure this is to set up transparent bridging on one or more Ethernet segments. Say you've set up transparent bridging using bridge-group 1. Then add the following to your DLSw configuration: 

dlsw bridge-group 1
If you contrast the syntax for the "dreaded" source-bridge transparent command you'll see just how much easier this is!

Dynamic Peers

If you're using TCP encapsulation, you can configure the router to use dynamic peers, which scales better. Dynamic peers activate only when there's traffic requiring a connection. The peer connection is de-activated when the last LLC2 session terminates and an idle period expires. An option allows teardown of the connection when there is no traffic for a specified period of time -- but be aware that this can disrupt idle sessions (which might be something you don't mind doing).

Oh, and if you hadn't noticed, this sort of behavior is the sort of thing you'd like for Dial-On-Demand SNA!

The configuration options go on the tcp remote-peer statement. They are:

Here's a sample of how these options might be used:
dlsw remote-peer 0 tcp 10.5.5.5 dynamic no-llc 10 inactivity 20
Warning: dynamic peers are a Cisco-only DLSw feature.

Dial-On-Demand SNA

To turn the above into DDR SNA, you'll want to configure some of the dynamic options mentioned above. You may also want to control irrelevant explorers with the dest-mac and dmac-output-list options on the remote peer statement.

The other thing needed is to use the keepalive and timeout options, so that the dial-up line can be de-activated when not needed. Set keepalive to 0 so the TCP connection stays alive even when the line is down, and so that TCP keepalives don't keep bringing the dial-up line back up. Optionally set timeout (the TCP retransmit limit) to something lower than its default 90 seconds, since you're probably dealing with a link with lowered reliability.

All this ends up looking like the following configuration command:

dlsw remote-peer 0 tcp 10.5.5.5 dynamic no-llc 10 inactivity 20 keepalive 0 timeout 5
That's just a remote-peer statement with a lot of options at the end of the line.

Another option that fits right in with this is promiscuous . This goes on the local-peer statement, and tells the router to accept DLSw connections from non-configured peers.

dlsw local-peer peer-id 10.1.1.1 promiscuous
Promiscuous peering can make large-scale DLSw easier to configure (and perhaps less secure?). It might be handy in DLSw Frame Relay networks, configured on the hub router in a star topology.

By the way, configuring all these options for many remote peers might get tedious. That's why Cisco added the dlsw peer-on-demand-defaults tcp (or fst ) commands. Sample use:

dlsw peer-on-demand-defaults tcp inactivity 20 keepalive 0 local-ack
The dynamic and no-llc options do not apply to this command.

DLSw Options

DLSw and SDLC

SDLC traffic can interoperate with DLSw, translating SDLC to Token Ring. To configure this, you need the sdlc dlsw interface command. You also need to configure SDLC polling role and other SDLC parameters that are beyond the scope of this article. See the Cisco Configuration Guide example.

DLSw and QLLC

QLLC is IBM's SDLC-like X.25 protocol. Cisco DLSw can eliminate the need for an expensive NPSI (X.25) interface in the front-end processor (FEP). It can also connect remote LAN-attached devices over an existing X.25 network directly to the FEP, without NPSI at the FEP and without X.25 interfaces in the LAN devices. Sounds like a way to migrate away from NPSI and X.25 to me!

DLSw Ring and Port Lists

A DLSw ring list is a list of Token Ring interfaces. The ring list can be specified in the DLSw remote peer statement, and traffic from that remote peer will only be forwarded to the specified Token Rings (and vice versa). The use of this mechanism is optional. To not use it, specify 0 in the remote-peer command (as we have done in all examples up to this point).

A DLSw port list is a list of Token Ring, Ethernet, or Serial interfaces. It is more complex than a ring list but behaves similarly.

Corrected 1/15/01: port lists cannot include Ethernet interfaces. Ring lists can include the virtual ring number for the Ethernet bridge group. However, in DLSw you don't explicitly assign Ethernet a virtual ring number, so using a dlsw bridge group is the way to go to control Ethernet ports.

Example of a ring-list:

dlsw ring-list 50 rings 1024 1025 1026
dlsw remote-peer 50 tcp 10.5.5.5
or a port-list:
dlsw port-list 50 serial 0
dlsw port-list 50 token 0
dlsw port-list 50 ethernet 2
dlsw remote-peer 50 tcp 10.5.5.5

DLSw Bridge Group Lists

This is a similar mechanism for just Ethernet interfaces. You can specify connectivity for traffic from a bridge-group to a remote peer (and vice versa).
dlsw bgroup-list 50 bgroups 1 3 5
dlsw remote-peer 50 tcp 10.5.5.5

Summary

Cisco DLSw has some nifty features that may be helpful. If you're transporting SNA traffic, it's well worth some time looking into using DLSw.

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 . 


10/97
Copyright 1997, Peter J. Welcher