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):
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, 22.214.171.124 and R3 will know how to reach its tunnel destination, 126.96.36.199.
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 188.8.131.52/32 is subnetted, 3 subnets O 184.108.40.206 [110/3] via 10.10.12.2, 00:22:58, FastEthernet1/0 O 220.127.116.11 [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 18.104.22.168 and 22.214.171.124 from R1:
R1#ping 126.96.36.199 source 188.8.131.52 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 184.108.40.206, timeout is 2 seconds: Packet sent with a source address of 220.127.116.11 !!!!! 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 18.104.22.168 tunnel destination 22.214.171.124 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 126.96.36.199 tunnel destination 188.8.131.52 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 184.108.40.206, destination 220.127.116.11 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, 18.104.22.168 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 22.214.171.124 source 126.96.36.199 Type escape sequence to abort. Tracing the route to 188.8.131.52 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 184.108.40.206/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 220.127.116.11/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 (18.104.22.168/22.214.171.124).
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.
Cisco CCNA Routing and Switching ICND2 200-101 Official Cert Guide – Wendell Odom
- How to configure a GRE tunnel