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

Reply via email to