zebra: Mark connected route as installed after interface flap event #13249
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
Issue: After vlan flap, zebra was not marking the selected/best route as installed. As a result, when a static route was configured with nexthop as directly connected interface's(vlan) IP, the static route was not being installed in the kernel since its nexthop was unresolved. The nexthop was marked unresolved because zebra failed to mark the best route as installed after interface flap. This was happening because, in dplane_route_update_internal() if the old and new context type, and nexthop group id are the same, then zebra doesn't send down a route replace request to kernel. But, the installed (ROUTE_ENTRY_INSTALLED) flag is set when zebra receives a response from kernel. Since the request to kernel was being skipped for the route entry, installed flag was not being set Fix: In dplane_route_update_internal() if the old and new context type, and nexthop group id are the same, then before returning, installed flag will be set on the route-entry if it's not set already. Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
Continuous Integration Result: FAILEDContinuous Integration Result: FAILEDSee below for issues. This is a comment from an automated CI system. Get source / Pull Request: SuccessfulBuilding Stage: SuccessfulBasic Tests: FailedTopotests Ubuntu 18.04 arm8 part 9: Failed (click for details)Topotests Ubuntu 18.04 arm8 part 9: Unknown Log URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-10771/artifact/TOPO9U18ARM8/TopotestDetails/ Topotests Ubuntu 18.04 arm8 part 9: No useful log foundSuccessful on other platforms/tests
|
|
@Mergifyio backport stable/8.5 stable/8.4 |
✅ Backports have been created
|
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-10771/ This is a comment from an automated CI system. |
mjstapp
approved these changes
Apr 12, 2023
This was referenced Apr 12, 2023
donaldsharp
added a commit
that referenced
this pull request
Apr 12, 2023
zebra: Mark connected route as installed after interface flap event (backport #13249)
donaldsharp
added a commit
that referenced
this pull request
Apr 12, 2023
zebra: Mark connected route as installed after interface flap event (backport #13249)
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.
Issue:
After vlan flap, zebra was not marking the selected/best route as installed.
As a result, when a static route was configured with nexthop as directly connected interface's(vlan) IP, the static route was not being installed in the kernel since its nexthop was unresolved. The nexthop was marked unresolved because zebra failed to mark the best route as installed after interface flap.
This was happening because, in dplane_route_update_internal() if the old and new context type, and nexthop group id are the same, then zebra doesn't send down a route replace request to kernel. But, the installed (ROUTE_ENTRY_INSTALLED) flag is set when zebra receives a response from kernel. Since the request to kernel was being skipped for the route entry, installed flag was not being set
Fix:
In dplane_route_update_internal() if the old and new context type, and nexthop group id are the same, then before returning, installed flag will be set on the route-entry if it's not set already.