pimd: Figure neighbors -vs- paths when doing RPF

When we are looking up a RPF with a ecmp path, there
are situations where we are failing to find a path change
because we were not considering the actual number of neighbors
we have available to us at the start of the loop.

Example:

Suppose 2 way ecmp with a neighbor on each path.  We have
multiple upstreams that are strewn across both paths.
If we loose a pim neighbor on one of the paths we would
initiate a rescan of the upstreams.  If the neighbor
we lost happened to be the last ecmp path we rescanned
we would not successfully find a new path and leave
the upstream stranded.

This code change looks at the number of available neighbors
that we have -vs- the number of paths we have and chooses
the smaller of the two for figuring out what to do.

There probably exist other failure scenarios as well that
I am missing here and quite frankly the current code muddies
the water between a RPF lookup failure -vs- a RPF lookup succeeded
and there are no paths.  Further work is needed here imo.

Additionally this idea of a pim_ecmp_nexthop_lookup and
pim_ecmp_nexthop_search is bogus.  They are the same function and
should be merged at some point in time.

Ticket: CM-21599
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

0 files changed, 0 insertions, 0 deletions