<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Hoi,<br>
    <br>
    <div class="moz-cite-prefix">On 4/5/24 15:23, Ondrej Zajicek wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:Zg%2F7abXoIbgv9KSb@feanor">
      <pre>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?
</pre>
    </blockquote>
    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.<br>
    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.<br>
    <br>
    I think it'd be super cool to use OSPFv3 without IPv4 transit
    networks and just reusing the loopback addresses, like so:<br>
    <br>
    root@vpp0-2:~# ip -br a<br>
    lo               UNKNOWN        127.0.0.1/8 ::1/128 <br>
    loop0            UNKNOWN        192.168.10.2/32
    2001:678:d78:200::2/128 fe80::dcad:ff:fe00:0/64 <br>
    e0               UP             192.168.10.2/32
    2001:678:d78:200::2/128 fe80::5054:ff:fef0:1120/64 <br>
    e1               UP             192.168.10.2/32
    2001:678:d78:200::2/128 fe80::5054:ff:fef0:1121/64<br>
    <b><br>
    </b>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. 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. <br>
    <br>
    The good news is, I have two patches to VPP that may still allow for
    this to work, one of them inhibits the 'unnumbered' interface from
    propagating its address to e0, and the other allows an interface to
    respond to ARP requests that are onlink but p2p and in another
    subnet. in other words, the configuration would look like this:<br>
    <br>
    root@vpp0-2:~# ip -br a<br>
    lo               UNKNOWN        127.0.0.1/8 ::1/128 <br>
    loop0            UNKNOWN        192.168.10.2/32
    2001:678:d78:200::2/128 fe80::dcad:ff:fe00:0/64 <br>
    e0               UP              fe80::5054:ff:fef0:1120/64 <br>
    e1               UP              fe80::5054:ff:fef0:1121/64<br>
    <br>
    .. and here I think your use-loopback commit will be active.,<br>
    <b><br>
    </b>Let me build Bird with your use-loopback <a
href="https://gitlab.nic.cz/labs/bird/-/commit/280daed57d061eb1ebc89013637c683fe23465e8">commit
    </a><b>
      and</b> VPP with my unnumbered-inhibit <a
href="https://github.com/pimvanpelt/lcpng/commit/a960d64a87849d312b32d9432ffb722672c14878">commit</a>
    <b>and</b> VPP accepting onlink ARP request (pending <a
      href="https://gerrit.fd.io/r/c/vpp/+/40482">gerrit</a>).<br>
    I will then check to see if VPP is happy to set the correct nexthop
    (both in Bird2, but also in the VPP FIB). <br>
    I'll report back after the weekend but thank you very much for
    working on this (and/or the extended next hop feature).<br>
    <br>
    groet,<br>
    Pim<br>
    <pre class="moz-signature" cols="72">-- 
Pim van Pelt
PBVP1-RIPE - <a class="moz-txt-link-freetext" href="https://ipng.ch/">https://ipng.ch/</a></pre>
  </body>
</html>