ON THE WIRE

Lotus Macintosh Users Take Note

Our intranet supports more than 9,000 PC and Macintosh users, more than 100 Token-Rings and a few Ethernets. We are routing from Token-Ring to Ethernet and source routing between rings. We have some two dozen Lotus Notes servers running on a variety of OS/2-based platforms. Our PC users communicate to the server via SPX, our Macintosh users via AppleTalk. Our problem is that 500-plus Macintosh users can no longer communicate to certain Notes servers.

The servers with which Macintosh users are able to communicate are running an older version of OS/2. We don't want to downgrad e to the old versio n of OS/2, yet we can't seem to fix this problem any other way. The Macintosh Chooser fails to see a server even on an isolated test ring with one AppleTalk seed router, one Notes server and the Macintosh itself.

Bill: This is one of those problems where we wanted to make certain that the AppleTalk protocol was working properly and not being affected by other events on the network.

Scott: The Chooser couldn't find certain Notes servers in the zone in which they were supposed to be.

Bill: From a protocol perspective, everything, including the correct broadcast from the Macintosh requesting servers in that zone, checked out just fine and dandy.

Scott: Our client also noted that the servers in question d idn't appear to be taking on the default zone for that server.

Bill: So we focused on the boot process to see how the Notes servers were attempting to acquire their zone information.

Scott: The manner in whic h the "good" servers requested z one information and the manner in which the "bad" servers requested zone information were slightly different, but our analysis indicated that both methods were acceptable.

Bill: In fact, an analysis of packets generated during a boot of a Macintosh on the production network showed the same technique as was used by the bad Notes servers.

Scott: So, if AppleTalk across the network was working as advertised, why didn't the servers in question get their zone information, despite setting the default zone at the server?

Bill: To answer that question, we need to delve into one of the more complex areas of the AppleTalk protocol.

Scott: Our client's network is an extended AppleTalk network. On extended networks, each zone has a unique multicast address with which it is associated. On a Token-Ring, this multicast address is called a functional address.

Bill: When an AppleTalk node boots on Token-Ring, it needs to kno w which functional address is associated wi th its default zone.

Scott: This mapping is maintained by AppleTalk routers and is part of the Zone Information Protocol (ZIP).

Bill: A complete mapping of the network-to-zone information is stored in the Zone Information Table (ZIT). A node sends out a "GetNetInfo" packet and a router replies with the functional address for that zone, provided the zone name is valid.

Scott: Before sending the GetNetInfo, however, a node sends out an AppleTalk Address Resolution Protocol (AARP) packet. This packet is broadcast to the AppleTalk broadcast address of C00040000000. On a Token-Ring, this is referred to as a functional address. On Ethernet, it would be a multicast address.

Bill: In a situation where the Macintosh remembers its earlier AppleTalk address, the AARP packet will contain the tentative address that the node wants to use.

Scott: After sending the AARP several times and receiving no reply (me aning no other node has that AppleTalk address), the s tation will go ahead and use that address.

Bill: Then the GetNetInfo packet containing the default zone is broadcast from the node to the AppleTalk broadcast address and replies are sent from routers back to that node.

Scott: In the case where the node didn't retain its previous address, the protocol works a bit differently.

Bill: In that case, the node sends out an AARP with a network address somewhere in the start-up range of 65,280 through 65,534.

Scott: If the start-up address checks out OK, as indicated by no returns from the AARP, then the node broadcasts a GetNetInfo packet.

Bill: As in our previous case, the routers reply, but this time they send the replies to the AppleTalk broadcast address, since there is no known route back to the start-up network range.

Scott: The node then re-AARPs to check the uniqueness of the new network address it picked from the GetNetInfo replies.

Bill: Further scrutinizing the trace of the boot process of a good vs. a bad Notes server, we saw that the servers that Mac users could successfully communicate with were servers that started out with a tentative AppleTalk address, whereas the bad servers started with a start-up network address.

Scott: This meant that the replies to the GetNetInfo from the routers were sent to the AppleTalk broadcast functional address instead of directly to the Macintosh that requested it.

Bill: Looking back at our Notes server traces, we saw that the Notes server tried the GetNetInfo request three times in succession, with a brief delay between each re try, as if it never received the functionally addressed reply packets.

Scott: To confirm our suspicion that the server wasn't receiving packets with the AppleTalk functional address, we generated a brief burst of small packets on the suspect server's ring. We set the destination address to the AppleTalk functional address and made sure that the packets were not source routed, so that our "mini broadcast storm" did not leave the server's ring.

Bill: Lo and behold, all the good servers reported receiver congestion, but the bad servers did not.

Scott: To make sure that the adapters of the bad Notes servers couldn't really process those broadcast frames that fast, we then proceeded to blast a server with packets directly addressed to that server.

Bill: This time, we got the receiver congestion reports we expected from that server.

Scott: It turns out that the suspect servers didn't even report receiver congestion for an all-stations broadcast storm; that is, packets with the destination address set to all ones.

Bill: Coincidentally, the good servers had a di fferent brand adapter than the bad servers.

Scott: But we still didn't kno w if it was the new OS/2 and its corresponding newer AppleTalk stack and Network Driver Interface Specification (NDIS) driver or the adapter itself, so we swapped adapters with the type used in the good servers, and ran the same NDIS and AppleTalk stack.

Bill: Bingo. We could see that the server picked up the GetNetInfo reply broadcasts and proceeded to function normally and Macintosh users were able to get to the server.

Scott: Meanwhile, our client is switching adapters and working with the adapter vendor in question as to why the adapters suddenly stopped receiving broadcast packets.

Bill and Scott are principals of Pine Mountain Group. They can be reached at otw@pmg.com.