DragonFly kernel List (threaded) for 2003-10
Re: Any interest in updating the routing engine?
:*bsd routing engine. The CEF table is built by route lookups
:against the master table whenever a new flow hits the router. The
:route is then 'cached' in the CEF table and stays until the flow
:stops, or the route is invalidated by an external means, be it link
:status or routing updates from an external/internal routing protocol
:Essentially, Cisco's have a concept of more than one route for a
:given destination. I'd like to pull that logic into *bsd.
:----- Be warned, ugly paste from notes --------------
:The routing table should be expanded to include the following
Good god, how long have you been day dreaming about this?
Generally speaking I like the concept of a two-stage route table. I
have a few comments. First, I think interface aliases would have to be
treated the same as the primary interface address (that is, entered into
the route table automatically simply by existing).
Second, I like the concept of a two-layer route table with lookups based
on both the souce and target IP's (and associated masks). I am presuming
that the primary layer would contain the multi-homed routes and the
secondary layer would 'lock in' the selected interface for a flow, like a
TCP connection, on a temporary basis.
Third, I think that if we were to do this sort of thing we really would
want to completely rewrite the BSD route table radix tree code. The
existing code is a huge mess and does not suit an MP environment all that
well. And it would have to be done in the kernel or as a kernel module,
though perhaps development could be done in userland using message-passing
(to make it easier to develop, with a manual scan of interface IP/MASK's
if the route table is otherwise not available as an emergency fallback).
I haven't gone over your notes with a fine toothed comb but your ideas
sound quite interesting.