> > We're talking about the auto routes in the main table, right? There > > is no reason for the addresses to be configured as a prefix, they > > can, and in my opinion should, be added as /~0 if the net is not > > guaranteed to be reachable at exactly this interface at all times. > > e.g. a user adding the address 1.1.1.1/24 on eth3 clearly says that > > 1.1.1.0/24 is always behind eth3, no matter what. > > Really? How it can be behind eth3 if state of eth3 says that "no packets > to this link - it's DOWN"?
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. > I'm not talking about new operational state of interface. I'm talking > about simple rule - if link is known to be unusable (!IFF_RUNNING), don't > use routes pointed to this link. Whether they are connected routes > created by kernel or static routes created by user. Sorry but OPER_DORMANT_L3DOWN is what this discussion was all about, if you're talking of something else you should say so. 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. Of course you could force everyone to use loopback devices implementing a heartbeat protocol which would control IFF_RUNNING but that's probably not what we want. In fact I think we should have a userspace daemon checking the links and putting them into dormant state upon failure so IFF_RUNNING gets cleared. > Simple scenario with my personal laptop - wired ethernet > (192.168.1.10/24) and wireless (172.16.100.10/24). Two defaults, wireless > one is with higher metric. If I walk away from my table and disconnect > wired ethernet cable, I'd expect that it wouldn't use default pointed to > wired network _and_ 192.168.1.0/24 pointed to it any more. Default > pointed to the wireless is there, wireless link is known to be usable > (IFF_RUNNING) and 192.168.1.0/24 is reachable via wireless as well. 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. If not this would be a bug and we'd have to look into this separately. * Paul Jakma <[EMAIL PROTECTED]> 2005-11-09 11:40 > The automatic kernel "connected" route should either be removed, or > ignored by the kernel until the interface is fully up (UP&RUNNING). > > E.g: > > A-B > | | > ----- > | > C > > B and A have a PtP link to each other and each have an interface to a > shared network, which has C on it. B's link to the subnet fails > (carrier is lost, IFF_RUNNING cleared), B now no longer can > communicate with C, even if it has a route to C via A (e.g. a default > route) because the kernel routing table still contains a valid > connected route for the shared subnet pointing out the ~IFF_RUNNING > interface. > > That connected route of the kernel should be removed (or marked > invalid/unusable in some way) while the interface is ~IFF_RUNNING. OK, I'm gonna explain how I see it a bit more detailed to hopefully make things clearer. Somehow it seems to be assumed that addresses have to be configured as prefixes, already including the netmask of the subnet it is on. This feature added recently is really only there to make life easier for the casual static routing case. It makes setting up static routes painless. As soon as the routes aren't static anymore they should be added by the daemon in charge, commonly the routing daemon. If the routing daemon sees the interface going down and has an alternative route it is in his responsibility to replace the route with the alternative route. - 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
