How to configure GRE Tunnel on Cisco IOS Router

Hello Michal.

Thank you very much. I haven’t had full understanding before.

According your explanation and Cisco guides DF bit plays central role in PMTUD (DF-bit is a feature of PMTUD). ICMP carries DF-bit. If I’m wrong let me know please.

DF bit is bit in IPv4 header, NOT in ICMP header. Exactly there it is.

When DF bit is set to 1 it tells the router that fragmentation of this ip packet is NOT allowed.

If router receives packet that has, lets say 1500 bytes, on ingress interface and packet has to be forwarded to egress interface that has for example 1400 bytes ip mtu, this would normally result in packet fragmentation in case DF bit was set to 0. But in case when DF bit is set to 1 then fragmentation of this packet is prohibited and router that needs to fragment the packet uses ICMP to let the originator of this big packet know, that he cant forward the packet because it is “too big” and would need to fragment it in order to forward it, but fragmentation is prohibited by DF bit.

Because GRE encapsulation creates new IPv4 outter header, DF bit would be set to 0 by default. But when we want to prohibit fragmentation on GRE tunnel path itself we should copy DF bit that is set to 1 in original IP header to outter IP header. This is done using “tunnel path-mtu-discovery” command in tunnel interface.

ICMP messages are just used as mechanism how to tell the originator of ip packet that he needs to lower packet in size othervise packet needs to be fragmented.

Hello Michal
Thanks for great explanation.

Hi Rene,

Thanks for the detailed explanation for the GRE Tunnel.
I have one question regarding the tunnel.
Even though we configured int tunnel 1 on HQ and Branch, the real flow for the packet is still going from HQ -> ISP -> Branch right? I’m kind of confused about this part.

It will be great if you could explain a little bit more. Thank you.

Hello Po

Yes you are correct. The actual packet does travel from HQ to ISP to Branch, however, the packet itself is only routed at HQ and Branch.

Think about it this way. Your packet is a car which is driving on the road. It gets to the port (HQ) and boards a ferry boat (encapsulated in the GRE tunnel). The ferry boat deals with all of the navigation between the start port and the destination port (Branch). The car doesn’t have to do any driving, or deal with traffic, or move in any way, the ferry takes care of all of that, taking the route that it knows (via ISP). Once the ferry reaches the destination port (Branch) the car disembarks and drives under its own power to get to where it wants to go.

From the car’s point of view, it travelled directly from HQ to Branch, and it knows nothing of the path and navigation needed by the ferry to reach that point, and it doesn’t really care about it either.

I hope this has been helpful!

Laz

2 Likes

That’s a really good example. It really helps me understand. Thank you.

1 Like

Hi Guys,

I’m curious.
What would the configuration need to be , so that i could have PC’s at both the HQ and Branch sitting in the same broadcast domain using GRE tunnel?

GRE allows broadcast\multicast yes ? Theoretically i could have them in the same broadcast domain and get DHCP etc from the same server (i know DHCP relay etc would be prefferd) but curious how i would set this up.

Hello Josh

A GRE tunnel must terminate on both ends on a router. Routing must take place at both ends of the GRE tunnel, so you cannot have the same subnet at both ends and have communication between those sites using only L2. You may be able to achieve this by actually creating two subnets on either end with the same IP address range and send packets over the trunk and change the IP addresses being used by implementing NAT, but this is not a recommended or elegant solution.

The correct solution for the problem you are describing is to use Layer 2 Tunnel Protocol (L2TP) which has been created exactly for this purpose, to extend an L2 subnet/broadcast domain between remote sites over a third party network such as the Internet. More information about this can be found at the following lesson:

I hope this has been helpful!

Laz

Thank you Laz ! I will definitely have a look through that lesson.
Do you have any information on EoGRE by any chance? i could only find limited information when searching online about the specifications.

On site recently i noticed that some Huawei gear is using some sort of EoGre tunneling which is basically mapping virtual interfaces and passing multiple vlans via a trunk.
Is this some sort of L2TP also?

Hello Josh

EoGRE does indeed perform a similar function to L2TP as it tunnels ethernet frames over a GRE (L3) tunnel. From my brief research Huawei does indeed implement it as an alternative to L2TP, but for most cases, and most vendors (including both Cisco and Huawei) EoGRE is a relatively new aggregation solution for aggregating Wi-Fi traffic from hotspots. Cisco describes it like this:

Ethernet over GRE (EoGRE) is a new aggregation solution for aggregating Wi-Fi traffic from hotspots. This solution enables customer premises equipment (CPE) devices to bridge the Ethernet traffic coming from an end host, and encapsulate the traffic in Ethernet packets over an IP GRE tunnel. When the IP GRE tunnels are terminated on a service provider broadband network gateway, the end host’s traffic is terminated and subscriber sessions are initiated for the end host.

You can find out more about Cisco;s EoGRE implementation at the following link:

I hope this has been helpful!

Laz

Hi,

why would we want to create a GRE tunnel in the reall world?, what are some reall world examples?, or do we use IPsec instead?

Hello Walter

GRE as a technology is rarely used alone due to the fact that it has no security features whatsoever. If you create a GRE tunnel over the Internet, you’re in for a rude awakening. The only time you would use a GRE tunnel alone is if it is over a network that you already administrate (your own WAN network?), and that you are sure is safe due to security measures that you have applied.

GRE is very useful because it supports multicast, something that is necessary for routing protocols and other applications to function correctly. This is a feature that is not available on a pure IPSec tunnel.

But GRE is a technology that is widely used in conjunction with other technologies. IPSec can be used to encrypt a GRE tunnel, something that is further described in the following lesson.


Similary, DMVPN is a technology that relies heavily on GRE, specifically, multipoint GRE (mGRE).

I hope this has been helpful!

Laz

2 Likes

Hi Laz,

Actually i am unable to understand why do we use GRE Tunneling any specific reason and advantage ?

Hello Pradyumna

GRE tunneling allows you to extend or span your private network across multiple sites, over a public network such as the Internet. It tunnels traffic so that from the point of view of the internal devices, communication between remote sites “look like” they remain in the network.

GRE tunnels are widely used, in conjunction with IPSec for encryption for point to point connections. GRE is also leveraged as multipoint GRE (mGRE) which is the primary feature used within the DMVPN framework.

I hope this has been helpful!

Laz

Hello Team,

I wanted to confirm something related to GRE Tunnels and VPNs.
When we talk about VPNs, should we always refer to GRE Tunnels?
GRE tunnels by default don’t provide encryption and I usually think that VPNs must provide security over an untrust network.
There are VPN services that provides security and privacy, all traffic is tunneled and we see ourselves with a different public IP address in the Internet, what type of VPN is this?

It is my understanding that when a router encapsulates a packet over a GRE Tunnel, it adds new header information to the packet which contains the source and destination endpoint IP addresses.
The source and destination IP addresses are part of the Transport network, underlay, in our case the Internet.
When the packet reaches the remote endpoint, the GRE header is removed and the original packet is forwarded out the remote router.
The original packet’s IP header is part of the overlay network, the tunnel network.
The tunnel interface’s line protocol won’t come up if there is no reachability between endpoints, I mean that tunnel interfaces are GRE P2P by default and the line protocol enters an UP state when the router detects a route to the tunnel destination endpoint.
Am I correct?
GRE P2P refers to Site-to-Site IPsec VPN?

The VPN term confuses me.

Regards,

Hello Luis

You bring up a very good point as far as terminology is concerned. The term VPN has unfortunately been used somewhat liberally, and to a certain degree, incorrectly, especially among marketing professionals.

Strictly speaking, a Virtual Private Network is a method of extending a private network across a public network. It’s original meaning had to do with connecting two or more remote private networks across a public network. It specifically involves the two (or more) ends of a VPN terminating at the customer premises. It doesn’t inherently include anything about security or privacy, although security is a best practice that should be implemented with VPNs.

Today there are several types of VPNs, some of which are closer to the original meaning of the term than others.

  1. VPNs that connect two or more remote sites extending their private network over a public network. This is also known as a Site-to-Site VPN. Technologies in this category at various levels of the OSI model include GRE tunnels, IPSec tunnels, DMVPNs, and Frame-Relay to name a few.
  2. VPNs that connect individual users to a corporate network using a VPN client, also called a remote access VPN. Some technologies used here include Anyconnet as well as other VPN clients, with a Cisco ASA or other security appliance.
  3. VPN Services, which are companies that allow you to securely connect to the Internet, and to hide your own IP address from the sites you visit. Strictly speaking, these are not VPNs. These are internet connection security services. They essentially allow you to connect to a “VPN server” somewhere on the Internet such that, that server becomes a relay or a proxy for all of your traffic. In other words, the sites and services you visit via that “VPN” see that server as the initiator of the communication, and not your own IP. This way you can (theoretically) hide your physical location, as well as any other network elements that can in any way associate you with that session.

Note that all of these technologies use some form of tunneling, which may warrant the use of the term VPN, but understanding the implications of the terminology is important.

To answer this question now, the answer is yes, because GRE (along with some other protocols) is the purest form of the original meaning of the term VPN. All the additional security features, and particulars of implementation and usage, are additions to this fundamental definition.

Yes, you are correct in your description, however, GRE doesn’t need any security (such as IPSec) to be considered a site-to-site VPN. Security should definitely be employed as best practice, but it is not part of the original VPN definition.

I hope this has been helpful!

Laz

Hello Everyone,

Can someone please explain how the ISP router treats the GRE header? There is no GRE configuration on this router. Does the router simply look at the packet, see that GRE is configured, and then forward it on?

Thanks again.

Hello Lee

The ISP router is oblivious to any GRE configuration. Actually, it doesn’t see the GRE information at all. It receives an IP packet with a regular IP header. The GRE information is found within the payload of that packet (including GRE headers, and encapsulated IP header information). As part of the payload of the IP packet, it remains untouched by the router. The ISP router will only decapsulate up to the outside IP header, will read the destination IP of 192.168.23.3 (in the case of communication from HQ to Branch) and will send it on its way.

The Branch router will also take a look at this header, and based on its configuration, will remove it and will then take a look at the GRE information found within that original packet, and will interpret it as a GRE tunnelled packet.

I hope this has been helpful!

Laz

Hi, I am new to Network Lessons but have been studying the Encor via the Official Cisco Book and a Udemy course but was struggling for motivation so decided to give Network Lessons a try . I have started with the GRE lesson and loved the explanation but didn’t see any information on things like GRE header format, GRE packet size overhead, Keep-alives, MTU size\fragmentation. Do we need this depth of knowledge to pass the ENCOR exam?.

Hello Andrew

It’s great to have you here, and we’re glad that you find the lessons helpful!

Unfortunately, there’s no way to know if a particular detail of a specific topic will be on the exam. Cisco has always been somewhat unclear on what may be included and what may not be included and they’ve done this by being very general in their exam topic lists. They state the following alongside their list of exam topics:

The following topics are general guidelines for the content likely to be included on the exam. However, other related topics may also appear on any specific delivery of the exam.

What can be considered a “related topic”? It’s not quite clear. However, you can get an idea of what detail you will need to know like so:

According to the ENCOR Exam Topics published by Cisco, there is only one topic covering GRE, and that is 2.2.b GRE and IPsec tunneling. This is one of seven topics found within the section called 2.0 Virtualization, which itself is 10% of the exam, as seen below.

From this, you can get an idea of the kind of detail that you will need to know for the exam.

To answer your specific question, I believe that you do not need to know details concerning the GRE header, packet size etc. Knowing this information is useful, but it is highly unlikely that it will be covered in the exam.

I hope this has been helpful!

Laz