How to configure a GRE tunnel


Tue, 12/13/2016 - 03:20
Jun 22nd, 2009
User Badges:
  • Gold, 750 points or more



Tunneling provides a mechanism to transport packets of one protocol within another protocol. The protocol that is carried is called as the passenger protocol, and the protocol that is used for carrying the passenger protocol is called as the transport protocol. Generic Routing Encapsulation (GRE) is one of the available tunneling mechanisms which uses IP as the transport protocol and can be used for carrying many different passenger protocols. The tunnels behave as virtual point-to-point links that have two endpoints identified by the tunnel source and tunnel destination addresses at each endpoint.


The below diagram shows encapsulation process of GRE packet as it traversers the router and enters the tunnel interface:



Configuring GRE Tunnel:


Configuring a GRE tunnel involves creating a tunnel interface, which is a logical interface. Then you must configure the tunnel endpoints for the tunnel interface.


To configure the tunnel source and destination, issue the tunnel source {ip-address | interface-type} and tunnel destination {host-name | ip-address} commands under the interface configuration mode for the tunnel.


The below example explain about how to create simple GRE tunnels between endpoints and the necessary steps to create and verify the GRE tunnel between the two networks.R1's and R2's Internal subnets( and are  communicating with each other using GRE tunnel over internet.Both Tunnel interfaces are part of the network.




First step is to create our tunnel interface on R1 and R2 :



R1(config)# interface Tunnel1

R1(config-if)# ip address

R1(config-if)# ip mtu 1400

R1(config-if)# ip tcp adjust-mss 1360

R1(config-if)# tunnel source

R1(config-if)# tunnel destination

R2(config)# interface Tunnel1

R2(config-if)# ip address

R2(config-if)# ip mtu 1400

R2(config-if)# ip tcp adjust-mss 1360

R2(config-if)# tunnel source

R2(config-if)# tunnel destination


Since GRE is an encapsulating protocol, we adjust the maximum transfer unit (mtu) to 1400 bytes and maximum segment size (mss) to 1360 bytes. Because most transport MTUs are 1500 bytes and we have an added overhead because of GRE, we must reduce the MTU to account for the extra overhead. A setting of 1400 is a common practice and will ensure unnecessary packet fragmentation is kept to a minimum.


After configuring tunnel,two tunnel endpoints can see each other can verify using an icmp echo from one end.

R1# ping

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:


Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms


Workstations on either network will still not be able to reach the other side unless a routing is configure on each router.Here We will configure static route on both router.


R1(config)# ip route

R2(config)# ip route


Now both networks ( and are able to freely communicate with each other over the GRE Tunnel .


Generic Routing Encapsulation (GRE)

Armando Yesua G... Wed, 12/02/2009 - 11:32
User Badges:
  • Cisco Employee,
Here is a sample config for GRE.

Consider the following topology

Router1 [S0]( ------ Internet -------([S0]Router2---
   |_( Tunnel____________________(|


interface Tunnel0
ip address
tunnel source
tunnel destination


interface Tunnel0
ip address
tunnel source
tunnel destination

And just apply the necessary routes for those tunnels:

for example

ip route Tunnel0

About Keepalives here is the information:

Router1(config)#interface Tunnel1

By default, this keepalive command sends a packet through the tunnel to check its status
once every 10 seconds. If there is no response to three successive polls, the router
declares the tunnel interface to be down. So, this will change the tunnel's status about
30 seconds after a failure.

You can adjust both the time interval and the number of retries. For example, to send a
keepalive packet every five seconds, but to keep the default three retry limit, you could
use the following command:

Router1(config)#interface Tunnel1
Router1(config-if)#keepalive 5
If you want to change the number of retries, you can specify the new value after the time
interval. The following example will send a keepalive packet every three seconds, and will
declare the tunnel down if it doesn't hear a response back to two successive keepalive

Router1(config)#interface Tunnel1
Router1(config-if)#keepalive 3 2
keithsauer507 Wed, 08/20/2014 - 10:09
User Badges:

Can you do this on an ehwic card?

I'm trying to simulate it in Cisco Packet Tracer Student 6.1 before rolling it into production.  Have a simulation of two 2811's with the same config as production on.

Issue when I go to specify the tunnel source it says Invalid input detected at '^' marker.  So running tunnel source ? shows it's looking for an interface name, not an ip address.

Well I have an HWIC card in the simulation and on Fa0/2/2 I have a cable going to another router where I am trying to gre tunnel over.  Issue is, if I specify Fa0/2/2 it says %ERROR: Source interface does not exist.  But clearly I can go into that interface and clearly I can ping the router connected to that interface!!!!

ashirkar Tue, 02/19/2013 - 22:19
User Badges:
  • Gold, 750 points or more

Dear Sachin,

Thanks for your feedback


Ashish Shirkar

(Community Manager-Network Infrastructure)

ashirkar Fri, 04/26/2013 - 02:56
User Badges:
  • Gold, 750 points or more

Hello Carlos,

Yes,you can also use dynamic routing ,Only endpoint should be reachable i.e your source and destination IP. Dynamic routing and tunnels combination can be a dangerous.You need to be careful when using a dynamic routing protocol bcoz it cause a GRE tunnel to avoid the recursive routing error message, which brings down the tunnel. This happens because the routers need to have a good path through the network to carry the tunnel to its destination.Make sure that the routers never get confused and think that the best path to the tunnel destination is through the tunnel can refer this documents for the same 

GRE - Recursive loops


Ashish Shirkar

Community Manager-NI

olufemi.bakare Thu, 11/14/2013 - 21:53
User Badges:

Thanks for this, but i want to ask, in your example, the internet ip addresses used, would one have to get them off an isp or one can just pick up any one?

tunnel source
tunnel destination

doxenhandler Mon, 12/02/2013 - 15:48
User Badges:

For use on the Internet, you need addresses that are assigned by an ISP or the registry appropriate to your country (ARIN, RIPE, etc.).

baydragon Fri, 01/17/2014 - 19:47
User Badges:

as long as both of them have the route of the addresses used in the tunnel source and destination.

Tom Teunissen Wed, 12/04/2013 - 02:46
User Badges:

I have an issue with a new GRE tunnel:

I can ping the tunnel source and destination addresses and the tunnel seems to be up, but I can't ping the endpoints...

I checked all configs and compared them to another working tunnel, maybe someone has an idea? :-)

cyberbench31 Wed, 01/06/2016 - 22:41
User Badges:

check the settings of your routing protocol, you should broadcast tunnel interface and not the public interface on you routing protocol..

sam.craven.01 Sun, 01/24/2016 - 13:06
User Badges:

I would look at your static/default route on both. That might be a reach but I have those statements on the configs that I am using.

I would also look at your ACL's, if any.

veneet.thakur Fri, 01/31/2014 - 04:35
User Badges:

Hi Tom,

If you the tunnel is up and you are able to ping the tunnel source & destination ips then there is definetly an issue with the routing which is configured for the endpoints, you should check if the routes are configured rightly.

thanks, Veneet

Tom Teunissen Fri, 01/31/2014 - 06:27
User Badges:


Thank you all for the possible answers. But it was another solution. Because of the tunnel vrf command I had left out. This would have worked if the used Loopback was part of the General/Generic/Unnamed vrf.

DCAT1S4-Edge#sh vrf

  Name                             Default RD          Protocols   Interfaces

  CustomerX                        6:6                 ipv4        Lo1541

  CustomerX-Q1541                  1541:1541           ipv4        Tu154128              


interface Tunnel154128

description CustomerX-V1541-Registration

ip vrf forwarding CustomerX-Q1541

ip address

ip mtu 1400

ip tcp adjust-mss 1360

tunnel source Loopback1541

tunnel destination

-> tunnel vrf CustomerX <-


Best regards, Tom

Eslam Tawfig Thu, 05/15/2014 - 20:50
User Badges:

Thank you so much for the information and the explanation. It was so simple and straight forward. wink

h_boulfrakh Thu, 08/27/2015 - 19:00
User Badges:

Hi , Tks for posting :)

But , 

I really want to know what I need as a prerequisite or special  configuration in the case of a GRE tunnel between two public IP address (two different wan) 


Configuration : 

R1 :

wan : @IP1 ..........@tunnel : dest : @IP2

R2 :

wan : @IP2...............@tunnel @IP1


it does not ping between points of tunnel  !!!!!!


Is what I need something from the provider?



Lost & Found Thu, 09/10/2015 - 04:03
User Badges:


Ive tried to configure Gre tunnel on out site 1 and 2 but both site has no connection. 

All tunnel interface status is UP/UP

from isp router 2 ip can ping the int tunnel IP but ISP router 1 can't ping it's own tunnel address.

Is it fine to run with s0/0 interface?

Router 2 - 2800 and router 1 - 2600

Do i need to setup OSPF to ping r1-r2? or just static configuration?

Please see the attached photo for the configuration.

clay.haynes Tue, 03/22/2016 - 09:53
User Badges:

This is blogspam and links to copyrighted material. This post should be removed.

aman7uela Thu, 06/23/2016 - 00:20
User Badges:

GRE can encapsulate other protocols. But how can you prove it? Can you please use routers as small as 3 to show me that?


This Document

Related Content