OSPF performance/SPF calculations

[Joakim Tjernlund]

Ondrej Zajicek <santiago at crfreenet.org> wrote on 2010/04/23 14:09:50:
>
> On Fri, Apr 23, 2010 at 12:38:59PM +0200, Joakim Tjernlund wrote:
> > > > But this won't fix multiple ptp I/Fs between the same two routes and
> > > > I don't think it will work if one end is unnumbered and the other one is not.
> > >
> > > Our algorithm (in the git tree) works well for multiple ptp ifaces between
> > > the same two routers (because both the SPF and the calc_next_hop() chooses
> > > the same (cheapest) ptp link.
>
> > Even if all local PtoP I/Fs have the same IP address or no IP address?
>
> Yes, for the version in the git tree.
>
> Or more precisely, it works for links having the same ptp address.
> (a link with ptp/peer addresses is considered unnumbered).
>
> If there is really no IP address on the link, it will not work, but
> for several completely different reasons - BIRD core would not accept
> such route.
>
> > What does this comment in calc_next_hop mean?
> >  /*
> >      * Remaining cases - local neighbours.
> >      * There are two problems with this code:
> >      * 1) we use IP address from HELLO packet
> >      *    and not the one from LSA (router or link).
> >      *    This may break NBMA networks
> >      * 2) we use find_neigh_noifa() and does not
> >      *    take into account associated iface.
> >      *    This breaks neighbors connected by more links.
> >      */
>
> This is an old code, which has some bugs i fixed a two weeks ago:

Oh, I figured I cloned fairly recently. Must have jut missed you change.

Anyhow I looked at the new code and it is an improvement but I think there
is a flaw: It looks like the ptp code just find ANY interface that has a connection
to the remote router, not the I/F that has created that particular RLSA entry.
That may lead to asymmetric links, TX one link and RX on another. Not sure
what other implications there might be but I believe OSPF was not designed to deal
with such scenarios.

     Jocke