Hallo Rene ,
I configure Gre Tunnel on Gns3 and I have Configured Routing Protocol ( ospf, EIGRP ) but the Tunnel Interface is Flapping UP /down and Iget the Error ; … hold Timer Expired .
can you help me to solve this please ?
Hello Mohammad
The first thing that comes to mind when you talk about a GRE tunnel, dynamic routing, and a flapping tunnel interface involves the GRE Tunnel Recursive Routing error. This situation is further described in the following lesson:
Take a look and see if that helps you in your troubleshooting. If not, please let us know more details about your topology so we can help you further.
I hope this has been helpful!
Laz
Rene
I saw an example where the tunnel interfaces were used in the IP ROUTE command. Is there a disadvantage using the tunnel interfaces. The example is below. Thanks
CLI Command Examples
R1(config)# int tunnel 0
R1(config-if)# ip address 192.168.2.1 255.255.255.0
R1(config-if)# tunnel source g0/1
R1(config-if)# tunnel destination 201.150.200.6
R1(config-if)# tunnel mode gre ip
R1(config-if)# exit
R1(config)# ip route 192.168.3.0 255.255.255.0 192.168.2.2
R3(config)# int tunnel 0
R3(config-if)# ip address 192.168.2.2 255.255.255.0
R3(config-if)# tunnel source g0/1
R3(config-if)# tunnel destination 201.150.200.1
R3(config-if)# tunnel mode gre ip
R3(config-if)# exit
R3(config)# ip route 192.168.1.0 255.255.255.0 192.168.2.1
Hello Donald
The routing commands applied by Rene in the lesson and those applied by you in your example do two different things. So to answer your question, you should use the appropriate routing commands for what you desire to achieve.
Remember that when we are talking about GRE, we are talking about an underlay network and an overlay network. The underlay network is the bare network that has no specialized features applied except for routing so that all devices can reach each other. The overlay network is the GRE part of the configuration which involves the tunneled packets, and the private IP addressing scheme.
In the lesson, Rene used static routing to ensure that IP routing is available so that the underlay network can fully communicate. This ensures that the endpoints of the tunnel (the HQ and branch routers) can communicate, as this is a prerequisite for implementing the GRE tunnel. In your example, to achieve the same thing, you must ensure that routing is enabled between the 201.150.200.1 and 201.150.200.6 addresses. (If these are on the same subnet, you don’t need to configure any routing).
In your example, you are applying routing on the overlay network, making sure that the networks behind the routers at each end of the tunnel can reach each other. Rene achieved this using the EIGRP routing protocol in the lesson.
I hope this has been helpful!
Laz
GREat Lesson!!!
1 Like
Hello Giacomo
Thanks for the GREat feedback!
Laz
1 Like
in the gre tunnel course we talk about carrying the boadcat through the tunnel is there a configuration example? my goal is to bridge two remote lans using GRE. thank you all
Hello Giovanni
A GRE tunnel is capable of carrying both multicast and broadcast traffic. How this is done is described in a NetworkLessons Note on GRE tunnels. There is no specialized configuration necessary in such a scenario, you simply create the GRE tunnel, and it will transmit any broadcast or multicast traffic received on one end, to the other end. One example of such an application is if you want to create OSPF adjacencies of two routers over a tunnel. OSPF uses both broadcast and multicast to establish adjacencies, and this can be achieved over a GRE tunnel.
If you want to bridge two remote LANs using GRE, I suggest you take a look at this lesson, which includes the implementation of IPSec to secure the tunnel:
I hope this has been helpful!
Laz
1 Like
Hi,
So, the GRE tunnel can be located ad layer 3 protocol?
Is the same also for GRE with IPSEC ?
Does the tunnel between spokes provide L2 connectivity?
I have to clarify this doubts
Thanks 
Hello Giovanni
GRE is a tunneling protocol that is able to tunnel a variety of protocols. GRE itself requires Layer 3 connectivity between the tunnel termination devices, since the encapsulating headers have the destination IP address of the tunnel termination devices. What’s encapsulated inside can be IP, or it can be Ethernet, or a variety of other protocols. Therefore, GRE is able to tunnel both Layer 2 and Layer 3 protocols.
This is the case regardless of whether or not you are employing IPSec to secure GRE.
Since this is true, this means that you are indeed able to create a tunnel that will provide L2 connectivity across a Layer 3 network by tunneling Ethernet. You can find out more about how to tunnel Ethernet over GRE at the following Cisco documentation:
I hope this has been helpful!
Laz
Hello Laz,
Greetings.
Do OSPF or EIGRP best to use routing protocol in GRE tunnel?
else i am able to see while creating GRE tunnel, we’re able to reach each other loopback, on top of it we created GRE tunnels
BR//
Nitin Arora
Hello Nitin
Because GRE supports multicast, you are able to run whatever routing protocol you like through the GRE tunnel. Both EIGRP and OSPF work just fine over the tunnel.
I’m not quite sure what you mean here. Are you saying that without a routing protocol, you are able to ping the loopback of the other router? If there is no routing protocol, and no static routing, then HQ will not be able to ping the 172.16.3.1 L0 interface of the Branch router since it has no route to that destination. The other direction will also not be possible. The routing protocol (or static routing) is necessary. If I haven’t answered your question, can you please clarify?
I hope this has been helpful!
Laz
Hello, everyone!
I’ve read that IPSec by itself does not support multicast traffic which IGPs like OSPF use while GRE does support a variety of protocols and packets but does not provide encryption, so those two are often used in conjuction in WAN VPN connections over the internet.
Are there any use cases for just pure GRE without IPSec?
Thank you!
Hello David
Yes, this is true. A pure IPsec configuration on most Cisco devices does not support multicast so an alternative is to use GRE with IPsec to encrypt it.
The only use cases where you would use an unencrypted GRE tunnel is if you are not concerned about security. This would only be the case if either:
- the GRE tunnel is traversing a trusted private network where there is no security risk
- the GRE tunnel is carrying traffic of little or no security value, thus you don’t care if the link is eavesdropped upon…
Now I did say at the beginning that IPsec does not support multicast, but this is not completely true. Most Cisco implementations (and other vendors) don’t support it, but as a standard, it has been included in the IPsec RFC. Why it’s not typically included is explained in this NetworkLessons note about IPsec multicast support.
I hope this has been helpful!
Laz
1 Like
Helpful like always, thank you Laz and for this simple explanation!
1 Like
Hello Laz,
When configuring GRE, isn’t it best practice to configure the MTU and maximum segment size on the tunnel interface as below?
int tunnel0
ip address 10.1.1.1 255.255.255.0
ip tcp adjust-mss 1360
ip mtu 1400
tunnel source loop0
tunnel destination 2.2.2.2
Also, would it be better to use loopback interfaces to establish the tunnel source and destination as opposed to physical interfaces in case they go down?
Thank You Laz
Hello Paul
Yes, you’re absolutely correct. It’s a good practice to adjust the MTU as well as the TCP MSS values on the tunnel interface to prevent packet fragmentation. The values you’ve used are commonly recommended for GRE tunnels, however, it might vary depending on the specific network environment. Take a look at this NetworkLessons note on the topic.
As for your second question, yes, it is generally better to use loopback interfaces to establish the tunnel source and destination. The main advantage of using a loopback interface is its stability. A loopback interface is a virtual interface that is always up, unlike physical interfaces which can go down. Hence, even if a physical interface fails, the GRE tunnel will remain up as long as there is a valid routing path between the source and destination loopback interfaces.
I hope this has been helpful!
Laz
Laz - would you kindly have a look at the CML topology/config included in the screenshot.
It is not clear to me why the KEEPALIVE is not supported in this scenario. This little detail is contained as a “footnote” in the Cisco docu and caused me all sorts of grief before I realized the problem. The GRE tunnel refuses to go PROTOCOL UP if the KEEPALIVE is enabled in the GRE config.
GRE_VRF.txt (1.1 KB)
Hello Sandro
Hmm, this is an interesting one! The reason behind this restriction is the way that GRE keepalives are created, sent, and received.
Let’s take your scenario as an example. When R1 creates a keepalive, what it does is it first crafts the return packet, where it uses the IP address of R2 as the source IP and the IP address of R1 as the destination IP. Yes, that’s right, it’s not a typo. This premade keepalive response packet is then encapsulated within the keepalive request packet. This is how most keepalives work.
So when R1 sends its request, R2 simply decapsulates it and then routes it based on the IP and GRE headers. In a normal non-VRF situation, this works fine.
However, when VRFs are used, after the keepalive packet is decapsulated, it loses its association with the receiving tunnel interface and any VRFs configured on that tunnel interface. As a result, the remote endpoint attempts to route the packet using the global routing table instead of the VRF where the tunnel resides. This prevents the keepalive packet from being returned to the sender.
There is a workaround however! You can put a static route in the global routing table to allow the keepalives to be correctly routed back to the originating router. However, this assumes that the IOS will allow you to enable the keepalives which from what I see in your output.
I have created a NetworkLessons note with more information and with links to related material that I hope you and others will find useful. Thanks for this very interesting question which lead to me doing research and learning a lot more about this topic!
I hope this has been helpful!
Laz
1 Like
Laz - thank you very much for this explanation. I would never have guessed that the IOS essentially sends a “prepaid return envelope” packet as part of the keepalive mechanism.
The accompanying note you prepared with the links to the Cisco docu are excellent and very helpful.
PS
Let me close the loop on this topic with another question - I hope you will forgive me.
After I wrote to you with the original question about the keepalives, I tried another configuration where I repurposed a VRF-lite lab that I completed earlier this year.
The direction from my ENCOR training material suggested that it is a good idea to know how to configure a GRE tunnel with >> all << its asscoiated interfaces in the VRF. So this is why I attempted the configuration I sent you in the original note. However, using the VRFs in the manner shown in that lab was out of scope for the ENCOR objectives — whereas VRF-lite is included as an objective.
So this brings me to my question: (refer to the CML topologies)
- In the model with the GRE tunnel between CE (R3, R5) routers, everything works. However, the CE routers are “unaware” of the VRF.
- When I configure the GRE tunnel directly on the PE routers (R1, R2) shown in the other CML model, the tunnel protocol does not come up. Here, all the GRE related interfaces, Tu0, src/dst intf, are all in the CUST-A VRF.
I suspect the problem here is that I am attempting a GRE overlay on top of a dot1q overlay which is probably not allowed in IOS or does not even make any sense…but I do not know how to articulate the problem precisely. I would appreciate your thoughts on this.
