Transparently bridged SNA, frame type problem.

[mdross]

I did post this under the LAN switching topic, but it occured to me maybe there's a more "SNA-specific" answer.

We are presently migrating off Token Ring, replacing it with switched Ethernet (all-Cisco network). In the process, we've hit a roadblock.

We have a legacy system (a Tandem, older revision) attached via Ethernet that communicates using translational bridging with the Token Ring interface into our mainframe (a 3745 TIC) via SNA. This legacy system can handle only the DIX / Ethernet II frame format. The mainframe also has an Ethernet connection, to which we've migrated all other SNA communications in an effort to eliminate the need for Token Ring equipment.

However, the mainframe understands SNA through Ethernet only over the 802.3 frame format (i.e., with the 802.2 LLC sublayer DSAP/SSAP fields). Thousands of our Ethernet-attached workstations are talking SNA just fine with the mainframe Ethernet adapter, using 802.3 Ethernet frame format, through transparent bridging. But the legacy system can't talk SNA with the mainframe Ethernet interface because the mainframe is looking for SNA via 802.3 while the legacy system can speak SNA only over DIX / Ethernet II.

This isn't a problem with this legacy system talking to the mainframe via Token Ring, because the DSAP and SSAP information in the legacy system Ethernet II frames are being repopulated into the correct Token Ring frame fields when they are translationally bridged.

It appears on the surface that our challenge is translating the DIX / Ethernet II frames from the legacy system to 802.3 frames at some point in the transparent bridging path. Thus far I haven't found a reasonable way to tell an MSFC2 to translate DIX / Ethernet II frames coming in on one VLAN interface to 802.3.

Any ideas appreciated.

[dixho]

You can use command "source-bridge enable-80d5" to convert DIX from ethernet to 802.2 to token ring or vice versa. The details about the command are as follows:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fibm_c/bcfpart1/bcfsrb.htm#1047803

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fibm_r1/br1fpt1/br1fsrb.htm#1021409

I see a challenge for you to have both 802.2 and DIX frames on the same VLAN. 80d5 support (i.e. DIX support) is configurable per SAP (Service access point). As most SNA devices uses 04, you cannot ask the router to handle both DIX and 802.2 frames for SAP 04. You need to either a different SAP value for the tandam or put the tandam in a different VLAN.

[mdross]

Hi. I appreciate the feedback very much.

Unfortunately, it seems that "source-bridge enable-80d5" does not apply here. We are migrating away from Token Ring. That is, getting rid of Token Ring is precisely what we wish to accomplish, so there is no T/R-to-Ethernet conversion. It's purely Ethernet transparent bridging (one Ethernet interface/VLAN to another Ethernet interface/VLAN) within which we need to perform the frame format translation (DIX/Ethernet II to 802.3/802.2). So that command shouldn't apply. In fact, in one of the links you list, it reads:

Note: The 80d5 frame processing option is available only with SR/TLB.

Seems an unusual challenge. We can definitely migrate the legacy, DIX-only system to its own VLAN if that would allow an option that wouldn't otherwise be available.

Thanks again. Here's hoping there's a way.

[dixho]

I am confused. I thought that you were running SR/TLB. I do not understand this because transparent bridging should not look at the ethernet frame types. All it cares are source and destination MAC address. What is the IOS version and hardware (MFSC?). Also, can you do a show bridge and find out if the station sending out DIX frames is in the bridge table. Also, have you checked the SNA stations and confirm that they all support DIX frames?

[mdross]

We are indeed, at present, performing Ethernet-to-Token Ring translational bridging between the legacy system (Ethernet-attached) and the mainframe 3745 (Token Ring-attached). And it's working perfectly. Has been for years.

But our goal now is to get rid of Token Ring altogether and have SNA between this legacy system and the mainframe go directly Ethernet-to-Ethernet (the mainframe has an IBM OSA Express Fast Ethernet interface as well). To do this, we attempted to transparently bridge between the legacy system (the Tandem) and the mainframe. Ethernet-to-Ethernet transparent bridging of SNA works fine between the mainframe Fast Ethernet interface and 1000+ Ethernet-attached workstations, which support SNA over 802.3/802.2. We want to use the same all-Ethernet path with the Tandem, and give our Token Ring gear back to the leaser who continues to charge us month-to-month for it.

But the Tandem speaks SNA only via the DIX/Ethernet II frame format, whereas the mainframe Fast Ethernet OSA Express adapter talks SNA only via the 802.3/802.2 frame format. Hence the inability of these two systems to talk SNA to each other over Ethernet.

> transparent bridging should not look at the ethernet frame types.

Exactly. Normally doesn't, and that's the problem. The legacy system talks SNA over DIX/Ethernet II. The mainframe talks Ethernet SNA over 802.3/802.2. Transparent bridging normally passes the frames in their original (transmitted) format standard from one host to another, in this case from the Tandem to the mainframe, so the mainframe drops them because it doesn't recognize SNA on the DIX/Ethernet II frame format.

What we're looking for, then, is some way of performing the DIX/Ethernet II-to-802.3/802.2 frame format translation within the all-Ethernet path/gear. (The Tandem is attached to a 3548XL uplinked to a 6509 with SUP2/MSFC2s, to which the mainframe Fast Ethernet interface is attached in a different VLAN).

Ethernet frame format conversion in the all-Ethernet infrastructure is the challenge.

[dixho]

I have a solution for you. The network topology is as follows:

tandam--ethernet--router_1--IP--router_2--ethernet--OSA

source-bridge 80d5-enable is configured on router_1. The IP network between router_1 and router_2 can be a cross-over cable, a VLAN on CAT6K, or anything. A DLSw peer connection is configured between router_1 and router_2.

Not an elegant solution, but it definitely works.

[mdross]

Yes, was thinking about DLSW to accomplish the frame format conversion. Have that going over the WAN. But you're right, I'd have to insert another router. No way I know of to simulate peering within a router/MSFC (say, with loopback interfaces); I don't think that works. Besides, how could I direct the transparently bridged frames through such a setup on the way to the mainframe VLAN? The bridge table is checked and they get switched directly to the MAC address source interface, of course. Any such thing as MAC-NAT? :-)

In fact, I have our MSFCs running Service Provider IOS, so unless I upgraded them as well to run DLSW, I'd have to insert two routers for the DLSW peers between the Tandem and the 6509 to which the mainframe OSA Express interface is attached.

I want the feature "bridge-group [bridge group #] 802D5-8023 (input-address-list [access list #])" in IOS 12.3XD. (Granted, my shop would be among minimal company.)

[dixho]

I think that I was not clear about my solution. I suggest you to create a new VLAN for all the Tandems. I assume that the only connection Tandems required is a SNA connection to the OSA. Router_1 is connecting to the new VLAN. This will take care of the problem on MAC-NAT.

If you want a new feature on IOS, you need to talk to the local Cisco Rep. He/she will take your requirements and build a business case. Cisco will look at the business case carefully and make a decision on whether to add the new feature or not.

[mdross]

Alas, SNA is using the same interface on the Tandem as does IP. I guess the only solution I can see is to give the Tandem it's own router (we do have one available), and use DLSW peering with another router, all internal to this site. The DLSW would serve as a Tandem-OSA communication intermediary to, hopefully, obviate the frame format issue.