Cisco GRE Tunnel Configuration: Step-by-Step Example

Generic Routing Encapsulation (GRE) transports packets of one protocol inside another over a virtual point-to-point link. On Cisco IOS the tunnel is a logical interface whose endpoints are defined by tunnel source and tunnel destination — the classic use is connecting two private networks across the Internet without buying a leased line. This step-by-step example builds a GRE tunnel between two routers, tunes MTU and MSS for the encapsulation overhead, and verifies reachability end to end.

GRE Tunnel Topology

Router R1 (public IP 1.1.1.1) and R2 (public IP 2.2.2.2) each have a private LAN — 192.168.1.0/24 and 192.168.2.0/24. The tunnel itself uses the 172.16.1.0/24 network, and both tunnel interfaces must be in that subnet.

The two tunnel interfaces behave like a single point-to-point link: each end sees exactly one neighbour, and the transport in between is whatever the public network happens to be. That is the whole appeal of GRE — the tunnel does not care whether the path runs over one hop or forty, and it does not require any change to the intervening network.

What GRE Encapsulation Adds to the Packet

Understanding the overhead is what makes the MTU section below make sense.

• 4 bytes of GRE header — two flag/version bytes and a two-byte protocol type identifying the payload.
• 20 bytes of outer IPv4 header — the source and destination are the public loopback or interface addresses of R1 and R2.

That is 24 bytes of overhead before any encryption is involved. A 1500-byte packet from a LAN host therefore becomes a 1524-byte packet on the wire, which is why a tunnel interface needs its IP MTU lowered rather than left at 1500. Wrap the tunnel in IPsec and you add another 50 to 73 bytes depending on mode and algorithms, which is why GRE-over-IPsec designs use noticeably smaller MTUs than plain GRE.

Prerequisites and Base Reachability

Three things must be true before the tunnel will come up, and checking them first saves a lot of confusion later.

1. The two endpoints can reach each other. On R1, ping 2.2.2.2 must succeed using the address you intend to use as the tunnel source, not just any address.
2. You know the public address you will source the tunnel from. Use a physical interface address or, better, a loopback — a loopback never goes down when a single uplink fails.
3. Nothing filters protocol 47. The intervening network must not block the outer IP packets carrying GRE; only reachability of the endpoint addresses matters, not any port number.

R1# ping 2.2.2.2 source g0/0
R2# ping 1.1.1.1 source g0/0

If those pings fail, stop here. A GRE tunnel cannot come up over an unreachable transport, and no amount of tunnel configuration will change that.

Configuring the GRE Tunnel on R1 and R2

R1(config)# interface Tunnel1
R1(config-if)# ip address 172.16.1.1 255.255.255.0
R1(config-if)# ip mtu 1400
R1(config-if)# ip tcp adjust-mss 1360
R1(config-if)# tunnel source 1.1.1.1
R1(config-if)# tunnel destination 2.2.2.2

R2(config)# interface Tunnel1
R2(config-if)# ip address 172.16.1.2 255.255.255.0
R2(config-if)# ip mtu 1400
R2(config-if)# ip tcp adjust-mss 1360
R2(config-if)# tunnel source 2.2.2.2
R2(config-if)# tunnel destination 1.1.1.1

Because GRE adds 24 bytes of overhead on top of a typical 1500-byte transport MTU, the tunnel MTU is lowered to 1400 and TCP MSS adjusted to 1360 — this keeps fragmentation and packet drops to a minimum. The tunnel source on one side must equal the tunnel destination on the other; the pair of addresses multiplexes GRE traffic so each router knows which tunnel a packet belongs to.

The MSS value follows directly from the MTU: ip tcp adjust-mss 1360 is the tunnel MTU of 1400 minus 40 bytes of TCP and IP header. That single line is often worth more than everything else in the configuration, because a TCP SYN passing through the tunnel is rewritten in both directions so that both ends use a segment size that will never be fragmented. Applications that do not negotiate MSS — most UDP protocols, and anything doing its own path MTU discovery — will not benefit and are the reason the DF-bit test later in this article matters.

For a production tunnel, Cisco's recommended baseline adds three interface hygiene commands. They are not required for the tunnel to pass traffic, but leaving them out causes subtle problems:

R1(config)# interface Tunnel1
R1(config-if)# tunnel mode gre ip
R1(config-if)# no ip redirects
R1(config-if)# no ip unreachables
R1(config-if)# no ip proxy-arp

no ip redirects matters most. A router can try to send an ICMP redirect to a host telling it to use a better next hop, but inside a tunnel the host cannot resolve the next hop that the router is suggesting, and the redirect is simply unnecessary on a point-to-point link.

Adding Routing for the Remote LANs

The tunnel alone only connects the two endpoints. Static routes send each private LAN across the tunnel:

R1(config)# ip route 192.168.2.0 255.255.255.0 172.16.1.2
R2(config)# ip route 192.168.1.0 255.255.255.0 172.16.1.1

Dynamic routing (OSPF, EIGRP) over the tunnel also works, but watch for recursive routing: the router must never conclude that the best path to the tunnel destination goes through the tunnel itself, or the tunnel collapses.

To run OSPF across the tunnel, put both tunnel interfaces in the same area and keep the tunnel destination out of the routing protocol's reach:

R1(config)# router ospf 1
R1(config-router)# network 172.16.1.0 0.0.0.255 area 0
R1(config-router)# network 192.168.1.0 0.0.0.255 area 0
R1(config-router)# passive-interface default
R1(config-router)# no passive-interface Tunnel1

When recursion happens you will see it explicitly in the log:

%TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down

The countermeasure is a static route for the tunnel destination that beats, or is outside, the dynamic protocol — for example a /32 pointing at the physical next hop, redistributed nowhere. Making the tunnel source a loopback address that is advertised only on the physical link achieves the same thing and is the cleaner design.

Verifying the GRE Tunnel

R1# ping 172.16.1.2
R1# show interfaces tunnel 1
R1# show ip route 192.168.2.0

A 100 percent ping success to the far tunnel address proves the tunnel is up. If the tunnel is up but remote LAN hosts are unreachable, check the static routes and ACLs; if the tunnel is down, confirm both endpoints can route to each other's public addresses.

Read the interface output carefully — show interfaces tunnel 1 prints the encapsulation being used, the keepalive setting, and the resolved source interface:

R1# show interfaces tunnel 1
Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 172.16.1.1/24
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
  Tunnel source 1.1.1.1 (GigabitEthernet0/0), destination 2.2.2.2
  Tunnel protocol/transport GRE/IP
  Keepalive set (10 sec)

Then confirm the far side of the path, not just the tunnel endpoint:

R1# ping 192.168.2.1 source 172.16.1.1
R1# show ip route 2.2.2.2
R1# show interfaces tunnel 1 | include (drops|Input|Output)

The show ip route 2.2.2.2 output is the recursion check. The tunnel destination's next hop must be a physical interface, never Tunnel1. If it says Tunnel1, you have recursion waiting to happen.

Keepalives and Tunnel Stability

By default GRE sends a keepalive every 10 seconds and declares the tunnel down after three missed replies — roughly 30 seconds after a real failure. Tune it per interface:

R1(config)# interface Tunnel1
R1(config-if)# keepalive 5
R1(config-if)# keepalive 3 2

The syntax is keepalive period retries; the first command sets the period to 5 seconds with the default retry count, and the second overrides both. Lowering the period makes failure detection faster and increases the amount of tunnel management traffic. In practice, if you need detection faster than a few seconds, GRE keepalives are the wrong tool — run a dynamic routing protocol over the tunnel with BFD, or use IPsec liveness detection, both of which are designed for the job.

Keepalives also consume bandwidth on the tunnel interface's counters, so if you are graphing tunnel throughput, small recurring counts are the keepalives and not customer traffic.

Troubleshooting: Tunnel Up but Traffic Dropped

The most common GRE fault is not a down tunnel, it is an up tunnel that silently drops large packets. Work through it in this order.

1. Test with a large, DF-bit packet. R1# ping 192.168.2.1 source 172.16.1.1 size 1400 df-bit. Success means the path MTU is fine; failure means a router in the transport path is dropping packets that cannot be fragmented.
2. Test just above the tunnel MTU. ping 192.168.2.1 source 172.16.1.1 size 1450 df-bit should fail, and that failure is the proof that your MTU handling is doing what you configured.
3. Confirm MSS clamping is in effect. show ip interface Tunnel1 | include mss should report the adjusted value. If TCP works for small transfers and stalls on large ones, MSS clamping is missing on one side.
4. Check for recursive routing. show ip route <tunnel destination> must point out a physical interface.
5. Check for asymmetric paths. If the return traffic takes a different route that does not pass through the tunnel, stateful firewalls and reverse path forwarding will drop it.
6. Check ACLs on the tunnel interface. ACLs applied to the tunnel see the decapsulated inner packet, not the outer one — a mistake that usually leads to an ACL that appears correct but drops the wrong thing.

GRE over IPsec and When to Avoid GRE

For secure site-to-site connectivity GRE is usually wrapped in IPsec. The GRE tunnel remains the routing interface and IPsec protects the outer packets, which means you get dynamic routing, multicast and QoS marking across an encrypted path — things a pure IPsec tunnel cannot easily carry. Enable it on the tunnel interface and reference a profile:

R1(config)# interface Tunnel1
R1(config-if)# tunnel protection ipsec profile GRE-PROFILE

Remember to size the MTU for the additional IPsec overhead; a tunnel that worked at ip mtu 1400 unprotected often needs closer to 1376 once ESP is added. For a working reference design, see our DMVPN phase 3 and NHRP shortcut configuration guide.

GRE is the wrong choice when you need many sites on one hub without per-site configuration — that is DMVPN; when you need native multicast without tunnels — that is a service provider VPN; and when the path already provides encryption and you are adding GRE only out of habit. As a multiplexing layer for a few point-to-point links it remains hard to beat for simplicity.

Frequently Asked Questions

Can I build more than one GRE tunnel between the same pair of endpoints? Yes, but you must give each tunnel a unique tunnel key so the receivers can tell them apart. Without a key, all traffic between the two addresses lands on one logical tunnel.

Does GRE encrypt anything? No. GRE is encapsulation only. Anyone on the path can read the inner packets, which is why GRE is normally paired with IPsec.

How do I calculate the correct tunnel MTU? Take the transport MTU and subtract 24 bytes for GRE over IPv4. With 1500-byte transport, 1476 is the theoretical maximum; operators commonly use 1400 to leave headroom for MPLS labels or IPsec.

Why does the tunnel show up but pass no traffic? Almost always routing to the tunnel destination, a missing route for the remote LAN, or an ACL. Verify with show ip route 2.2.2.2 and the remote LAN route.

Is a loopback better than a physical interface as the tunnel source? Yes, if it is reachable from the peer. A loopback survives individual link failures and keeps the tunnel's identity stable. The trade-off is that you then have to make sure the loopback is advertised on the transport.

What is the maximum number of tunnels one router can terminate? There is no fixed number; it depends on CPU, memory and the amount of state. A few hundred point-to-point GRE tunnels on a mid-range ISR is realistic; beyond that, a hub-and-spoke design such as DMVPN with mGRE is the standard answer.

For tunnel-path diagnosis see MTU mismatch troubleshooting with the DF bit, TCP MSS clamping and PMTUD troubleshooting, and VXLAN MTU and fragmentation in the underlay. Compare encryption options with our Juniper SRX route-based IPsec VPN guide.

原文链接：https://community.cisco.com/t5/networking-knowledge-base/how-to-configure-a-gre-tunnel/ta-p/3131970