ON THE WIRE

The Problem With Mixing Switching

by Bill Alderson and J. Scott Haugdahl

Q : We recently joined our corporate backbone to a remote Ethernet rib using a pair of routers connected via frame relay. The remote users have access to their own local server, but we wanted everyone on the remote LAN to be able to access our corporate mainframe via an SAA gateway attached to a Token-Ring backbone. The 3270 terminal emulation at the remote site communicating through the routers to the SAA gateway works great, but now users are having trouble accessing their local server. Sometimes they can't even attach to their server or, worse yet, the workstation hangs u pon booting. When we attach th e router at the backbone site to an isolated ring with only itself and the SAA gateway attached, everything works normally. How can our routed connection to the backbone possibly affect the local server access?

Scott: The first order of business was to step back and look at the big picture, like, "the backbone's connected to the hipbone, the hipbone's connected to the thighbone"

Bill: No bones about it. Except in this case, we needed to examine our client's network documentation to get a feel for the skeleton of the network.

Scott: Since data networks are packet-switched networks, we needed to see what packet-switching technology was employed.

Bill: In this particular case, the remote router was set up to switch packets at the network layer using the IPX protocol.

Scott: At the backbone, however, source route bridging, a form of datalink layer switc hing popular in Token-Ring environments, was employ ed by bridges attached to the backbone.

Bill: We began our testing by moving the router back to the backbone and then we analyzed an attempted connection at the remote Ethernet site to the local server.

Scott: Normally, a NetWare workstation will connect to the "nearest" file server. That is, the first server to respond to a "Get Nearest Server" request packet broadcast from the workstation using the NetWare Service Advertising Protocol (SAP).

Bill: This packet originates from a workstation on the Ethernet, so it does not contain source routing.

Scott: Since the router was set up on the Ethernet side to route IPX, it responded to SAP requests on behalf of other servers it learned about from the WAN side. Local servers will also respond to SAP requests, but in this case only the router did.

Bill: Our trace showed that a workstation first attempted to find a NetWare server with NetWare Direc tory Services (NDS) capability, namely a NetWare 4.x server.

Scott: Normally this is fine, since even though the server you first connect to upon booting may not be the server you log in to. This is how the NetWare connection protocol works--you always connect to the "nearest" server, then get "handed off" to the server you really wanted.

Bill: The router sends a reply to the workstation saying, "I know about an NDS server" that it discovered from a NetWare 4.1 SAP received via the WAN link. The NetWare 4.1 server resides on a ring attached to the backbone ring via a source route bridge.

Scott: The workstation then asks for a route to that server via a NetWare Routing Information Protocol (RIP) broadcast which then receives a reply from the router.

Bill: Next, the workstation sends a connection request packet to t he router t hat is to be routed via IPX to the NetWare 4.1 server. It receives no reply, so the workstation continues to retry with several packets over a span of 40 seconds, gives up, tries to SAP and RIP again, tries again to connect for 40 seconds, and then gives up for good. So while waiting all this time, the user perceived the workstation as hung.

Scott: No packet returned because the packet never made it to the NetWare 4.1 server in the first place. It only got as far as the backbone. None of the source route bridges forwarded the request, since it was not source routed by the router.

Bill: Whenever connecting two packet-switching technologies, you must pay close attention to which technology (here, IPX routing at the network layer or source routing at the DLC layer) is in charge of the packet. Since we're connecting an IPX routed network (the Ethernet and the routers) to a source route bridged network, we must turn on source routing where the router co nnects to the backbone, in order to have packets flow to and from the IPX and source-routed networ ks.

Scott: By configuring the router source routing at the Token-Ring interface, the NetWare 4.1 server could receive the connect request packet and send a reply back. Having done this, the connect sequence to a workstation on the remote Ethernet was satisfied, and the hand-off to the server on the Ethernet was accomplished without a hitch.

Bill: Not only that, but full IPX communication was then possible between any Ethernet node and Token-Ring node located throughout the infrastructure.

Scott: Another possible solution would have been to turn off a workstation's request for a connection to an NDS server, reverting to a BIND request instead. However, other complications needed consideration, and we wanted full communication capability from the remote Ethernet to any service on or off the backbone.

Bill: Now we're goi ng to leave our readers with a little something to ponder...

Scott: If the router didn't have s ource routing enabled at the Token-Ring interface, why did it accept a source-routed SAP broadcast that originated from the NetWare 4.1 server?

Bill: After all, that's how the NDS service SAP got propagated up to the Ethernet in the first place.

Scott: If source-route bridges don't accept broadcast packets unless the single- or all-routes broadcast bit is set, should routers?

Bill and Scott are principals of Pine Mountain Group. They can be reached at otw@pmg.com. Portions of the actual trace files from selected columns are available via Pine Mountain Group's Home Page ( http://www.pmg.com ).

February 13, 1996