bgpd: fix colored nexthops resolution

When the SR-TE service is off, colored BGP routes are not
selected if it is recursively resolved over routes that are
colored only.

Actually, a BGP nexthop context includes the color attribute;
when an update from ZEBRA is received, there is no color, and
the colored BGP nexthop contexts are parsed, only if there
is a non colored BGP nexthop context. The actual setup shows
this may not be the case every time.

Fix this by parsing all the colored BGP nexthop contexts.

Fixes: b8210849b8 ("bgpd: Make bgp ready to remove distinction between 2 nh tracking types")

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit is contained in:
Philippe Guibert 2024-05-13 17:42:30 +02:00
parent b6f1b32c8a
commit 42c497dec0

View File

@ -972,12 +972,12 @@ void bgp_nexthop_update(struct vrf *vrf, struct prefix *match,
* which should provide a better infrastructure to solve this issue in
* a more efficient and elegant way.
*/
if (nhr->srte_color == 0 && bnc_nhc) {
if (nhr->srte_color == 0) {
struct bgp_nexthop_cache *bnc_iter;
frr_each (bgp_nexthop_cache, &bgp->nexthop_cache_table[afi],
bnc_iter) {
if (!prefix_same(&bnc_nhc->prefix, &bnc_iter->prefix) ||
if (!prefix_same(match, &bnc_iter->prefix) ||
bnc_iter->srte_color == 0 ||
CHECK_FLAG(bnc_iter->flags, BGP_NEXTHOP_VALID))
continue;