A GRE tunnel interface stuck in Down state is a short, mechanical checklist, not a mystery — encapsulation mode, source/destination addressing, GRE key, the route to the far end, and keepalive configuration, checked in that order. This is the diagnostic sequence, the exact commands for each check, and the practical ping-size test that finds a silent MTU/fragmentation ceiling before it takes a tunnel down under load.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Seven configuration items decide whether a GRE tunnel interface comes up — and the fault is almost always exactly one of them.
A GRE tunnel interface reporting Down is one of the more mechanical troubleshooting jobs in routing — the fault-classification model behind it lists seven specific things to check, in order: encapsulation mode, IP addressing, source/destination assignment, GRE key, the underlying route to the destination, keepalive configuration, and MTU/MSS sizing. Nearly every "tunnel just won't come up" ticket resolves to one item on that list.
This is deliberately different from a tunnel that's already Up but won't pass traffic correctly — that's a routing or encapsulation-detail problem on a tunnel that already exists, and we cover that separately in our note on a VPN tunnel that's up but ping fails. What follows here is what to check before the tunnel interface even reports Up, plus the practical field method — testing with different ping sizes — for finding an MTU/fragmentation ceiling that a simple configuration read-through will never reveal.
GRE trouble splits the same way most tunnel trouble does: the interface never comes up, or it comes up and something downstream is still wrong.
Placing the symptom on this tree first tells you whether you're looking at an establishment problem — this note — or a routing/encapsulation problem on a tunnel that already exists, which belongs in a different diagnostic path entirely.
Diagram labels are kept in English for engineering clarity.
Everything on the left branch is read directly off the tunnel interface's own configuration and counters — display this, display ip routing-table, display keepalive packets count. Once the interface reports Up, a different diagnostic applies, and that's the companion note's territory, not this one's.
Four checks in the order the tunnel interface itself depends on them, plus the field test for the one failure mode a config read-through can't catch.
display this on the tunnel interface catches most of what actually blocks a GRE tunnel from ever coming up.
[HUAWEI-Tunnel0] display this
#
interface Tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel-protocol gre
source 10GE0/0/0
destination 1.1.1.2
#
return
// confirm the peer's source/destination are the exact mirror of these two linesThe tunnel's destination address has to be reachable through a route that isn't the tunnel itself — this is the single most common recursive-routing trap.
<Huawei> display ip routing-table
Destination/Mask Proto Pre Cost NextHop Interface
1.1.1.2/32 Static 60 0 20.1.1.2 GigabitEthernet0/0/1
// outbound interface is the physical uplink, not Tunnel0 -- this is correct
<Huawei> display ip interface brief
Interface IP Address/Mask Physical Protocol
Tunnel0 172.16.1.1/30 up upGRE Keepalive only tells you about the direction you enabled it on — a tunnel can look dead from one end and fine from the other.
# This platform's Tunnel interface
interface Tunnel1
tunnel-protocol gre
keepalive period 10 // Cisco's minimum configurable period is 10s
source 2.2.2.2
destination 1.1.1.1
# Cisco's Tunnel interface (defaults to GRE already)
interface Tunnel1
keepalive 10 3
tunnel source Loopback0
tunnel destination 2.2.2.2
<Huawei> display keepalive packets count
Keepalive sent: 120 Reply received: 118
// sent greater than reply received -> packets lost toward the peer or on the way backThis is a practical test, not a config check — run it whenever the tunnel comes up fine but drops under real traffic, or won't stay stable under load.
<Huawei> ping -s 1400 -a 172.16.1.1 172.16.1.2
Request time out
<Huawei> ping -s 1350 -a 172.16.1.1 172.16.1.2
Reply from 172.16.1.2: bytes=1350 time=2 ms
// breakpoint found between 1350 and 1400 -- set the tunnel MTU at or below it
[HUAWEI-Tunnel0] mtu 1350
[HUAWEI-GigabitEthernet0/0/1] tcp adjust-mss 1300
// leave headroom under the tunnel MTU for GRE + IP + TCP header overheadOnce the checks above have told you where the problem sits, these five account for most of what's actually wrong.
SYMPTOMdisplay this on the Tunnel interface shows what looks like complete configuration on both ends, but interface state stays Down.
CAUSEThis end's destination has to be the peer's source, and vice versa, and both ends' tunnel-protocol has to match exactly — a single field configured against the wrong address, or a protocol left at a different mode, is enough, and produces no specific error anywhere.
FIXRead display this side by side on both tunnel interfaces and confirm source/destination are exact mirrors and tunnel-protocol gre matches on both ends.
interface Tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel-protocol gre
source 10GE0/0/0
destination 1.1.1.2
// peer's tunnel interface must show source 1.1.1.2 / destination (this end's source)SYMPTOMEverything about the tunnel configuration reads correctly, but the interface never comes Up and there's nothing in the logs pointing at why.
CAUSEgre key is a simple shared value both ends must configure identically; a mismatch causes the receiving end to silently discard the far end's GRE-encapsulated packets as if they never arrived.
FIXConfirm the exact same gre key value is configured on both tunnel interfaces — there is no partial-match tolerance.
SYMPTOMThe tunnel interface comes up, then drops, then comes back — repeatedly — with no obvious link or hardware issue.
CAUSEEither there's no route to the tunnel's destination address at all, or the route that exists points back out through the tunnel interface itself (a routing loop), or a dynamic routing protocol running over the tunnel is inadvertently re-advertising the destination's own route back out through it.
FIXConfirm with display ip routing-table that the destination route's outbound interface is the correct physical or logical interface, not the tunnel; where necessary, pin it down with a higher-priority static /32 route.
SYMPTOMOne end declares the tunnel down; the other end shows no problem at all.
CAUSEGRE Keepalive only monitors the direction it's configured for — this end's Keepalive doesn't require or reflect anything about the peer's own Keepalive state, so a one-sided configuration produces a one-sided, and confusing, symptom.
FIXEnable Keepalive with matching period/retry-times on both ends if you want both directions monitored, and read display keepalive packets count on each end separately rather than assuming one end's view describes the whole picture.
SYMPTOMThe tunnel interface itself reports Up and Keepalive is healthy, but real traffic — especially TCP — degrades or hangs intermittently as packet sizes grow.
CAUSEGRE's own encapsulation overhead pushes the effective payload size below the physical interface's MTU; when the configured tunnel MTU (and tcp adjust-mss) don't account for that overhead, larger packets get silently fragmented, dropped, or blackholed depending on the path, and none of it shows up as a tunnel-down event.
FIXRun the ping -s / -a size-sweep test to find the actual breakpoint, then set the tunnel's mtu and the interface's tcp adjust-mss to values that leave room for GRE's overhead.
Pulled straight from the field — the ones worth having an answer ready for.
Yes — it's applied to the traffic being forwarded through the tunnel. Any packet larger than the configured tunnel MTU gets fragmented before it's encapsulated, so this is exactly the value to tune once the ping-size test has found your real breakpoint.
Cisco's Tunnel interface defaults to GRE encapsulation already, so tunnel-protocol usually isn't the mismatch. What does trip people up: Cisco's minimum configurable Keepalive period is typically 10 seconds, higher than this platform's 5-second default — set both ends to the same explicit value rather than leaving defaults in place, and remember Keepalive support on the peer has no bearing on whether your own end's Keepalive functions.
On older Cisco hardware, Tunnel interface traffic can be CPU-forwarded rather than hardware-forwarded; under heavy load the CPU process handling it (visible in show processes cpu as a process consuming an outsized share) can starve the Keepalive packets themselves, and Keepalive misses tear the tunnel down. Removing Keepalive on both ends as a diagnostic step — not a permanent fix — will confirm this: if the tunnel stays stable with Keepalive off, traffic volume, not a real link failure, was the cause.
This note is entirely about the tunnel interface itself failing to reach Up — protocol, addressing, key, route and keepalive. A tunnel that reports Up but won't pass ping correctly is a downstream problem — usually a routing or encapsulation-detail mismatch on a tunnel that already technically exists — and that's a different diagnostic path entirely, covered in our companion note on a VPN tunnel up but ping failing.
This is almost always the MTU/fragmentation case, not a route or Keepalive issue — small control packets and low-volume test traffic can cross the tunnel fine while larger real traffic hits GRE's encapsulation overhead and starts fragmenting or dropping. Run the ping-size sweep test under conditions that approximate real traffic size, not just a default-size ping.
Any of them, in practice — GRE is protocol-agnostic at the tunnel layer, so OSPF, IS-IS, BGP and RIP all run over a GRE tunnel interface exactly as they would over a physical one, along with common multicast protocols. The tunnel itself doesn't understand or filter what's inside it.
This note is built around the Huawei AR-series router's GRE fault-classification model and its display this / display ip routing-table / display keepalive packets count commands, plus the field cases and cross-vendor notes behind them. If your device is a different vendor, the exact commands change, but the underlying checklist — protocol mode, addressing, key, route, keepalive direction, MTU — carries over directly. It doesn't cover GRE running inside an IPSec tunnel in depth, or multicast-over-GRE forwarding performance limits.
Tell us which of the seven checks — protocol, address, key, route, keepalive, or MTU — you've already ruled out, plus your display this output, and we'll help you read the rest.