10% of our GRE tunnels flap each day. I've a whitepaper stating that EIGRP overtime will put a route to the tunnel network in its routing table with the next hop as the far end tunnel IP creating a routing loop (recurring routing). "The tunnel brings itself down until EIGRP rebuilds its routing table". The solution is to put static routes in place using /32. This is unacceptable. The problem seems to be EIGRP and GRE. EIGRP has more benefits than GRE so I want to find out what other options exist, beside GRE. What can I do to replace GRE quickly and least disruptively?
Eigrp and tunnels are very stable. This issue of learning the end points via the tunnel can happen with any routing protocol. When this happens they flap constantly not just a few times a day.
So first is before the tunnel is built how do the 2 routers know to get to the end points.
The key here is that what ever method you use to make say ping work you need to make sure you do not damage that. Most the time this is done via static or connected.
If you learn the end points via EIRGP then you must be very careful to filter this network so it is not learned from the neighbor relationship formed over the tunnel.
Now if you have a /24 that contains the tunnel end point this whole subnet must not be allowed to pass the tunnel. You cannot cause some traffic for this subnet to be though the tunnel and the rest direct. The best solution is to use the loopbacks as the tunnel end points so you only have a single device to worry about.
The main reason to use a tunnel at layer 3 is because the intervening routers do not have routes to the networks on the end points. If you have full readability via eigrp already then you do not need tunnels but I would assume there is some requirement that cannot be met with eigrp or they would not have been created in your network.
Thanks for your response. We have a /32 loopback for end points of the tunnel and we have put static routes on some links over many ISP links and some P2P between buildings but the same flapping continues. In some instances Cisco Works reveals the WAN link going down, the recursive routing kick in and then the FA egress interface of the edge router shutdown/online. How do I stop the FA from cycling? I thought just the tunnel int went down during recursive routing correction.