[PATCH] OSPF: Fix inverted path comparison for external

[Ondrej Zajicek]

On Tue, Feb 18, 2025 at 12:51:09PM +0200, Mantas Mikulėnas via Bird-users wrote:
> From: Mantas Mikulėnas <grawity at 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 at crfreenet.org)
"To err is human -- to blame it on a computer is even more so."