BGP, "Invalid NEXT_HOP attribute"
hello, recently i noticed some entries in syslog like this: 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 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 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 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 i am not sure how to understand this log message. i still have the route (including via nl-myb-1): root@uk-myb-2:~ # birdc show route 172.20.212.0/26 BIRD 2.16.1 ready. Table master4: 172.20.212.0/26 unicast [uk-jmp-2 11:03:22.032 from fd5b:a83:b06b:400::1] * (100/61) [AS4242422622i] via fe80::e0e3:b1bf:8d1d:abcd on wg.nl-myb-1 unicast [nl-myb-1 11:03:20.704 from fd5b:a83:b06b:500::1] (100/61) [AS4242422622i] via fe80::e0e3:b1bf:8d1d:abcd on wg.nl-myb-1 unicast [ny-czy-1 11:03:20.589 from fd5b:a83:b06b:200::1] (100/694) [AS4242422622i] via fe80::bc1b:dbed:690a:6840 on wg.uk-jmp-2 unicast [mia-czy-1 11:03:20.680 from fd5b:a83:b06b:900::1] (100/694) [AS4242422622i] via fe80::bc1b:dbed:690a:6840 on wg.uk-jmp-2 and it's in the FIB as well: root@uk-myb-2:~ # route -n get -inet 172.20.212.0/26 route to: 172.20.212.0 destination: 172.20.212.0 mask: 255.255.255.192 gateway: fe80::e0e3:b1bf:8d1d:abcd%wg.nl-myb-1 fib: 0 interface: wg.nl-myb-1 flags: <UP,GATEWAY,DONE> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1420 1 0 so everything seems fine. what is BIRD trying to indicate with this log message?
On Sat, Mar 15, 2025 at 11:07:04AM +0000, Lexi Winter via Bird-users wrote:
hello,
recently i noticed some entries in syslog like this:
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 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 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 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
i am not sure how to understand this log message.
what is BIRD trying to indicate with this log message?
Hello 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. Because it is an error during route export, the local situation is fine, but the route is not announced to the neighbor.
i still have the route (including via nl-myb-1):
root@uk-myb-2:~ # birdc show route 172.20.212.0/26 BIRD 2.16.1 ready. Table master4: 172.20.212.0/26 unicast [uk-jmp-2 11:03:22.032 from fd5b:a83:b06b:400::1] * (100/61) [AS4242422622i] via fe80::e0e3:b1bf:8d1d:abcd on wg.nl-myb-1 unicast [nl-myb-1 11:03:20.704 from fd5b:a83:b06b:500::1] (100/61) [AS4242422622i] via fe80::e0e3:b1bf:8d1d:abcd on wg.nl-myb-1 unicast [ny-czy-1 11:03:20.589 from fd5b:a83:b06b:200::1] (100/694) [AS4242422622i] via fe80::bc1b:dbed:690a:6840 on wg.uk-jmp-2 unicast [mia-czy-1 11:03:20.680 from fd5b:a83:b06b:900::1] (100/694) [AS4242422622i] via fe80::bc1b:dbed:690a:6840 on wg.uk-jmp-2
and it's in the FIB as well:
root@uk-myb-2:~ # route -n get -inet 172.20.212.0/26 route to: 172.20.212.0 destination: 172.20.212.0 mask: 255.255.255.192 gateway: fe80::e0e3:b1bf:8d1d:abcd%wg.nl-myb-1 fib: 0 interface: wg.nl-myb-1 flags: <UP,GATEWAY,DONE> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1420 1 0
so everything seems fine.
-- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
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.
thanks Ondrej. i thought these messages referred to incoming updates, but this makes more sense. however, i am unsure why BIRD would be trying to send such updates to a neighbor. 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? does this indicate something wrong with my configuration, or am i misunderstanding something here? 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.
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@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek:
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.
i see, i thought EBGP with a confederation peer would use recursive next hop resolution by default (since NEXT_HOP is propagated unchanged in this case, like in IBGP), but if not, this could be related. i will configure 'gateway recursive' explicitly on my peerings and see if this makes any difference. (i don't use 'next hop self' since my IGP covers the entire network.)
I received that, sorry for not replying earlier. Will check that.
no rush at all, i was only wondering because i know sometimes mail delivery from non-Google/Microsoft addresses can be an issue these days.
On Sat, Mar 15, 2025 at 03:08:35PM +0000, Lexi Winter wrote:
Ondrej Zajicek:
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.
i see, i thought EBGP with a confederation peer would use recursive next hop resolution by default (since NEXT_HOP is propagated unchanged in this case, like in IBGP), but if not, this could be related. i will configure 'gateway recursive' explicitly on my peerings and see if this makes any difference.
Yeah, it would make more sense. This is BIRD-specific deviation, as standard BGP behavior is equivalent to 'gateway recursive' always. Historically, we do 'gateway direct' for single-hop, 'gateway recursive' for multihop (by default), even that for BGP confederations it does not make much sense. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Lexi Winter -
Ondrej Zajicek