hedrick@aramis.rutgers.edu (Charles Hedrick) (07/25/88)
Introduction
to
Administration
of an
Internet-based
Local Network
C R
C S
Computer Science Facilities Group
C I
L S
RUTGERS
The State University of New Jersey
Center for Computers and Information Services
Laboratory for Computer Science Research
24 July 1988
This is an introduction for people who intend to set up or administer
a network based on the Internet networking protocols (TCP/IP).
Copyright (C) 1988, Charles L. Hedrick. Anyone may reproduce this
document, in whole or in part, provided that: (1) any copy or
republication of the entire document must show Rutgers University as
the source, and must include this notice; and (2) any other use of
this material must reference this manual and Rutgers University, and
the fact that the material is copyright by Charles Hedrick and is used
by permission.
Unix is a trademark of AT&T Technologies, Inc.
Table of Contents
1. The problem 1
2. Routing and Addressing 2
3. Choosing an addressing structure 3
3.1 Should you subdivide your address space? 5
3.2 Subnets vs. multiple network numbers 5
3.3 How to allocate subnet or network numbers 6
3.3.1 Dealing with multiple "virtual" subnets on one 7
network
3.4 Choosing an address class 8
4. Setting up routing for an individual computer 9
4.1 How datagrams are routed 11
4.2 Fixed routes 13
4.3 Routing redirects 14
4.4 Other ways for hosts to find routes 16
4.4.1 Spying on Routing 16
4.4.2 Proxy ARP 17
4.4.3 Moving to New Routes After Failures 22
5. Bridges and Gateways 24
5.1 Alternative Designs 25
5.1.1 A mesh of point to point lines 26
5.1.2 Circuit switching technology 27
5.1.3 Single-level networks 27
5.1.4 Mixed designs 28
5.2 An introduction to alternative switching technologies 29
5.2.1 Repeaters 29
5.2.2 Bridges and gateways 30
5.2.3 More about bridges 32
5.2.4 More about gateways 34
5.3 Comparing the switching technologies 34
5.3.1 Isolation 35
5.3.2 Performance 36
5.3.3 Routing 37
5.3.4 Network management 39
5.3.5 A final evaluation 41
5.4 Configuring routing for gateways 44
i
This document is intended to help people who planning to set up a new
network based on the Internet protocols, or to administer an existing
one. It assumes a basic familiarity with the TCP/IP protocols,
particularly the structure of Internet addresses. A companion paper,
"Introduction to the Internet Protocols", may provide a convenient
introduction. This document does not attempt to replace technical
documentation for your specific TCP/IP implementation. Rather, it
attempts to give overall background that is not specific to any
particular implementation. It is directed specifically at networks of
"medium" complexity. That is, it is probably appropriate for a
network involving several dozen buildings. Those planning to manage
larger networks will need more preparation than you can get by reading
this document.
In a number of cases, commands and output from Berkeley Unix are
shown. Most computer systems have commands that are similar in
function to these. It seemed more useful to give some actual examples
that to limit myself to general talk, even if the actual output you
see is slightly different.
1. The problem
This document will emphasize primarily "logical" network architecture.
There are many documents and articles in the trade press that discuss
actual network media, such as Ethernet, Token Ring, etc. What is
generally not made clear in these articles is that the choice of
network media is generally not all that critical for the overall
design of a network. What can be done by the network is generally
determined more by the network protocols supported, and the quality of
the implementations. In practice, media are normally chosen based on
purely pragmatic grounds: what media are supported by the particular
types of computer that you have to connect. Generally this means that
Ethernet is used for medium-scale systems, Ethernet or a network based
on twisted-pair wiring for micro networks, and specialized high-speed
networks (typically token ring) for campus-wide backbones, and for
local networks involving super-computer and other very high-
performance applications.
Thus this document assumes that you have chosen and installed
individual networks such as Ethernet or token ring, and your vendor
has helped you connect your computers to these network. You are now
faced with the interrelated problems of
- configuring the software on your computers
- finding a way to connect individual Ethernets, token rings, etc.,
to form a single coherent network
- connecting your networks to the outside world
My primary thesis in this document is that these decisions require a
bit of advance thought. In fact, most networks need an
1
"architecture". This consists of a way of assigning addresses, a way
of doing routing, and various choices about how hosts interact with
the network. These decisions need to be made for the entire network,
preferably when it is first being installed.
2. Routing and Addressing
Many of the decisions that you need to make in setting up TCP/IP
depend upon routing, so it will be best to give a bit of background on
that topic now. I will return to routing in a later section when
discussing gateways and bridges. In general, IP datagrams pass
through many networks while they are going between the source and
destination. Here's a typical example. (Addresses used in the
examples are taken from Rutgers University.)
network 1 network 2 network 3
128.6.4 128.6.21 128.121
============================ ========== ================
| | | | | | |
___|______ _____|____ __|____|__ __|____|____ ___|________
128.6.4.2 128.6.4.3 128.6.4.1 128.6.21.1 128.121.50.2
128.6.21.2 128.121.50.1
__________ __________ __________ ____________ ____________
computer A computer B gateway R gateway S computer C
This diagram shows three normal computer systems, two gateways, and
three networks. The networks might be Ethernets, token rings, or any
other sort. Network 2 could even be a single point to point line
connecting gateways R and S.
Note that computer A can send datagrams to computer B directly, using
network 1. However it can't reach computer C directly, since they
aren't on the same network. There are several ways to connect
separate networks. This diagram assumes that gateways are used. (In a
later section, we'll look at an alternative.) In this case, datagrams
going between A and C must be sent through gateway R, network 2, and
gateway S. Every computer that uses TCP/IP needs appropriate
information and algorithms to allow it to know when datagrams must be
sent through a gateway, and to choose an appropriate gateway.
Routing is very closely tied to the choice of addresses. Note that
the address of each computer begins with the number of the network
that it's attached to. Thus 128.6.4.2 and 128.6.4.3 are both on
network 128.6.4. Next, notice that gateways, whose job is to connect
networks, have an address on each of those networks. For example,
gateway R connects networks 128.6.4 and 128.6.21. Its connection to
network 128.6.4 has the address 128.6.4.1. Its connection to network
128.6.21 has the address 128.6.21.2.
Because of this association between addresses and networks, routing
decisions can be based strictly on the network number of the
2
destination. Here's what the routing information for computer A might
look like:
network gateway metric
128.6.4 none 0
128.6.21 128.6.4.1 1
128.121 128.6.4.1 2
From this table, computer A can tell that datagrams for computers on
network 128.6.4 can be sent directly, and datagrams for computers on
networks 128.6.21 and 128.121 need to be sent to gateway R for
forwarding. The "metric" is used by some routing algorithms as a
measure of how far away the destination is. In this case, the metric
simply indicates how many gateways the datagram has to go through.
(This is often referred to as a "hop count".)
When computer A is ready to send a datagram, it examines the
destination address. The network number is taken from the beginning
of the address and looked up in the routing table. The table entry
indicates whether the packet should be sent directly to the
destination or to a gateway.
Note that a gateway is simply a computer that is connected to two
different networks, and is prepared to forward packets between them.
In many cases it is most efficient to use special-purpose equipment
designed for use as a gateway. However it is perfectly possible to
use ordinary computers as gateways, as long as they have more than one
network interface, and their software is prepared to forward
datagrams. Most major TCP/IP implementations (even for
microcomputers) are designed to let you use your computer as a
gateway. However some of this software has limitations that can cause
trouble for your network.
3. Choosing an addressing structure
The first comment to make about addresses is a warning: Before you
start using a TCP/IP network, you must get one or more official
network numbers. TCP/IP addresses look like this: 128.6.4.3. This
address is used by one computer at Rutgers University. The first part
of it, 128.6, is a network number, allocated to Rutgers by a central
authority. Before you start allocating addresses to your computers,
you must get an official network number. Unfortunately, some people
set up networks using either a randomly-chosen number, or a number
taken from examples in vendor documentation. While this may work in
the short run, it is a very bad idea for the long run. Eventually,
you will want to connect your network to some other organization's
network. Even if your organization is highly secret and very
concerned about security, somewhere in your organization there is
going to be a research computer that ends up being connected to a
nearby university. That university will probably be connected to a
large-scale national network. As soon as one of your datagrams
3
escapes your local network, the organization you are talking to is
going to become very confused, because the addresses that appear in
your datagrams are probably officially allocated to someone else.
The solution to this is simple: get your own network number from the
beginning. It costs nothing. If you delay it, then sometime years
from now you are going to be faced with the job of changing every
address on a large network. Network numbers are currently assigned by
the DDN Network Information Center, SRI International, 333 Ravenswood
Avenue, Menlo Park, California 94025 (telephone: 800-235-3155). You
can get a network number no matter what your network is being used
for. You do not need authorization to connect to the Defense Data
Network in order to get a number. The main piece of information that
will be needed when you apply for a network number is that address
class that you want. See below for a discussion of this.
In many ways, the most important decision you have to make in setting
up a network is how you will assign Internet addresses to your
computers. This choice should be made with a view of how your network
is likely to grow. Otherwise, you will find that you have to change
addresses. When you have several hundred computers, address changes
can be nearly impossible.
Addresses are critical because Internet datagrams are routed on the
basis of their address. For example, addresses at Rutgers University
have a 2-level structure. A typical address is 128.6.4.3. 128.6 is
assigned to Rutgers University by a central authority. As far as the
outside world is concerned, 128.6 is a single network. Other
universities send any packet whose address begins with 128.6 to the
nearest Rutgers gateway. However within Rutgers, we divide up our
address space into "subnets". We use the next 8 bits of address to
indicate which subnet a computer belongs to. 128.6.4.3 belongs to
subnet 128.6.4. Generally subnets correspond to physical networks,
e.g. separate Ethernets, although as we will see later there can be
exceptions. Systems inside Rutgers, unlike those outside, contain
information about the Rutgers subnet structure. So once a packet for
128.6.4.3 arrives at Rutgers, the Rutgers network will route it to the
departmental Ethernet, token ring, or whatever, that has been assigned
subnet number 128.6.4.
When you start a network, there are several addressing decisions that
face you:
- Do you subdivide your address space?
- If so, do you use subnets or class C addresses?
- You do you allocate subnets or class C networks?
- How big an address space do you need?
4
3.1 Should you subdivide your address space?
It is not necessary to use subnets at all. There are network
technologies that allow an entire campus or company to act as a single
large logical Ethernet, so that no internal routing is necessary. If
you use this technology, then you do not need to subdivide your
address space. In that case, the only decision you have to make is
what class address to apply for. However we recommend using either a
subnet approach or some other method of subdividing your address space
in all cases:
- In section 5.2 we will argue that internal gateways are desirable
for networks of any degree of complexity.
- Even if you do not need gateways now, you may find later that you
need to use them. Thus it probably makes sense to assign
addresses as if each Ethernet or token ring was going to be a
separate subnet. This will allow for conversion to real subnets
later if it proves necessary.
- For network maintenance purposes, it is convenient to have
addresses whose structure corresponds to the structure of the
network. That is, when you see a stray packet from system
128.6.4.3, it is nice to know that all addresses beginning with
128.6.4 are in a particular building.
3.2 Subnets vs. multiple network numbers
Suppose that you have been convinced that it's a good idea to impose
some structure on your addresses. The next question is what that
structure should be. There are two basic approaches. One is subnets.
The other is multiple network numbers.
The Internet standards specify what constitutes a network number. For
numbers beginning with 128 through 191 (the most common numbers these
days), the first two octets form the network number. E.g. in
140.3.50.1, 140.3 is the network number. Network numbers are assigned
to a particular organization. What you do with the next two octets is
up to you. You could choose to make the next octet be a subnet
number, or you could use some other scheme entirely. Gateways within
your organization will be set up to know the subnetting scheme that
you are using. However outside your organization, no one will know
that 140.3.50 is one subnet and 140.3.51 is another. They will simply
know that 140.3 is your organization. Unfortunately, this ability to
add additional structure to the address via subnets was not present in
the original TCP/IP specifications. Thus some software is incapable
of being told about subnets.
If enough of the software that you are using has this problem, it may
be impractical for you to use subnets. Some organizations have used a
different approach. It is possible for an organization to apply for
5
several network numbers. Instead of dividing a single network number,
say 140.3, into several subnets, e.g. 140.3.1 through 140.3.10, you
could apply for 10 different network numbers. Thus you might be
assigned the range 140.3 through 140.12. All TCP/IP software will
know that these are different network numbers.
While using separate network numbers will work just fine within your
organization, it has two very serious disadvantages. The first, and
less serious, is that it wastes address space. There are only about
16,000 possible class B addresses. We cannot afford to waste 10 of
them on your organization, unless it is very large. This objection is
less serious because you would normally ask for class C addresses for
this purpose, and there are about 2 million possible class C
addresses.
The more serious problem with using several network numbers rather
than subnets is that it overloads the routing tables in the rest of
the Internet. As mentioned above, when you divide your network number
into subnets, this division is known within your organization, but not
outside it. Thus systems outside your organization need only one
entry in their tables in order to be able to reach you. E.g. other
universities have entries in their routing tables for 128.6, which is
the Rutgers network number. If you use a range of network numbers
instead of subnets, that division will be visible to the entire
Internet. If we used 128.6 through 128.16 instead of subdividing
128.6, other universities would need entries for each of those network
numbers in their routing tables. As of this writing the routing
tables in many of the national networks are exceeding the size of the
current routing technology. It would be considered extremely
unfriendly for any organization to use more than one network number.
This may not be a problem if your network is going to be completely
self-contained, or if only one small piece of it will be connected to
the outside world. Nevertheless, most TCP/IP experts strongly
recommend that you use subnets rather than multiple networks. The
only reason for considering multiple networks is to deal with software
that cannot handle subnets. This was a problem a few years ago, but
is currently less serious. As long as your gateways can handle
subnets, you can deal with a few individual computers that cannot by
using "proxy ARP" (see below).
3.3 How to allocate subnet or network numbers
Now that you have decided to use subnets or multiple network numbers,
you have to decide how to allocate them. Normally this is fairly
easy. Each physical network, e.g. Ethernet or token ring, is assigned
a separate subnet or network number. However you do have some
options.
In some cases it may make sense to assign several subnet numbers to a
single physical network. At Rutgers we have a single Ethernet that
spans three buildings, using repeaters. It is very clear to us that
as computers are added to this Ethernet, it is going to have to be
6
split into several separate Ethernets. In order to avoid having to
change addresses when this is done, we have allocated three different
subnet numbers to this Ethernet, one per building. (This would be
handy even if we didn't plan to split the Ethernet, just to help us
keep track of where computers are.) However before doing this, make
very sure that the software on all of your computers can handle a
network that has three different network numbers on it.
You also have to choose a "subnet mask". This is used by the software
on your systems to separate the subnet from the rest of the address.
So far we have always assumed that the first two octets are the
network number, and the next octet is the subnet number. For class B
addresses, the standards specify that the first two octets are the
network number. However we are free to choose the boundary between
the subnet number and the rest of the address. It's very common to
have a one-octet subnet number, but that's not the only possible
choice. Let's look again at a class B address, e.g. 128.6.4.3. It is
easy to see that if the third octet is used for a subnet number, there
are 256 possible subnets and within each subnet there are 256 possible
addresses. (Actually, the numbers are more like 254, since it is
generally a bad idea to use 0 or 255 for subnet numbers or addresses.)
Suppose you know that you will never have more than 128 computers on a
given subnet, but you are afraid you might need more than 256 subnets.
(For example, you might have a campus with lots of small buildings.)
In that case, you could define 10 bits for the subnet number, leaving
6 bits for addresses within each subnet. This choice is expressed by
a bit mask, using ones for the bits used by the network and subnet
number, and 0's for the bits used for individual addresses. Our
normal subnet choice is given as 255.255.255.0. If we chose 10 bit
subnet numbers and 6 bit addresses, the subnet mask would be
255.255.255.192.
Generally it is possible to specify the subnet mask for each computer
as part of configuring its TCP/IP software. The TCP/IP protocols also
allow for computers to send a query asking what the subnet mask is.
If your network supports broadcast queries, and there is at least one
computer or gateway on the network that knows the subnet mask, it may
be unnecessary to set it on the other computers. (This capability
brings with it a whole new set of possible problems. One well-known
TCP/IP implementation would answer with the wrong subnet mask when
queried, thus leading causing every other computer on the network to
be misconfigured.)
3.3.1 Dealing with multiple "virtual" subnets on one network
Most software is written under the assumption that every computer on
the local network has the same subnet number. When traffic is being
sent to a machine with a different subnet number, the software will
generally expect to find a gateway to handle forwarding to that
subnet. Let's look at the implications. Suppose subnets 128.6.19 and
128.6.20 are on the same Ethernet. Consider the way things look from
the point of view of a computer with address 128.6.19.3. It will have
7
no problem sending to other machines with addresses 128.6.19.x. They
are on the same subnet, and so our computer will know to send directly
to them on the local Ethernet. However suppose it is asked to send a
packet to 128.6.20.2. Since this is a different subnet, most software
will expect to find a gateway that handles forwarding between the two
subnets. Of course there isn't a gateway between subnets 128.6.19 and
128.6.20, since they are on the same Ethernet. Thus it must be
possible to tell your software that 128.6.20 is actually on the same
Ethernet.
For the most common TCP/IP implementations, it is possible to deal
with more than one subnet on a network. For example, Berkeley Unix
allows you to define gateways using a command "route add". Suppose
that you get from subnet 128.6.19 to subnet 128.6.4 using a gateway
whose address is 128.6.19.1. You would use the command
route add 128.6.4.0 128.6.19.1 1
This says that to reach subnet 128.6.4, traffic should be sent via the
gateway at 128.6.19.1, and that the route only has to go through one
gateway. The "1" is referred to as the "routing metric". If you use
a metric of 0, you are saying that the destination subnet is on the
same network, and no gateway is needed. In our example, on system
128.6.19.3, you would use
route add 128.6.20.0 128.6.19.1 0
The actual address used in place of 128.6.19.1 is irrelevant. The
metric of 0 says that no gateway is actually going to be used, so the
gateway address is not used. However it must be a legal address on
the local network.
Note that the commands in this section are simply examples. You should
look in the documentation for your particular implementation to see
how to configure your routing.
3.4 Choosing an address class
When you apply for an official network number, you will be asked what
class of network number you need. The possible answers are A, B, and
C. This affects how large an address space you will be allocated.
Class A addresses are one octet long, class B addresses are 2 octets,
and class C addresses are 3 octets. This represents a tradeoff:
there are a lot more class C addresses than class A addresses, but the
class C addresses don't allow as many hosts. The idea was that there
would be a few very large networks, a moderate number of medium-size
ones, and a lot of mom-and-pop stores that would have small networks.
Here is a table showing the distinction:
class range of first octet network rest possible addresses
A 1 - 126 p q.r.s 16777214
B 128 - 191 p.q r.s 65534
8
C 192 - 223 p.q.r s 254
For example network 10, a class A network, has addresses between
10.0.0.1 and 10.255.255.254. So it allows 254**3, or about 16 million
possible addresses. (Actually, network 10 has allocated addresses
where some of the octets are zero, so there are a few more networks
possible.) Network 192.12.88, a class C network has hosts between
192.12.88.1 and 128.12.88.254, i.e. 254 possible hosts.
In general, you will be expected to choose the lowest class that will
provide you with enough addresses to handle your growth over the next
few years. In general organizations that have computers in many
buildings will probably need and be able to get a class B address,
assuming that they are going to use subnetting. (If you are going to
use many separate network numbers, you would ask for a number of class
C addresses.) Class A addresses are normally used only for large
public networks and for a few very large corporate networks.
4. Setting up routing for an individual computer
All TCP/IP implementations require some configuration for each host.
In some cases this is done in a "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 kinds of
information need to be supplied for most implementations. This
includes
- parameters describing the specific machine, such as its Internet
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 Internet address. If the machine has more
than one network interface, you must assign a separate Internet
address for each. (In most cases, the same host name can be used.
The name goes with the machine as a whole, whereas the address is
associated with the connection to a specific network.) The address
should begin with the network number for the network to which it is to
be attached. We recommend that you assign addresses starting from 1.
Should you find that you need more subnets than your current subnet
mask allows, you may later need to expand the subnet mask to use more
bits. If all addresses use small numbers, this will be possible.
Generally the Internet address must be specified individually in a
configuration file on each computer. However some computers
9
(particularly those without permanent disks on which configuration
information could be stored) find out their Internet address by
sending a broadcast request over the network. In that case, you will
have to make sure that some other system is configured to answer the
request. When a system asks for its Internet address, enough
information must be put into the request to allow another system to
recognize it and to send a response back. For Ethernet systems,
generally the request will include the Ethernet address of the
requesting system. Ethernet addresses are assigned by the computer
manufacturers, and are guaranteed to be unique. Thus they are a good
way of identifying the computer. And of course the Ethernet address
is also needed in order to send the response back. If it is used as
the basis for address lookup, the system that is to answer the request
will need a table of Ethernet addresses and the corresponding Internet
address. The only problem in constructing this table will be finding
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
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. That is, 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. Generally any machine on the network that
believes it knows the subnet mask will answer any query about the
subnet mask. For that reason, an incorrect subnet mask setting on one
machine can cause confusion throughout the network.
Normally the configuration files do roughly the following things:
- 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 name server (used for looking up names and finding
the corresponding Internet address -- see the section on the
domain system in the Introduction to TCP/IP).
- 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.
10
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.
4.1 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
gateway 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.)
Destination Gateway 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
The example 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 designation for the controller hardware
that connects the computer to that Ethernet. (This system happens to
have controllers from two different vendors. The first one is made by
Interlan, the second by Pyramid.) The second column is the network
number for the network. The third column is this computer's Internet
address on that network. The last column shows other subnets that
share the same physical network.
11
Now let's look at the routing table. 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 gateway. The second column shows the
address of the gateway 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, i.e. that no
errors have occured indicating that the path is unusable.
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 gateway
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 gateway 128.6.7.1. As with network routes, the "G" flag
is used for routes that involve a gateway. The "D" flag indicates
that the route was added dynamically, based on an ICMP redirect
message from a gateway. (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 is also handy for sending queries to programs that are
designed to respond to network queries, but happen to be running on
the same 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 gateway 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
12
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, normally the user gets 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 packets
doesn't depend upon which method you use to set up the routes. When a
packet 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.
4.2 Fixed routes
The simplest way of doing routing is to have your configuration
contain commands to set up the routing table at startup, and then
leave it alone. 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 128.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
gateway 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 gateways 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 gateway on the path. Routes with metrics of
13
0 indicate that no gateway 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
gateway that has enough information to handle all possible
destinations.
If your network has only one gateway 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 gateway 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 gateways.
4.3 Routing redirects
Most Internet experts recommend leaving routing decisions to the
gateways. 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
gateway to update your routing tables. This gateway 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
gateway.) 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 gateway.
After all, if all you have is a single default entry, how will you
ever use the other gateways in the cases where they are better? The
answer is that most gateways 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 gateway 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 Gateway 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 gateway 128.6.4.27. Suppose there is also a gateway
128.6.4.30, which is the best way to get to network 128.6.7. How do
14
you find it? Suppose you have datagrams to send to 128.6.7.23. The
first datagram will go to the default gateway, since that's the only
thing in the routing table. However the default gateway, 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 gateway. However there are some fairly simple
methods for a gateway to determine that you would be better off using
a different one.) Thus 128.6.4.27 will send back a redirect
specifying that packets 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 gateway.
This strategy would be a complete solution, if it weren't for three
problems:
- It requires each computer to have the address of one gateway
"hardwired" into its startup files, as the initial default.
- If a gateway 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 gateway is removed, any systems
that have that gateway 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 gateway for that subnet. For example, on subnet
128.6.7, the default gateway would always be 128.6.7.1. If that
gateway is ever removed, some other gateway is given that address.
(There must always be at least one gateway 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 gateway goes down? You want traffic to be redirected back to a
gateway that is up. Unfortunately, a gateway that has crashed is not
going to issue Redirects. One solution is to choose very reliable
gateways. 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 a line goes down, your current route may no longer be a good one.
As long as the gateway to which you are talking is still up and
talking to you, it can simply issue a Redirect to the gateway that is
now the best one. However you still need a way to detect failure of
one of the gateways that you are talking to directly.
15
The best approach for handling failed gateways 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