185
Figure 7-2. IPX network design with RIP and SAP accumulation zone
The user-area routers distribute RIP and SAP information inward to this redundant pair of routers. In the center of the picture is an Ethernet segment that I call the Accumulation Zone. Each router that is
connected to this Accumulation Zone shares all of the RIP and SAP information that it receives with this segment. Note that this information need not be collected using either the RIP or SAP protocols. This
model works equally well for any dynamic routing protocol.
Then RIP and SAP information is distributed back out to the user areas by the Accumulation Zone routers. Note that none of these routers actually needs to have the entire route or SAP tables. Rather, they can all
just dump their tables onto this central segment for others to use as required. They can also take in only those routes and SAPs that they themselves require.
The advantage to this approach is that a central point in the network has all the RIP and SAP information that anybody could ever need. At the same time, though, keeping track of this information doesnt
overwhelm any device.
Suppose there is a sudden requirement for a user in one user area to have access to a particular server in another area. Then you can simply allow its Accumulation Zone routers to receive and distribute this
information to that users own server. This provides maximum flexibility to managing the IPX network. At the same time, it avoids the most serious problems with having to support a large route or SAP table.
7.2.3 Efficiency in IPX Networks
I conclude this section with a brief discussion of other basic things you can do to improve efficiency in an IPX network.
I already mentioned the need to keep the number of SAPs to a bare minimum. This information can be gathered in an Accumulation Zone, as mentioned earlier. However, in a large IPX network, it can easily
overwhelm the memory and bandwidth resources of the network devices to maintain all of it. Thus, the first thing to do is to create a thorough list of filters to restrict what routes and services are advertised.
Another aspect of the same issue is limiting the amount of server-to-server traffic. Usually this sort of traffic is not necessary. You often need to allow communication between user-area servers and central
servers. However, you should try to keep this traffic flow in a star format as much as possible.
Finally, in any large IPX network, it is critical to avoid using RIP and SAP protocols. These protocols work well in small- to medium-sized networks. But remember that routers and servers must all take part in
the routing protocols. Suppose, for example, that two servers communicate via RIP, but are separated by
186
three routers. Then the internal network numbers of these servers are, in fact, five hops apart, so an IPX network is usually somewhat larger than it appears on the surface.
In even a moderate-sized network, it is not difficult to find distances that are greater than 15 hops, which is too large for RIP to handle. As I already mentioned, RIP and SAP scale rather poorly for bandwidth usage.
It is a good idea to try to move away from these protocols in any large-scale IPX network.
It is possible to make an IPX network appear smaller than it is, however, by tunneling the IPX traffic inside of IP. For example, suppose that getting from a user-area router to the central Accumulation Zone
requires several router-to-router hops. You can make it require a single hop by configuring an IPX tunnel between the Accumulation Zone router and the last user-area router before the server.
Even in this case, however, you should avoid using RIP and SAP. Although this design avoids the hop- count problem, you still have to be concerned about the bandwidth-usage problem with these protocols.
187
Chapter 8. Elements of Efficiency
Efficiency is a nebulous term. In general, it measures how thoroughly one manages to achieve some desired result as a function of the required resources. The biggest problems in implementing efficiency in a
computer network are essentially matters of definition. What is the desired result for a network, and what resources are actually required?
With a relatively narrow view of the desired results in network design, it essentially comes down to the factors that I mentioned earlier when talking about network reliability. The network must deliver data to
the destination. It must do so within the required application constraints. In most networks, the desired result is effectively quantified with just four parameters: latency, jitter, throughput, and dropped packets. I
will define these terms when I come to talk about Quality of Service later in this chapter.
The hard part of describing efficiency is actually in defining the resources. Which resources should the definition include? Some resources are obvious. Everybody would agree that its necessary to worry about
CPU and memory utilization in their routers. The same is true for the bandwidth utilization on the various links that connect network devices. But some resources are harder to quantify or harder to see. How do you
compare the relative importance of these resources? Do you want to save bandwidth, for example, at the expense of CPU load?
The ultimate resource for any organization comes down to money, and efficiency has to be defined for the entire organization. Suppose, for example, that you can save money by running a particular application on
a particular type of server. The money you save has to be balanced against the extra money it costs to upgrade parts of the network. Perhaps the new implementation will turn out to be more expensive overall
than the old way. But perhaps it will also allow the organization to win new business that will more than pay for the difference in cost. Doing such an upgrade is worthwhile for the organization. You just have to
understand where you are drawing the line around what resources to include. Conversely, the network engineer may look at a Core router and see abnormally high CPU and memory utilization. If fixing this
problem means spending hundreds of thousands of dollars, the organization may not feel that the expense is justified.
Ultimately, efficiency is a matter of the global economics of the organization. This subject, however, is far beyond the scope of this book. The resources that I can reasonably talk about here are the ones that are
specific to the network. I can discuss how to make the best use of the resources already in the network, so I look at the four parameters—latency, jitter, throughput, and dropped packets—that describe how well the
network works. I also look at network resources such as bandwidth, CPU, and memory utilization. It is never possible to obtain perfect efficiency, though. Therefore, a network designers most difficult job is to
decide what tradeoffs will give the best design possible under the circumstances and will fit in best with larger corporate goals.
8.1 Using Equipment Features Effectively
There are usually several ways to configure any given piece of network equipment to achieve the same basic result. These different configurations usually do not use resources in the same way, and they often do
not have exactly the same performance characteristics. For example, an inefficient configuration of a router might mean that it has to do too much processing on each packet. This extra processing increases the
amount of time that each packet spends inside the router and probably also increases the memory utilization of the router, as it has to buffer large numbers of packets.
A typical example of this increase happens when an engineer fails to use special features of the equipment. For example, in many routers the ability to make most common routing decisions is delegated to logic
circuits supporting the interface card. This approach works well because it means that the CPU is free to coordinate the activities of the different cards. The result is vastly improved net throughput; however, the
advantage can be completely lost if this engineer implements a CPU-bound process that examines the contents of every packet.
