Today let’s go through a step-by-step guide on how to configure GRE Tunnels on Cisco devices.

 

 1- What is Generic Routing Encapsulation (GRE)?

GRE is an encapsulation protocol designed to initiate point-to-point connections able to carry any OSI layer 3 protocol over an IP network. Since it is a tunneling protocol, it can be deployed to connect discontinuous sub-networks, or provide workarounds for networks with limited hops.
GRE packets are identified within an IP packet by the protocol type 47.

An overhead of 24-bytes is added to the original packet by the GRE header. Consider reducing the MTU and MSS according to your needs to avoid packet fragmentation. E.g, if the real Ethernet interface has an MTU of 1500 bytes, then the MTU of the GRE Tunnel would be 1500 minus 24, or 1476 bytes. A common practice is to set the MTU to 1400 bytes.

As a result, we finally get the following:

 

 

If you consider deploying GRE in your production environment, be aware that it is not a secure protocol and that a security layer (e.g IPSec or PPTP) may need to be added.

For more information about GRE, please refer to the Cisco official documentation.

 

2- Deploying GRE Tunnels

For this demo, I will use two branch routers, Branch-1 and Branch-2 connected via an ISP. For simplicity reasons, I will assume that connectivity is already configured with BGP.

 

Unlike classic IPSec tunnels, where crypto-maps are created and applied to a physical interface, GRE tunnels are configured on a Tunnel interface. The endpoints of the IPSec Tunnel will be Branch-1 (192.168.0.1) and Branch-2 (192.168.0.2); they will use their Serial interface as the Tunnel source.

Note: The tunnel mode does not have to be set since single GRE over IP is the default mode.

 

Branch-1 Branch-2
interface Tunnel0
description Link to Branch-2
ip address 192.168.0.1 255.255.255.252
ip mtu 1476
ip tcp adjust-mss 1436
tunnel source Serial 0/0
tunnel destination 203.0.0.6
interface Tunnel0
description Link to Branch-1
ip address 192.168.0.2 255.255.255.252
ip mtu 1476
ip tcp adjust-mss 1436
tunnel source Serial 0/1
tunnel destination 203.0.0.2

 

Since GRE is an encapsulation protocol, the MTU and TCP MSS (Maximum Segment Size) have been reduced. This is an optimization, this step is not mandatory. By issuing the tunnel source command, the router will map the IP address of its Serial interface to the ‘source IP’ field of the GRE packet header. Likewise, the tunnel destination command will be used to fill the ‘destination’ field of the GRE IP packet header, therefore the forwarding decision will be made according to the entry present in the routing table for the corresponding endpoint. Having connectivity between the tunnel source and destination is crucial.

Now we can ensure that the Tunnel is up with the show commands:

 

Branch-1
Branch-1#show interfaces Tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Description: Link to Branch-2
Internet address is 192.168.0.1/30
MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
 Tunnel source 203.0.0.2 (Serial0/0), destination 203.0.0.6
 Tunnel protocol/transport GRE/IP

 

Once the Tunnel is functional, traffic can be redirected through it, either with static routes or by setting a routing protocol activated on the interface. In this example I have set up a very basic EIGRP relationship out of Tu0 with 192.168.0.2 as a neighbor.

 

Branch-1
10.0.0.0/24 is subnetted, 2 subnets
D 10.0.2.0 [90/297270016] via 192.168.0.2, 00:07:05, Tunnel0
C 10.0.1.0 is directly connected, FastEthernet0/0

Performing a Wireshark analysis is a great way to understand how technologies work and eventually troubleshoot.

Note: The source / destination IP given by Wireshark can be misleading since it highlights the encapsulated IP addresses instead of the GRE ones.

 

We can clearly see the different encapsulation layers, verify that a connectivity is established through the Tunnel and that endpoint addresses match the configuration we specified minutes ago. Also notice that the TTL value do not get decremented as it travels through the ISP.

Of course, since IPSec is not in place, we can clearly see the GRE payload. In the next topic we will see how to improve privacy by adding the framework in the game.

This article is intended to share knowledge. If you find something missing, or that should be improved, I would be pleased to add such information.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Let’s connect today

© 2019 Pierre Collard. All rights reserved. Solutions Architect Consultant at EVA GROUP.

Privacy Policy