OSPFv3 doesn't announce loopback IPv6 network
I want to use OSPF with BIRD v2.0.10 on Linux. That works well, except that the IPv6 network of the lo interface isn't announced on OSPFv3. The IPv6 networks of the ethernet interfaces are announced as well as the IPv4 networks of all interfaces (ethernet and lo). The only missing is the IPv6 network of lo. Here the OSPF config, really basic: protocol ospf v2 { ipv4 { import all; export all; }; area 0 { interface "eth*" { }; interface "lo" { stub; }; }; } protocol ospf v3 { ipv6 { import all; export all; }; area 0 { interface "eth*" { }; interface "lo" { stub; }; }; } Without any active OSPF neighbor the routes show all interface networks except that of interface lo: # birdc show route BIRD 2.0.10 ready. Table master4: 10.1.1.0/24 unicast [ospf1 17:03:20.860] * I (150/10) [3.3.3.3] dev eth0 10.1.2.0/24 unicast [ospf1 17:03:20.860] * I (150/10) [3.3.3.3] dev eth1 3.3.3.3/32 unicast [ospf1 17:03:20.860] * I (150/0) [3.3.3.3] dev lo Table master6: 2001:1::/64 unicast [ospf2 17:03:25.861] * I (150/10) [3.3.3.3] dev eth0 2001:2::/64 unicast [ospf2 17:03:25.861] * I (150/10) [3.3.3.3] dev eth1 Here the configuration of interface lo: # ip addr show dev lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet 3.3.3.3/32 scope global lo:1 valid_lft forever preferred_lft forever inet6 2001::3/128 scope global valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever What am I missing?
On Sun, Dec 11, 2022 at 06:30:46PM +0100, Bernhard Ehlers via Bird-users wrote:
I want to use OSPF with BIRD v2.0.10 on Linux.
That works well, except that the IPv6 network of the lo interface isn't announced on OSPFv3. The IPv6 networks of the ethernet interfaces are announced as well as the IPv4 networks of all interfaces (ethernet and lo). The only missing is the IPv6 network of lo.
Hi Due to some implementation details, OSPFv3 ignores interfaces that do not have link-local addresses (even if they are just stub). Just use: ip address add fe80::1/128 dev lo -- 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."
Am 11.12.22 um 18:50 schrieb Ondrej Zajicek:
On Sun, Dec 11, 2022 at 06:30:46PM +0100, Bernhard Ehlers via Bird-users wrote:
I want to use OSPF with BIRD v2.0.10 on Linux.
That works well, except that the IPv6 network of the lo interface isn't announced on OSPFv3. The IPv6 networks of the ethernet interfaces are announced as well as the IPv4 networks of all interfaces (ethernet and lo). The only missing is the IPv6 network of lo.
Hi
Due to some implementation details, OSPFv3 ignores interfaces that do not have link-local addresses (even if they are just stub). Just use:
ip address add fe80::1/128 dev lo
Thanks a lot, that works!!!
On 11.12.22 18:50, Ondrej Zajicek via Bird-users wrote:
On Sun, Dec 11, 2022 at 06:30:46PM +0100, Bernhard Ehlers via Bird-users wrote:
I want to use OSPF with BIRD v2.0.10 on Linux.
That works well, except that the IPv6 network of the lo interface isn't announced on OSPFv3. The IPv6 networks of the ethernet interfaces are announced as well as the IPv4 networks of all interfaces (ethernet and lo). The only missing is the IPv6 network of lo.
Hi
Due to some implementation details, OSPFv3 ignores interfaces that do not have link-local addresses (even if they are just stub). Just use:
ip address add fe80::1/128 dev lo
May I ask why not using the direct protocol to get the loopback addresses?
On 11.12.22 21:50 Bernd Naumann via Bird-users wrote:
On 11.12.22 18:50, Ondrej Zajicek via Bird-users wrote:
On Sun, Dec 11, 2022 at 06:30:46PM +0100, Bernhard Ehlers via Bird-users wrote:
I want to use OSPF with BIRD v2.0.10 on Linux.
That works well, except that the IPv6 network of the lo interface isn't announced on OSPFv3. The IPv6 networks of the ethernet interfaces are announced as well as the IPv4 networks of all interfaces (ethernet and lo). The only missing is the IPv6 network of lo.
Hi
Due to some implementation details, OSPFv3 ignores interfaces that do not have link-local addresses (even if they are just stub). Just use:
ip address add fe80::1/128 dev lo
May I ask why not using the direct protocol to get the loopback addresses?
I tried that as well and it worked. But I was concerned by this part of the documentation of the direct protocol:
The question is whether it is a good idea to have such device routes in BIRD routing table. OS kernel usually handles device routes for directly connected networks by itself so we don't need (and don't want) to export these routes to the kernel protocol. OSPF protocol creates device routes for its interfaces itself and BGP protocol is usually used for exporting aggregate routes.
So for OSPF the direct protocol should not be necessary and indeed it worked without it for the ethernet interfaces (both for IPv4 and IPv6) and for the lo interface on IPv4. Therefore my question. I think it is just personal choice, if one prefers adding the link-local address or using the direct protocol.
Hi, On Linux, I would suggest using a dummy interface for anything other than real loopback addresses (::1 and 127.0.0.1) and physical connections. The dummy interfaces as they have both link-local IPv6 and "real like" MAC address, so it is acting more like a physical device. This way, you would not need direct protocol either. Best Regards, Martin Hunek Dne pondělí 12. prosince 2022 9:28:31 CET, Bernhard Ehlers via Bird-users napsal(a):
On 11.12.22 21:50 Bernd Naumann via Bird-users wrote:
On 11.12.22 18:50, Ondrej Zajicek via Bird-users wrote:
On Sun, Dec 11, 2022 at 06:30:46PM +0100, Bernhard Ehlers via Bird-users wrote:
I want to use OSPF with BIRD v2.0.10 on Linux.
That works well, except that the IPv6 network of the lo interface isn't announced on OSPFv3. The IPv6 networks of the ethernet interfaces are announced as well as the IPv4 networks of all interfaces (ethernet and lo). The only missing is the IPv6 network of lo.
Hi
Due to some implementation details, OSPFv3 ignores interfaces that do not have link-local addresses (even if they are just stub). Just use:
ip address add fe80::1/128 dev lo
May I ask why not using the direct protocol to get the loopback addresses?
I tried that as well and it worked.
But I was concerned by this part of the documentation of the direct protocol:
The question is whether it is a good idea to have such device routes in BIRD routing table. OS kernel usually handles device routes for directly connected networks by itself so we don't need (and don't want) to export these routes to the kernel protocol. OSPF protocol creates device routes for its interfaces itself and BGP protocol is usually used for exporting aggregate routes.
So for OSPF the direct protocol should not be necessary and indeed it worked without it for the ethernet interfaces (both for IPv4 and IPv6) and for the lo interface on IPv4. Therefore my question.
I think it is just personal choice, if one prefers adding the link-local address or using the direct protocol.
On Mon, Dec 12, 2022, at 16:17, Martin Huněk via Bird-users wrote:
Hi,
On Linux, I would suggest using a dummy interface for anything other than real loopback addresses (::1 and 127.0.0.1) and physical connections. The dummy interfaces as they have both link-local IPv6 and "real like" MAC address, so it is acting more like a physical device. This way, you would not need direct protocol either.
This is what I'm using and it works well.
On Sun, Dec 11, 2022 at 09:50:09PM +0100, Bernd Naumann via Bird-users wrote:
Hi
Due to some implementation details, OSPFv3 ignores interfaces that do not have link-local addresses (even if they are just stub). Just use:
ip address add fe80::1/128 dev lo
May I ask why not using the direct protocol to get the loopback addresses?
You can do that, but then such route would be represented in OSPF as external route instead of as intra-area route (a prefix associated with a node), which has some subtle differences, e.g. another node announcing the same prefix as a intra-area route would be always considered closer, regardless of metric. -- 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."
participants (5)
-
Bernd Naumann -
Bernhard Ehlers -
Kevin P. Fleming -
Martin Huněk -
Ondrej Zajicek