Multiple routing tables in action...

[Bruce M. Simpson]

Julian Elischer wrote:
> The interaction with routing daemons is something I don't know
> enough about. I need someone who knows routing daemons to tell
> how to correctly tweek code that sends routing events.

As long as it doesn't break anything...

>
> I think it is possible that events from a particular FIB should only 
> be reported to routing sockets that are associated with that FIB.
> but I'm not sure about this.

Please look at the Linux rtnetlink socket, they use a tag-length-value 
protocol for just this reason.

It seems reasonable that PF_ROUTE messages have some kind of filter 
applied to them until a more complete story can be realised for this.
    Most PF_ROUTE clients are savvy enough to ignore message types on 
the socket that they don't understand.
    If there is a need to announce route adds and deletes on the socket 
on a per-fib basis, it seems reasonable to stash it in one of the unused 
fields (if we've got any of those..urp) and change the rtm_type field 
for now.

However it does take us further down a route (no pun intended) of 
incremental growth which has real risk (lack of or insufficiently rich 
test cases, requirements drift etc) and seems to be incumbent with open 
source in general.

>
> This would mean running a separate instance of the routing daemon for
> each FIB (VRF?).  Does this sound right to people?

Sounds crap! You really, really don't want to be doing that if you can 
avoid it.

Of course a lot of what's out there is not geared up to deal with it 
(and why would it be?) so it's fine for the time being, but it really, 
really can't be considered a complete, production-quality solution until 
the missing parts exist.
 
cheers
BMS

P.S. I am impressed by the scope and ambition of your work even if I 
haven't had a chance to digest it fully yet, and I hope that my concern 
about production quality open source here is not misinterpreted as 
nay-saying or disapproval by anyone.