On Tue, Feb 18, 2025, 18:38 Ondrej Zajicek <santiago@crfreenet.org> wrote:
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.
That is surprising to say the least... But I guess that is the problem then – I'd gone through the RFC to figure out why that was happening, but must have misunderstood this part. Doesn't it defeat the point of areas (and metrics for that matter), when a distant area happens to have 2+ slow links to the backbone?... (One of the ASBRs exporting this route happens to be an ABR for the separate area – is that something to be avoided?)
(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?
I don't remember for sure if they don't – it was 2020 when I did most of the experiments (this is the second time I'm trying to figure it out). RouterOS 7.x doesn't seem to have such an option, but it being a relatively new implementation I can only guess it follows the updated RFC.
-- 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."