Am Sonntag 13 November 2005 15:13 schrieb jamal: > > Obviously, no. I mean route entry "inactive" flag (not existing yet) > > which has exactly nothing to do with its destination. > > I dont know what that would buy you that a blackhole route could not > give you: Packets will be dropped at the ip level way before they hit > device level.
Most stuff needed for the inactive flag is already there to support multipath, so the change is quite small and even removes the abusage of RTNH_F_DEAD for fib flushing. I have a patch there that marks routes as inactive, however, I still have some bugs reactivating them. To answer your question, why setting a route to inactive: We know we have to do something about kernel generated routes. Thomas' ideas with /32 do not work (Thomas, f.e. try to get OSPF running with this suggestion, OSPF needs the interface property netmask). One idea is to remove the kernel generated routes when the interface is oper down. No doubt, that would be enough for routing daemons. However, if we mark routes inactive, we would also increase usability without a routing daemon: If queueing drops packets to the device anyway, do not even consider using it. Very nice for fast failure response towards applications. 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
