This document explains how the reachability cache works for data-link
switching (DLSw) and provides information to troubleshoot DLSw circuits.
There are no specific requirements for this document.
This document is not restricted to specific software or 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.
For more information on document conventions, refer to the
Cisco Technical Tips
Use the flowchart below to navigate through the Data-Link Switching
(DLSw) reachability cache entries.
DLSw reachability cache entries are controlled by these two
The remainder of this section explains the default method of
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
When you are troubleshooting DLSw reachability problems, use the
privileged EXEC command.
show dlsw reachability [[group [value] | local | remote] |
[mac-address [address] |
group???(Optional) Displays the contents of
the group reachability cache only.
Specifies the group number for the reachability check. Only displays group
cache entries for the specified group. The valid range is 1 to
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.
Specifies the MAC address for which to search in the reachability
netbios-names???(Optional) Displays DLSw
reachability for NetBIOS names only.
Specifies the NetBIOS name for which to search in the reachability
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
!--- 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.
!--- 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
!--- 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.
!--- 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.
!--- 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.
!--- 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
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
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
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
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
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
You can issue the clear dlsw reachability
command, to clear the entire DLSw reachability cache.