diff options
| author | Philippe Guibert <philippe.guibert@6wind.com> | 2023-06-01 09:48:58 +0200 |
|---|---|---|
| committer | Philippe Guibert <philippe.guibert@6wind.com> | 2023-06-16 10:55:17 +0200 |
| commit | 7817cdeadc3ba539b24fc39d7ec31f10c9edce8d (patch) | |
| tree | 96b3d920213b22188ee6419e40d56a0cc4230b44 /tests/lib/test_xref.py | |
| parent | b9c7e7a1a9ab22e83571652ff092bb519a7386f7 (diff) | |
bgpd: fix accept-own routes received by a route reflector
When using the bgp-accept-own community, with the
'attribute-unchanged next-hop' command, the advertised
mpls vpn updates that are reflected by a route reflector
are received, but are not selected.
Once the accept-own community is detected, a new bgp_path
is created, in addition of the original one; then the
next-hop of the NLRI is checked, but fails for two reasons:
- the next-hop tracking returns the real IP reachability
status for prefixes that have the BGP_ROUTE_IMPORTED subtype.
This is what happens with bgp updates with the accept-own
community.
- as the next-hop was unchanged and was the peer IP in the VRF.
Consequently, the new bgp_path is considered inactive in the
default VRF, and is not selected.
The incoming bgp updates with the accept-own community should
not be checked against the next-hop tracking. As the bgp_path
subtype has been changed to BGP_ROUTE_IMPORTED, let us check
the bgp subtype before calling the 'bgp_find_or_add_nexthop()'
function in the 'bgp_update()' call.
Fixes: 46dbf9d0c0b9 bgpd: ("Implement ACCEPT_OWN extended community")
Fixes: 376797711f4d - bgpd: track mpls vpn nexthops
Fixes: e6110f755718 bgpd: ("fix use nexthop tracking for exported vpn paths")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Diffstat (limited to 'tests/lib/test_xref.py')
0 files changed, 0 insertions, 0 deletions
