Hi,
I have usually used the "replace" keyword of iproute2 for similar
purposes. I would suggest a script as well, run via cron unless 1 minute
failover times are not acceptable. The logic could be as follows:
if ping -c1 $PRIMARY_NH >/dev/null 2>&1; then
ip route replace $PREFIX via $PRIMARY_NH
elif ping -c1 $SECONDARY_NH >/dev/null 2>&1; then
ip route replace $PREFIX via $SECONDARY_NH
else
ip route del $PREFIX
fi
Alternatively, one could look into a routing daemon that supports static
routing (Zebra/Quagga/FRRouting, BIRD, ...) and check if that supports
some form of next-hop tracking or at least removes static routes with
unreachable next-hops as one would expect from experience with dedicated
networking devices.
IMHO static route handling as done by the Linux kernel does not seem
useful for networking devices. I have even had bad experiences with
Arista switches and static routing because they relied too much on the
Linux kernel (probably still do).
Thanks,
Erik
--
Bufferbloat just waits in hiding to get you when you try to use the network.
-- Jim Gettys
On Wed, Jun 20, 2018 at 04:20:11AM +0100, cronolog+lartc wrote:
> Hi,
>
> I /think/ Linux continues sending ARP requests and doesn't fall back
> to the other route because the route to the failed next hop still
> exists in the routing table with highest metric, so it continues
> looking for this next hop. I get the same behaviour as you when
> labbing this up, I could not see a straightforward option to mark a
> route as invalid under changes in reachability, I'd also like to
> know if this feature is built in and exists.
>
>
> However in the enterprise Cisco world, we can do what you are trying
> to do very easily using "route tracking" and "IP SLA" features.
> Basically we define tests e.g. reachability via ping with
> appropriate frequency and threshholds, then attach these tests to
> one or more preferred routes. If the test fails, the associated
> route is automatically uninstalled from the forwarding table, so any
> existing lower metric routes get exposed and are used instead. When
> the test passes again, the preferred routes are reapplied.
>
> The underlying logic of this can certainly be scripted under Linux
> to get very similar functionality, then put into a cron job or a
> while loop or similar. Something along the lines of (pseudocode):
> if [the test such as ping fails] ; then
> if [preferred route exists] ; then ip route delete ... ; fi
> else ## ping is successful
> if [preferred route doesn't exist] ; then ip route add ... ; fi
> fi
>
>
> Hope that helps. I'm also interested in any other solutions to do
> this under Linux.
>
>
> On 2018-06-19 13:18, Akshat Kakkar wrote:
> >I have 2 interfaces
> >eno1 : 192.168.1.10/24
> >eno2 : 192.168.2.10/24
> >
> >I added routes as
> >172.16.0.0/12 via 192.168.1.254 metric 1
> >172.16.0.0/12 via 192.168.2.254 metric 2
> >
> >My intention : All traffic to 172.16.0.0/12 should go thru eno1. If
> >192.168.1.254 is not reachable (no arp entry or link down), then it
> >should fall back to eno2.
> >
> >But this is not working. My box keeps on looking for 192.168.1.254
> >(i.e. sending arp requests) and never falls back.
> >
> >Can anyone help?
> >
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
