Lesson Contents
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:
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:
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: