280 lines
12 KiB
Plaintext
280 lines
12 KiB
Plaintext
<!-- $Id$ -->
|
|
<!-- The FreeBSD Documentation Project -->
|
|
<!-- <!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'> -->
|
|
|
|
<sect><heading>Gateways and routes<label id="routing"></heading>
|
|
|
|
<p><em>Contributed by &a.gryphon;.<newline>6 October 1995.</em>
|
|
|
|
For one machine to be able to find another, there must be a
|
|
mechanism in place to describe how to get from one to the
|
|
other. This is called Routing. A ``route'' is a defined
|
|
pair of addresses: a <bf>destination</bf> and a
|
|
<bf>gateway</bf>. The pair indicates that if you are
|
|
trying to get to this <em>destination</em>, send along
|
|
through this <em>gateway</em>. There are three types of
|
|
destinations: individual hosts, subnets, and ``default''. The
|
|
``default route'' is used if none of the other routes
|
|
apply. We will talk a little bit more about default routes
|
|
later on. There are also three types of gateways:
|
|
individual hosts, interfaces (also called ``links''), and
|
|
ethernet hardware addresses.
|
|
|
|
<sect1><heading>An example</heading>
|
|
|
|
<p>To illustrate different aspects of routing, we will use
|
|
the following example which is the output of the command
|
|
<tt>netstat -r</tt>:
|
|
|
|
<tscreen><verb>
|
|
Destination Gateway Flags Refs Use Netif Expire
|
|
|
|
default outside-gw UGSc 37 418 ppp0
|
|
localhost localhost UH 0 181 lo0
|
|
test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77
|
|
10.20.30.255 link#1 UHLW 1 2421
|
|
foobar.com link#1 UC 0 0
|
|
host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0
|
|
host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 =>
|
|
host2.foobar.com link#1 UC 0 0
|
|
224 link#1 UC 0 0
|
|
</verb></tscreen>
|
|
|
|
The first two lines specify the default route (which we
|
|
will cover in the next section) and the <tt>localhost</tt> route.
|
|
|
|
The interface (<tt>Netif</tt> column) that it specifies to use
|
|
for <tt>localhost</tt> is <tt>lo0</tt>, also known as the
|
|
loopback device. This says to keep all traffic for this
|
|
destination internal, rather than sending it out over the
|
|
LAN, since it will only end up back where it started
|
|
anyway.
|
|
|
|
The next thing that stands out are the
|
|
``<tt>0:e0:...</tt>'' addresses. These are ethernet
|
|
hardware addresses. FreeBSD will automatically identify any
|
|
hosts (<tt>test0</tt> in the example) on the local ethernet and
|
|
add a route for that host, directly to it over the ethernet
|
|
interface, <tt>ed0</tt>. There is also a timeout
|
|
(<tt>Expire</tt> column) associated with this type of route,
|
|
which is used if we fail to hear from the host in a
|
|
specific amount of time. In this case the route will be
|
|
automatically deleted. These hosts are identified using a
|
|
mechanism known as RIP (Routing Information Protocol),
|
|
which figures out routes to local hosts based upon a
|
|
shortest path determination.
|
|
|
|
FreeBSD will also add subnet routes for the local subnet
|
|
(<tt>10.20.30.255</tt> is the broadcast address for the subnet
|
|
<tt>10.20.30</tt>, and <tt>foobar.com</tt> is the domain name
|
|
associated with that subnet). The designation <tt>link#1</tt>
|
|
refers to the first ethernet card in the machine. You will
|
|
notice no additional interface is specified for those.
|
|
|
|
Both of these groups (local network hosts and local
|
|
subnets) have their routes automatically configured by a
|
|
daemon called <tt>routed</tt>. If this is not run, then only
|
|
routes which are statically defined (ie. entered
|
|
explicitly) will exist.
|
|
|
|
The <tt>host1</tt> line refers to our host, which it knows by
|
|
ethernet address. Since we are the sending host, FreeBSD
|
|
knows to use the loopback interface (<tt>lo0</tt>) rather than
|
|
sending it out over the ethernet interface.
|
|
|
|
The two <tt>host2</tt> lines are an example of what happens
|
|
when we use an ifconfig alias (see the section of ethernet
|
|
for reasons why we would do this). The <tt>=></tt>
|
|
symbol after the <tt>lo0</tt> interface says that not only are
|
|
we using the loopback (since this is address also refers to
|
|
the local host), but specifically it is an alias. Such
|
|
routes only show up on the host that supports the alias;
|
|
all other hosts on the local network will simply have a
|
|
<tt>link#1</tt> line for such.
|
|
|
|
The final line (destination subnet <tt>224</tt>) deals with
|
|
MultiCasting, which will be covered in a another section.
|
|
|
|
The other column that we should talk about are the
|
|
<tt>Flags</tt>. Each route has different attributes that are
|
|
described in the column. Below is a short table of some of
|
|
these flags and their meanings:
|
|
|
|
<descrip>
|
|
|
|
<tag/U/ <bf/Up:/ The route is active.
|
|
|
|
<tag/H/ <bf/Host:/ The route destination is a single host.
|
|
|
|
<tag/G/ <bf/Gateway:/ Send anything for this destination
|
|
on to this remote system, which will figure out from
|
|
there where to send it.
|
|
|
|
<tag/S/ <bf/Static:/ This route was configured manually,
|
|
not automatically generated by the system.
|
|
|
|
<tag/C/ <bf/Clone:/ Generates a new route based upon this
|
|
route for machines we connect to. This type of route is
|
|
normally used for local networks.
|
|
|
|
<tag/W/ <bf/WasCloned/ Indicated a route that was
|
|
auto-configured based upon a local area network (Clone)
|
|
route.
|
|
|
|
<tag/L/ <bf/Link:/ Route involves references to ethernet
|
|
hardware.
|
|
|
|
</descrip>
|
|
|
|
|
|
<sect1><heading>Default routes</heading>
|
|
|
|
<p>When the local system needs to make a connection to
|
|
remote host, it checks the routing table to determine if
|
|
a known path exists. If the remote host falls into a
|
|
subnet that we know how to reach (Cloned routes), then
|
|
the system checks to see if it can connect along that
|
|
interface.
|
|
|
|
If all known paths fail, the system has one last option:
|
|
the <bf>default</bf> route. This route is a special type
|
|
of gateway route (usually the only one present in the
|
|
system), and is always marked with a ``<tt>c</tt>'' in
|
|
the flags field. For hosts on a local area network, this
|
|
gateway is set to whatever machine has a direct
|
|
connection to the outside world (whether via PPP link, or
|
|
your hardware device attached to a dedicated data line).
|
|
|
|
If you are configuring the default route for a machine
|
|
which itself is functioning as the gateway to the outside
|
|
world, then the default route will be the gateway machine
|
|
at your Internet Service Provider's (ISP) site.
|
|
|
|
Let us look at an example of default routes. This is a
|
|
common configuration:
|
|
<tscreen><verb>
|
|
[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW]
|
|
</verb></tscreen>
|
|
|
|
The hosts <tt>Local1</tt> and <tt>Local2</tt> are at your
|
|
site, with the formed being your PPP connection to your
|
|
ISP's Terminal Server. Your ISP has a local network at
|
|
their site, which has, among other things, the server
|
|
where you connect and a hardware device (T1-GW) attached
|
|
to the ISP's Internet feed.
|
|
|
|
The default routes for each of your machines will be:
|
|
|
|
<tscreen><verb>
|
|
host default gateway interface
|
|
---- --------------- ---------
|
|
Local2 Local1 ethernet
|
|
Local1 T1-GW PPP
|
|
</verb></tscreen>
|
|
|
|
A common question is ``Why (or how) would we set the
|
|
T1-GW to be the default gateway for Local1, rather than
|
|
the ISP server it is connected to?''.
|
|
|
|
Remember, since the PPP interface is using an address on
|
|
the ISP's local network for your side of the connection,
|
|
routes for any other machines on the ISP's local network
|
|
will be automatically generated. Hence, you will already
|
|
know how to reach the T1-GW machine, so there is no need
|
|
for the intermediate step of sending traffic to the ISP
|
|
server.
|
|
|
|
As a final note, it is common to use the address ``<tt>...1</tt>''
|
|
as the gateway address for your local network. So (using
|
|
the same example), if your local class-C address space
|
|
was <tt>10.20.30</tt> and your ISP was using <tt>10.9.9</tt> then the
|
|
default routes would be:
|
|
|
|
<tscreen><verb>
|
|
Local2 (10.20.30.2) --> Local1 (10.20.30.1)
|
|
Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1)
|
|
</verb></tscreen>
|
|
|
|
<sect1><heading>Dual homed hosts</heading>
|
|
|
|
<p>There is one other type of configuration that we should
|
|
cover, and that is a host that sits on two different
|
|
networks. Technically, any machine functioning as a
|
|
gateway (in the example above, using a PPP connection)
|
|
counts as a dual-homed host. But the term is really only
|
|
used to refer to a machine that sits on two local-area
|
|
networks.
|
|
|
|
In one case, the machine as two ethernet cards, each
|
|
having an address on the separate subnets. Alternately,
|
|
the machine may only have one ethernet card, and be using
|
|
ifconfig aliasing. The former is used if two physically
|
|
separate ethernet networks are in use, the latter if
|
|
there is one physical network segment, but two logically
|
|
separate subnets.
|
|
|
|
Either way, routing tables are set up so that each subnet
|
|
knows that this machine is the defined gateway (inbound
|
|
route) to the other subnet. This configuration, with the
|
|
machine acting as a Bridge between the two subnets, is
|
|
often used when we need to implement packet filtering or
|
|
firewall security in either or both directions.
|
|
|
|
<sect1><heading>Routing propagation</heading>
|
|
|
|
<p>We have already talked about how we define our routes to
|
|
the outside world, but not about how the outside world
|
|
finds us.
|
|
|
|
We already know that routing tables can be set up so that
|
|
all traffic for a particular address space (in our
|
|
examples, a class-C subnet) can be sent to a particular
|
|
host on that network, which will forward the packets
|
|
inbound.
|
|
|
|
When you get an address space assigned to your site, your
|
|
service provider will set up their routing tables so that
|
|
all traffic for your subnet will be sent down your PPP
|
|
link to your site. But how do sites across the country
|
|
know to send to your ISP?
|
|
|
|
There is a system (much like the distributed DNS
|
|
information) that keeps track of all assigned
|
|
address-spaces, and defines their point of connection to
|
|
the Internet Backbone. The ``Backbone'' are the main
|
|
trunk lines that carry Internet traffic across the
|
|
country, and around the world. Each backbone machine has
|
|
a copy of a master set of tables, which direct traffic
|
|
for a particular network to a specific backbone carrier,
|
|
and from there down the chain of service providers until
|
|
it reaches your network.
|
|
|
|
It is the task of your service provider to advertise to
|
|
the backbone sites that they are the point of connection
|
|
(and thus the path inward) for your site. This is known
|
|
as route propagation.
|
|
|
|
<!--
|
|
<sect1><heading>Multicast Routing</heading>
|
|
-->
|
|
|
|
<sect1><heading>Troubleshooting</heading>
|
|
|
|
<p>Sometimes, there is a problem with routing propagation,
|
|
and some sites are unable to connect to you. Perhaps the
|
|
most useful command for trying to figure out where a
|
|
routing is breaking down is the <tt>traceroute(8)</tt>
|
|
command. It is equally useful if you cannot seem to make
|
|
a connection to a remote machine (ie. <tt>ping(8)</tt>
|
|
fails).
|
|
|
|
The <tt>traceroute(8)</tt> command is run with the name
|
|
of the remote host you are trying to connect to. It will
|
|
show the gateway hosts along the path of the attempt,
|
|
eventually either reaching the target host, or
|
|
terminating because of a lack of connection.
|
|
|
|
For more information, see the manual page for
|
|
<tt>traceroute(8)</tt>.
|
|
|