hedrick@aramis.rutgers.edu (Charles Hedrick) (07/25/88)
They simply have a list of the Ethernet addresses that lie on each of
its two networks. This means
- A bridge can handle only two network interfaces. At a central
site, where many networks converge, this normally means that you
set up a backbone network to which all the bridges connect, and
then buy a separate bridge to connect each other network to that
backbone. Gateways often have between 4 and 8 interfaces.
- Networks that 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 direction 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 algorithm". 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
system must communicate among themselves. There is an IEEE proposal
to standardize the protocol for doing this, and for constructing the
spanning tree.
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 gateways, 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.
33
5.2.4 More about gateways
Gateways have their own advantages and disadvantages. In general a
gateway is more complex to design and to administer than a bridge. A
gateway must participate in all of the protocols that it is designed
to forward. For example, an IP gateway 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.
Gateways 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 only a binary decision to
make: does it or does it not pass a given packet from one network to
the other? However a gateway may have several network interfaces.
Furthermore, when it forwards a packet, it must decide what host or
gateway to send the packet to next. It is even possible for a gateway
to decide to send a packet back onto the same network it came from.
If a host is using the gateway as its default, it may send packets
that really should go to some other gateway. In that case, the
gateway will send the packet on to the right gateway, and send back an
ICMP redirect to the host. Many gateways can also handle parallel
paths. If there are several equally good paths to a destination, the
gateway will alternate among them in round-robin fashion.
In order to handle these decisions, a gateway will typically have a
routing table that looks very much like a host's. As with host
routing tables, a gateway'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 gateway, or there is an
entry saying that traffic for that network should be forwarded through
some other gateway or gateways. We will describe the "routing
protocols" used to build up this information later, in the discussion
on how to configure a gateway.
5.3 Comparing the switching technologies
Repeaters, buffered repeaters, bridges, and gateways 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 slightly larger areas (particularly those
with low traffic levels), and gateways used for long-distance links.
Note that this document so far has assumed that only gateways are
being used. The section on setting up a host described how to set up
a routing table listing the gateways 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. Section 3.3.1 describes how to configure
34
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, and
performing auxilliary support services.
5.3.1 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, gateway. 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, gateway. (Such problems are not very
common.)
- Software malfunctions that lead to excessive traffic between
particular hosts (i.e. not broadcasts). Bridges and gateways
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.
Gateways 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
research sites generally see problems of this sort regularly.
35
Traffic isolation is provided by bridges and gateways. 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 gateways 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.
5.3.2 Performance
This is becoming less of an issue as time goes on, since the
technology is improving. Generally repeaters can handle the full
bandwidth of the network. (By their very nature, a simple repeater
must be able to do so.) Bridges and gateways often have performance
limitations of various sorts. Bridges have two numbers of interest:
packet scanning 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 second that it can scan in this
way is the packet scanning rate. Throughput applies to both bridges
and gateways. This is the rate at which they can forward traffic.
Generally this depends upon packet size. Normally the number of
packets per second that a unit can handle will be greater for short
packets than long ones. Early models of bridge varied from a few
hundred packets 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 gateways varied from a few
hundred packets per second to 1000 or more. However second-generation
gateways are now available, using special-purpose hardware of the same
sophistication as that used by bridges. They can handle on the order
of 10000 packets per second. Thus at the moment high-performance
bridges and gateways 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.
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 packet only once as it
goes through a gateway, but that one prominent vendor counts packets
36
twice. Thus their switching rates must be deflated by a factor of 2.
Also, when comparing numbers make sure that they are for packets of
the same size. A simple performance model is
processing time = switching time + packet size * time per byte
That is, the time to switch a packet is normally a constant switching
time, representing interrupt latency, header processing, routing table
lookup, etc., plus a component proportional to packet size,
representing the time needed to do any packet copying. One reasonable
approach to reporting performance is to give packets per second for
minimum and maximum size packets. Another is to report limiting
switching speed in packets per second and throughput in bytes per
second, i.e. the two terms of the equation above.
5.3.3 Routing
Routing refers to the technology used to decide where to send a packet
next. Of course for a repeater this is not an issue, since repeaters
forward every packet.
Bridges are almost always constructed with exactly two interfaces.
Thus routing turns into two decisions: (1) whether the bridge should
function at all, and (2) whether it should forward any particular
packet. The second decision is usually based on a table of MAC-level
addresses. As described above, this is built up by scanning traffic
on both sides of the bridge. 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 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. There is currently no official standard for the protocol
used among bridges, although there is a standard in the proposal
stage. If you buy bridges from more than one vendor, make sure that
their spanning-tree protocols will interoperate.
Gateways generally allow arbitrary network topologies, including loops
and redundant links. Because gateways may have more than two
interfaces, they must decide not only when to forward a packet, but
where to send it next. They do this by maintaining 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. Gateways that handle TCP/IP should generally
support the two Internet standard routing protocols: RIP (Routing
37
Information Protocol) and EGP (External Gateway 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 gateway must support EGP. This is
becoming common enough that it is probably a good idea to make sure
that all gateways 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 gateways. 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 gateways).
- 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 gateways change a
lot.
Some vendors supply proprietary modifications to RIP that improve its
operation with EGP or increase the maximum path length beyond 15, but
do not otherwise modify it very much. If you expect your network to
involve gateways from more than one vendor, you should generally
require that all of them support RIP, since this is the only routing
protocol that is generally available. If you expect to use a more
sophisticated protocol in addition, the gateways must have some
ability 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 in general
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. However at the moment
I do not know of any commercial gateway that does this. (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
38
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. However at the moment, there is no generally implemented
routing technology other than RIP.
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 packet. 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 gateways 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
gateways vary in the degree of control that they support. Make sure
that you discuss any requirements that you have for control with all
prospective gateway vendors.
5.3.4 Network management
Network management covers a wide variety of topics. In general it
includes gathering statistical data and status information about parts
of your network, and taking action as necessary to deal with failures
and other changes. There are several things that a switch can do to
make this process easier. The most basic is that it should have a way
of gathering and reporting statistics. These should include various
sorts of packet counts, as well as counts of errors of various kinds.
This data is likely to be most detailed in a gateway, since the
gateway classifies packets using the protocols, and may even respond
to certain types of packet itself. However bridges and even buffered
repeaters can certainly have counts of packets forwarded, interface
errors, etc. It should be possible to collect this data from a
central monitoring point.
There is now an official Internet approach to network monitoring. The
first stages use a related set of protocols, SGMP and SNMP. Both of
these protocols are designed to allow you to collect information and
to make changes in configuration parameters for gateways and other
entities on your network. You can run the matching interface programs
on any host in your network. SGMP is now available for several
commercial gateways, as well as for Unix systems that are acting as
gateways. There is a limited set of information which any SGMP
implementation is required to supply, as well as a uniform mechanism
for vendors to add information of their own. By late 1988, the second
generation of this protocol, SNMP, should be in service. This is a
slightly more sophisticated protocol. It has with it a more complete
set of information that can be monitored, called the MIB (Management
Information Base). Unlike the somewhat ad hoc collection of SGMP
variables, the MIB is the result of numerous committee deliberations
involving a number of vendors and users. Eventually it is expected
that there will be a TCP/IP equivalent of CMIS, the ISO network
monitoring service. However CMIS, and its protocols, CMIP, are not
39
yet official ISO standards, so they are still in the experimental
stages.
In general terms all of these protocols accomplish the same thing:
They allow you to collect criticial information in a uniform way from
all vendors' equipment. You send commands as UDP datagrams from a
network management program running on some host in your network.
Generally the interaction is fairly simple, with a single pair of
datagrams exchanged: a command and a response. At the moment security
is fairly simple. It is possible to require what amounts to a
password in the command. (In SGMP it is referred to as a "session
name", rather than a password.) More elaborate, encryption-based
security is being developed.
You will probably want to configure the network management tools at
your disposal to do several different things. For short-term network
monitoring, you will want to keep track of switches crashing or being
taken down for maintenance, and of failure of communications lines and
other hardware. It is possible to configurate SGMP and SNMP to issue
"traps" (unsolited messages) to a specified host or list of hosts when
some of these critical events occur (e.g. lines up and down). However
it is unrealistic to expect a switch to notify you when it crashes.
It is also possible for trap messages to be lost due to network
failure or overload. Thus you should also poll your switches
regularly to gather information. Various displays are available,
including a map of your network where items change color as their
status changes, and running "strip charts" that show packet rates and
other items through selected switches. This software is still in its
early stages, so you should expect to see a lot of change here.
However at the very least you should expect to be notified in some way
of failures. You may also want to be able to take actions to
reconfigure the system in response to failures, although security
issues make some mangers nervous about doing that through the existing
management protocols.
The second type of monitoring you are likely to want to do is to
collect information for use in periodic reports on network utilization
and performance. For this, you need to sample each switch
perodically, and retrieve numbers of interest. At Rutgers we sample
hourly, and get the number of packets forwarded for IP and DECnet, a
count of reloads, and various error counts. These are reported daily
in some detail. Monthly summaries are produced giving traffic through
each gateway, and a few key error rates chosen to indicate a gateway
that is being overloaded (packets 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 do network management for buffered repeaters,
bridges, and gateways. Gateways are the most likely to contain
sophisticated network management software. Most gateway vendors that
handle TCP/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,
40
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.
(We have seen one case where it is necessary to take the bridge out of
service to gather this data.) 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 all of
the devices on your network collect statistics and provide some way of
querying them remotely. In the long run, you can expect the most
software to be available for standard protocols such as SGMP/SNMP and
CMIS. However proprietary monitoring tools may be sufficient as long
as they work with all of the equipment that you have.
5.3.5 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 gateways 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 gateways in places
where traffic would not require them for network monitoring
reasons.
- Because bridges must pass broadcast packets, 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 gateways.
- 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 gateways.
41
@section(Configuring Gateways)
This section deals with configuration issues that are specific to
gateways. Gateways than handle TCP/IP are themselves Internet hosts.
Thus the discussions above on configuring addresses and routing
information apply to gateways as well as to hosts. The exact way you
configure a gateway will depend upon the vendor. In some cases, you
edit files stored on a disk in the gateway itself. However for
reliability reasons most gateways 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 involves specifying the Internet address
and address mask for each interface, and enabling an appropriate
routing protocol. However generally a few other options are
desirable. There are often parameters in addition to the Internet
address that you should set for each interface.
One important parameter is the broadcast address. As explained above,
older software may react badly when broadcasts are sent using the new
standard broadcast address. For this reason, some vendors allow you
to choose 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 computers follow current standards, a
broadcast address of 255.255.255.255 should be used. However older
implementations may behave better with other addresses, particularly
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 implement subnets, you would use 128.6.0.0 as the broadcast
address even for a subnet such 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 choice, every
time the gateway sends a routing update broadcast, many machines on
your network will respond with ARP's or ICMP errors. Note that when
you change the broadcast address in the gateway, you may need to
change it on the individual computers as well. Generally the idea is
to change the address on the systems that you can configure to give
behavior that is compatible with systems that you can't configure.
Other interface parameters may be necessary to deal with peculiarities
of the network it is connected to. For example, many gateways test
Ethernet interfaces 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 version 1 transceivers. If you are
using such a transceiver, you would have to disable this keepalive
testing. Similarly, gateways connected by a serial line normally 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 features of the software that you want
to use. For example, it is often necessary to 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).
42
Most gateways have options that relate to security. At a minimum,
this may include setting password for making changes remotely (and the
"session name" for SGMP). If you need to control access to certain
parts of your network, you will also need to define access control
lists or whatever other mechanism your gateway uses.
Gateways that load configuration information over the network present
special issues. When such a gateway boots, it sends broadcast
requests of various kinds, attempting to find its Internet address 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 some cases, this is a dedicated micro running special
software. In other cases, generic software is available that can run
on a variety of machines. You should consult your vendor to make sure
that this can be arranged. For reliability reasons, you should make
sure that there is more than one host with the information and
programs that your gateways need. In some cases you will have to
maintain several different files. For example, the gateways used at
Rutgers use a program called "bootp" to supply their Internet address,
and they then load the code and configuration information using TFTP.
This means that we have to maintain a file for bootp that contains
Ethernet and Internet addresses for each gateway, and a set of files
containing other configuration information for each gateway. If your
network is large, it is worth taking some trouble to make sure that
this information remains consistent. We 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 gateway 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
gateways.
Starting a gateway is particularly challenging if it loads
configuration information from a distant portion of the network.
Gateways 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 gateways 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 network where there are appropriate
computers. This requires what is strictly speaking a violation of the
basic design philosophy for gateways. Generally a gateway should not
allow broadcasts from one network to pass through to an adjacent
network. In order to allow a gateway to get information from a
computer on a different network, at least one of the gateways 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 gateways do not come up after a power
failure because someone changed the configuration of another gateway
43
and made it impossible to load some necessary information.
5.4 Configuring routing for gateways
The final topic to be considered is configuring routing. This is more
complex for a gateway than for a normal host. Most Internet experts
recommend that routing be left to the gateways. Thus hosts may simply
have a default route that points to the nearest gateway. Of course
the gateways themselves can't get by with this. They need to have
complete routing tables.
In order to understand how to configure a gateway, we have to look in
a bit more detail at how gateways communicate routes. When you first
turn on a gateway, the only networks it knows about are the ones that
are directly connected to it. (They are specified by the
configuration information.) 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
gateway to advertise which networks it can get to, and to spread that
information from one gateway to the next. Eventually every gateway
should know how to get to every network. There are different styles
of routing protocol. In one common type, gateways talk only to nearby
gateways. In another type, every gateway builds up a database
describing every other gateway in the system. However all of the
protocols have some way for each gateway in the system to find out how
to get to every destination.
A metric is some number or set of numbers that can be used to compare
routes. The routing table is constructed by gathering information
from other gateways. If two other gateways claim to be able to get to
the same destination, there must be some way of deciding which one to
use. The metric is used to make that decision. Metrics all indicate
in some general sense the "cost" of a route. This may be a cost in
dollars of sending packets over that route, the delay in milliseconds,
or some other measure. The simplest metric is just a count of the
number of gateways along the path. This is referred to as a "hop
count". Generally this metric information is set in the gateway
configuration files, or is derived from information appearing there.
At a minimum, routing configuration is likely to consist of a command
to enable the routing protocol that you want to use. Most vendors
will have a prefered routing protocol. Unless you have some reason to
choose another, you should use that. The normal reason for choosing
another protocol is for compatibility with other kinds of gateway.
For example, your network may be connected to a national backbone
network that requires you to use EGP (exterior gateway protocol) to
communicate routes with it. EGP is only appropriate for that specific
case. You should not use EGP within your own network, but you may
need to use it in addition to your regular routing protocol to
communicate with a national network. If your own network has several
different types of gateway, then you may need to pick a routing
protocol that all of them support. At the moment, this is likely to
44
be RIP (Routing Information Protocol). Depending upon the complexity
of your network, you could use RIP throughout it, or use a more
sophisticated protocol among the gateways that support it, and use RIP
only at the boundary between gateways from different vendors.
Assuming that you have chosen a routing protocol and turned it on,
there are some additional decisions that you may need to make. One of
the more basic configuration options has to do with supplying metric
information. As indicated above, metrics 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
gateways would be considered better than one that passes through 3.
Of course if the latter route used 1.5Mbps lines and the former 9600
bps 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 bps 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 bps line. With
protocols that are based on bit rate, you might need to specify the
speed of each line (if the gateway cannot figure it out
automatically).
Most routing protocols are designed to let each gateway learn the
topology of the entire network, and to choose the best possible route
for each packet. 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 gateways. 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 gateways use only the routes
you want them to. But also use access control lists on the gateways
that are adjacent to the sensitive networks. These two mechanisms act
at different levels. The routing controls affect what happens to most
packets: 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 gateways from which you will accept information.
It may also be possible to rank gateways by priority. For example,
you might decide to listen to routes from within your own organization
45
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 gateway 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 bps 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.
46