Invalid NEXT_HOP attribute for OSPF known route

[Nico Schottelius]

Ondrej Zajicek <santiago at crfreenet.org> writes:
>> > I expect it is in multihop /
>> > gateway-recursive mode, as it is default for IBGP?
>>
>> It's in direct mode for all links, as the APU-ROUTERS have physical links
>> inside the kubernetes cluster as well as physical connection to the ROUTER.
>
> This is likely the issue. In BIRD, relations between default values
> are:

Removing the direct statement from the iBGP sessions indeed fixes the
problem. So technically speaking, what is the disadvantage/drawback
of avoiding the "direct" statement everywhere? We have so far added it
whenever the connection was in the same network segment (hence: direct),
but if it is enabled for eBGP by default (makes sense) and it does not
"help" in the iBGP case, should we ever use it?

> EBGP/IBGP -> direct / multihop -> gateway direct/recursive.
>
> So, by changing link mode to direct, you implicitly changed gateway mode
> from recursive to direct.
>
> In gateway direct mode, the next hop is not resolved through routing table,
> just through interface ranges. And if not found, it is rejected with
> 'Invalid next hop', so having OSPF route is irrelevant. But because link
> is IBGP, the original (indirect) next hop is there.

I understand the code path logic, but I don't understand the
"configuration logic". Or as said above: does it ever make sense to
apply direct explicitly?

>> I actually just realised that the "k8s_p5_1_v6" protocol did not have
>> the direct statement, however adding it does not change the situation
>> (probably because bird detects it as a direct link anyway).
>
> That is EBGP, which is direct by default (and that is OK). The issue is direct on IBGP.

Thanks for clarfication!

Best regards,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch