Troubleshooting DLSw Configuration

Available Languages

Download Options

PDF (232.7 KB)
View with Adobe Reader on a variety of devices

Updated:July 6, 2007

Document ID:17563

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

Prerequisites

Requirements

Components Used

Conventions

Background Information

Network Topology

Loops

Related Information

Introduction

This document discusses how to troubleshoot a Data-link Switching (DLSw) configuration.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

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.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

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 Basic DLSw+ Configurations and Troubleshooting 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 DLSw+ Configuration Commands for more information.

Network Topology

This section addresses some common issues and provides tips on how you can troubleshoot.

Loops

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.

Network Topology

Here is an example topology that traces the creation of a loop.

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.

Loop Creation: Scenario 1

This is the route of an explorer:

The 3174 in ring 11 sends an explorer to reach the host.
Both San Francisco 1 (SF1) and the bridge copy the frame.
SF1 creates a CUR frame to Los Angeles 1 (LA1), which is the peer, that tells LA1 that the 3174 wants to reach the host.
San Francisco 2 (SF2) receives the packet and repeats the action.
LA1 and Los Angeles 2 (LA2) create the explorer and send it to the ring.
LA1 and LA2 each receive an explorer (the one that the other created).

Now a problem arises. Each side determines that the 3174 is locally attached, and each router views the 3174 both locally and remotely.
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 loop.

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 cloud:

Loop Creation: Scenario 2

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 LA2.
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 DLSw Ethernet Redundancy Configuration Example for more information.