* jamal <[EMAIL PROTECTED]> 2005-11-13 10:09 > Issue-1) > We have agreed to implement based on 2863. > Stefan has gone one step further and suggested extra states for L3 > status. The idea for the extra states being to resolve in this fix old > standing issue (since 2.2 days) of higher metric routes being added > based on ip address add/del and admin status. > > c) dont do anything - current behavior is good enough. > Thomas main proponent.
That is a very misleading statement. I said current behaviour is good enough on the _kernel_ side. What has been proposed so far is a stupid hack around something broken in userspace. You need control over the routes? Take it! It's all yours. You really want to tell me that disabling/deleting/cuddling those routes upon a carrier loss solves you problem with control? You must be kidding. What are you going to do when you need to overwrite a route while the interface is up and running? Insert yet another hacky state to be set by the routing daemon but not affecting IFF_RUNING? 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? How does this solve your problem with drivers which do not maintain the carrier state appropriately? This is all a big joke, right? 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. 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. 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. Let me ask you one thing, how would you solve this problem in pre 2.2 era? That's what you get with my proposal, still unsolvable? 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. Who said the nexthops share the same carrier? This case must be solved by exchanging information with the nexthop, easiest solution being a neighbour probe. Doesn't work? Let's fix it. Take control over those routes, it's the job of a routing daemon after all, isn't it? - 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
