cnetlink: sync route cache on linkdown events #469
Merged
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.
Work around missing route removal notifications from kernel on link down with routes targeting nexthops on that link by forcing a cache resync on link down events to catch removed routes.
When a link goes down, the kernel will delete all nexthops on that link without sending out netlink notifications.
When a nexthop gets deleted, the kernel will delete all routes with the nexthop as destination without sending out netlink notifications.
These two combined means that when using nexthop objects, like FRR does by default, deletion of routes on link loss are never seen by libnl, and consequently never seen by baseboxd.
This causes flow table entries for routes to persist even though they were deleted in the kernel.
To work around this,
use nl_cache_resync_v2()
to trigger a resync of all routes when a link goes down.Motivation and Context
A customer reported routes still present in flow tables with EIGRP despite missing from kernel.
How Has This Been Tested?
Pipeline run with changes applied (87710 on cel-questone-2a).