Symptom
Route reflector chooses EVPN Ethernet Auto-discovery Route learned from route reflector peer as bestpath instead of the path learned directly the route reflector client.
Conditions
Client is peering with multiple route reflectors, with route reflectors peering with each other and each having different cluster-id.
Workaround
Configure the route reflectors with the same cluster-id.
Further Problem Description
This behavior can result in high CPU. A particular route reflector will likely learn a route from the client first and and advertise it out before receiving a copy from its peering route reflectors. Because the route-reflector learned path is then chosen as best, a withdrawal will be sent to peering route-reflectors as non-client learned paths are not to be advertised to non-clients. All the peering route reflectors will thus be left with only the client-learned path and start advertising again. This creates the potential for a cycle of updates and withdrawals, causing high CPU. This can eventually converge if the timing of the updates and withdrawals settles on a state where one route reflector in the cluster only has the client-learned path with no other updates pending. A consequence of this is that a cluster may have only one device that forwards the path into the network and thus loses the redundancy of having redundant route reflectors.
The bestpath decision causing this behavior occurs prior to the traditional bestpath tie-breaking algorithm, so there is no policy that can bypass it. The problem can be avoided by configuring the same cluster-id within the cluster peering with the same client, as then the route reflectors will not advertise the route to each other and trigger the bestpath behavior.
