Cisco Systems BC-281 User Manual
Configuring Data-Link Switching Plus
This chapter describes how to configure data-link switching plus (DLSw+), Cisco’s implementation of
the DLSw standard for Systems Network Architecture (SNA) and NetBIOS de vices. Refer to the DLSw+
Design and Implementation Guide for more complex configuration instructions. For a complete
description of the DLSw+ commands mentioned in this chapter, refer to the “DLSw+ Commands”
chapter of the Cisco IOS Bridging and IBM Networking Command Reference (Volume 1 of 2). To locate
documentation of other commands that appear in this chapter, use the command reference master index
or search online.
This chapter contains the following sections:
• Technology Overview, page 281
• DLSw+ Configuration Task List, page 288
• Verifying DLSw+, page 310
• Monitoring and Maintaining the DLSw+ Network, page 311
• DLSw+ Configuration Examples, page 312
To identify the hardware platform or software image information associated with a feature, use the
Feature Navigator on Cisco.com to search for information about the feature or refer to the software
release notes for a specific release. For more information, see the “Identifying Platform Support for
Cisco IOS Software Features” section on page lv in the “Using Cisco IOS Software” chapter.
Technology Overview
DLSw+ is a method of transporting SNA and Net BIOS. It complies with the DLSw standard documented
in RFC 1795 and the DLSw Version 2 standard. DLSw+ is an alternative to RSRB that addresses several
inherent problems that exist in RSRB, such as:
• SRB hop-count limits (SRB’s limit is seven)
• Broadcast traffic (including SRB explorer frames or NetBIOS name queries)
• Unnecessary traffic (acknowledgments and keepalives)
• Data-link control timeouts
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-281
Technology Overview
DLSw Standard
The DLSw standard, documented in RFC 1795, defines the switch-to-switch protocol between DLSw
routers. The standard also defines a mechanism to terminate data-link control connections locally and
multiplex the traffic from the data-link control connections to a TCP connection. The standard always
calls for the transport protocol to be TCP and always requires that data-link control connections be
locally terminated (the eq uivalent of Cisco’s local acknowledgment option). The standard also requires
that the SRB RIF be terminated at the DLSw router. The standard describes a means for prioritization
and flow control and defines error recovery procedures that ensure data-link control connections are
appropriately disabled if any part of their associated circuits breaks.
The DLSw standard does not specify when to establish TCP connections. The capabilities exchange
allows compliance to the standard, bu t at different levels of support. The standard does not specify how
to cache learned information about MAC addresses, RIFs, or NetBIOS names. It also does not describe
how to track either capable or preferred DLSw partners for either backup or load-balancing purposes.
The standard does not provide the specifics of media conversion, but leaves the details up to the
implementation. It does not define how to map switch congestion to the flow control for data-link
control. Finally, the MIB is documented under a separate RFC.
Configuring Data-Link Switching Plus
DLSw Version 2 Standard
In the Version 1 standard, a network design requires fully meshed connectivity so that all peers were
connect to every other peer. This design creates unnecessary broadcast traffic because an explorer
propagates to every peer for every broadcast.
The Version 2 standard is documented in RFC 2166. It includes RFC 1795 and adds the following
enhancements:
• IP Multicast, page 282
• UDP Unicast, page 283
• Enhanced Peer-on-Demand Routing Feature, page 283
• Expedited TCP Connection, page 283
Users implement DLSw Version 2 for scalability if they are using multivend or DLSw de vices with an IP
multicast network. DLSw Version 2 requires complex planning because it involves configuration
changes across an IP network.
IP Multicast
Multicast service avoids duplication and excessive bandwidth of broadcast traffic because it replicates
and propagates messages to its multicast members only as necessary. It re duces the amount of network
overhead in the following ways:
• A v oids the need to maintain TCP Switch-to-Switch Protocol (SSP) connections between two DLSw
peers when no circuits are available
• Ensures that each broadcast results in only a single explorer over every link
DLSw Version 2 is for customers who run a multicast IP network and do not need the advantages of
border peering.
BC-282
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
Configuring Data-Link Switching Plus
UDP Unicast
DLSw Version 2 uses UDP unicast in response to an IP multicast. When address resolution packets
(CANUREACH_EX, NETBIOS_NQ_ex, NETBIOS_ANQ, and DATAFRAME) are sent to multiple
destinations (IP multicast service), DLSw Version 2 sends the response frames (ICANREACH_ex and
NAME_RECOGNIZED_ex) via UDP unicast.
UDP unicast uses UDP source port 0. Howe ver , some fire wall products treat packets th at use UDP source
port 0 as security violations, discarding the pa ckets and preventing DLSw connections. To avoid this
situation, use one of the following procedures:
• Configure the firewall to allow UDP packets to use UDP source port 0.
• Use the dlsw udp-disable command to disable UDP unicast and send address resolution packets in
the existing TCP session.
Enhanced Peer-on-Demand Routing Feature
DLSw V ersion 2 establishes TCP connections only when necessary and the TCP connections are brought
down when there are no circuits to a DLSw peer for a specified amount of time. This method, known as
peer-on-demand routing, was recently introduced in DLSw Version 2, but has been implemented in Cisco
DLSw+ border peer technology since Cisco IOS Release 10.3.
Technology Overview
Expedited TCP Connection
DLSw Version 2 efficiently establishes TCP connections. Prev iously, DLSw created two unidirectional
TCP connections and then disconnected one after the capabilities exchange took place. With DLSw
Version 2, a single bidirectional TCP connection establishes if the peer is brought up as a result of an IP
multicast/UDP unicast information exchange.
DLSw+ Features
DLSw+ is Cisco’s version of DLSw and it supports several additional features and enhancements.
DLSw+ is a means of transporting SNA and NetBIOS traffic over a campus or WAN. The end systems
can attach to the network over T ok en Ring, Ethernet, Synchronous Data Link Control (SDLC) Protocol,
Qualified Logical Link Control (QLLC), or Fiber Distributed Data Interface (FDDI). See the DLSw+
Design and Implementation Guide Appendix B, “DLSw+ Support Matrix,” for details. DLSw+ switches
between diverse media and locally terminates the data links, keeping acknowl edgments, k eep ali v es, and
polling off the WAN. Local termination of data links also eliminates data-link control timeouts that can
occur during transient network congestion or when rerouting around failed links. Finally, DLSw+
provides a mechanism for dynamically searching a network for SNA or NetBIOS resources and includes
caching algorithms that minimize broadcast traffic.
DLSw+ is fully compatible with any vendor’ s RFC 1795 implementation and the following features are
available when both peers are using DLSw+:
• Peer groups and border peers
• Backup peers
78-11737-02
• Promiscuous and on-demand peers
• Explorer firewalls and location learning
• NetBIOS dial-on-demand routing feature support
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-283
Technology Overview
Configuring Data-Link Switching Plus
• UDP unicast support
• Load balancing
• Support for LLC1 circuits
• Support for multiple bridge groups
• Support for RIF Passthrough
• SNA type of service feature support
• Local acknowledgment for Ethernet-attached devices and media conversion for SNA PU 2.1 and
PU 2.0 devices
• Conversion between LLC2 to SDLC between PU 4 devices
• Local or remote media conversion between LANs and either SDLC Protocol or QLLC
• SNA View, Blue Maps, and Internetwork Status Monitor (ISM) support
MIB enhancements that allow DLSw+ features to be managed by the CiscoWorks Blue products, SNA
Maps, and SNA V ie w. Also, new traps alert network management stations of peer or circuit failures. For
more information, refer to the current Cisco IOS release note for the location of the Cisco MIB website.
Local Acknowledgment
When you have LANs separated by wide geographic distances, and you want to avoid sending data
multiple times, and the loss of user sessions that can occur with time delays, encapsulate the source-route
bridged traffic inside IP datagrams passed over a TCP connection between two routers with local
acknowledgment enabled.
Logical Link Control, type 2 (LLC2) is an ISO st andard dat a-link level protocol used in Token Ring
networks. LLC2 was designed to provide reliable sending of data across LAN media and to cause
minimal or at least predictable time delays. However, DLSw+ and WAN backbones created LANs that
are separated by wide, geographic distances-spanning countries and continents. As a result, LANs have
time delays that are longer than LLC2 allows for bidirectional communication between hosts. Local
acknowledgment addresses the problem of unpredictable time delays, multiple sendings, and lo ss of user
sessions.
In a typical LLC2 session, when one host sends a frame to another host, the sending host expects the
receiving host to respon d positi ve ly or ne gati v ely in a pred ef ined period of time commonly called th e T1
time. If the sending host does not receive an acknowledgment of the frame it sent within the T1 time, it
retries a few times (normally 8 to 10). If there is still no response, the sending host drops the session.
Figure 127 illustrates an LLC2 session in which a 37x5 on a LAN segment communicates with a 3x74
on a different LAN segment separated via a wide-area backbone network. Frames are transported
between Router A and Router B by means of DLSw+. However, the LLC2 session between the 37x5 and
the 3x74 is still end-to-end; that is, every frame generated by the 37 x5 traverses the backbone ne twork
to the 3x74, and the 3x74, on receipt of the frame, acknowledges it.
BC-284
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
Configuring Data-Link Switching Plus
SNA session
3
Figure 127 LLC2 Session without Local Acknowledgment
Technology Overview
Router B
Token
Ring
3x74
S1106a
37x5
Token
Ring
Router A
WAN
LLC2 session
SNA session
On backbone networks consisting of slow serial lin ks, the T1 timer on end hosts could e xpire before th e
frames reach the remote hosts, causing the end host to resend . Resending results in duplicate frames
reaching the remote host at the same time as the first frame reaches the remote host. Such frame
duplication breaks the LLC2 protocol, resulting in the loss of sessions between the two IBM machines.
One way to solve this time delay is to increase the timeout value on the end nodes to account for the
maximum transit time between the two end machines. However, in networks consisting of hundreds or
even thousands of nodes, every machine would need to be reconfigured with new values. With local
acknowledgment for LLC2 enabled, the LLC2 session between the two end nodes would not be not
end-to-end, but instead, would terminate at two local routers. Figure 128 shows the LLC2 session with
the 37x5 ending at Router A and the LLC2 session with the 3x7 4 ending at Router B. Bot h Router A and
Router B execute the full LLC2 protocol as part of local acknowledgment for LLC2.
Figure 128 LLC2 Session with Local Acknowledgment
TCP session
7x5
Token
Ring
Router A
LLC2 session LLC2 session
WAN
Router B
Token
Ring
3x74
S1107a
With local ackno wledgment for LLC2 enabled in both routers, Router A ackno wledges frames received
from the 37x5. The 37x5 still operates as if the acknowledgments it receives are from the 3x74. Router
A looks like the 3x74 to the 37x5. Similarly, Router B acknowledges frames received from the 3x74. The
3x74 operates as if the acknowledgments it receives are from the 37x5. Router B looks like the 3x74 to
37x5. Because the frames do not have to travel the WAN backbone networks to be acknowledged, but
are locally acknowledged by routers, the end machines do not time out, resulting in no loss of sessions.
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
BC-285
Technology Overview
Enabling local acknowledgment for LLC2 has the following advantages:
• Local acknowledgment for LLC2 solves the T1 timer problem without having to change any
configuration on the end nodes. The end nodes are unaware that the sessions are locally
acknowledged. In networks consisting of hun dreds or even thousands of machines, this is a definite
advantage. All the frames acknowledged by the Cisco IOS software appear to the end hosts to be
coming from the remote IBM machine. In fact, by looking at a trace from a protocol analyzer, one
cannot say whether a frame was acknowled ged by the l ocal router or by a remote IBM machin e. The
MAC addresses and the RIFs generated by the Cisco IOS software are identical to those generated
by the remote IBM machine. The only way to f ind out whet her a session is locally ack nowledged is
to use either a show local-ack command or a show sourc e-bridge command on the router.
• All the supervisory (RR, RNR, REJ) frames that are locally acknowledged go no farther than the
router. Without local acknowledgment for LLC2, every frame traverses the backbone.
With local acknowledgment, only data (I-frames) traverse the backbone, resulting in less traffic on
the backbone network. For installations in which customers pay for the amount of traffic passing
through the backbone, this could be a de finite cost-saving measure. A simple p rotocol exists
between the two peers to bring up or down a TCP session.
Notes on Using LLC2 Local Acknowledgment
Configuring Data-Link Switching Plus
LLC2 local acknowledgment is enabled with TCP and DLSw+ Lite remote peers.
If the LLC2 session between the loca l host and the router terminates in either router, the other will be
informed to terminate its connection to its local host.
If the TCP queue length of the connection between the two routers reaches the high-water mark, the
routers sends Receiver -Not- Ready (RNR) messages to the local hosts un ti l the queue limit is r educed to
below this limit. It is possible, ho we ver, to prevent the RNR messages from being sent by using the dlsw
llc2 nornr command.
The configuration of the LLC2 parameters for the local Token Ring interfaces can affect overall
performance. Refer to the chapter “Configuring LLC2 and SDLC Pa rameters” in this manual for more
details about fine-tuning your network through the LLC2 parameters.
The routers at each end of the LLC2 session execute the full LLC2 protocol, which could result in
significant router overhead. The decision to use local acknowledgment for LLC2 should be based on the
speed of the backbone network in relation to the Token Ring speed. For LAN segments separated by
slow-speed serial links (for example, 56 kbps), the T1 timer problem could occur more frequently. In
such cases, it might be wise to turn on local acknowledgment for LLC2. For LAN segments separated
by a T1, backbone delays will be minimal; in such cases, DLSw+, FST or direct encapsulation should
be considered in order to disable local acknowledgement. Speed mismatch between the LAN segments
and the backbone network is one criterion to help you decide to use local acknowledgment for LLC2.
There are some situations (such as the receiving host failing between the time the sending host sends
data and the time the receiving ho st recei ves it), i n which the sending host would determine, at the LLC2
layer, that data was recei ved when it actually was not. This error occurs because the router ackno wledges
that it received data from the sending host before it determines that the receiving host can actually
receive the data. But because both NetBIOS and SNA have error recovery in situations where an end
device goes down, these higher-level protocols will resend any missing or lost data. Because these
transaction request/confirmation prot ocols exist above LLC2, they are not affected by tight timers, as is
LLC2. They also are transparent to local acknowledgment.
BC-286
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
Configuring Data-Link Switching Plus
If you are using NetBIOS applications, note that there are two NetBIOS timers—one at the link level
and one at the next high er lev el. Local acknow ledgment for LLC2 is designed to solv e link timeouts only .
If you are experiencing NetBIOS session timeouts, you have two options:
• Experiment with increasing your NetBIOS timers and decreasing your maximum NetBIOS frame
size.
• Avoid using NetBIOS applications on slow serial lines.
Note By default, the Cisco IOS software translates Token Ring LLC2 to Ethernet 802.3 LLC2. To
configure the router to translat e Token Ring LLC2 frames into Ethernet 0x80d5 format frames, refer
to the section “Enable T ok en Ring LLC2-to-Ethernet Con v ersion” in the “Conf iguring Source-Ro ute
Bridging” chapter of the Cisco IOS Bridging and IBM Networking Command Reference (Volume 1
of 2).
DLSw+ Support for Other SNA Features
DLSw+ can be used as a transport for SNA features such as LNM, DSPU, SNA service point, and SNA
Switching Services (SNASw) through a Cisco IOS feature called virtual data-link control (VDLC).
LNM over DLSw+ allows DLSw+ to be used i n Token Ring networks that are managed by IBM’s LNM
software. Using this feature, LNM can be used to manage Token Ring LANs, control access units, and
Token Ring attached devices over a DLSw+ network. All management functions continue to operate as
they would in a source-route bridged network or an RSRB network.
DSPU over DLSw+ allows Cisco’s DSPU feature to operate in conjunction with DLSw+ in the same
router. DLSw+ can be used either upstream (toward the mainframe) or downstream (away from the
mainframe) of DSPU. DSPU concentration consolidates the appearance of multiple PUs into a single PU
appearance to VTAM , minimizing memory and cycles in central site resources (VTAM, NCP, and
routers) and speeding network startup.
Technology Overview
SNA service point over DLSw+ allo ws Cisco’s SNA service point feature to be used in conjunction with
DLSw+ in the same router. Using this feature, SNA service point can be configured in remote routers,
and DLSw+ can provide the path for the remote service point PU to communicate with NetView. This
allows full management visibility of resou rces from a NetView 390 console, while concurrently of fering
the value-added features of DLSw+ in an SNA network.
SNASw ov er DLSw+ allows Cisco’ s APPN Branch Extender functionality to be used in conjunction with
DLSw+ in the same router. With this feature, DLSw+ can be used to access SNASw in the data center.
DLSw+ can also be used as a transport for SNASw upstream connectivity, providing nondisruptive
recovery from failures.
Using DLSw+ as a transport for other Cisco IOS SNA features requires a feature called VDLC.
Cisco I OS data-link users (such as LNM, DSPU, SNA service point, and SNASw) write to a virtual
data-link control interface. DLSw+ then reads from this interface and sends out the traffic. Similarly,
DLSw+ can receive traffic destined for one of these data-link users and write it to the virtual data-link
control interface, from which the appropriate data-link user will read it.
In Figure 129, SNASw and DLSw+ use Token Ring and Ethernet, respectively, as “real” data-link
controls, and use virtual data-link control to communicate between themselves. When one of the
high-layer protocols passes data to the virtual data-link control, the virtual data-link control must pass
it to a higher-layer protocol; nothing leaves the virtual data-link control without going through a
data-link user.
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-287
DLSw+ Configuration Task List
5
ls
Figure 129 VDLC Interaction with Higher-Layer Protocols
Configuring Data-Link Switching Plus
DLSw+ Data-link users
Token
Ring
SNASw
VDLC
The higher-layer protocols make no distinction between the VDLC and any other data-link control, but
they do identify the VDLC as a destination. In the example shown in Figure 129, SNASw has two ports:
a physical port for Token Ring and a virtual port for the VDLC. When you define the SNASw VDLC
port, you can specify the MA C addr ess assigned to it. D ata transpor t from SNASw to DLSw+ by way of
the VDLC is directed to the VDLC MAC address. The type of higher-layer protocol you use determines
how the VDLC MAC address is assigned.
DLSw+ Configuration Task List
DLSw+ supports local or remote media conversion between LANs and SDLC or QLLC.
To configure DLSw+, complete the tasks in the following sections:
• Defining a DLSw+ Local Peer for the Router, page 288
• Defining a DLSw+ Remote Peer, page 289
Ethernet
CLSI
Data-link contro
1909
• Mapping DLSw+ to a Local Data-Link Control, page 292
• Configuring Advanced Features, page 295
• Configuring DLSw+ Timers, page 310
See the “DLSw+ Configuration Examples” section on page 312 for examples.
Defining a DLSw+ Local Peer for the Router
Defining a DLSw+ local peer for a router enables DLSw+. Specify all local DLSw+ parameters as part
of the local peer definition. To define a local peer, use the following command in global configuration
mode:
Command Purpose
Router(config)# dlsw local peer [peer-id
ip-address] [group group] [border] [cluster
cluster-id] [cost cost] [lf size] [keepalive
seconds] [passive] [promiscuous]
[init-pacing-window size] [max-pacing-window
size] [biu-segment]
The following is a sample dlsw local peer statement:
dlsw local peer peer-id 10.2.34.3
Defines the DLSw+ local peer.
BC-288
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
Configuring Data-Link Switching Plus
Defining a DLSw+ Remote Peer
Defining a remote peer in DLSw+ is opti onal, ho we ver , usually at least one side o f a peer connection has
a dlsw remote-peer statement. If you omit the dlsw remote-peer command from a DLSw+ peer
configuration, then you must configure the promiscuous keyword on the dlsw local-peer statement.
Promiscuous routers will accept any peer connection requests from other routers that are not
preconfigured. To define a remote peer, use the dlsw remote-peer command in global configuration
mode.
One of the options in the remote peer statement is to specify an encapsulation type. Configure one of the
following types of encapsulations with the dlsw remote-peer statement:
• TCP Encapsulation, page 289
• TCP/IP with RIF Passthrough Encapsulation, page 290
• FST Encapsulation, page 290
• Direct Encapsulation, page 291
• DLSw Lite Encapsulation, page 291
Which encapsulation type you choose depends on several factors, including whether you want to
terminate the LLC flows. TCP and DLSw+ Lite terminate the LLC, but the other encapsulation types do
not. For details on each encapsulation type, see the DLSw+ Design and Implementation Guide. See the
“Local Acknowledgement” section in the
acknowledgement.
DLSw+ Configuration Task List
overview chapter of this publication for a discussion on local
TCP Encapsulation
To configure TCP encapsulation on a remote peer, use the following command in global configuration
mode:
Command Purpose
Router(config)# dlsw remote-peer list-number tcp
ip-address [
[ip-address | frame-relay interface serial
number dlci-number | interface name]]
[bytes-netbios-out bytes-list-name]
[circuit-weight weight] [cluster cluster-id]
[cost cost] [dest-mac mac-address]
[dmac-output-list access-list-number]
[host-netbios-out host-list-name] [inactivity]
[dynamic] [keepalive seconds] [lf size] [linger
minutes] [lsap-output-list list] [no-llc
minutes] [passive] [priority] [rif-passthru
virtual-ring-number] [tcp-queue-max size]
[timeout seconds]
The following command specifies a dlsw remote peer with TCP encapsulation:
dlsw remote-peer 0 tcp 10.23.4.5
Defines a remote peer with TCP encapsulation.
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-289
DLSw+ Configuration Task List
TCP/IP with RIF Passthrough Encapsulation
To configure TCP/IP with RIF Passthrough encapsulation, use the following command in global
configuration mode:
Command Purpose
Router(config)# dlsw remote-peer list-number tcp
ip-address [backup-peer [ip-address |
frame-relay interface serial number dlci-number
|
interface name]] [bytes-netbios-out
bytes-list-name] [circuit-weight weight] [cost
cost] [dest-mac mac-address] [dmac-output-list
access-list-number] [host-netbios-out
host-list-name] [inactivity] [dynamic]
[keepalive seconds] [lf size] [linger minutes]
[lsap-output-list list] [no-llc minutes]
[passive] [priority] [rif-passthru
virtual-ring-number] [tcp-queue-max size]
[timeout seconds]
The following command specifies a remote peer with TCP/IP with RIF Passthrough encapsulation:
dlsw remote-peer 0 tcp 10.2.23.5 rif-passthru 100
Defines a remote peer with TCP/IP with RIF Passthrough
encapsulation.
Configuring Data-Link Switching Plus
FST Encapsulation
To configure FST encapsulation on a remote peer, use the following command in global configuration
mode:
Command Purpose
Router(config)# dlsw remote-peer list-number fst
ip-address [backup-peer [ip-address |
frame-relay interface serial number dlci-number
| interface name]]
[bytes-netbios-out bytes-list-name]
[circuit-weight weight] [cost cost] [dest-mac
mac-address] [dmac-output-list
access-list-number] [host-netbios-out
host-list-name] [keepalive seconds] [lf size]
[linger minutes] [lsap-output-list list]
The following command specifies a DLSw remote peer with FST encapsulation:
dlsw remote-peer 0 fst 10.2.23.5
Defines a remote peer with FST encapsulation.
BC-290
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
Configuring Data-Link Switching Plus
Direct Encapsulation
To configure direct encapsulation, use the following command in global configuration mode:
Command Purpose
Router(config)# dlsw remote-peer list-number
frame-relay interface serial number dlci-number
[backup-peer [ip-address | frame-relay interface
serial number dlci-number | interface name]]
[bytes-netbios-out bytes-list-name]
[circuit-weight weight] [cost cost] [dest-mac
mac-address] [dmac-output-list
access-list-number] [host-netbios-out
host-list-name] [keepalive seconds] [lf size]
[linger minutes] [lsap-output-list list]
pass-thru
Direct encapsulation is supported over High-Level Data Link Control (HDLC) and Frame Relay.
The following command specifies a DLSw remote peer with direct encapsulation over HDLC:
dlsw remote-peer 0 interface serial 01
Defines a remote peer with direct encapsulation.
DLSw+ Configuration Task List
Direct encapsulation over Frame Relay comes in two forms: DLSw Li te (LLC2 encap sulatio n) and
Passthrough. Specifying the pass-thru option con figures the router so that the traffic will not be locally
acknowledged. (DLSw+ normally locally acknowledges traffic to keep traffic on the WAN to a
minimum.)
The following command specifies a DLSw remote peer with Direct encapsulation with pass-thru over
Frame Relay:
dlsw remote-peer 0 frame-relay interface serial 01 pass-thru
DLSw+ Lite is described in the “DLSw Lite Encapsulation” section on page 291.
DLSw Lite Encapsulation
To configure DLSw Lite encapsulation, use the following command in global configuration mode:
Command Purpose
Router(config)# dlsw remote-peer list-number
frame-relay interface serial number dlci-number
[backup-peer [ip-address | frame-relay interface
serial number dlci-number | interface name]]
[bytes-netbios-out bytes-list-name]
[circuit-weight weight] [cost cost] [dest-mac
mac-address] [dmac-output-list
access-list-number] [host-netbios-out
host-list-name] [keepalive seconds] [lf size]
[linger minutes] [lsap-output-list list]
pass-thru
Defines a remote peer with DLSw Lite encapsula tion.
78-11737-02
The following command specifies a DLSw remote peer with DLSw Lite encapsulation over Frame
Relay:
dlsw remote-peer 0 frame-relay interface serial 01
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-291
DLSw+ Configuration Task List
Mapping DLSw+ to a Local Data-Link Control
In addition to configuring local and remote peers, you must map one of the following local data-link
controls to DLSw+:
• Token Ring, page 292
• Ethernet, page 293
• SDLC, page 293
• QLLC, page 294
• FDDI, page 295
Token Ring
Traffic that originates from Token Ring is source-route bridged from the local ring onto a source-bridge
ring group and then picked up b y DLSw+. You must include a sour ce-bridge ring-gr oup command that
specifies a virtual ring number when configuring Token Ring with DLSw+. In addition, you must
configure the source-bridge command that tells the DLSw+ router to bridge from the physical Token
Ring to the virtual ring.
Configuring Data-Link Switching Plus
To specify a virtual ring number, use the following command in global configuration mode:
Command Purpose
Router(config)# source-bridge ring-group
ring-group [virtual-mac-address]
Defines a virtual ring.
To enable DLSw+ to bridge from the physical Token Ring ring to the virtual ring, use the following
command in interface mode:
Command Purpose
Router(config-if)# source-bridge
source-ring-number bridge-number
target-ring-number
Defines SRB on interface.
To enable single-route explorers, use the following command in interface mode:
Command Purpose
Router(config-if)# source-bridge spanning
Enables single-route explorers.
Configuring the source-bridge spanning command is required because DLSw+ uses single-route
explorers by default.
BC-292
The following command configures a source-bridge ring-group and a virtual ring with a value of
100toDLSw+:
source-bridge ring-group 100
int T0
source-bridge 1 1 100
source-bridge spanning
The ring-group number specified in the source-bridge command must be the number of a defined
source-bridge ring-group or DLSw+ will not see this interface.
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
Configuring Data-Link Switching Plus
Ethernet
Traffic that originates from Ethernet is picked up from the local Ethernet interface bridge group and
transported across the DLSw+ network. Therefore, you must map a specific Ethernet bridge group to
DLSw+.
To map an Ethernet bridge group to DLSw+, use the following command in global configuration mode:
Command Purpose
Router(config)# dlsw bridge-group group-number
[llc2 [N2 number] [ack-delay-time milliseconds]
[ack-max number] [idle-time milliseconds]
[local-window number] [t1-time milliseconds]
[tbusy-time milliseconds] [tpf-time
milliseconds] [trej-time milliseconds]
[txq-max number] [xid-neg-val-time milliseconds]
[xid-retry-time milliseconds]] [locaddr-priority
lu address priority list number] [sap-priority
priority list number]
T o assign the Ethernet interface to a bridg e group, use the follo wing command in i nterface conf iguration
mode:
Links DLSw+ to the bridge group of the Ethernet LAN.
DLSw+ Configuration Task List
Command Purpose
Router(config-if)# bridge-group bridge-group
Assigns the Ethernet interface to a bridge group.
The following command maps bridge-group 1 to DLSw+:
dlsw bridge-group 1
int E1
bridge-group 1
bridge 1 protocol ieee
SDLC
Configuring SDLC devices is more complicated than configuring Ethernet and Token Ring. There are
several considerations that affect which interface commands are configured. See the DLSw+ Design and
Implementation Guide for more details.
To establish devices as SDLC stations, use the following commands in interface configuration mode:
Command Purpose
Step 1
Step 2
Step 3
Step 4
Step 5
Router(config-if)# encapsulation
sdlc
Router(config-if)# sdlc role {none |
primary | secondary | prim-xid-poll}
Router(config-if)# sdlc vmac
mac-address
Router(config-if)# sdlc address
hexbyte [echo]
Router(config-if)# sdlc partner
mac-address sdlc-address {inbound |
outbound}
1
Sets the encapsulation type of the serial interface to SDLC.
Establishes the role of the in terface.
Configures a MAC address for the serial interface.
Assigns a set of secondary stations attached to the serial link.
Specifies the destination address with which an LLC session is
established for the SDLC station .
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-293
DLSw+ Configuration Task List
Command Purpose
Step 6
Step 7
Router(config-if)# sdlc xid
Router(config-if)# sdlc dlsw
{sdlc-address | default | partner
mac-address [inbound | outbound]}
1. The last byte of the MAC address must be 00.
Configuring Data-Link Switching Plus
Specifies an XID value appropriate for the designated SDLC station
associated with this serial interface.
Enables DLSw+ on an SDLC interface.
Use the default option if you have more than 10 SDLC devices to attach to the DLSw+ network. To
configure an SDLC multidrop line downstream, you configure the SDLC role as either primary or
prim-xid-poll. SDLC role primary specifies that any PU without the xid-poll parameter in the
sdlc address command is a PU 2.0 device. SDLC role prim-xid-poll specifies that e very PU is ty pe 2.1.
We recommend that you specify sdlc role primary if all SDLC devices are type PU 2.0 or a mix of
PU 2.0 and PU 2.1. Specify sdlc role prim-xid-poll if all devices are type PU 2.1.
To configure DLSw+ to support LLC2-to-SDLC conversion for PU 4 or PU 5 devices, specify the echo
option in the sdlc address command. A PU 4-to-PU 4 configuration requires that none be specified in
the sdlc role command.
Refer to the “DLSw+ with SDLC Multidrop Support Configuration Examples” section on page 318 and
the “DLSw+ with LLC2-to-SDLC Conversion Between PU 4-to-PU 4 Communication Example” section
on page 319 for sample configurations.
The following configuration shows a DLSw+ router configured for SDLC:
dlsw local-peer peer-id 10.2.2.2
dlsw remote-peer 0 tcp 10.1.1.1
interface Serial1
mtu 6000
no ip address
encapsulation sdlc
no keepalive
nrzi-encoding
clockrate 9600
sdlc vmac 4000.3745.0000
sdlc N1 48016
sdlc address 04 echo
sdlc partner 4000.1111.0020 04
sdlc dlsw 4
QLLC
BC-294
SNA devices use QLLC when connecting to X.25 networks. QLLC essentially emulates SDLC over
x.25. Therefore, configuring QLLC devices is also complicated. There are several considerations that
affect which interface commands are configured. See the DLSw+ Design and Implementation Guide for
details.
You can configure DLSw+ for QLLC connectivity, which enables both of the following scenarios:
• Remote LAN-attached devices (physical units) or SDLC-attached devices can access an FEP or an
AS/400 over an X.25 network.
Our QLLC support allows remote X.25-attached SNA devices to access an FEP with out requiring
X.25 NCP Packet Switching Interface (NPSI) in the FEP. This may eliminate the requirement for
NPSI (if GATE and DATE are not required), thereby eliminating the recurring license cost. In
addition, because the QLLC attached devices appear to be Token Ring-attached to the Network
Control Program (NCP), they require no preconf iguration in the FEP. Remote X.25-attached SNA
devices can also connect to an AS/400 over Token Ring using this suppo rt.
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
Configuring Data-Link Switching Plus
• Remote X.25-attached SNA devices can access an FEP or an AS/400 over a Token Ring or over
T o enable QLLC connectivity for DLSw+, use the follo wing commands in interf ace conf iguration mo de:
Command Purpose
Step 1
Step 2
Step 3
Step 4
Router(config-if)# encapsulation x
25
Router(config-if)# x25 address
subaddress
Router(config-if)# x25 map qllc
virtual-mac-addr x121-addr
[cud cud-value] [x25-map-options]
Router(config-if)# qllc dlsw
{subaddress subaddress | pvc pvc-low
[pvc-high]} [vmac vmacaddr
[poolsize]] [partner
partner-macaddr] [sap ssap dsap]
[xid xidstring] [npsi-poll]
DLSw+ Configuration Task List
SDLC.
For environments just beginning to migrate to LANs, our QLLC support allows deployment of
LANs in remote sites while maintaining access to the FEP over existing NPSI links. Remote
LAN-attached devices (physical units) or SDLC-attached devices can access a FEP over an X.25
network without requiring X.25 hardware or software in the LAN-attached devices. The Cisco IOS
software supports direct attachment to the FEP over X.25 without the need for routers at the data
center for SNA traffic.
Specifies an interface as an X.25 device.
Activates X.25 subaddresses.
Associates a virtual MAC address with the X.121 address of the remot e
X.25 device.
Enables DLSw+ over QLLC.
The following configuration enables QLLC connectivity for DLSw+:
dlsw local-peer peer-id 10.3.12.7
dlsw remote-peer 0 tcp 10.3.1.4
interface S0
encapsulation x25
x25 address 3110212011
x25 map qllc 1000.0000.0001 3 1104150101
qllc dlsw partner 4000.1151.1234
FDDI
Configure an FDDI interface the same as a Token Ring or Ethernet interface, depending on whether you
are configuring SRB or Transparent Bridging. If you are configuring the router for SRB, configure the
FDDI interface for T ok en Ring. If you are conf iguring the router for T ransparent Br idging, configur e the
FDDI interface for Ethernet.
Configuring Advanced Features
DLSw+ goes beyond the standard to include additional functionality in the following areas:
• Scalability , page 296⎯Constructs IBM internetworks in a way that reduces the amount of broadcast
traffic, which enhances their scalability.
• Availability, page 303⎯Dynamically finds alternate paths and, optionally, load-balances across
multiple active peers, ports, and channel gateways.
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-295
DLSw+ Configuration Task List
Scalability
Configuring Data-Link Switching Plus
• Modes of Operation, page 306⎯Dynamically detects the capabilities of the peer router and operates
according to those capabilities.
• Network Management, page 307—Works with enhanced network management tools such as
CiscoW orks Blue Maps, CiscoWorks SNA V iew, and CiscoWorks Blue Internetw ork Status Monitor
(ISM).
• Traffic Bandwidth and Queueing Management, page 307—Offers several bandwidth management
and queueing features to enhance the overall performance of your DLSw+ network. Controls
different types of explorer traffic using multiple queues, each with a wide range of depth settings.
• Access Control, page 307—Provides access control to various resources throughout a network.
One significant factor that limits the size of Token Ring internet works is the amount of explorer traffic
that traverses the WAN. DLSw+ includes the following features to reduce the number of explorers:
• Peer Groups and Border Peers, page 296
• Explorer Firewalls, page 300
• NetBIOS Dial-on-Demand Routing, page 300
• SNA Dial-on-Demand Routing, page 301
• UDP Unicast Feature, page 301
• LLC1 Circuits, page 302
• Dynamic Peers, page 302
• Promiscuous Peer Defaults, page 302
Peer Groups and Border Peers
Perhaps the most significant optimization in DLSw+ is a feature kn own as peer groups. Peer groups are
designed to address the broadcast replication that occurs in a fully meshed network. When any-to-any
communication is required (for example, for NetBIOS or Advanced Peer-to-Peer Networking [APPN]
environments), RSRB or standard DLSw implementations require peer connections between every pair
of routers. This setup is not only difficult to configure, but it results in branch access routers having to
replicate search requests for each peer connection. This setup wastes bandwidth and router cycles. A
better concept is to group routers into cl usters and designate a focal router t o be responsible for broadcast
replication. This capability is included in DLSw+.
With DLSw+, a cluster of routers in a region or a division of a company can be combined into a peer
group. Within a peer group, one or more of the ro uters is d esignated to be th e border peer. Inst ea d of all
routers peering to one another, each router within a group peers to the border peer; and border peers
establish peer connections with each other. When a DLSw+ router receives a TEST frame or NetBIOS
NAME-QUERY, it sends a single explorer frame to its border peer. The DLSw+ border peer router
checks its local, remote and group cache for any reachability information before forwarding the explorer .
If no match is found, the border peer forwards the explorer on behalf of the peer group member. If a
match is found, the border peer sends the explorer to the appropriate peer or border peer. This setup
eliminates duplicate explorers on the access links and minimizes the processing required in access
routers.
You can further segment DLSw+ routers within the same border peer group that are serving the same
LANs into a peer cluster. This segmentation reduces explorers because the border peer recognizes that
it only has to forward an explorer to one member within a peer cluster. Only TCP encapsulation can be
used with the DLSw+ Peer Clusters feature.
BC-296
Cisco IOS Bridging and IBM Networking Configuration Guide
78-11737-02
Configuring Data-Link Switching Plus
The DLSw+ Peer Clusters feature is configured locally on the member peer or on a border peer . Although
both options can be configured, we recommend that the cluster-id of a particular peer is defined in either
the border peer or on the member peer, but not both because of potential configuration confusion.
DLSw+ Configuration Task List
78-11737-02
Cisco IOS Bridging and IBM Networking Configuration Guide
BC-297
Loading...