cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1748
Views
0
Helpful
28
Replies

DLSw+ reverse media translation and SDLC-attached FEP

ringwyrm
Level 1
Level 1

I have an SDLC-attached FEP, and I am doing reverse-media translation to the secondary which is on a remote token-ring LAN.

Whenever they bounced the FEP port, it takes 15 minutes or so to recover. Is there a timer or other setting I need to configure on the router? (DLSw+, SDLC, or LLC2 timers?)

28 Replies 28

jihicks
Cisco Employee
Cisco Employee

Hi Derick,

The connection is really initiated by the endpoints, the token ring PU sending TEST, then XID and the FEP sending SNRM. I don't see anything obvious to change. It may take tracing this at both ends to see what is going on, check the serial interface and dlsw circuit at the same time. You can cause your console commands to be time stamped with "terminal exec prompt timestamp". Make sure the circuit drops when the FEP port is bounced. Now see if one side is slow at starting the connection.

Jim

I'd like to add that this was a STUN connection and, of course, it took something like a few seconds or a minute to recover when it was stun. Then they moved the secondary PU to token ring (because the serial cards are way... way... way... out of support).

##############

interface Serial0/0/0

no ip address

encapsulation sdlc

no keepalive

clock rate 9600

sdlc role secondary

sdlc vmac 4000.6660.3400

sdlc address C1

sdlc partner 4000.3745.0103 C1

sdlc saps C1 08 08

sdlc dlsw C1

##############

So I was looking at this, and I'm curious if I should configure the "sdlc line-rate" command. Also since the attached device is a FEP should I use "sdlc address c1 seconly" instead of "sdlc role secondary?"

What is the PU type genned in the NCP and what is the device on token ring? Don't be fooled by PU2.0 and PU2.1 as the difference in the NCP gen is XID=YES for PU2.1. The "seconly" keyword is for PU4 to PU4 connections ( FEP to FEP ).

Configuring "sdlc line-speed" is OK, but not a fix for this problem. You really need more information about what is going on.

PU2.0

The secondary is a Tandem. Is there a timer on there that could be set? Obviously with the STUN connection if the serial line goes down... then the serial line goes down. On a token ring, things are different. So I wonder if there is a session timeout or a link timeout type setting on the Tandem...

So, we are about to do some testing on this during a window provided to us by the customer, but I would like to give you some additional details...

The SDLC-attached FEP, when they bounce the serial port, they start sending SNRMs, and they just start receiving DMs back from the router... this goes on for a totally random amount of time, somewhere between 10 minutes (the shortest they've seen) up to an hour (the longest they've seen).

Then, for whatever reason, they DMs stop and the PUs come active.

I'm curious. Since the default direction for the SDLC partner is inbound... when they bounce the FEP port, does the router disconnect the session, and just wait indefinitely for the secondary to send an XID?

Could this be fixed by changing the direction to outbound?

Also, would configuring the "sdlc xid" command have any effect when the sdlc role is secondary?

Yes, the router waits for the secondary to connect. Since the FEP is sending SNRM immediately, this is a PU2.0 in the NCP. You SHOULD have XID configured on the SDLC interface. However, I don't think it will get used in this case. You can try outbound also, it might help. However, normally the secondary would be retrying immediately, so I wonder what is going on with it. I suggest you open a case and get traces of the secondary ( on the token ring ).

Jim

Thanks for your help..

So strangely, we are receiving XID0s (TEST_STN.Ind), but the DLSw is not establishing. Its as if the router is ignoring it.

When they change to XID3 (ID.Ind), the router immediately recognizes this and trys to establish the circuit.

Its strange. If we wait long enough, the router eventually seems to just accept the TEST_STN.Ind (XID0) and it does recover, but it takes a very long time for this to magically clear and work. Nothing is different.. it just happens by itself.

So the secondary is sending it every five minutes, and I see it.. it seems like the router is ignoring it. When we switch to XID3, the router immediately trys to establish the circuit, every time.

Almost sounds like a bug. Is there something about XID0s that needs to be true for the router to acknowledge it and try to establish the circuit?

You are very welcome.

When this is going on, is the circuit between 4000.6660.34C1 and 4000.3745.0103 still up? If so, they took down the PU but not the line. If the circuit is still up, this might explain the problem, the XID3 might cause the DLSw circuit to go down due to circuit collision and come back up.

Alright, so completely disregard my previous message. That was a point-in-time evaluation based on the information I had and it is totally bogus (wrong).

So eventually the XID3s stopped coming too. I opened a case with Cisco which lead me to believe that there could be a timer/race issue. So I started packet capturing after a failure and ran all kinds of SDLC/DLSw debug on the other end and waited for it to recover.

What I am seeing is this: When in a failed state, I am seeing periodic UDP CANUREACH coming in from the remote secondary-attached router. Then the local router replies to that with a TCP ICANREACH (is this normal?). This occurs repeatedly. Nothing comes of it, the circuit stays down.

Then for some reason the CANUREACH comes in as *TCP* instead of the numerous previous *UDP* ones. When this occurs, the local router replies with a TCP ICANREACH and the link comes up immediately. It seems that TCP is triggering the right behavior and UDP is not.

Any thoughts on this? If I do "dlsw udp-disable" should the UDP stuff stop?

Absolutley. Sounds like the canureach ( UDP ) is getting dropped or blocked. If you configure "dlsw udp-disable" then the CANUREACH and ICANREACH are sent over the TCP session and not via UDP UNICAST. Sounds like that will fix it.

Well, they are definitely not being blocked. I see them coming in at the other end.

So the fact it recovered the first time it tried TCP may be a coincidence.

Still... I will disable UDP to see what happens. Do I have to disable this on both ends (not preferred) or just on one end?

Just one end The fact that you disabled it gets sent to the peer via capabilities, as soon as you enter it. You can see this in the field "UDP Unicast Support" in the output from "show dlsw cap" ( remote peers ) and "show dlsw cap local" for the local peer.

CANUREACH UDP --->

<---ICANREACH UDP

A couple of things. First, If you don't see dlsw UDP disable on either side, I am surprised that the CANUREACH would ever go over TCP. Second, you see the CANUREACH making it across, do you see the icanreach making it back to the router at the other side? It has to make it into the router, past any ACLs on the interface. I suspect it isn't. Otherwise, the problem would not exist. Reachability would be established. Anyway, since it appears to be a problem, the "dlsw udp-disable" should fix that .

Ahh.. well there is the weirdness maybe.

There are no ACLs or firewalls blocking anything in the path.

We are seeing this:

CANUREACH (UDP) --->

<--- ICANREACH (TCP)

We are seeing a TCP response to UDP request. Eventually, a TCP request comes and, and a TCP response occurs, and the circuit recovers.

Hi,

just to be sure.

We are talking about cisco to cisco, right?

What versions of ios are you running on both

routers?

thanks...

Matthias

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: