Unnumbered PtP links (Was: Re: OSPF: incorrect path computation for v2.0.5+?)

[Ondrej Zajicek]

On Mon, May 25, 2020 at 06:04:34PM +0000, Kenth Eriksson wrote:
> On Fri, 2020-05-22 at 22:59 +0200, Ondrej Zajicek wrote:
> > On Fri, May 22, 2020 at 07:14:44PM +0000, Kenth Eriksson wrote:
> > > On Thu, 2020-05-21 at 12:43 +0200, Ondrej Zajicek wrote:
> > > > This patch should fix the issue, could you try it?
> > > 
> > > Looks promising, applied on top of 2.0.7, and a quick test on the 5
> > > node setup looks correct. Will do some more testing.
> > > 
> > > We definitely need this fix in the pending 2.0.8 :-)
> > 
> > This issue has a long history. In 2012, we changed data field for
> > unnumbered PtP links from iface id (specified by RFC) to IP address based
> > on reports of bugs in Quagga that required it, and we used out-of-band
> > information to distinquish unnumberred PtPs with the same local IP
> > address.
> > 
> > Then with OSPF graceful restart implementation, we found that we can no
> > longer use out-of-band information, and we need to use only LSAdb info
> > for routing table calculation, but i forgot to finish handling of this
> > case, so multiple unnumbered PtPs with the same local IP addresses were
> > broken.
> > 
> > This patch returned back iface id to data field for unnumbered PtP links
> > (i.e. reverted back the change from 2012), while doing computation just
> > from LSAdb info. It fixed your case (multiple unnumbered PtPs with the
> > same local IP address) and is correct per RFC, but it may trigger bugs
> > with other implementations (like the one that led to the 2012 change).
> > 
> > Hopefully Quagga/FRR already fixed that issue and perhaps we should add
> > an option to revert back to the old behavior in case someone noticed a
> > compatibility issue.
> > 
> > It would be useful if anybody could try OSPFv2 unnumbered PtP links
> > between BIRD with this patch and other implementations.
> 
> Tried a small interop by loading bird 2.0.4 on node 2 and Quagga
> 0.99.11 on node 3 (the Quagga build has the unnumbered patch mentioned
> by Jocke). Results looks correct as far as I can tell. 
> 
> Seems like that patch is also part of FRR;
> https://github.com/FRRouting/frr/commit/c81ee5c94f
> 
> And it still looks like at least the functions are there in latest FRR
> 7.3.1. 
> https://github.com/FRRouting/frr/blob/frr-7.3.1/ospfd/ospf_interface.c#L393

Hi

Checked that. Seems like FRR uses the similar approach like BIRD 2.0.4,
so that is OK. It also seems that FRR does not implement OSPF graceful
restart, so they did not (yet) hit the same issue with Jocke's patch like
we in 2.0.5.


> Haven't actually tested if this actually interops with bird. 
> 
> The RFC states that unnumbered ptp links shall use ifIndex, whereas as
> numbered ptp links shall use IP interface address. Any reason to not
> follow the RFC? 
> https://tools.ietf.org/html/rfc2328#page-130

Well, i generally prefer not to make intentional changes that break
existing setups, and switching to this (as done by the patch i sent)
would break Mikrotik compatibility for unnumbered PtP links (due to
Mikrotik broken SPF calculation).


> Ondrej, what are you plans for the patch provided? Good to go for
> master? 

Seems to me that perhaps the least painful solution is to use 2.0.4
approach (position based) for regular OSPF, and switch to ifIndex/data
based approach (like the patch) when OSPF graceful restart is enabled.

So plan is to make a new/different patch for master.

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