[ On Saturday, July 28, 2001 at 12:25:06 (+0200), Alan Barrett wrote: ]
> Subject: Re: should the default route get a new interface automatically?
>
> If I understand correctly, you are doing something like this:
> 
> 	# 1. configure an interface
> 	ifconfig eth0 inet 10.2.3.4 netmask 255.255.255.0
> 	# 2. configure a default route
> 	route add default 10.2.3.1
> 	# 3. unconfigure the first interface
> 	ifconfig eth0 inet 10.2.3.4 netmask 255.255.255.0 delete
> 	# 4. configure a different interface
> 	ifconfig eth1 inet 10.2.3.4 netmask 255.255.255.0 delete
> 
> After step 2, the default route "knows" that it's through interface
> eth0, even though you didn't tell it that.
> 
> After step 4, you would like the default route to be through interface
> eth1, but it's still through eth0.

Yes, that's it exactly (your example is much simpler by ignoring the
second interface until it's used in step #4).  Thanks!

> The NetBSD kernel doesn't do recursive route lookups (though that would
> be a useful feature), so it's impossible to create a route in which the
> interface is determined at packet forwarding time via recursive lookup;
> the interface associated with a route is always determined at "route
> add" time.

Hmmm.... Indeed I don't think I'd want the recursive lookup done for
every packet....

What I haven't tried to figure out is what causes the interface to be
looked up and associated with the route in the first place.  I'm
assuming it's done when the "route add" (or I guess "route change")
happens.

> Since we don't have recursive route lookup, one could argue that the
> ifconfig delete in step 3 should also have deleted the default route.

Should it have deleted it, or just marked it as temporarily unavailable?

I'd prefer not to have ifconfig do any permanently destructive things.
If it simply marked the route as unavailable somehow; then in step #4 it
could bring the route back online since that step again provides the
network necessary to reach the gateway.

I'm guessing there's nothing special about the default route here -- it
could be any route.

The other thing I'm not sure about is how the link level routes appear
to get adjusted automatically and immediately.  Of course what I might
have seen were simply ARP table overwrites as packets arrived from the
new interface.  I didn't see any "arp info overwritten" messages though
(and indeed none of the addresses changed -- only the interface
associated).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>