summaryrefslogtreecommitdiff
path: root/tests/topotests/example-test/test_example.py
diff options
context:
space:
mode:
authorvivek <vivek@cumulusnetworks.com>2020-03-17 19:59:52 -0700
committervivek <vivek@cumulusnetworks.com>2020-03-17 19:59:52 -0700
commita3b725399030b9041fe2ae7d3597f43e7fb98481 (patch)
tree528c3b79278ad51ca3bc80080f7a81776f232135 /tests/topotests/example-test/test_example.py
parent09c04bc49098f513ceaba6323f5c2921212b8e03 (diff)
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>
Diffstat (limited to 'tests/topotests/example-test/test_example.py')
0 files changed, 0 insertions, 0 deletions