GRE Tunnel Problem

jpl861 · ‎10-07-2009

Hi,

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

SiteA-------------------------SiteB--------------------------SiteC

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.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a0080093f1f.shtml

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 10.196.255.3 offset 0 bytes

Oct 7 13:51:37.315: IP: recv fragment from 10.196.255.3 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.

John

Danilo Dy · ‎10-07-2009

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.

hammy1982 · ‎10-07-2009

Hi.

Did you mention to use the ip tcp mtu-path-discovery command?

Else you have to calculate your MTU by the Path you use.

IPSEC and GRE Header.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml#t16

hammy1982 · ‎10-08-2009

Hi.

Did you mention to use the ip tcp mtu-path-discovery command?

Else you have to calculate your MTU by the Path you use.

IPSEC and GRE Header.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml#t16

jpl861 · ‎10-08-2009

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.

Thanks,

John

hammy1982 · ‎10-08-2009

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

jpl861 · ‎10-08-2009

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

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 · ‎10-08-2009

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?

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a008048cffc.shtml

yuhuiyao · ‎10-12-2009

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.

jpl861 · ‎10-12-2009

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.