Hi Claudio and Stuart, thanks for your replies.
On Mon 31 Mar 2014 22:29:47 BST, Claudio Jeker wrote:
On Mon, Mar 31, 2014 at 07:59:19PM +0100, Stuart Henderson wrote:
On 2014/03/31 09:31, Andy wrote:
Hi Stuart,
Does Henning, Claudio or any of the other developers have any plan to
implement BGP equal cost multi-path support (maximum-paths) to OpenBGPd?
No idea about anyone else's plans...
For me it is fairly low on the todo list. I think that BGP equal cost
multi-path will not trigger most of the time since the routes need to be
equal till fairly far down the decision tree. There are more important
things to solve first (some of them bugs, some of them "features" and some
of them real features).
Yea that will definitely be the case for multi-homed redundant
Transits. And I have no doubt there are other very important things on
the list too.
If its OK I would like to highlight however that nearly every network I
know (the vast majority of the networks who we peer with at LONAP and
LINX in London and Amsterdam at least) have multiple routers attached
to the IXP exchanges, and in all those cases nearly every route learned
from those peers do match all the way down.
Our peerings now cover over 13% of the full Internet routing table
(currently 65549 routes out of 487459) and this is increasing.
And so around 12% of the Internet is being forced out only one IXP
connection via one ASBR leaving the other one mostly idle except for
some inbound packets which I am trying to steer with MEDs etc.
Anyway, this is becoming more common as IXPs now reach more and more
data centers and providers connect to the same exchanges at multiple
data centers.
I guess it should be quite quick to add as OpenOSPFd already supports this
and the kernel FIB is ready.
I don't think it's safe to assume "quick" here - at the very least, bgp
has a bunch more code handling nexthop validity than ospfd does.
The bgpd RIB and FIB is a fair bit different from the ospfd one. While
some basic ideas may be reused I doubt there is a lot of code that could
be shared.
Additionally I suspect this will result in bgpd needing to revalidate
routes more often, which is a known problem area for out-of-memory crashes
in bgpd's RDE.
Yeah, this is something we need to fix first (see above).
Interesting, does that mean OpenBGPD currently only revalidates the FIB
routes and not the RIB routes.
Adding these two features has obvious and significant benefits. BIRD already
supports ECMP and BFD but I would rather stick with OpenBGPd as it is
developed against OpenBSD :)
Note that I mostly added the BIRD port to test interop with bgpd/ospfd -
I've only run it minimally to test basic operation, and haven't had much
feedback about the port, so consider it not particularly well tested on
OpenBSD at this point.
If running BIRD I'd suggest probably doing it on a Linux-ish system..
While it does get some use on BSDs (I know of someone using it for a big
wireless network on FreeBSD) it's originally written for Linux and some
things aren't supported on BSDs. Case in point:
$ cat `find . -type f` | grep -c RTF_MPATH
0
:) As mentioned we would rather stick with OpenBGPD than try and make
BIRD work. I really don't want to have to go down that road..
There is also a GSoC project to get BFD into OpenBSD. So if a student is
interested in working on that that would be an oportunity.
Great news, crossing fingers we have some budding student with awesome
C skills is up for the challenge.
As always, thanks for your great work!
Cheers Andy.
