Invalid NEXT_HOP attribute for OSPF known route
Ondrej Zajicek
santiago at crfreenet.org
Wed Dec 15 18:08:06 CET 2021
On Tue, Dec 14, 2021 at 08:35:48PM +0100, Nico Schottelius wrote:
>
> Hello,
>
> every year or then bird is putting me into the Invalid NEXT_HOP
> message.
Hello
Yes, this is kind of confusing error message (as i noted in response
to Simon Ruderich).
> TL;DR:
> Why does bird on router1+router2 refuse the route
> 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122 via
> 2a0a:e5c0::225:90ff:fe1e:3e62
>
> even though router1+router2 know how to reach 2a0a:e5c0::/64 via
> fe80::20d:b9ff:fe57:2f91 by means of ospf?
Note that in gateway-recursive mode, the fact of whether reachability is
known is not relevant for 'Invalid NEXT_HOP' message. If it is
unreachable, then the route would be accepted as 'unreachable' and
changes to reachable if reachability is changed. It is usually some
other issue like zero or local IP address.
> In detail:
>
> router1, router2 are peered to apu-router1,apu-router2 via OSPF + BGP.
>
> apu-router1,apu-router2 are peered to a set of kubernetes hosts.
>
> The goal is to have router1 + router2 import the routes sent by the
> kubernetes hosts:
>
> router1 router2---------|
> | \ | |
> | \ | |
> | \ | |
> apu-router1 apu-router2 |
> . | . |
> |--------------------------
> . .
> [ kubernetes cluster via apu-routers ]
>
>
> The problem: router1+router reject the routes with:
>
> Dec 14 20:33:51 router1 daemon.err bird: apu_router1_place5_ungleich_ch_v6: Invalid NEXT_HOP attribute
>
> The setup:
>
> router1, router2, apu-router1, apu-router2 = ASN209898
> kubernetes hosts = ASN65533
> kubernetes peers with apu-routers only.
So the BGP link between kubernetes and APU-ROUTER is EBGP, while between
APU-ROUTER and ROUTER is IBGP? I expect it is in multihop /
gateway-recursive mode, as it is default for IBGP?
> The routes:
> Kubernetes announces parts of 2a0a:e5c0:0:12::/64 and
> 2a0a:e5c0:0:13::/64, for instance the route
> 2a0a:e5c0:0:12:b01a:5ae3:1bd4:1e00/122.
>
> Kubernetes nodes live in 2a0a:e5c0::/64.
>
> apu-routers have a leg in 2a0a:e5c0::/64, via eth1.2. They reach the
> cluster directly. They have the routes.
>
> routers1+2 receive the route for 2a0a:e5c0::/64 via ospf:
>
> bird> show route 2a0a:e5c0::/64
> Table master6:
> 2a0a:e5c0::/64 unicast [ospf6 17:08:18.515] * I (150/20) [0.0.0.47]
> via fe80::20d:b9ff:fe57:2f91 on bond0.8
> The apu-routers:
> - They import the route [0]
Could you show 'show route all' on apu-router for failed routes to see
their BGP_NEXT_HOP attribute? And also ideally tcpdump output to see
BGP_NEXT_HOP as sent from apu-router to router?
> - They export the route to the routers [1]
Could you also show 'show protocol all' for the session from apu-router to the kubernetes hosts?
> The routers:
> - print 4x the Invalid NEXT_HOP attribute, once per exported
> kubernetes network
> - They ignore the 4 routes [2]
>
> Question: why does bird on the routers not accept the routes? Or is
> there a different problem I am not seeing? Aside from that, shouldn't
> bird on the apu-routers set itself as nexthop for the kubernetes routes?
Not, because sending it to routerx over IBGP link, where BGP_NEXT_HOP is
kept unmodified by default (unless 'next hop self' option is used).
It might be an issue related to IPv6 dual next-hops (global and link-local),
where global is empty.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
More information about the Bird-users
mailing list