Re: Failover route

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 fails
> it 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