Hi netdev community, 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. I have posted this in lartc but looks like solution, if any, has to be from netdev. Your views on this. Do we have some plan/roadmap to resolve this in linux kernel? On Wed, Jun 20, 2018 at 1:49 PM, Erik Auerswald <auerswal@xxxxxxxxxxxxxxxxx> wrote: > 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
