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

[Kenth Eriksson]

On Thu, 2019-04-18 at 13:55 +0200, Ondrej Zajicek wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you recognize the sender
> and know the content is safe.
> 
> 
> 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.
> 

Does the description you give here comply to the intent in section
12.4.1.1 of RFC2328? The following statement of the RFC makes the
intent a bit unclear to me; "...a Type 3 link (stub network) should be
added." 

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

Configureable seems like a sensible thing to me. The default should be
what the standard suggests.
> 
> You say it differs from Quagga, what is their behavior?
> 

I'm not sure there is a difference after you explained that unnumbered
/32 with peer was treated different compared to /32 without peer. But
when I looked into the frr git repo, I can see that unnumbered
interface support was added in in git sha
525c183906c47c491611f294db218d53a561a3b9. Prior to that commit I think
quagga always re-distributed unnumbered interfaces as well.    
> --
> 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."