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.
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
