Multiple routing table support commited
Julian Elischer
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
to compile it into a kernel you need
options ROUTETABLES=N where N is from 1 to 16
leaving it out, or setting it to 1 will have the effect of
creating a kernel that should behave as it did prior to this
commit.
In this work a kernel routing table is
referred to as a 'fib' (Forwarding Information Base).
I was informed by various routing people during this work
that this is the new-fangled correct name for an in kernel
routing(forwarding) table.
for more information see
setfib(1) and setfib(2)
This code, backported to 6.3 is running on Ironport appliances
and Cisco/Ironport has graciously allowed it to be given back.
julian
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Zaphod Beeblebrox
> 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.
Julian Elischer
> On Fri, May 9, 2008 at 8:52 PM, Julian Elischer <jul...@elischer.org
> <mailto:jul...@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.
There is a reason this stuff is called FIB stuff and not RIB stuff..
>
> 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 <http://192.168.10.1/24>
what has http got to do with ifconfig?
(or did your email agent add that?)
>
> ... and on router-b
>
> ifconfig vlan10 192.168.10.2/24 <http://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 <http://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.
yes but that's not the problem I'm trying to solve.
It IS however related to the multipath code that Qing Li committed a
couple of weeks ago..
Bruce M. Simpson
Thanks so much for this.
Julian Elischer 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.
I think you well deserve a break after all that effort. I look forward
to p4 merge >;->
[I waded into the pf code last week, to write a patch to allow IP Router
Alert out by default -- as it breaks IGMP/MLD and thus link-scope/all
multicasting.
It looks like it wouldn't be too difficult for someone to add a "setfib"
tag, however, this can break backwards compatibility with pfsync'ed
nodes if pfstate/pfrule are changed.]
> This code, backported to 6.3 is running on Ironport appliances
> and Cisco/Ironport has graciously allowed it to be given back.
Thanks also to them for making this possible.
cheers
BMS
Bruce M. Simpson
>>
>> >From my read of your file, this doesn't address FreeBSD's utter lack
>> of what
>> they often call an RIB
>>
>
> discussion on this subject.
Whoops, didn't realize this was -current, haven't had my coffee.
Sorry -- this topic has been bashed around a lot on net@ over the past
few months.
If multipath support is something which really concerns you, there are a
number of issues which have to be solved. There are a number of ways you
can get involved, but probably the best and most direct way is to learn
C and start hacking the code yourself -- it is open source after all and
people seem to forget this.
Good luck.
Bruce M. Simpson
> On Fri, May 9, 2008 at 8:52 PM, Julian Elischer <jul...@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.
>>
>>
>>
>> http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/julian/routing/plan.txt
>>
>
>
> 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.
>
Please read the history of this thread, as there has been extensive
discussion on this subject. FreeBSD doesn't need to have a RIB, that's a
job for routing control plane software such as XORP and Quagga/Zebra.
There are strong arguments against using the kernel forwarding tables as
an exchange medium, the strongest one being "that's not what it's for".
Thanks.
Julian Elischer
> Julian,
>
> Thanks so much for this.
>
>> 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.
>
> to p4 merge >;->
>
> [I waded into the pf code last week, to write a patch to allow IP Router
> Alert out by default -- as it breaks IGMP/MLD and thus link-scope/all
> multicasting.
> It looks like it wouldn't be too difficult for someone to add a "setfib"
> tag, however, this can break backwards compatibility with pfsync'ed
> nodes if pfstate/pfrule are changed.]
max laire did some of this already... check the pf files now.
there should already be some fib support..
look at teh pre commit diff at:
http://www.freebsd.org/~julian/mrt.diff.
the pf changes are right at the top.
I will admit that I haven't tested the pf changes, as they are
max's work but as its a "New" feature in freeBSD it can't hurt
any existing setups and I did confirm that the certainly don't break
any other code.
>
>> This code, backported to 6.3 is running on Ironport appliances
>> and Cisco/Ironport has graciously allowed it to be given back.
>
> Thanks also to them for making this possible.
>
> cheers
Randy Bush
> they often call an RIB --- where routes are chosen to be put into the FIB.
and planes should have wings. the kernel forwards, not runs a control
plane of routing protocols.
randy