Can't ping through GRE Tunnel

[brentpavlovich]

Hello all, hopefully a simple issue. I am using Cisco Packet Tracer to simulate a network environment for an upcoming project. Part of the design involves the use of a GRE tunnel between two routers. Before I continue modeling the project which will involve a considerably more complex design, i'm having trouble getting a tunnel to establish between the two routers. There is nothing complex going on in this setup. Its two sites connected via the internet (simulated using a 4331 router). The public facing IPs of the two sites can ping each other. However the GRE tunnel won't establish, by which I mean i cannot ping one tunnel interface from another. Both sites say the tunnel interface is up up. I'm hoping someone can point me in the right direction as i'm not sure whether this is a simple config issue, or a bug with either the IOS running on the routers or the emulation software. 

From what I can tell troubleshooting, it seems to be an issue with ARP. Instead of routing to the tunnel destination IP, the router is sending an ARP request to the next hop which drops the packet. Interestingly if I enable proxy-arp on the internet interfaces, then I can ping. I've pasted the router configs in their entirety below. 

thanks for any and all replies! 

DataCenter1#show run

Building configuration...

Current configuration : 1026 bytes

!

version 15.4

no service timestamps log datetime msec

no service timestamps debug datetime msec

no service password-encryption

!

hostname DataCenter1

!

ip cef

no ipv6 cef

!

ip domain-name datacenter.net

!

spanning-tree mode pvst

!

interface Tunnel1

ip address 10.254.2.129 255.255.255.252

mtu 1476

tunnel source GigabitEthernet0/0/1

tunnel destination 192.168.0.2

!

interface GigabitEthernet0/0/0

no ip address

duplex auto

speed auto

shutdown

!

interface GigabitEthernet0/0/1

description Link-->Internet

ip address 192.153.118.10 255.255.255.0

no ip proxy-arp

duplex auto

speed 1000

!

interface GigabitEthernet0/0/2

no ip address

duplex auto

speed auto

shutdown

!

interface Vlan1

no ip address

shutdown

!

router bgp 65139

bgp log-neighbor-changes

no synchronization

neighbor 10.254.2.130 remote-as 123

!

ip classless

ip route 0.0.0.0 0.0.0.0 192.153.118.1

!

ip flow-export version 9

!

line con 0

!

line aux 0

!

line vty 0 4

login

!

end

Partner#show run

Building configuration...

Current configuration : 1037 bytes

!

version 15.4

no service timestamps log datetime msec

no service timestamps debug datetime msec

no service password-encryption

!

hostname Partner

!

ip cef

no ipv6 cef

!

spanning-tree mode pvst

!

interface Tunnel1

ip address 10.254.2.130 255.255.255.252

mtu 1476

tunnel source GigabitEthernet0/0/1

tunnel destination 192.153.118.10

!

interface GigabitEthernet0/0/0

no ip address

no ip proxy-arp

duplex auto

speed auto

!

interface GigabitEthernet0/0/1

description Link-->Internet

ip address 192.168.0.2 255.255.255.0

no ip proxy-arp

duplex auto

speed 1000

!

interface GigabitEthernet0/0/2

no ip address

duplex auto

speed auto

shutdown

!

interface Vlan1

no ip address

shutdown

!

router bgp 123

bgp log-neighbor-changes

no synchronization

neighbor 10.254.2.129 remote-as 65139

network 10.254.46.0 mask 255.255.254.0

!

ip classless

ip route 0.0.0.0 0.0.0.0 192.168.0.1

!

ip flow-export version 9

!

line con 0

!

line aux 0

!

line vty 0 4

login

!

end

[Richard Burts]

There are several interesting aspects to this situation. If we were going to investigate further I would want to see configuration details for the 4331 that is simulating the Internet. Here is what I observe:

- both routers use the IP of the public facing interface as the source/destination of the GRE tunnel.

- both routers can ping the peer router Public facing interface.

- if a ping from the tunnel source address to the tunnel destination address is successful (in both directions) then the tunnel should come up and be functional.

- but you tell us that a ping from the tunnel ip address to the remote end of the tunnel IP address fails. That is quite unexpected if the tunnel is really up. So we need to look for something else.

- you gave us a bit of a clue when you told us that if you enable proxy arp on the Public interfaces that you were then successful in ping to the remote end.

- you gave a very important clue when you found that the router is sending an arp request for the destination address when you attempt to ping the remote end of the tunnel. That is not the expected behavior. A GRE tunnel is effectively a point to point network. And in this case an arp should not be needed.

So the issue really is that the router is sending an arp request when it should not. I think this pretty clearly identifies the issue as a flaw in the implementation of PT.

[Georg Pauwen]

Hello,

can you post the zipped Packet Tracer project (.pkt) file ?

[brentpavlovich]

Thanks Rick for that info. I too feel the behavior i'm seeing through this software isn't what i would expect to see in a "real" network. For kicks i setup the same environment using a 4321 on a different IOS and it behaved the same way, pointing me to a glitch with the software over a glitch with the IOS. 

Georg, i've attached the project file. 

Thank you! 

[Georg Pauwen · Accepted solution]

Hello,

I agree, this definitely looks like a flaw in PT. You can 'trick' the routers to have tunnel connectivity by adding static host routes on all three routers as in the attached, revised file.

[brentpavlovich]

Interesting that adding host routes works. I think that confirms this is a bug with the software. Thanks so much all for your replies! That hack will work for what I need in my testing.