GRE tunnels are a staple of enterprise networks, used to connect remote sites over an untrusted intermediate network like the Internet. On the CCNA 200-301 exam (objective 5.7), you must be able to systematically troubleshoot why a GRE tunnel is not working. This skill separates a junior engineer who panics from a professional who methodically isolates the issue. In real networks, a broken GRE tunnel can mean a remote site goes completely dark, so mastering the troubleshooting process is essential.
Jump to a section
Imagine you run a courier service between two office buildings separated by a busy city. To avoid traffic, you build a private underground tunnel between the basements of the two buildings. This tunnel is your GRE tunnel. However, the tunnel is just an empty passage – it doesn't actually move packages. To send a package (an IP packet) through the tunnel, you first seal it in a special container (GRE encapsulation) that has the tunnel's entry and exit addresses written on it. Then you hand that container to the city's postal service (the public IP network) which delivers it to the other end. The postal service doesn't care what's inside the container; it only reads the outer addresses. At the far end, the container is opened and the original package is handed to the recipient. Now, if the tunnel stops working, you need to check several things: Is the tunnel physically built? (tunnel interface status). Are both ends configured to use the same tunnel parameters? (matching source/destination IPs, GRE key if used). Can the postal service actually reach the other building's address? (IP connectivity between tunnel endpoints). Is the container being opened correctly at the far end? (decapsulation, MTU issues). Finally, is the recipient allowed to receive packages through this tunnel? (routing – the tunnel must be in the routing table for traffic to use it). Each of these steps mirrors a real troubleshooting layer for GRE.
What is a GRE Tunnel and Why Does It Fail?
Generic Routing Encapsulation (GRE) is a tunneling protocol that encapsulates a wide variety of network layer protocols (most commonly IP, but also IPv6, IPX, etc.) inside an IP tunnel. It is stateless – there is no keepalive mechanism by default (though Cisco supports GRE keepalives). A GRE tunnel is defined by a tunnel source (the local router's outgoing interface IP) and a tunnel destination (the remote router's IP). When the tunnel is up, the router will encapsulate packets with a GRE header plus an outer IP header with source = tunnel source, destination = tunnel destination.
Common failure modes: - Layer 1/2 issues: The physical interface used as the tunnel source is down. - Layer 3 connectivity: The tunnel destination is not reachable via the public network. - Configuration mismatch: Tunnel source/destination, GRE key, or IP addresses on the tunnel interface are mismatched. - Routing problems: The tunnel interface is not in the routing table for the desired traffic, or recursive routing issues (the tunnel destination is learned through the tunnel itself). - MTU/Path MTU issues: GRE adds 24 bytes overhead (20 IP + 4 GRE), causing fragmentation or PMTUD black holes. - Access lists / firewalls: The outer IP packets (protocol 47) are blocked.
Step-by-Step Packet Flow
A packet destined for a remote subnet arrives at the router's egress interface.
The router looks up the destination in its routing table and finds a route pointing to the tunnel interface (e.g., Tunnel0).
The router performs GRE encapsulation: it adds a 4-byte GRE header (protocol type, flags, etc.) and then a 20-byte outer IP header with source = tunnel source IP, destination = tunnel destination IP, protocol = 47.
The router then looks up the outer destination IP in its routing table to determine the next-hop interface.
The packet is forwarded out the physical interface toward the tunnel destination.
At the remote router, the packet arrives with protocol 47. The router decapsulates it, removes the outer IP and GRE headers, and forwards the original packet based on its inner destination IP.
If any of these steps fails, the tunnel is broken.
Key Verification Commands
show ip interface brief
show interfaces tunnel 0
show ip route
show ip route 10.0.0.2 255.255.255.255
ping 10.0.0.2 source 10.0.0.1
show ip access-lists
show ip mtu
show ip interface tunnel 0 | include MTUExample output of a working tunnel:
Router# show interfaces tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.0.0.1/30
MTU 1476 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Tunnel source 192.168.1.1, destination 203.0.113.2
Tunnel protocol/transport GRE/IP
Tunnel TTL 255
Keepalive enabled (10 sec), retries 3
Tunnel is up, line protocol is upIf the tunnel is down, you might see:
Tunnel0 is up, line protocol is downThis indicates a problem with the tunnel destination reachability or a mismatch.
Interaction with Related Protocols
Routing protocols: OSPF, EIGRP, etc. can run over the tunnel interface. The tunnel interface must be up for neighbor relationships to form.
ACLs: If an ACL blocks protocol 47 on any intermediate interface, the tunnel will fail.
NAT: If the tunnel endpoint is behind NAT, the outer IP will be translated, but the tunnel destination must be the public IP after translation. NAT can also break GRE if not configured to handle protocol 47.
IPsec: GRE is often combined with IPsec for encryption. Troubleshooting then becomes two-fold: GRE first, then IPsec.
Check Tunnel Interface Status
Start with `show interfaces tunnel 0` or `show ip interface brief`. Look for 'up/up' (line protocol up). If line protocol is down, the tunnel endpoint is not reachable or there's a configuration mismatch. If the interface is administratively down, use `no shutdown`. Verify the tunnel source and destination IPs are correct and that the source interface is up/up.
Verify IP Connectivity Between Endpoints
From the local router, ping the tunnel destination IP using the tunnel source as the source: `ping 203.0.113.2 source 192.168.1.1`. If this fails, there is a layer 3 problem on the transport network. Check routing: `show ip route 203.0.113.2`. Ensure there is a valid route (not via the tunnel itself – that would be recursive routing). Also check for ACLs blocking ICMP or GRE (protocol 47).
Check for ACLs and Firewalls Blocking GRE
GRE uses IP protocol 47. Use `show ip access-lists` on all interfaces along the path (if you have access) to see if GRE is permitted. On the router, check inbound ACLs on the interface facing the tunnel destination: `show ip interface [interface] | include access list`. If an ACL denies protocol 47, the tunnel will fail. Also consider stateful firewalls that may need to permit GRE explicitly.
Verify Tunnel Configuration Match
GRE is stateless but both ends must agree on the tunnel source/destination IPs. On the local router, check `show running-config | section interface Tunnel0`. Ensure the tunnel source and destination on the remote router are the inverses. Also check for optional parameters like `tunnel key` (GRE key) – if one side has a key and the other doesn't, the tunnel may fail. Use `debug tunnel` with caution in production.
Check for Recursive Routing Issues
A classic trap: the route to the tunnel destination points out the tunnel interface itself, creating a loop. Verify with `show ip route [tunnel-destination]`. The next hop should be a physical interface, not the tunnel. If you see 'via Tunnel0', you have recursive routing. Fix by ensuring the route to the destination is via a physical interface or a static route with a different administrative distance.
Check MTU and Fragmentation Issues
GRE adds 24 bytes overhead. If the path MTU is 1500, the effective MTU on the tunnel is 1476. Check `show ip interface tunnel 0 | include MTU`. If the router sends a packet larger than the path MTU with the DF bit set, it will be dropped. Use `ping 10.0.0.2 size 1472 df-bit` to test. If it fails, you may need to adjust the tunnel MTU or enable TCP MSS clamping (`ip tcp adjust-mss 1400` on the tunnel interface).
In enterprise networks, GRE tunnels are often used to connect branch offices to a central hub over the Internet, carrying private IP traffic or routing protocols. For example, a company with 50 branches might use a hub-and-spoke GRE topology where each branch has a tunnel to the central data center. The tunnels carry OSPF or EIGRP, so the entire network appears as one OSPF area. A common problem: after a WAN outage, the tunnel comes up but OSPF neighbors don't form. The engineer checks the tunnel interface – it's up/up – but the OSPF process is not seeing the neighbor. The culprit is often the MTU: the GRE overhead causes the OSPF hello packets to be fragmented or dropped. The fix is to set ip mtu 1400 on the tunnel interface and ip ospf mtu-ignore (though the latter is a workaround). Another scenario: a branch router has a default route pointing to the Internet, but the tunnel destination is the hub's public IP. The engineer configures a static route for the hub's IP via the ISP, but accidentally points it to the tunnel interface – recursive routing kills the tunnel. The show ip route command reveals the loop. The fix is to use a separate route with a lower administrative distance or a different next-hop. Finally, performance considerations: GRE adds overhead and can cause fragmentation. In production, engineers often combine GRE with IPsec for encryption, which adds another 20+ bytes. They must adjust MTU and MSS accordingly. A misconfigured ACL on the hub's outside interface blocking protocol 47 is a frequent cause of mysterious tunnel failures – always check the ACLs first.
The CCNA 200-301 exam objective 5.7 covers 'Troubleshoot a GRE tunnel not working.' Expect scenario-based questions where you are given show command outputs and must identify the problem. Common traps:
Recursive routing: The most popular wrong answer is 'The tunnel source is incorrect' when the real issue is that the route to the destination points to the tunnel itself. Candidates see the tunnel interface is up/up and the destination is reachable via ping, but they miss that the route is via Tunnel0. Always check the routing table.
ACL blocking GRE: Candidates often check IP connectivity with ICMP (ping) and assume that if ping works, the tunnel should work. But GRE uses protocol 47, which may be blocked even if ICMP is permitted. The exam will show an ACL that permits ICMP but denies 47. The correct answer is 'GRE protocol is blocked.'
MTU mismatch: The exam may present a scenario where small packets work but large ones fail. Candidates might think the tunnel is down, but show interfaces tunnel shows up/up. The real issue is fragmentation. Look for DF bit set and packets being dropped. The fix is to reduce the tunnel MTU or use TCP MSS clamping.
Keepalive failure: GRE keepalives are optional. If enabled, they send GRE packets with a special sequence number. If the remote end doesn't respond, the local end marks the tunnel down. Candidates may not realize that keepalives are disabled by default. The exam might show a tunnel that flaps every 10 seconds – check keepalive configuration.
Decision rule: When troubleshooting a GRE tunnel, always start with the physical layer (interface status), then IP connectivity (ping with source), then protocol-specific (ACL for 47, routing for recursion), then application (MTU). Eliminate options that blame the tunnel configuration before verifying basic connectivity.
GRE tunnel line protocol is down if the tunnel destination is not reachable or there's a configuration mismatch.
GRE uses IP protocol 47 – ACLs must permit this protocol, not just ICMP.
Recursive routing occurs when the route to the tunnel destination points out the tunnel interface itself.
GRE adds 24 bytes overhead (20 IP + 4 GRE), reducing the effective MTU to 1476 on a 1500-byte link.
Use 'ping [destination] source [source]' to test IP connectivity between tunnel endpoints.
GRE keepalives are disabled by default and must be configured with 'keepalive' under the tunnel interface.
The 'tunnel key' command adds a 4-byte key in the GRE header; both sides must match.
These come up on the exam all the time. Here's how to tell them apart.
GRE Tunnel
No encryption – clear text
Stateless – no keepalive by default
Supports multiprotocol (IP, IPv6, etc.)
Overhead: 24 bytes (20 IP + 4 GRE)
Simple configuration
IPsec Tunnel
Provides encryption and authentication
Stateful – uses IKE for key management
Usually only carries IP
Overhead: 50+ bytes (ESP/AH)
More complex configuration
Mistake
If the tunnel interface is up/up, the tunnel is working perfectly.
Correct
The tunnel interface can be up/up even if there is no end-to-end path for payload traffic. For example, ACLs may block GRE protocol, or MTU issues may cause packet drops. Up/up only indicates that the router believes the tunnel destination is reachable at layer 3.
Candidates confuse interface status with actual data-plane functionality.
Mistake
GRE tunnels require keepalives to stay up.
Correct
GRE is stateless and does not require keepalives. Cisco routers can optionally send keepalives, but by default they are disabled. The tunnel stays up as long as the destination is reachable.
Many candidates assume all tunnels are like PPP or Frame Relay with LMI.
Mistake
Pinging the tunnel destination ensures the tunnel will work.
Correct
Ping uses ICMP (protocol 1), while GRE uses protocol 47. An ACL may permit ICMP but block 47, so ping succeeds but GRE fails.
Candidates think that if the endpoint is reachable, any protocol should work.
Mistake
The tunnel source must be the same as the outgoing interface's IP address.
Correct
The tunnel source can be any IP address assigned to the router (e.g., a loopback), as long as it is reachable from the remote end. The router will use that IP as the source of the outer IP header.
Candidates often assume the source must be the physical interface IP.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The line protocol of a GRE tunnel goes down when the router cannot reach the tunnel destination IP. First, verify that the tunnel destination is reachable via a ping with the correct source. Check the routing table to ensure there is a valid route (not recursive). Also check for ACLs blocking GRE (protocol 47) on any intermediate interface. If the tunnel source interface is down, the tunnel will also be down. Finally, check for mismatched tunnel keys or other optional parameters. Use 'show interfaces tunnel 0' to see the current status.
Recursive routing occurs when the route to the tunnel destination points to the tunnel interface itself. For example, if you have a static route 'ip route 203.0.113.2 255.255.255.255 Tunnel0', the router will try to send the encapsulated packet to the tunnel destination, but to do that it needs to look up the destination again, creating a loop. This causes the tunnel to flap or stay down. Fix by ensuring the route to the destination uses a physical interface or a different next-hop. Use 'show ip route [destination]' to check.
Use 'show ip access-lists' to view all ACLs on the router. Look for entries that deny protocol 47 (GRE). Also check the ACL applied to the interface facing the tunnel destination with 'show ip interface [interface]'. If you have access to intermediate devices, check their ACLs as well. A common mistake is to permit ICMP but forget to permit 47. The tunnel will appear up (because IP connectivity exists) but data won't flow.
The default MTU on a GRE tunnel is the MTU of the outgoing physical interface minus 24 bytes (20 for outer IP header + 4 for GRE). For a typical Ethernet interface with MTU 1500, the tunnel MTU defaults to 1476. You can verify with 'show ip interface tunnel 0 | include MTU'. If the path MTU is smaller, you may need to manually set the tunnel MTU or use TCP MSS clamping.
Yes, GRE is stateless and does not require keepalives. The tunnel interface will remain up as long as the tunnel destination is reachable via the routing table. Keepalives are optional and are used to detect failures more quickly. By default, keepalives are disabled. If you enable them, the router sends GRE keepalive packets and expects a reply. If no reply is received after the configured retries, the tunnel is marked down.
GRE is a simple tunneling protocol that encapsulates packets but provides no security. It can carry multiple protocols (IP, IPv6, etc.). IPsec provides encryption, authentication, and integrity but typically only carries IP. In practice, GRE is often used with IPsec (GRE over IPsec) to get both multiprotocol support and security. GRE overhead is 24 bytes; IPsec adds 50+ bytes depending on mode and algorithms.
If the tunnel flaps every 10 seconds, it is likely due to keepalive failure. Check the keepalive configuration with 'show running-config | section tunnel'. The default keepalive interval is 10 seconds with 3 retries. If the remote end is not responding, the local end marks the tunnel down. Also check for recursive routing: if the route to the destination changes, the tunnel may go up and down. Use 'debug tunnel' to see keepalive events (caution: can be verbose).
You've just covered Troubleshoot: GRE Tunnel Not Working — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?