Re: IGP(OSPF) learned route not used for iBGP?

12 May 2023

      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@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