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
