GRE Tunnels – Generic Routing Encapsulation

1. What Is GRE?

GRE (Generic Routing Encapsulation) is a tunnelling protocol defined in RFC 2784 that can encapsulate virtually any Layer 3 protocol inside an IPv4 (or IPv6) packet. A GRE tunnel creates a virtual point-to-point link between two routers across an existing IP network — making remote networks appear directly connected at Layer 3, even if they are separated by many hops.

GRE is called a generic encapsulation protocol because it is payload-agnostic. While IPsec can only encrypt unicast IP traffic, GRE can carry multicast, broadcast, routing protocol updates (OSPF hellos, EIGRP, BGP), IPv6 over IPv4, and non-IP protocols — making it the standard solution for running dynamic routing protocols across WAN links or the Internet.

Feature GRE IPsec (Transport / Tunnel Mode)
Payload support Any Layer 3 protocol — IP, IPv6, multicast, broadcast, routing protocols Unicast IP only (native); cannot carry multicast or routing protocol traffic
Encryption None — GRE provides encapsulation only, no confidentiality Strong encryption (AES, 3DES) — confidentiality, integrity, authentication
Overhead 24 bytes (4-byte GRE header + 20-byte outer IP header) Larger — ESP header + trailer + authentication data
Dynamic routing Yes — OSPF, EIGRP, BGP all work over GRE No — IPsec alone cannot carry OSPF hellos (multicast)
Typical use Site-to-site tunnels with dynamic routing; legacy WAN connectivity Encrypted site-to-site VPN; remote access VPN
Combined use GRE + IPsec = encrypted tunnel that also supports dynamic routing and multicast

Related pages: IPsec VPN | IPsec Basics | DMVPN | OSPF Overview | OSPF Configuration | EIGRP Overview | EIGRP Configuration | BGP Overview | Default Routes | Common Port Numbers (Protocol 47) | GRE Tunnel Configuration Lab | Site-to-Site IPsec VPN Lab

2. How GRE Encapsulation Works

GRE works by wrapping the original passenger packet (the data being tunnelled) with a GRE header and a new outer IP header. The resulting packet travels across the transit network addressed to the tunnel endpoint, where it is decapsulated and the original packet is delivered.

2.1 GRE Packet Structure

  Original packet (before entering the tunnel):
  ┌───────────────────────────────────────────────────────┐
  │  Inner IP Header  │  TCP/UDP  │  Payload Data         │
  │  Src: 10.1.1.1    │           │                       │
  │  Dst: 10.2.2.1    │           │                       │
  └───────────────────────────────────────────────────────┘

  After GRE encapsulation (sent across the transit network):
  ┌──────────────────┬─────────────┬───────────────────────────────────────┐
  │  Outer IP Header │  GRE Header │  Original (Inner) Packet              │
  │  Src: 203.0.113.1│  (4 bytes)  │  Inner IP │ TCP/UDP │ Payload Data    │
  │  Dst: 203.0.113.2│             │  Src:10.1 │         │                 │
  │  Proto: 47 (GRE) │             │  Dst:10.2 │         │                 │
  └──────────────────┴─────────────┴───────────────────────────────────────┘
        ↑                 ↑                  ↑
  Tunnel endpoints    Encapsulation     Passenger packet
  (public IPs)         header           (any L3 protocol)

2.2 GRE Header Fields

Field Size Description
C (Checksum Present) 1 bit If set to 1, a 16-bit checksum field follows to verify GRE header and payload integrity; disabled by default (adds overhead)
Reserved 12 bits Reserved for future use; must be zero
Ver (Version) 3 bits GRE version; always 0 for standard GRE (RFC 2784)
Protocol Type 16 bits EtherType of the encapsulated (passenger) protocol — e.g., 0x0800 for IPv4, 0x86DD for IPv6, 0x0806 for ARP
Checksum (optional) 16 bits Present only when C bit = 1; provides basic error detection
Reserved (optional) 16 bits Present only when C bit = 1; padding to align checksum field
Protocol 47: The outer IP header of a GRE packet uses IP Protocol number 47. This is distinct from TCP (6), UDP (17), or ESP (50). Firewalls and ACLs between tunnel endpoints must permit IP protocol 47 — not a port number — for GRE tunnels to function. A common misconfiguration is attempting to permit GRE by opening a UDP or TCP port, which has no effect.

2.3 Encapsulation Walk-Through

  Site A                   Internet (Transit)               Site B
  10.1.1.0/24                                            10.2.2.0/24
  Router-A                                               Router-B
  Tunnel source: 203.0.113.1                  Tunnel dest: 203.0.113.2

  Step 1: PC-A sends packet to PC-B
          Src: 10.1.1.10  Dst: 10.2.2.10  → routed to Router-A

  Step 2: Router-A matches route: 10.2.2.0/24 via Tunnel0 interface
          Encapsulates with GRE:
          Outer IP Src: 203.0.113.1   Outer IP Dst: 203.0.113.2
          GRE Protocol Type: 0x0800 (IPv4 passenger)
          Inner IP: original 10.1.1.10 → 10.2.2.10

  Step 3: Encapsulated packet routed across the internet to 203.0.113.2

  Step 4: Router-B receives packet (outer IP Dst = 203.0.113.2 = me)
          Identifies Protocol 47 (GRE) → decapsulates
          Delivers inner packet 10.1.1.10 → 10.2.2.10 to PC-B

  From Site A and Site B's perspective: they appear directly connected ✓

3. Why GRE Is Used for Routing Protocols and Multicast

The most important operational reason for choosing GRE over a plain IPsec tunnel is GRE's ability to carry multicast and broadcast traffic. This matters because all major dynamic routing protocols rely on multicast or broadcast to discover neighbours and exchange routes:

Routing Protocol Hello/Update Address Works over plain IPsec? Works over GRE?
OSPF 224.0.0.5 / 224.0.0.6 (multicast) No — IPsec drops multicast Yes — GRE encapsulates multicast as unicast to tunnel endpoint. See: OSPF Overview
EIGRP 224.0.0.10 (multicast) No Yes — see EIGRP Overview
RIPv2 224.0.0.9 (multicast) No Yes — see RIP Concepts
BGP Unicast TCP 179 Yes (unicast) — but no multicast extensions Yes — see BGP Overview
PIM (multicast routing) 224.0.0.13 (multicast) No Yes

When a router sends an OSPF Hello to 224.0.0.5 out the tunnel interface, GRE encapsulates the multicast packet as a unicast GRE packet addressed to the tunnel destination. The far-end router decapsulates it and processes the Hello normally — OSPF sees a point-to-point neighbour relationship over the tunnel. 

  OSPF over GRE Tunnel — Neighbour Formation:

  Router-A                    GRE Tunnel0                    Router-B
  Loopback: 1.1.1.1                                       Loopback: 2.2.2.2
  Tunnel IP: 172.16.0.1 /30                            Tunnel IP: 172.16.0.2 /30

  1. Router-A sends OSPF Hello to 224.0.0.5 on Tunnel0
  2. GRE encapsulates: inner dst=224.0.0.5 → outer dst=203.0.113.2 (tunnel endpoint)
  3. Router-B receives → decapsulates → processes OSPF Hello
  4. OSPF adjacency forms between 172.16.0.1 and 172.16.0.2
  5. OSPF routes exchanged — sites can now route dynamically ✓

4. GRE Tunnel Configuration

A GRE tunnel is configured using a tunnel interface on both routers. Each router needs to know the tunnel source (its own public IP) and the tunnel destination (the remote router's public IP). An IP address is assigned to the tunnel interface to create a virtual point-to-point subnet between the two endpoints.

4.1 Basic GRE Tunnel Configuration

  Topology:
  [Site A]──203.0.113.1──[Internet]──203.0.113.2──[Site B]
  Site A LAN: 10.1.1.0/24                    Site B LAN: 10.2.2.0/24
  Tunnel subnet: 172.16.0.0/30

  ! ══════════════════════════════════════════════════════════════
  !  Router-A Configuration
  ! ══════════════════════════════════════════════════════════════

  ! Physical WAN interface (facing Internet)
  interface GigabitEthernet0/0
   ip address 203.0.113.1 255.255.255.252
   no shutdown

  ! Tunnel interface
  interface Tunnel0
   ip address 172.16.0.1 255.255.255.252   ! Virtual tunnel IP
   tunnel source GigabitEthernet0/0         ! Can also be an IP address
   tunnel destination 203.0.113.2           ! Remote tunnel endpoint
   tunnel mode gre ip                       ! Default — optional to specify
   no shutdown

  ! Route to Site B LAN via the tunnel
  ip route 10.2.2.0 255.255.255.0 172.16.0.2
  ! OR use a dynamic routing protocol (OSPF/EIGRP) over the tunnel

  ! ══════════════════════════════════════════════════════════════
  !  Router-B Configuration
  ! ══════════════════════════════════════════════════════════════

  interface GigabitEthernet0/0
   ip address 203.0.113.2 255.255.255.252
   no shutdown

  interface Tunnel0
   ip address 172.16.0.2 255.255.255.252
   tunnel source GigabitEthernet0/0
   tunnel destination 203.0.113.1
   tunnel mode gre ip
   no shutdown

  ip route 10.1.1.0 255.255.255.0 172.16.0.1

4.2 Adding OSPF over the GRE Tunnel

  ! ── Both routers — add OSPF to form adjacency over the tunnel ──

  router ospf 1
   router-id 1.1.1.1                         ! Router-A: use 2.2.2.2 on Router-B
   network 10.1.1.0 0.0.0.255 area 0         ! LAN network
   network 172.16.0.0 0.0.0.3 area 0         ! Tunnel network (include both endpoints)

  ! OSPF over a GRE tunnel treats the tunnel as a point-to-point link.
  ! Default OSPF network type on tunnel interfaces is POINT_TO_POINT — correct.
  ! No DR/BDR election needed.

  ! Verify adjacency:
  Router-A# show ip ospf neighbor
  Neighbor ID  Pri  State     Dead Time  Address     Interface
  2.2.2.2        0  FULL/-    00:00:37   172.16.0.2  Tunnel0

4.3 GRE Keepalives

By default, a GRE tunnel interface is always up/up regardless of whether the far-end router is reachable. GRE keepalives send periodic probe packets through the tunnel; if no reply is received, the tunnel interface is brought down — preventing traffic from being blackholed into an unreachable tunnel. 

  ! Enable GRE keepalives (configured on one or both sides)
  interface Tunnel0
   keepalive 10 3
  !          ↑   ↑
  !       Period  Retries
  !    (send every 10 sec, down after 3 missed = 30 sec)

  ! Without keepalives:
  !   Tunnel0 shows up/up even if Router-B is offline
  !   Traffic routed into Tunnel0 is blackholed silently

  ! With keepalives:
  !   If Router-B goes offline → after 30 sec, Tunnel0 goes down/down
  !   Static routes via the tunnel withdraw or OSPF neighbour drops
  !   Traffic rerouted to alternate path (if available)

5. GRE MTU and Fragmentation

GRE adds 24 bytes of overhead to every packet (20-byte outer IP header + 4-byte GRE header). If the underlying network has a standard 1500-byte MTU, the effective MTU inside the GRE tunnel is reduced to 1476 bytes. Packets larger than 1476 bytes that arrive on the tunnel interface must be either fragmented or have the DF (Don't Fragment) bit cleared. 

  GRE MTU Calculation:

  Standard Ethernet MTU:    1500 bytes
  Outer IP header:           -20 bytes
  GRE header:                 -4 bytes
  ──────────────────────────────────────
  Effective GRE tunnel MTU: 1476 bytes

  With GRE + IPsec (ESP in tunnel mode):
  Outer IP header:           -20 bytes
  IPsec ESP header:          -8 bytes
  GRE header:                -4 bytes
  ESP trailer + auth:       ~-30 bytes
  ──────────────────────────────────────
  Effective MTU:            ~1418 bytes  (varies by cipher/auth algorithm)

  Best practice — set tunnel interface MTU explicitly:
  interface Tunnel0
   ip mtu 1476                  ! Reduces MTU to prevent fragmentation
   ip tcp adjust-mss 1436       ! Adjusts TCP MSS to prevent large TCP segments
                                 ! MSS = MTU - 20 (IP) - 20 (TCP) = 1436
ip tcp adjust-mss intercepts TCP SYN packets and rewrites the Maximum Segment Size option to prevent TCP sessions from negotiating a segment size that would result in packets exceeding the tunnel MTU. This is the most reliable fix for MTU-related issues over GRE tunnels — without it, large file transfers and HTTPS sessions may experience silent failure or retransmissions.

6. GRE + IPsec – Why They Are Used Together

GRE alone provides no security — traffic in the tunnel is plaintext. IPsec alone cannot carry multicast, broadcast, or routing protocol traffic. The combination of GRE + IPsec solves both problems simultaneously: GRE handles the encapsulation (including multicast and routing protocols), and IPsec encrypts the resulting GRE packets end-to-end. 

  GRE + IPsec Packet Structure:

  Original OSPF Hello (multicast 224.0.0.5):
  ┌─────────────────────────────────────────┐
  │  IP 224.0.0.5 │  OSPF Hello Payload    │
  └─────────────────────────────────────────┘

  After GRE encapsulation:
  ┌──────────────────┬──────────┬───────────────────────────────┐
  │  Outer IP header │  GRE hdr │  IP 224.0.0.5 │  OSPF Hello  │
  │  Src: 203.0.1    │  Proto47 │                               │
  │  Dst: 203.0.2    │          │                               │
  └──────────────────┴──────────┴───────────────────────────────┘

  After IPsec ESP encryption (GRE packet becomes the IPsec payload):
  ┌──────────────────┬──────────────┬───────────────────────────────────────┐
  │  Outer IP header │  ESP header  │  ENCRYPTED: GRE hdr + OSPF Hello     │
  │  Src: 203.0.1    │  (IPsec)     │  (confidential — transit cannot read) │
  │  Dst: 203.0.2    │              │                                        │
  └──────────────────┴──────────────┴───────────────────────────────────────┘

  Result: Encrypted tunnel that carries ANY traffic including routing protocols ✓

6.1 GRE + IPsec Configuration (IPsec Profile Method)

  ! ══════════════════════════════════════════════════════════════
  !  GRE over IPsec — IPsec Profile Method (recommended, modern)
  !  Applied directly to the tunnel interface
  ! ══════════════════════════════════════════════════════════════

  ! Step 1 — IKE Phase 1 Policy (ISAKMP)
  crypto isakmp policy 10
   encryption aes 256
   hash sha256
   authentication pre-share
   group 14
   lifetime 86400

  crypto isakmp key T@nnelK3y address 203.0.113.2   ! Router-A pre-shared key

  ! Step 2 — IPsec Transform Set
  crypto ipsec transform-set GRE-TS esp-aes 256 esp-sha256-hmac
   mode transport    ! Transport mode — GRE provides the outer IP header

  ! Step 3 — IPsec Profile (links transform set to tunnel interface)
  crypto ipsec profile GRE-PROFILE
   set transform-set GRE-TS

  ! Step 4 — Apply IPsec profile to the GRE tunnel interface
  interface Tunnel0
   ip address 172.16.0.1 255.255.255.252
   tunnel source GigabitEthernet0/0
   tunnel destination 203.0.113.2
   tunnel mode gre ip
   tunnel protection ipsec profile GRE-PROFILE   ! ← key command
   ip mtu 1400
   ip tcp adjust-mss 1360
   no shutdown

  ! Note: 'mode transport' is used because GRE already provides the outer
  ! IP header. IPsec only needs to encrypt the GRE packet content.
  ! If 'tunnel mode' were used instead, an extra IP header would be added.

6.2 When to Use GRE+IPsec vs Pure IPsec

Requirement Use GRE + IPsec Use Pure IPsec
Dynamic routing (OSPF, EIGRP) Yes — multicast routing hellos need GRE No — multicast not supported over plain IPsec
Multicast application traffic (video, PIM) Yes — GRE carries multicast payloads No
Simple unicast data encryption Can use either Simpler — fewer components, less overhead
IPv6 over IPv4 VPN Yes — GRE tunnel mode gre ipv6 or ip6ip Limited — requires IPv6-aware IPsec implementation
Non-IP protocol support Yes — GRE can encapsulate any protocol No — IPsec is IP-only
Overhead sensitivity Higher overhead (~54+ bytes with IPsec) Lower — no GRE header needed

7. Recursive Routing – A Critical GRE Pitfall

Recursive routing (also called a routing loop) is the most common and dangerous GRE misconfiguration. It occurs when the router tries to route the GRE outer IP packet (addressed to the tunnel destination) through the tunnel interface itself — causing the packet to be re-encapsulated infinitely until the TTL expires. 

  Recursive Routing Problem:

  Scenario:
    Tunnel destination: 203.0.113.2
    Static default route: 0.0.0.0/0 via Tunnel0  ← WRONG

  What happens:
  1. Router needs to send GRE packet to 203.0.113.2
  2. Looks up route: 0.0.0.0/0 → Tunnel0
  3. Tunnel0 needs to reach 203.0.113.2 (the tunnel destination itself)
  4. Looks up route: 0.0.0.0/0 → Tunnel0 → recurse → Tunnel0 → loop!
  5. Packet encapsulated endlessly until TTL = 0 → dropped

  Symptom: Tunnel0 goes up then immediately down with error:
  %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing

  Fix — ensure the tunnel destination is reachable via a route that does NOT
  use the tunnel interface:

  ! Correct — explicit route to tunnel destination via physical interface:
  ip route 203.0.113.2 255.255.255.255 GigabitEthernet0/0 203.0.113.254
  !                                     ↑ physical interface, not Tunnel0

  ! Then the default route can point to the tunnel (for remote LAN traffic):
  ip route 10.2.2.0 255.255.255.0 Tunnel0   ← safe, specific to remote LAN
Rule to prevent recursive routing: The tunnel destination IP must be reachable via a more specific route or via a physical interface — never via the tunnel interface itself. A common safe approach is to use a host route (/32) pointing to the tunnel destination via the WAN physical interface. This ensures the GRE outer packet always leaves via the physical interface, regardless of any default routes pointing into the tunnel.

8. Verification Commands

Command What It Shows
show interfaces tunnel0 Tunnel interface status (up/up), IP address, tunnel source, tunnel destination, encapsulation type, keepalive state, packets in/out
show ip interface brief Quick summary of all interface states — confirms Tunnel0 is up/up (or identifies if it is down)
show ip route Routing table — confirms routes learned/distributed over the tunnel; look for routes with Tunnel0 as next-hop interface
show ip ospf neighbor OSPF adjacency over the tunnel — state should be FULL for a working GRE+OSPF deployment
show ip eigrp neighbors EIGRP neighbour over the tunnel — confirms EIGRP adjacency via Tunnel0
show tunnel statistics Packet and byte counters for tunnel encapsulation and decapsulation; error counters for recursive routing and keepalive failures
show crypto ipsec sa IPsec Security Associations — confirms GRE+IPsec is encrypting/decrypting; shows packet counters for the SA
show crypto isakmp sa IKE Phase 1 SA state — should show QM_IDLE (active) for a working GRE+IPsec tunnel
ping 172.16.0.2 source 172.16.0.1 End-to-end ping across the GRE tunnel using tunnel IP addresses — confirms the tunnel is passing traffic
traceroute 10.2.2.1 source 10.1.1.1 End-to-end traceroute across the tunnel — should show tunnel endpoint as a single hop from Site A to Site B perspective

8.1 Sample Output – show interfaces tunnel0

  Router-A# show interfaces Tunnel0
  Tunnel0 is up, line protocol is up
    Hardware is Tunnel
    Internet address is 172.16.0.1/30
    MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
       reliability 255/255, txload 1/255, rxload 1/255
    Encapsulation TUNNEL, loopback not set
    Keepalive set (10 sec), retries 3, set in 00:12:44
    Tunnel linestate evaluation up
    Tunnel source 203.0.113.1 (GigabitEthernet0/0),
      destination 203.0.113.2
    Tunnel protocol/transport GRE/IP
      Key disabled, sequencing disabled
      Checksumming of packets disabled
    Tunnel TTL 255, Fast tunneling enabled
    Tunnel transport MTU 1476 bytes
    Tunnel transmit bandwidth 8000 (kbps)
    Tunnel receive bandwidth 8000 (kbps)
    Last input 00:00:02, output 00:00:02, output hang never
    Last clearing of "show interface" counters never
       5 minute input rate 2000 bits/sec, 3 packets/sec
       5 minute output rate 2000 bits/sec, 3 packets/sec
          12847 packets input, 1541640 bytes
          12847 packets output, 1541960 bytes

9. Troubleshooting GRE Tunnels

Symptom Likely Cause Fix
Tunnel0 shows up/down The tunnel destination IP is not reachable via the routing table; the outer IP path between tunnel endpoints is broken Verify reachability to the tunnel destination: ping 203.0.113.2 source GigabitEthernet0/0; check the route to the tunnel destination does not use the tunnel itself
%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing The tunnel destination is being routed through the tunnel interface itself — recursive routing loop Add a specific host route to the tunnel destination via the physical WAN interface: ip route 203.0.113.2 255.255.255.255 GigabitEthernet0/0 <next-hop>
GRE tunnel up but no traffic passes; OSPF neighbour never forms Firewall between tunnel endpoints blocking IP Protocol 47; or ACL on the router blocking GRE Add permit gre any any to the ACL; open Protocol 47 on intermediate firewalls — not a TCP/UDP port
Large files fail or hang; small pings work; HTTPS fails silently MTU mismatch — packets larger than tunnel MTU (1476) are being fragmented or dropped; DF bit set on inner packets Set ip mtu 1476 and ip tcp adjust-mss 1436 on the tunnel interface
GRE+IPsec traffic not encrypted; show crypto ipsec sa shows zero packets IPsec profile not applied to tunnel interface; IKE Phase 1 not established; pre-shared key mismatch Verify tunnel protection ipsec profile <name> is on the tunnel interface; check show crypto isakmp sa for SA state; verify pre-shared key matches on both ends
Tunnel up but goes down intermittently Keepalives enabled but far-end router slow to respond; or ISP blocking GRE keepalive probes Increase keepalive retries: keepalive 10 5; disable keepalives if the far-end router cannot respond (no keepalive) and use OSPF dead timer for detection instead

See also: GRE Tunnel Configuration Lab | Site-to-Site IPsec VPN Lab | IPsec VPN | DMVPN | show ip route | show interfaces

10. Key Terms Quick Reference

Term Definition
GRE Generic Routing Encapsulation (RFC 2784) — a tunnelling protocol that encapsulates any Layer 3 protocol inside an IPv4 (or IPv6) packet, identified by IP Protocol 47
Tunnel Interface A logical Cisco IOS interface (interface Tunnel<N>) that represents one end of a GRE (or other) tunnel; configured with a tunnel source IP and tunnel destination IP
Tunnel Source The local IP address (or physical interface) used as the outer source IP of GRE packets; typically the WAN-facing interface of the local router
Tunnel Destination The public IP address of the remote router's WAN interface; used as the outer destination IP of GRE packets
Passenger Packet The original packet being encapsulated and transported inside the GRE tunnel; becomes the inner IP packet after GRE encapsulation
Outer IP Header The new IP header added by GRE encapsulation; addressed with the tunnel source and destination public IPs; carries IP Protocol 47
Protocol 47 The IP Protocol number used for GRE traffic in the outer IP header; firewalls must permit Protocol 47 (not a TCP/UDP port) for GRE tunnels to pass
GRE Overhead 24 bytes per packet — 20-byte outer IP header plus 4-byte GRE header; reduces the effective MTU inside the tunnel from 1500 to 1476 bytes
GRE Keepalive Periodic probe packets sent through the tunnel to detect far-end failure; if no reply after configured retries, the tunnel interface is brought down to prevent blackholing
Recursive Routing A misconfiguration where the GRE outer packet is routed back through the tunnel interface itself, causing an infinite encapsulation loop; triggers the %TUN-5-RECURDOWN error message
GRE + IPsec The combination of GRE encapsulation (to carry multicast/routing protocols) and IPsec encryption (to provide confidentiality) — the standard design for encrypted dynamic routing over WAN/Internet
tunnel protection ipsec profile The Cisco IOS interface command that applies an IPsec profile to a GRE tunnel interface, enabling IPsec encryption of all GRE traffic without a separate crypto map
ip tcp adjust-mss A Cisco IOS command that intercepts TCP SYN packets and rewrites the MSS option to prevent TCP segment sizes that would exceed the tunnel MTU, avoiding fragmentation-related failures
DMVPN Dynamic Multipoint VPN — an advanced Cisco technology that extends GRE to support dynamic, scalable hub-and-spoke and spoke-to-spoke tunnelling using mGRE (multipoint GRE) and NHRP. See: DMVPN Overview

11. GRE Tunnels – Practice Quiz

1. What is the primary advantage of GRE over plain IPsec when connecting two sites that need to run OSPF between them?

Correct answer is B. OSPF uses multicast addresses (224.0.0.5 and 224.0.0.6) to send Hello packets and form adjacencies. Plain IPsec in either transport or tunnel mode can only encrypt unicast IP packets — it cannot carry multicast traffic. GRE solves this by encapsulating the multicast OSPF Hello inside a unicast GRE packet addressed to the tunnel destination. The receiving router decapsulates the GRE and processes the OSPF Hello normally, forming a full adjacency over the virtual point-to-point link.

2. Which IP Protocol number is used in the outer IP header of a GRE packet, and what must a firewall between tunnel endpoints permit?

Correct answer is C. GRE is identified in the outer IP header by IP Protocol number 47. This is not a TCP or UDP port — it is the IP Protocol field in the IP header (the same field that contains 6 for TCP, 17 for UDP, and 50 for IPsec ESP). A common misconfiguration is trying to open a port number for GRE traffic. Firewalls and ACLs must explicitly permit IP Protocol 47 using syntax like permit gre any any in a Cisco ACL.

3. A router receives a %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing error. What is the cause and fix?

Correct answer is A. Recursive routing occurs when the router looks up a route to the tunnel destination and finds it points to the tunnel interface itself — creating an infinite loop. The standard fix is to add a host route (/32) pointing to the tunnel destination IP via the physical WAN interface or its next-hop gateway. This ensures the outer GRE packet is always routed out the physical interface, not back into the tunnel. Example: ip route 203.0.113.2 255.255.255.255 GigabitEthernet0/0 <isp-gateway>

4. What is the effective MTU inside a standard GRE tunnel over an Ethernet link with a 1500-byte MTU?

Correct answer is D. Every GRE packet carries two IP headers: the original inner IP header (part of the passenger packet) and the new outer IP header added by GRE encapsulation (20 bytes), plus the 4-byte GRE header itself. Total overhead = 24 bytes. With a physical Ethernet MTU of 1500 bytes, the maximum size of the passenger packet that fits inside a GRE frame is 1500 − 24 = 1476 bytes. Configure ip mtu 1476 on the tunnel interface and ip tcp adjust-mss 1436 to prevent fragmentation issues.

5. Why is tunnel mode transport (IPsec transport mode) used when combining GRE with IPsec, rather than IPsec tunnel mode?

Correct answer is B. In IPsec tunnel mode, the entire IP packet (including the IP header) is encrypted and a new outer IP header is added. But GRE has already added an outer IP header to route the tunnel traffic. Using IPsec tunnel mode would result in three IP headers: original inner, GRE outer, and IPsec outer — wasteful overhead. IPsec transport mode encrypts only the payload (the GRE packet's content, not its outer header), using the existing GRE outer IP header for routing. The result is two headers: GRE outer + ESP encrypted content — efficient and correct.

6. What is the purpose of the keepalive command on a GRE tunnel interface?

Correct answer is C. Without keepalives, a GRE tunnel interface remains up/up even if the far-end router is completely offline. Traffic routed into the tunnel is silently discarded at the encapsulating router (since the GRE outer packet can reach the transit network but the tunnel endpoint no longer exists). Keepalives solve this by sending periodic GRE probe packets; if the far end does not respond after the configured number of retries, the tunnel is brought down, allowing routing protocols (or static route floating) to find an alternate path.

7. An engineer runs show interfaces tunnel0 and sees the interface is up/down. What does this most likely indicate?

Correct answer is A. A GRE tunnel interface in the up/down state means the interface is configured (line protocol up) but the tunnel cannot establish because the routing table has no path to the tunnel destination — or the path it found routes back through the tunnel (recursive routing). First check: ping <tunnel-destination> source <tunnel-source-interface>. If ping fails, the underlying IP path between tunnel endpoints is broken. If ping succeeds but tunnel is still down, check for recursive routing with show ip route <tunnel-dest>.

8. Which command on a GRE tunnel interface prevents TCP session failures caused by packets exceeding the tunnel MTU?

Correct answer is D. TCP negotiates its Maximum Segment Size (MSS) during the three-way handshake. If the MSS is set too high, the resulting TCP segments — after GRE encapsulation adds 24 bytes overhead — exceed the physical link MTU. This causes fragmentation or silent drops (if the DF bit is set), resulting in large transfers silently hanging while small pings work fine. ip tcp adjust-mss 1436 rewrites the MSS option in TCP SYN packets to 1436 bytes (1476 tunnel MTU − 20 TCP − 20 IP = 1436), ensuring no TCP segment ever exceeds the tunnel capacity.

9. A company needs to run EIGRP between its headquarters and three branch offices over the Internet. The link must also be encrypted. Which technology combination is most appropriate?

Correct answer is B. EIGRP uses multicast address 224.0.0.10 for hello and update packets — plain IPsec cannot carry this multicast traffic. GRE is needed to encapsulate EIGRP multicast as unicast GRE packets addressed to each branch router. IPsec encrypts the GRE packets to protect the traffic in transit over the Internet. This GRE+IPsec combination is the classic enterprise WAN design for encrypted dynamic routing. For larger scale deployments (many branches), DMVPN (which uses mGRE) would be the more scalable evolution of this design.

10. What information is carried in the GRE header's Protocol Type field, and why is this field important?

Correct answer is C. The Protocol Type field in the GRE header is a 16-bit EtherType value identifying the type of payload (passenger protocol) encapsulated within the GRE packet. This is what makes GRE truly "generic" — the same encapsulation can carry IPv4 (0x0800), IPv6 (0x86DD), ARP (0x0806), MPLS (0x8847), or any other protocol. When the receiving router decapsulates the GRE packet, it reads this field to determine how to process and forward the inner packet. This field is also why GRE can carry non-IP protocols — as long as the passenger protocol has an EtherType value, GRE can transport it.

← Back to Home