summaryrefslogtreecommitdiffstats
path: root/ospf6d/ospf6_lsdb.c
diff options
context:
space:
mode:
authorDinesh Dutt <ddutt@cumulusnetworks.com>2013-08-24 07:55:50 +0000
committerDavid Lamparter <equinox@opensourcerouting.org>2013-11-07 18:15:43 -0800
commitb81e97a8a7f85ecc7489dc8a7c7b9d403d9c4bc6 (patch)
tree48e2c8492f01cc177a6691878cf4e5a329fe4d2d /ospf6d/ospf6_lsdb.c
parent17d003da963d6294e5ab95c690de285eccf0bac0 (diff)
downloadquagga-b81e97a8a7f85ecc7489dc8a7c7b9d403d9c4bc6.tar.bz2
quagga-b81e97a8a7f85ecc7489dc8a7c7b9d403d9c4bc6.tar.xz
ospf6d: correct nexthop through directly connected networks
This is implementing this part of RFC 2328: This is the "first case", see below, 16.1.1. The next hop calculation ... If there is at least one intervening router in the current shortest path between the destination and the root, the destination simply inherits the set of next hops from the parent. Otherwise, there are two cases. In the first case, the parent vertex is the root (the calculating router itself). This means that the destination is either a directly connected network or directly connected router. The outgoing interface in this case is simply the OSPF interface connecting to the destination network/router. ... The current Quagga code always tries to inherit the nexthop from a parent vertex, but does not cover the case that the destination is directly connected to the root vertex. This patch adds support for that case. Signed-off-by: James Li <jli at cumulusnetworks.com> Reviewed-by: Dinesh G Dutt <ddutt at cumulusnetworks.com> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Diffstat (limited to 'ospf6d/ospf6_lsdb.c')
0 files changed, 0 insertions, 0 deletions