Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
As far as we currently understand, there are no routes / scenarios for which "next hop self" is actually needed, and it is actively harmful to have "next hop self" for routes that are being reflected. So the practical solution is not to configure "next hop self" at all. Here is the relevant BIRD code for what "next hop self" does: if (p->cf->next_hop_self || rta->dest != RTD_ROUTER || ipa_equal(rta->gw, IPA_NONE) || ipa_is_link_local(rta->gw) || (!p->is_internal && !p->cf->next_hop_keep && (!p->neigh || (rta->iface != p->neigh->iface)))) set_next_hop(z, p->source_addr); else set_next_hop(z, rta->gw); In other words, (1) If "next hop self" is set, the behaviour is to set the route's next hop to the peering's local address. (2) That also happens, without "next hop self" being set, for non-gateway routes - which include the local Calico endpoint routes that we are primarily interested in. When originating those routes, we do want the next hop that "next hop self" would give us, but the code above makes clear that we will get that anyway. On the other hand, if "next hop self" accidentally applies to a route that is being reflected, the effect is to insert the route reflector into the data path for traffic to that route - which is absolutely wrong. Net: unless/until we can identify any scenarios where "next hop self" is definitively needed, we should omit it.
- Loading branch information