[PATCH] More multipath support for OSPF

[Ondrej Zajicek]

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 at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20140206/89d471c8/attachment-0001.asc>