DLSW and the MAC that won't bridge....

[2tramsay]

I'm trying to migrate from a CIP attached router (7204) to an OSA card on our mainframe for our SNA connectivity. I've run into a bit of an odd problem.

It seems I can make a connection to the MAC on the OSA card from a subnet within my data center (I've tried several), but I can't make one work from a remote location via DLSW. The same connections work to the CIP attached router. To me, it looks like I have a problem with bridging, but I'm not 100% sure. I'm tring to connect to 00096b1ade31 on SAP 4.

I have a DLSW tunnel up and running from my remote location directly to my core switch (6509). The MAC in question is attached directly to the same core switch. I have bridging enabled on the VLAN, but I don't see the MAC in the bridge table. I do however see the MAC in the MAC address table.

WPG6509-A#SH DLSW REA

DLSw Local MAC address reachability cache list

Mac Addr status Loc. port rif

0000.836c.4278 FOUND LOCAL TBridge-001 --no rif--

0000.c1a2.e717 FOUND LOCAL TBridge-001 --no rif--

0002.319c.6194 FOUND LOCAL TBridge-001 --no rif--

0002.31b8.1483 FOUND LOCAL TBridge-001 --no rif--

0002.31b8.1576 FOUND LOCAL TBridge-001 --no rif--

0002.31b8.20e0 FOUND LOCAL TBridge-001 --no rif--

0002.31c6.39c7 FOUND LOCAL TBridge-001 --no rif--

0009.6b1a.de31 SEARCHING LOCAL

0020.00a4.5a28 FOUND LOCAL TBridge-001 --no rif--

0070.3006.5d03 FOUND LOCAL TBridge-001 --no rif--

4000.2216.3002 FOUND LOCAL TBridge-001 --no rif--

4080.0000.0000 FOUND LOCAL TBridge-001 --no rif--

DLSw Remote MAC address reachability cache list

Mac Addr status Loc. peer

0002.31b8.1483 FOUND REMOTE 10.89.1.2(2065)

0009.6b1a.de31 SEARCHING REMOTE

4000.0255.1091 SEARCHING REMOTE

WPG6509-A#sh mac-address-table | include de31

* 300 0009.6b1a.de31 dynamic Yes 0 Gi2/1

WPG6509-A#

WPG6509-A#sh run int vlan 300

Building configuration...

Current configuration : 282 bytes

!

interface Vlan300

description Mainframe VLAN

ip address 10.3.1.2 255.255.255.0

no ip redirects

ip directed-broadcast 176

ip route-cache flow

ip ospf network broadcast

standby 3 ip 10.3.1.1

standby 3 priority 125

standby 3 preempt

bridge-group 1

hold-queue 1000 in

end

WPG6509-A#sh run int gig 2/12

Building configuration...

Current configuration : 92 bytes

!

interface GigabitEthernet2/12

switchport

switchport access vlan 300

no ip address

end

Other config tidbits:

bridge 1 protocol vlan-bridge

WPG6509-A#sh run | include dlsw

dlsw local-peer peer-id 10.3.4.1

dlsw remote-peer 0 tcp 10.123.1.1

dlsw remote-peer 0 tcp 10.89.1.2

dlsw remote-peer 0 tcp 10.149.2.1

dlsw icanreach sap 0 4

dlsw bridge-group 1

Ideas welcome!

[mbinzer]

Hi,

first things first.

0009.6b1a.de31 SEARCHING LOCAL

that means the dlsw reachability cache has not yet found this mac address. As long as it is in SEARCHING it will not bring up a circuit.

when you say this worked on a cip router. Make sure that you are not confusing yourself with the format of the mac addresses used.

dlsw treats all mac address internally as tokenring format. Canonical versus non-canonical. I always forget which one is what so i say tokenring and ethernet format.

A cip is treated as a tokenring aswell from the mac address format.

But a OSA via bridge group sits on a ethernet segment.

So on what media is the client that tries to connect to that OSA via dlsw and what in what format is his dmac configured?

thanks...

Matthias

[2tramsay]

Thanks Matthias...

The OSA is ethernet, and the client at the remote end is ethernet - An Axis Print Server. (I have one SDLC partner connection as well on a 1721 Cisco router). They work when I aim at the CIP token ring address (40007200000A). This makes sense based on what your telling me. That MAC is token-ring format, the OSA is ethernet. When I aim at the token ring equivalent of the OSA card, I end up with the same problem - 0090.D658.7B8C SEARCHING. As I said, this works fine if my clients are local to my data center - even if they have to cross subnets. The only time I cannot make a connection is via DLSW. What's interesting is that the DLSW reachability does find the remote MAC of the Axis print server - ethernet format and all.

[jihicks]

Hi Tom,

The OSA has to be set up in non-QDIO mode.

Here is a link to an IBM redbook that should help, see Chapter 7.

http://www.redbooks.ibm.com/abstracts/sg245948.html?Open

I assume that you have an XCA and a Switched Major Node defined for this and both are active. When you see the MAC seraching, at the router local to the OSA, there is a test frame being sent out to the OSA. If the OSA answers test, then from the "show dlsw reach", it will change to "found".

We did have a problem where voice discovery caused a problem for the OSA, but this would prevent the link from connecting, see Bug ID CSCea90470. Sounds like this is not the case here.

I suggest sniffing the port where the OSA is connected to see if the test frame is going out to the OSA. If so and the OSA is not answering the test, then you may have to enlist IBM support at that point.

Jim

[2tramsay]

Hi Jim....

OSA is in Non-QDIO mode. XCA node and Switched major node are both Active. I have functional connections from Communication Servers under Linux systems on VM and from local SNA clients. The only issue is with clients that are across a DLSW pipe. Hope that's what your after. I've spoken to a couple of IBM'ers as well and they think it's a Cisco issue (of course!). What I find very odd is that I can see the MAC (Sh MAC-Address-table), but not in the bridge table (Sh Bridge). Any time I've done DLSW before, I cannot get a DLSW circuit unless the MAC is in the bridge table. All of the relevant connections terminate at the 6509 - DLSW tunnel, the VLAN interface is defined there, the OSA card is connected there, etc...

I don't think it's related to CSCea90470. It's a different set of circumstances, and a different result.

[jihicks]

The client is trying to connect to the wrong version ( bit-swapped ) of the MAC address. If the client is on ethernet, then they should be trying to connect to 0009.6b1a.de31. But if the client is on token ring or this is an SDLC partner MAC, then they should be connecting to 0090.D658.7B8C.

The fact that the canonical address on ethernet is 0009.6b1a.de31 and this is what shows as "searching" in DLSw, means client is connecting to the wrong version of the address. From a DLSw searching standpoint, the MAC should be the non-canonical version, or 0090.D658.7B8C.

MAC addresses in DLSw are always token ring format or non-canonical.

[2tramsay]

Thanks for your reply...

Client is ethernet (I do have and SDLC partner connection as well). I get the same result when trying to connect to the non-canonical version of the MAC -searching. So, is there no way to establish an SNA session to my OSA card via a DLSW connection? Documentation seems to indicate that OSA is fully supported. Not sure what to do next?

[jihicks]

Hi Tom,

You said that you can connect SNA devices that are local to the OSA, but not via DLSw, however you mention subnet. The SNA connections are via LLC ( layer 2 ) and not via IP. Make sure that the OSA supports this. Also, just to be sure, check "show span", there should be a port for the VLAN and a port for DLSw in the spanning tree and both should be forwarding.

Best regards,

Jim

[2tramsay]

Hi Jim...

Basically, I can make an SNA connection from an AXIS print server anywhere in this building. I've tried four different subnets. Aim at the MAC on SAP 4, and everything connects just fine. So, the support is there for OSA - Layer 2 connection works like a charm; except when the client has to connect via a DLSW connection. I did a show span, and I do see both the Mainframe VLAN and DLSW have a port that is forwarding. This one has me baffled...

[jihicks]

Hi Tom,

Then you should now see DLSw searching local for 0090.D658.7B8C, as this is the correct form of the OSA MAC address in DLSw.

Do you see this?

Jim

[2tramsay]

Yup! Searching... not 'Found'

[jihicks]

SPAN the OSA port on the switch and sniff the packets. Open up a TAC case.

Jim

[jihicks]

Hi Tom,

I would take off "dlsw icanreach sap 0 4" and any other filters you have that I don't know about and try again. SAPs 0 and 4 are correct, but I would take it off as a test.

D NET,ID=xca_groupname,E

Will tell you if there are PUs using the XCA.

Also attach the XCA and I will look at it.

Jim

[jihicks]

Hi Tom,

Try adding this command, in case the ethernet frame type is 80d5:

source-bridge enable-80d5

Find out which side is supposed to initiate the connection and span the port on the switch, so you can see what the explorer looks like and what MAC it is trying to connect to.

Look at the MAC address table for the destination MAC to be sure that the destination MAC is not found on a different port on the switch, causing the explorer to be sent somewhere other than the DLSw router.

Best regards,

Jim