The classic film Casablanca must surely be high on everyone's list of all-time favorites. So what does that have to do with your upgrade efforts, you ask? Think of it this wayóthose efforts do bear a resemblance to the film's plot. For instance, in both, several entities, whether LANs or individuals, must get together. If the LANs are of dissimilar types, there's a translation problem that rivals anything Rick's multi-lingual bartenders ever dealt with. And as if that isn't enough, there may even be a need to span the globe with your messageóthat is, talk to a WAN. You're definitely in the same boat (airplane?) as was Victor Laszlo, another of the film's major characters.
There's one critical difference, of course. Instead of trading jewels or secrets for passports or plane tickets, you, as a network manager, must examine and decide between components whose job it is to connect networks or portions of networks.
There are several such devices available. What distinguishes each from the other members of the group is the OSI level at which the particular mechanism can function.
Repeaters and bridges, discussed in chapter 14, deal with the data link and network layers of the OSI model respectively. Repeaters offer the simplest means of interconnection. All they do is boost or regenerate a signal, thereby extending the physical distance that a network may traverse. Bridges, on the other hand, connect networks rather than simply extend them. Bridges, like repeaters, are hardware devices. But bridges also differ from repeaters. Bridges can link networks that have some differences at the physical or data link layers. Connecting a broadband and baseband network is one example of using a bridge.
Neither of these types of components needs to have sophisticated software or a great deal of memory. When all you're doing is in effect passing a signal with no concern for its format, your methods don't need to be fancy.
Routers, however, are a different animal altogether from either repeaters or bridges. Routers make the connection between networks at the OSI transport layer. Recall from chapter 3, "The OSI Model: Bringing Order to Chaos," that the transport layer is where networks begin to operate in a more encompassing way. The transport layer handles tasks that are by definition critical to internetworking:
On top of everything else that the transport layer must deal with, it is at once concierge, traffic cop, and native guide of and between networks. That is why routers must be so much more sophisticated than their interconnectivity predecessors.
Routers can connect networks that are dissimilar at the physical, data link, and network layers. However, routers cannot join networks that are dissimilar above the transport layer.
A router decides whether to forward a packet after it looks at that packet's protocol level (for example, TCP/IP or IPX/SPX) addresses; it ignores the MAC address. Routers, since they operate strictly at OSI level three, can also ignore differences in transport channels. Ethernet, FDDI, ISDN, and more are all the same to these devices.
Each network interface on a router has its own unique IP address. The most important part of this address is what's properly called the destination address, but which to most of us is the same thing as IP addressóthat set of four decimal numbers, separated by periods, which completely describes the interface as a node within the network. And because the router as a whole has its own IP address, it can and does exchange information with other routers. Such conversations concern the state of the network, which paths are free, which nodes if any are down, and so on.
You'll probably have gathered from the discussion to this point that you may not need a router. The topology of your network and its configuration (type and number of hosts and nodes) and characteristics (volume of traffic, peak traffic periods) might be better served by a repeater, bridge, or gateway.
For instance, some bridges can route between different media. Therefore, a network which has both thinnet and fiber-optic segments but doesn't need to go from TCP/IP to FDDI could use a bridge that conforms to the Translation Bridging Standard.
Bridges have the additional advantage of being much less expensive than routers. They're simpler devices in every way and therefore much easier to install and fine-tune. Many are self-configuring. A bridge's simpler technology also means that it's usually more reliable than more complex components like routers and gateways; there's simply less to go wrong.
Another factor that must be considered when choosing an appropriate interconnectivity device is the nature of the upper layers of the OSI model as those layers are implemented across your network(s). If the configurations you need to connect differ at the session layer (perhaps in having different algorithms for mapping device names to network addresses), neither bridges nor routers will suffice. Likewise, if your networks use different software to control the presentation or access layers, thereby having different schemes for access to or execution of applications, either a router or a bridge is moot. In cases like these, you'll have to use a gateway.
Even more touchy is the idea of running bridges and routers in tandem. Bridges, being less discriminating devices, may forward packets that a router may not have the ability to translate. Certain devices, like some older DECnet routers, also present a problem because they have the same MAC address on all ports, introducing the possibility of further confusion on the part of their peer routers and any bridges that they must communicate with. If you can, avoid running bridges and routers in parallel.
At this point, a few examples of the use of routers are in order. A router can connect
Routers can ignore topologies and access protocols, unlike bridges. While bridges could handle the thinnet-to-10BaseT or thicknet-to-thinnet connections mentioned earlier, they could not translate the access protocols they found there. Bridges can be oblivious to access-level protocols, but the users in these two hypothetical configurations don't have that luxury.
On the other hand, routers need common ground at the upper layers of the OSI model, unlike gateways. That's why something like "connecting a Novell LAN to a mainframe" will never appear in a list like the previous one. Such environments have nothing in common at any OSI layer. Therefore, they would have to be connected by a gateway rather than a router.
A router is actually a pair of devices that can send, receive, and process network signals. A router's most frequent processing task is some form of protocol translation.
When a signal is forwarded to a router in preparation for being passed along to another network or segment, the signal is first stored and then translated so that its protocols are recognizable to the destination. Only then do the packets move to that other side.
Routers go beyond simple store/translate/forward devices, however. Most routers seek the optimum path to transmit data. They keep one ear glued to the networks or subnetworks that they connect, listening for bad segments or faulty nodes. They use such information in directing packets to avoid obstacles. Some of the more complex routers can even "hear" traffic jams on the nets or segments they service. Combining this input with their ability to reroute allows such devices to do what is called load balancing. That is, these high-end routers can redirect network traffic so that gridlock is not only prevented, but precluded. With load balancing, packets are routed so that no network segment carries too heavy a traffic burden.
Routers can operate over a variety of lines, including leased lines as well as the partially dialup ISDN lines that, because of their lower costs, are increasingly popular. Routers, regardless of the type of channel that they must talk across, all do the following:
In accomplishing this last point, routers use yet another type of specialized software called routing protocols. Beyond pushing packets out of a router's front door, routing protocols have another, very important responsibility. They handle the distribution, among routers on a given network, of the information regarding network conditions exchanged between those routers. That is, routing protocols decide
Under some of the older routing algorithms, every node on a network had complete knowledge about every other node and each path in that network. Such a scenario requires that each node, including every router, also have a whale of a CPU as well as serious RAM. Remember, we're talking about individual packets of data hereóevery time a single one is transmitted, a router using this methodology has to search a table containing every detail of network addressing and status.
More recently developed routing protocols distribute network status information among routers. Among these are the Open Shortest Path First (OSPF) routing protocol, developed out of a standard of the ISO, and the Interior Gateway Routing Protocol(IGRP), developed in the mid-1980s by Cisco Systems, one of the major manufacturers of interconnectivity hardware. Both OSPF and IGRP can handle larger and more complex networks than can some of the older routing protocols. IGRP, for example, had built into it from the earliest design stages the ability to handle a variety of bandwidth and delay characteristics.
Take a glance at the following table for a summary of the most widely-used routing protocols. Then we'll discuss each in more detail.
| Acronym | Full Name | Used with... |
| BGP | Border Gateway Protocol | TCP/IP |
| EGP | Exterior Gateway Protocol | TCP/IP |
| IGRP | Interior Gateway Routing Protocol | TCP/IP |
| ISñIS | Intermediate System to Intermediate System | TCP/IP |
| NLSP | NetWare Link Services Protocol | IPX/SPX |
| OSPF | Open Shortest Path First | TCP/IP |
| RIP | Routing Information Protocol | TCP/IP |
| RTMP | Routing Table Maintenance Protocol | AppleTalk |
The Border Gateway Protocol (BGP) carries out interdomain routing. BGP can guarantee transmissions free of loopbacksóthat is, when packets circle round and round within a closed path. With each trip through the loop, a counter is incremented. If that counter reaches the maximum allowed value for the protocol in use, a problem with the path or the message itself is assumed, further efforts to deliver the packet are dropped, and the packet itself is discarded.
BGP functions between what are called autonomous systems. Autonomous systems are defined as a set of gateways under a single administrative control. Note that phrase "a set of gateways;" this isn't the same as a set of networks or network segments. For instance, a set of devices might connect the components of a campus network, while another set might connect that network to a regional network. Each of these sets of switches, not the networks with which it deals, comprises an autonomous sytem.
BGP works with the following information:
The Exterior Gateway Protocol (EGP) is used for communicating with routers in a number of governmental networks. In the Defense Data Network (DDN) of the Department of Defense, EGP talks to specific routersóthose that have been designated as critical devices.
EGP has also been used to connect to other large backbone networks within the federal government, such as the National Science Foundation Network (NSFnet).
IGRP allows the user to configure many of its operating characteristics, such as bandwidth, internetwork delays, and loads. It recognizes the following three types of routes:
ISñIS, the intermediate system to intermediate system protocol, is actually a specification of ISO for a dynamic routing protocolóthat is, one that can re-route on the fly to bypass obstacles or find optimum paths. A number of vendors have implemented ISñIS in such a way as to make it available as an IP routing protocol.
The Sequenced Packet Exchange Protocol (SPX) makes diagnostic and management functions available to the station running it. SPX operates at the OSI network layer and has some of the abilities usually found in session layer protocols. But SPX cannot initiate a connection. That is why SPX needs the Internetwork Packet Exchange Protocol (IPX) to be up and running. IPX is a transport layer protocol that handles the addressing and routing every network conversation requires.
But neither IPX nor SPX can function outside a single network. To fill this need, the NetWare Link Services Protocol (NLSP) was developed by Novell to accomplish the interconnection of IPX/SPX LANs.
OSPF is designed expressly for IP networks. It supports subnets, as well as the tracking of externally-supplied routing information. OSPF uses IP multicasting as its transmission method. OSPF, one of the most widely-used routing protocols, can
So you can see that any router running OSPF can send data within network segments or subnetworks, between such structures, and beyond to other such constructs, WANs, or other large networks.
OSPF can also be configured to operate without packet authentication and with connections only to specified environments. It even offers virtual linksóa means by which breaks in a backbone (either physical or caused by routing problems) or backbones that have been segmented can be bypassed through the use of border routers.
RIP, the Routing Information Protocol, is one of the oldest routing schemes. It is based on an even older protocol, the Xerox Network System (XNS) but adapts that software for use in an IP environment. RIP is still widely used, however. Probably one reason for its continuing viability is that it was designed for small, homogenous environments.
RIP broadcasts packets every 30 seconds as a means of exchanging and keeping up-to-date routing information between routers. This process, common to all routing protocols, is called advertising.
If a router that relies on RIP doesn't receive an ad from one of its peer routers for a period of 180 seconds, it assumes that any routes served by its tardy co-worker are no longer useable. Should the silence extend to 240 seconds or more, the router erases all routing table entries that pertain to its uncommunicative partner.
A routing table is a file, maintained within a router and also on at least one of the hosts that it serves, which contains entries for all nodes on a network that packets must be directed to, and the router or gateway through which the data may pass. A line from a routing table might look like the following:
127.0.0.3 128.6.4.6
The first of these IP addresses is that of a workstation; the second represents the router through which any packets requested by or intended for that station can travel.
In addition to being designed with the assumption that it will run in small to medium networks that contain little diversity of hardware or software, RIP has other constraints built into it. These include
For these and other reasons, some vendors provide their own modifications to RIP to allow it, for example, to go beyond a path length of 15.
AppleTalk has its own routing protocol, called the Routing Table Maintenance Protocol (RTMP). RTMP helps provide end-to-end connectivity between internetworked AppleTalk nodes. In other words, it does within an AppleTalk network or subnetwork the same thing that, for example, OSPF does in TCP/IP environments, keeping track of paths, addresses, and the best routes between and among those.
There's one more piece of internal router software that you should know about. It's called the Internet Control Message Protocol (ICMP). It's ICMP's job to handle re-directsóthose instances when a router must, on the fly, send a packet along a different, faster route than that originally designated for it.
Now that we've got a basic understanding of how routers do their jobs, let's turn to the physical characteristics that any router you consider should include.
You should be able to control a router in a number of ways:
A device that offers less flexibility than this in management probably won't stand up to the day-to-day variations in situations encountered by and problems posed to the average network administrator.
Your router should be modular. If there is one constant in data processing, it's the rapidity with which things change. Both network software and network hardware can be expected to continue to evolve at rates as fast or faster than we've become accustomed to. This being the case, a router's design which is based on modules (for example, a CPU or NIC) that can be quickly and easily swapped in and out can be a welcome island of stability in an ocean of seeming network chaos.
Any router worth its salt must have a processor powerful enough to deliver packets to a network at the highest speed that the network's cable is capable of. In today's terms, that means that any router you consider should run at a minimum of 14,400 Kbps. And as for NICs, a reputable router should offer connections to as many types of wire as possible. At the very least, Ethernet, FDDI, and token-ring connections should be available.
All the processing power in the world will do little good if a router's onboard memory isn't also up to the job. As the case with the CPU, make sure that any router you consider has enough RAM to sling data at a minimum speed of 14,400 Kbps.
Routers' RAM typically ranges from 2M in small models, such as a wire-speed segment router, to 8M in devices, such as a high-speed wide area router. Memory requirements are also affected by upgrades to router software. While such upgrades don't necessarily require additional memory, failing to provide it (to device or host, or both) can cause degrdation of performance.
Acting as an interpreter is one of a router's most important reasons for being. At a minimum, a good router should be able to handle AppleTalk, IPX/SPX, and TCP/IP. Adding DECnet, VINES, and X.25 to the kitty wouldn't hurt.
TCP/IP environments often include a number of routing protocols. For example, such an environment might include an older segment that uses RIP and a more recent one that employs OSPF. So don't think you're covered if the router you're considering speaks only one routing protocol. At a minimum, a truly flexible router should offer not only that routing protocol but also NLSP, RIP, and RTMP.
Some network software doesn't handle delays gracefully. NetBEUI is a prime example. NetBEUI is actually NETBEUI.COM, a terminate-and-stay-resident (TSR) utility that is the immediate predecesor of NetBIOS, IBM's transport layer protocol. Precisely because it is implemented as a TSR, NetBEUI, now largely obsolete, is prone to timeouts.
A router's ability or lack thereof to prioritize its handling of packets can have an enormous effect on the number of such errors a network produces, which you have to resolve. As important as the protocols it translates and the ways in which it decides upon routes is a router's ability to prioritize tasks.
In evaluating the performance of routers, always keep in mind that different vendors use different measurements to describe the throughput of their products. While all are more than happy to talk about packets per second, vendors don't all mean the same thing when they use that phrase. Most count a packet only once as it goes through a router; some few, however, count such packets twice, presumably operating under the premise that it is both leaving its source and going on its way to a destination. In any case, it's clear that routers described in these terms have a hidden, unfair advantage over some of their competitors.
Any comparison of routers should also determine what size of packet each router deals with. Fortunately, there is a formula that such imbalanced presentations of router characteristics can be evened out.
ï Throughput=Switching Time+(Packet Size x Time per Byte)
Look at this formula a litle more closely. It says, for one thing, that the time normally needed to switch a packet is a constant, made up of factors like interrupt frequency, header processing, routing table lookup time needed, and so on. Also, the throughput formula claims that there is a component to throughput that is proportional to packet size and that represents the time needed to copy a packet before translating it.
Using this formula can be of some help in comparing routers whose vendors use differing yardsticks in measuring their products' performance. Another way of making sense of such comparisons is to obtain throughput statistics for different-size packets, perhaps of a minimum, middle, and maximum size. Or you could look for two different statisticsóswitching speed given in packets per second and throughput represented as bytes per second.
As an additional check on how a router is doing, you might consider using one of the host-resident software modules, available for most of the popular routing protocols, that tap in on inter-router conversations. Such software maintains a complete picture of the up-to-the-nanosecond condition of your networkójust like the data that routers share amongst themselves, except that it's accessible from the host.
Quite a few things shouldn't happen on a network. But you can wager a sizeable wad of cash that sooner or later they will. So any router you're considering should have mechanisms or algorithms for preventing or at least dealing with the following.
Those methods typically will be part of the job of the routing protocol. For instance, BGP maintains a table on the physical status of every segment that it deals with.
Go over the documentation for your router candidates with a fine-tooth comb or simply ask the manufacturer or your retailer specific questions to determine how the routing protocols supported by any router you're considering handle these problems.
A short in a cable, a power surge, or drop-off can distort a signal on a line. Also, the way and frequency with which network cabling is maintained can affect its integrity.
An ailing transceiver can generate signals that are healthy electronically but a bit peaked in other ways. For instance, a packet might refuse to relinquish the channel. Another might be infinitely long. Still another might cause or misinterpret collisions. While such problems aren't common, they can hobble communications at large and routers in particular.
Some routing software can sabotage itself by producing errors that then in turn produce random, undue traffic on certain paths in a network. Be sure any router you consider can isolate and report such errors.
An important subset of network planning and design is traffic planning. A properly planned network should never, in theory, experience overloads. But networks, like any other construct, can get out of hand or can be asked to do more than they were originally intended to do. A router that can perform load balancing as a means of optimizing transmission times can isolate overloads and work around them.
Just as you meticulously planned your network's configuration as a whole, you should give close scrutiny to what you want your routers to do and where you expect them to do it.
The discussion of routing protocols earlier in this chapter indicated an important fact of networking life. Few real standards exist for routers. This lack of a solid means of comparison of competing devices added with the continually growing role routers play in allowing dissimilar networks to communicate makes router modeling even more important. When you consider the cost of networking hardware and the investment of time that installing and fine-tuning it represents, having a reasonable idea up front of how routers can be expected to perform in your environment is only a little short of critical.
By constructing scenarios and comparing router performances in such circumstances, you can be assured of buying the right routers and the right number of routers. And you can do more. You can design routing paths and allow for alternatives. You can estimate the effects that varying levels of traffic will have on router performance. You can evaluate throughput and translation time. You can even plan ahead for router failure. In short, simulations will allow you to introduce just the right routers into your environment.
In constructing the model against which you will evaluate the router candidates you're considering, be sure to include parameters that reflect the realities of your network. For instance, you might want to map out the network as it currently is configured, marking overall traffic volumes along paths. Include figures for acceptable end-to-end delays for applications. It is also helpful to indicate the nature of the packets that usually travel between specific nodes. That is, mark on your network map whether paths carry TCP/IP traffic, IPX/SPX, or AppleTalk. Mark packet sizes as well, and make sure to include a wide variety. One simulation recently published on the Internet suggests using packet lengths of 64, 80, 100, 120, 150, and 300 bytes. What's more, this same study recommended raising packet frequency figures in an inverse relation to packet size. In other words, your simulation should include the presumption that smaller packets are delivered at a higher rate than larger ones. This is not only the most common real-world case but also reflects an important source of stress upon routersóthe frequent arrival of small packets, each of which must be stored, translated, and forwarded.
Having constructed your scenario in this way, proceed to evaluate routers against it. Compare more factors than throughput. For one thing, be sure to look at the delays that different routers engender when faced with
You'll probably find that some routers' behaviors are nearly indistinguishable under these conditions while other performance characteristics vary widely. Of course, any factor that is particularly representative of your network should outweigh even several of those that do not as clearly reflect it.
***
Keep in mind that in the real world, the bulk of network traffic consists of packets in the 60-, 80-, 100-byte range. So whatever other traits your network has, the ability of a router to quickly process heavy streams of small packets is something to keep a sharp eye on.
***
This section presents a scenario/simulation like that just described.
Desktop Data, a growing (but fictitious) desktop publishing firm, has a mixed-protocol networking environment. The MIS and Research departments run a Novell LAN. Art and Advertising (A/A), on the other hand, relies on a small network of Macs and PowerMacs. Technical Writing and Editing (TW/E) relies on a mixed bag of UNIX workstations and high-end PCs running xterm emulators, held together by TCP/IP.
The writers and editors frequently complain that the response times they encounter are
Artists, researchers, and administrators, on the other hand, are satisfied with the overall performance they encounter.
You, as network administrator, are faced with the task of reconciling these conflicting expectations. You have two goals in mind:
You start by drawing the layout of the network. You accurately represent the length of each of the thinnet segments that make up Desktop Data's network architecture. You place Desktop Data's two servers (MIS/Research and TW/E jointly use the same Sun SPARCStation as a server, while A/A's server is a SuperMac) at the points on your map that correspond to the actual locations of those machines. Next, you monitor traffic on each segment over the course of several days, noting not only volumes but also patterns in usage. For example, you realize that, despite the fact that each of the subnets in question has, on the average, five active users at any given point, TW/E places a heavier demand on its server than do the other departments. Its five users generate an average of 17 application requests per minute to the server, while A/A and MIS make 12 and nine respectively. Since any single request to a server produces about 85 Kbps in network traffic, it appears that TW/E has a legitimate cause for complaint. At this point, you feel you have located the problem. Your current router cannot forward packets fast enough to handle the 17 requests per minute that are intended for the TCP/IP and Novell server. Its buffers fill up too quickly. Packet throughput on this segment starts to fall off when as few as four users are active. Your current router is not configured to prioritize requests; you reason that this inability might be contributing to the situation.
Your next step is to use the data you've compiled in a new equationóone into which you introduce statistics on routers that do offer job prioritization. You look at three such devices, plugging each of them into your scenario. In addition, you adjust the scenario to reflect the performance of your current router, with two enhancements:
Having made these adjustments, you discover that modifying your current router's setup in this way is sufficient to clear up the problems TW/E had been experiencing. As important, no significant degradation of response time for your Novell users is to be expected. Only if five writers and editors and four administrators simultaneously access the server they share will the latter group experience any appreciable drop in response time.
As a network administrator, you've hit a grand slam. You've cleared up a thorny problem without spending additional money or the time needed to install and configure a significant new network component.
The Desktop Data scenario is an illustration of only a few of the issues involved in router management. Such administration also involves
Let's break some of the items in this this task list down a little further.
First-time setup of a router is so extensive as to appear to deserve its own chapter in this book. Since Upgrading and Repairing Networks is already a hefty volume, we'll content ourselves with looking at a synopsis of a real-world router configuration.
Cisco Systems specifies the following tasks as belonging to the initial setup of one of its devices.
To properly define all the connections to a router, you must take into account
The following table summarizes the most common interfaces, as well as factors that a router may need to know about them:
Interface Characteristics
ISDN basic rate Switch type?
Service profile
Caller screening?
Ethernet Tunneling?
FDDI Timing parameters
Duplicate address checking?
Asynchronous serial PPP or SLIP?
Synchronous serial Transmit delays
Module timing
Data compression rates
Token ring Token-ring speed
Early release of tokens
Most of the router configuration parameters shown in this table are self-descriptive. One, however, may need some explanation.
Tunneling is a situation where a packet may travel through a router other than the default device that ordinarily handles it to arrive at its destination (see fig. 15.1).
If you anticipate remote access via modem to your network through the router you're configuring, you must, in addition to the interfaces described in the previous table, define the nature of the dialup interface to your router. (We didn't include dialup in the previous table only because this interface has enough parameters for a table all its own.)
In defining a dialup interface on a router, you have to specify quite a few parameters. For example, configuring a dialup connection to a Cisco router requires information on, among other things:
And that's not all. This information must be supplied for every dialup connection you are installing.
Whether to use an internal or external router is another question to be considered during router planning.
Novell is one networking environment in which there is a choice between a router that exists as a separate physical entity or a router that is internal to a file server. Internal routers are recommended only for small LANs to connect dissimilar cabling. For instance, the NetWare 3.1.1 System Administrator's Guide presents internal routers in the three configurations shown in figures 15.2, 15.3, and 15.4.
Figure 15.2 An Internal router might be needed on an Ethernet Novell Network.
Figure 15.3 An Internal router connecting Ethernet 802.3 and 10BaseT segments of a Novell Network.
Figure 15.4 An Internal router connecting ARCnet and Ethernet segments of a Novell Network.
Keep in mind that all these scenarios involve connecting Novell LANs. None of the LANs in question are large. Since all are by definition IPX/SPX networks, no extensive protocol conversion is needed; at most, addressing structures must be translated from, for example, Ethernet to ARCnet.
In such a situation, an internal router is a feasible alternative. But in most environments that require a router in the first place, this kind of simplicity is only a dream. In the real world, protocols must be converted, network loads balanced, transmissions prioritized, and so on. Unless your environment is as streamlined as those in the previous figures, an internal router isn't an answer.
As the last stop on our cook's tour of router planning, configuration, and management, let's take a look at some points which can affect real-world router configuration.
***
In setting up your router to handle all the protocol types described in the following sections, the basic tasks you must carry out are
While only the first of these is actually required, all are strongly recommended.
***
AppleTalk can run over Ethernet, token-ring, or FDDI channels, as well as on Apple's proprietary twisted-pair access system called LocalTalk.
The name AppleTalk is actually a catch-all reference to a number of flavors of a protocol suite. Apple talks as summarized in the following table below.
| This "Talk"... | ...Talks Over |
| EtherTalk | Ethernet |
| FDDITalk | FDDI |
| LocalTalk | Apple twisted pair |
| TokenTalk | Token Ring |
Whatever dialect of AppleTalk you're dealing with, you'll find it contains a number of related protocols:
ARP, DDP, and RTMP accomplish end-to-end connectivity between internetworked nodesóthat is, between nodes existing on separate AppleTalk networks. NBP and ZIP keep track of node name and location information. AEP is a reachability-tester, analogous to the PING command. ATP is AppleTalk's transport protocol.
VINES is derived from the XNS protocol. It uses 48-bit addresses that are made up of a network number and a host number. The network number pertains to a VINES logical network, defined as a single server and a group of nodes. This first portion of a VINES address is 32 bits long. The host number takes up the remaining 16 bits of the address. For client nodes, it must be in the range 0x8001 through 0xFFFE.
VINES has a number of parameters that must be defined to your router. These include
Static is a term applied to routes and paths that cannot be altered. For instance, if you wanted messages from Node A to travel only via Router B along thinnet C, you have to define a static path to bring that about.
DECnet recognizes levels of routers. So, in addition to the three basic configuration tasks, setting up your router to talk to DECnet means identifying those levels that it can occupy. In conjunction with setting up router levels, you will probably need to define areas of the DECnet that cannot be reached by a router at the level in question.
IP configuration involves not only to-be-expected tasks like assigning addressing but also ones such as defining alternative schemes for address resolution, enabling or disabling DNS, defining how broadcast packets are handled, enabling or disabling the receipt of protocol unreachable and similar administrative messages, setting up an audit trail, and so on. Of course, IP configuration on any router must begin with the big three. But it will extend to less common actions like those just described and to configuring individual routing protocols. When one considers just how many of these there are in a TCP/IP environment, IP configuration can be seen for the weighty job it is.
The Internetwork Packet Exchange protocol, or IPX, is the communications tool through which Novell networks establish, monitor, and drop connections. IPX assigns addresses and routes to outgoing data messages and reads the addresses of incoming messages to direct them to the appropriate destination.
Because NetWare was intended from the start to act as a network operating system (rather than a suite of protocols interacting with a classic operating system), IPX is more closely linked to other portions of NetWare than, for example, TCP/IP is to UNIX. As an example, IPX does not handle the preparation of data packets for transmission. Before packets are handed off to it, they are assembled and formatted by the NetWare shell itself. Once in the hands of IPX, the data packet is forwarded partially through the services of a LAN driver that controls the NIC.
This closer relationship presents a few wrinkles of router configuration that are unique to Novell. You may, for example, need to distinguish between interfaces to Novell networks that can support a single LAN and those through which access to several LANs are possible. Or you might have to create filters to shield your router from some of NetWare's default broadcasts.
More detail on router makeup, operation, and planning is out there, but when you move beyond the points we've discussed, you enter vendor-specific territory. So let's turn instead to some personality profiles for routers that would make excellent additions to any network. Each of the six routers outlined in the following sections also meet the more general criteria for router selection stated earlier in this chapter. Each is an external, dedicated router.
First, we'll look at specifications for four wide area routers. Then we'll examine two local area devices. Also, be aware that each of these two groups contain routers that might serve as "upgrades" for some of the less powerful members of the same group. So if your current router isn't performing like it used to, the following sections may suggest alternatives.
(d)A High-Speed, Multi-Port Wide Area Router
ôB7 Management: Windows, Macintosh, Telnet, or SNMP
The perfect router should be accompanied, at no extra cost to you, by management software and a support agreement that make your job as network administrator at least a bit easier. Both software and support are sketched out in the following sections.
The availability of the following items is typical of data processing support agreements. One-year warranties are the norm; routers that offer extended warranties are usually high-end, high-cost devices. Software updates, telephone technical support, and replacement of defective components, on the other hand, are widely offered, particularly because no licensing questions apply here.
As one example of router monitoring software, take a look at a product called RouterCheck.
RouterCheck is an AppleTalk router monitoring tool that profiles individual routers, reporting on router location and configuration. RouterCheck looks for inconsistencies in that configuration, and reports these as well, along with recommended corrective actions for each. RouterCheck can run from any version 6.0 or later Macintosh machine, within the network or across the Internet. Similarly, RouterCheck keeps tabs on any AppleTalk router, whether local or long-distance.
This management software package can report the following for every router that it is aware of:
Information compiled by RouterCheck can be displayed in its entirety or in selected subsets.
If, after studiously reading everything in this chapter, you still haven't found quite the right answer to your routing problems, take heart! The last word on routers is thisóyou may not need one.
No, this isn't a return to the discussion of the difference between routers, bridges, and repeaters. It's a new topic altogetherórouting that is accomplished strictly through software.
The most recent development in this area is the introduction by Microsoft Corporation of what is called the MPR Service for Windows NT. The Multi-Protocol Routing Service (MPR) offers a low-cost LAN-LAN routing mechanism, eliminating the need for a dedicated router. It also facilitates migration from NetWare to Windows NT, by replacing NetWare-based LAN-LAN routers with Windows NT Server.
Windows NT Server, even before the addition of MPR, provided routing support for remote connection to a Windows NT LAN, as well as LAN-LAN routing support for connection to AppleTalk networks. With the addition of MPR, that LAN-LAN routing support has been enhanced to include TCP/IP and IPX/SPX networks. When used with appropriate additional NICs, MPR will also enable the connection of Windows NT LANs to WANs.
Let's wrap up this chapter with a router quick reference in the form of a table summarizing the most important characteristics of routers and the features that a good router should offer.
| Trait | Needed or Just Nice? | Acceptable Minimum |
| Load-balancing | Nice | N/A |
| CPU | Needed | Powerful enough to transmit at 14,400 Kbps |
| RAM | Needed | Powerful enough to transmit at 14,400 Kbps |
| Protocols translated | Needed | AppleTalk, IPX/SPX, TCP/IP |
| Routing protocols | Needed | NLSP, OSPF, RIP, RTMP |
| Cabling supported | Needed | Ethernet, FDDI, ISDN, token ring |
| Ports | Needed | At least one Ethernet and one WAN port |
| Management software | Needed | At no extra charge and should provide the ability to view all or selected subsets of router information. That information should include packet counts and error counts. |
| Support | Needed | At no extra charge, unlimited phone support. |
