isisd: fix wrong next-hops from SPF

The forwarding table was filled with wrong next-hops, and which is even
worse, it was done in a totally non-deterministic way.

The next-hop set for an IP prefix by isisd was the neighbor IS from
which the flooded LSP about the IP prefix was arrived. So, if an IS
received all the LSPs through its, say, eth0 interface, all entries
in the forwarding table contained the next IS reachable via eth0 as
the next-hop.

The solution is to propagate the correct next-hop further from node to
node as the SPF algorithm traverses the graph and selects the next
node to be added to the set of already covered nodes.

Also, the construction of the tentative node list (the nodes where the
shortest path is not known yet) was buggy: if a node was already a
member of this list with a certain path cost, and an alternative path
was found to it with a lower cost while processing a pseudo-node LSP,
it was not added to the list. This way, the path selected by isisd for
a certain prefix was the first one it encountered during the LSDB
processing.

Signed-off-by: Fritz Reichmann <fritz@reichmann.nl>

0 files changed, 0 insertions, 0 deletions