cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
33484
Views
10
Helpful
19
Replies

Configuring 2 GRE tunnels with same Source interfaces and dest IP addresses

keeleym
Level 5
Level 5

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

2 Accepted Solutions

Accepted Solutions

Richard Burts
Hall of Fame
Hall of Fame

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

HTH

Rick

View solution in original post

http://www.cisco.com/en/US/docs/ios/interface/command/reference/ir_t2.html#wp1012689

Usage Guidelines

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.

View solution in original post

19 Replies 19

Richard Burts
Hall of Fame
Hall of Fame

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

HTH

Rick

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

http://www.cisco.com/en/US/docs/ios/interface/command/reference/ir_t2.html#wp1012689

Usage Guidelines

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.

Hi Edison

Thanks for the detailed reply. Much appreciated.

Best Regards,

Michael

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.

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

HTH

Rick

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.

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

HTH

Rick

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...

 

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

HTH

Rick

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.... 

 

 

 

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

 

HTH

Rick

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

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: