Force gateway recursive lookup in iBGP routes

[Miroslav Kalina]

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 at livesport.eu
+420 773 071 848

Livesport s.r.o.
Aspira Business Centre
Bucharova 2928/14a, 158 00 Praha 5
www.livesport.eu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20200302/8bfd4eea/attachment.htm>