In the traditional implementation of GRE tunnels on Cisco routers there is an issue about what causes the GRE tunnel to go down. As long as the Cisco router has a valid route to the tunnel destination the router will show the tunnel as up/up. This can lead to a situation in which the tunnel is not passing traffic because of some issue in the transit network but the tunnel interface is still up/up.
There are at least 2 aspects of this to consider:
- it is much less of an issue if you are running EIGRP over the tunnels. This is because EIGRP will detect loss of connectivity (lost EIGRP hello messages) and drop the neighbor relationship and drop any routes learned over the tunnel, even if the interface still says up/up.
- Cisco has provided a feature to address this in fairly recent code. There is now support for keepalives on the GRE tunnel. They are optional. But if you configure keepalives on the GRE tunnel and if there is some loss of connectivity through the tunnel, then the tunnel interface will show as up/down.
I think that I understood the part of the question about do GRE tunnels go down. But I do not understand very well what you are asking here. What kind of implementation are you asking for documentation?
I have done many GRE tunnels, and I have run EIGRP over quite a few of these tunnels. EIGRP has worked well for us over GRE tunnels.
My current setup is FW1-SW1-RTR1-LINK1. I have a similar on my other leg, which is FW2-SW2-RTR2-LINK2. HSRP is running between RTR1 and RTR2 through its gigabit interfaces. RTR1 through has the higher priority which makes it the active router.
RTR1 and RTR2 are running EIGRP as the routing protocol. My question is:
1. I wanted to setup load balancing between the two links but my problem how do I do it considering that the default gateway of my firewall is the virtual ip of HSRP. And as I've know, packets are being routed automatically to the active router which is RTR1.
2. How do I setup my routers to force packets destined to x.x.x.x to route via LINK1 and y.y.y.y to LINK2 ?
Not sure how this is related to the gre tunnel question so I will try to comment just this part.
Best would be to run a routing protocol between the firewalls and the routers but many people prefer to user the older layer 2 design.
Forcing certain packet one way or another is not all that hard since you are manually load balancing the traffic. Although you can use unequal load balancing in EIGRP you will get mixed results.
Since rtr1 and rtr2 talk EIGRP (I hope) to each other over the LAN interface that uses HSRP they learn each others routes. All you need to do is manipulate the metric of xxxx and yyyy. You want the routers to think that the cost over the ethernet to the other router is better than the cost over their directly connected link.
The hot router even though he knows he just received a packet on the same interface he is going to send it out on (ie to the other router) will still do that. It is not exactly the most efficient thing to do but it works. What it will attempt to do to resolve this is send a ICMP redirect message to the firewall telling it the better path. Since firewalls tend to dislike these type of messages it will just ignore it and keep sending all its traffic to the hot router.
This is all fine and good for this end but you must also do something on the far side. You can use a similar solution but if you want the traffic to flow back on the same link it was received on you have a issue.
For example device aaaa sends traffic to xxxx over link1 and yyyy over link 2. The return traffic are both going to destination aaaa and it will pick the link only based on the destination. If you do not want it to work this way you are going to have to use policy routing to override the normal routing and use the source address to choose the path.
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 customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...