GRE Tunnels - Configuring and Verifying
Updated: Apr 12
VPN technologies is such an interesting topic to touch on for the CCNP route exam due to how complex one can configure it. In my experience, I have seen them in action with manage service providers and ISPs but during my time working for them, GRE tunnels was in the process of phasing out and to be replaced by MPLS circuits.Now this doesn't mean GRE tunnels are done for, it is still widely used in major businesses today. I'm glad I was able to get familiar with it before it was gone from our company. Now let us start on the basics of what a GRE tunnel is about and how to configure one. For my lab environment, I will be using the EVE-NG platform to simulate the lab below but GNS3 is perfectly fine to use to follow along. For the router image, I am using c3725-adventerprise9-mz.124-15.T14 image. If you need any references for the following subject, they are located at the bottom of this post. I will attempt to have the references for any topic at the bottom of every post from now on.
GRE stands for Generic Routing Encapsulation which is a tunneling protocol that provides a generic approach on transporting packets of one protocol over another protocol via encapsulation, such protocols as broadcast or multicast, as well as non-IP protocols. Understanding the basics on how to configure a GRE tunnel will be on the CCNP Route exam so please keep this in mind.
Here are a some brief information to know about GRE before tackling on some configuration examples. First, there are two things that assist with GRE tunnel traffic fragmentation: TCP MSS and PMTUD. TCP MSS(Maximum Segment Size) handles the fragmentation at two endpoints of a TCP connection while PMTUD was created in order to avoid fragmentation in the path between the endpoints. It is pretty much used to dynamically determine the lowest MTU size along the path to and from a packet's source as well as their destination. The next thing to know about GRE is how it works together with IPSEC. Naturally, GRE does not encrypt traffic at all so to combat this issue, we use IPSEC to encrypt the tunnel. One thing to remember about IPSEC, it does not support broadcast or multicast. With all this being said, let us continue on with basic GRE tunnel configurations as well as implementing IPSEC as well. Configuring IPSEC isn't on the CCNP exams but knowing how it works will definitely help. I will cover IPSEC in another post that way this one won't be as long winded.
We will be using the topology above to configure a basic GRE tunnel. I have the interface configs applied to the three routers as well as the loopback addresses. The configs are provided below.
Once the interfaces have been configured, we need to make sure all the routers can see each other. One way to do this is to use OSPF so that way all routers can connect to one another. (Using EIGRP is perfectly fine as well) I'll provide a small snippet of what I configured on each router. Now what I'm doing below is advertising the interfaces on each router using OSPF.
Now that OSPF has been configured, I tested connectivity between R1 and R3 by doing a ping test between those two routers. Ping results are listed above as well. We can now begin on creating a GRE tunnel. Before we begin creating the tunnels, remember that there are four tunnel states:
Up/up - This implies that the tunnel is fully functional and passes traffic. It is both administratively up and it's protocol is up as well.
Administratively down/down - This implies that the interface has been administratively shut down.
Up/down - This implies that, even though the tunnel is administratively up, something causes the line protocol on the interface to be down.
Reset/down - This is usually a transient state when the tunnel is reset by software. This usually happens when the tunnel is misconfigured with a Next Hop Server (NHS) that is it's own IP address.
When creating a tunnel interface and nothing has been configured on it, the interface is not shut by default. So during this part, the interface will show in an up/down status. The reason as to why it shows as an up/down status is because the interface has been administratively enabled but does not have a tunnel source or destination enabled, which brings the line protocol down. Of course, to bring the interface into an up/up status, we would need to configure the source and destination. We will use R1 as an example.
Below are the configs to bring the tunnel interface up/up. For the tunnel source, we would need an interface that is in the up/up status and has an IP address already configured on it. (It is recommended to source loopback interfaces to avoid physical link failures if they were to occur on the router but for this example only, I will use a physical interface) Sourcing an IP address, on the router itself is also valid. Now for the destination, we would need a valid IP address that is routable. Fun fact about the the tunnel destination IP address, it does not have to be reachable. Again, I will use R1 along with R3 as examples and will use the 10.1.1.0/24 address to configure the tunnel interfaces from the topology above.
We now have a working GRE tunnel between R1 and R3. By default, the tunnel is configured as a point-to-point GRE tunnel. If the tunnel is still in an up/down status there are three things that could be causing the issue:
There is no route to the destination address
The interface that is configured as the tunnel source is down
The route to the tunnel destination address is through the tunnel itself
As quoted by Cisco:
These three rules (missing route, interface down, and misrouted tunnel destination) are problems local to the router at the tunnel endpoints and do not cover problems in the intervening network or other features related to the GRE tunnel that might be configured. This document describes scenarios where other factors might influence the state of the GRE tunnel.
One last thing before I wrap up this post, with our GRE tunnel in an operational status, we can run a routing protocol over the tunnel itself. I will use EIGRP as an example to advertise the tunnel interface IP addresses and the loopback addresses. Below will be configs of both R1 and R3 on how I configured those two routers.
As seen above, both R1 and R3 are able to form a neighbor via EIGRP on their tunnel interfaces and they are advertising each other's loopback addresses as well. Using the show ip route eigrp command we are able to confirm that the loopback addresses are definitely being advertised and reachable.
This wraps up my post for GRE tunnels. I will probably continue writing about VPN technologies in the next few posts as I am preparing myself for the CCNP route exam.
Anyways, thank you for reading and until next time.