This document describes the solution for a data-link switching (DLSw)
scenario using Network Address Translation (NAT) (based on this illustration)
that involves peers disconnecting themselves for no apparent reason.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware
For more information on document conventions, refer to the
Cisco Technical Tips
Debugs in Routers A and C show that the connection gets past CAP_EXG,
and reaches the CONNECT state. The Cisco implementation of DLSw specifies that,
instead of using two TCP sessions between Router A and Router C, one TCP
connection is dropped when a connection is established between the two
The TCP connection that is dropped is determined by following section
7.6.7 of RFC
"The TCP connections control vector indicates the support of
an alternate number of TCP Connections for the Data Link Switching traffic. The
base implementation of Data Link Switching supports two TCP connections, one
for each direction of data traffic.
This control vector is optional. If it is omitted in a DLSw
Capabilitiies Exchange, two TCP connections are assumed. It is further assumed
that if a Data Link Switching can support one TCP Connection, it can support
two TCP connections.
If TCP connections CV values agree and the number of
connections is one, then the DLSw with the higher IP address must tear down the
TCP connections on its local port 2065."
DLSw plus (DLSw+) peers establish a connection between Routers A and C,
but do not stay connected.
Router A thinks its DLSw TCP session is between itself (126.96.36.199)
and 188.8.131.52, which is the Router C IP address once it goes through NAT.
Router A concludes that it has the higher IP address, so it thinks it must tear
down the TCP connection on its local port 2065.
Router C thinks its DLSw TCP session is between itself (184.108.40.206) and
220.127.116.11. Router C thinks it has the higher IP address and that it must
tear down the TCP connection on its local port 2065.
As a result, both TCP sessions are torn down,
leaving the routers in a DISCONNECT state.
Change NAT to translate 18.104.22.168 into 22.214.171.124 to avoid confusion
about which IP address is higher.
Use the new configuration option v2-single-tcp in
the dlsw peer command configurations. This feature
has been introduced with Cisco bug ID
(registered customers only)
and integrated in Cisco IOS® Software
Releases 12.3(04.04)B, 12.2(19.04)S, 12.3(03.03)T, 012.003(003.003),
12.3(03.02)T, and 12.002(018.002).
DLSw version 2,
defines the DLSw TCP peer bringup with a single TCP session. With this, the
problem described above does not exist anymore since there is only one TCP
session and it makes no difference which end has the numericaly higher or lower
The v2-single-tcp keyword instructs this router to
bring up a DLSw version 2 peer and, because of this, both routers automatically
only use one TCP session to establish the peer.
The use of the new keyword should be similar to this for the topology
described in this document:
Branch Router C tries to establish a DLSw peer to data center Router A.
Data center Router A is running Cisco IOS Software version 12.0 or later, which
already supports DLSw version 2. The dlsw local-peer
command configuration on data center Router A is either promiscous, to allow
any incoming peer connection, or, if you have to configure each connection
individually, the peer to branch Router C is configured to be passive.
Branch Router C is configured on this dlsw
remote-peer command with the new keyword
v2-single-tcp, which starts a version 2 peer to the
central data center Router A:
dlsw remote-peer 0 tcp 126.96.36.199
For more detailed information, refer to the release notes of Cisco bug
(registered customers only)