frr
frr copied to clipboard
zebra: Remove duplicate host routes for the loopback address
Currently two host routes are created for a loopback address on /32 subnet. The fix is to remove the one marked "local".
interface lo ip address 10.0.0.1/32 exit ! enke-vm1# show ip route 10.0.0.1/32 Routing entry for 10.0.0.1/32 Known via "local", distance 0, metric 0 Last update 00:03:38 ago
- directly connected, lo, weight 1
Routing entry for 10.0.0.1/32 Known via "connected", distance 0, metric 0, best Last update 00:03:38 ago
- directly connected, lo, weight 1
@ton31337 Yes, just "cosmetic" clean up to avoid questions from QA. Two entries are created, and the "local" one is not used.
@ton31337 Yes, just "cosmetic" clean up to avoid questions from QA. Two entries are created, and the "local" one is not used.
Not used yet, but eventually it should be preferred. As fixed here https://github.com/FRRouting/frr/commit/fb1f2cc9dfc95cce0422c74570dc3d52d4e255e9.
As I understand, the /32 loopback is commonly redistributed as "connected". I don't think it's safe to change it to "local".
That's one good reason to install only the "connected" /32 in this case.
Yes, from the redistribution perspective, it's harmful to prefer local over connected. (Unless they also exist without redistribution).
Hi, Don: no real issue, just code hygiene IMO. Is there any reason for creating two entries unnecessarily?
It's not unnecessary. How would you propose to do a redistribute local for the matching /32 routes in your case?
Even with two entries (one as "connected", and the other as "local") in RIB, only one can be chosen as the best and be redistributed. Currently the "connected" one is chosen, and that should not change (for backward compatibility). As I understand, that's also how it is commonly deployed, that is, "redistribute connected" includes the loopback.
The change is safe as currently "redistribute local" does not include that /32.
I just did a rebase. But the label "rebase" remains?
This pull request has conflicts, please resolve those before we can evaluate the pull request.
This PR is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this PR closed.