On 3/12/19 8:32 AM, Leroy Tennison wrote:
I have a device with two routes to the Internet configured as default nexthop via <IP address 1> dev <NIC 1> weight 1 default nexthop via <IP address 2> dev <NIC 2> weight 1 > If I'm understanding what I saw correctly, if (when) one interface failsit still tries it every other time. What I saw was an outbound ping regularly failing then succeeding (a few successes then a few failures then the success/failure pattern repeated). I then noticed that one interface wasn't fully plugged in and, after rectifying that, received 100% ping response.Adjusting weights in this situation only makes things better/worse depending on which interface fails, is there a way to configure failover so that one interface is always tried and the second used only if the first fails? Bonding isn't an option because these are two distinct point-to-point links.
You're stepping into a very murky area. I've not been able to get what I think you're wanting to do to work reliably after multiple attempts in 20<ish> years. - Hopefully someone knows something that I don't.
I have gotten Dead Gateway Detection to work. But that only removes a route when the Dead Gateway is detected and will not detect when the gateway is alive, nor will it re-add the gateway.
I have had issues with DGD not working (without fobbing some knobs) if link is not lost. So an SDSL issue on the other side of a bridging modem isn't detected properly.
I have not needed to fight this battle in a while. But I've come to the conclusion that I'd do it in multiple stages. I'd likely use a NetNS (or possibly heavy weight VM) to function as a local gateway that would monitor the immediate upstream gateway. It would then conditionally advertise itself as a default gateway to a (main) downstream routing instance that would do ECMP across the viable upstream routing instances.
You also have the problem of how to detect and respond to problems past the ISP's default gateway. I.e. if the problem is in their core or their upstream connections. In this scenario, all the logic testing reachability to the ISP is largely useless, if not actually providing a false signal. At least that (or something resembling it) had been my plan.
One of the complications with doing this is how do you have routes to probe things without having the kernel use said routes for data traffic. This starts to quickly get into Policy Based Routing and / or containerization with separate routes. I suppose you can also have a route to the probe destination that is more specific than the default. Now we're down the rabbit hole.
Recently I've been wondering about doing something to monitor the traffic and actually watch for a sufficient imbalance in outgoing SYN vs incoming SYN+ACK. If that gets too far towards SYN only, consider the route as being problematic. This would account for the ISP upstream issue too. Thus far I've only been thinking about the route in it's entirety. But it should be possible to also be more granular.
I have long wanted Bidirectional Forwarding Detection to be a thing between my router and my ISPs. Unfortunately, (it's my understanding that) BFD requires active support from the other side.
I would love to learn that someone has solved this with just the Linux kernel and not requiring some sort of daemon, be it a proper routing daemon or something like I've described above.
-- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
