jamal <[EMAIL PROTECTED]> writes: > a) one that depends on the L3* states that goes around and marks every > route as "inactive". What "inactive" means is still unclear; it could > just be to add a blackhole route. Stefan and Krzysztof main proponents.
Blackhole is different, packets get simply dropped with it. Inactive route -> route entry is _ignored_ and next entries are considered by routing code. For example: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 ppp0 Normally default traffic is being routed out via 10.0.0.1 on eth0. With eth0 carrier down (dormant etc - ! IFF_RUNNING) eth0 routes are inactive (still present but ignored) and the ppp0 route is used. This example assumes eth0 (IFF_RUNNING) takes priority over ppp0. > b) one that treats oper status up/down no different than admin status > up/down for kernel owned routes with oper status behavior constrained by > a sysctl. Admin and operational down aren't very different but while we probably want "ifconfig down; ifconfig up" to drop routes we don't want that with a carrier down-up event. Kernel-added automatic direct routes are IMHO no exception. > c) dont do anything - current behavior is good enough. > Thomas main proponent. I think we should do it later, though. Device flags / oper status first. > My suggestion to move forward is: > i) Lets just stick to existing states in the RFC and no innovation of > any sort. This is backwards: > Issue-2) > User space may be involved in kicking some of these state transitions. > The issue is how to code so that you have no exposure to races from user > space being preempted etc. So we need a real code to see how to do it and if it could be done this way or needs another. > I think this is resolvable once we agree on recommendation for #1 above. > The main contention at the moment is between Thomas and Stefan - each > has a different approach and we want one patch not 10. So we now have one working patch, and we will probably have up to 2 more. Then we choose the best approach and the rest is easy. Come on, making a patch showing the general idea as well as the problematic details (locking) is trivial if the idea isn't broken. -- 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
