Force gateway recursive lookup in iBGP routes

[Ondrej Zajicek]

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 at 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."