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 <santi...@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: santi...@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."
