ospfd: make ECMP nexthop order deterministic

The order of ECMP nexthops currently depends on whatever order the
pqueue code returns the vertices in, which is essentially random since
they compare as equal.  While this shouldn't cause issues normally, it
is nondeterministic and causes the ldp-topo1 test to fail when the
ordering comes up different.  Also, nondeterministic behaviour is not a
nice thing to have here in general.

Just sort by nexthop address;  realistic numbers of ECMP nexthops should
hopefully not make this a performance issue.  (Also, nexthops should be
hot in the caches here.)

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

diff --git a/ospfd/ospf_spf.c b/ospfd/ospf_spf.c
index 74dba273e619815fb89c9931ec250f0639ff6f74..6e03fa9bdeb04648bc5f3c833397e973e784d31d 100644 (file)
--- a/ospfd/ospf_spf.c
+++ b/ospfd/ospf_spf.c
@@ -166,6 +166,12 @@ static void vertex_parent_free(void *p)
        XFREE(MTYPE_OSPF_VERTEX_PARENT, p);
 }
 
+static int vertex_parent_cmp(void *aa, void *bb)
+{
+       struct vertex_parent *a = aa, *b = bb;
+       return IPV4_ADDR_CMP(&a->nexthop->router, &b->nexthop->router);
+}
+
 static struct vertex *ospf_vertex_new(struct ospf_lsa *lsa)
 {
        struct vertex *new;
@@ -180,6 +186,7 @@ static struct vertex *ospf_vertex_new(struct ospf_lsa *lsa)
        new->children = list_new();
        new->parents = list_new();
        new->parents->del = vertex_parent_free;
+       new->parents->cmp = vertex_parent_cmp;
 
        listnode_add(&vertex_list, new);
 
@@ -463,7 +470,7 @@ static void ospf_spf_add_parent(struct vertex *v, struct vertex *w,
        }
 
        vp = vertex_parent_new(v, ospf_lsa_has_link(w->lsa, v->lsa), newhop);
-       listnode_add(w->parents, vp);
+       listnode_add_sort(w->parents, vp);
 
        return;
 }