-
Notifications
You must be signed in to change notification settings - Fork 5
Description
There is no existing logic in maghemite to perform next-hop validity checks (beyond ensuring it is unicast and isn't a local address) or recursive resolution.
This means that if a BGP peer sends us a route with a non-connected next-hop (e.g. an eBGP peer is using a third-party next-hop or has modified it via policy, or an iBGP peer is re-advertising an external route w/o next-hop self), or if a static route is configured with a non-connected next-hop, we will just accept and install the route with the next-hop as-is.
This is problematic for indirect next-hops because there will (usually) be no way for ARP/NDP to complete.
Note: There may be some exceptions to this, e.g. if we are targeting an address assigned to the directly connected peer and their ARP/NDP stack replies to queries targeting a local address not assigned to the interface queries arrive on (on Linux, this is controlled by the arp_accept sysctl parameter).