lkml.org 
[lkml]   [1997]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Patch for route.c
On Thu, 10 Apr 1997, Alan Cox wrote:

> > A machine on __any__ single __physical__ network link needs only two routes.
> > Note the emphasis on "any" and "physical".
> >
> > (1) A route to its local network or subnet.
> > (2) A route to all other places.
>
> One great thing btw is the more you shout the more I can tell you are wrong.
> Consider the case
>
>
> [Backbone1]--------------ethernet-----------[Backbone2]
> | | |
> Host1 Host2 Host3
>
>
> You want all the hosts to pick the right backbone router. You also dont want
> to feed all the traffic through one router first because it creates
> bottlenecks
> as well as very bad single point of failure cases.
>
> Alan
>

Alan, the network topography has to be controlled by the routers, not the
hosts. The hosts have no way to accomplish anything by modifying their
routing tables using 'routed` or 'gated`. No matter what they do, the
hosts will end up sending their data out the only path to the network,
their single Ethernet card.

One of the reasons why `gated` got its name changed is because it is
really for `gateways`. Such a router may have two or more paths to
a destination. The `gated` daemon can help determine the "minimum cost"
route to the destination. Therefore, a TCP/IP based router can function
as a bridge such as the old Digital DMPR. In fact, I worked on "Phase V"
routing.

When a host first attempts to send a datagram, for a connectionless service,
or establish a connection, it broadcasts an ARP request for the hardware
address of the host or gateway that "knows" the IP Address. In the case of
a host, the host responds with its hardware address. In the case of a
gateway, the gateway must "know" if it can handle a route to the required
destination. If it has a route to the destination, it responds with its
hardware address. All subsequent communications for that IP address are made
using the hardware addresses so determined.

When I ^X this message, it will go the hardware address of my Cisco Router.
None of the other 600-odd nodes on the Local Area Network will even know.
The Cisco Router doesn't really "know" that it has a route to you. It only
knows that the IP Address received during the ARP was not for my domain.
It therefore responds with its hardware address. It will forward anything
it gets out the T1 link.

Some of our hosts will use an additional gateway. At our site in Wakefield
there will be three gateways before the Cisco. Hosts in Wakefield don't
care (or even know) about the Cisco router. They only know about their
gateway to "the rest of the world", as in (2) above "A route to all other
places".

In all cases, the host will send and receive through its single hardware
interface so modifying its routing tables will not be useful. Hense, running
`gated` on a host is not useful. Further, many hosts have routing
capabilities built-in that can't be turned ON/OFF with a switch in /proc
(such as Linux). Routing table entries in such a host often cause that
host to "forward" packets out the same interface through which they were
received. This is not good.

Again, the host should not be the entity that determines the minimum cost
route to a destination unless it has two or more physical connections. Most
have only one. The gateway, by its very nature, has two or more connections.
The `gated` daemon can be very useful on a gateway.

One of the things a host does when a route seems to have been lost,
(RFC-816, is to again send another ARP request. If two or more gateways
have been communicating using `gated`, the gateway that still has a route
to the destination will offer its hardware address in response. This
handles your "single-point-failure" problem cited in your response.

One of the advantages of Linux is it allows the default route to be
specified as `route add default dev eth0` without a named gateway. Any
gateways that are still alive can then route packets out of the local
area.


Cheers,
Dick Johnson
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Richard B. Johnson
Project Engineer
Analogic Corporation
Voice : (508) 977-3000 ext. 3754
Fax : (508) 532-6097
Modem : (508) 977-6870
Ftp : ftp@boneserver.analogic.com
Email : rjohnson@analogic.com, johnson@analogic.com
Penguin : Linux version 2.1.32 on an i586 machine (66.15 BogoMips).
Warning : I read unsolicited mail for $350.00 per hour. Supply billing address.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.061 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site