I took a look on the subject, and I have a question, when we will configure the static route
it will solve the problem for sure, but the we will not use the routing protocol EIGRP, so I can't see why we will use this solution whitout knowing the source problem for the flapping of th tunnel interface!!!
I do not understand how you believe that configuring a static route for the tunnel destination address means that you will not use the routing protocol. We would use the routing protocol to advertise our subnets to the remote peer and use the routing protocol to learn the subnets from the remote peer. But if the tunnel destination address is learned by the routing protocol then it produces the recursive routing problem, which was the case in the original post. While there are other potential solutions the most common solution to the problem is a static route for the destination. Then you can use the dynamic routing protocol for the other subnets.
 Clearly the source of the flapping was recursive routing and recursive routing happens when the tunnel destination address appears to be reached through the tunnel. Having the tunnel destination address included in the dynamic routing protocol is the most common source of this problem.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...