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."