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. 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: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
