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

[Joakim Tjernlund]

On Tue, 2019-04-23 at 14:09 +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 Tue, Apr 23, 2019 at 10:28:46AM +0000, Kenth Eriksson wrote:
> > > 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."
> 
> The section 12.4.1.1 for 'unnumbered' case (Option 1) describes handling
> of *peer* IP address, it is silent about handling of *local* IP address.
> 
> 
> > > 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.
> 
> I think the standard just does not consider the case of 'unnumbered'
> link with both local and remote address but without subnet and assumes
> 'real' unnumbered PtP link with no local IP address associated with
> the iface.

There is always some local address, in linux you have to assign it to the I/F,
but in others, like Cisco, you can assign an IP address to a dummy I/F and then
tell unnumbered I/Fs to use the dummy I/Fs' IP address.
There has to be some SRC IP address on pkgs sent by OSPF

Since Linux always has an local IP adress it is not possible to deduce if the
user intended the link to be unnumbered or not, unless one wants to add explicit
config "unnumbered", it would be best to assume unnumbered I think.

Consider the use case with many /32 ptp links, all with the same local IP, there would
be a lot of redundant host routes in the Router LSA. Better to let the user
add an explicit stub network for all PtoP's if one needs it.