GRE Tunnel Problem

Unanswered Question
Oct 7th, 2009


I would like to seek your help guys on deploying a GRE tunnel in two of our sites. This is the diagram.


SiteA is using 4506 and SiteB and C are using 6509 in hybrid mode. The broken lines are 100Mbps Metro Ethernet link.

Each Site has its own ISP. We wanted to create a GRE tunnel between SiteA and SiteC because we don't want to failover the internet connection of SiteA to SiteB during SiteA ISP downtime. We want to fail it over to SiteC. However, after creating the GRE tunnel between SiteA and C, the tunnel interface keeps on going up and down. I already filtered the loopback addresses used as source/destination to not cross the GRE tunnel to prevent recursive routing. We are using EIGRP as the routing protocol. Also, the Microsoft Exchange traffic and other traffic that SiteC is hosting became inaccessible from SiteA.

I tried to check the link above but unfortunately, I can only go for 3rd solution. The 4500 and 6500 doesn't have the ip tcp adjust-mss command. So I just increased the interface IP MTU to 1500 as recommended by Cisco. I also keep on receiving this output from the 6500 switch.

Oct 7 13:51:37.311: IP: recv fragment from offset 0 bytes

Oct 7 13:51:37.315: IP: recv fragment from offset 1456 bytes

We have already tried building GRE tunnel between one of our sites to another site in a different country but we are using E1 connection and I was able to use the ip tcp adjust-mss command coz we used a router. I suspect there's a problem with MTU size.

Please help me understand what to do next. Thanks in advance.


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Danilo Dy Wed, 10/07/2009 - 23:44

Does the source and destination IP can reach each other before putting the GRE Tunnel?

There might be some routing constraint specially in SiteB. For GRE Tunnel, I usually use static routing for source and destination IP to be more preferred. Make sure this is done in SiteA, SiteB, and SiteC.

Inside GRE Tunnel, you can use any routing protocol of your choice, just take note of GRE Tunnel default cost.

John Patrick Lopez Thu, 10/08/2009 - 00:41

Hi Guys,

The command, ip tcp mtu-path-discovery is not available too. I only have tunnel path-mtu-discovery command but I tried that one yesterday and it didn't fix the issue. I can ping the Exchange server when the tunnel is down but when it goes up, the ping stops. All paths are metro ethernet. I don't know if I need to deal with MTU and IP MTU to fix the issue.



hammy1982 Thu, 10/08/2009 - 01:14

Did you try to debug ospf events?

Yesterday i had a similar problem too.

"debug ip ospf events" says that MTU of far end Interface was to small.

you have to look if there is a fix MTU on the Interface where you bound the GRE Tunnel. Try to set the MTU on the Tunnel not on the Interface.

It has to be the same on both ends.

You could try to set MTU to 1300.

Maybe you have a Problem with your Path.

Try to get close to your MTU by pinging (without GRE) with df-bit set. Then set the MTU on the Tunnel (minus GRE-Overhead).

John Patrick Lopez Thu, 10/08/2009 - 02:38

I am using EIGRP. In OSPF, the MTU must match so it will give you an error why the adjacency won't come up. I think you can do something like ip mtu ignore...i

i will try to decrease the value of the IP MTU and see how it will react to network traffic. I can't do it right now coz it's support hours.

Danilo Dy Thu, 10/08/2009 - 04:07

The tunnel should remain up/up regardless of what you do with the MTU settings.

You will only deal with MTU once you sent packet through the tunnel.

Before you look into your problem with MTU, you have to make sure the tunnel is up/up.

If tunnel is bouncing up and down its probably recursive routing, therefore its recommended that source and destination IP Address is using static routing in SiteA, SiteB, and SiteC. Have you checked what I told you earlier?

yuhuiyao Mon, 10/12/2009 - 06:14

Agreed. MTU is a second stage, first the tunnel should up and stable.

Running gre on a switch sometimes will causes an issue. Unlike a router which supports gre natively, a switch might behave differently.

I suggest you open a case with Cisco. My thought is, it is more like a bug.

frag/reassembly will not kill a tunnel. This is not a frag issue.

John Patrick Lopez Mon, 10/12/2009 - 22:53

Yes. I filtered the loopback interface to be advertised out of the tunnel to prevent recursive routing. I might try to simulate this scenario using 3 routers instead and see if there's a bug. Someone told me before that tunnel interfaces on 6500 have bugs. I would open a TAC case too.


This Discussion