On Tuesday 18 February 2003 15:42, der Mouse wrote:
> >> *What* kind of routing?
> > The kind of routing where multiple default routes are possible;
> 
> I can't see any connection between that and having gateways that are
> off-net for all interfaces.

That's because I just threw it in offtopic.

> > Where communicating with an ethernet-connected gateway that isn't in
> > your specific netmask is simple;
> 
> It is?  How do you know which Ethernet?  Then, how do you find it?

In linux, this "just works":

IP: 1.2.3.4
nm: 255.255.255.0

route add -host 4.3.2.1 dev eth0
route add default 4.3.2.1

... presto.

Setting a default route in a similar fashion doesn't appear to work on NetBSD.

> I still can't figure out what it would even _mean_ to have a route
> pointing to a gateway what's not on-net for any configured interface
> address, or where you would expect such packets to be sent.

You can't program the default route with an IP address that isn't in your 
netmask, even if it's still on the same ethernet segment as you are.

> Hypothetical example:
> 
> 	Machine has
> 		le0	10.0.1.1/24 and 172.20.4.9/28
> 		fxp0	10.0.2.14/24
> 		ppp0	172.17.9.1 -> 10.0.3.44
> 		lo0	127.0.0.1/8
> 
> Now, we add a default route pointing to 192.168.14.88.  We send a
> packet to (say) 10.20.30.40, which doesn't match any of the interface
> routes.  Where do you expect it to go?  Why?  How is the OS supposed to
> figure that out?

Where is 192.168.14.88? How did that IP get in there? According to what you're 
describing above, 192.168.14.88 can't *be* the default route because NetBSD 
chokes on it. Or does it choke on it no longer? Appears to for me.

On Linux, we could do this to get around that minor problem:

route add -host 192.168.14.88 dev eth0
route add default 192.168.14.88

... and have it "just work". Assuming 14.88 is configured to deal with it.

With the default gateway in place, then the packet would be sent to the 
gateway, since the gateway would be assumed to be "smarter" and there are no 
local routes to the destination. Which IMHO is how it should be.

> Scrap the second address on le0 if it makes you happier.

It makes no difference in this case.

> > *Many* ethernet segments are shared by multiple networks.
> 
> Certainly.  And as far as I can see this fact is totally irrelevant to
> the discussion at hand.

Not at all. It currently seems impossible (unless perhaps I'm missing 
something, which itself is certainly possible) to set the default route to be 
an IP on one of those other networks.

> Putting this together with what sense I have managed to glean amid what
> you said, I get the feeling that you want either
[...]
> (b) Some kind of mutant IP, wherein multiple networks may be present on
> a given interface and a machine may have an address on fewer than all
> of them, but should attempt to communicate directly with addresses on
> any of them (presumably, the peer either has a similarly mutant stack
> or is not expected to be able to reply - you will also have to address
> how a host locates peers on networks like Ethernet where hardware
> addresses do not bear any direct relation to IPs).

Sure would be nice. This makes very little sense to me:

:douglas:17:13:52 /doke# route add -net 192.168.0.0 -interface 10.0.2.5
add net 192.168.0.0: gateway 10.0.2.5
:douglas:17:14:01 /doke# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.755 ms
[...]
:douglas:17:14:05 /doke# route delete default
delete net default
:douglas:17:14:08 /doke# route add default 192.168.0.1
writing to routing socket: Network is unreachable
add net default: gateway 192.168.0.1: Network is unreachable

Why is it bitching about an unreachable network? I just pinged the IP a moment 
ago. And I'm not saying it should attempt to communicate directly on the 
ethernet segments with hosts that it doesn't know about--unless I tell it it 
can.

Now, routing directly to foreign networks seems possible:

:douglas:17:13:52 /doke# route add -net 192.168.0.0 -interface 10.0.2.5
:douglas:17:13:54 /doke# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.897 ms

But not default routes.

> Yes, if you have a machine using (a), you may have to do a lot of
> hoop-jumping to communicate between it and a machine that does normal
> IP-over-Ethernet; mutatis mutandis, the same applies to (b).  I fail to
> see why it is a deficiency in NetBSD that it doesn't yet do so.  Has
> someone already standardized (a) or (b)?  If so, why not just point at
> the spec?  If not, how do you expect NetBSD to conform to a standard
> that doesn't exist?

I was actually under the impression before that the whole network would be 
considered unreachable, not just as a default route. I'm glad my tests have 
proven otherwise, but still it makes no sense not to allow a single host 
route that is directly reachable via ethernet to become a default route.

My other gripe is that NetBSD sends out the wrong interface, traffic which 
must be fast-routed with an ipfilter rule. A machine with:

fxp0: 64.1.2.3
fxp1: 10.0.0.5

... will answer out 64.1.2.3 when any non-specifically-routed traffic comes in 
on 10.0.0.5. With a source address of 10.0.0.5. That's just not right.

This is very interesting to me at any rate.