GRE Tunnels on a Cisco Router

One of my projects involved the configuration of GRE (Generic Routing Encapsulation) tunnels, encrypted by IPSec, between two locations. I was having some problems getting the tunnels to work properly, but now I’ve managed to resolve that problem, and the configuration is working well. Here’s some additional information on the problem and how it was finally corrected.

This was my first project using GRE tunnels. I’d used IPSec tunnels many times, and on many different platforms, but this time around we needed an interface that could be tracked for HSRP (Hot Standby Router Protocol) purposes, and until recently Cisco didn’t offer IPSec tunnel interfaces. (I just came across some documentation last night that indicated very recent releases of IOS offer this functionality.) So, the idea was to use GRE tunnels, track the GRE tunnels using HSRP for failover with another router, and encrypt the traffic using IPSec in transport mode.

The GRE tunnel configuration (scrubbed for sensitive data) looked something like this originally:

interface Tunnel0
 description GRE tunnel to other location
 ip address 192.168.254.1 255.255.255.252
 tunnel source FastEthernet0/0
 tunnel destination 172.31.254.1
 crypto map tunnel-ipsec-map

Of course, there was an appropriately configured interface at the other end of the tunnel as well. The tunnels came up, and appeared to work just fine, until we added the keepalive statement. (The keepalive statement is required for the tunnel to report an actual up/down status, necessary for HSRP interface tracking.) Then they went down and stayed down.

A “debug tunnel” statement showed that the keepalives were being sent, but none were being received. Thinking perhaps the IPSec configuration was incorrect, I removed the “crypto map” statement from the tunnel interface. It still didn’t work.

After reviewing the configuration again, I began to suspect an MTU issue—the “show int tun0″ output listed an MTU of 1514. I consulted with a Cisco expert (recently obtained his CCIE), and he confirmed that it was most likely an MTU issue. So I modified the configuration to look like this:

interface Tunnel0
 description GRE tunnel to other location
 ip address 192.168.254.1 255.255.255.252
 ip mtu 1400
 keepalive
 tunnel source FastEthernet0/0
 tunnel destination 172.31.254.1

At that point, the tunnel finally came up and I was able to pass traffic through the tunnel. I re-added the “crypto map” statement to enforce encryption, and the tunnels promptly went back down again.

Once again, debug output saved the day. The output from a “debug crypto” statement was constantly reporting “packet too small”. A search of the Cisco web site turned up a result (I can’t find it now) that indicated a bug within IOS and suggested the addition of a “tunnel key” statement. So, I modified the configuration again:

interface Tunnel0
 description GRE tunnel to other location
 ip address 192.168.254.1 255.255.255.252
 ip mtu 1400
 keepalive
 tunnel source FastEthernet0/0
 tunnel destination 172.31.254.1
 tunnel key 12345
 crypto map tunnel-ipsec-map

With this configuration, the IPSec/ISAKMP SAs were established and the tunnels came up, passing traffic as expected. The debug output showed no crypto errors, and keepalives were being sent and received. Success!

Tags: , , , ,

11 comments

  1. Ollie’s avatar

    Excellent post on Generic Routing Encapsulation, thanks for sharing with us.

  2. Jon’s avatar

    Thanks for the write up most insightful

  3. sajith’s avatar

    thanks for sharing …

  4. slowe’s avatar

    Ollie, Jon, Sajith, I’m glad you found the post useful. Thanks for taking the time to comment!

  5. Joel’s avatar

    Sir, after changing the IP MTU size to 1400, did you see the change on the ‘sh int tun0′ output?

    I just recently tried this and the mtu size still shows 1514.

    Thanks.

  6. slowe’s avatar

    Joel, it’s been so long since I did this configuration I can’t even remember. Might I suggest using something like GNS3 to simulate the environment to see what results you could expect?

  7. RD’s avatar

    @Joel, you need to shut the interface or reload the device to take effect.

  8. Kaime’s avatar

    thank for the post.
    very helpful

  9. richard’s avatar

    In the show int tun… You will see the mtu 1514, however, the tunnel uses the defined mtu.

  10. Sheryl’s avatar

    i have an almost sinilar problem. The tunnel works fine. however as soon as the internet fails, the tunnel does not come up automatically. We have revisit the settings and all are present including keep alive which has been set as 10 3.
    Any suggestion on what could be the problem and how it can be resolved?

  11. ahmed mokhtar’s avatar

    guys i’m enduring the same problem of sheryl tunnels can not switch to up status automatically , any suggestions plzz ????!!

Comments are now closed.