On Thu, Feb 06, 2014 at 02:17:12PM +0100, Peter Christensen wrote:
Hi,
Hello
I noticed that the multipath support in OSPF seems to be fairly limited. Essentially I was only able to make it do multipath if I had two interfaces connecting to the same router. At my company, we need true multipath between multiple routers using a single interface. (If I needed the other, I could use LACP)
Not if such multipath spans multiple routers (e.g. a network consists of several routers connected by ptp links to a circle. Also note that even if you have just one interface, you still get ECMP if there are several paths (through different neighbor routers) to one router few hops away.
I am aware of the implications the default multipath implementation in Linux which operates on a per-packet basis, which is why we've patched our kernels to do it per-flow instead.
Really? AFAIK default Linux implementation is per-flow, not per-packet, unless this was changed recently.
Anyway, I seemed to have managed to make multipath work as expected - at least in our setup. (Patch attached)
Well, what is expected is the question. BIRD currently do multipath on idea that multiple paths through OSPF network topology to one destination in one area are merged, but two same routes originated by two different routers are considered different destinations (which makes perfect sense for propagated default gateways or anycast destinations). You patch merges such routes from different routers, but still keeps routes from different area. Few months ago, Volodymyr Samodid commented that ECMP in OSPF should merge paths from multiple areas. So it seems that this should be at least configurable (like 'ecmp merge internal <bool>', 'ecmp merge external <bool>', 'ecmp merge areas <bool>'). The question is how much detailed such configuration shouldbe. For example, it may be useful to merge external routes with the same route tag, but not merge external routes with different ones. And what about merging internal and external routes together, is this useful? Any thoughts on this issue?
Essentially, I've hooked my multipath code into ri_install_ext() and ri_install_net(), where I add the equal routes if the routes share the same type, metrics and OSPF area. I realize that my add_nexthops() is /very/ similar to merge_nexthops() in functionality, but it seemed that the top_hash_entry() could be null, so I wrote a new method which did not rely on that - at the cost of more calls to copy_nexthop(), I guess.
Any thoughts?
The implementation looks clear and simple, i will look at it thoroughly in a few days. On the first look i see that the patch forgot to zero orta->rid and perhaps orta->tag if merged routes have it different. -- 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."