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

[Joakim Tjernlund]

On Sat, 2020-05-23 at 18:04 +0200, Ondrej Zajicek wrote:
> On Sat, May 23, 2020 at 03:28:00PM +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?
> 
> Perhaps it was other way (Q dependent on remote neighbor sending IP)?
> 
> See http://trubka.network.cz/pipermail/bird-users/2012-August/007880.html

Not sure, I do recall Q had problem using unnumbered in one end of the link and numbered in the other,
a hint of this can been seen from the old commit msg:
This has the following advantages:
 - Multiple PtP interfaces with the same IP address between two routers.
 - Use Unnumbered PtP on just one end of the link. <<<<-----
 - Faster OI lookup for the OSPF interface and only
   done once for PtoP links.

This should all be history by now as Q no longer uses the old way.

> 
> > > > 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.
> 
> It would work with any number of links - the flag would mean 'already
> consumed for PtP link', so next same PtP description would not match it
> and use next available matching interface.
> 
> It probably would not work for unnumbered PtMP interfaces, but these are
> not supposed to exist by RFC 2328 anyways.

I see, I cannot say if this has any drawbacks though. It feels like some middle ground
between the old method and the pos method.

 Jocke