BIRDv2 OSPF: Stub for loopback potentially broken: Invalid Prefix in LSA

[Ondrej Zajicek]

On Mon, Apr 15, 2019 at 12:56:24PM +0000, Kenth Eriksson wrote:
> > > Does OSPFv3 (RFC5340 / RFC5838) handle unnumbered (/32) differently
> > > from OSPFv2? 
> > 
> > Not in a significant way.
> > 
> 
> So a /32 shall be implicitly re-distributed in the OSPF area both for
> OSPFv2 and OSPFv3? I think that differs from how Quagga did it for
> unnumbered interfaces.

Well, we are mixing two cases here:

1) Just /32 (or /128) stub addresses (with no peer)

2) 'Unnumbered' PtP addresses with /32 local and /32 peer address.

The first case is always propagated in the OSPF area for both OSPFv2 and
OSPFv3 as any other prefix.

The second case is more complex. In OSPFv2, it always does not propagate
/32 local addresses and it propagates /32 peer addresses only if
configured as stub. In OSPFv3, this is not implemented and neither local
/32 address nor peer /32 address are propagated (as Linux IPv6 does not
have PtP addresses and we missed that when done OSPFv3-IPv4). But this we
should fix and it should behave as in OSPFv2.

Another issue is whether local /32 *should* be propagated for
'unnumbered' PtP links. We do not do that, but i think it should be
configurable, and perhaps default yes in cases the local IP is not
covered by range from other ifaces.

You say it differs from Quagga, what is their behavior?

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at 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."