-
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: Fix flooding of old copies of self-originated LSAs #7202
Conversation
When receiving old copies (e.g. originated before the local ospf6d was restarted) of supposedly self-originated LSAs which we previously tried to flush from the network (by setting them to MaxAge), neither flood them nor add them to our LSDB. Instead, keep the MaxAge version until we actually (re-)originate them. Possible fix for FRRouting#7030. Testcase in FRRouting#7168 (tests/topotests/ospf6-dr-no-netlsa-bug7030). Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
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.
Thanks for your contribution to FRR!
Click for style suggestions
To apply these suggestions:
curl -s https://gist.githubusercontent.com/polychaeta/00815f70f33b65e0563c8a6672aed368/raw/0e3f9bcfefb20662338eccb364a8f902d03c6d42/cr_7202_1601414772.diff | git apply
diff --git a/ospf6d/ospf6_flood.c b/ospf6d/ospf6_flood.c
index 56aac0f21..d2423556d 100644
--- a/ospf6d/ospf6_flood.c
+++ b/ospf6d/ospf6_flood.c
@@ -1006,7 +1006,8 @@ void ospf6_receive_lsa(struct ospf6_neighbor *from,
if (is_debug)
zlog_debug(
"%s: Current copy of LSA %s is MAXAGE, but new has recent age, flooding/installing.",
- old->name, __PRETTY_FUNCTION__);
+ old->name,
+ __PRETTY_FUNCTION__);
ospf6_lsa_purge(old);
ospf6_flood(from, new);
ospf6_install_lsa(new);
@@ -1014,7 +1015,8 @@ void ospf6_receive_lsa(struct ospf6_neighbor *from,
if (is_debug)
zlog_debug(
"%s: Current copy of self-originated LSA %s is MAXAGE, but new has recent age, ignoring new.",
- old->name, __PRETTY_FUNCTION__);
+ old->name,
+ __PRETTY_FUNCTION__);
ospf6_lsa_delete(new);
}
return;
If you are a new contributor to FRR, please see our contributing guidelines.
After making changes, you do not need to create a new PR. You should perform an amend or interactive rebase followed by a force push.
💚 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-14434/ This is a comment from an automated CI system. Warnings Generated during build:Checkout code: Successful with additional warnings
Warnings Generated during build:Debian 10 amd64 build: Successful with additional warningsDebian Package lintian failed for Debian 10 amd64 build:
|
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.
a second pair of eyes would be nice to have; @odd22 , do you have some knowledge on ospfv3 ?
@pguibert6WIND I'm not so familiar with ospfv3, but after reading the corresponding issue #7030 and the proposed solution, it seems that the fix is OK for me and seems not introduce any side effect. May be @chiragshah6 could have a look to this PR as suggest by @gromit1811 |
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.
LGTM
Tested this fix by running an internal test that occasionally failed with this problem. Completed a loop of 400 test iterations over the weekend and it looks good. |
Note: This seems to fix my problem (at least the topotest in #7168 no longer fails), but I'm not sure whether it breaks other things (like the reboot problem 7624953 was trying to fix) as I'm not very familiar with the code in question. Needs proper review by an ospf6d wizard before merging.
When receiving old copies (e.g. originated before the local ospf6d was
restarted) of supposedly self-originated LSAs which we previously tried to
flush from the network (by setting them to MaxAge), neither flood them nor
add them to our LSDB. Instead, keep the MaxAge version until we actually
(re-)originate them.
Possible fix for #7030. Testcase in #7168
(tests/topotests/ospf6-dr-no-netlsa-bug7030).
Signed-off-by: Martin Buck mb-tmp-tvguho.pbz@gromit.dyndns.org