Bird OSPF bug? (Mutliple areas, rfc1583compat off, cost ignored)
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? -- End of message. Next message?
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. Option rfc1583compat disables this behavior and changes it to simpler, older RFC 1583 behavior, but that behavior may lead to routing loops in some border cases. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
On Sun, 27 Jan 2019 at 02:14, Ondrej Zajicek <santiago@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 -- End of message. Next message?
On Sun, Jan 27, 2019 at 02:19:03AM +0700, Igor Podlesny wrote:
On Sun, 27 Jan 2019 at 02:14, Ondrej Zajicek <santiago@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@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."
participants (2)
-
Igor Podlesny -
Ondrej Zajicek