In our hack around this we (Fastly) ended up adding a bgp_rte_same with pretty much everything you mention. One non-obvious addition is that we ended up enforcing that the multipath entry had the same next AS, i.e bgp_get_neighbor(new) == bgp_get_neighbor(old). With nothing else to tie break, we'd end up getting next hops towards the same prefix over different carriers. The problem with this is that with a high degree of route churn we'd get next hop invalidation, in which case a flow going over one carrier would flap onto another mid-flight, which had performance implications for users. We ended up enforcing this in our selection policy but it should arguably be optional (strict mode). On Sun, Jun 7, 2015 at 5:43 PM, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, May 22, 2015 at 12:13:31PM +0200, Alexander Frolkin wrote:
Hi Ondrej,
I was wondering how hard it would be to add BGP multipath support to BIRD, or if anyone was working on it already? BGP multipath is one thing we are currently working on.
That's great news! Do you know when it's likely to be available?
Hi
There is devel version of BGP multipath in our Git. Currently it allows to merge routes that have the same preference, bgp_local_pref, bgp_path length, bgp_origin, bgp_med (if relevant), ibgp/ebgp and igp_metric.
As BGP multipath is non-standard, i wonder what kind of BGP multipath behavior is expected by users and which options are necessary. I will probably add some option to relax check for equal bgp_path length.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."