Ondrej Zajicek <santiago@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