Re: Failover route

On 3/16/19 11:29 AM, Grant Taylor wrote:
> I'm very intrigued by the idea of using (what I'm going to call) BFD-EM 
> /without/ BFD control sessions.  I think this means that BFD-EM will 
> work against any device that will forward packets back to you.

I can see how BFD-EM can work in the SDSL failure scenario that I described.

+-------+     +------------+     /   +-----+   === Ethernet
| Linux +=====+ SDSL Modem +----/----+ ISP |   --- SDSL
+-------+     +------------+   /     +-----+    /  Break

I think the sequence of events would be something like the following:

1)  BFD-EM would send an IP packet (Ethernet frame) from it's Link-Net 
IP & local MAC to it's Link-Net IP and the upstream router's MAC.

2)  The upstream router will receive the Ethernet frame because it's to 
the upstream router's MAC.

3)  The upstream router will then route the IP packet out the proper 
interface for the destination IP of the packet.  This should be the same 
interface that the packet (Ethernet frame) came in on.

4)  BFD-EM will receive the IP packet from it's Link-Net IP & the 
upstream router's MAC to it's Link-Net IP and local MAC.

5)  BFD-EM successfully confirmed that there is end-to-end connectivity 
across the link via steps 1 through 4.

I like this.

It shouldn't require any support from the upstream router other than 
standard routing, which it is already doing.

I can also see how a BFD-EM implementation would only need to 
dynamically modify any route(s) using the upstream router.  It wouldn't 
need to remove or re-add any IPs to the interface.  (No fighting with 
NetworkManager, et al.)

I can see how it would be possible to use established system 
initialization scripts to bring up the interface with an IP and no 
default gateway.  Then have the BFD-EM implementation add / remove the 
default gateway as appropriate in response to the successful completion 
of steps 1 through 4 above.

I now wonder if it would be possible to have a BFD-EM implementation 
that doesn't alter the routing table itself.  Instead have it speak a 
routing protocol to a traditional routing daemon and allow it to manage 
the routing table.  Maybe a simple stateless routing protocol, RIP comes 
to mind.

> Very interesting. 

Very interesting indeed.



-- 
Grant. . . .
unix || die