-
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
bgpd: Add nexthop of received EVPN RT-5 for nexthop tracking #5334
Conversation
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
Continuous Integration Result: FAILEDSee below for issues. This is a comment from an automated CI system. Get source / Pull Request: SuccessfulBuilding Stage: SuccessfulBasic Tests: FailedTopology tests on Ubuntu 18.04 amd64: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-TOPOU1804-9695/test Topology Tests failed for Topology tests on Ubuntu 18.04 amd64:
see full log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-9695/artifact/TOPOU1804/ErrorLog/log_topotests.txt Successful on other platforms
Topology Tests memory analysis: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-9695/artifact/TOPOU1804/MemoryLeaks/CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base1 Static Analyzer issues remaining.See details at |
ci:rerun |
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-9707/ This is a comment from an automated CI system. CLANG Static Analyzer Summary
No Changes in Static Analysis warnings compared to base1 Static Analyzer issues remaining.See details at |
d9266a4
to
b315b89
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-9717/ This is a comment from an automated CI system. CLANG Static Analyzer Summary
1 Static Analyzer issues remaining.See details at |
💚 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-9718/ This is a comment from an automated CI system. CLANG Static Analyzer Summary
1 Static Analyzer issues remaining.See details at |
Problem statement: When IPv4/IPv6 prefixes are received in BGP, bgp_update function registers the nexthop of the route with nexthop tracking module. The BGP route is marked as valid only if the nexthop is resolved. Even for EVPN RT-5, route should be marked as valid only if the the nexthop is resolvable. Code changes: 1. Add nexthop of EVPN RT-5 for nexthop tracking. Route will be marked as valid only if the nexthop is resolved. 2. Only the valid EVPN routes are imported to the vrf. 3. When nht update is received in BGP, make sure that the EVPN routes are imported/unimported based on the route becomes valid/invalid. Testcases: 1. At rtr-1, advertise EVPN RT-5 with a nexthop 10.100.0.2. 10.100.0.2 is resolved at rtr-2 in default vrf. At rtr-2, remote EVPN RT-5 should be marked as valid and should be imported into vrfs. 2. Make the nexthop 10.100.0.2 unreachable at rtr-2 Remote EVPN RT-5 should be marked as invalid and should be unimported from the vrfs. As this code change deals with EVPN type-5 routes only, other EVPN routes should be valid. 3. At rtr-2, add a static route to make nexthop 10.100.0.2 reachable. EVPN RT-5 should again become valid and should be imported into the vrfs. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
b315b89
to
7c31238
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-9730/ This is a comment from an automated CI system. CLANG Static Analyzer Summary
1 Static Analyzer issues remaining.See details at |
#define BGP_ATTR_NH_AFI(afi, attr) \ | ||
((afi != AFI_L2VPN) ? afi : \ | ||
((attr->mp_nexthop_len == BGP_ATTR_NHLEN_IPV4) ? AFI_IP : AFI_IP6)) | ||
|
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.
We should try to do subsequent changes to base the nh_afi just on the nexthop length, but for now, this seems fine.
* | ||
* Ideally, a BGP route should be marked as valid only if the | ||
* nexthop is reachable. Thus, other EVPN route types also should be | ||
* added here after testing is performed for them. |
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.
Quite correct for most and probably all EVPN routes, we should certainly enable for RT-2 and RT-3 after testing. That can be in a subsequent commit.
This changeset follows the PR FRRouting#5334 Above PR adds nexthop tracking support for EVPN RT-5 nexthops. This route is marked VALID only if the BGP route has a valid nexthop. If the EVPN peer is an EBGP pee and "disable_connected_check" flag is not set, "connected" check is performed for the EVPN nexthop. But, usually EVPN nexthop is not the BGP peering address, but the VTEP address. Also, NEXTHOP_UNCHANGED flag is enabled by default for EVPN. As a result, in a common deployment for EVPN, EVPN nexthop is not connected. Thus, adding a fix to remove the "connected" check for EVPN nexthops. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
This changeset follows the PR FRRouting#5334 Above PR adds nexthop tracking support for EVPN RT-5 nexthops. This route is marked VALID only if the BGP route has a valid nexthop. If the EVPN peer is an EBGP pee and "disable_connected_check" flag is not set, "connected" check is performed for the EVPN nexthop. But, usually EVPN nexthop is not the BGP peering address, but the VTEP address. Also, NEXTHOP_UNCHANGED flag is enabled by default for EVPN. As a result, in a common deployment for EVPN, EVPN nexthop is not connected. Thus, adding a fix to remove the "connected" check for EVPN nexthops. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
This changeset follows the PR FRRouting#5334 Above PR adds nexthop tracking support for EVPN RT-5 nexthops. This route is marked VALID only if the BGP route has a valid nexthop. If the EVPN peer is an EBGP pee and "disable_connected_check" flag is not set, "connected" check is performed for the EVPN nexthop. But, usually EVPN nexthop is not the BGP peering address, but the VTEP address. Also, NEXTHOP_UNCHANGED flag is enabled by default for EVPN. As a result, in a common deployment for EVPN, EVPN nexthop is not connected. Thus, adding a fix to remove the "connected" check for EVPN nexthops. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
This changeset follows the PR FRRouting#5334 Above PR adds nexthop tracking support for EVPN RT-5 nexthops. This route is marked VALID only if the BGP route has a valid nexthop. If the EVPN peer is an EBGP pee and "disable_connected_check" flag is not set, "connected" check is performed for the EVPN nexthop. But, usually EVPN nexthop is not the BGP peering address, but the VTEP address. Also, NEXTHOP_UNCHANGED flag is enabled by default for EVPN. As a result, in a common deployment for EVPN, EVPN nexthop is not connected. Thus, adding a fix to remove the "connected" check for EVPN nexthops. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
This changeset follows the PR FRRouting#5334 Above PR adds nexthop tracking support for EVPN RT-5 nexthops. This route is marked VALID only if the BGP route has a valid nexthop. If the EVPN peer is an EBGP pee and "disable_connected_check" flag is not set, "connected" check is performed for the EVPN nexthop. But, usually EVPN nexthop is not the BGP peering address, but the VTEP address. Also, NEXTHOP_UNCHANGED flag is enabled by default for EVPN. As a result, in a common deployment for EVPN, EVPN nexthop is not connected. Thus, adding a fix to remove the "connected" check for EVPN nexthops. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
This changeset follows the PR FRRouting#5334 Above PR adds nexthop tracking support for EVPN RT-5 nexthops. This route is marked VALID only if the BGP route has a valid nexthop. If the EVPN peer is an EBGP pee and "disable_connected_check" flag is not set, "connected" check is performed for the EVPN nexthop. But, usually EVPN nexthop is not the BGP peering address, but the VTEP address. Also, NEXTHOP_UNCHANGED flag is enabled by default for EVPN. As a result, in a common deployment for EVPN, EVPN nexthop is not connected. Thus, adding a fix to remove the "connected" check for EVPN nexthops. Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
This changeset follows the PR FRRouting/frr#5334 Above PR adds nexthop tracking support for EVPN RT-5 nexthops. This route is marked VALID only if the BGP route has a valid nexthop. If the EVPN peer is an EBGP pee and "disable_connected_check" flag is not set, "connected" check is performed for the EVPN nexthop. But, usually EVPN nexthop is not the BGP peering address, but the VTEP address. Also, NEXTHOP_UNCHANGED flag is enabled by default for EVPN. As a result, in a common deployment for EVPN, EVPN nexthop is not connected. Thus, adding a fix to remove the "connected" check for EVPN nexthops. Signed-off-by: Ameya Dharkar <adharkar@vmware.com> Signed-off-by: harios <hari@niralnetworks.com>
This changeset follows the PR FRRouting#5334 Above PR adds nexthop tracking support for EVPN RT-5 nexthops. This route is marked VALID only if the BGP route has a valid nexthop. If the EVPN peer is an EBGP pee and "disable_connected_check" flag is not set, "connected" check is performed for the EVPN nexthop. But, usually EVPN nexthop is not the BGP peering address, but the VTEP address. Also, NEXTHOP_UNCHANGED flag is enabled by default for EVPN. As a result, in a common deployment for EVPN, EVPN nexthop is not connected. Thus, adding a fix to remove the "connected" check for EVPN nexthops. Signed-off-by: Ameya Dharkar <adharkar@vmware.com> (cherry picked from commit 41a28a2)
Problem statement:
When IPv4/IPv6 prefixes are received in BGP, bgp_update function registers the
nexthop of the route with nexthop tracking module. The BGP route is marked as
valid only if the nexthop is resolved.
Even for EVPN RT-5, route should be marked as valid only if the the nexthop is
resolvable.
Code changes:
only if the nexthop is resolved.
imported/unimported based on the route becomes valid/invalid.
Testcases:
At rtr-1, advertise EVPN RT-5 with a nexthop 10.100.0.2.
10.100.0.2 is resolved at rtr-2 in default vrf.
At rtr-2, remote EVPN RT-5 should be marked as valid and should be imported into
vrfs.
Make the nexthop 10.100.0.2 unreachable at rtr-2
Remote EVPN RT-5 should be marked as invalid and should be unimported from the
vrfs. As this code change deals with EVPN type-5 routes only, other EVPN routes
should be valid.
At rtr-2, add a static route to make nexthop 10.100.0.2 reachable.
EVPN RT-5 should again become valid and should be imported into the vrfs.
Signed-off-by: Ameya Dharkar adharkar@vmware.com