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:

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:

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

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

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

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:

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: