A GUIDE TO TCP/IP INTERNETWORKING

Standard HTML 4.01 document

RFC Index: www.c-extra.com

Origin: Rutgers University

2. Addressing and Routing

2.9 Network-wide services: naming

If you are going to have a TCP/IP network, there are certain things that you ar e going to have to do centrally. Some of them are simply administrative. The mos t important is that you will a central registry of names and IP addresses. The N etwork Information Center (NIC) performs this role for the Internet network as a whole. If you are connected to the international Internet, your administrator w ill need to register with NIC, so that queries from other institutions about you r hosts are forwarded to your servers. You will want to maintain a database cont aining information about each system on your network. At a minimum, you need to have the host name and IP address for each system. Probably the central registry will assign IP addresses. If your network is subnetted, or if you use multiple class C network numbers, the registry will probably assign network numbers to ne w networks or subnets. Most commonly, individual host administrators will be allowed to choose their own host names. However the registry must at least verify that there are no duplicate names. If you have a very large network, you may choose to delegate some of these tasks to subregistries, possibly one for each 15 department. We suggest that you assign numbers in the simplest way: starting from 1. Thus if your network is 128.6, you would assign 128.6.1 as your first subnet, 128.6.2 as the second, etc. IP addresses for individual hosts should probably start at 2. This allows you to reserve 1 on each subnet for use by a router. Thus the first host on subnet 128.6.4 would be 128.6.4.2, the next 128.6.4.3, etc. There is a specific reason for keeping addresses as small as possible. If you have a large organization, you may run out of subnet numbers. If you do, and if your host numbers are small, you can assign another bit for the subnet. For example, we use the entire third octet as a subnet number. As long as all of our host numbers are less than 128, we will be able to expand to 9-bit subnet numbers. For example, subnet 128.6.4 would be split into two separate subnets, 128.6.4.0 and 128.6.4.128. If we had assigned host numbers above 128, this split would be impossible. Host names need not be so systematic. They can start with almost any word made up of letters numbers, and hyphens. It is safest for the first character to be a letter. It will be easier for users if the name is fairly short. (We have seen software that has trouble dealing with names longer than 16 characters). Many times departments or projects choose a theme, and pick names that are consistent with them. For example, the machines used by computer science graduate students at Rutgers are named after rock bands: STEELEYE, BAND, TREX, DEVO, etc. The math department uses famous mathematicians: GAUSS, FERMAT, etc. If your institution does not have any connection with the outside world, such one-word names are all you need.

If you are connected to with the Internet, your organization will need to get a "domain name". This is assigned to you by NIC, just as your network numb er is. Unlike the network number, you can get along without one if your network is isolated. If you find later that you need one, it is easy to add a domain name. (We recommend that you start with an official network number from the beginning because changing network numbers later can be traumatic). Domain names normally end in .EDU for educational institutions, .COM for companies, etc. For example, Rutgers University has a domain name of .RUTGERS.EDU. A full domain-style host name consists of your one-word internal name followed by your organization's domain name. For example, a computer normally used at Rutgers is known internally as ATHOS. It's full name is ATHOS.RUTGERS.EDU. If you have a large organization, it is possible to have sub-domains. For example, you might have a subdomain for each department. This adds another period to your names. For example, the computer science department might have decided to create a subdomain. In this case, the above computer would probably be called ATHOS.CS.RUTGERS.EDU. Once you get a domain name assigned to you, it is wise to change all of your configuration files so that the full form of name is used. However your software can be set up so that the one-word versions are accepted as nicknames. That way your users don't have to type out the long form. If you have more than one or two systems, you are going to need some 16 way to keep host information up to date on all of your systems. TCP/IP software needs to be able to translate host names into IP addresses. When a user tries to connect to another system, he wants to be able to refer to it by name. The software has to translate the name into the IP address in order to open the connection. Most software provides two ways to do this translation: a static table or a name server. The table approach is probably easier for small organizations, as long as they are not connected to any other network. You simply create a file that lists the names and addresses of all your hosts. Here is one commonly-used format for the host table:

    128.6.4.2    aramis.rutgers.edu aramis
    128.6.25.2   aramis.rutgers.edu aramis
    128.5.4.3    gauss.rutgers.edu gauss
    128.6.4.4    athos.rutgers.edu gauss
    128.6.25.4   athos.rutgers.edu gauss

In this format, each line represents a single IP address. If a system has two interfaces, there are two lines in the table for it. You should try to put the address first that is likely to be used more often. The documentation for your systems should indicate what format they want the host information to use. The address has both primary names, e.g. aramis.rutgers.edu, and nicknames, e.g. aramis. Brief nicknames is to make it easier for local users. In the simplest setup, every computer has its own copy of the host table. If you choose to use the setup, you will want to set up procedures to make sure that systems get updated copies of the host table regularly. Larger sites, and all sites that are connected to the Internet, should use name servers instead of individual host tables.

A name server is a program that you run on a few of your systems to keep track of names. When a program needs to look up a name, instead of looking for a copy of the host table, it sends a network query to the name server. This approach has two advantages:
•  For a large site, it is easier to keep tables up to date on a few name servers than on every system.
•  If your site is connected to the Internet, your name server will be able to talk to name servers at other organizations, and look up names elsewhere.

Using a name server is the only way to have access to complete host information about the rest of the Internet. It is important to understand the difference be tween a name server and a resolver. A name server is a program that accesses a h ost database, and answers queries from other programs. A resolver is a set of su broutines that can be loaded with your program. It generates queries to the name server, and processes the responses. Every system should use the resolver. (Act ually, the resolver is generally loaded with each program that uses the network, since it's simply a set of subroutines). You only need a few name servers. Many people confuse these two concepts, and come to believe that every computer needs to run a name server. In order to use a resolver, each computer will need a configuration file or other option that specifies the address of a name server where queries should be sent. Generally you should specify several name servers, in case one of them is down. If your system cannot reach any name server, much of your software is likely to misbehave. Thus you should be very careful to have enough name servers around that every system can always reach at least one name server. Name servers generally have a number of configuration options. Rather than giving advice here on setting up a name server, we prefer to refer you to two official Internet standards documents. RFC 1032 contains instructions for getting a domain name from the Network Information Center, including the necessary forms. RFC 1033 contains instructions on how to set up a name server. You will also need documentation for the specific name server software that you are going to use. In some cases you may need to use both fixed tables and name servers. If you have some TCP/IP implementations that do not include resolvers, then you will have to have host tables for those systems. If your network is connected to the international Internet, you are going to have problems with systems that don't have resolvers. The Internet is too big for there to be a host table that lists all of its hosts. Thus you will have to put together a host table that lists those hosts that your users tend to use. The Network Information Center maintains a host table that will be a good starting point. However it is by no means complete. So you will have to add your users' favorite hosts to it. Systems that use a resolver will not have this problem, since the name servers are able to translate any legal host name.

Host name and number allocation is the only facility that has to be done centrally. However there are other things that you may prefer to do centrally. It is very common to have one or two computers that handle all computer mail. If are on the Internet, it is easy for every one of your computers to talk directly to any other computer on the Internet. However most institutions want to communicate with systems on other networks, such as Bitnet and Usenet. There are routers between the various networks. But choosing the right router, and transforming computer mail addresses correctly is a rather specialized business. Thus many sites set up the appropriate software only one place and direct all external mail (or all external mail to hosts that are not on the Internet) through this system.

2.10 Setting up routing for an individual computer

All TCP/IP implementations require some configuration for each host. In some cases this is done during "system generation". In other cases, various startup and configuration files must be set up on the system. Still other systems get configuration information across the network from a "server". While the details differ, the same kind of information needs to be supplied for most implementations. This includes:

      •  Parameters describing the specific machine, such as its IP address.
      •  Parameters describing the network, such as the subnet mask (if any).
      •  Routing software and the tables that drive it.
      •  Startup of various programs needed to handle network tasks.

Before a machine is installed on your network, a coordinator should assign it a host name and IP address, as described above. Once you have name and address, y ou are ready to start configuring your computer. Often you have to put the addre ss and name into a configuration file on the computer. However some computers (p articularly those without permanent disks on which configuration information cou ld be stored) get this information over the network. When such a system starts, it broadcasts a request over the network. In effect, this request says "who a m I?" If you have any computers like this, you will have to make sure that s ome system on your network is ready to answer these questions. The obvious issue is: how can another system tell who you are? Generally this is done based on Et hernet address (or the analogous address for other types of network). Ethernet a ddresses are assigned by the computer manufacturer. It is guaranteed that only one machine in the entire world has any particular Ethernet address. The address is normally stored in ROM somewhere in the machine. The machine may not know its IP address, but it does know its Ethernet address. Thus the "who are I" request includes the Ethernet address. Systems that are set up to answer such requests have a table that lists Ethernet addresses and the corresponding IP address. This lets them know how to answer. Unfortunately, you have to set this table up manually. Generally you know the IP address, because your address coordinator has assigned it. The only problem in constructing the table will be finding out the Ethernet address for each computer. Generally, computers are designed so that they print the Ethernet address on the console shortly after being turned on. However in some cases you may have to find a way to bring the computer up and then type a command that displays information about the Ethernet interface. Generally the subnet mask should be specified in a configuration file associated with the computer. (For UNIX systems, the "ifconfig" command is used to specify both the Internet address and subnet mask). However there are provisions in the IP protocols for a computer to broadcast a request asking for the subnet mask. The subnet mask is an attribute of the network. It is the same for all computers on a given subnet. Thus there is no separate subnet table corresponding to the Ethernet/Internet address mapping table used to answer address queries. Ideally, only a few authoritative computers will answer queries about the subnet mask. However many TCP/IP implementations are set up so that any machine on the network that believes it knows the subnet mask will answer. If your TCP/IP is like this, an incorrect subnet mask setting on one machine can cause confusion throughout the network. Normally the startup files do roughly the following things:
•  Load any special device drivers that may be necessary. (This is particularly common with PC's, where network access is likely to depend upon add-on controller cards and software that is not part of the original operating system).
•  Enable each of the network interfaces (Ethernet interface, serial lines, etc). Normally this involves specifying an Internet address and subnet mask for each, as well as other options that will be described in your vendor's documentation.
•  Establish network routing information, either by commands that add fixed routes, or by starting a program that obtains them dynamically.
•  Turn on the domain system (used for looking up names and finding the corresponding Internet address. Note that the details of this will depend upon how the domain system is configured. In most cases only a few hosts actually run domain name servers that must be started. Other hosts simply need configuration files that specify where the nearest name server is located.
•  Set various other information needed by the system software, such as the name of the system itself.
•  Start various "daemons". These are programs that provide network services to other systems on the network, and to users on this system. In the case of PC's, which often cannot run multiple processes, similar facilities may be provided by so-called "TSR", or they may be built into the device drivers.

It is not practical to document these steps in detail, since they differ for each vendor. This section will concentrate on a few issues where your choice will depend upon overall decisions about how your network is to operate. These overall network policy decisions are often not as well documented by the vendors as the details of how to start specific programs. Note that some care will be necessary to integrate commands that you add for routing, etc., into the startup sequence at the right point. Some of the most mysterious problems occur when network routing is not set up before a program needs to make a network query, or when a program attempts to look up a host name before the name server has finished loading all of the names from a master name server.

2.11 How datagrams are routed

If your system consists of a single Ethernet or similar medium, you do not need to give routing much attention. However for more complex systems, each of your machines needs a routing table that lists a router and interface to use for every possible destination network. A simple example of this was given at the beginning of this section. However it is now necessary to describe the way routing works in a bit more detail. On most systems, the routing table looks something like the following. (This example was taken from a system running Berkeley UNIX, using the command "netstat -n -r". Some columns containing statistical information have been omitted).

In the following example, a system is connected to two Ethernets:

  controller   network   address     other networks

      il0      128.6.7   128.6.7.26    128.6.6
      pe0      128.6.4   128.6.4.61      none

The first column shows the name for the Ethernet interface. The second column is the network number for that Ethernet. The third column is this computer's Internet address on that network. The last column shows other subnets that share the same physical network. Now let's look at the routing table:

Destination     Router      Flags      Interface

 128.6.5.3     128.6.7.1     UHGD        il0
 128.6.5.21    128.6.7.1     UHGD        il0
 127.0.0.1     127.0.0.1     UH          lo0
 128.6.4       128.6.4.61    U           pe0
 128.6.6       128.6.7.26    U           il0
 128.6.7       128.6.7.26    U           il0
 128.6.2       128.6.7.1     UG          il0
 10            128.6.4.27    UG          pe0
 128.121       128.6.4.27    UG          pe0
 default       128.6.4.27    UG          pe0

For the moment, let us ignore the first 3 lines. The majority of the table consists of a set of entries describing networks. For each network, the other three columns show where to send datagrams destined for that network. If the "G" flag is present in the third column, datagrams for that network must be sent through a router (gateway). The second column shows the address of the router to be used. If the "G" flag is not present, the computer is directly connected to the network in question. So datagrams for that network should be sent using the controller shown in the third column. The "U" flag in the third column simply indicates that the route specified by that line is up. (Generally a route is assumed to be up unless attempts to use it consistently result in errors). The first 3 lines show "host routes", indicated by the "H" flag in column three. Routing tables normally have entries for entire networks or subnets. For example, the entry 128.6.2 128.6.7.1 UG il0 indicates that datagrams for any computer on network 128.6.2 (i.e. addresses 128.6.2.1 through 128.6.2.254) should be sent to router 128.6.7.1 for forwarding. However sometimes routes apply only to a specific computer, rather than to a whole network. In that case, a host route is used. The first column then shows a complete address, and the "H" flag is present in column 3. E.g. the entry:

128.6.5.21   128.6.7.1    UHGD    il0

indicates that datagrams for the specific address 128.6.5.21 should be sent to the router 128.6.7.1. As with network routes, the "G" flag is used for routes that involve a router. The "D" flag indicates that the route was added dynamically, based on an ICMP redirect message from a router. (See below for details). The following route is special:

127.0.0.1    127.0.0.1    UH      lo0

127.0.0.1 is the address of the "loopback device". This is a dummy software module. Any datagram sent out through that "device" appears immediately as input. It can be used for testing. The loopback address can also handy for talking to applications that are on your own computer. (Why bother to use your network to talk to a program that is on the same machine you are?). Finally, there are "default" routes, e.g.:

default      128.6.4.27   UG      pe0

This route is used for datagrams that don't match any other entry. In this case, they are sent to a router with address 128.6.4.27. In most systems, datagrams are routed by looking up the destination address in a table such as the one just described. If the address matches a specific host route, then that is used. Otherwise, if it matches a network route, that is used. If no other route works, the default is used. If there is no default, the user should get an error message such as "network is unreachable". The following sections will describe several ways of setting up these routing tables. Generally, the actual operation of sending datagrams doesn't depend upon which method you use to set up the routes. When a datagram is to be sent, its destination is looked up in the table. The different routing methods are simply more and less sophisticated ways of setting up and maintaining the tables.

Fixed routes
The simplest way to set up routing is to use fixed commands. Your startup files contain commands to set up the routing table. If any changes are needed, you make them manually, using commands that add and delete entries in the routing table. (When you make such a change, don't forget to update the startup files also). This method is practical for relatively small networks, particularly if they don't change very often. Most computers automatically set up some routing entries for you. UNIX will add an entry for the networks to which you are directly connected. For example, your startup file might contain the commands:

ifconfig  ie0  128.6.4.4     netmask  255.255.255.0 ifconfig  ie1  128.6.5.35    netmask  255.255.255.0

These specify that there are two network interfaces, and your addresses on them. The system will automatically create routing table entries

128.6.4   28.6.4.4    U    ie0
128.6.5   128.6.5.35  U    ie1

These specify that datagrams for the local subnets, 128.6.4 and 128.6.5, should be sent out the corresponding interface. In addition to these, your startup files would contain commands to define routes to whatever other networks you wanted to reach. For example,

route add   128.6.2.0   128.6.4.1   1
route add   128.6.6.0   128.6.5.35  0

These commands specify that in order to reach network 128.6.2, a router at address 128.6.4.1 should be used, and that network 128.6.6 is actually an additional network number for the physical network connected to interface 128.6.5.35. Some other software might use different commands for these cases. UNIX differentiates them by the "metric", which is the number at the end of the command. The metric indicates how many routers the datagram will have to go through to get to the destination. Routes with metrics of 1 or greater specify the address of the first router on the path. Routes with metrics of 0 indicate that no router is involved: this is an additional network number for the local network. Finally, you might define a default route, to be used for destinations not listed explicitly. This would normally show the address of a router that has enough information to handle all possible destinations. If your network has only one router attached to it, then of course all you need is a single entry pointing to it as a default. In that case, you need not worry further about setting up routing on your hosts. (The router itself needs more attention, as we will see). The following sections are intended to provide help for setting up networks where there are several different routers.

Routing redirects
Most TCP/IP experts recommend leaving routing decisions to the routers. That is, it is probably a bad idea to have large fixed routing tables on each computer. The problem is that when something on the network changes, you have to go around to many computers and update the tables. If changes happen because a line goes down, service may not be restored until someone has a chance to notice the problem and change all the routing tables. The simplest way to keep routes up to date is to depend upon a single router to update your routing tables. This router should be set as your default. (On UNIX, this would mean a command such as "route add default 128.6.4.27 1", where 128.6.4.27 is the address of the router). As described above, your system will send all datagrams to the default when it doesn't have any better route. At first, this strategy does not sound very good if you have more than one router. After all, if all you have is a single default entry, how will you ever use the other routers in the cases where they are better? The answer is that most routers are able to send "redirects" when they get datagrams for which there is a better route. A redirect is a specific kind of message using the ICMP (Internet Control Message Protocol). It contains information that generally translates to "In the future, to get to address XXXXX, please use router YYYYY instead of me". Correct TCP/IP implementations use these redirects to add entries to their routing table. Suppose your routing table starts out as follows:

Destination     Router        Flags      Interface

127.0.0.1      127.0.0.1       UH          lo0
128.6.4        128.6.4.61      U           pe0
default        128.6.4.27      UG          pe0

This contains an entry for the local network, 128.6.4, and a default pointing to the router 128.6.4.27. Suppose there is also a router 128.6.4.30, which is the best way to get to network 128.6.7. How do you find it? Suppose you have datagrams to send to 128.6.7.23. The first datagram will go to the default router, since that's the only thing in the routing table. However the default router, 128.6.4.27, will notice that 128.6.4.30 would really be a better route. (How it does that is up to the router. However there are some fairly simple methods for a router to determine that you would be better off using a different one). Thus 128.6.4.27 will send back a redirect specifying that datagrams for 128.6.7.23 should be sent via 128.6.4.30. Your TCP/IP software will add a routing entry.

128.6.7.23    128.6.4.30    UDHG    pe0

Any future datagrams for 128.6.7.23 will be sent directly to the appropriate router. This strategy would be a complete solution, if it weren't for three problems:

      •  It requires each computer to have the address of one router "hardwired" into its startup files, as the initial default.
      •  If a router goes down, routing table entries using it may not be removed.
      •  If your network uses subnets, and your TCP/IP implementation does not handle them, this strategy will not work.

How serious the first problem is depends upon your situation. For small networks, there is no problem modifying startup files whenever something changes. But some organizations can find it very painful. If network topology changes, and a router is removed, any systems that have that router as their default must be adjusted. This is particularly serious if the people who maintain the network are not the same as those maintaining the individual systems. One simple appoach is to make sure that the default address never changes. For example, you might adopt the convention that address 1 on each subnet is the default router for that subnet. For example, on subnet 128.6.7, the default router would always be 128.6.7.1. If that router is ever removed, some other router is given that address. (There must always be at least one router left to give it to. If there isn't, you are completely cut off anyway).

The biggest problem with the description given so far is that it tells you how to add routes but not how to get rid of them. What happens if a router goes down? You want traffic to be redirected back to a router that is up. Unfortunately, a router that has crashed is not going to issue Redirects. One solution is to choose very reliable routers. If they crash very seldom, this may not be a problem. Note that Redirects can be used to handle some kinds of network failure. If something fails in a distant part of the network, your current route may no longer be a good one. As long as the router to which you are talking is still up and talking to you, it can simply issue a Redirect to the router that is now the best one. However you still need a way to detect failure of one of the routers that you are talking to directly. The best approach for handling failed routers is for your TCP/IP implementation to detect routes that have failed. TCP maintains various timers that allow the software to detect when a connection has broken. When this happens, one good approach is to mark the route down, and go back to the default router. A similar approach can also be used to handle failures in the default router. If you have marked two routers as default, then the software should be capable of switching when connections using one of them start failing. Unfortunately, some common TCP/IP implementations do not mark routes as down and change to new ones. In particular, Berkeley 4.2 UNIX does not. However Berkeley 4.3 UNIX does do this.

Other ways for hosts to find routes
As long as your TCP/IP implementations handle failing connections properly, establishing one or more default routes in the configuration file is likely to be the simplest way to handle routing. However there are two other routing approaches that are worth considering for special situations:

      •  spying on the routing protocol
      •  using proxy ARP

Routers generally have a special protocol that they use among themselves. Note that redirects cannot be used by routers. Redirects are simply ways for routers to tell "dumb" hosts to use a different router. The routers themselves must have a complete picture of the network, and a way to compute the optimal route to each subnet. Generally they maintain this picture by exchanging information among themselves. There are several different routing protocols in use for this purpose. One way for a computer to keep track of routers is for it to listen to the routers' messages among themselves. There is software available for this purpose for most of the common routing protocols. Proxy ARP is an alternative technique for letting routers make all the routing decisions. It is applicable to any broadcast network that uses ARP or a similar technique for mapping Internet addresses into network-specific addresses such as Ethernet addresses. With proxy ARP, you dispense with explicit routing tables, and do everything at the level of Ethernet addresses. Proxy ARP can be used for all destinations, only for destinations within your network, or in various combinations. It will be simplest to explain it as used for all addresses. To do this, you instruct the host to pretend that every computer in the world is attached directly to your local 27 Ethernet. On UNIX, this would be done using a command route add default 128.6.4.2 0 where 128.6.4.2 is assumed to be the IP address of your host. As explained above, the metric of 0 causes everything that matches this route to be sent directly on the local Ethernet. Alternatively, some systems will allow you to get the same effect by setting a subnet mask of 0. If you do this, you may have to take precautions to make sure that it isn't reset by an ICMP subnet mask broadcast by a system that knows the real subnet mask. When a datagram is to be sent to a local Ethernet destination, your computer needs to know the Ethernet address of the destination. In order to find that, it uses something generally called the ARP table. This is simply a mapping from Internet address to Ethernet address. Here's a typical ARP table. (On many system, it is displayed using the command "arp -a").

FOKKER.RUTGERS.EDU (128.6.5.16) at 8:0:20:0:8:22 temporary
CROSBY.RUTGERS.EDU (128.6.5.48) at 2:60:8c:49:50:63 temporary
CAIP.RUTGERS.EDU (128.6.4.16) at 8:0:8b:0:1:6f temporary
DUDE.RUTGERS.EDU (128.6.20.16) at 2:7:1:0:eb:cd temporary
W20NS.MIT.EDU (18.70.0.160) at 2:7:1:0:eb:cd temporary
OBERON.USC.EDU (128.125.1.1) at 2:7:1:2:18:ee temporary
GATECH.EDU (128.61.1.1) at 2:7:1:0:eb:cd temporary
DARTAGNAN.RUTGERS.EDU (128.6.5.65) at 8:0:20:0:15:a9 temporary


Note that it is simply a list of IP addresses and the corresponding Ethernet address. The "temporary" indicates that the entry was added dynamically using ARP, rather than being put into the table manually. If there is an entry for the address in the ARP table, the datagram is simply put on the Ethernet with the corresponding Ethernet address. If not, an "ARP request" is broadcast, asking for the destination host to identify itself. This request is in effect a question "will the host with Internet address 128.6.4.194 please tell me what your Ethernet address is?". When a response comes back, it is added to the ARP table, and future datagrams for that destination can be sent without delay. This mechanism was originally designed only for use with hosts attached directly to a single Ethernet. If you need to talk to a host on a different Ethernet, it was assumed that your routing table would direct you to a router. The router would of course have one interface on your Ethernet. Your computer would then end up looking up the address of that router using ARP. It would generally be useless to expect ARP to work directly with a computer on a distant network. Since it isn't on the same Ethernet, there's no Ethernet address you can use to send datagrams to it. And when you send an ARP request for it, there's nobody to answer the request. Proxy ARP is based on the concept that the routers will act as proxies for distant hosts.

Dynamic routing: Routing Information Protocol (RIP)
RIP is one of a class of algorithms known as "distance vector algorithms". They are sometimes known as Bellman-Ford, because the formulation is based on Bellman's equation on dynamic programming. The basic algorithms described in this protocol were used in computer routing as early as 1969 in the ARPAnet. RIP was designed to work with moderate-size networks using reasonably homogeneous technology. Thus it is suitable as an Interior Gateway Protocol (IGP) for many campuses and for regional networks using serial lines whose speeds do not vary widely. It is not intended for use in more complex environments. RIP does not solve every possible routing problem. The protocol is limited to networks whose longest path involves 15 hops. The designers believe that the basic protocol design is inappropriate for larger networks. RIP uses fixed "metrics" to compare alternative routes. It is not appropriate for situations where routes need to be chosen based on real-time parameters such a measured delay, reliability, or load. The obvious extensions to allow metrics of this type are likely to introduce instabilities of a sort that the protocol is not designed to handle. A number of different approaches for finding routes between networks are possible. One useful way of categorizing these approaches is on the basis of the type of information the routers need to exchange in order to be able to find routes.
Distance vector algorithms are based on the exchange of only a small amount of information. Each entity (router or host) that participates in the routing protocol is assumed to keep information about all of the destinations within the system. Generally, information about all entities connected to one network is summarized by a single entry, which describes the route to all destinations on that network. This summarization is possible because as far as IP is concerned, routing within a network is invisible. Each entry in this routing database includes the next router to which datagrams destined for the entity should be sent. In addition, it includes a "metric" measuring the total distance to the entity. Distance is a somewhat generalized concept, which may cover the time delay in getting messages to the entity, the dollar cost of sending messages to it, etc. Distance vector algorithms get their name from the fact that it is possible to compute optimal routes when the only information exchanged is the list of these distances. Furthermore, information is only exchanged among entities that are adjacent, that is, entities that share a common network. Distance vector algorithms are based on a table giving the best route to every destination in the system. Of course, in order to define which route is best, we have to have some way of measuring goodness. This is referred to as the "metric". In simple networks, it is common to use a metric that simply counts how many routers a message must go through. In more complex networks, a metric is chosen to represent the total amount of delay that the message suffers, the cost of sending it, or some other quantity which may be minimized. The main requirement is that it must be possible to represent the metric as a sum of "costs" for individual hops.

Formally, if it is possible to get from entity i to entity j directly (i.e., without passing through another gateway between), then a cost, d(i,j), is associated with the hop between i and j. In the normal case where all entities on a given network are considered to be the same, d(i,j) is the same for all destinations on a given network, and represents the cost of using that network. To get the metric of a complete route, one just adds up the costs of the individual hops that make up the route. Let D(i,j) represent the metric of the best route from entity i to entity j. It should be defined for every pair of entities. d(i,j) represents the costs of the individual steps. Formally, let d(i,j) represent the cost of going directly from entity i to entity j. It is infinite if i and j are not immediate neighbors. (Note that d(i,i) is infinite. That is, we don't consider there to be a direct connection from a node to itself). Since costs are additive, it is easy to show that the best metric must be described by:

                 D(i,i) = 0,                      all i

                 D(i,j) = min [d(i,k) + D(k,j)],  otherwise
                           k

and that the best routes start by going from i to those neighbors k for which d(i,k) + D(k,j) has the minimum value. (These things can be shown by induction on the number of steps in the routes). Note that we can limit the second equation to k's that are immediate neighbors of i. For the others, d(i,k) is infinite, so the term involving them can never be the minimum.

It turns out that one can compute the metric by a simple algorithm based on this. Entity i gets its neighbors k to send it their estimates of their distances to the destination j. When i gets the estimates from k, it adds d(i,k) to each of the numbers. This is simply the cost of traversing the network between i and k. Now and then i compares the values from all of its neighbors and picks the smallest. It can be shown that this algorithm will converge to the correct estimates of D(i,j) in finite time in the absence of topology changes. Basically, entities just can't stop sending updates or recomputing metrics, and the networks can't delay messages forever. (Crash of a routing entity is a topology change). Because we don't have to make assumptions about when updates are sent, it is safe to run the algorithm asynchronously. That is, each entity can send updates according to its own clock. Updates can be dropped by the network, as long as they don't all get dropped. Because we don't have to make assumptions about the starting condition, the algorithm can handle changes. When the system changes, the routing algorithm starts moving to a new equilibrium, using the old one as its starting point. It is important that the algorithm will converge in finite time no matter what the starting point. Otherwise certain kinds of changes might lead to non-convergent behavior.

The statement of the algorithm given above (and the proof) assumes that each entity keeps copies of the estimates that come from each of its neighbors, and now and then does a min over all of the neighbors. In fact, real implementations don't necessarily do that. They simply remember the best metric seen so far, and the identity of the neighbor that sent it. They replace this information whenever they see a better (smaller) metric.This allows them to compute the minimum incrementally, without having to store data from all of the neighbors.
Let us summarize what a host or router R does. For each destination in the system, R will keep a current estimate of the metric for that destination (i.e., the total cost of getting to it) and the identity of the neighboring router on whose data that metric is based. If the destination is on a network that is directly connected to R, then R simply uses an entry that shows the cost of using the network, and the fact that no router is needed to get to the destination. It is easy to show that once the computation has converged to the correct metrics, the neighbor that is recorded by this technique is in fact the first router on the path to the destination. (If there are several equally good paths, it is the first router on one of them). This combination of destination, metric, and router is typically referred to as a route to the destination with that metric, using that router.

The following procedure is carried out by every entity that participates in the routing protocol. This must include all of the routers in the system. Hosts that are not routers may participate as well.
•  Keep a table with an entry for every possible destination in the system. The entry contains the distance D to the destination, and the first router R on the route to that network. Conceptually, there should be an entry for the entity itself, with metric 0, but this is not actually included.
•  Periodically, send a routing update to every neighbor. The update is a set of messages that contain all of the information from the routing table. It contains an entry for each destination, with the distance shown to that destination.
•  When a routing update arrives from a neighbor R', add the cost associated with the network that is shared with R'. (This should be the network over which the update arrived). Call the resulting distance D'. Compare the resulting distances with the current routing table entries. If the new distance D' for N is smaller than the existing value D, adopt the new route. That is, change the table entry for N to have metric D' and router R'. If R' is the router from which the existing route came, i.e., R' = R, then use the new metric even if it is larger than the old one.

The discussion above assumes that the topology of the network is fixed. In practice, routers and lines often fail and come back up. To handle this possibility, we need to modify the algorithm slightly. If the topology changes, the set of neighbors changes. Therefore, the next time the calculation is done, the change will be reflected. However, actual implementations use an incremental version of the minimization. Only the best route to any given destination is remembered. If the router involved in that route should crash, or the network connection to it break, the calculation might never reflect the change. The algorithm as shown so far depends upon a router notifying its neighbors if its metrics change. If the router crashes, then it has no way of notifying neighbors of a change. In order to handle problems of this kind, distance vector protocols must make some provision for timing out routes. The details depend upon the specific protocol. As an example, in RIP every router that participates in routing sends an update message to all its neighbors once every 30 seconds. Suppose the current route for network N uses router R. If we don't hear from R for 180 seconds, we can assume that either the router has crashed or the network connecting us to it has become unusable. Thus, we mark the route as invalid. When we hear from another neighbor that has a valid route to N, the valid route will replace the invalid one. Note that we wait for 180 seconds before timing out a route even though we expect to hear from each neighbor every 30 seconds.

Unfortunately, messages are occasionally lost by networks. Thus, it is probably not a good idea to invalidate a route based on a single missed message. As we w ill see below, it is useful to have a way to notify neighbors that there current ly isn't a valid route to some network. RIP, along with several other protocols of this class, does this through a normal update message, by marking that networ k as unreachable. A specific metric value is chosen to indicate an unreachable d estination; that metric value is larger than the largest valid metric that we ex pect to see. In the existing implementation of RIP, 16 is used. This value is no rmally referred to as "infinity", since it is larger than the largest valid metr ic. Suppose a network becomes inaccessible. All of the immediately neighboring r outers time out and set the metric for that network to 16. For purposes of analy sis, we can assume that all the neighboring routers have gotten a new piece of h ardware that connects them directly to the vanished network, with a cost of 16. Since that is the only connection to the vanished network, all the other routers in the system will converge to new routes that go through one of those routers. It is easy to see that once convergence has happened, all the routers will have metrics of at least 16 for the vanished network. Routers one hop away from the original neighbors would end up with metrics of at least 17; routers two hops aw ay would end up with at least 18, etc. As these metrics are larger than the maxi mum metric value, they are all set to 16. It is obvious that the system will now converge to a metric of 16 for the vanished network at all routers. Unfortunate ly, the question of how long convergence will take is not amenable to quite so s imple an answer. The choice of infinity = 16 is a tradeoff between network size and speed of convergence in case counting to infinity happens. The designers of RIP believed that the protocol was unlikely to be practical for networks with a diameter larger than 15. There are several things that can be done to prevent pr oblems of slow convergence. The ones used by RIP are called "split horizon wi th poisoned reverse", and "triggered updates". "Split horizon" is a s cheme for avoiding problems caused by including routes in updates sent to the ro uter from which they were learned. The "simple split horizon" scheme omits route s learned from one neighbor in updates sent to that neighbor. "Split horizon wit h poisoned reverse" includes such routes in updates, but sets their metrics to i nfinity. If A thinks it can get to D via C, its messages to C should indicate th at D is unreachable. If the route through C is real, then C either has a direct connection to D, or a connection through some other router. C's route can't poss ibly go back to A, since that forms a loop. By telling C that D is unreachable, A simply guards against the possibility that C might get confused and believe th at there is a route through A. This is obvious for a point to point line. But co nsider the possibility that A and C are connected by a broadcast network such as an Ethernet, and there are other routers on that network. If A has a route through C, it should indicate that D is unreachable when talking to any other router on that network. The other routers on the network can get to C themselves. They would never need to get to C via A. If A's best route is really through C, no other router on that network needs to know that A can reach D. This is fortunate, because it means that the same update message that is used for C can be used for all other routers on the same network. Thus, update messages can be sent by broadcast. In general, split horizon with poisoned reverse is safer than simple split horizon. If two routers have routes pointing at each other, advertising reverse routes with a metric of 16 will break the loop immediately. If the reverse routes are simply not advertised, the erroneous routes will have to be eliminated by waiting for a timeout. However, poisoned reverse does have a disadvantage: it increases the size of the routing messages. Split horizon with poisoned reverse will prevent any routing loops that involve only two routers. However, it is still possible to end up with patterns in which three routers are engaged in mutual deception. For example, A may believe it has a route through B, B through C, and C through A. Split horizon cannot stop such a loop. This loop will only be resolved when the metric reaches infinity and the network involved is then declared unreachable. Triggered updates are an attempt to speed up this convergence. To get triggered updates, we simply add a rule that whenever a router changes the metric for a route, it is required to send update messages almost immediately, even if it is not yet time for one of the regular update message. (The timing details will differ from protocol to protocol. Some distance vector protocols, including RIP, specify a small time delay, in order to avoid having triggered updates generate excessive network traffic). Note how this combines with the rules for computing new metrics.

Each host that implements RIP is assumed to have a routing table. This table has one entry for every destination that is reachable through the system described by RIP. Each entry contains at least the following information:
•  The IP address of the destination.
•  A metric, which represents the total cost of getting a datagram from the host to that destination. This metric is the sum of the costs associated with the networks that would be traversed in getting to the destination.
•  The IP address of the next router along the path to the destination. If the destination is on one of the directly-connected networks, this item is not needed.
•  A flag to indicate that information about the route has changed recently. This will be referred to as the "route change flag."
•  Various timers associated with the route.

The entries for the directly-connected networks are set up by the host, using information gathered by means not specified in this protocol. The metric for a directly-connected network is set to the cost of that network. In existing RIP implementations, 1 is always used for the cost. In that case, the RIP metric reduces to a simple hop-count. More complex metrics may be used when it is desirable to show preference for some networks over others, for example because of differences in bandwidth or reliability. Implementors may also choose to allow the system administrator to enter additional routes. These would most likely be routes to hosts or networks outside the scope of the routing system. Entries for destinations other these initial ones are added and updated by the algorithms described in the following sections. In order for the protocol to provide complete information on routing, every router in the system must participate in it. Hosts that are not routers need not participate, but many implementations make provisions for them to listen to routing information in order to allow them to maintain their routing tables.

RIP is a UDP-based protocol. Each host that uses RIP has a routing process that sends and receives datagrams on UDP port number 520. All communications directed at another host's RIP processor are sent to port 520. All routing update messages are sent from port 520. Unsolicited routing update messages have both the source and destination port equal to 520. Those sent in response to a request are sent to the port from which the request came. Specific queries and debugging requests may be sent from ports other than 520, but they are directed to port 520 on the target machine. The packet format is shown in tbable below.

Every datagram contains a command, a version number, and possible arguments. The command field is used to specify the purpose of this datagram. Commands can be:
•  Request: A request for the responding system to send all or part of its routing table.
•  Response: A message containing all or part of the sender's routing table.This message may be sent in response to a request or poll, or it may be an update message generated by the sender.

For request and response, the rest of the datagram contains a list of destinations, with information about each. Each entry in this list contains a destination network or host, and the metric for it. The packet format is intended to allow RIP to carry routing information for several different protocols. Thus, each entry has an address family identifier to indicate what type of address is specified in that entry. The address family identifier for IP is 2. The IP address is the usual Internet address, stored as 4 octets in network order. The metric field must contain a value between 1 and 15 inclusive, specifying the current metric for the destination, or the value 16, which indicates that the destination is not reachable. Each route sent by a router supercedes any previous route to the same destination from the same router. The maximum datagram size is 512 octets. This includes only the portions of the datagram described above. It does not count the IP or UDP headers. Every 30 seconds, the output process is instructed to generate a complete response to every neighboring router. There are two timers associated with each route, a "timeout" and a "garbage-collection time". Upon expiration of the timeout, the route is no longer valid. However, it is retained in the table for a short time, so that neighbors can be notified that the route has been dropped. Upon expiration of the garbage-collection timer, the route is finally removed from the tables. The timeout is initialized when a route is established, and any time an update message is received for the route. If 180 seconds elapse from the last time the timeout was initialized, the route is considered to have expired, and the deletion process is started for it

A RIP datagram

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   command     |    version    |      must be zero             |
+---------------+---------------+-------------------------------+
| address family identifier     |      must be zero             |
+-------------------------------+-------------------------------+
|                         IP address                            |
+---------------------------------------------------------------+
|                        must be zero                           |
+---------------------------------------------------------------+
|                        must be zero                           |
+---------------------------------------------------------------+
|                          metric                               |
+---------------------------------------------------------------+

2.12 Internetworking

This section will deal in more detail with the technology used to construct larger networks. It will focus particularly on how to connect together multiple Ethernets, token rings, etc. These days most networks are hierarchical. Individual hosts attach to local-area networks such as Ethernet or token ring. Then those local networks are connected via some combination of backbone networks and point to point links. A campus might have a network that looks in part like this:

 ______________________________
|   net 1      net 2    net 3  |        net 4            net 5
| ---------X---------X-------- |      --------    ---------------------
|                         |    |         |                 |
|  Building A             |    |         |                 |
|               ----------X--------------X-----------------X
|                              |  campus backbone network  :
|______________________________|                           :
                                                    serial :
                                                      line :
                                              -------------X----------
                                                       net  6

Nets 1, 2 and 3 are in one building. Nets 4 and 5 are in different buildings on the same campus. Net 6 is in a somewhat more distant location. The diagram above shows nets 1, 2, and 3 being connected directly, with switches that handle the connections being labelled as "X". Building A is connected to the other buildings on the same campus by a backbone network. Note that traffic from net 1 to net 5 takes the following path:
•  from 1 to 2 via the direct connection between those networks
•  from 2 to 3 via another direct connection
•  from 3 to the backbone network - across the backbone network from building A to the building in which net 5 is housed
•  from the backbone network to net 5

Traffic for net 6 would additionally pass over a serial line. With the setup as shown, the same switch is being used to connect the backbone network to net 5 and to the serial line. Thus traffic from net 5 to net 6 would not need to go through the backbone, since there is a direct connection from net 5 to the serial line. This section is largely about what goes in those "X".
Note that there are alternatives to the sort of design shown above. One is to use point to point lines or switched lines directly to each host. Another is to use a single-level of network technology that is capable of handling both local and long-haul networking.

Mesh of point to point lines
Rather than connecting hosts to a local network such as Ethernet, and then interconnecting the Ethernets, it is possible to connect long-haul serial lines directly to the individual computers. If your network consists primarily of individual computers at distant locations, this might make sense. Here would be a small design of that type.

  computer 1                computer 2             computer 3
       |                         |                      |
       |                         |                      |
       |                         |                      |
  computer 4 -------------- computer 5 ----------- computer 6

In the design shown earlier, the task of routing datagrams around the network is handled by special-purpose switching units shown as "X". If you run lines directly between pairs of hosts, your hosts will be doing this sort of routing and switching, as well as their normal computing. Unless you run lines directly between every pair of computers, some systems will end up handling traffic for others. For example, in this design, traffic from 1 to 3 will go through 4, 5 and 6. This is certainly possible, since most TCP/IP implementations are capable of forwarding datagrams. If your network is of this type, you should think of your hosts as also acting as routers. Much of the discussion below on configuring routers will apply to the routing software that you run on your hosts. This sort of configuration is not as common as it used to be, for two reasons:
•  Most large networks have more than one computer per location. In this case it is less expensive to set up a local network at each location than to run point to point lines to each computer.
•  Special purpose switching units have become less expensive. It often makes sense to offload the routing and communications tasks to a switch rather than handling it on the hosts.

It is of course possible to have a network that mixes the two kinds of techology. In this case, locations with more equipment would be handled by a hierarchical system, with LANs connected by switches. Remote locations with a single computer would be handled by point to point lines going directly to those computers. In this case the routing software used on the remote computers would have to be compatible with that used by the switches, or there would need to be a router between the two parts of the network. Design decisions of this type are typically made after an assessment of the level of network traffic, the complexity of the network, the quality of routing software available for the hosts, and the ability of the hosts to handle extra network traffic.

Circuit switching technology
Another alternative to the hierarchical LAN/backbone approach is to use circuit switches connected to each individual computer. This is really a variant of the point to point line technique, where the circuit switch allows each system to have what amounts to a direct line to every other system. This technology is not widely used within the TCP/IP community, largely because the TCP/IP protocols assume that the lowest level handles isolated datagrams. When a continuous connection is needed, higher network layers implement it using datagrams. This datagram-oriented technology does not match a circuit-oriented environment very closely. In order to use circuit switching technology, the IP software must be modified to be able to build and tear down virtual circuits as appropriate. When there is a datagram for a given destination, a virtual circuit must be opened to it. The virtual circuit would be closed when there has been no traffic to that destination for some time. The major use of this technology is for the DDN (Defense Data Network). The primary interface to the DDN is based on X.25. This network appears to the outside as a distributed X.25 network. TCP/IP software intended for use with the DDN must do precisely the virtual circuit management just described. Similar techniques could be used with other circuit-switching technologies, e.g. AT&T's DataKit.

Single-level networks
In some cases new developments in wide-area networks can eliminate the need for hierarchical networks. Early hierarchical networks were set up because the only convenient network technology was Ethernet or other LAN's, and those could not span distances large enough to cover an entire campus. Thus it was necessary to use serial lines to connect LAN's in various locations. It is now possible to fi nd network technology whose characteristics are similar to Ethernet, but where a single network can span a campus. Thus it is possible to think of using a singl e large network, with no hierarchical structure. The primary limitations of a la rge single-level network are performance and reliability considerations. If a si ngle network is used for the entire campus, it is very easy to overload it. Hier archical networks can handle a larger traffic volume than single-level networks if traffic patterns have a reasonable amount of 37 locality. That is, in many ap plications, traffic within an individual department tends to be greater than tra ffic among departments. Let's look at a concrete example. Suppose there are 10 d epartments, each of which generates 1 Mb/s of traffic. Suppose futher than 90% o f that traffic is to other systems within the department, and only 10% is to oth er departments. If each department has its own network, that network only needs to handle 1 Mb/s. The backbone network connecting the department also only needs 1 Mb/s capacity, since it is handling 10% of 1 Mb/s from each department. In order to handle this situation with a single wide-area network, that network would have to be able to handle the simultaneous load from all 10 departments, which would be 10 Mb/s. However this example was carefully constructed to be favorable to the hierarchical design. If more of the traffic in the department is going to other departments, then the backbone will need a higher bandwidth. For example, suppose that a campus has a few centralized resources, e.g. mainframes and other large systems in a computing center. If most of the network traffic is from small systems attempting to get to the central system, then the argument above does not work. In this case a hierarchy may still be useful. However it doesn't reduce the bandwidth required for the long-haul network. In the example above, if all 10 departments communicated primarily with systems at the computer center, the backbone would have to be able to carry all of their traffic: 10 Mb/s. The computer center would either attach its systems directly to the backbone, or it would have a "departmental" network with a capacity of 10 Mb/s rather than the 1Mb/s needed by the other departments. The second limitation on single-level networks is reliability, maintainability and security. Wide-area networks are more difficult to diagnose and maintain than local-area networks, because problems can be introduced from any building to which the network is connected. They also make traffic visible in all locations. For these reasons, it is often sensible to handle local traffic locally, and use the wide-area network (WAN) only for traffic that actually must go between buildings. However if you have a situation where each location has only one or two computers, it may not make sense to set up a local network at each location, and a single-level network may make sense.

Mixed designs
In practice, few large networks have the luxury of adopting a theoretically pure design. It is very unlikely that any large network will be able to avoid using a hierarchical design. Suppose we set out to use a single-level network. Even if most buildings have only one or two computers, there will be some location where there are enough that a local-area network is justified. The result is a mixture of a single-level network and a hierachical network. Most buildings have their computers connected directly to the wide-area network, as with a single-level network. However in one building there is a local-area network which uses the wide-area network as a backbone, connecting to it via a switching unit. On the other side of the story, even network designers with a strong commitment to hierarchical networks are likely to find some parts of the network where it simply doesn't make economic sense to install a local-area network. So a host is put directly onto the backbone network, or tied directly to a serial line. However you should think carefully before making ad hoc departures from your design philosophy in order to save a few dollars. In the long run, network maintainability is going to depend upon your ability to make sense of what is going on in the network. The more consistent your technology is, the more likely you are to be able to maintain the network.

2.13 Switching technologies

This section will discuss the characteristics of various technologies used to switch datagrams between networks. In effect, we are trying to fill in some details about the black boxes assumed in previous sections. There are three basic types of switches, generally referred to as repeaters, bridges, and routers, or alternatively as level 1, 2 and 3 switches (based on the level of the OSI model at which they operate). Note however that there are systems that combine features of more than one of these, particularly bridges and routers. The most important dimensions on which switches vary are isolation, performance, routing and network management facilities. These will be discussed below. The most serious difference is between repeaters and the other two types of switch. Until recently, routers provided very different services from bridges. However these two technologies are now coming closer together. Routers are beginning to adopt the special-purpose hardware that has characterized bridges in the past. Bridges are beginning to adopt more sophisticated routing, isolation features, and network management, which have characterized routers in the past. There are also systems that can function as both bridge and router (brouters). This means that at the moment, the crucial decision may not be to decide whether to use a bridge or a router, but to decide what features you want in a switch and how it fits into your overall network design.

Repeaters
A repeater is a piece of equipment that connects two networks that use the same technology. It receives every data packet on each network, and retransmits it o nto the other network. The net result is that the two networks have exactly the same set of packets on them. For Ethernet or IEEE 802.3 networks there are actua lly two different kinds of repeater. (Other network technologies may not need to make this distinction). A simple repeater operates at a very low level indeed. Its primary purpose is to get around limitations in cable length caused by signa l loss or timing dispersion. It allows you to construct somewhat larger networks than you would otherwise be able to construct. It can be thought of as simply a two-way amplifier. It passes on individual bits in the signal, without doing any processing at the packet level. It even passes on collisions. That is, if a collision is generated on one of the networks connected to it, the repeater generates a collision on the other network. There is a limit to the number of repeaters that you can use in a network. The basic Ethernet design requires that signals must be able to get from one end of the network to the other within a specified amount of time. This determines a maximum allowable length. Putting repeaters in the path does not get around this limit. (Indeed each repeater adds some delay, so in some ways a repeater makes things worse). Thus the Ethernet configuration rules limit the number of repeaters that can be in any path. A "buffered repeater" operates at the level of whole data packets. Rather than passing on signals a bit at a time, it receives an entire packet from one network into an internal buffer and then retransmits it onto the other network. It does not pass on collisions. Because such low-level features as collisions are not repeated, the two networks continue to be separate as far as the Ethernet specifications are concerned. Thus there are no restrictions on the number of buffered repeaters that can be used. Indeed there is no requirement that both of the networks be of the same type. However the two networks must be sufficiently similar that they have the same packet format. Generally this means that buffered repeaters can be used between two networks of the IEEE 802.x family (assuming that they have chosen the same address length and maximum packet size), or two networks of some other related family. A pair of buffered repeaters can be used to connect two networks via a serial line. Buffered repeaters share with simple repeaters the most basic feature: they repeat every data packet that they receive from one network onto the other. Thus the two networks end up with exactly the same set of packets on them.

Bridges and routers
A bridge differs from a buffered repeater primarily in the fact that it exercizes some selectivity as to what datagrams it forwards between networks. Generally the goal is to increase the capacity of the system by keeping local traffic confined to the network on which it originates. Only traffic intended for other networks goes through the bridge. So far this description would also apply to a router. Bridges and routers differ in the way they determine what datagrams to forward. A bridge uses only the OSI level 2 address. In the case of Ethernet or IEEE 802.x networks, this is the 6-byte Ethernet or MAC-level address. (The term "MAC-level address" is more general. However for the sake of concreteness, examples in this section will assume that Ethernet is being used. You may generally replace the term "Ethernet address" with the equivalent MAC-level address for other similar technologies). A bridge does not examine the datagram itself, so it does not use the IP address or its equivalent for routing decisions. In contrast, a router bases its decisions on the IP address, or its equivalent for other protocols. There are several reasons why it matters which kind of address is used for decisions. The most basic is that it affects the relationship between the switch and the upper layers of the protocol. If forwarding is done at the level of the MAC-level address (bridge), the switch will be invisible to the protocols. If it is done at the IP level, the switch will be visible. Let's give an example. Here are two networks connected by a bridge:

           network 1          network 2
            128.6.5            128.6.4
     ==================  ================================
       |            |      |            |             |
    ___|_______   __|______|__   _______|___   _______|___
     128.6.5.2       bridge       128.6.4.3     128.6.4.4
    ___________   ____________   ___________   ___________
    computer A                   computer B    computer C

Note that the bridge does not have an IP address. As far as computers A, B, and C are concerned, there is a single Ethernet (or other network) to which they ar e all attached. This means that the routing tables must be set up so that comput ers on both networks treat both networks as local. When computer A opens a conne ction to computer B, it first broadcasts an ARP request asking for computer B's Ethernet address. The bridge must pass this broadcast from network 1 to network 2. (In general, bridges must pass all broadcasts). Once the two computers know e ach other's Ethernet addresses, communications use the Ethernet address as the destination. At that point, the bridge can start exerting some selectivity. It will only pass datagrams whose Ethernet destination address is for a machine on the other network. Thus a datagram from B to A will be passed from network 2 to 1, but a datagram from B to C will be ignored. In order to make this selection, the bridge needs to know which network each machine is on. Most modern bridges build up a table for each network to which they are connected, listing the Ethernet addresses of machines known to be on that network. They do this by watching all of the datagrams on each network. When a datagram first appears on network 1, it is reasonable to conclude that the Ethernet source address corresponds to a machine on network 1. Note that a bridge must look at every datagram on the Ethernet, for two different reasons. First, it may use the source address to learn which machines are on which network. Second, it must look at the destination address in order to decide whether it needs to forward the datagram to the other network. As mentioned above, generally bridges must pass broadcasts from one network to the other. Broadcasts are often used to locate a resource. The ARP request is a typical example of this. Since the bridge has no way of knowing what host is going to answer the broadcast, it must pass it on to the other network. Some bridges have user-selectable filters. With them, it is possible to block some broadcasts and allow others. You might allow ARP broadcasts (which are essential for IP to function), but confine less essential broadcasts to one network. For example, you might choose not to pass rwhod broadcasts, which some systems use to keep track of every user logged into every other system. You might decide that it is sufficient for rwhod to know about the systems on a single segment of the network. Now let's take a look at two networks connected by a router:

           network 1                         network 2
            128.6.5                           128.6.4
     ====================      =====================================
       |              |          |              |                |
    ___|_______   ____|__________|____   _______|___      _______|___
     128.6.5.2    128.6.5.1  128.6.4.1    128.6.4.3        128.6.4.4
    ___________   ____________________   ___________      ___________
    computer A           router          computer B       computer C

Note that the router has IP addresses assigned to each interface. The computers' routing tables are set up to forward through appropriate address. For example, computer A has a routing entry saying that it should use the router 128.6.5.1 to get to subnet 128.6.4. Because the computers know about the router, the router does not need to scan all the packets on the Ethernet. The computers will send datagrams to it when appropriate. For example, suppose computer A needs to send a message to computer B. Its routing table will tell it to use router 128.6.5.1. It will issue an ARP request for that address. The router will respond to the ARP request, just as any host would. From then on, datagrams destined for B will be sent with the router's Ethernet address.

More about bridges
There are several advantages to using the MAC-level address, as a bridge does. First, every packet on an Ethernet or IEEE network has such an address. The address is in the same place for every packet, whether it is IP, DECnet, or some other protocol. Thus it is relatively fast to get the address from the packet. A router must decode the entire IP header, and if it is to support protocols other than IP, it must have software for each such protocol. This means that a bridge automatically supports every possible protocol, whereas a router requires specific provisions for each protocol it is to support. However there are also disadvantages. The one that is intrinsic to the design of a bridge is: A bridge must look at every packet on the network, not just those addressed to it. Thus it is possible to overload a bridge by putting it on a very busy network, even if very little traffic is actually going through the bridge.

However there is another disadvantage that is based on the way bridges are usua lly built. It is possible in principle to design bridges that do not have this d isadvantage. It stems from the fact that bridges do not have a complete routing table that describes the entire system of networks. They simply have a list of t he Ethernet addresses that lie on each of its networks. This means: Networks tha t use bridges cannot have loops in them. If there were a loop, some bridges would see traffic from the same Ethernet address coming from both directions, and would be unable to decide which table to put that address in. Note that any parallel paths to the same destination constitute a loop. This means that multiple paths cannot be used for purposes of splitting the load or providing redundancy. There are some ways of getting around the problem of loops. Many bridges allow configurations with redundant connections, but turn off links until there are no loops left. Should a link fail, one of the disabled ones is then brought back into service. Thus redundant links can still buy you extra reliability. But they can't be used to provide extra capacity. It is also possible to build a bridge that will make use of parallel point to point lines, in the one special case where those lines go between a single pair of bridges. The bridges would treat the two lines as a single virtual line, and use them alternately in round-robin fashion. The process of disabling redundant connections until there are no loops left is called a "spanning tree protocol". This name comes from the fact that a tree is defined as a pattern of connections with no loops. Thus one wants to disable connections until the connections that are left form a tree that "spans" (includes) all of the networks in the system. In order to do this, all of the bridges in a network 43 system must communicate among themselves. The IEEE has standardized this protocol. Note that there is a tendency for the resulting spanning tree to result in high network loads on certain parts of the system. The networks near the "top of the tree" handle all traffic between distant parts of the network. In a network that uses routers, it would be possible to put in an extra link between parts of the network that have heavy traffic between them. However such extra links cannot be used by a set of bridges.

More about routers
Routers have their own advantages and disadvantages. In general a router is more complex to design and to administer than a bridge. A router must participate in all of the protocols that it is designed to forward. For example, an IP router must respond to ARP requests. The IP standards also require it to completely process the IP header, decrementing the time to live field and obeying any IP options. Routers are designed to handle more complex network topologies than bridges. As such, they have a different (and more complex) set of decisions to make. In general a bridge has fairly simple decision to make: should it forward a datagram, and if so which interface should it send the datagram out? When a router forwards a datagram, it must decide what host or router to send the datagram to next. If the router sends a datagram back onto the same network it came from, it should also issue a redirect to the source of the datagram telling it to use a better route. Many routers can also handle parallel paths. If there are several equally good paths to a destination, the router will alternate among them in round-robin fashion. (This is done by some bridges also, though it is less common there. In both cases, there are some issues raised by round-robin alternation. It tends to lead to datagrams arriving in an order different than the order in which they were sent. This can complicate processing by the destination host. Some older TCP/IP implementations have bugs in handling out of order datagrams). In order to handle these decisions, a router will typically have a routing table that looks very much like a host's. As with host routing tables, a router's table contains an entry for each possible network number. For each network, there is either an entry saying that that network is connected directly to the router, or there is an entry saying that traffic for that network should be forwarded through some other router or routers.

Comparing the switching technologies
Repeaters, buffered repeaters, bridges, and routers form a spectrum. Those devices near the beginning of the list are best for smaller networks. They are less expensive, and easier to set up, but less general. Those near the end of the list are suitable for building more complex networks. Many networks will contain a mixture of switch types, with repeaters being used to connect a few nearby network segments, bridges used for somewhat larger areas, and routers used for long-distance links. Note that this document so far has assumed that only routers are being used. The section on setting up a host described how to set up a routing table listing the routers to use to get to various networks. Repeaters and bridges are invisible to IP. So as far as previous sections are concerned, networks connected by them are to be considered a single network. We have seen before how to configure a host in the case where several subnets are carried on a single physical network. The same configuration should be used when several subnets are connected by repeaters or bridges. As mentioned above, the most important dimensions on which switches vary are isolation, performance, routing, network management.

Isolation.Generally people use switches to connect networks to each other. So they are normally thinking of gaining connectivity, not providing isolation. However isolation is worth thinking about. If you connect two networks and provide no isolation at all, then any network problems on other networks suddenly appear on yours as well. Also, the two networks together may have enough traffic to overwhelm your network. Thus it is well to think of choosing an appropriate level of protection. Isolation comes in two kinds: isolation against malfunctions and traffic isolation. In order to discuss isolation of malfunctions, we have to have a taxonomy of malfunctions. Here are the major classes of malfunctions, and which switches can isolate them:
•  Electrical faults, e.g. a short in the cable or some sort of fault that distorts the signal. All types of switch will confine this to one side of the switch: repeater, buffered repeater, bridge, router. These are worth protecting against, although their frequency depends upon how often your cables are changed or disturbed. It is rare for this sort of fault to occur without some disturbance of the cable.
•  Transceiver and controller problems that general signals that are valid electrically but nevertheless incorrect (e.g. a continuous, infinitely long packet, spurious collisions, never dropping carrier). All except the simple repeater will confine this: buffered repeater, bridge, router. (Such problems are not very common).
•  Software malfunctions that lead to excessive traffic between particular hosts (i.e. not broadcasts). Bridges and routers will isolate these. (This type of failure is fairly rare. Most software and protocol problems generate broadcasts).
•  Software malfunctions that lead to excessive broadcast traffic. Routers will isolate these. Generally bridges will not, because they must pass broadcasts. Bridges with user-settable filtering can protect against some broadcast malfunctions. However in general bridges must pass ARP, and most broadcast malfunctions involve ARP. This problem is not severe on single-vendor networks where software is under careful control. However sites with complex network environments or experimental network software may see problems of this sort regularly.

Traffic isolation is provided by bridges and routers. The most basic decision is how many computers can be put onto a network without overloading its capacity. This requires knowledge of the capacity of the network, but also how the hosts will use it. For example, an Ethernet may support hundreds of systems if all the network is used for is remote logins and an occasional file transfer. However if the computers are diskless, and use the network for swapping, an Ethernet will support between 10 and 40, depending upon their speeds and I/O rates. When you have to put more computers onto a network than it can handle, you split it into several networks and put some sort of switch between them. If you do the split correctly, most of the traffic will be between machines on the same piece. This means putting clients on the same network as their servers, putting terminal servers on the same network as the hosts that they access most commonly, etc. Bridges and routers generally provide similar degrees of traffic isolation. In both cases, only traffic bound for hosts on the other side of the switch is passed. However see the discussion on routing.

Performance. Absolute performance limits are becoming less of an i ssue as time goes on, since the switching technology is improving. Generally rep eaters can handle the full bandwidth of the network. (By their very nature, a si mple repeater must be able to do so). Bridges and routers often have performance limitations of various sorts. Bridges have two numbers of interest: packet scan ning rate and throughput. As explained above, a bridge must look at every packet on the network, even ones that it does not forward. The number of packets per s econd that it can scan in this way is the packet scanning rate. Throughput appli es to both bridges and routers. This is the rate at which they can forward traff ic. Generally this depends upon datagram size. Normally the number of datagrams per second that a unit can handle will be greater for short datagrams than long ones. Early models of bridge varied from a few hundred datagrams per second to around 7000. The higher speeds are for equipment that uses special-purpose hardware to speed up the process of scanning packets. First-generation routers varied from a few hundred datagrams per second to 1000 or more. However third-generation routers are now available, using special-purpose hardware of the same sophistication as that used by bridges. They can handle on the order of 100000 datagrams per second. Thus at the moment high-performance bridges and routers can switch most of the bandwidth of an Ethernet. This means that performance should no longer be a basis for choosing between types of switch. However within a given type of switch, there are still specific models with higher or lower capacity. And there may still be differences in price/performance. This is particularly true at the low end. The least expensive bridges are currently less than half the price of the least expensive router. Unfortunately there is no single number on which you can base performance estimates. The figure most commonly quoted is packets per second. Be aware that most vendors count a datagram only once as it goes through a router, but that one prominent vendor counts datagrams twice. Thus their switching rates must be deflated by a factor of 2. Also, when comparing numbers make sure that they are for datagrams of the same size. A simple performance model is processing time = switching time + datagram size * time per byte. That is, the time to switch a datagram is normally a constant switching time, representing interrupt latency, header processing, routing table lookup, etc., plus a component proportional to datagram size, representing the time needed to do any datagram copying. One reasonable approach to reporting performance is to give datagrams per second for minimum and maximum size datagrams. Another is to report limiting switching speed in datagrams per second and throughput in bytes per second, i.e. the two terms of the equation above.

Routing. For a repeater this is not an issue, since repeaters forward every packet. The routing strategy for a bridge turns into two decisions: (1) enabling and disabling links in order to maintain the spanning tree, and (2) deciding whether it should forward any particular packet, and out what interface (if the bridge is capable of handling more than two interfaces). The second decision is usually based on a table of MAC-level addresses. As described above, this is built up by scanning traffic visible from each interface. The goal is to forward those packets whose destination is on the other side of the bridge. This algorithm requires that the network configuration have no loops or redundant lines. Less sophisticated bridges leave this up to the system designer. With these bridges, you must set up your network so that there are no loops in it. More sophisticated bridges allow arbitrary topology, but disable links until no loops remain. This provides extra reliability. If a link fails, an alternative link will be turned on automatically. Bridges that work this way have a protocol that allows them to detect when a unit must be disabled or reenabled, so that at any instant the set of active links forms a "spanning tree". If you require the extra reliability of redundant links, make sure that the bridges you use can disable and enable themselves in this way. If you buy bridges from more than one vendor, make sure that their spanning-tree protocols will interoperate. Routers generally allow arbitrary network topologies, including loops and redundant links. Because of their more general routing algorithms, routers must maintain a model of the entire network topology. Different routing techniques maintain models of greater or lesser complexity, and use the data with varying degrees of sophistication. Routers that handle IP should generally support the two Internet standard routing protocols: RIP (Routing Information Protocol) and EGP (External Routers Protocol). EGP is a special-purpose protocol for use in networks where there is a backbone under a separate administration. It allows exchange of reachability information with the backbone in a controlled way. If you are a member of such a network, your router must support EGP. This is becoming common enough that it is probably a good idea to make sure that all routers support EGP. RIP is a protocol designed to handle routing within small to moderate size networks, where line speeds do not differ radically. Its primary limitations are:
•  It cannot be used with networks where any path goes through more than 15 routers. This range may be further reduced if you use an optional feature for giving a slow line a weight larger than one.
•  It cannot share traffic between parallel lines (although some implementations allow this if the lines are between the same pair of routers).
•  It cannot adapt to changes in network load.
•  It is not well suited to situations where there are alternative routes through lines of very different speeds.
•  It may not be stable in networks where lines or routers change a lot.

Today, some vendors supply proprietary modifications to RIP that improve its op eration with EGP or increase the maximum path length beyond 15, but do not other wise modify it very much. If you expect your network to involve routers from mor e than one vendor, you should generally require that all of them support RIP, si nce this is the only routing protocol that is generally available. If you expect to use a more sophisticated protocol in addition, it may be useful for the rout ers to translate between their own protocol and RIP. However for very large or complex networks, there may be no choice but to use some other protocol throughout. More sophisticated routing protocols are possible. The primary ones being considered today are CISCO System's IGRP, and protocols based on the SPF (shortest-path first) algorithms. In general these protocols are designed for larger or more complex networks. They are usually stable under a wider variety of conditions, and they can handle arbitrary combinations of line type and speed. Some of them allow you to split traffic among parallel paths, to get better overall throughput. Some newer technologies may allow the network to adjust to take into account paths that are overloaded. (There are very serious problems with maintaining stable routing when this is done). There are enough variations among routing technology, and it is changing rapidly enough, that you should discuss your proposed network topology in detail with all of the vendors that you are considering. Make sure that their technology can handle your topology, and can support any special requirements that you have for sharing traffic among parallel lines, and for adjusting topology to take into account failures. In the long run, we expect one or more of these newer routing protocols to attain the status of a standard, at least on a de facto basis. One additional routing topic to consider is policy-based routing. In general routing protocols are designed to find the shortest or fastest possible path for every datagram. In some cases, this is not desired. For reasons of security, cost accountability, etc., you may wish to limit certain paths to certain uses. Most routers now have some ability to control the spread of routing information so as to give you some administrative control over the way routes are used. Different routers vary in the degree of control that they support. Make sure that you discuss any requirements that you have for control with all prospective router vendors.

Network management. It covers a wide variety of topics. In general it includes gathering statistical data and status information about parts of yo ur network, and taking action as necessary to deal with failures and other chang es. The most primitive technique for network monitoring is periodic "pinging< /I>" of critical hosts. Pinging is a monitoring technique that depends on an "ec ho" datagram. This is a specific type of datagram that requests an immediate rep ly. Most TCP/IP implementations contain a program (usually called "ping") that 4 9 sends an echo to a specified host. If you get a reply, you know that the host is up, and that the network connection to the host works. If you don't get a rep ly, you know that something is wrong with one of the other. By pinging a reasona ble sample of hosts, you can normally tell what is going on. If all the hosts on a network suddenly stop returning pings, it is reasonable to conclude that the connection to that network has gone bad. If one host stops returning pings, but other hosts on the same network still do, then it is reasonable to conclude that the host has crashed. More sophisticated network monitoring requires the abilit y to get specific status and statistical information from various devices on the network. These should include various sorts of datagram counts, as well as coun ts of errors of various kinds. This data is likely to be most detailed in a rout er, since the router classifies datagrams using the protocols, and may even resp ond to certain types of datagram itself. However bridges and even buffered repea ters can certainly have counts of datagrams forwarded, interface errors, etc. It should be possible to collect this data from a central monitoring point. There is now an official TCP/IP approach to network monitoring: SNMP. It has a more co mplete set of information that can be monitored, called the MIB (Management I nformation Base). Eventually it is expected that there will be a TCP/IP equi valent of CMIS, the ISO network monitoring service. However CMIS, and its protoc ols, CMIP, are still in the experimental stages. In general terms all of these p rotocols accomplish the same thing: They allow you to collect critical informati on in a uniform way from all vendors' equipment. You send commands as UDP datagr ams from a network management program running on some host in your network. Gene rally the interaction is fairly simple, with a single pair of datagrams exchange d: a command and a response. At the moment security is fairly simple. It is poss ible to require what amounts to a password in the command. More elaborate, encry ption-based security is being developed. You will probably want to configure the network management tools at your disposal to do several different things. For s hort-term network monitoring, you will want to keep track of switches crashing o r being taken down for maintenance, and of failure of communications lines and o ther hardware. It is possible to configurate SNMP to issue "traps" (unsolicited messages) to a specified host or list of hosts when some of these critical event s occur (e.g. lines up and down). However it is unrealistic to expect a switch t o notify you when it crashes. It is also possible for trap messages to be lost d ue to network failure or overload. Thus you can't depend completely on traps. Yo u should also poll your switches regularly to gather information. Various displa ys are available, including a map of your network where items change color as th eir status changes, and running "strip charts" that show datagram rates and othe r items through selected switches. You may also want to be able to take actions to reconfigure the system in response to failures, although security issues make some managers nervous about doing that through the existing management protocol s. The second type of monitoring you are likely to want to do is to collect info rmation for use in periodic reports on network utilization and performance. For this, you need to sample each switch perodically, and retrieve numbers of interest. Monthly summaries are produced giving traffic through each router, and a few key error rates chosen to indicate a router that is being overloaded (datagrams dropped in input and output). It should be possible to use monitoring techniques of this kind with most types of switch. At the moment, simple repeaters do not report any statistics. Since they do not generally have processors in them, doing so would cause a major increase in their cost. However it should be possible to put network management software in buffered repeaters, bridges, and routers. Routers are the most likely to contain sophisticated network management software. Most router vendors that handle IP are expected to implement the monitoring protocols described above. Many bridge vendors make some provisions for collecting performance data. Since bridges are not protocol-specific, most of them do not have the software necessary to implement TCP/IP-based network management protocols. In some cases, monitoring can be done only by typing commands to a directly-attached console. In other cases, it is possible to gather data via the network, but the monitoring protocol is ad hoc or even proprietary. Except for very small networks, you should probably insist that any switch more complex than a simple repeater should collect statistics and provide some way of querying them remotely. Portions of the network that do not support such operations can be monitored by pinging. However ping simply detects gross failures. It does not allow you to look at the noise level of a serial line and other quantities needed to do high-quality maintenance. In the long run, you can expect the most software to be available for standard protocols such as SNMP and CMIS. However proprietary monitoring tools may be sufficient as long as they work with all of the equipment that you have.

A final evaluation. Here is a summary of the places where each kind of switch technology is normally used:
•  Repeaters are normally confined to a single building. Since they provide no traffic isolation, you must make sure that the entire set of networks connected by repeaters can carry the traffic from all of the computers on it. Since they generally provide no network monitoring tools, you will not want to use repeaters for a link that is likely to fail.
•  Bridges and routers should be placed sufficiently frequently to break your network into pieces for which the traffic volume is manageable. You may want to place bridges or routers even in places where traffic level alone would not require them for network monitoring reasons.
•  Because bridges must pass broadcast datagrams, there is a limit to the size network you can construct using them. It is probably a good idea to limit the network connected by bridges to a hundred systems or so. This number can be increased somewhat for bridges with good facilities for filtering.
•  Because certain kinds of network misbehavior will be passed, bridges should be used only among portions of the network where a single group is responsible for diagnosing problems. You have to be crazy to use a bridge between networks owned by different organizations. Portions of your network where experiments are being done in network technology should always be isolated from the rest of the network by routers.
•  For many applications it is more important to choose a product with the right combination of performance, network management tools, and other features than to make the decision between bridges and routers.

2.14 Configuring routers

This section deals with configuration issues that are specific to routers. Rout ers that handle IP are themselves Internet hosts. Thus the discussions above on configuring addresses and routing information apply to routers as well as to hos ts. The exact way you configure a router will depend upon the vendor. In some ca ses, you edit files stored on a disk in the router itself. However for reliabili ty reasons most routers do not have disks of their own. For them, configuration information is stored in non-volatile memory or in configuration files that are uploaded from one or more hosts on the network. At a minimum, configuration invo lves specifying the IP address and address mask for each interface, and enabling an appropriate routing protocol. However generally a few other options are desi rable. There are often parameters in addition to the IP address that you should set for each interface. One important parameter is the broadcast address. As exp lained above, older software may react badly when broadcasts are sent using the new standard broadcast address. For this reason, some vendors allow you to choos e a broadcast address to be used on each interface. It should be set using your knowledge of what computers are on each of the networks. In general if the compu ters follow current standards, a broadcast address of 255.255.255.255 should be used. However older implementations may behave better with other addresses, part icularly the address that uses zeros for the host number. (For the network 128.6 this would be 128.6.0.0. For compatibility with software that does not implemen t subnets, you would use 128.6.0.0 as the broadcast address even for a subnet su ch as 128.6.4). You should watch your network with a network monitor and see the results of several different broadcast address choices. If you make a bad choic e, every time the router sends a routing update broadcast, many machines on your network will respond with ARP's or ICMP errors. Note that when you change the b roadcast address in the router, you may need to change it on the individual comp uters as well. Generally the idea is to change the address on the systems that y ou can configure to give behavior that is compatible with systems that you can't configure. Other interface parameters may be necessary to deal with peculiariti es of the network it is connected to. For example, many routers test Ethernet in terfaces to make sure that the cable is connected and the transceiver is working correctly. Some of these tests will not work properly with the older Ethernet v ersion 1 transceivers. If you are using such a transceiver, you would have to di sable this keep-alive testing. Similarly, routers connected by a serial line nor mally do regular testing to make sure that the line is still working. There can be situations where this needs to be disabled. Often you will have to enable fea tures of the software that you want to use. For example, it is often necessary t o turn on the network management protocol explicitly, and to give it the name or address of a host that is running software to accept traps (error messages). Mo st routers have options that relate to security. At a minimum, this may include setting password for making changes remotely. If you need to control access to c ertain parts of your network, you will also need to define access control lists or whatever other mechanism your router uses. Routers that load configuration in formation over the network present special issues. When such a router boots, it sends broadcast requests of various kinds, attempting to find its Internet addre ss and then to load configuration information. Thus it is necessary to make sure that there is some computer that is prepared to respond to these requests. In s ome cases, this is a dedicated micro running special software. In other cases, g eneric software is available that can run on a variety of machines. You should c onsult your vendor to make sure that this can be arranged. For reliability reaso ns, you should make sure that there is more than one host with the information a nd programs that your routers need. In some cases you will have to maintain seve ral different files. For example, some UNIX based routers use a program called " bootp" to supply their Internet address, and they then load the code and configu ration information using TFTP. This means that is necessary to maintain a file f or bootp that contains Ethernet and Internet addresses for each router, and a se t of files containing other configuration information for each router. If your n etwork is large, it is worth taking some trouble to make sure that this informat ion remains consistent. You must keep master copies of all of the configuration information on a single computer, and distribute it to other systems when it changes, using the UNIX utilities make and rdist. If your router has an option to store configuration information in non-volatile memory, you will eliminate some of these logistical headaches. However this presents its own problems. The contents of non-volatile memory should be backed up in some central location. It will also be harder for network management personnel to review configuration information if it is distributed among the routers. Starting a router is particularly challenging if it loads configuration information from a distant portion of the network. Routers that expect to take configuration information from the network generally issue broadcast requests on all of the networks to which they are connected. If there is a computer on one of those networks that is prepared to respond to the request, things are straightforward. However some routers may be in remote locations where there are no nearby computer systems that can support the necessary protocols. In this case, it is necessary to arrange for the requests to be routed back to the network where there are appropriate computers. This requires what is strictly speaking a violation of the basic design philosophy for routers. Generally a router should not allow broadcasts from one network to pass through to an adjacent network. In order to allow a router to get information from a computer on a different network, at least one of the routers in between will have to be configured to pass the particular class of broadcasts used to retrieve this information. If you have this sort of configuration, you should test the loading process regularly. It is not unusual to find that routers do not come up after a power failure because someone changed the configuration of another router and made it impossible to load some necessary information.

The final topic to be considered is configuring routing. This is more complex f or a router than for a normal host. Most TCP/IP experts recommend that routing b e left to the routers. Thus hosts may simply have a default route that points to the nearest router. Of course the routers themselves can't get by with this. Th ey need to have complete routing tables. In order to understand how to configure a router, we have to look in a bit more detail at how routers communicate route s. When you first turn on a router, the only networks it knows about are the one s that are directly connected to it. (They are specified by the configuration in formation). In order to find out how to get to more distant parts of the network , it engages in some sort of "routing protocol". A routing protocol is simply a protocol that allows each router to advertise which networks it can get to, and to spread that information from one router to the next. Eventually every router should know how to get to every network. There are different styles of routing p rotocol. In one common type, routers talk only to nearby routers. In another typ e, every router builds up a database describing every other router in the system . However all of the protocols have some way for each router in the system to fi nd out how to get to every destination. A metric is some number or set of number s that can be used to compare routes. The routing table is constructed by gather ing information from other routers. If two other routers claim to be able to get to the same destination, there must be some way of deciding which one to use. T he metric is used to make that decision. Metrics all indicate in some general se nse the "cost" of a route. This may be a cost in dollars of sending datagrams ov er that route, the delay in milliseconds, or some other measure. The simplest me tric is just a count of the number of routers along the path. This is referred t o as a "hop count". Generally this metric information is set in the router confi guration files, or is derived from information appearing there. At a minimum, ro uting configuration is likely to consist of a command to enable the routing prot ocol that you want to use. Most vendors will have a prefered routing protocol. U nless you have some reason to choose another, you should use that. The normal re ason for choosing another protocol is for compatibility with other kinds of rout er. For example, your network may be connected to a national backbone network th at requires you to use EGP (exterior router protocol) to communicate routes with it. EGP is only appropriate for that specific case. You should not use EGP with in your own network, but you may need to use it in addition to your regular rout ing protocol to communicate with a national network. If your own network has sev eral different types of router, then you may need to pick a routing protocol tha t all of them support. At the moment, this is likely to be RIP (Routing Informat ion Protocol). Depending upon the complexity of your network, you could use RIP throughout it, or use a more sophisticated protocol among the routers that suppo rt it, and use RIP only at the boundary between routers from different vendors. Assuming that you have chosen a routing protocol and turned it on, there are som e additional decisions that you may need to make. One of the more basic configur ation options has to do with supplying metric information. As indicated above, m etrics are numbers which are used to decide which route is the best. Unsophisticated routing protocols, e.g. RIP, normally just count hops. So a route that passes through 2 routers would be considered better than one that passes through 3. Of course if the latter route used 1.5 Mb/s lines and the former 9600 b/s lines, this would be the wrong decision. Thus most routing protocols allow you to set parameters to take this sort of thing into account. With RIP, you would arrange to treat the 9600 b/s line as if it were several hops. You would increase the effective hop count until the better route was chosen. More sophisticated protocols may take the bit rate of the line into account automatically. However you should be on the lookout for configuration parameters that need to be set. Generally these parameters will be associated with the particular interface. For example, with RIP you would have to set a metric value for the interface connected to the 9600 b/s line. With protocols that are based on bit rate, you might need to specify the speed of each line (if the router cannot figure it out automatically). Most routing protocols are designed to let each router learn the topology of the entire network, and to choose the best possible route for each datagram. In some cases you may not want to use the "best" route. You may want traffic to stay out of a certain portion of the network for security or cost reasons. One way to institute such controls is by specifying routing options. These options are likely to be different for different vendors. But the basic strategy is that if the rest of the network doesn't know about a route, it won't be used. So controls normally take the form of limiting the spread of information about routes whose use you want to control. Note that there are ways for the user to override the routing decisions made by your routers. If you really need to control access to a certain network, you will have to do two separate things:

•  Use routing controls to make sure that the routers use only the routes you want them to.
•  Use access control lists on the routers that are adjacent to the sensitive networks.

These two mechanisms act at different levels. The routing controls affect what happens to most datagrams: those where the user has not specified routing manually. Your routing mechanism must be set up to choose an acceptable route for them. The access control list provides an additional limitation which prevents users from supplying their own routing and bypassing your controls. For reliability and security reasons, there may also be controls to allow you to list the routers from which you will accept information. It may also be possible to rank routers by priority. For example, you might decide to listen to routes from within your own organization before routes from other organizations or other parts of the organization. This would have the effect of having traffic use internal routes in preference to external ones, even if the external ones appear to be better. If you use several different routing protocols, you will probably have some decisions to make regarding how much information to pass among them. Since multiple routing protocols are often associated with multiple organizations, you must be sure to make these decisions in consultation with management of all of the relevant networks. Decisions that you make may have consequences for the other network which are not immediately obvious. You might think it would be best to configure the router so that everything it knows is passed on by all routing protocols. However here are some reasons why you may not want to do so:
•  The metrics used by different routing protocols may not be comparable. If you are connected to two different external networks, you want to specify that one should always be used in preference to the other, or that the nearest one should be used, rather than attempting to compare metric information received from the two networks to see which has the better route.
•  EGP is particularly sensitive, because the EGP protocol cannot handle loops. Thus there are strict rules governing what information may be communicated to a backbone that uses EGP. In situations where EGP is being used, management of the backbone network should help you configure your routing.
•  If you have slow lines in your network (9600 b/s or slower), you may prefer not to send a complete routing table throughout the network. If you are connected to an external network, you may prefer to treat it as a default route, rather than to inject all of its routing information into your routing protocol.