On Fri, Feb 28, 2020 at 02:01:40PM +0100, Miroslav Kalina wrote:
Hello there,
I am currently trying to use BIRD for route propagation from our baremetal Kubernetes clusters (Calico CNI, iBGP sessions within AS65100) into infrastructure via eBGP (private AS) and it works well.
The issue I have is when I want also to create BGP peering between BIRD and (MetalLB) service inside Kubernetes cluster (multihop, no NAT involved, session established OK) and I receive routes /32 with BGP.next_hop to IP within Kubernetes cluster (=not directly connected). These routes are marked as "unreachable" even if I explicitly set "gateway recursive".
Hello The issue here is that BIRD does not support resolution of recursive gateway through another route with recursive next hop. Recursive route 10.96.255.33/32 uses next hop 10.96.20.25, which is resolved through 10.96.20.0/26, which itself has a recursive next hop. Perhaps you could modify okubedev1m1 / 10.96.20.0/26 to have direct next hop.
Produces following routing table:
bird> show route all Table master4: 10.96.255.33/32 unreachable [okubedev1_lb1 10:32:14.973 from 10.96.20.25] * (100) [?] Type: BGP univ BGP.origin: Incomplete BGP.as_path: BGP.next_hop: 10.96.20.25 BGP.local_pref: 0 10.96.20.0/26 unicast [okubedev1m1 11:15:45.704] * (100) [i] via 10.30.21.19 on enp0s4 Type: BGP univ BGP.origin: IGP BGP.as_path: BGP.next_hop: 10.30.21.19 BGP.local_pref: 100 10.30.20.0/22 unicast [direct1 13:52:46.301] * (240) dev enp0s4 Type: device univ
-- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."