[PATCH] More multipath support for OSPF

[Ondrej Zajicek]

On Thu, Feb 06, 2014 at 09:47:03PM +0100, Peter Christensen wrote:
>>> 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).
> The way I interpret the OSPFv2 spec, a destination is simply an IP  
> address prefix. There may be several routes to a particular destination  
> through a lot of routers, but if multiple routes to that destination  
> exist whcih seems identical in quality (cost etc.), those routes are  
> eligible for multipath - even though those destinations are default  
> gateways or anycast destinations (anycast destination are after all  
> indistinguishable from ordinary destinations). So at least what I expect  
> is that /any/ seemingly equal route to a given network should be merged  
> into a multipath route if ecmp is enabled.

I checked the OSPFv2 spec and you are right, your interpretation seems
to be more in line with the meaning of the OSPFv2 spec.

>> 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.
> Really? From RFC 2328 (OSPF Version 2) section 16.8 (page 178):
> ...
> Arent't they saying that each route in the multipath entry must share the same associated area?

Sorry, i misremembered that comment, it was related to merging of
external paths, not merging paths from different 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?
> At least from the RFC 2328 point of view, it apparently doesn't make  
> sense to merge the routes across different types of routes. But I guess  
> that boils down to the fact that they usually have different costs.

You are right, merging routes from different areas or of different types
does not really make sense.

>>> 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.
>>
> Yeah, I guess clearing rid makes sense since the route is really from  
> different routers. As for the tag, I'm not sure what the expected  
> behavior is, since it is out of the scope of the OSPFv2 spec. Maybe that  
> is cause enough to make it tunable whether routes with different tags  
> can be merged.
>
> Another thing I've personally noticed, is that I should probably also  
> check ORTA_NSSA, ORTA_PROP and ORTA_PREF when verifying equal cost  
> routes in ri_install_ext. ri_better_ext is after all taking them into  
> consideration.

Note that the last comparison in ri_better_ext() is based on rid, which
means that you would have to merge ext routes even in some cases when
ri_better() returns true. Or perhaps change ri_better_ext() to
ri_compare_ext() returning -1, 0, 1 to avoid complicated
ri_equal_cost().

Also i am not sure if we would not have to merge next hops in
ri_install_rt() for the purpose of summary-rt LSA processing, i would
have to look deeper at this.

-- 
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/20140210/4a02e305/attachment-0001.asc>