Thomas Graf <[EMAIL PROTECTED]> writes: > What has been proposed so far is a stupid hack around something broken > in userspace.
Not sure. Ignoring routes going though failed interfaces doesn't seem like a hack at all. > What are you going to do when you need to overwrite a route while the > interface is up and running? Can't see a problem with that. > How does the above solve your problem for virtual routing links with > multiple hops in between? How are you going to detect the carrier of > non-adjacent media? The drivers are responsible (keep-alives etc). How is that relevant? > How does this solve your problem with drivers which > do not maintain the carrier state appropriately? Look, it doesn't fix the drivers which don't compile either, nor it writes new drivers :-) Not sure about coffee. I don't consider it "his problem" but rather a matter of correctness and least surprise. > What you need is a reliable way to tell whether that route can be > taken or not, please don't even think about telling me that IFF_RUNNING > is the way to go, we can do better than that, far better. IFF_RUNNING seems like a very reliable way to tell that the route _can't_ be taken. No reason to send packets (which will be blocked at queue level, BTW) if the device is down. > I see that disabling the routes for directly connected networks is the > easiest way to go for you at the moment because not a single bit has to > be changed in your daemon. And if there is no daemon? And we can "disable" all routes, direct and non-direct. Not that they are really disabled - just not used until the carrier (or whatever) is back. From your perspective nothing really changes. > It makes your routing daemon see things clear > while not taking care of anything. Look at the big picture and you'll see > it's completely useless because it's unreliable and doesn't work for > everyone, not even a majority. I think it should work transparently for everyone. What potential problem do you see? > The example of multiple gateway failover is brought up over and over > again. Very good marketing, the case of nexthop failover is exactly the > one where link state is completely useless and inappropriate. Really? How do you reach the next hop when your carrier is down? -- Krzysztof Halasa - 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
