multiple routing tables review patch ready for simple testing.

John Hay jhay at meraka.org.za
Fri May 2 17:43:01 UTC 2008


On Fri, May 02, 2008 at 04:44:20PM +0100, Bruce M. Simpson wrote:
> John Hay wrote:
> >The linux guys seems to have multiple fibs (or whatever they call them)
> >which they can chain together by giving them different priorities. The
> >effect seems to be that a packet will be matched through the highest
> >priority fib to the lowest until a route match is found en then is used.
> >Will something like that be possible? I came across that kind of use
> >with the olsr guys. They let olsrd twiddle one of the higher priority
> >fibs and then put fallback routes in a lower priority fib. That way
> >olsrd can override a route (even the default route) and when olsrd
> >exists and deltes all its routes, the original ones are still in the
> >lower priority fib and will be used.
> >  
> 
> XORP already does this without relying on any kernel support.
> 
> Each routing protocol supplies an origin table of its own. The RIB makes 
> the decision on which route to plumb to the kernel based on 
> administrative distance. When xorp_olsr exits, its origin table is 
> removed, and the winning routes are recalculated.
> 
> You don't need to go to the kernel for this sort of thing unless you 
> specifically need to implement route policy based on which interface(s) 
> a packet came in on.

Yes I know that. But in the world of adhoc wireless mesh networking
there are very few non-linux people, so they basically call the shots
and use the linux kernel features to the full. To them it is unneeded
complexity that the kernel already takes care of. :-/ In a sense I can
understand them because their stuff also run on the small embedded
stuff like the linksys wireless boxes and it needs to scale. The
biggest adhoc olsr network is probably the Freifunk one that have
more than 600 wireless nodes, mostly consisting of linksys boxes.

On some boxes that are also connected to different kinds of networks,
they run a different routing daemon into another fib and by setting
the priorities on the fibs, they can decide which daemon's routes
have the highest priority. And both routing daemons are happy because
the other is not stomping on its feet.

John
-- 
John Hay -- John.Hay at meraka.csir.co.za / jhay at FreeBSD.org


More information about the freebsd-net mailing list