[comp.protocols.tcp-ip] Routing methods

smiles@ferrari.nmc.ed.ray.com (Kevin Ruddy) (08/21/90)

Our organization would like to set some guidelines pertaining to routing.

The three choices we see are as follows: default routing, proxy ARP, and RIP.
Proxy ARP appears to be a poor solution.  RIP would work fine, but there's
the issue of maintaining routing daemons on many hosts.  Default routing
along with ICMP redirects might work as well, but that could be a bad idea,
too.

What is a good solution?  Default routing involves a minimum configuration
on hosts, but if the router should change ...  And then there will always be
OSPF, right?  Anyone have some solid answers?  Thanks in advance ...

Kevin Ruddy
smiles@ferrari.nmc.ed.ray.com

hedrick@athos.rutgers.edu (Charles Hedrick) (08/21/90)

First, the question you were asking seems to be about finding your
gateway, not about routing.  At the moment there is no good way for
hosts to find gateways.  Which way you use will depend upon the
specific capabilities of your host.  Ideally you need two things:

  - find a gateway when you start a connection
  - discover a gateway that has gone down and move to a new one

Default routing and proxy ARP will both do that, and both require
essentially the same kind of implementation.  For default routing,
your implementation needs the following features:

  - the ability to declare multiple default gateways, and to use
	any one that is up

  - a way of detecting when the current gateway is down, usually
	because the upper layers detect a timeout.  (Another way
	is to ping all gateways that are in use.)

Unfortunately the Unix TCP/IP implementations I've looked at are
unable to use more than one default.  Thus there's no way to go to
backup routes.  In addition default routes requires you to configure
in a list of default gateways.

Proxy ARP has no problem finding the gateway.  You don't need to
configure anything, and it can find any gateway that is up.  However
most Unix implementations do not have the ability to clear the current
ARP entry when there is a timeout.  Indeed the versions of BSD that
I've seen will keep a failed ARP entry forever if there is some
program attempting to use it.

RIP will do the job.  My main objections are (1) we don't use RIP for
routing and (2) I don't like listening to broadcasts on diskless
machines.  When a broadcast is sent, every machine on the network
pages in its rip daemon at the same time.  

An alternative to RIP is cisco's gateway discovery daemon.  Each
gateway sends a periodic broadcast.  There's a priority so you can
prefer some gateways over others.  From a host's point of view it has
roughly the same features as RIP, but work no matter what routing
protocol you are using, and is small enough that you could put it in
the kernel or lock down the daemon in memory.

In my opinion the best solution is a gateway discovery broadcast, but
done as ICMP and implemented in the kernel.  But putting it in the
kernel, diskless systems don't have the synchronized swapin problem.
The last IETF actually agreed to get a gateway discovery ICMP out the
door, so there's some hope.  

Until then, there is no ideal gateway discovery method.  You have to
choose which of the existing methods has the fewest disadvantages in
your enviornment.  You may well end up using different ones on
different types of host.

On our Suns, we use proxy ARP.  I use this rather than defaults
primarily because it requires the minimum amount of configuration.
However I've done kernel hacking to make it work:

  - ARP entries time out after 20 min, even if they are in use.

  - when an upper layer times out, ARP entries are cleared

  - NFS timeouts trigger ARP clearing, not just TCP timeouts

  - our cisco gateways have an "arp-delay" parameter.  This delays
	ARP responses.  It lets	us choose which gateway will win if
	several answer.  (With most implementations, the last ARP
	response to arrives wins.)  [cisco did not adopt this
	feature, reportedly because they didn't think they could
	explain to customers what it did.]

I think my next choice would be the cisco gateway discovery thing,
particularly if you machines have disks.  I might also consider trying
to put it into the kernel for diskless machines.

Maybe we can all agree to lean on the vendors to implement the new
gateway discovery ICMP.