12-07-2009 03:07 AM - edited 03-04-2019 06:53 AM
Hi All
I did post a question a little while ago regarding GRE tunnels with VRF's and got some helpful responses, However there is something that I do not understand and I am hoping some of the more knowledgeable folks on here can provide an explanation.
I am trying to set up two GRE tunnels between two routers, using the same source interface and destination IP address for each tunnel.
I start off configuring the first tunnel (tun0) as follows
Router 1
interface Tunnel0
description O&M Tunnel
ip address 10.0.0.1 255.255.255.252
tunnel source FastEthernet0/0
tunnel destination 192.168.80.1
tunnel key 123
Router 2
interface Tunnel0
description O&M Tunnel
ip address 10.0.0.2 255.255.255.252
tunnel source FastEthernet0/0
tunnel destination 192.168.50.1
tunnel key 123
Once I have the configuration on each router, I can then successfully ping each tunnel end point IP address (10.0.0.x) from the opposite router. All as expected.
I then configure the second tunnel (tun1) as follows,
Router 1
interface Tunnel1
description User Plane Tunnel
ip address 20.0.0.1 255.255.255.252
tunnel source FastEthernet0/0
tunnel destination 192.168.80.1
tunnel key 321
Router 2
interface Tunnel1
description User Plane Tunnel
ip address 20.0.0.2 255.255.255.252
tunnel source FastEthernet0/0
tunnel destination 192.168.50.1
tunnel key 321
Now when I ping the tunnel 1 end point IP address (20.0.0.x) from the opposite router the ping is successful. However when I attempt to ping the tunnel 0 end point IP addresses (10.0.0.x) , these pings now fail. It seems that the configuration of the second tunnel has killed the first.
Can anybody explain why this is?
Is there something wrong with my configuration or is it just not possible to have more than 1 tunnel interface with the same source interface/destination IP address?
Best Regards & Thanks in advance,
Michael
Solved! Go to Solution.
12-07-2009 11:00 AM
Michael
I do not believe that it works to have 2 GRE tunnels with exactly the same source and destination addresses between 2 routers. I believe that there must be at least one unique address (source or destination) for each tunnel.
HTH
Rick
12-07-2009 02:25 PM
http://www.cisco.com/en/US/docs/ios/interface/command/reference/ir_t2.html#wp1012689
The source address is either an explicitly defined IP address or the IP address assigned to the specified interface.
You cannot have two tunnels using the same encapsulation mode with exactly the same source and destination address. The workaround is to create a loopback interface and source packets off of the loopback interface.
When using tunnels to Cayman boxes, you must set the tunnel source command to an explicit IP address on the same subnet as the Cayman box, not the tunnel itself.
GRE tunnel encapsulation and deencapsulation for multicast packets are handled by the hardware in PFC3 and 12.2(18)SXF and later releases. Each hardware-assisted tunnel must have a unique source. Hardware-assisted tunnels cannot share a source even if the destinations are different. You should use secondary addresses on loopback interfaces or create multiple loopback interfaces to ensure the hardware-assisted tunnels do not share a source.
12-07-2009 11:00 AM
Michael
I do not believe that it works to have 2 GRE tunnels with exactly the same source and destination addresses between 2 routers. I believe that there must be at least one unique address (source or destination) for each tunnel.
HTH
Rick
12-07-2009 02:15 PM
Hi Rick
Thanks for the reply and information. That's pretty much what I expected, as I had searched the web and had not come across any site which showed multiple GRE tunnels using the same source interface/destination IP address.
Best Regards,
Michael
12-07-2009 02:25 PM
http://www.cisco.com/en/US/docs/ios/interface/command/reference/ir_t2.html#wp1012689
The source address is either an explicitly defined IP address or the IP address assigned to the specified interface.
You cannot have two tunnels using the same encapsulation mode with exactly the same source and destination address. The workaround is to create a loopback interface and source packets off of the loopback interface.
When using tunnels to Cayman boxes, you must set the tunnel source command to an explicit IP address on the same subnet as the Cayman box, not the tunnel itself.
GRE tunnel encapsulation and deencapsulation for multicast packets are handled by the hardware in PFC3 and 12.2(18)SXF and later releases. Each hardware-assisted tunnel must have a unique source. Hardware-assisted tunnels cannot share a source even if the destinations are different. You should use secondary addresses on loopback interfaces or create multiple loopback interfaces to ensure the hardware-assisted tunnels do not share a source.
12-07-2009 11:28 PM
Hi Edison
Thanks for the detailed reply. Much appreciated.
Best Regards,
Michael
01-21-2010 03:56 AM
Hello, I create two or more GRE tunnels with the same origins, but not the same destinations, ie I have 3 routers A, B, C 2 tunnels have one that goes from A to B and the other goes from A to C on origin of both tunnels is the same interface (same IP) and destination are diferent , is this possible and if no additional configuration that I recommend.
01-21-2010 04:19 AM
Juan
I do not fully understand the environment that you describe (are there 2 tunnels between A and B or is it a tunnel A to B and a tunnel A to C?). But multiple tunnels should work ok as long as the source/destination of each tunnel is unique.
HTH
Rick
01-21-2010 07:33 AM
I'm going to Eplica better on my network I have 3 each router connected to the cloud of ISP, my router is the router A, B and C, router A to B there is a tunnel, as the router A to C There is another tunnel, in my router to have the origins of my two tunnels, a tunnel to B and the other to C, my question is on the router A can create the two tunnels so that both share the same interface and IP origin? but it is possible that changes do.
01-23-2010 02:04 PM
Juan
It works well and no problem to have 2 tunnels on router A with the same source IP if one tunnel goes to router B and one tunnel goes to router C.
HTH
Rick
11-05-2014 04:05 PM
Hi Richard,
I am having issues implementing the backup tunnel for my customer.
RTR-A - 1xcircuit (say 183.2.3.1)
RTR-B - 2xcircuit (f0/0,f0/1)
Currently there is a tunnel1 from RTR-B sourcing from f0/0 going to RTR-A without any issue. But when I configure the tunnel2 sourcing from f0/1 pointing to the same destination IP of RTR-A with the following static, the first tunnel will go down...
I configured the following static say
ip route 183.2.3.1 255.255.255.252 163.2.3.1
ip route 183.2.3.1 255.255.255.252 173.2.3.1
As long I configured the 2nd static the first tunnel will go down... but when I make the 2nd static a higher AD the first tunnel remains up but the 2nd tunnel remains down.
If RTR-A has 2xcircuit I don't have a problem if I am simulating it.
My question is, is it possible to do a tunnel from RTR-B with a dual home circuit to the same destination?
Thank you...
11-06-2014 01:40 PM
The original post was clear that it was just a regular GRE tunnel with no encryption or anything like that. Can you clarify whether the tunnel you are asking about is just a regular GRE or does it perhaps also use encryption?
The private Email that you sent has a bit that is not in this post and I quote it here "I was able to make it happen but using the loopback on RTR-A as the destination for the 2nd tunnel of RTR-B. But I just don't understand why its not working in the normal destination as the IP of RTR-A?" If it works ok with the second tunnel using the loopback then I would have thought that it should work using a second physical interface. Can you post the config of both routers? That might help us identify what is the issue here?
HTH
Rick
11-08-2014 07:19 AM
Hi Rick,
Thank you. It has an encryption. I attached the configs for the two routers.
For the file "with_loopback" I configured it to make the second tunnel work.
Please note that RTR-B has a dual link to RTR-A with just a single link.
The file "without_ loopback" that's the one I am having issues with the second tunnel. If I configure the static with the same AD from RTR-B, the first tunnel which is currently up will just go down...
ip route 163.81.217.136 255.255.255.252 163.81.217.121
ip route 163.81.217.136 255.255.255.252 159.42.205.241
Ok, I have changed the AD of the second static to a higher one
ip route 163.81.217.136 255.255.255.252 163.81.217.121
ip route 163.81.217.136 255.255.255.252 159.42.205.241 250
The first tunnel remains up but the second tunnel is not coming up...
Ok, then I interchanged the AD on the two static just like below...
ip route 163.81.217.136 255.255.255.252 163.81.217.121 250
ip route 163.81.217.136 255.255.255.252 159.42.205.241
And now the second tunnel goes UP and the first tunnel then go down...
I don't know if i need to add something in the config or this design just don't work? I am not certain.
Thanks Rick....
11-08-2014 09:07 AM
Thanks for the additional information. It does help explain what is going on. My first reaction is that I am surprised that either set of configurations works. My experience is that when we are dealing with IPSec tunnels that IOS supports a single IPSec Security Association to a single remote device. But if you can get it to work with two tunnels that is interesting.
The thing that I notice is that in RouterB with loopback the tunnel destinations are different
tunnel destination 163.81.217.138
tunnel destination 20.20.20.20
where in RouterB without loopback the tunnel destination is the same in both tunnels.
I also notice that you have applied the crypto maps to the outbound interfaces and to the tunnel interfaces. In old versions of IOS it was required to have the crypto map applied to both. But by 12.4 the crypto map is applied only to the outbound interface and not to the tunnel. I have seen some odd things happen in recent code versions when the crypto map is applied to both the tunnel and the outbound interface. I am not sure that this is a factor here but I do suggest that you remove the crypto map from the tunnel interfaces.
HTH
Rick
11-08-2014 05:02 PM
Thanks Rick.
I removed all the crypto map from the tunnel interface but still not working. I keep seeing this
*Mar 1 01:36:23.747: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
(ip) vrf/dest_addr= /163.81.217.138, src_addr= 159.42.205.242, prot= 47
*Mar 1 01:37:23.819: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
(ip) vrf/dest_addr= /163.81.217.138, src_addr= 159.42.205.242, prot= 47
11-08-2014 05:06 PM
From the above comments
The thing that I notice is that in RouterB with loopback the tunnel destinations are different
tunnel destination 163.81.217.138
tunnel destination 20.20.20.20
-Yes that's correct, it has different destination (with loopback)
where in RouterB without loopback the tunnel destination is the same in both tunnels.
-(without loopback) Yes the same on both tunnels since I am only using one IP of the DIP physical interface.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide