failover by EIGRP for 2 ipip tunnels

[rezaniazian42634]

hello
I have question about how to have failover solution when I am using 2 IPIP tunnels to connect a single router.

I can not figure it out  what network to advertise in EIGRP.

and now I am using static routing which is not efficient and I do not have failover on my sites.

my configuration on my customer side is :

----------

interface Tunnel122

 ip address 10.0.1.18 255.255.255.252

 ip mtu 1439

 ip tcp adjust-mss 1439

 tunnel source 88.19.5.34

 tunnel destination 46.36.112.5

 tunnel mode ipip0

interface Tunnel123

 ip address 10.0.2.18 255.255.255.252

 ip mtu 1439

 ip tcp adjust-mss 1439

 tunnel source 88.19.5.34

 tunnel destination 94.182.20.11

 tunnel mode ipip0

and my Head Quarter configuration : 
---------- 

interface Tunnel122

 ip address 10.0.1.17 255.255.255.252

 ip mtu 1439

 ip tcp adjust-mss 1439

 tunnel source 46.36.112.5

 tunnel destination  88.19.5.34

 tunnel mode ipip0

interface Tunnel123

 ip address 10.0.2.17 255.255.255.252

 ip mtu 1439

 ip tcp adjust-mss 1439

 tunnel source 94.182.20.11

 tunnel destination  88.19.5.34

 tunnel mode ipip0

[Elliot Dierksen]

When doing GRE tunnels and a routing protocol you have to be very careful. You can inadvertently advertise the interfaces that are the endpoints into the tunnel which makes the tunnels crash. I have found it very helpful and a best practice to put the transport underlay network into a separate VRF. This link is about DMVPN, but it also talks about the concept of an underlay network in a VRF. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dmvpn/configuration/xe-16/sec-conn-dmvpn-xe-16-book/sec-conn-dmvpn-mtt.html 

The other thing I would say is to keep all the tunnels up all the time, but weight them (on both sides) with the interface level "bandwidth" and/or interface level "delay" commands. Neither of those commands affect forwarding rates. They are only used for routing protocol metric calculation. I wouldn't load balance across the tunnels because the different paths could have widely varying delays which could put a load onto the hosts to reassemble out of order packets. You can try load balancing across multiple paths, but beware of that.