Please sign in to comment.
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 <firstname.lastname@example.org>
- Loading branch information...