http://www.microsoft.com/technet/tnnews/features/macroute.htm (PC Press Internet CD, 03/1996)
| Updated: March 11, 1996 |  Go To TechNet Home Page |
By John Jacobs
ABSTRACT: This article discusses AppleTalk routing in terms familiar to administrators who have used other routable protocols, such as TCP/IP and IPX. From this basic information, the article moves on to discuss how to plan a routed network, problems resulting from poor planning, Windows NT Server configuration problems, and guidelines for avoiding problems. At the end of the article are pointers to related information.
Introduction
AppleTalk Routing Basics
Example
AppleTalk Routing Functionality in Windows NT Server
Potential Seed Routing Problems
Avoiding Problems
Conclusion
More Information
When implementing mixed-platform networks, administrators are often challenged by interoperability issues. Implementing AppleTalk routing is particularly troublesome: the AppleTalk designers developed new solutions to solve new problems, and Windows NT Server administrators who are not familiar with AppleTalk networking may find the configuration options confusing. The Windows NT Server documentation covers this topic in detail, but some administrators have requested a new perspective to help them understand the hardcopy and online documentation. This article describes the basic theory of AppleTalk routing, explains the routing capabilities of Windows NT Server, describes common problems, and discusses strategies for avoiding problems.
Like many other routable protocols, AppleTalk uses a unique two-part address to identify each node on a network: the network address ("network number") identifies a physical subnet, and the node address ("node ID") identifies a particular node on that physical subnet.
AppleTalk uses one byte to store the node ID and two bytes to store the network number. Like most routable protocols, Apple's initial release of AppleTalk, known as AppleTalk Phase 1, maintained a one-to-one mapping between network numbers and subnets. In other words, each network number identified only one subnet, and each subnet had only one network number. Also, AppleTalk Phase 1 reserved two node IDs. This combination of a one-byte node ID, a one-to-one mapping between network number and subnet, and two reserved addresses limited the number of nodes per subnet to 254.
In the early days of AppleTalk networking few companies needed more than 254 nodes on a single subnet, but over time this limit became a serious obstacle. AppleTalk Phase 2, released in 1989, avoids the problem in an unusual way: it maps a "range" of unique, consecutive network numbers to each subnet. If you need to support more nodes on one subnet than one network number alone can identify, you simply assign the subnet multiple network numbers.
AppleTalk Phase 2 reserves three node IDs, so it supports 253 nodes for every network number you assign to the subnet. For example, if you need support for up to 253 nodes you assign that subnet a range of only one network number; if you need support for up to up to 506 nodes you assign the subnet a range of two numbers, and so on.
AppleTalk network numbers are two-byte values, so you have over 65,000 network numbers to choose from. Few organizations have 65,000 AppleTalk devices, much less 65,000 subnets with AppleTalk devices, so assigning multiple network numbers to some or all subnets is rarely a problem.
An AppleTalk node cannot communicate with other nodes until it obtains a valid network number and node ID. The node must also learn its subnet's network range. Nodes obtain this information from the network's routers, which must know network range assignments in order to route frames between subnets. At boot time, the node broadcasts a message to its subnet's routers, and one of those routers replies with the subnet's network range. The node picks a network number within that range and picks an unused node ID.
Each router has to know the network range of each subnet it is connected to, at least one path to each subnet on the network, and the network range assigned to each subnet. Each routers keeps track of paths and network ranges in its routing table. Manually entering the complete table into each router would be extremely time-consuming and error-prone. Instead, the administrator pre-configures the routing table of at least one router on each subnet to know that subnet's network range. These routers are called "seed routers." At boot time each seed router broadcasts its "seed ranges" to each of its subnets. Non-seed routers on these subnets receive this information and add it to their routing tables, and every 10 seconds each router (seed router or otherwise) rebroadcasts its entire routing table to each of its subnets. Eventually each router learns at least one path to each subnet on the network.
A router attached to multiple subnets might seed none, one, some, or all of those subnets.
Two or more routers can seed the same subnet, as long as they both seed it with identical network range information. This provides fault tolerance by keeping one router ready as a backup in case the other router fails.
In addition to managing network ranges, seed routers also create and manage sets of network nodes called zones. A zone can include nodes from different subnets. Each subnet has a default zone. When a node boots and contacts a router for network range information, the reply also includes the name of the subnet's default zone.
Zones are similar to Windows NT domains in three ways: both are logical groupings of computers; people use these groupings to quickly find information on the network; and a computer can belong to only one of these groups at a time. Unlike domains, zones are voluntary associations: a user can make a node leave one zone to join another at any time.
For example, you could create a Publishing zone that contains all of the Macintosh computers used by your company's desktop publishing staff, even if those computers are spread over several subnets. An Accounting zone could contain all the computers owned by the accounting staff. If most of the nodes on a particular subnet are used by the publishing staff, the administrator might make Publishing that subnet's default zone, but if someone from the accounting staff joins this subnet, they may choose to join the Accounting zone instead.
Suppose you have a network with six subnets and six routers:
Figure 1: Example network with six subnets and six routers
It pays to plan network range assignments in advance, as can be seen in the numbering schemes below.
Subnets A, B, E, and F each have far fewer than 253 nodes, so unless you expect considerable growth on these subnets there is no need to assign them more than one network number each. Subnet C has fewer than 253 nodes, and subnet D has fewer than 506 nodes, so you can assign C one network number and D two network numbers. For example
| A | B | C | D | E | F | |
| Range | 1-1 | 2-2 | 3-3 | 4-5 | 6-6 | 7-7 |
However, subnet C has only three unused node IDs, and any significant growth on this subnet will force you to renumber. When that happens, two renumbering options would be:
| A | B | C | D | E | F | |
| Range | 1-1 | 2-2 | 3-4 | 5-6 | 7-7 | 8-8 |
| Range | 1-1 | 2-2 | 8-8 | 4-5 | 6-6 | 7-7 |
To communicate, AppleTalk nodes need a network number and range, and nodes reevaluate these when AppleTalk is stopped and restarted, which generally means rebooting the node. To shut off any router or node connected to a subnet you renumber, in the two examples above, you would have to reboot 660 nodes in the top example and 250 in the bottom one.
You can avoid these problems if subnet numbering allows for growth:
| A | B | C | D | E | F | |
| Range | 10-10 | 20-20 | 30-31 | 40-41 | 50-50 | 60-60 |
Each subnet must have at least one seed router. Router 1 must seed subnet A, router 2 must seed subnet B, router 4 must seed subnet E, and router 6 must seed subnet F, because these routers are the only ones connected to their subnets. Routers 1, 3, and 4 are candidates for seeding subnet C, and routers 2, 3, and 5 are candidates for seeding subnet D.
There can be more than one seed router on a subnet. For example, router 1 and router 3 could both seed subnet C, if both of them seed with identical network ranges.
A router might not seed any networks. For example, if router 2 seeds both subnets B and D, and router 1 seeds both subnets A and C, then router 3 does not need to seed either subnet C or D.
The previous information has been general, applying to dedicated hardware routers as well as to general-purpose computers running routing software (including Windows NT Server). This section describes the specifics of configuring Windows NT Server as an AppleTalk router.
Routing is a feature of Windows NT Server's Services for Macintosh (SFM). To install it, start Control Panel, Network, select Add Software, choose Services For Macintosh from the list, and select Continue. You can configure SFM when you install it and reconfigure it later by choosing Services for Macintosh from the Installed Network Software list in Control Panel, Network, and selecting Configure. In either case, you use this dialog:
Figure 2: Windows NT Server AppleTalk Configuration
Note that AppleTalk Routing is an option and selecting or deselecting it does not affect the Default Network and Desired Zone entries. In other words, a Windows NT Server computer running SFM can be a file or print server, or it can be a router, or it can be both at the same time. People sometimes misunderstand this and enable routing when it is not needed.
If you enable the AppleTalk Routing option then you can select the Advanced option, which produces a dialog similar to this:
Figure 3: Windows NT Server AppleTalk routing configuration
A Windows NT Server computer acting as an AppleTalk router is typically connected to several networks and you can choose different routing options for each of them, including whether you seed some or all of them.
If you enable the Seed this Network option, you must enter the beginning and ending network numbers that define the range you want to assign to this subnet. After entering network range information you can also manage zones with the buttons and fields in the dialog's Zone Information section.
The dialog in Figure 3 is designed for network media that support network ranges (such as Ethernet/EtherTalk and token ring/TokenTalk). LocalTalk does not support network ranges; if you select a network provided by a LocalTalk adapter, this dialog will accept only a single network number, not Start and End values.
The two most common seed router configuration errors are:
AppleTalk does not define "correct" router behavior when these conflicts occur, and different routers react to these conflicts differently. This section gives examples of these problems, and describes router reactions and client-side symptoms. These examples are based on the network diagrammed above, and introduce errors into this starting configuration:
| A | B | C | D | E | F | |
| Range | 10-10 | 20-20 | 30-31 | 40-41 | 50-50 | 60-60 |
An additional router that you boot on Subnet C seeds it with a range other than 30-31, such as 30-35.
Many hardware routers respond to this conflict by no longer routing any AppleTalk transmissions on the subnet containing the offending router.
Suppose routers 1, 3, and 4 behave this way. Nodes on Subnets A and E would no longer be able to communicate with nodes on any other subnet. Nodes on Subnets B, D, and F would still be able to communicate with each other, but none of them could communicate with Subnets A, C, or E.
Seed routers maintain lists of zones they know about. If the new router defines any zones, the nodes on Subnet C would start seeing those zones instead of the ones defined by the rest of the routers.
If routers 1, 3, and 4 were Windows NT Server computers running SFM, they would continue to function as usual even though there was evidence of a conflict.
If the new router is running Windows NT Server, it will identify a potential conflict when it boots, and, rather than seed the network with a conflicting range, it will adopt the range in use by the other routers (seeding subnet C with 30-31) and continue to use this range until its SFM service is restarted. In this way SFM avoids conflicts without disrupting the network.
However, even though SFM uses 30-31 to avoid a conflict, the next time SFM starts it will again try to seed the network with the values you entered in the routing dialog (namely, 30-35). SFM identifies that the value ranges conflict, but it cannot identify one as wrong, so it defaults to the information you entered in the routing dialog and tries seeding with that.
Suppose that a month later you turn off all of the routers and nodes for routine maintenance, after which you boot this new Windows NT Server router before you boot another seed router on subnet C. The Windows NT Server router will not be able to sense the potential conflict, and will seed subnet C with the range 30-35. If routers 1, 3, and 4 are running Windows NT Server, they will sense the conflict and use 30-35 instead of 30-31. Otherwise, if routers 1, 3, and 4 are designed to stop routing AppleTalk when they sense a conflict, they will stop routing AppleTalk.
This illustrates why seed router misconfiguration problems may not appear (or disappear) until you boot your seed routers in a particular order.
A node on subnet F is communicating with a node on subnet E. Routers "think" in terms of network numbers such as 50 and 60 instead of subnet names such as E and F, so router 6 needs to route requests from the subnet with a network range that includes network number 60 (subnet F) to whatever subnet has a range that includes network number 50 (subnet E). In this case, router 6 finds a path in its routing table that goes through router 5 and crosses three routers to get to subnet E. Now, suppose you boot Router 2 and have it (incorrectly) seed subnet B with a range that overlaps the range for subnet E (such as 50-50).
Router 2 informs the other routers that it has a direct connection to the subnet whose range is 50-50. The other routers assume that router 2 directly connects subnets E and D. Router 5 sees this as a shorter path to subnet B than the one through routers 3 and 4, so it starts routing frames that are destined for subnet E through router 2, and they, of course, never arrive on subnet E.
Typical symptoms of this problem include servers and zones that appear and disappear at random.
Windows NT Server behaves as described above.
Here are some recommendations that can help you avoid the problems most frequently reported to Microsoft Windows NT Server technical support:
The information above focuses on the theory of AppleTalk routing to clarify the Windows NT Server configuration options and to make routing problems easier to understand and avoid. The Windows NT Server documentation and TechNet provide information on implementing mixed networks with Windows NT Server.
The following Knowledge Base articles may be useful when planning or implementing Windows NT Server-based routing. You can search for related articles on TechNet using keywords such as "Windows NT Server," ("Services For Macintosh" or SFM), route, and seed.
Q105155 Explanation of Seed Router Roles in AppleTalk Internets
Q129039 Situations Not Requiring Seed Routing
Q108875 SFM Seed Routing and Seeding Devices
Q140008 Seed Routing Network Range Options Grayed Out with DEC FDDI
Q130000 Application Events 2000 & 3001 Appear While Monitoring SFM
Q128607 Macintosh Chooser Cannot See SFM Servers Using Compaq PCI NIC
Q122799 Err Msg: Unable to Find Seed Router w/COPS LTI Appletalk NIC
Services for Macintosh Administrator's Guide (supplied with Windows NT Server)
Services for Macintosh online Help
Inside AppleTalk, Second Edition, by Gursharan S. Sidhu, Richard F. Andrews, Alan B. Oppenheimer, Apple Computer, Inc., 1990.
Microsoft TechNet
Volume 4, Issue 3
March 1996
 |
Click Here to Search TechNet Web Contents | TechNet CD Overview | |
Microsoft TechNet Credit Card Order Form At this time we can only support electronic orders in the US and Canada. International ordering information. |
| Go To TechNet Home Page |
©1996 Microsoft Corporation |  Go To Microsoft Home Page |