How to configure GRE Tunnel on Cisco IOS Router

Tunneling is a concept where we put ‘packets into packets’ so that they can be transported over certain networks. We also call this encapsulation.

A good example  is when you have two sites with IPv6 addresses on their LAN but they are only connected to the Internet with IPv4 addresses.Normally it would be impossible for the two IPv6 LANs to reach each other but by using tunneling the two routers will put IPv6 packets into IPv4 packets so that our IPv6 traffic can be routed on the Internet.

Another example is where we have an HQ and a branch site and you want to run a routing protocol like RIP, OSPF or EIGRP between them. We can tunnel these routing protocols so that the HQ and branch router can exchange routing information.

Basically when you configure a tunnel, it’s like you create a point-to-point connection between the two devices. GRE (Generic Routing Encapsulation) is a simple tunneling technique that can do this for us. Let me show you a topology that we will use to demonstrate GRE:

three cisco routers with tunnel

Above we have 3 routers connected to each other. On the left side we have the “HQ” router which is our headquarters. On the right side there is a “Branch” router that is supposed to be a branch office. Both routers are connected to the Internet, in the middle on top there is an ISP router. We can use this topology to simulate two routers that are connected to the Internet. The HQ and Branch router each have a loopback interface that represents the LAN.

Tunneling is a concept where we put 'packets into packets' so that they can be transported over certain networks. We also call this encapsulation. A good example  is when you have two sites with IPv6 addresses on their LAN but they are only connected to the Internet with IPv4 addresses.Normally it w


Let me show you the basic configuration of these routers so that you can recreate it if you want:

HQ(config)#interface fastEthernet 0/0           
HQ(config-if)#ip address 192.168.12.1 255.255.255.0
HQ(config-if)#exit
HQ(config)#interface loopback0
HQ(config-if)#ip address 172.16.1.1 255.255.255.0
HQ(config-if)#exit
HQ(config)#ip route 192.168.23.3 255.255.255.255 192.168.12.2
ISP(config)#interface fastEthernet 0/0
ISP(config-if)#ip address 192.168.12.2 255.255.255.0
ISP(config-if)#exit
ISP(config)#interface fastEthernet 1/0
ISP(config-if)#ip address 192.168.23.2 255.255.255.0
Branch(config)#interface fastEthernet 0/0
Branch(config-if)#ip address 192.168.23.3 255.255.255.0
Branch(config-if)#exit
Branch(config)#interface loopback 0
Branch(config-if)#ip address 172.16.3.3 255.255.255.0
Branch(config-if)#exit
Branch(config)#ip route 192.168.12.1 255.255.255.255 192.168.23.2

I created a static route on the HQ and Branch router so that they can reach each other through the ISP router. They will be unable to reach the networks on each others loopback interfaces however. Now let’s create a tunnel:

HQ(config)#interface tunnel 1     
HQ(config-if)#tunnel source fastEthernet 0/0
HQ(config-if)#tunnel destination 192.168.23.3
HQ(config-if)#ip address 192.168.13.1 255.255.255.0
Branch(config)#interface tunnel 1
Branch(config-if)#tunnel source fastEthernet 0/0
Branch(config-if)#tunnel destination 192.168.12.1
Branch(config-if)#ip address 192.168.13.3 255.255.255.0

You can pick any number for the tunnel interface that you like. We need to specify a source and destination IP address to build the tunnel and we’ll use the 192.168.13.0 /24 subnet on the tunnel interface. Let’s verify that our tunnel is working:

HQ#show interfaces tunnel 1
Tunnel1 is up, line protocol is up 
  Hardware is Tunnel
  Internet address is 192.168.13.1/24
  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 192.168.12.1 (FastEthernet0/0), destination 192.168.23.3
  Tunnel protocol/transport GRE/IP
Branch#show interfaces tunnel 1
Tunnel1 is up, line protocol is up 
  Hardware is Tunnel
  Internet address is 192.168.13.3/24
  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 192.168.23.3 (FastEthernet0/0), destination 192.168.12.1
  Tunnel protocol/transport GRE/IP

Above you can see that the tunnel interface is up/up on both routers. The default tunneling mode is GRE. Let’s see if both routers can reach each other:

Branch#ping 192.168.13.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.13.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/12 ms

There we go…they can ping each other without any issues! So that wasn’t too bad right? Let’s see if we can enable a routing protocol so that we can advertise the loopback interfaces. I’ll use EIGRP for this:

HQ(config)#router eigrp 13    
HQ(config-router)#no auto-summary 
HQ(config-router)#network 192.168.13.0
HQ(config-router)#network 172.16.1.0
Branch(config)#router eigrp 13
Branch(config-router)#no auto-summary 
Branch(config-router)#network 192.168.13.0
Branch(config-router)#network 172.16.3.0

I’ll activate EIGRP on the tunnel and loopback interfaces. You will see that both routers establish an EIGRP neighbor adjacency through the tunnel interface. Let’s check the routing tables:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 660 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

510 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: , ,


Forum Replies

  1. Hi Rene,
    Your post is very informative bro…keep it up!!

    Would you please help me understand what you really mean by this rule #1?
    (Don’t advertise the tunnel destination IP address on the tunnel interface. Don’t advertise it or use route filtering.)

    What if you used the network connected to R2 as the destination IP? like:

    R1(config)#interface tunnel 1
    R1(config-if)#tunnel source fa0/0
    R1(config-if)#ip address 192.168.13.1 255.255.255.0
    R1(config-if)#tunnel destination 192.168.23.3
    

    -

    R3(config)#interface tunnel 1
    R3(config-if)#tunnel source Fa0/0
    R3(config-if)#
    ... Continue reading in our forum

  2. Hi Rene,
    Very interesting post and topics.

    please woul you give me more details on the 1st rule you listed to fix the issues? (Don’t advertise the tunnel destination IP address on the tunnel interface. Don’t advertise it or use route filtering)

    What if we set the tunnels this way below, would we have the same rr issue?

    R1(config)#interface tunnel 1
    R1(config-if)#tunnel source fa0/0
    R1(config-if)#ip address 192.168.13.1 255.255.255.0
    R1(config-if)#tunnel destination 192.168.23.3
    

    -

    R3(config)#interface tunnel 1
    R3(config-if)#tunnel source Fa0/0
    R3(config-if)#ip 
    ... Continue reading in our forum

  3. Hi Thom,

    In my example, R1 and R3 learn about each others tunnel destination IP address through R2 with a hop count of 2.

    Once the tunnel is established, they learn about each others destination IP address through the tunnel with a hop count of 1.

    Since 1 is a better metric than 2, they remove their entry from the routing table that points to R2 and insert an entry that points to the tunnel interface.

    The tunnel now collapses…because we are trying to reach the tunnel destination through the tunnel itself. The same problem will occur if you configure OSPF on the

    ... Continue reading in our forum

  4. Hi Rene, thank you for the excellent post.

    And if I’m running OSPF instead of RIP, how could I solve this situation since my tunnel has a lower cost than my physical interfaces?

    I tried to filter the tunnel destination address (LSA3) with distribute-list IN on the tunnel interface, but it didn’t work. Any idea?

    Thanks!

  5. I got “recursive routing” before applying the offset command.

    However ; I noted that traceroute works, before and after applying offset. It, also, displays the same result (below).

    **R1#traceroute 3.3.3.3**
    
    Type escape sequence to abort.
    Tracing the route to 3.3.3.3
    
      1 192.168.12.2 56 msec 8 msec 12 msec
      2 192.168.23.3 20 msec 20 msec 20 msec

30 more replies! Ask a question or join the discussion by visiting our Community Forum