Thursday, February 2, 2012

Visualizing tunnels - inside GRE Tunnel Flow

Visualizing tunnels

When I was first introduced to tunnel interfaces, it took me a while to work out a solid visualization in my mind. Referencing documentation on the topic at the time probably would have sped things along considerably, but I digress. For the novice, I suggest thinking of a tunnel interface as simply adding or removing protocol headers, rather than transmitting packets. Consider the following illustration.
Routers 1, 2, and 3 are physically connected in series using point-to-point links in the range. A tunnel between routers 1 and 3 is configured and addressed as R1 has been configured to source the tunnel from its physical interface FastEthernet0/0, with the destination address of R3's interface.
hostname R1
interface Tunnel0
ip address
tunnel source
tunnel destination
interface FastEthernet0/0
ip address
R3's configuration is a mirror image of R1:
hostname R3
interface Tunnel0
ip address
tunnel source
tunnel destination
interface FastEthernet0/0
ip address
R1 and R3 both view the network as directly connected. Because we didn't specify a tunnel type in our setup, GRE encapsulation (the default mode) is used.
R1# show interface tun0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is
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, destination
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255
Fast tunneling enabled
Although the tunnel terminates at a (virtual) interface, it isn't responsible for obtaining layer two adjacency information or for transmitting packets. Instead, packets routed into or out of a tunnel interface have a protocol header added or removed, respectively. Consider what happens when R1 receives a packet to be routed through the GRE tunnel.
  1. A packet is received on or sourced from R1.
  2. A routing decision is made, and the packet is forwarded "out" the tunnel interface.
  3. The tunnel interface encapsulates the packet with a new IP header and a GRE header. Its destination IP address is that of the tunnel destination (
  4. A second routing decision is made to determine the new packet's outbound interface based on the outermost IP header.
  5. The packet is transmitted out the appropriate physical interface.
Having illustrated the outbound tunnel process, it's simple to reverse the flow and examine the inbound process.
  1. A packet is received on R3's physical interface.
  2. A routing decision determines that the destination address belongs to R3.
  3. The router recognizes the destination IP address and GRE header as belonging to the tunnel interface. The tunnel interface removes the outer IP and GRE headers, and the original IP packet is sent back "in" to the router.
  4. A second routing decision is performed based on the original destination IP address.
  5. The IP TTL is decremented by one and the packet is transmitted out the appropriate interface.
Note that R2 never sees packets destined to or from the subnet, only for the tunnel endpoints and There are other, more interesting modes of tunnel encapsulation, such as IPv6-in-IP and IPsec, but the general flow remains the same.

No comments:

YouTube Channel