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