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