This document discusses how to troubleshoot a Data-link Switching
There are no specific requirements for this document.
This document is not restricted to specific software and hardware
The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.
Technical Tips Conventions for more information on document
If the peers do not connect, verify whether IP connectivity exists
between the two routers. If so, verify whether you have the appropriate DLSw
peer statements in place on both the local and remote routers. Refer to
DLSw+ Configurations and
DLSw IP Connectivity Issues for more information. If no remote
statements exist, use the keyword promiscuous on the local
peer statement on one end. Refer to
Configuration Commands for more information.
This section addresses some common issues and provides tips on how you
Remember that the Routing Information Field (RIF) termination is an
important aspect of DLSw. RIF causes major issues through the easy creation of
loops in the network.
Here is an example topology that traces the creation of a
DLSw terminates the RIF, and the packet goes around endlessly. Every
time that a CANUREACH (CUR) frame is sent from peer to peer, the recipient peer
creates a new explorer (NO RIF) and sends it.
This is the route of an explorer:
The 3174 in ring 11 sends an explorer to reach the
Both San Francisco 1 (SF1) and the bridge copy the
SF1 creates a CUR frame to Los Angeles 1 (LA1), which is the peer,
that tells LA1 that the 3174 wants to reach the
San Francisco 2 (SF2) receives the packet and repeats the
LA1 and Los Angeles 2 (LA2) create the explorer and send it to the
LA1 and LA2 each receive an explorer (the one that the other
Now a problem arises. Each side determines that the 3174 is locally
attached, and each router views the 3174 both locally and
Each side sends a CUR frame to SF1 and SF2, and create an explorer
for the host from the 3174.
Both routers (SF1 and SF2) copy the frame again, and see that the
host is both local and remote. DLSw now breaks and goes into a
The best thing you can do in this situation is to make sure that the
virtual rings for the routers are exactly the same on each side of the
The routers on each side of the cloud are configured with the same
virtual ring number. This configuration ensures that a router that sends an
explorer has already passed through the ring and, therefore, the router drops
the explorer. When LA1 generates an explorer for a CUR frame that SF1 receives,
LA2 drops the explorer, because the explorer already passed through ring 1. The
routers must have different bridge numbers configured, if they are headed for
the same ring. This is the case on the LA side of this network. With Ethernet,
you must disable a peer:
A packet on the Ethernet does not have a RIF in itself. Therefore, when
the other router on the LAN creates a broadcast, the router cannot determine if
the broadcast is from the other router or from an originating station. In the
case of Systems Network Architecture (SNA), the router cannot determine whether
the packet originates locally or remotely. Explorers from the Token Ring have
both source and destination MAC addresses. Therefore, such explorers are not
really a broadcast on the Ethernet. Rather, they are sent as a directed frame
from one station to another.
Consider this sequence:
The 3174 sends an explorer to the host.
Both SF1 and SF2 accept the explorer.
SF1 and SF2 each generate a CUR to the other side, LA1 and
These CURs both generate an explorer to which the host responds. As
this is a single route explorer, an all routes explorer responds.
Both LA1 and LA2 create a CUR frame to SF1 and SF2, which creates
this packet for the 3174.
The problem is that SF1 hears the MAC address of the host from the
Ethernet and determines that the host resides on its own local LAN. But, in the
SF1 cache, the host appears to respond from a remote peer. Thus, the router has
the host defined as both local and remote.
DLSw now breaks and goes into a loop.
In order to fix DLSw, you must disable one peer or use the Ethernet
Redundancy feature. Refer to
Ethernet Redundancy Configuration Example for more information.