OSPF performance/SPF calculations
joakim.tjernlund at transmode.se
Fri Apr 23 15:27:10 CEST 2010
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.
More information about the Bird-users