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