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 versions.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
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 routers.
The TCP connection that is dropped is determined by following section 7.6.7 of RFC 1795 :
"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 CSCeb47150 (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, RFC 2166 , 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 IP address.
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 v2-single-tcp
For more detailed information, refer to the release notes of Cisco bug ID CSCeb47150 (registered customers only) .