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

[Joakim Tjernlund]

On Sat, 2020-05-23 at 15:28 +0000, Joakim Tjernlund wrote:
> On Sat, 2020-05-23 at 13:57 +0200, Ondrej Zajicek wrote:
> 
> > On Sat, May 23, 2020 at 10:43:52AM +0000, Joakim Tjernlund 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).
> > > Not sure I follow here, have you done away with rt_pos_to_ifa() and friends now
> > > and gone back to the old way?
> > Yes, it does not use rt_pos_to_ifa(). The approach with rt_pos_to_ifa()
> > does not work with graceful restart - after restart, router learns its
> > own LSAs (generated by previous run) and needs to do routing table
> > calculation without stored pos info. And it is probably bad idea to have
> > different route calculation algorithms in these cases.
> 
> 
> hmm, I wonder how other impl. does this. I recall the some reference impl. also
> 
> used something like the pos method?
> 
> 
> 
> > > The old way had several drawbacks, one of them was this
> > > dependency on interface ID. Does current impl. depend on a well behaved neighbor too?
> > The current (2.0.7) is broken with regard to multiple unnumbered PtPs
> > with the same local IP address (as it uses only IP address in the data
> > field), but does not depend on well behaved neighbors.
> > The offered patch uses interface IDs, like described in RFC. That patch
> > is reliable (i do not see any issue with using interface IDs, what do you
> > mean?), but depends on well behaved neighbors. And it seems that there
> > are significat badly behaved ones.
> 
> 
> When I developed this pos idea on Quagga I found that Q was dependant on
> 
> the remote neighbour also sending interface ID in its LSA for unnumbered interfaces.
> 
> Using the pos method, all this dependency went away. I suspect Bird does not have this
> 
> dependency, it will work regardless of IP address or Interface ID in remote hosts?
> 
> 
> 
> > > Is it compatible with any other Bird release?
> > Yes, that is not an issue. BIRD (at least post-2012) does not use 'data'
> > field of PtP links from neighbor LSAs. This field is only relevant for
> > the router who originated that LSA. It would work (for BIRD peers) even
> > if we put some random numbers here.
> > My current idea how to make it work without interface-ids and without
> > stored pos info: The problem is to match Router-LSA records with OSPF
> > ifaces that generated them. Instead of using just 'data' field, we can
> > use all fields ('data' to mach local IP address, router-id to see if
> > there is established neighbor with that router-id, and matching
> > configured cost).
> 
> 
> I think this will not work, all my efforts to match the correct interface just using
> 
> the LSAs failed for multiple unnumbered I/Fs to the same remote host. That lead to the
> 
> pos method in the end. Now, this was many years ago som maybe memory fails me.
> 
> 
> 
> > And for case with two parallel equal links that are described in
> > Router-LSA by two equal records, we would have flag (in ospf_iface) that
> > ensures one OSPF iface is matched with at most one record, so the first
> > record is matched with the first matching iface and the second record is
> > matched with the second matching iface.
> 
> 
> There can be more than 2 ptop links, we can have many more than 2.
> 
> 
> 
> > I would be glad to hear any comments to this idea or suggestions of other
> > ideas how to solve it.

Thinking some more on this ..

The pos method depends only on your own Router LSA.
If I recall correctly(mind you, this was a long time ago), the R-LSA only depends
on your own interfaces wanting to use OSPF, you could always calculate your own R-LSA
before starting any graceful restart(or so I hope) instead of relying on someone else's idea
of you own R-LSA(it would be safer to only trust your self).

 Jocke