cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
403
Views
0
Helpful
3
Replies

Simple problem with GRE tunnels

Iceberg83
Level 1
Level 1

Hi everyone

I've encountered a very strange situation today.

The problem is very simple: Two Cisco 2800 Series connected over a leased VPN. Simple GRE tunnels configured on both, everything running smoothly.

Basic config on both routers:

Router A:

interface Tunnel1

description *****

ip address 172.16.201.1 255.255.255.252

ip tcp adjust-mss 1200

tunnel source FastEthernet0/1 (which is 10.124.200.58)

tunnel destination 10.124.200.62

tunnel path-mtu-discovery

Router B:

interface Tunnel1

description *****

ip address 172.16.201.2 255.255.255.252

ip tcp adjust-mss 1200

tunnel source FastEthernet1/0 (which is 10.124.200.62)

tunnel destination 10.124.200.58

tunnel path-mtu-discovery

At that moment, everything was running fine.

Now, I have to change one of my 2800 with a 3845. So recreated Tunnel1 from Router A config to my 3845, and connected the cable to the new router. Then changed the tunnel source and that's it.

Ping from 10.124.200.58 to 10.124.200.62 continued to work just fine.

Both tunnels were up/up. But ping to Ip address of the tunnel failed everytime. I've spent hours to figure what's happening, deleted and recreated the tunnels, but with no success.

The most awkward thing happened when I got the cable back to my initial 2800. Again, both tunnel went up/up straight away, ping to *200.62 passed through just fine, but no replies when pinging on the Ip address of the tunnels.

I also tried rebooting both routers, no success.

Surely I must be missing something. But what is it?

Any help would be highly appreciated.

Thank you

Ed

3 Replies 3

Hello

Not sure what occuring but can you try:

1) Default each physical interface and delete the tunnels once again.

2) Cear the arp cache
3) Recreate the physical interfaces and again make sure you have reachability between these interfaces

4) recreate the tunnels without PMTUD enabled

Router A

interface Tunnel1

description *****

tunnel mode gre ip

ip address 172.16.201.1 255.255.255.252

tunnel source FastEthernet0/1

tunnel destination 10.124.200.62

Router B:

interface Tunnel1

tunnel mode gre ip

description *****

ip address 172.16.201.2 255.255.255.252

tunnel source FastEthernet1/0

tunnel destination 10.124.200.58

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

blau grana
Level 7
Level 7

I would also suggest to try this without tunnel path-mtu-discovery on both tunnel ends.

Best Regards

Please rate all helpful posts and close solved questions

Best Regards Please rate all helpful posts and close solved questions

Hi,

first, to get a proper linkstatus for the tunnel-interfaces, I'd recommend to enable keepalives.

PMTUD shouldn't be a problem, it just copies the DF-bit of the original header into the tunnel (transport) IP-header. Of course it won't hurt to disable it while troubleshooting in order to simplify the setup.

You could do some basic troubleshooting to confirm the reachability of the tunnel endpoints.

Router A:

show ip route 10.124.200.62

show ip int brief fa0/1

ping ip 10.124.200.62 source fa0/1

For Router A you already did that,  vice versa for Router B?

If it works bidirectional there is connectivity but not for encasulated packets.

What is the output of "show interface tu 1" like?

Hardware is Tunnel

...

MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,

...

Encapsulation TUNNEL, loopback not set

...

Tunnel protocol/transport GRE/IP

GRE (point-to-point, IPv4) is the default mode but you also can set it with "tunnel mode gre".

Maybe "debug tunnel" shows something interesting?

Hope that helps

Rolf

Review Cisco Networking for a $25 gift card