OSPF over GRE Stuck in EXCHANGE - Partial Reachability and Backup Path Judgement
An enterprise connects HQ and a branch over a GRE tunnel across the internet. Tunnel addresses are 172.16.1.1/30 at HQ and 172.16.1.2/30 at the branch; OSPF area 0 runs over the tunnel while the physical uplinks sit in area 1. For two days the adjacency has remained in EXCHANGE. display ospf interface Tunnel0/0/0 reports MTU 1476 on HQ and 1500 on the branch. Branch users can ping 172.16.1.1 but cannot reach any HQ LAN subnet, and HQ users cannot reach the branch LAN either. The branch also has a floating static default route with administrative distance 200 pointing at the tunnel. Constraints: the tunnel must stay up and the ISP underlay cannot carry frames larger than 1500 bytes.
1. Account for the EXCHANGE state and for the exact pattern of reachability. Why do small pings to 172.16.1.1 succeed, and why do both directions of LAN traffic fail?
Read the worked answer
Why EXCHANGE: the MTU values on the two tunnel interfaces differ (1476 vs 1500). During database description exchange, a DBD packet larger than the local interface MTU is discarded, the master/slave negotiation never completes, and the neighbour stays in EXCHANGE. No LSAs are exchanged, so neither router learns the other's LAN prefixes through OSPF.
Why the pings work: 172.16.1.1/30 is a directly connected subnet on the tunnel. A small ICMP echo is well under 1476 bytes, so it is forwarded as a connected route with no OSPF involvement.
Why both LAN directions fail - two different causes:
- Branch → HQ: the floating static default (AD 200) is installed because no OSPF default exists, so forward traffic is actually forwarded into the tunnel and reaches HQ.
- HQ → branch: HQ has no route to the branch LAN at all, so the reply is dropped. From the branch user's perspective the connection simply times out.
- HQ users → branch LAN fail at the first hop for the same reason: no route entry.
So the symptom looks like a total outage, but the two directions break for different reasons. Confirm with display ospf peer (state EXCHANGE/Exchange), display ip routing-table on HQ (no branch LAN prefix) and on the branch (0.0.0.0/0 pointing at the tunnel).
2. Propose remediation options for the adjacency, with the trade-off of each, and state how you would verify the fix.
Read the worked answer
The underlay cannot carry more than 1500 bytes, so raising the tunnel MTU is not available. The real ceiling for GRE over IPv4 is 1500 − 20 (outer IP) − 4 (GRE) = 1476.
Option A - align the tunnel MTUs (recommended). Set the branch tunnel to ip mtu 1476 to match HQ, then clamp TCP inside the tunnel on both sides (tcp adjust-mss 1400 or lower). Both routers now build identical DBDs; the adjacency reaches FULL and every packet stays under the GRE ceiling with no fragmentation.
Option B - ospf mtu-ignore on one or both tunnel interfaces. Fastest fix and keeps the tunnel as is, but it suppresses only the MTU check. Any OSPF packet that legitimately exceeds the local MTU can still be dropped or fragmented, and fragmentation of protocol traffic is fragile. Acceptable as a temporary measure when a change window is not available; document it as debt.
Option C - re-encapsulate (IPsec/DSVPN or a different tunnel type). Changes the overhead and the MSS calculation; only worth it if security or scalability is also required.
Verification: display ospf peer reaches FULL on both sides, display ospf interface shows consistent MTU, and the branch routing table now shows HQ LAN prefixes as OSPF (not only the AD-200 static). Then test with a large-packet ping across the tunnel (ping -s 1400 -vpn-instance ... 192.168.x.x) rather than a default 56-byte ping, which would hide the MSS problem.
3. After the adjacency is fixed, the business wants automatic failover to a 4G backup link when the internet path to HQ dies. The branch already has a static default with AD 200 pointing into the tunnel. Explain why that is not sufficient and what you would add.
Read the worked answer
Administrative distance is only compared when a route is present in the table. GRE has no liveness detection of its own: the tunnel interface stays up as long as the local physical interface is up, even when the far end or the internet path is dead. In that situation the AD-200 static default remains the active default and silently blackholes traffic - it never steps aside, because no better route was withdrawn and the static itself never disappeared.
The static route needs a condition attached to it:
- BFD for the static/tunnel (
bfdsession bound to the peer IP, ortrack nqa/track bfdlinked to the static route) so the route is withdrawn when the path fails and the 4G default (a higher AD, e.g. 250, via the cellular interface) takes over. - Or run OSPF with BFD on the tunnel and let the 4G link carry a static default; when the adjacency drops, OSPF routes and the tunnel default disappear together.
Watch two side effects: BFD timers must tolerate internet jitter (3×300 ms minimum, not 3×50 ms), and the 4G link must be NATed with its own outbound policy or it will blackhole return traffic. Verify with display bfd session all, then pull the underlay and confirm the routing table switches to the 4G next hop within the target time.