DLSw+ reverse media translation and SDLC-attached FEP

[ringwyrm]

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?)

[ringwyrm]

Yes it is Cisco to Cisco.

On the FEP/SDLC end:

2811 w/ 12.4(8d) Advanced Enterprise

On the secondary/ethernet end:

7200 NPE-G2 w/12.4(15)T1 Advanced Ent w/SNASw

[jihicks]

I think what you were seeing is a CANUREACH explorer ( CUR_ex ) over UDP and a CANUREACH CIRCUIT START ( CUR_cs ) over TCP. The explorer comes first and then the circuit start.

[ringwyrm]

Yep... you're right.

So what triggers the circuit start suddenly? This is where I am lost. Is there a timer?

Do you want the case number?

[jihicks]

XID, see the following:

http://www.cisco.com/en/US/tech/tk331/tk336/technologies_tech_note09186a00800a6934.shtml

[ringwyrm]

Ok..

Well, I have a trace which will show that the secondary unrelenting sends XIDs every five seconds or so when it is in a failed state. That trace in the case.

[jihicks]

Yes and in the IP trace I see the UDP CANUREACH being sent out and no response received. I suspect at the time we we had the MAC of the SDLC side in the cache on the router. We can answer test locally. We can not answer XID locally. Seems like we are back to the same place, disable UDP and see if that fixes the problem.

[ringwyrm]

It did not fix the problem.

I am sending some new captures shortly. In this case, we see 1-for-1:

CANUREACH (TCP) --->

<--- ICANREACH (TCP)

Both ends show that the MACs/SAPs are found in the DLSw reachability cache. I see XIDs coming in from the secondary every second, and I do not see corresponding ID_STN.Ind going out over DLSw.

One thing I notice in the debugs is that the CANUREACH/ICANREACH packet debugs show the SAPs as (00 08). However, the configuration on the Tandem and on the router is (08 08). Does this different matter?

[jihicks]

No the test frame foing from SAP 08 to SAP 00 is OK.

In the last sniffer trace that you attached, I see two CUR_ex frames that match the correct MAC addresses. Frame 12 ( no response ) and frame 25. The ICANREACH response to frame 25 is over TCP. Then I see CUR_cs ( frame 49 ) and ICUR_CS ( Frame 51 ) and REACH_ACK ( frame 53 ). XIDFRAME ( see RFC 1795 )from 253.1 to 1.73 and the I see the XID Format 0 Type 2 from the Tandem. The circuit keeps progessing to connected. You said you had another with the udp-disable that you were going to attach?

be careful, most of the CUR frames in this trace are for other MAC pairs than the ones we are working with.

[jihicks]

I think what you were seeing is a CANUREACH explorer ( CUR_ex ) over UDP and a CANUREACH CIRCUIT START ( CUR_cs ) over TCP. The explorer comes first and then the circuit start.

[ringwyrm]

This issue has been resolved as bridging loop which was formed by a backside link between two different customers of ours, and a third-party.

This was a surprise to me, because we were seeing the TEST frame P/F just fine...

I have a question, what MAC address does DLSw use for its multicast CUR and ICR messages? I'd like to filter on those on all of our customer-facing interfaces.

[jihicks]

You are not using multicast as you do not have this configured. You are using UDP unicast. All explorers are sourced from the MAC intiating the connection to the target MAC of the connection. Multicast and unicast are in regards to the IP addresss and not the MAC address. If you want to filter, this can be done at the interface ( if bridging ) or via DLSw icanreach and icanreach mac-exclusive.

http://www.cisco.com/en/US/tech/tk331/tk336/technologies_configuration_example09186a0080094135.shtml

[ringwyrm]

Right...

I think we are going to filter on source MAC address on the opposite "sides" of the loop, if you know what I mean by that.

Why did the Test P/F seem to work? I am curious about that. Is that translated to a simple sort of ping/oam between DLSw peers? That would make sense.

[jihicks]

Once reachability has been established and the remote MAC address is in reachabiltiy, then the test frame is answered locally by DLSw ( nothing is sent to the peer )if the cache entry is not stale, age < 4 minutes. I think that is why it was being answered. If cache entry is older than 4 minutes but less than 16 minutes ( defaults ) then reachabilty is verified by sending a CUR back to the peer where it is found in cache. If more than 16 minutes it ages out of cache.

[mbinzer]

Hi,

at canureach_ex is a test or a contextless xid. If you have reachability over a specific

peer it is send to this peer only. If there

is no reachability it is send to all connected peers.

If the other ends status is FOUND local and it is less than 4 minutes old by default, it will answer directly to this with a positive response, without even bothering the real end system.

If the cache status is FOUND, and between 4 minutes and 16 minutes old it will send a verify to this reachability. If answered positive it answers with an icanreach_ex.

If there is no reachability it will search on all local interfaces to find the requested resource.

thanks...

Matthias