BGP: Fix network import check use with NHT instead of scanner
When next hop tracking was implemented and the bgp scanner was eliminated,
the "network import-check" command got broken. This patch fixes that
issue. NHT is used to not just track nexthops, but also the static routes
that are announced as part of BGP's network command. The routes are
registered only when import-check is enabled. To optimize performance,
we register static routes only when import-check is enabled.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Resolving routes over the default route for NHT can lead to all sorts
of problems. So, we explicitly exclude resolving routes for NHT over the
default route. A knob is provided to allow the route to be resolved over
the default in case of special circumstances.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
In nexthop tracking, the code currently compares the nexthop state of the
resolved_route for a prefix with the previous nexthop state. However, if
the resolved route itself changes, we can end up comparing the RIBs of
unrelated prefixes and assuming that nothing has changed. To fix this, we
need to store and compare the new resolved route with the previously
resolved route. If this has changed, assume the NH associated with a route
has changed.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
The code is structured in a way that ends up invoking zebra_delete_rnh()
multiple times which can lead to crashes and asserts. This patch fixes
the issue by setting a flag when an RNH structure is being deleted and
ignores any further attempts to delete the structure.
Zebra: Add route-map support for Next Hop Tracking
It is sometimes useful to restrict the resolution of recursive routes
to only specific via's. For example, in some configurations resolving
a route through a default route is not acceptable.
This patch adds a new route-map attach point, to zebra's next-hop-tracking
server. Whenever NHT is considering sending notification of a route
resolution, it applies a specified route-map and only if it passes, is the
NHT reachable message sent to the appropriate client protocol (BGP, OSPF etc.).
If the route-map filters the resolution, then a withdraw is sent to the
client protocol.
The route-map is sent the ip address of the route via which the resolution is
happening as well as the valid NHs associated with that route.
We also add support for matching on IP addr prefix len and source protocol
to ensure that resolution happens only via a very specific route.
quagga: nexthop-tracking.patch
Add next hop tracking support to Quagga. Complete documentation in doc/next-hop-tracking.txt.
Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
