[BUG] SR Linux not setting next-hop-self on BGP RR

[ipspace]

It looks like a SR Linux device running as a BGP route reflector does not do "next-hop-self".

Validation log @ https://netlab-cicd.pages.dev/srlinux/clab/bgp/03-ibgp-rr.yml-validate.log (the validation plugin threw an error, but based on the JSON dump, it's evident the next hop is not the loopback address of the route reflector)

Topology @ https://github.com/ipspace/netlab/blob/dev/tests/integration/bgp/03-ibgp-rr.yml

I solved a similar issue with a route map on Arista EOS. If that's not an option, we could add a device quirk to prevent this scenario.

[jbemmel]

Third party next hop support was recently added if I recall, that might fix it

[ipspace]

(Edited your comment to remove the quoted email -- GitHub is doing a poor job these days)

I checked the SR Linux configuration for 02-ibgp-ebgp-session and 03-ibgp-rr. In the IBGP/EBGP case, you set "next-hop-self" to True, in the 03-ibgp-rr one you do not, which results in validation failure.

It could be that setting 'next-hop-self' affects reflected routes (like on Arista EOS), in which case you'd have to use a route map on IBGP updates, and I'm positive SR Linux had the ability to set BGP next hop to 'self' in a route map for a while (that's not a third-party next hop).

[ipspace]

FWIW, the weird error in the validation log was caused by FRR validation plugin crashing when trying to report that the next hop is wrong. Fixed in 63047f0