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. Now you try redistribute static routes. However, you cannot convert an external route as intra-area in OSPF, as you would need to. 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. 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. Should the routing daemon do another bit of guesswork here? It would also be interesting to see what a dhcp server does if it cannot find the interface it should serve leases on. Or keepalived. This idea is so insane that you should bury it as soon as possible. Really. > IFF_RUNNING is a very weak way to detect if an interface is unusable, > not all drivers correctly report the carrier state and overubscriptions, > or carrier losses on virtual links are a far more likely cause for a link > getting unusable. We should solve this issue correctly and not just work > around it. Carrier detection is being added to more and more (ethernet) drivers. Devices that support it can benefit from this feature, the rest cannot. > 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. Anyway, we might be getting too off topic. Let's first see whether my RFC2863 idea or the dormant/protocol flag makes it. Stefan - 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
