Configuring Data-Link Switching and Network Address Translation

Available Languages

Download Options

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

Updated:September 9, 2005

Document ID:12344

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

Problem

Solutions

Solution 1

Solution 2

Related Information

Introduction

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.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

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

Conventions

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

Background Information

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."

Problem

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 (123.112.5.10) and 123.112.1.19, 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 (172.10.1.1) and 123.112.5.10. 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.

Solutions

Solution 1

Change NAT to translate 172.10.1.1 into 123.112.6.1 to avoid confusion about which IP address is higher.

Solution 2

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: