-
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
pim, pim6d: pimreg interface is not getting added in a certain scenario #13822
Conversation
Problem: When ipv6 pim configuration is removed from the IIF on FHR node, if we wait for RST timer to expire and then add the ipv6 pim configuration on the IIF again, it is seen that pimreg is not getting added due to which null register wont be sent, the register flag state also remains NO_INFO forever instead of RegPrune. The reason for this is, when RST timer expires and IIF is unknown for the (S,G) upstream, the FHR state is not reset due to which when the RP becomes reachable, upstream state changes from NotJoined to Join but the register suppress timer could not be started since we see there is no change in FHR state. Fix: When the Register Timer expires and the reg state is set to PIM_REG_NOINFO,reset the FHR flag, so that when the RP becomes reachable can be because of config change or RP not reachable, it is able to resume its duty. Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.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 i386 part 9: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-PULLREQ2-TOPO9U18I386-12441/test Topology Tests failed for Topotests Ubuntu 18.04 i386 part 9 Topotests Ubuntu 18.04 i386 part 1: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-PULLREQ2-TOPO1U18I386-12441/test Topology Tests failed for Topotests Ubuntu 18.04 i386 part 1 Topotests Ubuntu 18.04 i386 part 3: Failed (click for details)Topotests Ubuntu 18.04 i386 part 3: Unknown Log URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-12441/artifact/TOPO3U18I386/TopotestDetails/Topology Test Results are at https://ci1.netdef.org/browse/FRR-PULLREQ2-TOPO3U18I386-12441/test Topology Tests failed for Topotests Ubuntu 18.04 i386 part 3 Successful on other platforms/tests
|
ci:rerun bgpd and ospf failures |
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-PULLREQ2-TOPO9U18AMD64-12453/test Topology Tests failed for Topotests Ubuntu 18.04 amd64 part 9 Successful on other platforms/tests
|
ci:rerun test_ospf_sr_te_topo1 failed which is not related to this change |
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-12462/ This is a comment from an automated CI system. |
Problem:
When ipv6 pim configuration is removed from the IIF on FHR node, if we wait for RST timer to expire and then add the ipv6 pim configuration on the IIF again, it is seen that pimreg is not getting added due to which null register wont be sent, the register flag state also remains NO_INFO forever instead of RegPrune. The reason for this is, when RST timer expires and IIF is unknown for the (S,G) upstream, the FHR state is not reset due to which when the RP becomes reachable, upstream state changes from NotJoined to Join but the register suppress timer could not be started since we see there is no change in FHR state.
Fix:
When the Register Timer expires and the reg state is set to PIM_REG_NOINFO,reset the FHR flag, so that when the RP becomes reachable can be because of config change or RP not reachable, it is able to resume its duty.
Closes #12396