IGP(OSPF) learned route not used for iBGP?

[Nico Schottelius]

Hey Ondrej,

you are, as always, correct. The iBGP configuration was:

protocol bgp server138_v6_v4 {
    local as 199553;
    direct;
    neighbor 2a0a:e5c0:0:b::8a as 199553;
    bfd on;

    ipv6 {
      import all;
      export filter all_but_no_igp;
    };

    ipv4 {
      import all;
      export filter all_but_no_igp;
      extended next hop on;
    };
}

Changing it to:

protocol bgp server138_v6_v4 {
    local as 199553;
    direct;
    neighbor 2a0a:e5c0:0:b::8a as 199553;
    bfd on;

    ipv6 {
      import all;
      export filter all_but_no_igp;
      gateway recursive;
    };

    ipv4 {
      import all;
      export filter all_but_no_igp;
      extended next hop on;
      gateway recursive;
    };
}

makes it work.

Thanks a lot for the pointer.

Best regards,

Nico

Ondrej Zajicek <santiago at crfreenet.org> writes:

> On Fri, May 12, 2023 at 05:15:43PM +0200, Nico Schottelius via Bird-users wrote:
>>
>> Hello fellow bird users,
>>
>> a quick IGP/iBGP question:
>>
>> Why does apu-router1 that should learn the IPv6 default route from
>> server138 complain about not accepting the route?
>>
>> May 12 17:13:18 apu-router1 daemon.err bird: server138_v6_v4: Invalid NEXT_HOP attribute - address 2a0a:e5c0:32:2::21 not directly reachable
>> May 12 17:13:18 apu-router1 daemon.err bird: server138_v6_v4: Invalid route ::/0 withdrawn
>>
>> Checking that apu-router1 has the route:
>>
>> bird> show route 2a0a:e5c0:32:2::20/124
>> Table master6:
>> 2a0a:e5c0:32:2::20/124 unicast [ospf6 17:14:01.612] * E2 (150/10/10000) [0.0.0.138]
>>         via fe80::3eec:efff:fed2:d0c2 on eth1.2 weight 1
>>         via fe80::3eec:efff:fed2:d0c4 on eth2 weight 1
>>                      unicast [server137_v6_v4 17:13:19.524] (100) [i]
>>         via 2a0a:e5c0:0:b::89 on eth2
>>                      unicast [server138_v6_v4 17:13:18.394] (100) [i]
>>         via 2a0a:e5c0:0:b::8a on eth2
>> bird>
>>
>> The complete setup is as follows:
>>
>>     apu-router1 -- server138 -- [wireguard] -- server120
>>
>> - apu-router1 and server138 are ASN 199553 [iBGP)
>> - server120 is 209898 [eBGP]
>
> Hello
>
> Considering that route for 2a0a:e5c0:32:2::20/124 is at apu-router1, my
> guess is that your IBGP link is configured as 'direct', which implies
> 'gateway direct' processing of bgp_next_hop attribute, expecting it to
> be directly reachable on apu-router1, not indirectly through OSPF route
> (like with regular IBGP).
>
> Either set 'gateway recursive' option in IBGP channels on apu-router1, or
> set 'next hop self' in IBGP channels on server138.
>
> What is your IBGP config on apu-router1?


--
Sustainable and modern Infrastructures by ungleich.ch