This article will discuss generic routing encapsulation (GRE), which is a type of IP tunnel. GRE is defined in RFC2784. This RFC defines a new header that is being used together with a new IP header to encapsulate the original data. In order to bring up a GRE tunnel, the two routers must agree on few parameters. It’s important to remember that a GRE tunnel doesn’t encrypt the packets. To encrypt the packets another tunneling protocol/feature has to be used, such as IPsec.

A GRE tunnel is a point-to-point logical connection. If you have multiple devices that need to be connected using GRE tunnels, then a separate tunnel has to be configured for each pair of devices.

The connection between the two devices through the GRE tunnel is done by means of the tunnel interfaces. The tunnel interfaces are configured with IP addresses that must be in the same subnet. This is no different than you would do with a physical interface.

The router between the tunnel is configured to encapsulate the original packet inside a tunnel header and a new IP header. The below diagram should give you a better understanding of how the router encapsulates the packet before it is sent through the tunnel interface:

Here the ingress interface is the interface from where the packets are received and the egress interface is the tunnel interface. As you can see, two new headers are added to the packet.

There can be static routes configured over the tunnel interfaces or even routing protocols can be configured to run over the tunnel interfaces. As mentioned already, the tunnel interfaces are behaving as point-to-point interfaces, hence the next-hop for the routes (either static routes or dynamically learned routes) will be the peer IP address configured on the tunnel interface on the remote router.

When a tunnel interface is being configured, several things are required (except the IP address):

  • tunnel source
  • tunnel destination
  • tunnel mode

The above ones are mandatory. Without any of them, the tunnel will not come up. Let’s discuss them.

The tunnel source is the IP address from which the tunnel will be initiated locally. This IP address has to match with the tunnel destination configured on the other router on the tunnel interface.

The tunnel destination is the IP address from which the tunnel session will be initiated. This IP address has to match with the tunnel source configured on the other router on the tunnel interface.

The tunnel mode specifies the GRE mode and it can be IPv4, IPv6 or multipoint.

It is crucial that, between the tunnel source and the tunnel destination, there is IP reachability. In both directions. If this condition is not met, then the GRE tunnel will not come up.

As a GRE tunnel can be established over the Internet, over which you don’t have any control, there might be firewalls in the middle that can drop GRE packets or have some policies that restrict traffic between your source and destination IP address of the tunnels. That’s why it is important to test reachability from both sides between the source and destination of the tunnels.

Let’s discuss our topology.

The tunnel is established between R1 and R3. On each router there is a tunnel interface configured with an IP address from the same subnet. The source and destination tunnel will be the IP addresses 1.1.1.X.

The goal will be to configure static routes through the tunnel interfaces so that the two hosts can ping each other.

This is the logical diagram of how R1 and R3 are connected.

In reality, they are connected like this:

As you can see, R1 and R3 are not directly connected. I’m using OSPF so that R1 will know how to reach the tunnel destination, 1.1.1.3 and R3 will know how to reach its tunnel destination, 1.1.1.1.

Instead of this OSPF area, you could have the Internet.

So let’s check the route table and confirm that we have the IP address that will serve as endpoints for the tunnel interfaces. On R1:

R1#show ip route ospf
     1.0.0.0/32 is subnetted, 3 subnets
O       1.1.1.3 [110/3] via 10.10.12.2, 00:22:58, FastEthernet1/0
O       1.1.1.2 [110/2] via 10.10.12.2, 00:22:58, FastEthernet1/0
     10.0.0.0/24 is subnetted, 2 subnets
O       10.10.23.0 [110/2] via 10.10.12.2, 00:22:58, FastEthernet1/0
R1#

Let’s test if we have reachability between 1.1.1.1 and 1.1.1.3 from R1:

R1#ping 1.1.1.3 source 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/42/68 ms
R1#

Everything looks fine, so if we were to configure GRE tunnels between R1 and R3, then should come up.

We explained earlier what is needed to bring up a GRE tunnel interface. This would be the configuration needed on R1:

R1#show running-config interface Tunnel0
Building configuration...

Current configuration : 115 bytes
!
interface Tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel source 1.1.1.1
tunnel destination 1.1.1.3
end

R1#

As you can see, we configured the IP address, the tunnel source and tunnel destination. By default, the tunnel mode is “gre ip,” hence is not shown here.

Similarly on R3, just that the tunnel source and destination are reversed:

R3#show running-config interface Tunnel0
Building configuration...

Current configuration : 115 bytes
!
interface Tunnel0
ip address 172.16.1.2 255.255.255.252
tunnel source 1.1.1.3
tunnel destination 1.1.1.1
end

R3#

Once we have configured them, let’s check if they are up. As you can see below, the tunnel interface is up and you can see that the mode is GRE/IP:

R1#show interfaces Tunnel0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.16.1.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 1.1.1.1, destination 1.1.1.3
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255

Having the tunnel up doesn’t mean necessarily that it can pass traffic. Let’s test if we can ping the IP address configured on the R3 tunnel interface:

R1#ping 172.16.1.2 source 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/23/24 ms
R1#

From the point of view of R1, it is directly connected to R3 through the tunnel interface.

For instance, 1.1.1.1 and 172.16.1.1 are both configured on R1. This is what a traceroute looks like when the corresponding IP address from R3 is being tested. This is for the loopback interface/tunnel destination of R3:

R1#traceroute 1.1.1.3 source 1.1.1.1

Type escape sequence to abort.
Tracing the route to 1.1.1.3

1 10.10.12.2 4 msec 24 msec 20 msec
2 10.10.23.3 36 msec 48 msec 24 msec
R1#

And now the IP address of the tunnel interface:

R1#traceroute 172.16.1.2 source 172.16.1.1

Type escape sequence to abort.
Tracing the route to 172.16.1.2

1 172.16.1.2 28 msec 72 msec 88 msec
R1#

Now let’s configure the two static routes, one on R1 and one on R3, for the two subnets where the hosts are connected.

This is for R1 to have reachability to 100.100.2.0/24:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip route 100.100.2.0 255.255.255.0 172.16.1.2
R1(config)#end
R1#sho
*Mar 1 00:38:15.647: %SYS-5-CONFIG_I: Configured from console by console
R1#show ip route static
100.0.0.0/24 is subnetted, 2 subnets
S 100.100.2.0 [1/0] via 172.16.1.2
R1#

And this is for R3 to have reachability to 100.100.1.0/24:

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip route 100.100.1.0 255.255.255.0 172.16.1.1
R3(config)#end
R3#
*Mar 1 00:38:59.643: %SYS-5-CONFIG_I: Configured from console by console
R3#show ip route static
100.0.0.0/24 is subnetted, 2 subnets
S 100.100.1.0 [1/0] via 172.16.1.1
R3#

Let’s test if PC1 can reach PC2:

PC1> ping 100.100.2.2
84 bytes from 100.100.2.2 icmp_seq=1 ttl=62 time=54.270 ms
84 bytes from 100.100.2.2 icmp_seq=2 ttl=62 time=49.945 ms
^C
PC1>

Everything is working as expected, so we solved the tasks.

While PC1 was pinging PC2, I took a packet capture on R1 showing what the packet that is being encapsulated looks like:

As you can see, the original packet (delimited by the source/destination IP 100.100.1.2/100.100.2.2) is encapsulated with a GRE header and a new IP header is applied, which has the tunnel source and destination (1.1.1.1/1.1.1.3).

Below you can see the GRE header:

As a comparison, you can see that when I’m pinging the loopback of R3 sourcing the packets from the loopback of R1, they are not encapsulated:

And that would be all about GRE tunnels. This topic is not that complicated and the configuration is pretty straightforward. You just need to know the exact steps with what needs to be configured.

Of course, things can get complicated if you decide to put IPsec on top of GRE, but careful and organized configuration can keep you out of problems.

Also, one needs to be making sure that there is IP reachability between the endpoints of the tunnel.

As a summary, we learned what the GRE tunnels are, what are the requirements, what are the configuration steps and how to check their status.

References

  1. Cisco CCNA Routing and Switching ICND2 200-101 Official Cert Guide – Wendell Odom
  2. How to configure a GRE tunnel