IGP(OSPF) learned route not used for iBGP?

[Nico Schottelius]

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]

As the wireguard interface seems to be unusable with OSPF (likely due to
missing multicast support), we use direct to read the route from the
interface, the snippet from server137:

protocol direct {
        ipv6;
        interface "s*";
}

And then we propagate it via OSPF:

  ipv6 {
    import all;

    # Forward the routes that we specifically picked from s* devices
    # that are not picked up by ospf
    export filter {
      if source = RTS_DEVICE then {
        accept;
      }
      reject;
    };
  };

On server138:

bird> show route ::/0
Table master6:
::/0                 unicast [server121_p15_v6_v4 15:11:34.058] * (100) [AS209898i]
	via 2a0a:e5c0:32:2::21 on s138s121
bird> show route 2a0a:e5c0:32:2::20/124
Table master6:
2a0a:e5c0:32:2::20/124 unicast [direct1 15:11:12.662] * (240)
	dev s138s121
                     unicast [server137_v6_v4 15:11:36.524] (100) [i]
	via 2a0a:e5c0:0:b::89 on eth2
                     unicast [apu_router2_v6_v4 15:13:17.009] (100) [i]
	via 2a0a:e5c0:0:b::47 on eth2
                     unicast [apu_router1_v6_v4 15:14:01.616] (100) [i]
	via 2a0a:e5c0:0:b::46 on eth2
bird>

What are we doing incorrectly so that the apu-router1 does not use
2a0a:e5c0:32:2::20/124 that it learned via OSPF?

Best regards,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch