[quagga-dev 11726] Re: [quagga-dev,8747,RFC] ECMP for RIP

Feng Lu lu.feng at 6wind.com
Mon Nov 3 06:38:48 GMT 2014

On 07/30/2011 01:36 PM, Karel Tuma wrote:
> Hello list,
> This is quick&  dirty hack to get RIP with multipath running. Sorry it's
> such a huge blob and not series of patches - its mostly refactoring of
> existing code. In short:
> struct rip_info - now treats each nexthop separately. all nexthops for
> prefix are list chained. uniqueness is based from whom we've heard about
> the nexthop (which means no peer shall advertise two nexthops for same
> route).
> The basic idea is to remember all routes advertised, keyed by:
> from+prefix+nexthop (originally it was just the prefix).
> This will possibly break other parts of the code which blindly assume
> that struct route_node->struct rip_info always points to best nexthop,
> it will not, in fact, you'll see gc'ed route in there for sure someday.
> right now rip_output_process() and rip_zebra_ipv4_add() will just
> cherrypick whatever is there meaningful associated with given prefix
> (possibly multipath).
> Redistribution is probably broken horribly.
> This code is actually used in production (linux gateways connected to
> mesh of cheap L3/RIP A6400's via GigE links) and seem to coexist with
> all the rip-multipath speakers nicely.
> There are possibly few ways to improve upon this:
> - continue on hacking with rip_info's
> - split nexthop/peer ambiguity somewhere else (keep it in single
> rip_info?)
> - completely rewrite the thing and design it around prefix+nexthop
> instead of peer+prefix.
> Whatever the case, porting this to ripng is trivial as the protocol
> logic in there appears to be rather identical.
Hi Karel,

Thanks for your patch.

While other RIP ECMP patches have been applied. Please refer to the commits:

b397cf4 ripd: add ECMP support
0b74a0a ripd: allow to enable/disable the ECMP feature

Best regards,
Feng Lu

More information about the Quagga-dev mailing list