Thank you for your reply, I just don't understand it well enought. Why is route 10.96.20.0/26 recursive, when it's next hop (10.30.21.19) is in my directly connected network (10.30.20.0/22) ? When I tried to change peers to different ASs (okubedev1m1 AS65102, okubedev1_lb1 AS65101), it's working well even if I don't see much difference in routing table. To me it looks like route for 10.96.20.0/16 doesn't change much. Even fiddling AS path in filter doesn't seem to help. 10.96.255.33/32 unicast [okubedev1_lb1 12:06:22.708 from 10.96.20.57] * (100/?) [AS65101?] via 10.30.21.19 on enp0s4 Type: BGP univ BGP.origin: Incomplete BGP.as_path: 65102 65101 BGP.next_hop: 10.96.20.57 BGP.local_pref: 100 10.96.20.0/26 unicast [okubedev1m1 12:04:17.932] * (100) [AS65102i] via 10.30.21.19 on enp0s4 Type: BGP univ BGP.origin: IGP BGP.as_path: 65102 BGP.next_hop: 10.30.21.19 BGP.local_pref: 100 10.30.20.0/22 unicast [direct1 08:32:56.003] * (240) dev enp0s4 Type: device univ Unfortunately this setup works well in single-node clusters only (okubedev1) but I got duplicated routes for multi-node clusters, which I believe I know why is happening (inner iBGP full mesh within cluster) and I don't want to use it that way. 10.96.2.128/26 unicast [okubedev2m1 12:06:04.814] * (100) [AS65102i] via 10.30.21.4 on enp0s4 Type: BGP univ BGP.origin: IGP BGP.as_path: 65102 BGP.next_hop: 10.30.21.4 BGP.local_pref: 100 unicast [okubedev2n1 12:06:09.604] (100) [AS65102i] via 10.30.21.5 on enp0s4 Type: BGP univ BGP.origin: IGP BGP.as_path: 65102 BGP.next_hop: 10.30.21.5 BGP.local_pref: 100 Thanks for your time. Best regards On 2/28/20 4:51 PM, Ondrej Zajicek wrote:
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
-- Miroslav Kalina Systems developement specialist miroslav.kalina@livesport.eu +420 773 071 848 Livesport s.r.o. Aspira Business Centre Bucharova 2928/14a, 158 00 Praha 5 www.livesport.eu