#
Upgrading and Repairing Networks

# - 15 -

# Routers

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 multilingual 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.

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--Network Glue

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 extending 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 network and a 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

Routers, however, are a different animal altogether from repeaters and 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:

- Addressing
- Connect/disconnect protocols
- Packet management:
  - Error detection or correction
  - Routing

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.

> NOTE: 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 so on 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, 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 that 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.

> CAUTION: 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 with which they must communicate. 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

- A thinnet-based Novell LAN and a 10BaseT Banyan VINES network
- An Ethernet-UNIX environment to either a Novell LAN, 10BaseT Banyan VINES, or AppleTalk
- A thicknet backbone to several thinnet segments

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 a connection like 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.

## Routers in Pairs

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 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.

## The Anatomy of a Router

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 they must talk across, all do the following:

- Read a data packet
- Strip off the packet's protocols
- Replace the stripped-off information with the protocols the destination network or segment requires
- Add routing information
- Send the packet on its way to its recipient by the optimum path

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 the following:

- Which router needs to know about which routes and other routers
- How often to update this information

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, 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

BGP. The Border Gateway Protocol (BGP) carries out interdomain routing. BGP can guar- antee transmissions free of loopbacks--that is, when packets circle around and around 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 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 system.

BGP works with the following information:

- Route numbers (actually, each route number is a network number)
- A list of autonomous systems through which transmissions have passed, called the AS list
- A list of other characteristics of each transmission path

BGP concerns itself primarily with the reachability of the networks that it seeks to connect to.

EGP. 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. 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:

- Interior (routes between subnets in a single network)
- Exterior (routes to networks outside the autonomous system that the router running IGRP belongs to)
- System routes (routes to networks serviced by members of the same autonomous system as that which the router running IGRP belongs to)

IS-IS. 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 reroute 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.

NLSP. 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. 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

- Authenticate packets
- Talk to internal routers
- Talk to border routers (devices that connect to a number of subnets or segments)
- Talk to boundary routers (devices that comprise autonomous systems)

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. 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 coworker 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.

> NOTE: 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 the following:

- RIP cannot connect networks in which any path goes through more than 15 switches.
- RIP cannot share traffic between parallel lines.
- RIP cannot adapt to changes in network load--that is, it cannot perform load balancing.
- RIP cannot easily reroute packets across lines of noticeably different speeds.

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.

RTMP. 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.

ICMP. 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 redirects--those instances when a router must, on the fly, send a packet along a different, faster route than that originally designated for it.

### Identifying Physical Characteristics

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.

Manageability. You should be able to control a router in a number of ways:

- Directly by means of the Simple Network Management Protocol
- Remotely through a Telnet session
- Remotely through a modem

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.

Modularity. 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 as 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.

CPU and NIC. 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.

Memory. 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 was 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.

> NOTE: 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 degradation of performance.

Translation. 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 as possibilities wouldn't hurt.

Routing Protocols. 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.

### Prioritization

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.

### Comparing Performance

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, 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 so that such imbalanced presentations of router characteristics can be evened out.

Throughput=Switching Time+(Packet SizexTime per Byte) Look at this formula a little 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.

> NOTE: 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 among themselves, except that it's accessible from the host.

### Avoiding Pitfalls

Quite a few things shouldn't happen on a network, but you can wager 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.

> NOTE: These 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.

Electrical Faults. 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.

Transceiver and Controller Problems. 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.

Excessive Traffic Between Routers. Some routing software can sabotage itself by producing errors that in turn produce random, undue traffic on certain paths in a network. Be sure any router you consider can isolate and report such errors.

Traffic Overloads. 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.

## Router Planning

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 to 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 practically 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 allow you to introduce just the right routers into your environment.

## Network Role-Playing

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 recommends 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 the following:

- Frequently sent large packets (those of 120 bytes or more)
- Infrequently sent large packets interspersed with smaller packets
- A steady, heavy stream of small packets

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 those that do not as clearly reflect it.

> TIP: Keep in mind that in the real world, the bulk of network traffic consists of packets in the 60-, 80-, or 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.

### Desktop Data

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

- Inadequate in general
- Lagging during periods of heavy network activity in particular

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:

- Track down the causes of the delays that TW/E is experiencing and correct them in as cost-, time-, and labor-efficient a manner as possible.
- Do nothing, while making these corrections, to disturb the satisfactory performance that A/A and MIS have reported.

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 9 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:

- Priorities have been assigned to TCP/IP applications
- The router's memory has been reconfigured to work in tandem with this prioritization

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.

Router Management. The Desktop Data scenario is an illustration of only a few of the issues involved in router management. Such administration also involves

- Initial configuration: defining the router's address, name, and so on
- Setting up time and date services--for example, time zone
- Configuring SNMP: access control, trap operation, server shutdown conditions, and so on
- Security: setting up passwords and access to certain commands and perhaps encrypting passwords, and setting up user name authentication
- Fault control: the ability to display system statistics such as memory and stack utilization and error messages, and to test connectivity, memory, and interfaces
- Performance management: Configuring switching, queueing, and scheduling priorities, and the ability to modify buffer size

Let's break some of the items in this task list down a little further.

Initial Router Configuration. 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 settle for 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:

- Acquiring the new router's IP address
- Resolving the address--that is, associating it with a device name in the host
- Loading the router's configuration file
- Modifying the boot field in the router's configuration register
- Specifying the system image the router loads during a restart
- Specifying the configuration file the router loads during a restart
- Specifying buffer size for loading configuration files
- Enabling compression of configuration files
- Enabling manual load of a system image
- Enabling loads of system images from the network
- Defining whether and how the new router acts as a TFTP or RARP server

Router Interfaces. To properly define all the connections to a router, you must take into account the following:

- The categories of interfaces
- Any special characteristics supported by any of those categories

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).

Figure 15.1
Packets traveling from Router A to Router B take a default path. The same applies to packets moving between Routers B and C, but traffic between A and C must tunnel.

Dialup Interfaces. 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 of 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:

- Speed of transmission
- Start/stop bits
- Parity
- Automatic detection of the transmission speed in use
- Control flow
- Packet dispatch sequences
- Transport protocol
- Session time limits
- Automatic dialing
- Length of the wait before automatically redialing
- Number of redials
- Line timeout and automatic disconnect
- Terminal characteristics: screen length and width, escape character and other special key sequences, any terminal locking mechanism, line and connection information to be supplied after a successful logon, and any banner messages
- Telnet characteristics: echo, speed negotiation, end-of-line control, connection failure and success messages, recording of the location of the telnet client, and circumstances when a connection is refused

And that's not all. This information must be supplied for every dialup connection you are installing.

A Special Case. 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.

### Router Configuration--Hints for the Real World

As the last stop on our cook's tour of router planning, configuration, and management, let's take a look at some points that can affect real-world router configuration.

> TIP: In setting up your router to handle all the protocol types described in the following sections, the basic tasks you must carry out are

- Enable routing
- Establish security for access to the subnet in question
- Enable monitoring of the subnet

> While only the first of these is actually required, all are strongly recommended.

AppleTalk. 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 catchall reference to a number of flavors of a protocol suite. Apple talks as summarized in the following table.

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:

- AppleTalk Address Resolution Protocol (ARP)
- Datagram Delivery Protocol (DDP)
- Routing Table Maintenance Protocol (RTMP)
- Name Binding Protocol (NBP)
- Zone Information Protocol (ZIP)
- AppleTalk Echo Protocol (AEP)
- AppleTalk Transaction Protocol (ATP)

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.

Banyan VINES. 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

- Means of displaying of host addresses
- Means of controlling of routing updates
- Enabling or disabling of fast switching
- Defining static routes
- Means of controlling of broadcast packets

> NOTE: Static is a term applied to routes and paths that cannot be altered. For instance, if you want 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. DECnet recognizes levels of routers. So, in addition to the three basic configuration tasks, setting up your router to talk to DECnet means identifying which levels 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. IP configuration involves not only expected tasks like assigning addressing but also tasks 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.

Novell. 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.

## Router Profiles

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 contains 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.

### An Ethernet-To-Internet IP Router

- Interfaces: dialup, leased/switched, or ISDN
- Connect protocols: PPP or Frame Relay
- Management: Windows, Macintosh, telnet, or SNMP
- Ethernet port: auto-switching between thicknet, thinnet, and 10BaseT Ethernet
- Number of WAN ports: one RS-232 operating at 128 Kbps in both synchronous and asynchronous modes
- Cost: $995.00

### An Easy-To-Use Wide Area Router

- Interfaces: dialup, leased/switched, or ISDN; allows for isolation of low-usage links as dial-on-demand-only
- Connect protocols: PPP or Frame Relay
- Protocols routed: AppleTalk, DECnet, IPX, TCP/IP
- Management: Windows, Macintosh, telnet, or SNMP
- Ethernet port: auto-switching between thicknet, thinnet, and 10BaseT Ethernet
- Number of WAN ports: one RS-232 operating at 128 Kbps in both synchronous and asynchronous modes
- Cost: $1,295.00

### A High-Speed, Multi-Port Ethernet-To-Intenet Router

- Interfaces: dialup, leased/switched, ISDN, or T1
- Connect protocols: PPP or Frame Relay
- Protocols routed: AppleTalk, DECnet, IPX, TCP/IP
- Management: Windows, Macintosh, telnet, or SNMP
- Ethernet port: auto-switching between thicknet, thinnet, and 10BaseT Ethernet
- Number of WAN ports: two T1/E1 rate synchronous V.35; two 128 Kbps synchronous/asynchronous RS-232
- Cost: $2,195.00

A High-Speed, Multi-Port Wide Area Router

- Interfaces: dialup, leased/switched, ISDN, or T1
- Connect protocols: PPP or Frame Relay
- Protocols routed: AppleTalk, DECnet, IPX, TCP/IP
- Management: Windows, Macintosh, telnet, or SNMP
- Ethernet port: auto-switching between thicknet, thinnet, and 10BaseT Ethernet
- Number of WAN ports: two T1/E1 rate synchronous V.35; two 128 Kbps synchronous/asynchronous RS-232
- Cost: $2,995.00

### Wire-Speed Segment Router

- Segments managed: one Ethernet subnet
- Fault management: store-and-forward with error isolation
- Protocols routed: AppleTalk, DECnet, IPX, TCP/IP; ability to include other protocols (with upgrade/add-on)
- Management: Windows, Macintosh, telnet, or SNMP
- Ethernet ports: two; autoswitching between thicknet, thinnet, and 10BaseT Ethernet
- Cost: $2,995.00

### Multi-Port Ethernet Switching Router

- Segments managed: multiple Ethernet segments
- Fault management: store-and-forward with error isolation
- Protocols routed: AppleTalk, DECnet, IPX, TCP/IP; ability to include other protocols (with upgrade/add-on)
- Management: Windows, Macintosh, telnet, or SNMP
- Ethernet ports: four; autoswitching between thicknet, thinnet, and 10BaseT Ethernet
- Cost: $3,495.00

## Router Support

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. This software and support are sketched out in the following sections.

### Management Software

- X-Windows, Windows, and Macintosh versions of the management software should be available.
- Router parameters should be displayed in an easy-to-understand, needs-little-if-any-interpretation manner.
- You should have the option of viewing full or selected sets of router statistics.
- You should be able to manage both local and remote routers through the same software.
- You should be able to carry out downloads of software to the router from the management package.

### Support Agreement

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.

- Minimum one-year warranty; a three-year warranty is preferable
- Free software updates for the life of the router
- Free unlimited phone-in technical support
- Replacement of defective components (hardware or software) within 48 hours

A Real-World Router Monitoring Tool. 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:

- Router type
- Serial number
- Model number
- Software version
- Routing table contents
- Router statistics: packet receive and transmit counts, error counts, and collision counts
- Losses of connectivity

Information compiled by RouterCheck can be displayed in its entirety or in selected subsets.

## Software Routers

If, after studiously reading everything in this chapter, you still haven't found 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 accomplished strictly through software.

The most recent development in this area is the introduction by Microsoft Corporation of 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 also enables the connection of Windows NT LANs to WANs.

## Summary

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

© Copyright, Macmillan Computer Publishing. All rights reserved.