-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ospf6d: Type-7 LSA originated with wrong sequence number #9193
Conversation
For the future – please, use "Fixes #X" or "Closes #X" instead of "Issue #X" to automatically close the issue when the PR is merged. |
Sure. Thanks for letting me know. |
Outdated results 💚Basic BGPD CI results: SUCCESS, 0 tests failed
For details, please contact louberger |
How about we just force push the commit change that addresses this issue |
Continuous Integration Result: SUCCESSFULContinuous 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-FRRPULLREQ-20561/ This is a comment from an automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings
|
RCA: When Type-7 LSA is updated, the LSDB is searched, if the LSA is present in the LSDB then the LSA is updated with next sequence number and if not then it is originated with the INITIAL sequence number. Here while originating Type-7 LSA Process Level LSDB is searched for instead of area level LSDB. Fix: Search in the area level LSDB and not in the process level. Fixes FRRouting#9099 Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
0bbe62d
to
96cad17
Compare
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
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 amd64 part 9: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-TOPO9U18AMD64-20570/test Topology Tests failed for Topotests Ubuntu 18.04 amd64 part 9:
see full log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-20570/artifact/TOPO9U18AMD64/ErrorLog/log_topotests.txt Successful on other platforms/tests
|
ci:rerun |
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 amd64 part 1: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-TP1U1804AMD64-20584/test Topology Tests failed for Topotests Ubuntu 18.04 amd64 part 1:
see full log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-20584/artifact/TP1U1804AMD64/ErrorLog/log_topotests.txt Topotests Ubuntu 18.04 arm8 part 8: Failed (click for details)Topotests Ubuntu 18.04 arm8 part 8: No useful log foundSuccessful on other platforms/tests
|
ci:rerun |
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 i386 part 1: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-TOPO1U18I386-20594/test Topology Tests failed for Topotests Ubuntu 18.04 i386 part 1:
see full log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-20594/artifact/TOPO1U18I386/ErrorLog/log_topotests.txt Topotests Ubuntu 18.04 amd64 part 6: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-TOPO6U18AMD64-20594/test Topology Tests failed for Topotests Ubuntu 18.04 amd64 part 6:
see full log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-20594/artifact/TOPO6U18AMD64/ErrorLog/log_topotests.txt Successful on other platforms/tests
|
ci:rerun |
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-FRRPULLREQ-20599/ This is a comment from an automated CI system. |
@Mergifyio backport stable/8.0 |
Command
|
RCA: When Type-7 LSA is updated, the LSDB is searched, if the
LSA is present in the LSDB then the LSA is updated with next
sequence number and if not then it is originated with the
INITIAL sequence number.
Here while originating Type-7 LSA Process Level LSDB is searched
for instead of area level LSDB.
Fix: Search in the area level LSDB and not in the process level.
Fixes #9099
Signed-off-by: Mobashshera Rasool mrasool@vmware.com