Stefan, I am not gonna comment on this email although it is tempting. Can you refer to my latest email and see if we can reach some closure?
cheers, jamal On Sun, 2005-13-11 at 16:01 +0100, Stefan Rompf wrote: > 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 > - 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