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. Note - the patch is probably *not* 100% right; I am not very sure whether both checks are backwards or only the orta_pref() one. It's merely my first successful attempt at fixing the issue (which only affected Bird, not any other OSPFv2 implementation I have here). Regardless, it did happen to fix the issue I was having, and now Bird2 chooses the path I expect it to choose: Before: Table master4: 172.20.0.0/14 unicast [ospf4 10:09:35.865] * E2 (150/10080/100) [31.220.42.129] via 10.147.255.10 on homegw Type: OSPF-E2 univ OSPF.metric1: 10080 OSPF.metric2: 100 OSPF.tag: 0x00000000 OSPF.router_id: 31.220.42.129 After: Table master4: 172.20.0.0/14 unicast [ospf4 12:48:02.452] * E2 (150/30/100) [31.220.42.129] via 10.147.240.122 on gre-land Type: OSPF-E2 univ OSPF.metric1: 30 OSPF.metric2: 100 OSPF.tag: 0x00000000 OSPF.router_id: 31.220.42.129 --- proto/ospf/rt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proto/ospf/rt.c b/proto/ospf/rt.c index d7753ce0a..c6bf5699e 100644 --- a/proto/ospf/rt.c +++ b/proto/ospf/rt.c @@ -200,7 +200,7 @@ orta_compare_asbr(const struct ospf_proto *p, const orta *new, const orta *old) if (!p->rfc1583) { - r = epath_preferred(new) - epath_preferred(old); + r = epath_preferred(old) - epath_preferred(new); if (r) return r; } @@ -242,7 +242,7 @@ orta_compare_ext(const struct ospf_proto *p, const orta *new, const orta *old) /* 16.4 (6c) - if not RFC1583, prefer routes with preferred ASBR/next_hop */ if (!p->rfc1583) { - r = orta_pref(new) - orta_pref(old); + r = orta_pref(old) - orta_pref(new); if (r) return r; } -- 2.48.1