A GRE tunnel between two branches flaps every minute or so once OSPF over it starts advertising the WAN subnets; what is happening, and how do you stop it?
answer
- how does the router reach the tunnel's destination?
- longest match beats the default route
- down, withdraw, up, learn, down again
- keep underlay routes out of the overlay
basics
~20 sThis is recursive routing: OSPF over the tunnel advertises a route to the tunnel's own destination, so reaching the endpoint requires the tunnel. It drops, the route is withdrawn, it recovers, and repeats. Keep underlay addresses out of the overlay IGP.
solid answer
~50 sA GRE tunnel needs an underlay route to its destination — say `203.0.113.2`, reached through the default route to the ISP. When the far branch puts its WAN subnet `203.0.113.0/29` into OSPF, the near router learns it across the tunnel, and longest-prefix match prefers the /29 to `0.0.0.0/0`. The delivery packet for the tunnel's own destination would now be routed into the tunnel. Implementations detect this recursion and take the tunnel down — no RFC defines that check — which drops the OSPF adjacency, withdraws the /29, restores the underlay path and lets the tunnel and adjacency return; then it repeats. The fix is to keep underlay addresses out of the overlay IGP: don't advertise or redistribute the WAN subnets, and pin the destination to the underlay with a host route or a separate routing table.
go deeper
Recall that a tunnel's far endpoint must always be reached through the real network underneath, never through the tunnel itself.
Explain why longest-prefix match lets a /29 learned over the tunnel override the default route that delivered the tunnel packets.
Diagnose the flap from its regular period and the route to the tunnel destination, walk the cycle step by step, and choose the fix that removes the cause.
Set the estate-wide rule that keeps underlay and overlay apart, by separate routing tables or by policy, and decide how it is enforced across many sites.
## Two routing questions in one router A router with a GRE tunnel answers two different routing questions with one routing table: - **Overlay:** where does an inner packet, such as one for `10.2.0.0/24`, go? Answer: into the tunnel, learned through OSPF running across it. - **Underlay:** where does the *delivery* packet, addressed to the tunnel's far endpoint, go? Answer: out of the physical interface, towards the ISP. **Recursive routing** is the fault where the second answer becomes "into the tunnel": the route to the tunnel's destination is learned through the tunnel itself. A packet cannot be delivered by a tunnel whose own delivery depends on that tunnel. No GRE RFC describes this failure; it follows from ordinary longest-prefix routing. ## The scenario | | Branch A | Branch B | |---|---|---| | WAN subnet | `198.51.100.0/29` | `203.0.113.0/29` | | Router WAN address (tunnel endpoint) | `198.51.100.1` | `203.0.113.2` | | Underlay route to the far endpoint | `0.0.0.0/0` via the ISP | `0.0.0.0/0` via the ISP | | Tunnel addresses | `172.16.0.1/30` | `172.16.0.2/30` | The tunnel and the OSPF adjacency are up. Then someone includes Branch B's WAN interface in OSPF, or redistributes connected routes on it. ## The flap cycle, step by step 1. Branch B advertises `203.0.113.0/29` into OSPF across the tunnel. 2. Branch A installs `203.0.113.0/29` via the tunnel. It is longer than `0.0.0.0/0`, so it wins. 3. To send any GRE packet, Branch A looks up `203.0.113.2` and finds the tunnel. The tunnel now depends on itself. 4. The implementation detects the recursion and takes the tunnel down. If it did not, its delivery packets would have no path to the endpoint at all. 5. With the tunnel down, the OSPF adjacency is lost and the `/29` learned across it is withdrawn. 6. The default route to the ISP is the best path to `203.0.113.2` again, so the tunnel comes up. 7. OSPF re-forms the adjacency, exchanges its database, relearns the `/29` — and step 3 happens again. The period is set by how quickly the implementation notices the recursion plus how long OSPF takes to bring an adjacency to full and recompute routes, which is why the flap is steady rather than random. ## How to recognise it - The tunnel goes down and up on a **regular cycle**, and the cycle lines up with OSPF adjacency changes. - During the up phase, the route to the **tunnel's own destination address** points at the tunnel interface instead of the WAN. - The trigger is a change that put **underlay addresses into the overlay IGP**: a new network statement, a redistribution, or a summary that happens to cover the WAN subnet. - Many implementations log a dedicated recursion message; the wording is the implementation's, not a protocol's. ## Fixes, from most to least robust | Fix | Why it works | Limit | |---|---|---| | Keep the underlay in a **separate routing table** (a VRF) from the overlay | The tunnel destination is looked up only where OSPF over the tunnel never installs anything | Needs implementation support and more configuration | | **Never advertise underlay addresses** into the overlay IGP | Removes the cause at its origin; OSPF floods link-state data across an area, so stopping it at the source is cleanest | Relies on discipline at every site | | **Pin a host route** (`203.0.113.2/32`) via the ISP next hop | A /32 beats any shorter overlay prefix by longest match | An overlay /32 for the same address ties on length, and preference between them is implementation-specific | | **Filter routes** to tunnel endpoints learned on the tunnel | Stops them reaching the routing table | Filtering inside a link-state area is coarser than at the origin | Raising OSPF timers only slows the cycle; lowering the MTU or enabling GRE options does nothing, because neither changes where the delivery packet is routed. ## What it is not - **Not RFC 1701's Recursion Control.** That three-bit field counted how many further encapsulations were allowed. RFC 2784 deprecated it, and it never governed routing. - **Not RFC 2784 section 3.1's loop.** That rule covers a *decapsulated* packet whose destination is the tunnel's other end; the receiver must discard it. Recursive routing is about where the *delivery* packet is sent. - **Not an MTU fault.** MTU problems stall large transfers on a stable tunnel; recursion takes the whole tunnel down and up.
- Why does a GRE recursive-routing flap run on a regular period?Each cycle is the sum of fixed delays: the implementation noticing the recursion and dropping the tunnel, the tunnel coming back over the underlay, and OSPF re-forming the adjacency, exchanging its database and recomputing routes. Nothing else changes between cycles, so the period stays steady until the advertisement is removed.
- Does a static /32 to the GRE tunnel's destination always win against OSPF?Against any shorter prefix learned through the tunnel, yes, by longest match. If OSPF also carries a /32 for the same address, the prefixes tie and the choice falls to the implementation's preference between route sources. Separating underlay and overlay into different routing tables removes the question entirely.
saying these in an interview costs you the question
- The flap is an MTU problem; lowering the tunnel MTU will stop it.
- Raising the OSPF dead interval fixes a recursive-routing flap.
- RFC 2784's Recursion Control field prevents recursive routing.
- Advertising the WAN subnets into OSPF is harmless while a default route exists.
- GRE detects recursion itself through a field in its header.