summaryrefslogtreecommitdiff
path: root/lib/workqueue.c
diff options
context:
space:
mode:
authorPhilippe Guibert <philippe.guibert@6wind.com>2023-06-01 09:48:58 +0200
committerPhilippe Guibert <philippe.guibert@6wind.com>2023-06-16 10:55:17 +0200
commit7817cdeadc3ba539b24fc39d7ec31f10c9edce8d (patch)
tree96b3d920213b22188ee6419e40d56a0cc4230b44 /lib/workqueue.c
parentb9c7e7a1a9ab22e83571652ff092bb519a7386f7 (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 'lib/workqueue.c')
0 files changed, 0 insertions, 0 deletions