properly handle on-link routes #373
Merged
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
When adding routes over vlan interface on port or bond interfaces, their port id will be 0, but they won't be a bridge interface either, so they get rejected. Fix this by using the function cnetlink::is_switch_interface(), which will also simplify the check a bit. Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
Do not rely on the nl_l3::get_neighbors_of_route() including the destination of the route as a nexthop, and instead do a test if we have a via or gw, and if not, use the remote directly as the next hop. Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
On-link routes will have a next hop with just the interface. In this case rtnl_route_nh_get_via will return a nullptr. In this case, just ignore the nexthop, and don't add it to unresolved_nexthops. This then allows dropping the special handling of LINK_SCOPE later on, since unresolved_nhs won't contain the route itself anymore. Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
On-link routes have no via, so they will never have a reachable nexthop. Demote the ERROR log to a debug log. Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
Now that we properly handle the on-link route in {add,del}_l3_route, we
do not manually need to add it in {add,del}_l3_addr anymore.
Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
rubensfig
approved these changes
Mar 9, 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.
Handle on-link routes like normal routes and don't add them as a side effect of handling ip addresses on interfaces.
Description
Currently on-link routes are added indirectly when adding ip addresses with a non all-1 netmask. But the kernel notifies us about these routes as well, and we try to handle them, but due to special handling they always stay as unresolved.
So fix this by allowing on-link routes (without any ip next hops) to be added and removed, and drop the special handling for ip addresses.
As a side effect includes a fix for routes on vlan interfaces on ports.
Motivation and Context
This is a preparation for tackling the non-routed L3 neighbor handling (#364). We need to know about on-link routes being added or going away, so we can determine if a neighbor is routable or not, and add/remove their flows.
How Has This Been Tested?
Running a full pipeline on ag5648 (currently in progress)
Depends on bisdn/meta-switch#54