zebra: fix stale NHG in kernel (backport #18899) #19087
Closed
Conversation
This file contains hidden or 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
I see this issue during below events sequencing 1. zebra creates an nhe and sets 'initial delay' flag for the nexthop received along with kernel/connected route and this routes is a v6 route. 2. Later zebra receives intf_address event for the interface that belongs to the same nhe created above. but this is v4 event. Then zebra iterates through the nhe set linked to this interface and eventually it will end up installing this nhe in kernel So, we install the NHG in kernel for connected/kernel routes and that looks to be deviating from the expected behaviour. All this happens when we receive interface event, we attempt a reinstall for all the NHGs associated with that intf. But if the 'initial delay' is already set for an NHG, we can skip that. Fixing the same. Signed-off-by: Krishnasamy <krishnasamyr@nvidia.com> (cherry picked from commit d7f6d95) # Conflicts: # zebra/zebra_nhg.c
During FRR restart nexthop-group entries are not getting cleaned up in below scenario. 1. Let's say an NHG refcnt is getting decremented and it becomes zero. we add a timer for this NHG before deleting it in zebra/kernel. so this NHG will be intact in kernel until the timer expires. 2. Now, the timer is running and frr is getting restarted. All the NHGs are getting cleaned up in kernel but the one that has timer running is still installed in the kernel. Check if any NHG has timer running during zebra shutdown and remove from kernel. Signed-off-by: Krishnasamy <krishnasamyr@nvidia.com> (cherry picked from commit 0743cca)
|
Cherry-pick of d7f6d95 has failed: To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
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.
Fixing stale NHG issue in kernel.
Issue1:
So, we install the NHG in kernel for connected/kernel routes and that looks to be deviating from the expected behaviour. All this happens when we receive interface event, we attempt a reinstall for all the NHGs associated with that intf. But if the 'initial delay' is already set for an NHG, we can skip that.
Fixing the same.
Issue2:
During FRR restart nexthop-group entries are not getting cleaned up in
below scenario.
add a timer for this NHG before deleting it in zebra/kernel.
so this NHG will be intact in kernel until the timer expires.
NHGs are getting cleaned up in kernel but the one that has timer
running is still installed in the kernel.
Check if any NHG has timer running during zebra shutdown and remove from
kernel.
This is an automatic backport of pull request #18899 done by Mergify.