pimd: fix recursive lookup for RP #7855
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Topology: Client---R1(1.1.1.1)---4link---R2(2.2.2.2)---cisco(3.3.3.3) 3.3.3.3 is RP. R1(1.1.1.1) is bgp neighbor with R2(2.2.2.2) and configure static route 2.2.2.2 via 4 links in order to establish the bgp neighborship. R1 :B> 3.3.3.0/24 [20/0] via 2.2.2.2 (recursive), 00:13:34 * via 20.0.0.2, ens192, 00:13:34 * via 30.0.0.2, ens224, 00:13:34 * via 40.0.0.2, ens256, 00:13:34 * via 50.0.0.2, ens161, 00:13:34 Issue: R1 > rp info incoming interface is ens224 and (*, G ) mroute pointing to ens192 This is not expected. Root Cause: In R1, RP(3.3.3.3) is a recursive route. zclient_lookup_nexthop() lookup for 3.3.3.3 which will give the nexthop as 2.2.2.2 which is a recursive route. So it will lookup for 2.2.2.2 and will get 4 non-recursive nexthops 20.0.0.2, 30.0.0.2, 40.0.0.2 and 50.0.0.2. Since it is a recursive lookup, 20.0.0.2 is replaced by 2.2.2.2. The final nexthop we will get as 2.2.2.2, 30.0.0.2, 40.0.0.2 and 50.0.0.2. Since 2.2.2.2(1st nexthop) we dont have any pim neighbor, 30.0.0.2(2nd nexthop) will be choosen as nexthop for route 3.3.3.3 and rp iif updated as ens224. Where as pim nexthop cache will have the 3.3.3.3 nexthops as 20.0.0.2, 30.0.0.2, 40.0.0.2, 50.0.0.2. That's why (*,G) mroute iif will be set as ens192(first nexthop). Fix: zclient_lookup_nexthop() dont replace the first nexthop with the recursive route. Signed-off-by: Sarita Patra <saritap@vmware.com>
donaldsharp
requested changes
Jan 12, 2021
| @@ -464,14 +455,6 @@ int zclient_lookup_nexthop(struct pim_instance *pim, | |||
| .protocol_distance, | |||
| nexthop_tab[0].route_metric); | |||
| } | |||
|
|
|||
There was a problem hiding this comment.
Shouldn't we delete everything from 441-457 ? This is now dead code and we don't need the debug anymore.
Continuous Integration Result: FAILEDSee below for issues. This is a comment from an automated CI system. Get source / Pull Request: SuccessfulBuilding Stage: SuccessfulBasic Tests: FailedTopo tests part 2 on Ubuntu 16.04 amd64: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-TP0U1604AMD64-16468/test Topology Tests failed for Topo tests part 2 on Ubuntu 16.04 amd64: see full log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-16468/artifact/TP0U1604AMD64/ErrorLog/log_topotests.txt Topo tests part 3 on Ubuntu 18.04 arm8: Failed (click for details)Topo tests part 3 on Ubuntu 18.04 arm8: No useful log foundSuccessful on other platforms/tests
Warnings Generated during build:Debian 10 amd64 build: Successful with additional warningsDebian Package lintian failed for Debian 10 amd64 build: |
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
|
I believe b59839a fixes this issue |
|
@polychaeta autoclose in 1 week |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Topology:
Client---R1(1.1.1.1)---4link---R2(2.2.2.2)---cisco(3.3.3.3)
3.3.3.3 is RP.
R1(1.1.1.1) is bgp neighbor with R2(2.2.2.2) and configure static
route 2.2.2.2 via 4 links in order to establish the bgp neighborship.
R1 :B> 3.3.3.0/24 [20/0] via 2.2.2.2 (recursive), 00:13:34
Issue:
R1 > rp info incoming interface is ens224 and (*, G ) mroute pointing to ens192
This is not expected.
Root Cause:
In R1, RP(3.3.3.3) is a recursive route. zclient_lookup_nexthop() lookup
for 3.3.3.3 which will give the nexthop as 2.2.2.2 which is a recursive route.
So it will lookup for 2.2.2.2 and will get 4 non-recursive nexthops 20.0.0.2,
30.0.0.2, 40.0.0.2 and 50.0.0.2. Since it is a recursive lookup, 20.0.0.2 is
replaced by 2.2.2.2. The final nexthop we will get as 2.2.2.2, 30.0.0.2, 40.0.0.2
and 50.0.0.2. Since 2.2.2.2(1st nexthop) we dont have any pim neighbor,
30.0.0.2(2nd nexthop) will be choosen as nexthop for route 3.3.3.3 and rp iif
updated as ens224.
Where as pim nexthop cache will have the 3.3.3.3 nexthops as 20.0.0.2, 30.0.0.2,
40.0.0.2, 50.0.0.2. That's why (*,G) mroute iif will be set as ens192(first nexthop).
Fix: zclient_lookup_nexthop() dont replace the first nexthop with the recursive route.
Signed-off-by: Sarita Patra saritap@vmware.com