-
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: Do not perform "connected" check for EVPN nexthop #5419
Conversation
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>
💚 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-9837/test Topology Tests failed for Topology tests on Ubuntu 18.04 amd64:
see full log at https://ci1.netdef.org/browse/FRR-FRRPULLREQ-9837/artifact/TOPOU1804/ErrorLog/log_topotests.txt Successful on other platforms
Topology Tests memory analysis: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-9837/artifact/TOPOU1804/MemoryLeaks/ <TITLE>clang_check</TITLE>clang_check |
@@ -3454,7 +3454,8 @@ int bgp_update(struct peer *peer, struct prefix *p, uint32_t addpath_id, | |||
&& (safi == SAFI_UNICAST || safi == SAFI_LABELED_UNICAST)) | |||
|| (safi == SAFI_EVPN && | |||
bgp_evpn_is_prefix_nht_supported(p))) { | |||
if (peer->sort == BGP_PEER_EBGP && peer->ttl == 1 | |||
if (safi != SAFI_EVPN | |||
&& peer->sort == BGP_PEER_EBGP && peer->ttl == 1 |
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.
can we replace 1 with BGP_DEFAULT_TTL?
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.
yes -- no magic numbers... using the #def would be better here
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 will fix this. But Just to clarify, the ttl part is not that was modified now, but already present in the code.
checked the CI logs and its not quite clear if the failure is related to changes. Giving it another try. 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-9854/ This is a comment from an automated CI system. clang_check |
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.
The changes look good to me. When I reported the problem, I'd suggested that we need to introduce a per-afi/safi disable_nexthop_connected_check flag (and config) to handle this in a comprehensive way. This can of course be in a subsequent commit.
[By way of explanation, whenever the sender of the prefix is setup to pass along the next hop unchanged (whether by explicit config or due to defaults), the receiver must be setup (by config or via defaults) to skip the "next hop must be connected" check for EBGP peerings. This can be achieved be configuring the peering itself for multihop or via configs to disable the connected check, which need to be at the afi/safi granularity to match the sender's next hop settings.]
This changeset follows the PR
#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