Configuring Generic Routing Encapsulation (GRE) tunnels on Cisco IOS

Overview

Generic routing encapsulation (GRE) is a tunneling protocol which was initially developed by Cisco, and later it has been adopted as an industry standard in RFC 2784. GRE allows the encapsulation of a wide variety of network layer protocols inside virtual point-to-point links. This means that the original packet is encapsulated inside a GRE header and a new IP header containing the source and the destination of the tunnel endpoints. The GRE protocol does not provide any security for the data being transported so if encryption is needed GRE must be used in conjunction with IPsec protocol. Some of the reasons for using GRE are the need to transport multicast traffic, or to provide workarounds for networks with limited hops. In this article we will demonstrate how two networks which do not have reachability can be connected through an GRE tunnel.

GRE tunnelling concepts

GRE tunnelling configuration involves the creation of tunnel interfaces. Tunnel interfaces are logical interfaces which are configured in the same manner as physical or loopback interfaces. Since the tunnel interfaces are behaving as point-to-point interfaces the IP addresses configured on both sides must be in the same subnet. When setting up the GRE tunnel each side must specify a source and a destination. The IP address of the source on side A of the tunnel must match the IP address of the destination on side B of the tunnel and vice versa.

IP reachability between the tunnel endpoints is critical otherwise the GRE tunnel will not come up. The GRE tunnel interface comes up as soon as it is configured and it stays up as long as there is a valid tunnel source address or interface which is up. When a packet is sent through the GRE tunnel it gets encapsulated with a GRE header and an outer IP header and these headers are removed when the packet exits the GRE tunnel. GRE tunnels are designed to be completely stateless. This means that if one side of the tunnel goes down the other side might remain up because it cannot detect if the remote tunnel endpoint is unreachable. In this situation packets that go through the GRE tunnel will be dropped. Fortunately there is a solution for this issue by enabling keepalives on both sides of the tunnel. We’ll discuss this in more detail in the troubleshooting section.

Initial IP configuration and routing

First let’s proceed and configure the IP addressing and routing. Below is the topology I will use to demonstrate how GRE tunnels work. In order to simplify the routing I have used OSPF as the routing protocol and configured all the routers to be in the same area 0. Hosts PC1 and PC2 will be used to test reachability through the GRE tunnel.

The IP addressing scheme is configured as displayed in the topology above. We will assign an router ID (RID) following a simple scheme (i’ll use 1.1.1.1 for R1, 2.2.2.2 for R2 and so on) and then enable OSPF on all interfaces in area 0. Below is the OSPF configuration snippet for all four routers.

As you can see router R1 can reach router R4. The goal of this configuration is that host PC1 can reach host PC2 and viceversa via the GRE tunnel.

Creating a GRE tunnel

First we need to create two tunnel interfaces one (Tunnel1) on router R1 and the other (Tunnel2) on router R4. The tunnel will be established between these two routers. The tunnel interfaces on both routers must always be configured with an IP address that needs to be from the same subnet. In my topology, both tunnel interfaces will use IPs from 172.30.1.0/30 network. Let’s create and configure the Tunnel1 interface on router R1.

After we complete the tunnel configuration, the router will confirm the creation of the tunnel by displaying a message on the console similar to the one below.

*Jun 1 13:56:54.588: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

Since GRE is encapsulating protocol this adds some extra overhead to the original packet and can cause fragmentation. In this case we can adjust the maximum transmission unit (MTU) value to 1400 bytes and maximum segment size (MSS) to 1360 bytes. TCP MSS defines the maximum amount of data that a host is willing to accept in a single TCP/IP datagram and it’s usually 40 bytes less than the MTU of the interface. Using a value of 1400 is a common practice and will ensure unnecessary packet fragmentation is kept to a minimum. A similar configuration needs to be applied for interface Tunnel2 on router R4 with the exception that the tunnel source and destination are reversed.

GRE tunnels doesn’t provide encryption, but we can provide a key on each side of the tunnel by using the tunnel key command.

R1(config)# interface Tunnel1
R1(config-if)# tunnel key 100

R1(config)# interface Tunnel2
R4(config-if)# tunnel key 100

This can be thinked as a simple clear-text password authentication mechanism with no encryption. Tunnel ID keys are locally configured and can be used as a form of weak security to prevent improper configuration or injection of packets from a foreign source. They need to match on both sides. It’s not recommended to rely on this key for security purposes, instead you can use IPsec to protect GRE tunnel traffic.

At this point, both tunnel endpoints and should be able to communicate between them. Let’s test this by running a ping from router R1 using Tunnel1 as source to the IP address of the Tunnel2 interface on router R4.

As we can see the test is successful. Although the GRE tunnel is up hosts PC1 and PC2 are still not able to communicate yet. We need to setup a static route on both endpoints. On router R1 we need to add a static route to the remote network 192.168.20.0/24 via Tunnel1 interface which connects the remote end of our GRE Tunnel. Therefore, when R1 receives a packet destined for 192.168.20.0 network, it knows that the exit interface is Tunnel1 and it will route the packet through the GRE tunnel.

R1(config)# ip route 192.168.20.0 255.255.255.0 Tunnel1

The same configuration must be repeated for R2:

R4(config)# ip route 192.168.10.0 255.255.255.0 Tunnel2

Now both hosts PC1 and PC2 should have full reachability over the GRE tunnel.

GRE tunnel verification and troubleshooting

We can check the operational status of the tunnel interface using the show interfaces Tunnel command. Let’s check the status of Tunnel1 interface on router R1.

The output of this command displays a lot of useful information for troubleshooting and debugging. I have highlighted in red the most important lines from the output. We can see that the Tunnel1 interface is up and the transport protocol is GRE. Also we can see the source and destination endpoints and the fact that traffic is being passed in both directions. Let’s run some tests to verify reachability between hosts PC1 and PC2. First let’s ping PC2 from PC1.

From the traceroute output we can see that the path goes through the GRE tunnel. Since GRE tunnels are stateless, by default they cannot detect the operational status of the remote tunnel interface. So if one interface can go down while the other side remains up. We can resolve this by enabling keepalive packets on each side of the tunnel. By doing this, each side of the tunnel periodically sends a keepalive to the other side. If one side doesn’t receive a keepalive in the specified time, the tunnels go down on each side. Let’s configure both interfaces to send keepalives at every 30 seconds.

R1(config)# interface Tunnel1
R4(config-if)# keepalive 10 3

R4(config)# interface Tunnel2
R4(config-if)# keepalive 10 3

We configured both tunnel interfaces to send 3 keepalives at interval of 10 seconds. In this case if 3 keepalives are missed after 30 seconds the interfaces status should go down. From the output of the show interface Tunnel command we should see that keepalives have been set.

Let’s simulate a failure by shutting down interface Gi0/1 on router R3. After 30 seconds both tunnel interfaces will go down and the following message will be displayed on the router console.

*Jun 1 19:26:14.358: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down

If we check the operational status the interfaces it will display that the line protocol is down.

R1#show interface tunnel 1 | include Tunnel1
Tunnel1 is up, line protocol is down

Some things to keep in mind when troubleshooting GRE tunnels:

make sure the source and destination tunnels are setup correctly

if using tunnel keys check that they match on both sides

check the routing tables for missing routes

check for any access lists blocking GRE traffic

Summary

In this article we discussed basic concepts and configuration of GRE tunnels. GRE is used as the core protocol for DMVPN which allows you to build scalable networks where a single tunnel interface can be used to reach numerous remote sites. In situations where encryption is needed GRE can be used in conjunction with IPsec to protect the traffic for security reasons.