GRE stands for Generic Routing Encapsulation. As the name implies, it is a mechanism or tunneling protocol that permits the encapsulation of many different IP protocols inside an arbitrary transport protocol. It can be used for a number of things such as:

*Provide multi-protocol local networks over a single-protocol backbone
*Provide workarounds for limited hop counts networks. A RIP based network could be an example (15 max hop)
*Provide bridging of discontinuous sub-networks
*Allow VPN accross WAN

In this section, we will use IP as both the delivery and payload protocol. Let’s use the following topology to demonstrate how to configure GRE tunnels…

So what we have here is a Company named “RouteLeak” that needs to be directly connected to one of its Branch offices. They are both connected to the Internet Service Provider and the IP addresses are pre-configured. Let’s check the routing table of both “RouteLeak HQ” and “RouteLeak Branch”…

As you can see here, the only component routes in our main routing table are the connected routes. Let’s check the Branch Office router…

Same goes here ! Our endgame is to have a direct link between the HQ and the Remote Office via GRE tunnel and advertise our internal prefixes (Loopback IPs) through the GRE tunnel. Let’s discuss a bit about GRE before we hop into the consoles again.

It’s important to note that GRE tunnel is a basic non-negotiated tunnel meaning you have to specify a source as well as a destination address. GRE only needs tunnel endpoints and it only has 4 to 8 bytes of overhead.

There are 2 modes of GRE tunnels:
*Point-to-Point (GRE)
*Point-to-Multipoint (mGRE) – We will see that in the DMVPN post

To basically define the interface of a GRE tunnel, you will need the following:
*An IP address
*A tunnel source
*A tunnel destination

Let’s now hop back onto the consoles and configure our GRE tunnels. The network range we will be using is 10.1.1.0/30. We will then fine tune it…

All right, we have our tunnel IP address in as well as the tunnel source and tunnel destination addresses which are the interfaces facing the Service Provider.

I wanted to bring something to your attention though. Have you notice that when specifying the tunnel source, you have many options and one of them is to use a loopback address as your tunnel source. In our case, it really does not matter because we only have a single ingress/egress point. But if you have a network with multiple ingress points, you can specify a loopback address as your tunnel source and let’s say your primary link goes down and your secondary picks up; your tunnel will still be up because you will still have a route to the loopback address.

All right, let’s check the configuration on the router at the Branch Office and also see if our tunnel is up. Note that if one tunnel is down on 1 side, it will also be down on the other. Let’s check…

Ok ! The tunnel configuration seems to be okay but the state of the protocol is “down”. This is not good ! Any idea why ?

Well, in order for the tunnel to come up you have to have a component route to the destination address. Let’s check to see if we have the destination address in our routing table and if we can ping it from the source address. Let’s start from the router at the HQ…

As you can see here, we do not have a route to 172.16.23.3. Let’s configure a static route to point to the ISP router for 172.16.23.3/24…

All right, let’s do the same for 172.16.12.1/24 on the router at the Branch Office…

All right ! Let’s check to see if we can ping the WAN interfaces from both routers…

We can ping them ! Note that in our case here, you don’t need to specify a source interface when pinging the opposite WAN interface because your closest egress point is the actual WAN interface on the router you are on anyway. If your tunnel source was a loopback address for instance, you would definitely need to specify the source address when pinging the opposite source address. But it is good habit to specify it anyway.

Good ! At this point, our GRE tunnels should be up. Let’s check…

Very good ! Our GRE tunnels are up and running and we can ping across. If we check the routing table, we should see them as directly connected. Let’s check…

Very good ! Let’s now fine tune our GRE tunnel…

For the purpose of this lab, we set the bandwidth of the tunnel to 1Mbps and the delay to 1000 msec. Note that when configuring the delay metric, the input variable is in tens of msec. If you look closely, we have “delay 100” which is 1000msec. You can check that by running the command “sh int tu100 | inc DLY”.
The “ip tcp adjust-mss” command helps us avoid truncation by specifying the MSS value on the intermediate router of the SYN packets. The “load-interval” command adjust the window in terms of time for which data is computed for load statistics. I like to set the load interval for every 30 sec so I can see new stats every 30 sec such as bandwidth utilization and so on.
The “keepalive” is mainly used to bring down the line protocol of a tunnel because a configured tunnel does not have the ability to bring down the line protocol of either tunnel endpoint, if the far end is unreachable. The traffic sent from the tunnel is then black-holed.

Ok good ! I’ll configure the same feature at the remote side. Let’s then configure EIGRP and advertise our loopback addresses. We will need to make sure our loopback addresses are learned from the tunnel…

Looks Like we are solid at the HQ side. Let’s check the remote…

We are good ! Our GRE tunnels are up and both are learning internal routes through the GRE tunnels.

The following is the GNS3 file pertaining to this lab – You can download it here.

Quick Tips: There is a common issue related to GRE tunnels which is called “Recursive routing” where your tunnel interfaces keep flapping. This is due to the destination address being learned through the tunnel itself. Think of it as “If there is no telephone lines from Houston to Dallas, how am I making calls from Houston to Dallas ? The infrastructure (Route) needs to exist first (outside entity) before a call can be made through the lines”. In our case, we created static routes to the ISP and we ensured that the interfaces facing the ISP are not advertised in EIGRP. We just made sure that the router doesn’t reach the tunnel destination through the tunnel itself. There are a couple of ways you can design your network to avoid recursive routing. We will see those design cases in a later post.

In the troubleshooting section, we will see different implementation involving GRE tunnels but we should be good for now… I’ll talk to you guys later.