Problem establishing SNA session over DLSw link

KeithGage · ‎11-30-2004

We are experiencing sporadic problems establishing an SNA session over a DLSw tunnel. The session is between a Tandem host and a CICS region on OS/390. A Cisco 7500 router performs one end of the DLSw link; that same router is channel-attached to the OS/390 mainframe using CIP and uses CSNA for SNA traffic.

The connection is initiated by the SNA software on the Tandem box, but it rarely works on the first attempt. The session goes into a pending state and has to be cancelled and re-tried. This has to be repeated until such time it is successful. Once the session is started it works without problem.

At the point of attempting to start the session all the components are in the 'correct' state, i.e.

-DLSw tunnel is connected

-Host PU is in 'connectable' (CONCT) state

-Host XCA defining CIP SNA and virtual lines are active

No action needs to be taken on the OS/390 end of the link (or anywhere else for that matter) between start attempts on Tandem.

From device traces on OS/390 my suspicion is that the session requests are not actually getting to VTAM on OS/390 for some reason. DLSw traces on 7500 appear the same in both case of success or fail of session start.

Has anyone experienced this, or know of problems in this area that may explain what we are seeing?

Thanks.

Keith

mbinzer · ‎11-30-2004

Hi,

what version of ios are you running on the cisco 7500 router acting as dlsw peer?

Additional when you try to establish the connection in what state is the dlsw reachability cache at that point on the 7500?

show dlsw reach

debug dlsw reach verbose

will give you a first idea.

Additional you can get some information even after the fact from the 7500 with the following display:

show dlsw circuit history detail

by default the router keeps the last 32 circuits or circuits attempts.

You get a listing of existing circuits and those who never connected ect together with a trace of the internal state machine.

If you have to many circuits and it scrolled already out of the 32 abailable ones than you can increase the history table with the following command:

conf t

dlsw history-log 500

this would increase the history log buffer to keep the last 500 circuits, again the default is 32.

You can then do the show dlsw circuit history detail, save it to a text file and search for the mac address pair you are interested in.

If the 7500 does see the circuit setup attempt than you will have a log of it in the circuit history table. Please post the output and we can then have a more detailed look on what might go wrong.

thanks...

Matthias

KeithGage · ‎12-02-2004

Hi,

Thanks for quick response. We'll try what you suggested as soon as we can and post info.

Keith

maryodriscoll · ‎02-03-2005

Matthias

I am replying to this message on behalf of Keith Gage. I have attached 3 text files that show the version IOS running on the CIP, Dlsw circuit history detail and DLSW reachability. I am not a mainframe SNA expert or CIP expert but hope you can see something in these files that would explain why SNA sessions take a while to establish intermittently.

Thanks and Reegards

Mary O Driscoll

ehirsel · ‎02-03-2005

What software type and level is running on the Tandem host? And what device is on the other end of the DLSW link (i.e., another router)?

Are there any error messages on the Tandem host? Some emulators allow the user to run a trace, and if that one does, please run it and let me know what the results are.

mbinzer · ‎02-03-2005

Mary,

thanks for the extra information.

I would advice at this point the following:

Open a case with the Tac. Provide the information you have at that point and agree on a action plan, i.e. what to look at what trace to take, when you are able to recreate the problem.

What i can see from the documents you attaches is the following:

I only see sna circuits in the dlsw circuit history.

In you show dlsw reach there are quite some netbios names aswell and a large number of mac addresses learned from the remote peer.

You may want to discuss some filter options with the tac to make sure we cut down on the size of the reach cache and to make sure we advertise only those mac addresses which are really needed.

From the show version, 12.1(17) should be fine for dlsw in the way you described it.

From the show dlsw circuit history detail we have a couple of times that circuits are disconnecting.

Most of the time these circuits are up for a long time and they get the following sequence before terminating:

Index local addr(lsap) remote addr(dsap) remote peer

1157627904 4000.0410.0001(08) 0800.8e00.9708(08) 10.19.2.124

Created at : 12:02:55.115 GMT Mon Nov 29 2004

Connected at : 12:02:55.447 GMT Mon Nov 29 2004

Destroyed at : 22:04:01.158 GMT Wed Dec 1 2004

Local Corr : 1157627904 Remote Corr: 3321888773

Bytes: 140092/145133 Info-frames: 1748/2327

XID-frames: 1/2 UInfo-frames: 0/0

Flags: Remote created, Local connected

Last events:

Current State Event Add. Info Next State

-------------------------------------------------------------------

CONNECTED DLC DataInd 0x0 CONNECTED

CONNECTED WAN infoframe 0x0 CONNECTED

CONNECTED DLC DataInd 0x0 CONNECTED

CONNECTED WAN infoframe 0x0 CONNECTED

CONNECTED DLC DataInd 0x0 CONNECTED

CONNECTED WAN infoframe 0x0 CONNECTED

CONNECTED DLC DataInd 0x0 CONNECTED

CONNECTED WAN infoframe 0x0 CONNECTED

CONNECTED DLC DataInd 0x0 CONNECTED

CONNECTED WAN infoframe 0x0 CONNECTED

CONNECTED DLC DataInd 0x0 CONNECTED

CONNECTED ADM WanFailure 0x0 HALT_NOACK_PEND

HALT_NOACK_PEND DLC DiscCnf 0x0 CLOSE_PEND

CLOSE_PEND DLC CloseStnCnf 0x0 DISCONNECTED

this circuit was up for more than a month and the reason for disconnection was ADM WAN failure which means the dlsw peer went away at some point.

Some other circuits get these sequence:

CONNECTED WAN infoframe 0x0 CONNECTED

CONNECTED WAN halt-dl 0x0 HALT_PENDING

WAN halt-dl means the other end tells us to disconnect. No information on this end why. Most of the time it is a legitimate disconnect. but you would need to look at the dlsw peer to get information who terminated the session.

I dont see anything specific in a sense that a circuit did not go to connect at all. In the information you supplied.

Again my advice open a case with the tac and then you can work the issue to completion.

thanks...

Matthias

maryodriscoll · ‎02-04-2005

Matthius, One of our CCIE's is going to open a tac call with the information from above, thanks for your help

Mary O Driscoll

maryodriscoll · ‎02-04-2005

Matthius, One of our CCIE's is going to open a tac call with the information from above, thanks for your help

Mary O Driscoll