BGP, "Invalid NEXT_HOP attribute"

[Ondrej Zajicek]

On Sat, Mar 15, 2025 at 01:37:55PM +0000, Lexi Winter wrote:
> Ondrej Zajicek:
> > On Sat, Mar 15, 2025 at 11:07:04AM +0000, Lexi Winter via Bird-users wrote:
> > > Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid NEXT_HOP attribute - neighbor address fd5b:a83:b06b:500::1
> > > Mar 15 11:03:22 uk-myb-2 bird[60388]: nl-myb-1: Invalid route 172.20.212.0/26 withdrawn
> 
> > The message is generated during route export and means that the NEXT_HOP
> > attribute for the route that would be announced to the neighbor is the
> > same as the IP address of that neighbor. This is not valid, so BIRD sends
> > a route withdraw instead of an update.
> 
> neighbor fd5b:a83:b06b:500::1/nl-myb-1 is an EBGP confederation peer, so
> the only way we could have a route with next hop of fd5b:a83:b06b:500::1
> is because uk-myb-2 received this route from nl-myb-1, or from its IBGP
> RR cluster peer that also peers with nl-myb-1.
> 
> but in that case, nl-myb-1 ASN should be in confederation AS set of the
> route, so we should not try to advertise it back to nl-myb-1, i think?

BGP itself does not do loop prevention on export, only on import. So it
would still try to announce it back. For regular EBGP, this is usually
prevented by the fact that route received directly from EBGP is preferred
than one received through IBGP. In confederation, perhaps the metrics
should handle that.

Note that confederations in BIRD are a bit tricky. There are two styles:

1) Shared IGP:
In this case, intra-confederation EBGP links should have an option
'gateway recursive', so bgp_next_hop is resolved recursively through
shared IGP routes.

2) Per-member IGP:
In this case, intra-confederation EBGP links should have an option
'next hop self', so bgp_next_hop is reset on here. Also it makes sense
to enable AIGP, so total per-confederation metrics are taken into account.


> PS: i sent you a mail (not to the list) about my BFD-related core dump,
> i didn't hear back from you so i'm not sure if you received it.

I received that, sorry for not replying earlier. Will check that.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
"To err is human -- to blame it on a computer is even more so."