Hi,
On 3/16/19 18:12, Grant Taylor wrote:
On 3/16/19 10:22 AM, Erik Auerswald wrote:
As a crude method I have used a cron job to ping the gateways and add
or remove (default) routes based on ping results in the past. You
could use iproute2's 'ip link' to check interface status instead (or
first).
Is the following true:
· The NIC link is staying up.
· The IP is remaining assigned to the interface.
· You are conditionally adding / changing / removing the default
gateway that is the far side of the link.
· You have some sort of ECMP and / or PBR in place to work with
multiple default gateways.
I found issues with relying on link status in the following scenario:
+-------+ +------------+ / +-----+ === Ethernet
| Linux +=====+ SDSL Modem +----/----+ ISP | --- SDSL
+-------+ +------------+ / +-----+ / Break
Linux will think that the link is up, because it is up to the SDSL
modem. Yet there is no end-to-end connection between Linux and the ISP
because there is a break in the SDSL connection to between the SDSL
modem and the ISP.
I have fought this very scenario. The same could be true if you use an
Ethernet switch as a media converter going between copper and fiber.
The problem is that Linux sees the link as always being up, despite
there being a break further down the line.
If you have an xDSL modem such that the next-hop IP address is on the
ISP side, using ping to probe reachability of the next-hop should just
work. You could look into using the -r and -I options of ping (from
iputils as packaged by Debian, in my case).
If you want to check to some specific IPs or hosts behind one ISP, you
can use static host routes (that are not withdrawn via any daemon and
stay up even when the interface status goes down) pointing out the
specific interface to check. Of course, those IPs should not provide
other useful service, or you risk blackholing them on connection
failures.
You may be able to subscribe to Netlink messages to get informed about
interface state changes. At least for a prototype it might suffice to
use iproute2's 'ip monitor' to receive Netlink messages, but I have
not yet tried this.
I like the idea and the ingenuity. Unfortunately it suffers from the
underlying problem above.
Routing daemons are supposed to do that, so using one with static
default routes might give you the intended results.
I don't know that I've heard that routing daemons are /supposed/ /to/
rely on local link state. I think that many do for various reasons. But
I've never heard of any such mandate before.
I'd say that is more of a tradition. Routing daemons are often written
to mimic Cisco IOS behaviour, and there static routes towards an
IP that is not reachable (except for a possible default route) are
removed from the RIB and FIB. This is not a requirement for a routing
daemon, and e.g. Cisco IOS allows overriding this default behaviour.
To me, monitoring for loss of a link is mostly an optimization for the
routing daemon to know that a link is unusable in short order and can
remove the associated routes. I'm fairly certain that the Linux kernel
will do the same when link goes down, and remove routes that were using
that link.
IIRC the Linux kernel does not remove those routes itself.
Sure, there are some link-state protocols that may want to know this
information as part of the protocol's operation. As such the routing
daemon that implements said protocol would want to know too.
Thanks,
Erik
