Description
We do have a race when we create a NH ID while FRR has also "reserved" it internally.
In zebra logs, this is expressed by a debug message such as:
2025/08/12 08:24:49 ZEBRA: [RG2NH-FTSDH][EC 4043309102] Kernel updated a nexthop group with ID (3[if 256 vrfid 0]) that we are still using for a route, sending it back down
In that case, FRR rewrites the NH with its own, creating an inconsistency in grout.
FRR Issue is tracked here: FRRouting/frr#19119
To reproduce this, add automatically an IP6 link local to the loopback interface:
|
if (iface->type == GR_IFACE_TYPE_LOOPBACK) |
|
break; |
Version
grout v0.11.0-46-g86c69f20-dirty (DPDK 24.11.1)
Description
We do have a race when we create a NH ID while FRR has also "reserved" it internally.
In zebra logs, this is expressed by a debug message such as:
2025/08/12 08:24:49 ZEBRA: [RG2NH-FTSDH][EC 4043309102] Kernel updated a nexthop group with ID (3[if 256 vrfid 0]) that we are still using for a route, sending it back downIn that case, FRR rewrites the NH with its own, creating an inconsistency in grout.
FRR Issue is tracked here: FRRouting/frr#19119
To reproduce this, add automatically an IP6 link local to the loopback interface:
grout/modules/ip6/control/address.c
Lines 326 to 327 in a1d5dc9
Version
grout v0.11.0-46-g86c69f20-dirty (DPDK 24.11.1)