]> git.puffer.fish Git - matthieu/frr.git/commit
bgpd: Refine multiaccess check for next hop resetting
authorvivek <vivek@cumulusnetworks.com>
Wed, 18 Mar 2020 02:59:52 +0000 (19:59 -0700)
committervivek <vivek@cumulusnetworks.com>
Wed, 18 Mar 2020 02:59:52 +0000 (19:59 -0700)
commita3b725399030b9041fe2ae7d3597f43e7fb98481
tree528c3b79278ad51ca3bc80080f7a81776f232135
parent09c04bc49098f513ceaba6323f5c2921212b8e03
bgpd: Refine multiaccess check for next hop resetting

A BGP update-group is dynamically created to group together a set of peers
such that any BGP updates can be formed just once for the entire group and
only the next hop attribute may need to be modified when the update is sent
out to each peer in the group. The update formation code attempts to
determine as much as possible if the next hop will be set to our own IP
address for every peer in the group. This helps to avoid additional checks
at the point of sending the update (which happens on a per-peer basis) and
also because some other attributes may/could vary depending on whether the
next hop is set to our own IP or not. Resetting the next hop to our own IP
address is the most common behavior for EBGP peerings in the absence of
other user-configured or internal (e.g., for l2vpn/evpn) settings and
peerings on a shared subnet.

The code had a flaw in the multiaccess check to see if there are peers in
the update group which are on a shared subnet as the next hop of the path
being announced - the source peer could itself be in the same update group
and cause the check to give an incorrect result. Modify the check to skip
the source peer so that the check is more accurate.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
bgpd/bgp_nexthop.c
bgpd/bgp_nexthop.h
bgpd/bgp_route.c