Re: Multiple routing table support commited

On Fri, May 9, 2008 at 8:52 PM, Julian Elischer <julian_at_elischer.org> wrote:

> I have committed the base of teh Multi-routing-table support.
> I am current;y waiting for it to loop back to me before a final
> make universe test, but I think it should be ok.
> if you do nothing you should not see any difference.
>
> for a description  of what and how, look at:
>
>
> http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/julian/routing/plan.txt


>From my read of your file, this doesn't address FreeBSD's utter lack of what
they often call an RIB --- where routes are chosen to be put into the FIB.
Zebra does this to some extent, but there is one glaring case where zebra
cannot fix the problem and FreeBSD's actions need be improved.

Consider a colocation facility where customer equipment is on a vlan and
every one of these vlan's has two routers (each advertising RIP default
routes to the customer equipment).  All of these routers synchronize with
OSPF.

Now ... if vlan 10 on router-a and router-b both service a particular
customer, you would (on router-a)

ifconfig vlan10 192.168.10.1/24

... and on router-b

ifconfig vlan10 192.168.10.2/24

... and then the customer would take the other addresses on that network and
listen to RIP for his default route.

But there's a problem.  When you type this command on router-a, it will
dutifully advertise 192.168.10.0/24 to OSPF ... including to router-b... at
which point the ifconfig command on router-b will fail unless you offline
OSPF on router-b (which is an unattractive solution).

Now... some would argue that for all other uses of multiple routes, zebra
forms an adequate solution.  However, it does not address this particular
problem and there are far more uses of multiple identical routes (including
multipath, etc) s.t. FreeBSD really does need a multiple route plan.