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
lib: skip route-map optimization if !AF_INET(6) #14094
lib: skip route-map optimization if !AF_INET(6) #14094
Conversation
Currently we unconditionally send a prefix through the optimized route-map codepath if the v4 and v6 LPM tables have been allocated and optimization has not been disabled. However prefixes from address-families that are not IPv4/IPv6 unicast always fail the optimized route-map index lookup, because they occur on an LPM tree that is IPv4 or IPv6 specific. e.g. Even if you have an empty permit route-map clause, Type-3 EVPN routes are always denied: ``` --config route-map soo-foo permit 10 --logs 2023/02/17 19:38:42 BGP: [KZK58-6T4Y6] No best match sequence for pfx: [3]:[0]:[32]:[2.2.2.2] in route-map: soo-foo, result: no match 2023/02/17 19:38:42 BGP: [H5AW4-JFYQC] Route-map: soo-foo, prefix: [3]:[0]:[32]:[2.2.2.2], result: deny ``` There is some existing code that creates an AF_INET/AF_INET6 prefix using the IP/prefix information from a Type-2/5 EVPN route, which allowed only these two route-types to successfully attempt an LPM lookup in the route-map optimization trees via the converted prefix. This commit does 3 things: 1) Reverts to non-optimized route-map lookup for prefixes that are not AF_INET or AF_INET6. 2) Cleans up the route-map code so that the AF check is part of the index lookup + the EVPN RT-2/5 -> AF_INET/6 prefix conversion occurs outside the index lookup. 3) Adds "debug route-map detail" logs to indicate when we attempt to convert an AF_EVPN prefix into an AF_INET/6 prefix + when we fallback to a non-optimized lookup. Additional functionality for optimized lookups of prefixes from other address-families can be added prior to the index lookup, similar to how the existing EVPN conversion works today. New behavior: ``` 2023/02/17 21:44:27 BGP: [WYP1M-NE4SY] Converted EVPN prefix [5]:[0]:[32]:[192.0.2.7] into 192.0.2.7/32 for optimized route-map lookup 2023/02/17 21:44:27 BGP: [MT1SJ-WEJQ1] Best match route-map: soo-foo, sequence: 10 for pfx: 192.0.2.7/32, result: match 2023/02/17 21:44:27 BGP: [H5AW4-JFYQC] Route-map: soo-foo, prefix: 192.0.2.7/32, result: permit 2023/02/17 21:44:27 BGP: [WYP1M-NE4SY] Converted EVPN prefix [2]:[0]:[48]:[aa:bb:cc:00:22:22]:[32]:[20.0.0.2] into 20.0.0.2/32 for optimized route-map lookup 2023/02/17 21:44:27 BGP: [MT1SJ-WEJQ1] Best match route-map: soo-foo, sequence: 10 for pfx: 20.0.0.2/32, result: match 2023/02/17 21:44:27 BGP: [H5AW4-JFYQC] Route-map: soo-foo, prefix: 20.0.0.2/32, result: permit 2023/02/17 21:44:27 BGP: [KHG7H-RH4PN] Unable to convert EVPN prefix [3]:[0]:[32]:[2.2.2.2] into IPv4/IPv6 prefix. Falling back to non-optimized route-map lookup 2023/02/17 21:44:27 BGP: [MT1SJ-WEJQ1] Best match route-map: soo-foo, sequence: 10 for pfx: [3]:[0]:[32]:[2.2.2.2], result: match 2023/02/17 21:44:27 BGP: [H5AW4-JFYQC] Route-map: soo-foo, prefix: [3]:[0]:[32]:[2.2.2.2], result: permit ``` Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Fixes up evpn_prefix2prefix() to use IPV(4|6)_MAX_BITLEN instead of 32/128 directly. Signed-off-by: Trey Aspelund <taspelund@nvidia.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 debian 10 amd64 part 9: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-PULLREQ2-TOPO9DEB10AMD64-13121/test Topology Tests failed for Topotests debian 10 amd64 part 9 Successful on other platforms/tests
|
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-13121/ This is a comment from an automated CI system. |
Backport for 8.5.
Closes #14082