A GRE tunnel that comes up but still won't let two sites ping each other's tunnel address is one of the most common early-stage VPN tickets. This is the order that finds the fault fastest — encapsulation before routing, the exact display commands for each stage, the checks that only matter once the interface is already Up, and the real misconfiguration cases behind them.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The instinct is to start pinging and tracing routes immediately — but on a GRE tunnel, a good share of ping failures never get that far: the two ends aren't even speaking the same encapsulation yet.
An interface that's Up doesn't mean the tunnel is healthy, and correct-looking configuration on both ends doesn't mean the two sites can actually reach each other's Tunnel interface IP address. The order that finds the fault fastest is: confirm both ends use the same encapsulation, confirm the tunnel's addressing is mirrored and complete, confirm a route exists between the two physical source/destination addresses, and only once the interface itself is genuinely Up, check the GRE Key and the route to the peer's Tunnel interface address specifically.
What follows is the diagnostic order this is built on, drawn from the Huawei AR router's own GRE fault-classification model, the checks and display commands for each stage, a documented misconfiguration case, and a set of FAQ answers pulled from the same maintenance material. If the tunnel underneath this is IPSec-protected, IPSec VPN Tunnel Won't Come Up? covers the negotiation layer; if it's a dynamic hub-and-spoke design instead of a fixed point-to-point tunnel, DSVPN over IPSec Between Huawei Branches and a Cisco Hub covers that variant directly.
GRE ping failures split into three shapes: the Tunnel interface itself never comes Up, it's Up but the two ends still can't ping each other's Tunnel IP, or it's Up and ping works but the link is unstable or slow.
Placing the symptom on this tree first tells you which stage below actually applies — and, more usefully, whether you're looking at a routing problem yet at all.
Diagram labels are kept in English for engineering clarity.
Almost every check on the left branch is a plain configuration mismatch that has to match, field for field, on both ends. The middle branch is what's left once the interface itself is healthy but the two Tunnel IP addresses still can't reach each other; the right branch is a routing-design problem, not a tunnel misconfiguration.
Four checkpoints, each with its own display command — the fault tree above tells you which one to start at.
If the Tunnel interface's network-layer protocol won't come Up at all, don't go near routing yet — encapsulation is the first thing that has to match.
[Huawei-Tunnel0/0/0] display this
[V200R009C00SPC300]
#
interface Tunnel0/0/0
ip address 172.16.1.1 255.255.255.252
tunnel-protocol gre
source GigabitEthernet1/0/0
destination 1.1.1.2
#
return
// tunnel-protocol gre confirms the actual encapsulation in use
// source/destination on this end must mirror the peer's destination/sourceCorrect encapsulation and correct addressing still won't bring the interface Up if the two physical endpoints can't actually reach each other.
<Huawei> display ip routing-table
<Huawei> display fib
// confirm the FIB table agrees with the routing table before assuming
// the tunnel itself is the problem rather than the transport network below itThis is where a second, less obvious pair of checks lives: the GRE Key, and a route to the peer's Tunnel interface address specifically — not just its physical address.
Two very different-looking symptoms trace back to the same root cause: the route to the tunnel's own destination address points at the wrong kind of outbound interface.
<Huawei> ping -s packetsize -a source-ip-address host
// increase packetsize until loss appears -- that breakpoint sets the working MTU
[Huawei-Tunnel0/0/0] mtu mtu-value
[Huawei-Tunnel0/0/0] tcp adjust-mss valueOnce the stages above have told you where the problem sits, these six account for most of what's actually wrong.
SYMPTOMThe Tunnel interface's network-layer protocol never comes Up, no matter what else on the interface looks correct.
CAUSEtunnel-protocol has to be identical on both ends; display this on each side is the only reliable way to see what's actually configured, because a mismatched encapsulation type is completely silent otherwise — no log, no error message.
FIXReconfigure tunnel-protocol gre on whichever end is wrong; because this clears the existing source and destination, re-enter them immediately afterward.
[Huawei-Tunnel0/0/0] tunnel-protocol gre
[Huawei-Tunnel0/0/0] source GigabitEthernet1/0/0
[Huawei-Tunnel0/0/0] destination 1.1.1.2SYMPTOMBoth ends look fully configured, individually, but the Tunnel interface never comes Up.
CAUSEThe source/destination pair is what identifies one single tunnel; if this end's destination isn't the peer's source (and vice versa), the two ends are technically each building a different tunnel that never meets the other.
FIXRead display this on both ends side by side and confirm the mirror explicitly — don't just trust that whoever configured the far end got it right.
SYMPTOMThe Tunnel interface is Up on both ends, encapsulation and addressing both check out, but the two sides still can't ping each other's Tunnel IP.
CAUSEgre key is optional, but if either end configures it, both have to carry the identical value — a Key set on one end and left unset (or set differently) on the other blocks the tunnel from actually passing traffic even while the interface state looks perfectly healthy.
FIXEither configure the same gre key value on both ends, or remove it from both — never leave it configured on only one side.
SYMPTOMPhysical source and destination addresses are reachable and the interface is Up, but a Ping to the peer's Tunnel IP still fails.
CAUSEA tunnel being Up only confirms the physical underlay is reachable — reaching the peer's logical Tunnel interface address is a separate routing question, resolved over whatever routing protocol runs across the tunnel, not something the tunnel's own Up state implies automatically.
FIXConfirm a route to the peer's Tunnel IP exists — via a routing protocol running over the tunnel (GRE supports static routing, OSPF, IS-IS, RIP and BGP), or a static route — before assuming the tunnel itself is broken.
SYMPTOMPing works fine, but the Tunnel interface bounces Up/Down repeatedly, or throughput is unexpectedly poor, with nothing else obviously wrong.
CAUSEIf the route to the tunnel's own destination address resolves with the GRE Tunnel interface itself as the outbound interface, the tunnel depends on itself to stay up — a documented cause of flapping. Separately, a destination route whose outbound interface is a VLANIF interface is a documented cause of low throughput.
FIXCheck display ip routing-table for the destination address's outbound interface specifically; if it's the tunnel itself, replan the underlying routing so the destination is reached over a real physical interface, not the tunnel that depends on it.
SYMPTOMIn a GRE over IPSec deployment, traffic was riding the tunnel, the tunnel flapped Down and traffic failed over to NAT, and when the tunnel came back Up, traffic stayed on NAT instead of returning to it.
CAUSEThis is a documented real case. Once traffic has failed over to a NAT session, that NAT session table entry has higher priority than the routing table — so even after the GRE tunnel is Up again and the routing table would correctly point traffic at it, the existing NAT session keeps winning.
FIXClear the NAT session table so traffic re-resolves against the now-correct routing table and returns to the tunnel; don't assume "tunnel Up" alone means traffic has actually moved back onto it.
<RouterA> system-view
[RouterA] reset nat session all
Warning:The current all NAT sessions will be deleted.
Are you sure to continue?[Y/N]YPulled straight from the field — the ones worth having an answer ready for.
In order of how often they show up: encapsulation mismatch between the two ends; IP address, source or destination not configured, or not mirrored between the two ends; GRE Key configured inconsistently; no route between the physical source and destination addresses; a Keepalive configuration where the send/receive counters don't line up; mismatched MTU values between the two ends; and an interface TCP MSS value set high enough that the frame plus overhead exceeds the MTU.
Two things specifically: a GRE Key mismatch (configured on one end and not the other, or configured with different values), and a missing route to the peer's Tunnel interface address itself — reachability between the physical source and destination addresses doesn't automatically give you a route to the logical Tunnel IP on top of it.
Nothing necessarily changed in the tunnel's own configuration. Check whether the destination route's outbound interface is the tunnel itself — that's a documented, recursive-routing cause of flapping — or a VLANIF interface, which is a documented cause of low throughput. Both are network-design issues to replan, not tunnel misconfigurations to patch.
Yes — GRE supports static routing, OSPF, IS-IS, RIP and BGP over the tunnel, and it can carry multicast protocols including PIM. That's one reason GRE over IPSec exists at all: a plain IPSec tunnel only protects unicast traffic, so any multicast that needs encrypting gets encapsulated in GRE first, and IPSec then protects the GRE tunnel itself.
Two ordinary reasons: an IPSec tunnel alone only protects unicast traffic, so any multicast that also needs encrypting — voice paging, some routing protocols — has to be encapsulated in GRE first and handed to IPSec afterward; and GRE gives you a real logical interface to run a dynamic routing protocol over, which a bare IPSec policy doesn't provide by itself. See DSVPN over IPSec Between Huawei Branches and a Cisco Hub for a worked example of exactly this combination.
Yes — an MTU configured on the GRE Tunnel interface applies to traffic forwarded through that tunnel; anything longer than the configured value gets fragmented before it's sent. That's exactly the mechanism the ping -s test in Stage 3 above is built around.
This note is built around the Huawei AR-series router's GRE fault-classification model — display this, display ip routing-table, display fib — and the field cases behind them, drawn from the same maintenance documentation. It assumes a static point-to-point GRE tunnel, not DSVPN's dynamic mGRE variant or a fully worked GRE over IPSec deployment. For the IPSec negotiation layered on top of a tunnel like this, see IPSec VPN Tunnel Won't Come Up?; for the dynamic multipoint case, see DSVPN over IPSec Between Huawei Branches and a Cisco Hub.
Tell us whether the Tunnel interface itself is Up, plus the display this output from both ends, and we'll help you read it.