I’m having an issue with the configuration of a site-to-site link I’m trying to create using EoIP.
One site has two ISPs for redundancy, as both experience occasional dropouts. I have created an EoIP tunnel over each connection to the router at the other site (a datacenter), and the tunnels are secured with IPSec.
I have noticed however that the tunnel interfaces will show as Running, even if the underlying IPSec connection is not established. For example, if I disable the EoIP interface on one end, the IPSec connection will drop out, which I can see through IP > IPSec, but the EoIP interface on the other end will still show as running.
I am wanting to bond the two connections so that while both ISPs are up, I can get increased throughput to the datacenter, but as the EoIP interfaces always appear to be running, the bond isn’t seeing when one connection drops out, and is still trying to send traffic through that interface.
Is there something here I’m doing wrong? How can I get the EoIP interfaces to properly reflect if they are connected or not?
Try using OSPF across the tunnel. As long as the two interfaces have the same cost, OSPF will use equal-cost multipath routing (EQMP) to load share between the two paths. If one path fails, OSPF will lose adjacency across it regardless of the interface’s up/down state.
use keepalives on the interface. w/o keepalives the router cannot figure out whether the tunnel is working or not.
to be honest, the name “tunnel” is a bit confusing. Indeed it’s a tunnel, but it’s essentially stateless. there ain’t no control mechanism behind it.
just look at it as follows:
you put certain bytes in front of your IP packet (that’s referred as tunnel header) and glue another IP header to it (alltogether called tunnel overhead) and expect that someone on the far side has configured a mechanism to strip’em down and forward you original IP packet. then imagine a separate flow that works backwards.
either way you just can’t tell whether it’s working unless you have traffic on it. this is where keepalives come into the picture.
or as Zerobyte said, if you run any dynamic routing protocol over the tunnel that might steer traffic onto it - as long the OSPF or BGP can talk to the far side, they will know, it’s reachable, so they will use the received routing updates to steer your traffic onto the tunnel. whenever the tunnel stops transmitting your data (and implicitly the routing PDUs, so no HELLOs or BGP keepalives is received from the peer) the neighbourship will go down, and without received routes the traffic will be moved off from the non-working tunnel.
keepalives do the same, but they might rely on the far end a bit less than dynamic routing protocols. you specify the interval how often these small keepalives shall be sent (say 1-10sec) and the number of failed receptions after the tunnel will be declared as “down” or “not running”. then it’s just works.
indeed it provides less visibility compared to a proper dynamic routing session where your routers can “see” behind the far end device, but in most cases you will be just ok.
some ISPs will simply not establish no dynamic routing with you unless you pay them extra $$.