GRE Tunnels: The Complete Guide for Network Engineers

GRE (Generic Routing Encapsulation, full form: Generic Routing Encapsulation) is the simplest tunnel protocol in the network engineer's toolkit. You take any kind of network packet, wrap it inside an IP packet, and send it across an IP network as if you had a direct cable between the two endpoints. That is GRE in one sentence. RFC 2784 (with RFC 2890 adding key and sequence-number extensions) defines the format, Cisco invented it in the early 1990s, and three decades later it still underpins more enterprise overlays than any other tunnel technology because it is everywhere, it is well-understood, and it does exactly one thing well.

This is the cluster overview for the full PingLabz GRE series: how GRE encapsulation works, the packet format, configuration on Cisco IOS XE, routing protocols over GRE, keepalives, the MTU and fragmentation problem, GRE over IPsec, multipoint GRE / DMVPN, and troubleshooting. We will walk through the basics, then the parts of GRE that catch engineers out in production, then the operational realities. If you are configuring your first GRE tunnel, designing a hub-and-spoke overlay, or chasing a recursive-routing flap at 2 AM, start here.

What GRE Solves

GRE was built to carry network protocols that the underlying IP network does not natively understand. In the early 1990s that meant tunneling IPX, AppleTalk, and DECnet across an IP backbone. In 2026 the use cases are different but the core value is the same: GRE lets you treat an IP path between two routers as a virtual point-to-point link.

That virtual link gives you four things you cannot easily get from plain IP routing:

• Multicast over an internet path. OSPF and EIGRP rely on multicast hellos, and the public internet does not forward multicast. Wrap them in GRE and the multicast becomes a unicast IP packet the internet is happy to deliver.
• Non-IP payload over IP. IPv6 over IPv4 (6in4), MPLS over IP backbones, IS-IS over IP - GRE carries any protocol the receiver knows how to decode.
• A predictable Layer 3 next-hop. The other end of the tunnel is always one IP hop away no matter how many physical hops the underlay takes, which simplifies recursive routes, traffic engineering, and policy-based routing.
• Decoupled overlay from underlay. Tunnel endpoints can change carriers, IP addresses, or physical paths without touching the overlay routing protocol. GRE is the duct tape of network engineering, and it never wears out.

What GRE deliberately does not do is encrypt. There is no authentication, no confidentiality, no integrity protection in the GRE header. If you put GRE on the public internet, anyone who can capture the packets can read them. That is why production deployments almost always pair GRE with IPsec, which is the subject of GRE over IPsec: When and How to Combine Them.

How GRE Encapsulation Works (the 10,000-Foot View)

A GRE tunnel is just two routers that have agreed to wrap traffic for each other. There are no sessions, no handshakes, no negotiation. Each router has a tunnel interface configured with a tunnel source (the local underlay IP), a tunnel destination (the remote underlay IP), and a tunnel mode (almost always gre ip for plain GRE over IPv4). Anything routed into that tunnel interface gets encapsulated and sent to the destination.

The encapsulation steps in order:

1. A packet is routed into the tunnel interface by the IP routing table. The tunnel interface looks like any other interface to the routing process.
2. The router prepends a GRE header (4 bytes minimum, more if optional fields are enabled) describing the protocol type of the inner packet.
3. The router prepends an outer IP header. The outer source is the tunnel source IP, the outer destination is the tunnel destination IP, and the protocol field is set to 47 (the IANA-assigned GRE protocol number).
4. The packet is forwarded out the underlay interface that the routing table says reaches the tunnel destination. From the underlay's perspective it is a plain IP unicast packet bound for some destination on the public internet.
5. The remote router receives the packet, sees protocol 47, strips the outer IP and GRE headers, and routes the inner packet according to its own routing table.

That is it. There is no per-packet state on either end. If a packet is dropped, GRE does not know and does not care; the inner protocol (TCP, the routing protocol, whatever) handles loss recovery. This statelessness is GRE's strength (no fancy failure modes) and its weakness (no native liveness check, which is why GRE keepalives were added later).

GRE Packet Format

The wire format of a GRE-encapsulated packet, from outermost to innermost:

Total overhead added per packet is 24 bytes for plain GRE over IPv4 (20-byte outer IPv4 plus 4-byte GRE). That is the reason the canonical Cisco MTU recommendation for a 1500-byte underlay is 1476 bytes inside the tunnel. Add IPsec encryption on top of GRE and you lose another 50-60 bytes depending on the cipher and mode, which is why MTU-and-MSS becomes its own deep dive at GRE MTU and Fragmentation: Fixing Tunnel Packet Loss.

GRE Header Fields

The 4-byte mandatory GRE header has five flag bits and a Protocol Type field. The flags decide whether optional fields follow:

The Protocol Type field is what makes GRE generic. By advertising the EtherType of the inner protocol, GRE can carry anything the receiver knows how to decode. Most of the time you are looking at 0x0800 (IPv4) or 0x86DD (IPv6) and the rest of the flags are zero. The Key field becomes important when you build multipoint GRE for DMVPN; see mGRE and DMVPN Introduction for how the same tunnel source can serve many destinations.

Configuration on Cisco IOS XE: Minimum Viable GRE

The smallest working GRE tunnel between two Cisco routers:

! ---- R1 ----
interface Tunnel0
 ip address 10.0.0.1 255.255.255.252
 tunnel source 198.51.100.1
 tunnel destination 203.0.113.1
 tunnel mode gre ip
!
! ---- R2 ----
interface Tunnel0
 ip address 10.0.0.2 255.255.255.252
 tunnel source 203.0.113.1
 tunnel destination 198.51.100.1
 tunnel mode gre ip

Two interface stanzas, four lines of relevant config each. The tunnel source and destination must be IPs that the underlay routing table can reach (typically internet-routable addresses on each end, or any reachable IP if the tunnel rides over a private WAN). The 10.0.0.0/30 inside the tunnel is the overlay; pick anything you like as long as both ends agree.

Verification on R1:

R1# show interface Tunnel0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 10.0.0.1/30
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
  Tunnel source 198.51.100.1, destination 203.0.113.1
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255, Fast tunneling enabled
  Tunnel transport MTU 1476 bytes

R1# ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

If show interface Tunnel0 says "up / up" and the ping across the overlay works, you have a tunnel. tunnel transport MTU 1476 is Cisco doing the math: 1500 underlay minus 24 GRE+IP overhead. Note that line-protocol-up does not actually mean the remote end is reachable. A GRE tunnel will show up / up as long as the underlay route to the destination is reachable, even if the remote router is offline. That is exactly the problem keepalives were invented to solve. Full lab walkthrough at GRE Tunnel Configuration: Step-by-Step Cisco IOS-XE Lab.

Routing Over GRE

The reason most GRE tunnels exist is to carry a routing protocol. Plain static routes do not need GRE; if you have a static route to the remote network via the underlay, you do not need a tunnel. GRE earns its keep when you want OSPF, EIGRP, or BGP to form a neighbor relationship across an underlay that does not natively support it.

The pattern is the same regardless of routing protocol:

1. Bring up the GRE tunnel.
2. Put the tunnel interface in the routing protocol's interface set (network statement, ip ospf command, EIGRP network command, or BGP neighbor using the tunnel-overlay IP).
3. Watch the neighbor come up. From the routing protocol's perspective the tunnel looks like any other point-to-point link.

OSPF over GRE is the most common case because OSPF needs multicast (224.0.0.5 / 224.0.0.6) for hellos and DR election. The internet does not forward multicast; GRE wraps the multicast in unicast and the problem disappears. EIGRP behaves the same way. iBGP over GRE is common in hub-and-spoke designs where the overlay carries the iBGP mesh. Worked configs and gotchas (recursive routing, OSPF network types, EIGRP delay tweaking) are at Routing Protocols Over GRE: OSPF, EIGRP, BGP.

One thing to plan for: any routing protocol you run inside the tunnel must not use the tunnel to learn the route to the tunnel destination itself. That is recursive routing, the tunnel will flap, and the symptom is "GRE tunnel keeps going up and down every few minutes." Use a static route to the tunnel destination via the underlay, or filter the underlay's IP out of the inside-the-tunnel routing protocol.

GRE Keepalives

Vanilla GRE has no liveness check. The tunnel interface stays up / up as long as the local router can route to the configured tunnel destination. If the remote router crashes, is rebooted, or has a software fault that stops it processing GRE, the local end has no way to know and traffic black-holes.

Cisco's GRE keepalives (a Cisco extension, not in the original RFC 2784 but widely adopted by other vendors) fix this by periodically sending a small GRE-encapsulated packet whose inner IP is addressed back to the sender. The remote router does not have to do anything special; it just routes the inner packet according to its routing table, which sends it back through the tunnel to the sender. If keepalives stop returning, the local end declares the tunnel down.

interface Tunnel0
 keepalive 10 3

That tells the router: send a keepalive every 10 seconds, and declare the tunnel down after 3 missed responses (so 30 seconds of no response). Defaults are 10 seconds and 3 retries. Keepalives are unidirectional - each end runs them independently - and they have a subtle interaction with IPsec that catches engineers out, which is the subject of the dedicated GRE Tunnel Keepalives Explained article.

MTU, Fragmentation, and MSS Clamping

The single most common operational problem with GRE tunnels is MTU. Every encapsulation adds bytes, and when the resulting packet is too big to fit in the underlay path MTU, something must give: either the packet is fragmented, or it is dropped with an ICMP "fragmentation needed" message, or, in the most painful case, it is silently dropped by an underlay device that filters ICMP.

The math for plain GRE over IPv4 with a 1500-byte underlay:

Add IPsec on top in tunnel mode and you lose another 50-60 bytes. The two-line fix that prevents 90 percent of GRE MTU pain on Cisco:

interface Tunnel0
 ip mtu 1400
 ip tcp adjust-mss 1360

ip mtu 1400 tells the tunnel interface to fragment IP packets larger than 1400 bytes before encapsulation, leaving headroom for IPsec overhead. ip tcp adjust-mss 1360 rewrites the MSS value in TCP SYN packets so endpoints negotiate a segment size that fits inside the tunnel without requiring fragmentation in the first place. Full breakdown of the math, when to set what value, and how to debug the symptoms (large pings fail, small ones succeed; HTTPS works for some sites but not others) is at GRE MTU and Fragmentation.

Security: GRE Has None - Use IPsec

GRE was designed for trusted networks. The header has no authentication, no integrity check (the optional checksum is integrity in the weakest sense), and no encryption. Anyone with packet-capture access on the underlay path can read every byte of every inner packet.

For lab and private-WAN use that is fine. For anything traversing the public internet it is not. The standard pattern is GRE inside IPsec: GRE provides the encapsulation and routing-protocol multicast support, IPsec provides confidentiality, integrity, and authentication. Modern IOS XE deployments use IPsec profiles attached to the tunnel interface (the tunnel protection ipsec profile command), which is cleaner than the older crypto map approach. The full configuration walkthrough is at GRE over IPsec: When and How to Combine Them.

For the framework on when to use plain GRE, GRE-over-IPsec, IPsec alone, or something else (VXLAN, WireGuard, SD-WAN overlays), see GRE vs IPsec vs GRE-over-IPsec: Which Tunnel Type?.

Multipoint GRE and DMVPN

Standard GRE is point-to-point: one tunnel source, one tunnel destination, one neighbor. That works for two sites. For 50 branches connecting to two hubs, you do not want 100 manually configured GRE tunnels.

Multipoint GRE (mGRE, tunnel mode gre multipoint) lets a single tunnel interface have many remote destinations. Combined with NHRP (Next Hop Resolution Protocol) for dynamic mapping and IPsec for encryption, mGRE becomes DMVPN (Dynamic Multipoint VPN), the Cisco standard for hub-and-spoke and spoke-to-spoke overlays. DMVPN Phase 1 is hub-and-spoke only (spoke-to-spoke goes through the hub). Phase 2 enables direct spoke-to-spoke after a hub-mediated NHRP resolution. Phase 3 (the modern default) uses NHRP shortcut switching for efficient direct paths.

DMVPN deserves its own cluster, but the GRE-side foundation is just a multipoint tunnel interface and an NHRP map command. The introduction lives at mGRE and DMVPN Introduction.

GRE Across Vendors

GRE is a standard and every major vendor implements it. Cisco gets the most coverage in this guide because of its CLI ubiquity, but the wire format is the same everywhere. Quick orientation:

Configuration syntax differs, behavior of optional fields (Key, Sequence) differs, and keepalive interop between Cisco and non-Cisco kit can be flaky because keepalives are a Cisco extension. The Linux deep dive is at GRE on Linux: ip tunnel add Commands.

Troubleshooting: The Common Failures

The five GRE failure modes you will actually see in production:

• Recursive routing. The route to the tunnel destination is learned through the tunnel itself. The tunnel comes up, the routing protocol learns a better path to the underlay through the tunnel, the tunnel goes down, the routing protocol forgets, and the cycle repeats. Symptom: tunnel flaps every few seconds. Fix: static route to the tunnel destination via the underlay, or distribute-list the underlay IP out of the tunnel-side routing protocol.
• MTU drops. Small packets work, large packets do not. Pings work, HTTPS to certain sites stalls. Fix: ip mtu 1400 and ip tcp adjust-mss 1360 on the tunnel interface.
• Keepalive flap with IPsec. GRE keepalives stop returning when the IPsec tunnel rekeys, or when one direction's IPsec SA dies. Fix: enable IPsec DPD (Dead Peer Detection) and check keepalive intervals against rekey timers.
• Underlay reachability lost. The local end can no longer route to the tunnel destination IP. Tunnel interface goes down even though "show running-config" looks correct. Fix: check the underlay routing table with show ip route <tunnel-destination>.
• ACL blocking GRE. A stateful firewall in the path drops protocol 47 because it does not match TCP, UDP, or ICMP. Fix: add an explicit permit for IP protocol 47 between tunnel endpoints. This catches a lot of greenfield deployments where the underlay firewall was provisioned without knowledge of the GRE plan.

The full debug walkthrough with debug tunnel, debug ip packet detail, and packet captures of the problem cases is at GRE Tunnel Troubleshooting Guide.

The Full GRE Cluster, in Reading Order

The articles in this cluster, in the order they make sense to read:

1. GRE Tunnel Configuration: Step-by-Step Cisco IOS-XE Lab
2. GRE over IPsec: When and How to Combine Them
3. GRE Tunnel Keepalives Explained
4. GRE MTU and Fragmentation: Fixing Tunnel Packet Loss
5. GRE vs IPsec vs GRE-over-IPsec: Which Tunnel Type?
6. Routing Protocols Over GRE: OSPF, EIGRP, BGP
7. mGRE and DMVPN Introduction
8. GRE Tunnel Troubleshooting Guide
9. GRE on Linux: ip tunnel add Commands

This list grows as the cluster expands. Bookmark this page; the cluster is the canonical PingLabz reference for GRE.

Frequently Asked Questions

What is the GRE protocol number?

GRE is IP protocol 47, assigned by IANA. That is the value in the Protocol field of the outer IP header. GRE is not a TCP or UDP protocol, so it has no port number. If a firewall in the path filters by TCP/UDP port and does not have an explicit allow for IP protocol 47, GRE packets get dropped at that hop. This is the single most common reason a GRE tunnel works in lab and fails in production.

Is a GRE tunnel secure?

No. GRE has no encryption, no authentication, and no integrity protection. Anyone who can capture packets on the underlay path can read every byte of the inner traffic. That is why production deployments wrap GRE inside IPsec (or run an alternative like WireGuard or an SD-WAN overlay). GRE alone is appropriate for trusted networks (private MPLS, internal data center) but not for the public internet.

Is GRE a VPN?

GRE is a tunnel, which is one of the components a VPN is built from, but GRE alone is not a VPN in the security sense. A VPN, as the term is normally used, implies confidentiality (encryption) and authentication. GRE provides neither. GRE-over-IPsec is a VPN. Plain GRE is a tunnel that happens to look topologically like a VPN.

GRE vs IPsec - which one should I use?

If you need encryption and only need to carry unicast IP, use IPsec alone (in tunnel mode). If you need to carry multicast (so OSPF / EIGRP can form neighbors over the tunnel) or you need to carry non-IP protocols, use GRE. If you need encryption and multicast support, use GRE over IPsec. The decision tree is at GRE vs IPsec vs GRE-over-IPsec: Which Tunnel Type?.

Is GRE a Cisco proprietary protocol?

No. Cisco invented GRE and was the first vendor to ship it, but the protocol was standardized as RFC 1701 in 1994 and updated as RFC 2784 in 2000. RFC 2890 added optional Key and Sequence Number extensions. Every major networking vendor (Juniper, Arista, Linux, FortiGate, MikroTik, Palo Alto) implements GRE as an interoperable standard. Some specific extensions, like Cisco GRE keepalives, are vendor-specific and may not interoperate cleanly across vendors.

How much overhead does GRE add to each packet?

Plain GRE over IPv4 adds 24 bytes per packet: 20 bytes of outer IPv4 header plus 4 bytes of GRE header. Enabling Key, Sequence, or Checksum adds 4 bytes per field. GRE over IPv6 has 40 bytes of outer IPv6 header plus 4 bytes of GRE for 44 bytes total. Add IPsec in tunnel mode and you lose another 50-60 bytes depending on the cipher. That is why ip mtu 1400 on the tunnel interface is the safe default - it leaves headroom for any encryption you add later.

Key Takeaways

GRE is the simplest possible tunnel: an outer IP header, a 4-byte GRE header, and your original packet. It carries multicast over unicast underlays, runs routing protocols across paths that would otherwise not support them, and gives you a clean Layer 3 next-hop between two endpoints regardless of how complicated the underlay is. It has been a network-engineer staple for three decades because it does one thing well, almost never breaks, and works the same way on every vendor.

If you take one thing away from this guide, take this: GRE without IPsec is a private-network tool, GRE with IPsec is the production tunnel of choice, and the operational pain of GRE always reduces to either MTU or recursive routing. Set ip mtu 1400, run keepalive 10 3, route the tunnel destination statically through the underlay, and you have eliminated 80 percent of the failure modes before you have a single user complaint. Bookmark this page, work through the cluster articles in order, and lab every design decision before you ship it. GRE is simple. Production GRE done well is the result of caring about the parts that look simple.