* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-09 17:13 > Am Mittwoch 09 November 2005 15:25 schrieb Thomas Graf: > > > It's still behind eth3 but not reachable at the moment. If you know > > that the network can be reached via other interfaces then just don't > > statically assign a route for it and have the routing daemon take care > > of it, where's the problem? Nobody forces you to configure your > > addresses as prefixes, it's just a usability thing, really. > > This doesn't work. What do you think a routing daemon does when it is told to > announce a network/mask? It announces all interfaces that are in this range > with their network address, calculated by address and mask configured on that > interface. With your suggestion, it would announce /32, not the network > behind it.
Obviously you would tell the routing daemon of the network, it would then add it to the kernel and to its internal connected routes list. > And if that's not enough, the system would be totally unreachable without a > running routing daemon in this configuration. Never ever give your phone > number to an admin of such a router. Yes, what's your next argument? Running dhcp on every interface by default because the admin could forget adding the address at bootup and the system would be unreachable? > Wait, not totally. Broadcasts would always go out of this interface due to an > implicit route in the local routing table that should not be touched from > userspace. The broadcast routes in the local table are not generated for /31 and /32 prefixes. > > That should work, you have have two default routes, fib_detect_death() > > should notice that the first default route is dead and use the other. > > It implies the neighbour entry of the default gateway to be unreachable > > though so it might take a while to notice. > > For todays' failover requirements, It takes ages for an arp entry to timeout. I agree, we might just want to force a neighbour probe when the carrier is lost to speed this up. OTOH, userspace can always replace the default route when receiving !IFF_RUNNING notifications. My point is that in this example, disabling the route because of a carrier loss is just non-sense, the carrier state wouldn't help in many cases because f.e. although the carrier is up, the gateway is unreachable. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
