nl_l3: only route l3 neighs if we have a route for them #374
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
IPv6 link-local will need some special handling, will fix that tomorrow. |
KanjiMonster
force-pushed
the
jogo_check_routability_of_l3_neighs
branch
from
02908fc
to
4719213
Compare
|
Fixed IPv6 by ignoring IPv6 LL addresses; these should be unroutable anyway. |
Make sure we do not add host entries for l3 neighs for which we do not have a route until we a route gets added, and drop the host entries again when the route gets removed. To do this, we need to start keeping track of all l3 neighs we currently handle. To make this easy, use a set, and reuse the nh_stub to store the neighbor information. Due to IPv6 LL addresses being a bit more complicated, and should never routable anyway, do not track them. To allow nh_stub to be used in a set, we need to make it comparable, so implement the < operator for it. Using this we can then determine the routability of a l3 neigh we add by asking the kernel for the route to it, then checking if it has a nexthop that exist on one of our interfaces. Only if this is true, add a host route for it and add it to the set of routed l3 neighbours, in all other cases add it to the set of unrouted l3 neighbours. Then when adding a route, add all currently unrouted l3 neighbors matching this route, and conversely, when removing a route remove all matching l3 neighbors that are currently routed. Fixes l3 neighbours learned on an additional on-link staying reachable after removing the on-link route. Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
KanjiMonster
force-pushed
the
jogo_check_routability_of_l3_neighs
branch
from
4719213
to
0fdba0d
Compare
rubensfig
approved these changes
Mar 11, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Make sure we do not add host entries for l3 neighs for which we do not
have a route until we a route gets added, and drop the host entries
again when the route gets removed.
To do this, we need to start keeping track of all l3 neighs we currently
handle. To make this easy, use set, and reuse the nh_stub to store the
neighbor information.
To allow nh_stub to be used in a set, we need to make it comparable, so
implement the < operator for it.
Using this we can then determine the routability of a l3 neigh we add by
asking the kernel for the route to it, then checking if it has a nexthop
that exist on one of our interfaces.
Only if this is true, add a host route for it and add it to the set of
routed l3 neighbours, in all other cases add it to the set of unrouted
l3 neighbours.
Then when adding a route, add all currently unrouted l3 neighbors
matching this route, and conversely, when removing a route remove all
matching l3 neighbors that are currently routed.
Fixes l3 neighbours learned on an additional on-link staying reachable
after removing the on-link route.
Signed-off-by: Jonas Gorski jonas.gorski@bisdn.de
How Has This Been Tested?
Using the commands from #364 and verified that no host entries get added without a on-link route, and the host entry appearing and vanashing when adding and removing the on-link route.
Running a pipeline on ag5648 to check for regressions.