zebra: remove kernel routes that are suppressed#3165
zebra: remove kernel routes that are suppressed#3165eqvinox merged 1 commit intoFRRouting:masterfrom
Conversation
mjstapp
left a comment
There was a problem hiding this comment.
Had a couple of questions in-line
zebra/zebra_rib.c
Outdated
| redistribute_delete(p, src_p, re); | ||
| UNSET_FLAG(re->flags, ZEBRA_FLAG_SELECTED); | ||
| if (RIB_KERNEL_ROUTE(re)) | ||
| SET_FLAG(re->flags, ROUTE_ENTRY_REMOVED); |
There was a problem hiding this comment.
I don't understand what effect this will have - no one looks for ROUTE_ENTRY_REMOVED in the flags field?
There was a problem hiding this comment.
actually, this flag is looked up for route reap entries process
zebra/zebra_rib.c
Outdated
| UNSET_FLAG(re->flags, ZEBRA_FLAG_SELECTED); | ||
| if (RIB_KERNEL_ROUTE(re)) | ||
| SET_FLAG(re->flags, ROUTE_ENTRY_REMOVED); | ||
| if (CHECK_FLAG(re->status, ROUTE_ENTRY_REMOVED)) { |
There was a problem hiding this comment.
was this meant to use the REMOVED flag set above? if so ... why - won't the normal reaping of route_entries later in the processing flow do what's needed?
There was a problem hiding this comment.
I will do the test with just the set of the REMOVE flag
if the reap process is called, then I will just keep the set of the remove flag in the code.
if this does not work, I will directly remove the route if it is a kernel route.
There was a problem hiding this comment.
test done, and pr updated.
please review
zebra/zebra_rib.c
Outdated
| SET_FLAG(re->flags, ROUTE_ENTRY_REMOVED); | ||
| if (CHECK_FLAG(re->status, ROUTE_ENTRY_REMOVED)) { | ||
| if (IS_ZEBRA_DEBUG_RIB) { | ||
| rnode_debug(rn, re->vrf_id, "rn %p, removing kernel entry re %p", |
There was a problem hiding this comment.
this clause will affect all route types, but the comment suggests you meant it as a special case just for KERNEL routes?
There was a problem hiding this comment.
yes, I just want to flush the kernel routes that becomes unselected.
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-5617/ This is a comment from an EXPERIMENTAL automated CI system. CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base |
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
e7dbc54 to
000baf2
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-FRRPULLREQ-5624/ This is a comment from an EXPERIMENTAL automated CI system. CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base |
|
after simplification of algorithm, the result is still satisfying, ie the route is suppressed from Zebra RIB, after interface goes down. |
000baf2 to
48e022a
Compare
Continuous Integration Result: FAILEDSee below for issues. This is a comment from an EXPERIMENTAL automated CI system. Get source and apply patch from patchwork: SuccessfulBuilding Stage: FailedUbuntu1404 amd64 build: Successful NetBSD6 amd64 build: FailedDejaGNU Unittests (make check) failed for NetBSD6 amd64 build: (see full PyTest log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-5637/artifact/CI007BUILD/ErrorLog/log_pytests.txt) NetBSD6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-5637/artifact/CI007BUILD/config.status/config.status NetBSD7 amd64 build: FailedDejaGNU Unittests (make check) failed for NetBSD7 amd64 build |
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
| /* Update nexthop for route, reset changed flag. */ | ||
| nexthop_active_update(rn, old, 1); | ||
| UNSET_FLAG(old->status, ROUTE_ENTRY_CHANGED); | ||
| if (!nexthop_active_update(rn, old, 1) && |
There was a problem hiding this comment.
my understanding of the problem is that the kernel route has a nexthop who's interface is down now and we are not getting a callback about it. What happens when that interface comes back up, is the kernel route restored?
There was a problem hiding this comment.
when interface comes back up, the kernel route did not restore the route, because the route was flushed.
in the kernel I tested ( ubuntu 16.04), the route is flushed when nexthop is unreachable.
There was a problem hiding this comment.
I'm really confused about what we are trying to fix then. If the route is flushed are we not getting a RTM_DELROUTE for it?
There was a problem hiding this comment.
yes. we are not getting RTM_DELROUTE
we received the interface down event.
but we did not receive the RTM_DELROUTE event
There was a problem hiding this comment.
Confirmed that when an interface goes down, there is no DELROUTE for IPv4 routes, they're silently deleted from the kernel.
But I'm not sure the fix is correct?
There was a problem hiding this comment.
I'm not really sure where the fix should go either, have been tossing it around in my mind for a while now and not really coming up with something better. Let me spend a few minutes here thinking about it.
There was a problem hiding this comment.
so I like the fix because it's targeted to just kernel routes, in my mind it's not a lot different than the here be dragons bit of code. I think I'm ok with this.
There was a problem hiding this comment.
I'm going to add a comment above this and merge
Continuous Integration Result: FAILEDSee below for issues. This is a comment from an EXPERIMENTAL automated CI system. Get source and apply patch from patchwork: SuccessfulBuilding Stage: FailedUbuntu1404 amd64 build: Successful NetBSD6 amd64 build: FailedDejaGNU Unittests (make check) failed for NetBSD6 amd64 build: (see full PyTest log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-5637/artifact/CI007BUILD/ErrorLog/log_pytests.txt) NetBSD6 amd64 build: config.status output from configure script can be found at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-5637/artifact/CI007BUILD/config.status/config.status NetBSD7 amd64 build: FailedDejaGNU Unittests (make check) failed for NetBSD7 amd64 build |
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-5637/ This is a comment from an EXPERIMENTAL automated CI system. CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base |
|
as remind, we are trying to fix #3152 |
on some cases, kernel routes are not selected, because the kernel suppressed it without informing the netlink layer that the route has been suppressed ( for instance, when an interface goes down, the route never goes back when interface goes up again). This commit intends to suppress that entry from zebra. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
48e022a to
212df1d
Compare
|
just rebased |
💚 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-FRRPULLREQ-5671/ This is a comment from an EXPERIMENTAL automated CI system. CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base |
on some cases, kernel routes are not selected, because the kernel
suppressed it without informing the netlink layer that the route has
been suppressed ( for instance, when an interface goes down, the route
never goes back when interface goes up again). This commit intends to
suppress that entry from zebra.
Signed-off-by: Philippe Guibert philippe.guibert@6wind.com
Summary
[fill here]
Related Issue
[fill here if applicable]
Components
[bgpd, build, doc, ripd, ospfd, eigrpd, isisd, etc. etc.]
Always remember to follow proper coding style etc. as
described in the FRRouting Dev Guide.
http://docs.frrouting.org/projects/dev-guide/en/latest/workflow.html