Troubleshooting DLSw Reachability

Introduction

This document explains how the reachability cache works for data-link switching (DLSw) and provides information to troubleshoot DLSw circuits.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software or 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

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Reachability

Use the flowchart below to navigate through the Data-Link Switching (DLSw) reachability cache entries.

DLSw reachability cache entries are controlled by these two timers:

• VERIFY timer

• reachability (DELETE) timer

The remainder of this section explains the default method of operation.

When a CANUREACH (CUR) arrives from the WAN for an address that is not in the cache, a test frame is sent to all local Data Link Controls (DLCs) as a single route explorer (SRE), by default, on the Token Ring network. The MAC address or Network Basic Input/Output System (NetBIOS) name is entered into the cache with the status SEARCHING. At the first response to this, the information is added to the cache, the status of that address or name is changed to FOUND, and both the VERIFY and DELETE timers are started. If additional responses come in, they are added to the cache (up to four). Otherwise, the state remains FOUND, and the timers are not reset.

Nothing is done when the VERIFY timer expires (4 minutes by default). The show dlsw reachability command still sees that entry as FOUND, even after more than 4 minutes, as long as another CUR is not received for that resource. However, the first CUR for that resource causes a VERIFY state, as it becomes evident that the VERIFY timer has expired.

At this point, tests are forwarded only to that interface (or set of interfaces) where the resource had been learned about previously. All reachability information is then deleted. When the first response comes back, the state is changed back to FOUND, the port information is added back into the cache, and the VERIFY timer is reset. The DELETE timer is not touched. If there are additional responses after the first, the port information is added back into the cache (alternate paths). However, the state remains FOUND and neither timer is affected.

If there is no response to the test(s) that are sent out as part of the verify operation within the explorer time-out timer, then the cache entry is deleted. This is the first point at which an entry may be deleted automatically: the time at which reachability was first learned + the VERIFY timer + x + the explorer time-out (where x is the interval between when the VERIFY timer expired and when the next CUR for the resource was received).

If a device has been learned and has passed all verify operations while its DELETE timer (16 minute default) is running, then it is automatically deleted at the expiration of the DELETE timer (unlike the VERIFY timer, which waits for the next test to delete). This is to ensure that a new path to an existing resource is learned within a reasonable amount of time; if the verify only occurred, a new alternate path would not be learned, if there was at least one valid path in the cache.

Once a circuit is set up, it has all the reachability information that it needs. As such, other reachability entries that come and go have absolutely no effect on existing circuits, only on new ones. It is very possible to have an active circuit (and a session connection) between two resources for which you no longer have any reachability information. This is fine, and it is likely the norm rather than the exception, in traditional Systems Network Architecture (SNA) environments where devices make connections and do not send any further test frames.

show dlsw reach

When you are troubleshooting DLSw reachability problems, use the show dlsw reachability privileged EXEC command.

show dlsw reachability [[group [value] | local | remote] |
                        [mac-address [address] |
                        [netbios-names [name]]

• group???(Optional) Displays the contents of the group reachability cache only.

• value ???(Optional) Specifies the group number for the reachability check. Only displays group cache entries for the specified group. The valid range is 1 to 255.

• local???(Optional) Displays contents of the local reachability cache only.

• remote???(Optional) Displays contents of the remote reachability cache only.

• mac-address???(Optional) Displays DLSw reachability for MAC addresses only.

• address ???(Optional) Specifies the MAC address for which to search in the reachability cache.

• netbios-names???(Optional) Displays DLSw reachability for NetBIOS names only.

• name ???(Optional) Specifies the NetBIOS name for which to search in the reachability cache.

Refer to DLSw+ Configuration Commands, in addition to the next sample output, to understand the output from this command.

Router# show dlsw reachability

DLSw MAC address reachability cache list
MAC AddrstatusLoc.peer/portrif
0000.f641.91e8SEARCHINGLOCAL

!--- CUR is received from the WAN for an address that is not in the cache. !--- TEST frames are sent to all local DLCs (SRE by default, on Token Ring). !--- The MAC address or NETBIOS name is entered into the cache, with the !--- status SEARCHING.

0000.f641.91e8VERIFYLOCAL

!--- The first CUR that is received after the VERIFY timer expires (default 4 !--- minutes) causes the cache entry to change to the VERIFY state. A directed !--- test poll is sent to only that interface or group of interfaces from which !--- the cache entry was previously learned. All reachability information is !--- deleted. !--- The first response back causes the cache entry to be reinstated in the !--- FOUND state. The VERIFY timer is restarted, but the DELETE timer is !--- unchanged. Additional responses to CUR are cached (as alternative paths), !--- but the cache entry state remains FOUND, and the timers are unaffected.

0006.7c9a.7a48FOUNDLOCAL Tokenring0/00CB0.0011.3E71.A041.0DE5.0640

!--- Each entry includes either the port???if FOUNDLOCAL???or the DLSw peer IP !--- address???if FOUNDREMOTE. !--- The first response to the TEST frame that is received is entered into the !--- cache, and the status of the address or of the name found is changed to !--- FOUND. The VERIFY and DELETE timers are started. !--- Additional responses to TEST frames are cached (up to four) and do not !--- affect FOUND status or timers.

0800.5a4b.1cbcSEARCHINGREMOTE

!--- The TEST frame is received on the local interface. CUR sent to the WAN. !--- The MAC address or NetBIOS name is entered into the cache, with a status !--- of searching.

0800.5a8f.9c3fFOUNDREMOTE10.1.1.5/008B0.A041.0DE5.0640

!--- Each entry includes either the post???if FOUNDLOCAL???or the DLSw peer IP !--- address???if FOUNDREMOTE. !--- Omit the first four digits and then use the 3-digit (ring) and 1-digit !--- (bridge) numbers to trace the source of the MAC address. !--- In this example, the MAC address has come from these values: !--- ring = A04, bridge = 1 !--- ring = 0DE, bridge = 5 !--- ring = 064, bridge = 0

Other states include:

• UNCONFIRMED???Station is configured, but DLSw has not verified it. The dlsw icanreach command adds entries of this status in the remote reachability cache.

• NOT_FOUND???Negative caching is on, and the station has not responded to queries.

Note: Load balancing is simple round-robin on FOUND cache entries. If end stations connect after 16 minutes (the sna-cache-timeout), then they will not necessarily load balance. Round-robin is restarted every time that the cache entry is refreshed. Increase the sna-cache-timeout, to help improve load balancing.

If there is no response to directed test polls within the explorer-timeout timer, then the cache entry is deleted. This is the first point at which an entry might be deleted automatically: time at which reachability was first learned + VERIFY timer + x + explorer-timeout (where x is the interval between when the VERIFY timer and when the next CUR for the resource was received). These are the timers for the DLSw reachability cache:

• sna-cache-timeout???Length of time that a MAC or SAP location cache entry exists before it is discarded (both local and remote). Default is 16 minutes.

• sna-verify-interval???Interval between the creation of the cache entry and the time that it is marked stale and a directed search is sent to verify. Default is 4 minutes.

• sna-explorer-timeout???Length of time that Cisco IOS software waits for an explorer response before it marks a resource as unreachable. Default is 3 minutes.

• explorer-wait-time???Amount of time to wait for all stations to respond to explorers that are sent to them.

Once the DLSw circuit is established, it is no longer affected by entries in the reachability cache. The majority of SNA sessions will have no entries in the reachability cache, as they stay established for longer than 16 minutes.

You can issue the dlsw icanreach command to add a static entry to the remote reachability cache, to prevent polling across the WAN for that address. The entry that is seen in the remote DLSw peer reachability cache, as a result of this command, will be in the UNCONFIRMED state.

You can issue the clear dlsw reachability command, to clear the entire DLSw reachability cache.

Related Information

• Troubleshooting DLSw
• DLSw and DLSw+ Support
• Technology Support
• Product Support
• Technical Support - Cisco Systems