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
Hi, Anno domini 2023 Nico Schottelius via Bird-users scripsit: I'm not totally sure what the NH issue is as I'm not fully following topology and configuration, however OSPF on Wireguard interfaces works with bird (at least v1.6): [...]
As the wireguard interface seems to be unusable with OSPF (likely due to missing multicast support),
Missing Multicast support isn't the issue (if you have PTP tunnels), the lack of a link-local address is. I'm solving this with up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/addr_gen_mode in /etc/network/interfaces (on a Debian system), then OSPF works fine on Wireguard PTP tunnels :) Cheers, Max -- Alles sollte so einfach wie möglich gemacht sein. Aber nicht einfacher. (Einstein)
Hello! On 5/12/23 17:15, 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
Could you please disclose what "show interfaces" writes out? BIRD basically checks whether it's possible to infer the nexthop interface from its address based on the addresses assigned to interfaces. This way, setting up wireguard with OSPF can be particularly tricky. Maria
Hello Maria, Maria Matejka via Bird-users <bird-users@network.cz> writes:
Could you please disclose what "show interfaces" writes out?
Sure: [18:59] apu-router1.place5:~# birdc BIRD 2.0.12 ready. bird> show interfaces lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 127.0.0.1/8 (Preferred, scope host) 2a0a:e5c0:1e:a::b/128 (Preferred, scope univ) 2a0a:e5c0:1e:a::a/128 (scope univ) 2a0a:e5c0:0:a::b/128 (scope univ) 2a0a:e5c0:0:a::a/128 (scope univ) 2a0a:e5c0::4/128 (scope univ) 2a0a:e5c0::3/128 (scope univ) 2a0a:e5c0::1/128 (scope univ) ::1/128 (scope host) eth0 down (index=2) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 eth1 up (index=3) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 fe80::20d:b9ff:fe57:2f91/64 (Preferred, scope link) eth2 up (index=4) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 2a0a:e5c0:0:b::46/64 (Preferred, scope univ) fe80::20d:b9ff:fe57:2f92/64 (Preferred, scope link) eth1.5 up (index=5) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 2a0a:e5c0:0:6::46/64 (Preferred, scope univ) fe80::20d:b9ff:fe57:2f91/64 (Preferred, scope link) eth1.2 up (index=7) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 2a0a:e5c0::46/64 (Preferred, scope univ) fe80::20d:b9ff:fe57:2f91/64 (Preferred, scope link) eth1.7 up (index=8) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 2a0a:e5c0:0:3::46/64 (Preferred, scope univ) fe80::20d:b9ff:fe57:2f91/64 (Preferred, scope link) eth1.41 down (index=9) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 bird> and server138: bird> show interfaces lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 127.0.0.1/8 (Preferred, scope host) ::1/128 (Preferred, scope host) eth0 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 2a0a:e5c0::3eec:efff:fed2:d0c2/64 (Preferred, scope univ) fe80::3eec:efff:fed2:d0c2/64 (Preferred, scope link) eth1 down (index=3) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 eth2 up (index=4) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 2a0a:e5c0:0:b::8a/64 (Preferred, scope univ) fe80::3eec:efff:fed2:d0c4/64 (Preferred, scope link) eth3 down (index=5) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 eth4 down (index=6) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 eth5 up (index=7) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 192.168.1.210/24 (Preferred, scope site) fe80::3eec:efff:fed2:d0c7/64 (Preferred, scope link) eth6 down (index=8) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 eth7 down (index=9) MultiAccess Broadcast Multicast AdminDown LinkDown MTU=1500 k8sbr0 up (index=10) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 2a0a:e5c0:43:aa::1/64 (Preferred, scope univ) fe80::f84f:6ff:fe68:c858/64 (Preferred, scope link) vethaeaa6a09 up (index=11 master=k8sbr0) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 fe80::d4d3:54ff:fe67:a40b/64 (Preferred, scope link) veth30d9aa51 up (index=12 master=k8sbr0) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 fe80::ac8c:8fff:fe7c:4404/64 (Preferred, scope link) s138s121 up (index=28) PtP Multicast AdminUp LinkUp MTU=1420 2a0a:e5c0:32:2::22/124 (Preferred, scope univ) Does this explain it? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch
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? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
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
participants (4)
-
Maria Matejka -
Maximilian Wilhelm -
Nico Schottelius -
Ondrej Zajicek