Multiple routing tables in action...

[Julian Elischer]

Max Laier wrote:
> On Tuesday 29 April 2008 20:19:14 Julian Elischer wrote:
>> Paul wrote:
>>> I've been waiting for something like this.  Linux has done policy
>>> routing for many many years and is very good at it.  I prefer to use
>>> FreeBSD for routing though and this is a feature I have been waiting
>>> for :) Mainly to use with BGP , having multiple BGP routing tables.  
>>> I would like it to be similar to Cisco's VRF or Juniper's routing
>>> instance, but maybe that's asking too much.  We use it on our
>>> hardware routers for implementations such as having multiple bgp
>>> route tables and having customer bandwidth pricing change based on
>>> which routing table their traffic gets , say.. value customers,
>>> premium customers, customers who want only certain carriers in their
>>> bandwidth mix, etc.   Would be fun to have support for FBSD with
>>> quagga/openbgpd etc.. and be able to use dscp for marking or any
>>> other policy based rule (source ip for instance).
>>>
>>> Thanks Julian.. This is a step forward in the right direction :)
>> 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.
>>
>> 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.
>>
>> This would mean running a separate instance of the routing daemon for
>> each FIB (VRF?).  Does this sound right to people?
> 
> OpenBSD "added"[1] a field to the rt_msghdr to indicate/select the 
> source/destination table.  If we were to do the same at least OpenBGPB 
> should work with fairly minimal changes.

I would like someone who knows routing daemons to add this
or tell me what needs to be done.

> 
> I think it's a sensible approach, too.  A routing daemon wouldn't have to 
> select over a dozen sockets to do what is needed and it will be much 
> easier as well.  If easily done, a way to "bind" a route socket to a 
> table id would also be nice as it would easily make things work with 
> multi table oblivious daemons.

I already have a socket option that works on routing sockets to bind 
them to a FIB.

and /usr/bin/setfib can be used to make a fib-unaware process bind by 
default to a set fib.
e.g. setfib -2 routed [args]




> 
>