On Fri, Apr 05, 2024 at 04:27:27PM +0200, Pim van Pelt wrote:
Hoi,
On 4/5/24 15:23, Ondrej Zajicek wrote:
I have almost implemented 'extended next hop' for OSPFv3. But then i pivoted to supporting properly IPv4 loopback nexthop [*]. Now i have doubts about usefulness of 'extended next hop', as any IPv4 router needs at one IPv4 address anyways (at least to be able to send ICMP messages) and there is no need to put IPv4 addresses on links. Are there any good arguments for it? In VPP, an interface that does not have an ip4 address, will not allow for ip4 traffic to enter it. In other words, there must be an ip4 address on the interface before forwarding is turned on. I know how to change that behavior in VPP, but it's not a problem in practice, because we can set 'unnumbered' interface and borrow an IPv4 address from another interface, usually a loopback interface with a /32 ip4 and /128 ip6.
I think it'd be super cool to use OSPFv3 without IPv4 transit networks and just reusing the loopback addresses, like so:
root@vpp0-2:~# ip -br a lo UNKNOWN 127.0.0.1/8 ::1/128 loop0 UNKNOWN 192.168.10.2/32 2001:678:d78:200::2/128 fe80::dcad:ff:fe00:0/64 e0 UP 192.168.10.2/32 2001:678:d78:200::2/128 fe80::5054:ff:fef0:1120/64 e1 UP 192.168.10.2/32 2001:678:d78:200::2/128 fe80::5054:ff:fef0:1121/64 * *However, up-thread (message of 2024-04-30, 16:04) I had that configuration, saw the LSAs but did not see Linux (nor VPP) pick up the routes.
Even if LSAs are here the question is whether OSPF generated such routes (i.e. whether birdc show route would show them). In order for kernel to pick them up, OSPF has to generate them and with 'onlink' flag on next hop.
My suspicion is that your commit will be inert in this scenario, because e0 already has an IPv4 address, so loopback_addr_used will remain 0.
I think it might help, because even if loopback_addr_used will remain 0, there is also this change in the patch: https://gitlab.nic.cz/labs/bird/-/commit/280daed57d061eb1ebc89013637c683fe23... That for OSPFv3-IPv4 removes next-hop-in-address-range check (and automatically adds onlink flag), which caused rejection of such next hops. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."