Bird OSPF bug? (Mutliple areas, rfc1583compat off, cost ignored)

[Ondrej Zajicek]

On Sun, Jan 27, 2019 at 02:19:03AM +0700, Igor Podlesny wrote:
> On Sun, 27 Jan 2019 at 02:14, Ondrej Zajicek <santiago at crfreenet.org> wrote:
> 
> > On Sat, Jan 26, 2019 at 02:07:52PM +0700, Igor Podlesny wrote:
> > > I have test lab -- two OSPF routers, Bird 1.6.4: A, B.
> > >
> > > 2 areas defined: 0.0.0.0, 0.0.0.1. Export "all".
> > >
> > > When rfc1583compat is Off I observe default route gets propagated via
> > > area 0.0.0.1 in despite its interfaces have higher costs than area
> > > 0.0.0.0's have.
> > >
> > > Turning rfc1583compat On changes it to expected behaviour: interfaces
> > > costs are respected again.
> > >
> > > Bug or am I missing some piece of OSPF knowledge here?
> >
> > Hi
> >
> > I think it is correct. In OSPF, intra-area paths using non-backbone areas
> > are preferred over shorter backbone or inter-area paths. See RFC 2328,
> > section 16.4.1.
> 
> 
> And even higher interfaces costs shouldn't affect it? O_o

Yes, (from RFC 2328, section 16.4.1.):

            The path preference rules, stated from highest to lowest
            preference, are as follows. Note that as a result of these
            rules, there may still be multiple paths of the highest
            preference. In this case, the path to use must be determined
            based on cost, as described in Section 16.4.

            o   Intra-area paths using non-backbone areas are always the
                most preferred.

            o   The other paths, intra-area backbone paths and inter-
                area paths, are of equal preference.

Path/interface costs are relevant as a secondary measure in each of these
groups.

It is an OSPF detail with interesting history, where the original
algorithm from RFC 1583 was buggy and it took two tries to fix it.
For full story behind this, see:

RFC 2178, G.7 Advertising same external route from multiple areas
RFC 2328, G.2 Changes to external path preferences

-- 
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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20190126/fbc5eb8f/attachment.sig>