-
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: add a knob to generate Type-7 default routes #9585
ospf6d: add a knob to generate Type-7 default routes #9585
Conversation
@frrbot rereview |
Outdated results 💚Basic BGPD CI results: SUCCESS, 0 tests failed
For details, please contact louberger |
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-PULLREQ2-TP1U1804AMD64-82/test Topology Tests failed for Topotests Ubuntu 18.04 amd64 part 1:
see full log at https://ci1.netdef.org/browse/FRR-PULLREQ2-82/artifact/TP1U1804AMD64/ErrorLog/log_topotests.txt Topotests debian 10 amd64 part 1: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-PULLREQ2-TOPO1DEB10AMD64-82/test Topology Tests failed for Topotests debian 10 amd64 part 1:
see full log at https://ci1.netdef.org/browse/FRR-PULLREQ2-82/artifact/TOPO1DEB10AMD64/ErrorLog/log_topotests.txt Successful on other platforms/tests
Warnings Generated during build:Checkout code: Successful with additional warningsTopotests Ubuntu 18.04 amd64 part 1: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-PULLREQ2-TP1U1804AMD64-82/test Topology Tests failed for Topotests Ubuntu 18.04 amd64 part 1:
see full log at https://ci1.netdef.org/browse/FRR-PULLREQ2-82/artifact/TP1U1804AMD64/ErrorLog/log_topotests.txt Topotests debian 10 amd64 part 1: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-PULLREQ2-TOPO1DEB10AMD64-82/test Topology Tests failed for Topotests debian 10 amd64 part 1:
see full log at https://ci1.netdef.org/browse/FRR-PULLREQ2-82/artifact/TOPO1DEB10AMD64/ErrorLog/log_topotests.txt
|
CI:rerun |
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-PULLREQ2-100/ This is a comment from an automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings
|
0986409
to
ddbce5b
Compare
Outdated results 💚Basic BGPD CI results: SUCCESS, 0 tests failed
For details, please contact louberger |
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-PULLREQ2-154/ This is a comment from an automated CI system. |
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.
just one comment to @donaldsharp 's comment ... the code and operation look fine
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.
waiting on conflicts at this point
Fix wrong comparison since route->path.metric_type is always set to either 1 or 2. The OSPF6_PATH_TYPE_EXTERNAL2 constant, whose value is 4, refers to a route type so its usage was incorrect here. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When set to its default value, the metric type associated to a "redistribute" statement shouldn't be displayed as part of the running configuration. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
…mation-originate" The route created by the "default-information-originate" command isn't a regular external route. As such, an NSSA ABR shouldn't originate a corresponding Type-7 LSA for it (there's a separate configuration knob to generate Type-7 default routes). While here, fix a small issue in ospf6_asbr_redistribute_add() where routes created by "default-information-originate" were being displayed with an incorrect "unknown" type. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add the "default-information-originate" option to the "area X nssa" command. That option allows the origination of Type-7 default routes on NSSA ABRs and ASBRs. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
ddbce5b
to
6735622
Compare
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
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-291/ This is a comment from an automated CI system. |
Add a knob to generate Type-7 default routes on NSSA ABRs/ASBRs.
Syntax:
area A.B.C.D nssa default-information-originate [{metric (0-16777214)|metric-type (1-2)}]
.Example:
This PR also includes a few assorted fixes. Please refer to the individual commits for details.