On Tue 01 Apr 2014 10:27:03 BST, Andy wrote:
On Tue 01 Apr 2014 10:10:02 BST, Andy wrote:
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).
PS forgive me for bringing up an old discussion, but do any of these
features include enhancing the nexthop validation code?
Specifically to accommodate CARP interfaces, to allow setting the
nexthop on an announced route to a CARP IP address?
This currently doesn't work as OpenBGPD considers the CARP interface
as being a different network to the physical interface, even though
they are on the same segment and valid according to the BGP rules of
being directly connected.
Cheers :)
Andy
PS; Forgot to mention that we have sponsored a PhD/RA chap who is
slowly looking at this specific 'setting nexthop to CARP' enhancement
in his spare time. He's currently familiarizing himself with the
OpenBGPD code.
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.
