GRE Tunnel Key

When you use the same source interface for multiple GRE tunnels, your router won’t know what tunnel to use to de-encapsulate packets. In this lesson, I’ll show you what happens and how to solve this issue with the tunnel key.

Configuration

Here is the topology we’ll use:

H1 H2 R1 R2 Two Gre Tunnels

Above, we have two GRE tunnels between R1 and R2. These are routers running IOSv Version 15.7(3)M3. R1 and R2 have a default route that sends all traffic through the Tunnel1 interface. Here are the configurations:

Configurations

Want to take a look for yourself? Here you will find the startup configuration of each device.

H1

hostname H1
!
no ip routing
!
interface GigabitEthernet0/1
 ip address 192.168.1.101 255.255.255.0
!
ip default-gateway 192.168.1.254
!
end

H2

hostname H2
!
no ip routing
!
interface GigabitEthernet0/1
 ip address 192.168.2.102 255.255.255.0
!
ip default-gateway 192.168.2.254
!
end

R1

hostname R1
!
ip cef
!
interface Tunnel1
 ip address 172.16.12.1 255.255.255.0
 tunnel source 192.168.12.1
 tunnel destination 192.168.12.2
!
interface Tunnel2
 ip address 172.16.21.1 255.255.255.0
 tunnel source 192.168.12.1
 tunnel destination 192.168.12.2
!
interface GigabitEthernet0/1
 ip address 192.168.1.254 255.255.255.0
!
interface GigabitEthernet0/2
 ip address 192.168.12.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 172.16.12.2
!
end

R2

hostname R2
!
ip cef
!
interface Tunnel1
 ip address 172.16.12.2 255.255.255.0
 tunnel source 192.168.12.2
 tunnel destination 192.168.12.1
!
interface Tunnel2
 ip address 172.16.21.2 255.255.255.0
 tunnel source 192.168.12.2
 tunnel destination 192.168.12.1
!
interface GigabitEthernet0/1
 ip address 192.168.2.254 255.255.255.0
!
interface GigabitEthernet0/2
 ip address 192.168.12.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 172.16.12.1
!
end

GRE Without Tunnel Key

Let’s send a ping from H1 to H2:

H1#ping 192.168.2.102 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.2.102, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 8/8/8 ms

The ping is successful. What tunnel interface did we use? Let’s have a look:

R1#show interfaces tunnel 1 stats
Tunnel1
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache          0          0          1        124
                   Total          0          0          1        124
R1#show interfaces tunnel 2 stats
Tunnel2
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache          1        124          0          0
                   Total          1        124          0          0

In the output above, you can see R1 transmits the ICMP request packet on its tunnel 1 interface. However, it de-encapsulates the ICMP reply on its tunnel 2 interface.

We can see a similar output on R2:

R2#show interfaces tunnel 1 stats
Tunnel1
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache          0          0          1        124
                   Total          0          0          1        124
R2#show interfaces tunnel 2 stats
Tunnel2
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache          1        124          0          0
                   Total          1        124          0          0

Above, we see that R2 receives the ICMP request on its tunnel 2 interface, but transmits the ICMP reply on the tunnel 1 interface.

Why is this happening? Let’s take a closer look at the GRE encapsulated ICMP request packet:

R1 R2 Gre Encapsulated Icmp Packet

GRE without key

In the packet above, there is nothing R1 or R2 can use to differentiate to decide which tunnel interface to use to de-encapsulate packets. This can be an issue. For example, you could have an access-list on tunnel 1 to deny certain packets. This doesn’t happen now because the routers use the tunnel 2 interface to de-encapsulate packets.

GRE With Tunnel Key

Let’s see if we can change this behavior. We can do this with the tunnel key command, which adds a 32-bit unique key ID to the GRE header. I’ll add a unique tunnel key on each tunnel interface:

R1(config)#interface Tunnel 1
R1(config-if)#tunnel key 1

R1(config)#interface Tunnel 2
R1(config-if)#tunnel key 2
R2(config)#interface Tunnel 1
R2(config-if)#tunnel key 1

R2(config)#interface Tunnel 2
R2(config-if)#tunnel key 2

Let’s clear the packet counters so we can take a fresh look:

R1#clear counters
Clear "show interface" counters on all interfaces [confirm]
R2#clear counters
Clear "show interface" counters on all interfaces [confirm]

Let’s send another ping:

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

If you like to keep on reading, Become a Member Now!

  • 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 800 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)
521 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
    How to change it to use second key instead the first key

  2. Hello Lam

    The choice of GRE key depends on the routing configured in each router.

    There are two GRE tunnels between R1 and R2 with specific IP addresses. The default route within R1 and R2 indicates which should be the next-hop IP. This next-hop IP is also what specifies which tunnel should be used.

    R1 has a default route to 172.16.12.2 and R2 has a default route to 172.16.12.1 so for all communication in both directions, Tunnel 1 should be used since tunnel 1 is on the 172.16.12.0/24 subnet.

    Without the GRE key, as you see in the lesson, either tunnel will b

    ... Continue reading in our forum

  3. HI Laz

    Thank, I now has clearer understanding.

    Regards

    Tan lam soon

  4. Hello Alex

    GRE tunnels by definition support multicast traffic. This is why GRE is often used to convey multicast traffic over a network that may natively not support it. This is useful also for routing protocols to function since they extensively use multicast to operate. The use of a tunnel key does not affect this support of multicast, so yes, you should be able to transmit multicast traffic over GRE tunnels that use a tunnel key.

    As for the two GRE tunnels in your lab, there’s really no reason for only one tunnel to be functional at any time. I’m inclin

    ... Continue reading in our forum

  5. What happend if i enable tunnel key on tu2 but no enable tunnel key on tu1. The dafault route stil to Tu1 . What happend?

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