This topic is to discuss the following lesson:
Hi Rene
How to change it to use second key instead the first key
Hello Lam
The choice of GRE key depends on the routing configured in each router.
There are two GRE tunnels between R1 and R2 with specific IP addresses. The default route within R1 and R2 indicates which should be the next-hop IP. This next-hop IP is also what specifies which tunnel should be used.
R1 has a default route to 172.16.12.2 and R2 has a default route to 172.16.12.1 so for all communication in both directions, Tunnel 1 should be used since tunnel 1 is on the 172.16.12.0/24 subnet.
Without the GRE key, as you see in the lesson, either tunnel will be used. By putting in the GRE key, only tunnel 1 is used.
Now if you want to use Tunnel 2, you simply change the routing so that the default route of R1 points to 172.16.21.2 and the default route of R2 points to 172.16.21.1. Then traffic will use the other tunnel.
I hope this has been helpful!
Laz
HI Laz
Thank, I now has clearer understanding.
Regards
Tan lam soon
Hi Laz,
I have two points to discuss:
- Does the use of tunnel key allow the transmission of multicast traffic over GRE tunnels?
- In a local Lab, I tried to build two GRE tunnels based on loopback interfaces. Bothe tunnels have same source and destination IPv4 address. First tunnel interface has an IPv6 address (the tunnel is supposed to carry IPv6 traffic), second tunnel interface has an IPv4 address (the tunnel is supposed to carry IPv4 traffic). The observed behaviour is that always the second tunnel to be configured is up, the second one is always down. e.g. if I first configure the IPv6 over IPv4 tunnel and then the IPv4 over IPv4 tunnel, then it’s the latter that works.
Is this behaviour expected?
Thanks
Alex
Hello Alex
GRE tunnels by definition support multicast traffic. This is why GRE is often used to convey multicast traffic over a network that may natively not support it. This is useful also for routing protocols to function since they extensively use multicast to operate. The use of a tunnel key does not affect this support of multicast, so yes, you should be able to transmit multicast traffic over GRE tunnels that use a tunnel key.
As for the two GRE tunnels in your lab, there’s really no reason for only one tunnel to be functional at any time. I’m inclined to believe that the problem lies elsewhere. I suggest you start off by recreating the lab in the lesson, with two tunnels that support IPv4. Make sure you get both tunnels to work. Then, go on to changing one of the tunnels to support IPv6. The following lesson will help you to do that:
https://networklessons.zendesk.com/agent/tickets/31220
Check out the behaviour at this point and let us know how you come along. If you have trouble along the way, let us know so we can help you further.
I hope this has been helpful!
Laz
What happend if i enable tunnel key on tu2 but no enable tunnel key on tu1. The dafault route stil to Tu1 . What happend?
Hello Daniel
That’s an excellent question! I tried labbing this up and found the following:
In the first case I removed the tunnel key from Tunnel 2 on both ends. When pinging I found that the behavior remained the same, as if both keys were installed. It seems that both R1 and R2 recognize that the route that must be taken is via tunnel 1 since routing is configured that way, and since tunnel 1 still has keys on both ends, there is no confusion as to which tunnel to use.
In the second case I replaced the tunnel key on Tunnel 2 and removed it from Tunnel 1. I found that the pings from H1 were sent out of R1 correctly, as I see the Pkts Out
column value increasing. However, I see that the packets never reach R2, or at least they never register on the stats of the tunnel interface. I would have to assume then that if a router like R2 has at least one GRE tunnel configured with a key, and the arriving packet has no key, it simply drops the packet.
I hope this has been helpful!
Laz
Thank you very much . It is very helpful
Hi Laz - without the keys configured, what causes the return traffic from H2 to go via Tun2 in the 1st place, and end up being de-encapsulated on R1 on Tun2? Becase from a routing perspective the next hop is pointing to an IP address on Tun1, so why does R2 send it via Tun2?
Interestingly, I tried changing the next-hop in the default route to be on the Tun2 interface (no key) and I noticed both ICMP request and replies used Tun2, which is different from the behaviour seen in the lesson when the next-hop was pointing to an Tun1 next-hop.
Thanks
Hello Bhawandeep
This is an excellent question. I have been unable to find any official document that states the process that a router will use to determine which tunnel to use. You may find that different IOS versions will use a slightly different process.
Remember that when you use the next hop IP in the ip route
command, a recursive lookup will take place to find the exit interface. It may use the exit interface of the tunnel that corresponds to the next hop IP, however, when this is encapsulated on the other end, there is no information in the packet to determine which tunnel should be used.
Based on your post, as well as on this Cisco community post below, it seems that the higher tunnel number is used. Note that tunnel 2 is always used for incoming packets, while the outgoing tunnel used is based on the routing.
I hope this has been helpful!
Laz