GRE Tunnel Recursive Routing — Interface Goes Up/Down
Presenting Symptom
The GRE tunnel interface on a Cisco router repeatedly goes up and down every few seconds, causing intermittent connectivity between two remote sites.
Network Context
A small branch office is connected to the corporate headquarters via a GRE tunnel over the public Internet. The branch router (Cisco 4321, IOS XE 16.9) and the HQ router (Cisco 4451, IOS XE 16.9) are configured with a GRE tunnel interface (Tunnel0) using IP addresses 10.0.0.1/30 and 10.0.0.2/30, respectively. The tunnel source is the router's public-facing interface (GigabitEthernet0/0/0) and the tunnel destination is the peer's public IP. The network uses static routes for reachability.
Diagnostic Steps
Check the status of the tunnel interface
show interfaces tunnel 0Tunnel0 is up, line protocol is up (looped)
Hardware is Tunnel
Internet address is 10.0.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 source 203.0.113.1, destination 198.51.100.1
Tunnel protocol/transport GRE/IP
...If the line protocol shows 'up (looped)' or 'up/down', it indicates a problem. The 'looped' status suggests a recursive routing issue where the tunnel destination is reachable via the tunnel itself.
Examine the routing table for the tunnel destination
show ip route 198.51.100.1Routing entry for 198.51.100.1/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.0.0.2, via Tunnel0
Route metric is 0, traffic share count is 1The output shows that the route to the tunnel destination (198.51.100.1) points to the tunnel interface (Tunnel0) itself. This is the classic recursive routing problem: the tunnel's destination is being reached through the tunnel, creating a loop.
Verify the static route configuration
show running-config | include ip routeip route 198.51.100.1 255.255.255.255 Tunnel0
This confirms that a static route is configured that sends traffic to the tunnel destination via the tunnel interface. This is incorrect; the tunnel destination should be reachable via the physical interface (e.g., GigabitEthernet0/0/0).
Check the tunnel keepalive and debug tunnel events
debug tunnel*Mar 1 00:00:10.123: Tunnel0: GRE keepalive sent *Mar 1 00:00:10.124: Tunnel0: GRE keepalive received, sending reply *Mar 1 00:00:20.123: Tunnel0: GRE keepalive sent *Mar 1 00:00:20.124: Tunnel0: GRE keepalive received, sending reply ...
The debug output shows keepalive packets being sent and received, but the interface still flaps. This indicates that the keepalive mechanism is working, but the underlying routing issue causes the tunnel to go down when the recursive route is removed and re-added.
Root Cause
A static route is configured that points to the tunnel destination IP address via the tunnel interface itself (e.g., 'ip route 198.51.100.1 255.255.255.255 Tunnel0'). This creates a recursive routing loop: the router tries to reach the tunnel destination through the tunnel, but the tunnel requires the destination to be reachable. The router detects this loop and brings the tunnel interface down, then re-establishes it, causing the flapping.
Resolution
Verification
After applying the fix, verify the routing table and tunnel status: 1. show ip route 198.51.100.1 Expected output: The route should point to the physical interface (e.g., via GigabitEthernet0/0/0, 203.0.113.2), not Tunnel0. 2. show interfaces tunnel 0 Expected output: Tunnel0 is up, line protocol is up (not looped). 3. ping 198.51.100.1 source GigabitEthernet0/0/0 Expected: Successful ping replies.
Prevention
["Always ensure that the tunnel destination IP is reachable via a physical interface or a non-tunnel path. Use a separate route for the tunnel destination that does not involve the tunnel itself.","Use a loopback interface as the tunnel source and destination to avoid dependency on a single physical interface, but still ensure the loopback addresses are reachable via the underlay network.","Implement dynamic routing protocols (e.g., OSPF, EIGRP) over the tunnel with proper route filtering to prevent the tunnel destination from being advertised into the tunnel."]
CCNA Exam Relevance
On the CCNA 200-301 exam, recursive routing is a common troubleshooting scenario. Questions may present a scenario where a GRE tunnel is flapping and ask the candidate to identify the root cause. The exam tests the understanding that the tunnel destination must be reachable via the physical network, not through the tunnel itself. Candidates must know how to interpret 'show interfaces tunnel' and 'show ip route' outputs to diagnose the issue.
Exam Tips
Memorize the key symptom: a GRE tunnel interface showing 'up (looped)' or flapping indicates recursive routing.
Remember that the tunnel destination IP must have a route that does not point back to the tunnel interface. Check 'show ip route <destination>' to verify.
In the exam, if you see a static route like 'ip route <tunnel-dest> <mask> Tunnel0', that is the smoking gun for recursive routing.
Commands Used in This Scenario
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions