SNA over the Internet

Unanswered Question

I am tasked with finding cheaper broadband solutions for connecting remote facilities back to corporate. I need to set up IPSEC tunnels from the remote to corporate that allow me to not have to change my current private addressing. This I believe I should have no problems accomplishing. The tricky part is I also have to run SNA over the Internet. Has any one tried to run a DLSW type connection over a DSL or Cable modem IPSEC tunnel. If so did, did it work or was the latency of the Internet too large to keep the dlsw peers active?

Any suggestions are appreciated.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
rclousto Fri, 10/17/2003 - 09:42
User Badges:

Hi Phil, I don't believe you'll have any latency problems using DSL or cable. Have you considered SNASw in the branch rather than DLSw? You can use an Enterprise Extender (HPR/IP) connection to the host. It should be more straightforward to set up. You can find more info starting at . We also have a draft whitepaper on setting up IPSEC over a SNASw APPN connection to the host. I can send it to you (it's not published on CCO yet) if you like.

rclousto Fri, 11/07/2003 - 10:16
User Badges:

On its way. The white paper actually covers host to host, without SNASw, but I also sent you a presentation I gave at the last SHARE which includes a SNASw branch example with IPSec. Regards, Bob

rclousto Mon, 01/19/2004 - 07:34
User Badges:

I've sent this to you. I'm trying to get more information on VTAM encryption, which I don't think I even mention in the presentation. If anyone has a pointer to this I'd be grateful, and we'd update the white paper and presentation with that information. Thanks and regards, Bob

slleb Tue, 12/09/2003 - 07:08
User Badges:

Could you also send it to me?



mbinzer Mon, 01/19/2004 - 09:37
User Badges:
  • Cisco Employee,


if you want to run dlsw over a vpn/nat solution you need to look at the following:

this discusses problems with dlsw version 1, RFC1795, this is the default for cisco routers. The point is that the dlsw peer establishment is defined as a bringup of two single tcp connections until the capabilities exchange is done. Each router opens his own write pipe and recieves the read pipe from the other one. So each of them has two tcp pipes open at that point. Then the router with the "numerical" higher ip address drops his pipe on the local tcp port 2065.

This can cause quite some trouble if you dont control the ip nat translation inbetween. So both sides either think they have the numericaly higher ip address on its local peer and both drop the connection or both think they have the lower one and the connection times out.

Additional we commited a change to dlsw with CSCeb47150 which allows the remote device to bring up a dlsw version 2, RFC2166, peer to head end system, and in that case the peer bringup is defined with only one tcp pipe and the whole problem with who has the numericaly higher or lower ip address does not exist anymore. I copy the release note for CSCeb47150 right below here:


Symptom: Customer has DLSW defined at two locations. The locations are connected together over a

VPN tunnel. The peers start to establish and drop after capabilities excahnge.

Conditions: NAT is being used but outside the customer's point of control.

Problem: DLSw Version 1, RFC1795, defines the dlsw peer with tcp encapsulation to use 2 tcp pipes

for the peer bringup. A Write and a Read pipe. Both routers establish their respective Write pipe.

That means that if router A opens a dlsw peer to router B router A establishes his Write pipe to

router B and router B than establishes his Write Pipe back to router A. Next the capabilities

exchange happens and during this exchange the two routers decide if they can drop one tcp

connection and use the resulting tcp session for traffic in both directions. This decision is

based on the numericaly order of the local peer ip addresses. The peer with the numericaly higher

ip address is supposed to drop his tcp pipe. This is defined in RFC 1795 section 7.6.7.

If ip NAT is used inbetween the two dlsw peer routers and the NAT is changing the order of numericaly

higher or lower local peer ip address the peer may fail to establish. Both routers may think that they

are the higher ip address and both drop their tcp session or both think they are the lower ip address

and wait for the other end to take action.

Workaround: The user must preserve the numericaly order of the dlsw local peer ip addresses through

ip NAT. This is not always possible and in any case it is not an easy task.


This ddts added a new configuration option to the dlsw peer statements:


This is intended to do the following:

DLSw Version 2, RFC2166, defines the dlsw tcp peer bringup with a single tcp session. So above Problem

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 will instruct this router to bring up a dlsw Version 2 peer and thus both routers

will automatically only use 1 tcp session to establish the peer.

The usage of the new keyword should be like this:

Branch router A tries to establish a dlsw peer to data center router B.

Data center router B is running ios 12.0 or higher and thus already supporting dlsw version 2.

The dlsw local peer configuration on data center router B is either promiscous, to allow any incoming

peer connection, or if you have to configure each connection individual the peer to branch router A is

configured to be passive.

Branch router A is configured on his dlsw remote-peer statement with the new keyword v2-single-tcp and thus

it starts a version 2 peer to the central data center router A.


DLSw version 2 does not support priority peers.





This Discussion