Re: OSPF for IPv4 over IPv6 only?

2024-04-05 Thread Ondrej Zajicek via Bird-users 
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/280daed57d061eb1ebc89013637c683fe23465e8#da87cc518d8a6ca24bc804dfc6ad134504731a9c

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: santi...@crfreenet.org)
"To err is human -- to blame it on a computer is even more so."

Re: OSPF for IPv4 over IPv6 only?

2024-04-05 Thread Pim van Pelt via Bird-users 

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. 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.


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:


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  fe80::5054:ff:fef0:1120/64
e1   UP          fe80::5054:ff:fef0:1121/64

.. and here I think your use-loopback commit will be active.,
*
*Let me build Bird with your use-loopback commit 
*and* 
VPP with my unnumbered-inhibit commit 
 
*and* VPP accepting onlink ARP request (pending gerrit 
).
I will then check to see if VPP is happy to set the correct nexthop 
(both in Bird2, but also in the VPP FIB).
I'll report back after the weekend but thank you very much for working 
on this (and/or the extended next hop feature).


groet,
Pim

--
Pim van Pelt
PBVP1-RIPE -https://ipng.ch/

Re: OSPF for IPv4 over IPv6 only?

2024-04-05 Thread Ondrej Zajicek via Bird-users 
On Tue, Apr 02, 2024 at 11:49:21PM +0200, Pim van Pelt via Bird-users wrote:
> Hoi Ondrej,
> 
> On 02.04.2024 16:40, Ondrej Zajicek via Bird-users wrote:
> > Although one could have option that forces it to interpret as IPv6, i
> > would prefer to have 'extended next hop' option that allows to accept
> > both IPv4 and IPv6 next hops in Link-LSA.

> ps - even with IPv4 on the interface and RFC5838 as it was intended, I still
> don't see Bird emit the learned routes to the kernel (see my message to
> Benoit on 30.03.2024, 15:50); so I think even setting extended next hop
> aside, I cannot confirm that OSPFv3 with ipv4 channel works in that
> configuration.

Hi

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?

[*] https://bird.network.cz/pipermail/bird-users/2024-April/017555.html

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
"To err is human -- to blame it on a computer is even more so."

Re: announce IPV4 loopback via an OSPF v3 backbone

2024-04-05 Thread Ondrej Zajicek via Bird-users 
On Wed, Mar 27, 2024 at 09:08:35AM +, Benoit Chesneau wrote:
> Hi everyone,
> 
> I was reading  the ospv3 spec and this link 
> https://networklessons.com/ospf/ospfv3-for-ipv4- and  was wondering if such 
> features is supported in bird 2. Can we announce loopbacks via OSPFv3 and 
> remove the need to use OSPFv2 and ptp subnets ? 
> 
> I see it as a good opportunity to reduce the usage of the IPv4 addresses if 
> we can just advertise loopbacks...

Hi

This feature was not implemented in BIRD 2, i just implemented it yesterday:

https://gitlab.nic.cz/labs/bird/-/commit/280daed57d061eb1ebc89013637c683fe23465e8

If there is no IPv4 address on the iface, it chooses an IPv4 address from
another OSPF-managed iface (preferably /32 or stub) and announces that.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
"To err is human -- to blame it on a computer is even more so."