Configuring A Router

Learn the ins and outs of the smartest internetworking devices.

While switches and bridges can often configure themselves automatically-at least to the point where traffic will flow and some of the objectives of these devices will be fulfilled-the plug-and-play, full-service router doesn't exist. The subject of router configuration is enormous , encompassing the specific behavior of hundreds of hardware interfaces, protocols, and parameters, as well as many vendor-specific methods and applications. However, there are several tasks common to most router applications that are worth trying to understand better.

Whether the router provides a simple ISP connection from a two-node network over an analog line or serves as a multi-gigabit collapsed backbone connected to numerous ATM and FDDI segments, there are several fundamental configuration tasks you need to know about. You must configure the physical interfaces to LANs and WANs. On each interface, you need to enable support for needed traffic protocols. For each interface-protocol combination, you must either define routing tables or configure support for an automatic routing table update protocol. To implement traffic policies, including security and priority setting, you need to define filters for each interface-protocol combination.

Physical Interfaces

With the exception of special purpose " one-armed " routers, routers have at least two physical interfaces. While wide-area connections require trickier and more esoteric information for configuration, local-area connections are not always trivial to set up. For example, Ethernet interfaces that can handle either 10Mbit/sec or 100Mbit/sec links may need to be explicitly configured to auto-negotiate the speed. In addition, the congestion control some 100BaseT vendors provide won't work on auto-negotiated links. FDDI networks include powerful fault tolerant features, but they must be configured properly on the router interface.

Setting up WAN interfaces can be a challenge if your experience is limited to LANs. First, there's the Physical layer, a line whose other end you generally don't control (your two-wire or four-wire cable most likely gets terminated in a telephone company facility somewhere). You're probably at the mercy of the telephone service provider for information about whether the line is working properly.

If the link is a dial-up analog line, you will need to set up modems, perhaps by creating a script that issues AT commands to the modem and that sends along a user name and password to authenticate a session. ISDN modems can gracefully and rapidly dial their destinations, but there are a multitude of decisions to make with respect to the two BRI channels. Do you want the second channel to be active all the time, or only when the first line is saturated , or never? If the second channel is up and a call comes in, should one of the lines unbond itself and answer the incoming call?

Whether it's a dial-up or an always-live connection, the link will need to be configured for one of the framing protocols-PPP, frame relay, LAP-B (Link Access Protocol-Balanced, for X.25), HDLC (High-level Data-Link Control), or another Layer 2 protocol. Often, the necessary information will come from the telecommunications service provider. For example, you will need to tell the interface which Data Link Connection Identifier (DLCI) to use any time a link is made up of a frame relay permanent virtual circuit. Encryption and data compression may need to be configured at Layer 2 also. Frame types are often closely linked to a particular interface and a specific service, so many configuration choices can be handled by the manufacturer's default values and by the information your service provider is obligated to supply.

Know Your Protocols

Configuring one or more Network-layer protocols on any given interface is the task that first comes to mind when you think of configuring routers. Before we discuss network protocols, it's important to recall that most modern routers are also bridges. If you have multiple protocols running on your network-and who doesn't these days-you have to decide what to do with each one when it gets to the router.

Some packets, such as LAT and NetBIOS, can't be routed, because they don't have Network-layer source and destination addresses. Therefore, if you want the users connected to two interfaces to be able to run NetBIOS-based peer-to-peer networking, for example, you will have to enable bridging between the two interfaces. Then, unless you explicitly filter particular kinds of traffic, every protocol that isn't routed from one interface to the other will be bridged. For example, if you route only IP and IPX and turn bridging on for the sake of NetBIOS, you will also be bridging AppleTalk broadcasts.

Other packet types, such as AppleTalk and old versions of IPX, can be routed; yet, even when they are routed, they might still clog a wide-area link with more overhead than better-behaved protocols would. If you bridge these chatty protocols over a dial-up line, whether analog or ISDN, you better hope there isn't a meter going "kachingg" every minute or two, because those lines will be up around the clock-unless you're a genius at filtering and spoofing.

The most common network protocol you're likely to want to route is IP. Typically, each router interface will be assigned an IP address that is part of the same subnet as the other nodes on the segment. (For more details on IP addresses and subnetting, see the Tutorial "IP Addresses and Subnet Masks," page 27, October 1995, by Steve Steinke.) The interface will also need to have a subnet mask specified. In most cases, you will also specify a default gateway address and a DNS server address. If you are setting up Internet access, the values for these addresses will be provided by your ISP.

If there are Novell servers in your network, you most certainly have IPX traffic. By default, any NetWare or IntranetWare server with multiple interfaces will route traffic between them. Whether you are configuring a single-purpose router or a server that functions as a router, the essential configuration step is to assign a unique network number to each interface on the IPX internetwork. IPX has one significant advantage over IP in that all you need for a new subnet is an interface and a network number. You don't have to be concerned with scarce , carefully reserved 32-bit addresses, address classes, and subnet masks as you do with IP.

One peculiarity of IPX is that there are four possible Ethernet frame types on Novell networks: 802.2, 802.3, Ethernet II, and SNAP (Subnet Access Protocol). If there is a mixture of these frame types on a network, there can be odd effects. For example, some routers can only route one of these frame types on an interface at a time, so if bridging is disabled, devices configured for the nonrouted frame types may be invisible.

Supplying Routes

Aside from accepting incoming traffic and forwarding outgoing traffic on its interfaces, a router must keep track of how to move packets a step closer to their ultimate destination. The mechanism for storing this information is the routing table. (If bridging is enabled, bridging tables must be present. Bridging tables associate specific MAC addresses-actual physical nodes-with specific interfaces, while routing tables are concerned only with associating network addresses with specific interfaces.)

There must be a separate routing table for each enabled network protocol: one for IP, one for IPX, one for SNA, one for AppleTalk, one for VINES IP, one for DECnet, and so forth. The good news is that there are routing information protocols that can automatically populate and update routing tables. The bad news is that there may be several of these routing information protocols for each network protocol, and you might have to tweak each of them separately.

Sometimes, especially with point-to-point links, there's no need for the traffic and configuration overhead of dynamic routing tables. In these cases, you can define static routes that will accomplish your goals. There may also be times when you choose to employ a combination of static and dynamic routes.

For traditional IP networks, the Routing Information Protocol (RIP) is widely used. There are two versions of RIP, with valuable extra features in version 2. You may have to decide whether to listen for RIP broadcasts, send RIP broadcasts, or both. There are features of RIP designed to stamp out unproductive routing loops -split horizons and poison reverse-which you might choose to implement. Some RIP implementations can be set for triggered updates, where updates are governed by route changes rather than by a fixed schedule.

The OSPF (Open Shortest Path First) protocol for dynamic-routing table updates has become increasingly important in recent years because it uses less network throughput capacity than RIP for updates. Additionally, it converges on a stable configuration after changes occur more quickly than RIP.

OSPF, RIP, and Cisco's proprietary IGRP (Interior Gateway Routing Protocol) and EIGRP (Enhanced IGRP) are all designed primarily for use within a particular Internet domain or Autonomous System (AS)-that is, an area with common administration and a specific routing strategy. Other routing information protocols are better suited to networks with inter-AS traffic, such as the Internet backbone. These protocols include EGP (Exterior Gateway Protocol) and various versions of BGP (Border Gateway Protocol).

Special-purpose applications might also require separate routing tables or parameter settings on existing routing information protocols. Multicasting, for example, can be accomplished only if routers are configured to handle it. Networks that implement the Resource Reservation Protocol, RSVP, might select tortuous routes when not all the routers in a domain support it.

RIP, IGRP, and EIGRP have also been implemented for IPX-based networks. The IPX link state protocol, analogous to OSPF in the IP world, is NLSP (NetWare Link Services Protocol.) NLSP can greatly reduce the fat of frequent RIP broadcasts, which have traditionally consumed scarce WAN bandwidth on large Novell networks.

Policy And Security

With properly configured interfaces, network protocols, and routing information protocols or static routes, the traffic will go through routers. In fact, traffic that you'd prefer not to have routed may go through. Routers can be configured with filters to help secure the network and to keep it focused on your organization's goals.

Filters can be configured on the German model-everything not explicitly permitted is prohibited-or the Italian model-everything not explicitly prohibited is permitted. Thus, you may elect to filter all traffic except that which comes from specific source addresses. Or you may want to forward every protocol except DECnet and VINES IP. Any characteristic that is transmitted in a packet can be used for filtering: source or destination addresses, protocol types, port IDs, application-specific indicators, and even particular data. This is the case because filtering is implemented primarily by defining a bit mask and comparing the masked value in each packet to some other value.

Numerous filters, with various dependencies and Boolean relationships to each other, may have to be defined for each protocol on each interface. Fortunately, most vendors have many useful filters predefined, and some have tools for defining, testing, and implementing them efficiently and safely.

Configuring routers is not a job for amateurs, or even for careless professionals: Ask the folks at Network Solutions and other ISPs who have browned out chunks of the Internet in recent months with mistyped command lines. The spirit of this tutorial is to alert readers to the scope of the task, and, perhaps, to help organize and make more manageable the prospect of learning to master this job.

This tutorial, number 111, by Steve Steinke, was originally published in the November 1997 issue of Network Magazine.