Force gateway recursive lookup in iBGP routes
Ondrej Zajicek
santiago at crfreenet.org
Fri Feb 28 16:51:09 CET 2020
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."
More information about the Bird-users
mailing list