GRE Tunnel Configuration

Generic Routing Encapsulation (GRE) is a tunnelling protocol developed by Cisco that wraps one network protocol inside another. It creates a virtual point-to-point link between two routers, allowing private network traffic to travel across a public or untrusted network as if the two routers were directly connected. Unlike IPsec, GRE supports multicast and routing protocol traffic — making it the preferred overlay for carrying OSPF, EIGRP, or RIP adjacencies across a WAN. For WAN background see WAN.

GRE adds a 24-byte overhead to each packet: a 20-byte outer IP header (identifying the tunnel endpoints on the public network) and a 4-byte GRE header (identifying the protocol being encapsulated). The inner packet — the original private IP datagram — is preserved intact. At the remote router, the outer IP and GRE headers are stripped and the original packet is delivered to the destination.

Before starting, ensure you are familiar with basic interface configuration at Basic Interface Configuration and static routing at Static Routing Configuration. For encrypting the GRE tunnel, see IPsec Basics and Site-to-Site IPsec VPN — a GRE-over-IPsec combination is the foundation for traditional site-to-site VPNs. For a full comparison of VPN deployment models, visit Site-to-Site vs Remote Access VPN. For dynamic multipoint VPNs built on GRE see DMVPN Phase 1, 2 & 3.

1. GRE Tunnel — Core Concepts

How GRE Encapsulation Works

When a router sends a packet into a GRE tunnel interface, IOS wraps it in two additional headers before forwarding it across the public network:

  Original packet (inner):
  ┌──────────────────────────────────────────────────┐
  │  Inner IP Header  │  TCP/UDP  │  Data Payload    │
  │  Src: 10.1.0.10   │           │                  │
  │  Dst: 10.2.0.10   │           │                  │
  └──────────────────────────────────────────────────┘

  After GRE encapsulation (outer):
  ┌────────────────────┬──────────┬──────────────────────────────────────────┐
  │  Outer IP Header   │  GRE Hdr │  Original (inner) IP packet              │
  │  Src: 203.0.113.1  │  4 bytes │  Inner IP │ TCP/UDP │ Data               │
  │  Dst: 198.51.100.1 │          │  10.1.0.10 → 10.2.0.10                  │
  └────────────────────┴──────────┴──────────────────────────────────────────┘
  ▲ Public network sees only the outer header — private addresses are hidden ▲

GRE Tunnel Characteristics

Property	Value / Behaviour
Default tunnel mode	`tunnel mode gre ip` — encapsulates IPv4 inside IPv4 GRE
Overhead per packet	24 bytes (20-byte outer IP + 4-byte GRE header)
MTU consideration	Default interface MTU is 1500; effective payload MTU is 1476 (1500 − 24). Adjust with `ip mtu 1476` and `ip tcp adjust-mss 1436` on the tunnel interface
Supports multicast	Yes — routing protocols (OSPF, EIGRP, RIP) can form adjacencies over GRE
Encryption	None natively — combine with IPsec for encrypted tunnels (GRE over IPsec)
Tunnel interface type	Virtual point-to-point — appears as a routed interface, supports static routes and dynamic routing protocols
Keepalives	Optional — `keepalive [seconds] [retries]` detects tunnel peer failure
Recursive routing risk	The route to the tunnel destination must NOT use the tunnel itself — causes recursive routing loop. Ensure the physical interface/static route to the far-end public IP exists before configuring the tunnel

GRE vs Other Tunnel Technologies

Technology	Encryption	Multicast/Routing Protocols	Overhead	Primary Use
GRE	❌ None	✅ Yes	24 bytes	Overlay for routing protocols across WAN; combined with IPsec for security
IPsec (tunnel mode)	✅ AES/3DES	❌ No multicast	50–60 bytes	Encrypted site-to-site VPN for unicast traffic only
GRE over IPsec	✅ AES/3DES	✅ Yes (via GRE)	~74 bytes	Encrypted VPN that also carries routing protocol multicast
DMVPN	✅ Optional	✅ Yes	24+ bytes	Hub-and-spoke with dynamic spoke-to-spoke tunnels at scale — see DMVPN Phase 1, 2 & 3

2. Lab Topology & Scenario

Two branch offices need to share private network resources across an ISP's public network. A GRE tunnel between NetsTuts_R1 (Branch A) and NetsTuts_R2 (Branch B) creates a virtual point-to-point link. Static routes through the tunnel forward private traffic; the underlying ISP cloud sees only the public outer IP headers. An optional OSPF configuration is shown in Step 4 to demonstrate dynamic routing over the tunnel.

  Branch A                   ISP Cloud (Public)              Branch B
  ─────────                  ──────────────────              ─────────
  10.1.0.0/24                                               10.2.0.0/24
  [PC-A: 10.1.0.10]                                        [PC-B: 10.2.0.10]
        |                                                          |
   Gi0/1 (LAN)                                              Gi0/1 (LAN)
   10.1.0.1                                                 10.2.0.1
        |                                                          |
   NetsTuts_R1 ──── Gi0/0: 203.0.113.1 ════ 198.51.100.1 :Gi0/0 ──── NetsTuts_R2
   (Branch A)       PUBLIC WAN INTERFACE       PUBLIC WAN INTERFACE    (Branch B)
        |                                                          |
   Tunnel0                    GRE Tunnel                     Tunnel0
   172.16.0.1/30 ◄────────────────────────────────────► 172.16.0.2/30
   tunnel source Gi0/0                              tunnel source Gi0/0
   tunnel dest 198.51.100.1                         tunnel dest 203.0.113.1

  Interface Summary:
  ┌─────────────────┬──────────────────┬──────────────────┐
  │ Interface       │ NetsTuts_R1      │ NetsTuts_R2      │
  ├─────────────────┼──────────────────┼──────────────────┤
  │ Gi0/0 (WAN)     │ 203.0.113.1/30   │ 198.51.100.1/30  │
  │ Gi0/1 (LAN)     │ 10.1.0.1/24      │ 10.2.0.1/24      │
  │ Tunnel0 (GRE)   │ 172.16.0.1/30    │ 172.16.0.2/30    │
  └─────────────────┴──────────────────┴──────────────────┘

3. Step 1 — Configure Physical Interfaces

Physical interfaces must be configured and reachable across the public network before the tunnel is created. The tunnel source and destination are public IP addresses — if routing to these addresses fails, the tunnel stays down.

NetsTuts_R1 — Branch A

NetsTuts_R1>en
NetsTuts_R1#conf t

! ── WAN interface (public IP — tunnel source) ────────────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#description WAN to ISP
NetsTuts_R1(config-if)#ip address 203.0.113.1 255.255.255.252
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

! ── LAN interface (private — Branch A hosts) ─────────────
NetsTuts_R1(config)#interface GigabitEthernet0/1
NetsTuts_R1(config-if)#description LAN Branch A
NetsTuts_R1(config-if)#ip address 10.1.0.1 255.255.255.0
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

! ── Default route toward ISP (public next-hop) ───────────
NetsTuts_R1(config)#ip route 0.0.0.0 0.0.0.0 203.0.113.2

NetsTuts_R2 — Branch B

NetsTuts_R2>en
NetsTuts_R2#conf t

NetsTuts_R2(config)#interface GigabitEthernet0/0
NetsTuts_R2(config-if)#description WAN to ISP
NetsTuts_R2(config-if)#ip address 198.51.100.1 255.255.255.252
NetsTuts_R2(config-if)#no shutdown
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#interface GigabitEthernet0/1
NetsTuts_R2(config-if)#description LAN Branch B
NetsTuts_R2(config-if)#ip address 10.2.0.1 255.255.255.0
NetsTuts_R2(config-if)#no shutdown
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#ip route 0.0.0.0 0.0.0.0 198.51.100.2

Confirm both WAN interfaces can reach each other before proceeding. From R1: ping 198.51.100.1 should succeed. If the ISP cloud is simulated in Packet Tracer or GNS3, add a router in between with routes to both subnets to simulate the public network. The tunnel will not come up if the physical path between the public IPs is broken.

4. Step 2 — Create the GRE Tunnel Interfaces

The tunnel interface is a virtual interface. The four mandatory parameters are: tunnel source (local public IP or interface), tunnel destination (remote public IP), the tunnel IP address, and the tunnel mode (defaults to GRE but explicit configuration is best practice):

NetsTuts_R1 — Tunnel0 Configuration

NetsTuts_R1(config)#interface Tunnel0
NetsTuts_R1(config-if)#description GRE Tunnel to Branch B (R2)
NetsTuts_R1(config-if)#ip address 172.16.0.1 255.255.255.252

! ── Source = local WAN interface (can use IP or interface name)
NetsTuts_R1(config-if)#tunnel source GigabitEthernet0/0

! ── Destination = remote router's public WAN IP ──────────
NetsTuts_R1(config-if)#tunnel destination 198.51.100.1

! ── Mode defaults to gre ip — explicit for clarity ───────
NetsTuts_R1(config-if)#tunnel mode gre ip

! ── Adjust MTU to account for 24-byte GRE overhead ───────
NetsTuts_R1(config-if)#ip mtu 1476
NetsTuts_R1(config-if)#ip tcp adjust-mss 1436

! ── Optional: keepalive to detect tunnel peer failure ─────
NetsTuts_R1(config-if)#keepalive 10 3

NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

NetsTuts_R2 — Tunnel0 Configuration

NetsTuts_R2(config)#interface Tunnel0
NetsTuts_R2(config-if)#description GRE Tunnel to Branch A (R1)
NetsTuts_R2(config-if)#ip address 172.16.0.2 255.255.255.252
NetsTuts_R2(config-if)#tunnel source GigabitEthernet0/0
NetsTuts_R2(config-if)#tunnel destination 203.0.113.1
NetsTuts_R2(config-if)#tunnel mode gre ip
NetsTuts_R2(config-if)#ip mtu 1476
NetsTuts_R2(config-if)#ip tcp adjust-mss 1436
NetsTuts_R2(config-if)#keepalive 10 3
NetsTuts_R2(config-if)#no shutdown
NetsTuts_R2(config-if)#exit

tunnel source accepts either an interface name (GigabitEthernet0/0) or an IP address (203.0.113.1). Using the interface name is preferred — if the WAN IP ever changes (DHCP reassignment), the tunnel automatically picks up the new address. tunnel destination must always be the remote public IP — never the tunnel IP. ip tcp adjust-mss 1436 modifies the TCP Maximum Segment Size in SYN packets so that hosts reduce their segment size to avoid fragmentation (1476 MTU − 20 IP − 20 TCP = 1436 MSS).

Recursive routing warning: If a static or dynamic route to the tunnel destination (198.51.100.1 or 203.0.113.1) is learned through the tunnel itself, the router enters a recursive loop and the tunnel flaps. Always ensure the route to the tunnel destination exits via a physical interface — the default route via ip route 0.0.0.0 0.0.0.0 [ISP-gateway] configured in Step 1 handles this correctly.

5. Step 3 — Route Private Traffic Through the Tunnel

The tunnel interface is up, but traffic to 10.1.0.0/24 and 10.2.0.0/24 has no route through it yet. Add static routes pointing the remote private subnet through the tunnel interface (or the far-end tunnel IP):

NetsTuts_R1 — Static Route to Branch B's LAN

! ── Route Branch B LAN (10.2.0.0/24) via the tunnel ─────
NetsTuts_R1(config)#ip route 10.2.0.0 255.255.255.0 Tunnel0

! ── Alternative: specify far-end tunnel IP as next-hop ───
! NetsTuts_R1(config)#ip route 10.2.0.0 255.255.255.0 172.16.0.2

NetsTuts_R2 — Static Route to Branch A's LAN

! ── Route Branch A LAN (10.1.0.0/24) via the tunnel ─────
NetsTuts_R2(config)#ip route 10.1.0.0 255.255.255.0 Tunnel0

NetsTuts_R2(config)#end
NetsTuts_R2#wr
Building configuration...
[OK]
NetsTuts_R2#

Using Tunnel0 as the exit interface (rather than the far-end tunnel IP) creates a directly-attached static route — suitable for a point-to-point tunnel where only one next-hop exists. If you specify the far-end tunnel IP (172.16.0.2), the router performs a recursive lookup to resolve that address — both methods work for GRE point-to-point tunnels. After completing configuration save with write memory.

6. Step 4 — Optional: Run OSPF Over the GRE Tunnel

One of GRE's key advantages over raw IPsec is multicast support — this allows dynamic routing protocols to form adjacencies over the tunnel. OSPF Hellos are multicast packets; they travel through the GRE tunnel just like any other IP traffic. Replace the static routes from Step 3 with OSPF for automatic route discovery:

NetsTuts_R1 — OSPF Over Tunnel

! ── Remove static route added in Step 3 (if replacing with OSPF)
NetsTuts_R1(config)#no ip route 10.2.0.0 255.255.255.0 Tunnel0

NetsTuts_R1(config)#router ospf 1
NetsTuts_R1(config-router)#router-id 1.1.1.1

! ── Advertise LAN and tunnel networks ────────────────────
NetsTuts_R1(config-router)#network 10.1.0.0 0.0.0.255 area 0
NetsTuts_R1(config-router)#network 172.16.0.0 0.0.0.3 area 0

! ── Do NOT advertise the public WAN network via OSPF ─────
NetsTuts_R1(config-router)#exit

! ── Reduce OSPF hello/dead timers on tunnel (optional) ───
NetsTuts_R1(config)#interface Tunnel0
NetsTuts_R1(config-if)#ip ospf hello-interval 10
NetsTuts_R1(config-if)#ip ospf dead-interval 30
NetsTuts_R1(config-if)#exit

NetsTuts_R2 — OSPF Over Tunnel

NetsTuts_R2(config)#no ip route 10.1.0.0 255.255.255.0 Tunnel0

NetsTuts_R2(config)#router ospf 1
NetsTuts_R2(config-router)#router-id 2.2.2.2
NetsTuts_R2(config-router)#network 10.2.0.0 0.0.0.255 area 0
NetsTuts_R2(config-router)#network 172.16.0.0 0.0.0.3 area 0
NetsTuts_R2(config-router)#exit

NetsTuts_R2(config)#interface Tunnel0
NetsTuts_R2(config-if)#ip ospf hello-interval 10
NetsTuts_R2(config-if)#ip ospf dead-interval 30
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#end
NetsTuts_R2#wr

The OSPF network statement includes the tunnel subnet (172.16.0.0/30) — this activates OSPF on the Tunnel0 interface so the routers exchange Hellos through the tunnel and form an adjacency. The LAN subnets (10.x.x.x) are also advertised so each router learns the remote branch LAN dynamically. The public WAN networks are intentionally excluded — they are reachable via the default route and should not appear in the OSPF topology. For OSPF concepts, see OSPF Single-Area Configuration and OSPF Neighbor States.

7. Verification

show interfaces Tunnel0

NetsTuts_R1#show interfaces Tunnel0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Description: GRE Tunnel to Branch B (R2)
  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)
  Tunnel linestate evaluation up
  Tunnel source 203.0.113.1 (GigabitEthernet0/0), destination 198.51.100.1
  Tunnel Transmit Bandwidth 8000 (kbps)
  Tunnel Receive Bandwidth 8000 (kbps)
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Last input 00:00:03, output 00:00:03, output hang never
  ...

Tunnel0 is up, line protocol is up confirms the tunnel is operational. Both states must be up — up/down means the interface exists but the tunnel cannot reach the destination (check routing to the far-end public IP). The output confirms source (203.0.113.1 via Gi0/0), destination (198.51.100.1), and protocol (GRE/IP). Keepalive is active (10 sec interval).

show ip interface brief — Confirm Tunnel IP

NetsTuts_R1#show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0    203.0.113.1     YES manual up                    up
GigabitEthernet0/1    10.1.0.1        YES manual up                    up
Tunnel0               172.16.0.1      YES manual up                    up

show ip route — Verify Tunnel Routes

NetsTuts_R1#show ip route
Codes: C - connected, S - static, O - OSPF ...

Gateway of last resort is 203.0.113.2 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 203.0.113.2
      10.0.0.0/24 is subnetted, 2 subnets
C       10.1.0.0 [0/0] is directly connected, GigabitEthernet0/1
O       10.2.0.0 [110/1000] via 172.16.0.2, 00:01:12, Tunnel0
      172.16.0.0/30 is subnetted, 1 subnets
C       172.16.0.0 [0/0] is directly connected, Tunnel0
      203.0.113.0/30 is subnetted, 1 subnets
C       203.0.113.0 [0/0] is directly connected, GigabitEthernet0/0

The route to 10.2.0.0/24 (Branch B LAN) is learned via OSPF (O) and exits through Tunnel0 via next-hop 172.16.0.2. The public WAN networks are not in the OSPF topology. A static route configuration would show S 10.2.0.0/24 via Tunnel0 instead of the OSPF entry. For route table details, see show ip route.

ping — Test Private Connectivity Through the Tunnel

! ── Ping from R1 to R2's tunnel IP ──────────────────────
NetsTuts_R1#ping 172.16.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/4 ms

! ── Ping from R1 to Branch B LAN ────────────────────────
NetsTuts_R1#ping 10.2.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/4/6 ms

! ── Extended ping — source from LAN interface ────────────
NetsTuts_R1#ping 10.2.0.10 source GigabitEthernet0/1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/5/8 ms

show ip ospf neighbor — OSPF Adjacency Over the Tunnel

NetsTuts_R1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:28    172.16.0.2      Tunnel0

OSPF adjacency state FULL/DR over the Tunnel0 interface confirms routing protocol traffic is flowing through the GRE tunnel. For OSPF neighbour state details, see OSPF Neighbor States.

Verification Command Summary

Command	What It Shows	Primary Use
`show interfaces Tunnel0`	Tunnel status (up/up), source, destination, protocol, keepalive, encapsulation	Primary verification — confirm tunnel is up and parameters are correct
`show ip interface brief`	Quick status of all interfaces including Tunnel0 IP and line/protocol state	Fast overview — confirm tunnel IP assigned and both states are up
`show ip route`	Routing table — confirms remote LAN routes exit via Tunnel0	Verify traffic will be forwarded through the tunnel to the correct destination
`show ip ospf neighbor`	OSPF adjacencies — confirms FULL state with remote router via Tunnel0	Confirm dynamic routing protocol is operational over the GRE tunnel
`ping [remote-tunnel-ip]`	ICMP through the tunnel — confirms end-to-end tunnel reachability	Basic connectivity test between tunnel endpoints
`ping [remote-LAN] source [local-LAN-int]`	End-to-end LAN-to-LAN reachability sourced from the local LAN interface	Simulates host-to-host traffic — confirms routing in both directions is correct
`debug tunnel`	Real-time GRE encapsulation/decapsulation events — shows when packets enter and exit the tunnel	Deep troubleshooting — use with caution on production routers; disable with `undebug all`

8. Troubleshooting GRE Tunnel Issues

Problem	Symptom	Cause	Fix
Tunnel interface up/down	`show interfaces Tunnel0` shows up/down — line protocol down	No route to the tunnel destination (far-end public IP). The physical path across the ISP is missing or broken	Ping the far-end public IP from the WAN interface: `ping 198.51.100.1 source Gi0/0`. If it fails, fix the physical routing first. Check the default route is pointing to the ISP gateway
Tunnel flaps continuously	Tunnel goes up then down repeatedly — `%TUN-5-RECURDOWN` syslog messages	Recursive routing: the route to the tunnel destination is being resolved through the tunnel itself — creating a loop	Ensure the route to the tunnel destination (198.51.100.1) exits via a physical interface, not Tunnel0. The default route (`ip route 0.0.0.0 0.0.0.0 [ISP-gw]`) via Gi0/0 resolves this. Never advertise the tunnel endpoint's public IP into OSPF or route it via the tunnel
Tunnel is up but traffic fails (large packets)	Tunnel is up and small pings succeed, but large file transfers or web pages fail or hang	MTU/fragmentation issue — the GRE overhead (24 bytes) pushes packets over the physical MTU of 1500. Large packets are fragmented or dropped by devices with "don't fragment" (DF bit) set	Set `ip mtu 1476` and `ip tcp adjust-mss 1436` on the Tunnel0 interface on both routers. Test with `ping 10.2.0.1 size 1400 df-bit` to confirm large packets now pass
OSPF adjacency not forming over tunnel	`show ip ospf neighbor` shows no neighbours on Tunnel0	OSPF network statement missing the tunnel subnet, or Hello/Dead timer mismatch between the two tunnel endpoints, or multicast not supported on the path	Verify `network 172.16.0.0 0.0.0.3 area 0` is in the OSPF config on both routers. Check `show ip ospf interface Tunnel0` — confirm Hello/Dead timers match on both sides. GRE supports multicast natively, so timer mismatch is the most common cause. See Troubleshooting Layer 3 Routing and OSPF Configuration
Tunnel up but no route to remote LAN	Can ping the far-end tunnel IP (172.16.0.2) but cannot reach 10.2.0.0/24	Static route to the remote LAN is missing, or OSPF is not advertising the remote LAN network	Check `show ip route` — is 10.2.0.0/24 present? If using static routes, verify `ip route 10.2.0.0 255.255.255.0 Tunnel0` is configured. If using OSPF, confirm the remote LAN is included in the `network` statement on R2
One-way traffic only	R1 can ping R2's LAN but R2 cannot ping R1's LAN	Asymmetric route configuration — the return route (from R2 to R1's LAN) is missing	Verify both routers have routes in both directions. Check `show ip route` on R2 for the 10.1.0.0/24 entry. A missing static route or OSPF network statement on one side causes one-way reachability

Key Points & Exam Tips

GRE tunnels require four parameters: tunnel source (local public IP or interface), tunnel destination (remote public IP), a tunnel IP address (private transit subnet), and the tunnel mode (gre ip is the default).
GRE adds 24 bytes of overhead per packet (20-byte outer IP header + 4-byte GRE header). Set ip mtu 1476 and ip tcp adjust-mss 1436 on the tunnel interface to prevent fragmentation issues with large TCP payloads.
The tunnel interface status is up/up only when the router has a route to the tunnel destination via a physical interface. An up/down state means the routing to the far-end public IP is broken — fix physical connectivity first.
Recursive routing is the most common GRE misconfiguration — if the route to the tunnel destination resolves through the tunnel itself, the tunnel loops and flaps with %TUN-5-RECURDOWN. Always route the tunnel destination via a physical interface (usually the default route).
GRE supports multicast, allowing OSPF, EIGRP, and RIP to form adjacencies over the tunnel. This is the key advantage over raw IPsec, which blocks multicast. Use OSPF over GRE for dynamic route discovery between sites.
The tunnel IP addresses (172.16.0.0/30 in this lab) are a separate transit subnet — not the public WAN IPs. Traffic between branch LANs is routed to this tunnel subnet, which is then encapsulated and forwarded using the public IPs as the outer headers.
For encryption, combine GRE with IPsec: configure an IPsec crypto map or use a tunnel protection profile to encrypt the GRE tunnel traffic. See IPsec Basics and Site-to-Site vs Remote Access VPN.
GRE keepalives (keepalive [seconds] [retries]) detect tunnel peer failure and bring the line protocol down when the remote router is unreachable — essential for routing protocol failover to an alternate path.
On the CCNA exam: know GRE tunnel configuration commands (tunnel source, tunnel destination, tunnel mode gre ip), the overhead value (24 bytes), why recursive routing is dangerous, and the advantage of GRE over IPsec for routing protocol adjacencies.

Next Steps: For dynamic spoke-to-spoke tunnels at scale, explore DMVPN (Dynamic Multipoint VPN) which builds on GRE and NHRP — see DMVPN Phase 1, 2 & 3. To encrypt this GRE tunnel, add an IPsec profile — see IPsec Basics and Site-to-Site IPsec VPN. For modern SD-WAN as an evolution of overlay networking see Cisco SD-WAN Overview. For FHRP redundancy at the branch LAN, see HSRP and VRRP & GLBP. For NTP synchronisation across the tunnel, see NTP Synchronisation. For OSPF over the tunnel see OSPF Single-Area Configuration and OSPF Multi-Area Configuration.

TEST WHAT YOU LEARNED

1. What are the four mandatory parameters required to bring a GRE tunnel interface to an up/up state on Cisco IOS?

A. Tunnel source, tunnel destination, keepalive, and MTU setting B. Tunnel source (local public IP or interface), tunnel destination (remote public IP), an IP address on the tunnel interface (private transit subnet), and a route to the tunnel destination via a physical interface — without the physical route the line protocol stays down regardless of the other parameters C. Tunnel source, tunnel destination, encryption key, and tunnel mode D. Tunnel IP address, OSPF network statement, keepalive, and tunnel mode

Correct answer is B. A GRE tunnel requires: (1) tunnel source — the local public-facing IP or interface name that identifies this end of the tunnel; (2) tunnel destination — the remote router's public IP; (3) ip address on the Tunnel interface — the private transit subnet address used to route traffic through the tunnel; and (4) a working route to the tunnel destination via a physical interface — without this, the line protocol remains down even if the other three are correctly configured. Keepalive and tunnel mode (gre ip is the default) are optional configuration items that improve operation but are not strictly required to bring the tunnel up.

2. A GRE tunnel shows Tunnel0 is up, line protocol is down. What is the most likely cause?

A. The tunnel IP address is in the wrong subnet — it must be in the same subnet as the WAN interface B. OSPF has not formed an adjacency over the tunnel yet C. The tunnel mode is set to gre ip instead of gre multipoint D. There is no route to the tunnel destination address (far-end public IP) via a physical interface — the router cannot reach 198.51.100.1 across the physical network, so the line protocol cannot come up. Check routing to the public IP and confirm the WAN interface is up

Correct answer is D. The tunnel interface state up/down (interface up, line protocol down) means the virtual interface has been created but the tunnel endpoint cannot be reached across the physical network. IOS requires a route to the tunnel destination address via a non-tunnel interface. If the ISP connectivity is broken, or the default route is missing, or the WAN interface is down, the line protocol on the tunnel stays down. The tunnel IP address is completely independent of the WAN subnet — it is a separate overlay address. OSPF adjacency issues would not prevent the tunnel line protocol from coming up. gre ip is the standard and correct mode for point-to-point tunnels.

3. What is recursive routing in the context of GRE tunnels, and what syslog message does it produce?

A. Recursive routing occurs when the route to the tunnel destination (the far-end public IP) is resolved through the tunnel itself — the tunnel is used to reach the address that defines the tunnel's endpoint, creating an infinite loop. IOS detects this and generates %TUN-5-RECURDOWN, bringing the tunnel down to break the loop B. Recursive routing occurs when OSPF redistributes tunnel routes back into the physical routing table — prevented with route-map filters C. Recursive routing is when two GRE tunnels share the same source IP — each tunnel tries to use the other to reach its destination D. Recursive routing occurs when a static route and an OSPF route exist for the same destination simultaneously — OSPF has lower AD so it wins, but this causes the static route to become recursive

Correct answer is A. GRE recursive routing is a self-referential loop: R1's tunnel destination is 198.51.100.1. If a dynamic routing protocol (e.g., OSPF via the tunnel) installs a route for 198.51.100.1 pointing to Tunnel0, R1 now tries to reach 198.51.100.1 through the tunnel. But to use the tunnel, it must reach 198.51.100.1 — which it tries to do through the tunnel again — an infinite loop. IOS detects this condition and logs %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing. The fix is ensuring the tunnel destination's public IP is always routed via a physical interface — the default route via the ISP gateway (ip route 0.0.0.0 0.0.0.0 [ISP-gw]) achieves this. Never redistribute or advertise the tunnel endpoint's public IPs into a routing protocol running over the tunnel.

4. Why is GRE preferred over raw IPsec when dynamic routing protocols such as OSPF or EIGRP must run between two sites?

A. GRE provides stronger encryption than IPsec — AES-256 is the default, making it more secure for routing protocol traffic B. IPsec cannot be configured on Cisco routers without a GRE tunnel — IOS requires GRE as the underlying transport for all IPsec implementations C. GRE supports multicast packets — OSPF Hellos and EIGRP updates are multicast packets (224.0.0.5, 224.0.0.10). Raw IPsec in tunnel mode only encrypts unicast traffic and drops multicast. A GRE tunnel carries multicast natively, allowing routing protocol adjacencies to form over the tunnel; adding IPsec on top of GRE then provides encryption D. GRE has lower CPU overhead than IPsec — routing protocols require frequent Hello packets which would overwhelm the encryption engine

Correct answer is C. The fundamental limitation of raw IPsec is multicast. OSPF uses multicast addresses 224.0.0.5 (AllSPFRouters) and 224.0.0.6 (AllDRRouters) for Hello packets and LSA flooding. EIGRP uses 224.0.0.10. IPsec tunnel mode only processes unicast packets — multicast packets are not encrypted and are instead dropped by the IPsec policy. GRE is a generic tunnel that treats all IP packets (unicast, multicast, broadcast) identically — it wraps them in a unicast outer header so they traverse the public network as regular unicast IP. This allows routing protocol multicast to flow through the GRE tunnel. The combination of GRE (for multicast support) + IPsec (for encryption) is the traditional site-to-site VPN solution that supports dynamic routing protocols. GRE itself provides no encryption.

5. What is the purpose of `ip mtu 1476` and `ip tcp adjust-mss 1436` on a GRE tunnel interface?

A. These commands increase the tunnel's throughput by allowing larger packets to bypass the physical MTU limit B. ip mtu 1476 sets the tunnel's maximum bandwidth; ip tcp adjust-mss 1436 limits concurrent TCP sessions to 1436 C. These are keepalive commands — the numbers specify the keepalive interval (1476 seconds) and retry count (1436) D. GRE adds 24 bytes of overhead to every packet. The physical interface MTU is 1500 — so the effective payload MTU through the tunnel is 1476 (1500 − 24). ip mtu 1476 tells the router to fragment packets larger than 1476 bytes before encapsulation. ip tcp adjust-mss 1436 modifies the TCP MSS in SYN packets (1476 − 20 IP − 20 TCP = 1436), instructing remote TCP hosts to limit their segment size so that GRE-encapsulated packets never exceed 1500 bytes on the physical wire

Correct answer is D. GRE encapsulation adds 24 bytes per packet. If a host sends a 1500-byte IP packet (the standard Ethernet MTU), adding 24 bytes of GRE overhead produces a 1524-byte outer packet — which exceeds the 1500-byte physical MTU and must be fragmented. Fragmentation is expensive (CPU overhead) and problematic (some routers block ICMP fragmentation-needed messages, breaking Path MTU Discovery). The solution is to set the tunnel interface MTU to 1476, telling the router the maximum payload it can carry without fragmentation. ip tcp adjust-mss handles TCP specifically — by modifying the MSS value in TCP SYN packets as they cross the tunnel interface, it tells the remote TCP endpoint to limit its segments to 1436 bytes, so the fully-encapsulated packet never exceeds 1500 bytes on the WAN link.

6. An engineer uses `tunnel source GigabitEthernet0/0` rather than `tunnel source 203.0.113.1`. What advantage does this provide?

A. Using an interface name is required syntax — IOS does not accept IP addresses directly in the tunnel source command B. If the WAN interface IP changes (for example, a DHCP reassignment by the ISP), the tunnel source automatically updates to the new IP without requiring manual reconfiguration. Using a static IP address would leave the tunnel source pointing to an address no longer assigned to the interface C. Interface-based tunnel sources enable hardware acceleration — IP-based sources are processed in software only D. Using the interface name causes the tunnel to use the interface's MAC address as the source identifier rather than the IP — this improves tunnel stability

Correct answer is B. Both forms (tunnel source GigabitEthernet0/0 and tunnel source 203.0.113.1) are valid IOS syntax and produce functionally identical results when the interface has a static IP. The advantage of the interface name form appears when the WAN IP is dynamically assigned (DHCP from ISP) or when it changes during a maintenance window. If the WAN IP changes and the tunnel source is configured as a static IP, the tunnel source becomes invalid — IOS won't automatically detect the new IP. Specifying the interface name causes IOS to dynamically resolve the tunnel source to whatever IP is currently assigned to that interface — the tunnel adapts to IP changes automatically. In enterprise or ISP environments where WAN IPs can change, the interface name is the preferred and more resilient form.

7. What is the correct OSPF network statement to activate OSPF on a GRE tunnel interface with IP address 172.16.0.1/30?

A. network 172.16.0.1 0.0.0.0 area 0 — host wildcard for exact IP match B. network Tunnel0 area 0 — interface name directly in the OSPF network statement C. network 172.16.0.0 0.0.0.3 area 0 — the network address of the /30 tunnel subnet with wildcard 0.0.0.3 covering the two-host subnet, activating OSPF on Tunnel0 and advertising the transit link to the neighbour D. The OSPF network statement is not needed — OSPF activates automatically on all interfaces when router ospf 1 is configured

Correct answer is C. The OSPF network statement uses a network/wildcard pair. For 172.16.0.1/30, the network address is 172.16.0.0 and the /30 wildcard is 0.0.0.3 (inverted 255.255.255.252 subnet mask). This activates OSPF on the Tunnel0 interface (172.16.0.1 falls within the 172.16.0.0/30 range) and advertises the tunnel transit network to the OSPF neighbour. Option A (host wildcard 0.0.0.0) would also work to activate OSPF on Tunnel0 since 172.16.0.1 matches exactly — but it would only advertise the host route, not the subnet. The subnet statement (option C) is the standard and preferred form. IOS OSPF does not support interface-name syntax in network statements — that syntax is for ip ospf [pid] area [area] under the interface instead.

8. R1 can ping R2's tunnel IP (172.16.0.2) successfully, but PC-A (10.1.0.10) cannot reach PC-B (10.2.0.10). The tunnel is up/up on both routers. What is the most likely cause?

A. A static route or OSPF network statement for the remote LAN (10.2.0.0/24 on R1, or 10.1.0.0/24 on R2, or both) is missing — the tunnel itself is functional but traffic destined for the remote LAN has no route through it. Check show ip route on both routers for the remote LAN prefix B. The GRE tunnel does not support end-to-end host traffic — it only passes traffic between the two router tunnel interfaces C. The tunnel MTU is too small — the host-to-host traffic requires ip mtu 1500 on the tunnel interface D. The LAN interfaces on R1 and R2 must be in the same VLAN as the tunnel interface for host traffic to route correctly

Correct answer is A. The successful ping to 172.16.0.2 confirms: (1) the tunnel is up, (2) GRE encapsulation/decapsulation is working, and (3) routing between the two routers' tunnel IPs is correct. The failure of host-to-host traffic (10.1.0.10 → 10.2.0.10) is a Layer 3 routing problem at the LAN level — not a tunnel problem. Either R1 has no route for 10.2.0.0/24 (traffic from PC-A arrives at R1 but R1 doesn't know to send it into the tunnel), or R2 has no route for 10.1.0.0/24 (return traffic from PC-B has no path back), or both. The fix is to add static routes (ip route 10.2.0.0 255.255.255.0 Tunnel0 on R1 and ip route 10.1.0.0 255.255.255.0 Tunnel0 on R2) or include the LAN subnets in the OSPF network statements.

9. Which command confirms that an OSPF adjacency has formed successfully over a GRE tunnel interface?

A. show interfaces Tunnel0 — the keepalive field shows OSPF Hello state B. show ip route ospf — if OSPF routes appear, the adjacency must be up C. show tunnel endpoints — lists all active GRE tunnel peers with routing protocol state D. show ip ospf neighbor — this command lists all OSPF neighbours with their state (FULL = fully adjacent), neighbour ID, dead time, interface IP, and the interface through which they were learned. A neighbour listed with interface Tunnel0 and state FULL confirms the OSPF adjacency is operational over the GRE tunnel

Correct answer is D. show ip ospf neighbor is the definitive command for verifying OSPF adjacency state. The output includes the neighbour's router ID, priority, state (FULL/DR, FULL/BDR, or FULL/-), dead timer countdown, the neighbour's interface IP address, and the local interface through which the neighbour is reachable. A neighbour showing state FULL via Tunnel0 confirms that OSPF Hellos are being exchanged through the GRE tunnel and the adjacency is fully established. Option B (show ip route ospf) would show OSPF-learned routes only after the adjacency is FULL and routes have been exchanged — useful for confirming route propagation but not the adjacency state itself. show interfaces Tunnel0 shows physical tunnel state, not routing protocol state.

10. An engineer configures a GRE tunnel on R1 with `tunnel source 203.0.113.1` and `tunnel destination 198.51.100.1`. She then configures OSPF and includes the tunnel destination network in the OSPF advertisement. Shortly after, the tunnel begins flapping. What is happening and how should it be fixed?

A. OSPF and GRE are incompatible — OSPF must be replaced with static routes to stop the flapping B. The tunnel is flapping because OSPF hello timers on the tunnel do not match — set both sides to ip ospf hello-interval 10 C. This is a recursive routing loop: OSPF has installed a route for 198.51.100.1 (the tunnel destination) via Tunnel0, because the WAN subnet was advertised into OSPF. R1 now tries to reach 198.51.100.1 through the tunnel, which depends on reaching 198.51.100.1 — a loop. IOS detects this and logs %TUN-5-RECURDOWN. Fix: remove the WAN/public subnet from the OSPF network statement — only advertise private LAN and tunnel subnets via OSPF D. The tunnel flaps because the OSPF process ID (1) conflicts with the GRE tunnel number (0) — change the OSPF process to ID 10 or higher

Correct answer is C. This is the classic recursive routing scenario triggered by incorrect OSPF configuration. When the engineer includes the tunnel destination's public WAN subnet (203.0.113.0/30 or 198.51.100.0/30) in the OSPF network statement, OSPF learns a route to 198.51.100.1 via the tunnel (from R2's advertisement). This OSPF route has AD 110 — lower than the static default route (AD 1) if the default route isn't redistributed with the correct metric. But even more critically, if the OSPF route for 198.51.100.1 points to Tunnel0, R1 now resolves its tunnel destination through the tunnel itself — recursive loop. IOS detects this and flaps the tunnel with %TUN-5-RECURDOWN. The fix is simple: never include the public WAN subnets or the tunnel destination's IP range in OSPF network statements when that OSPF runs over the GRE tunnel. Only private LAN subnets and the tunnel transit subnet (172.16.0.0/30) should be in OSPF.

Back to Home