On Tue, Feb 18, 2025 at 12:51:09PM +0200, Mantas Mikulėnas via Bird-users wrote:
From: Mantas Mikulėnas <grawity@gmail.com>
For an ordinary E1 or E2 route exported by another Bird2 router in the same area, it was consistently choosing a 10000+ metric path through another area, despite having a direct 10-metric path to the origin in the same backbone area.
It seems that this was because the rule 16.2 metric comparison was backwards and always chose highest metric.
Hi I think the original code is right. orta_pref() / epath_preferred() does not return metric (higher -> worse), but it returns whether the path is preferred (0/1, higher -> better). Therefore there is: rt.c:245: r = orta_pref(new) - orta_pref(old); but rt.c:250: r = ((int) old->metric1) - ((int) new->metric1); The behavior you are describing:
it was consistently choosing a 10000+ metric path through another area, despite having a direct 10-metric path to the origin in the same backbone area.
It seems to me that it is in fact a peculiar behavior specified by RFC 2328 16.4.1:
When multiple intra-AS paths are available to ASBRs/forwarding addresses, the following rules indicate which paths are preferred. These rules apply when the same ASBR is reachable through multiple areas, or when trying to decide which of several AS-external-LSAs should be preferred.
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.
Can you send me the output of 'show ospf state', so i could check that?
(which only affected Bird, not any other OSPFv2 implementation I have here).
Not sure why other implmenetations do not have the same behavior, perhaps they are RFC 1583 and not RFC 2328 OSPF versions, or they are configured with RFC1583Compatibility enabled? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."