GRE Tunnels

Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco that encapsulates a wide variety of network layer protocols inside IP tunnels. It is defined in RFC 2784 and RFC 2890. GRE creates a virtual point-to-point link between two routers over an IP network. The original packet (payload) is wrapped with a GRE header and then an outer IP header. The outer IP header has source and destination addresses that are the tunnel endpoints. The inner packet is carried as the payload and can be any Layer 3 protocol (IPv4, IPv6, IPX, etc.) or even a broadcast frame.

GRE solves several problems: - Multi-protocol transport: GRE can encapsulate non-IP protocols (e.g., IPX, AppleTalk) across an IP-only network. Although CCNA focuses on IP, this capability is a key feature. - Routing protocol support: GRE tunnels allow routing protocols (OSPF, EIGRP) to run over the tunnel interface, enabling dynamic routing across a VPN. Without GRE, you would need static routes or complex configurations. - Connecting discontiguous networks: GRE can connect networks that have overlapping address spaces (by using NAT or VRF-lite, but GRE itself doesn't solve overlap). - Support for multicast and broadcast: GRE can encapsulate multicast and broadcast traffic, which is necessary for routing protocols like OSPF that use multicast.

- Flags (checksum, key, sequence number presence) - Protocol Type (e.g., 0x0800 for IPv4, 0x86DD for IPv6) 3. Add outer IP header: The router adds a new IP header with source address = tunnel source (the local tunnel endpoint IP) and destination address = tunnel destination (the remote tunnel endpoint IP). The protocol field in the outer IP header is set to 47 (GRE). 4. Transmission: The encapsulated packet is sent out the physical interface towards the tunnel destination. The transit network (internet) routes this packet based on the outer IP header. 5. Decapsulation: The remote router receives the packet with protocol 47. It recognizes it as a GRE packet, removes the outer IP header and GRE header, and retrieves the original payload packet. 6. Forwarding: The remote router then looks up the destination IP of the original packet in its routing table and forwards it out the appropriate interface.

The standard GRE header (RFC 2784) is 4 bytes:

Optional fields (if flags set):

On Cisco IOS, a GRE tunnel is configured as a logical interface. Example:

interface Tunnel0
 ip address 10.0.0.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 203.0.113.2
 tunnel mode gre ip

show ip interface brief
show interfaces tunnel 0
show ip route
show running-config interface tunnel 0

Example output of show interfaces tunnel 0:

Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 10.0.0.1/30
  MTU 1476 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 192.168.1.1, destination 203.0.113.2
  Tunnel protocol/transport GRE/IP
  Tunnel TTL 255

Note the MTU: GRE adds 24 bytes overhead (20 outer IP + 4 GRE) to the original packet, reducing the MTU from 1500 to 1476. This can cause fragmentation issues if the path MTU is not adjusted.

GRE alone provides no encryption or authentication. For secure VPNs, GRE is often combined with IPsec. Two common approaches: - GRE over IPsec: The GRE packet is encrypted by IPsec. This is flexible because IPsec can be applied to the physical interface or a crypto map. - IPsec over GRE: The original packet is encrypted first, then encapsulated in GRE. Less common.

Cisco recommends GRE over IPsec for site-to-site VPNs because it allows routing protocols to run over the tunnel and provides encryption.

GRE tunnels do not inherently detect if the remote endpoint is reachable. Cisco routers support GRE keepalives (tunnel keepalive) to monitor the tunnel's health. If keepalives are enabled, the router sends periodic GRE keepalive packets (which are encapsulated in GRE) and expects a reply. If no reply is received after a configured number of retries, the tunnel interface goes down. This is useful for triggering route failover. Configuration:

interface Tunnel0
 keepalive 10 3

This sends a keepalive every 10 seconds, and if 3 consecutive replies are missed, the tunnel is considered down.

Because a GRE tunnel is a virtual point-to-point link, you can run a routing protocol over it. For example, you can configure OSPF on the tunnel interface:

router ospf 1
 network 10.0.0.0 0.0.0.3 area 0

This allows dynamic routing of networks behind each GRE endpoint. Without GRE, you would need static routes to reach remote networks across an IPsec VPN.

In enterprise networks, GRE tunnels are commonly used to connect branch offices to a central headquarters over the internet. For example, a company with a main office in New York and a branch in London might set up a GRE tunnel between their edge routers. The tunnel interface on each router gets an IP address from a private subnet (e.g., 10.0.0.0/30). Static routes or dynamic routing protocols like OSPF are configured to advertise the internal networks (e.g., 192.168.1.0/24 in NY and 192.168.2.0/24 in London). The GRE tunnel allows the two sites to communicate as if they were directly connected. However, since GRE does not provide encryption, the traffic is sent in cleartext over the internet. To secure it, the GRE tunnel is often combined with IPsec. A typical deployment is 'GRE over IPsec', where the GRE packets are encrypted by an IPsec tunnel. This provides both the multiprotocol capability of GRE and the security of IPsec.

Another scenario is when an organization needs to carry non-IP traffic (e.g., legacy IPX) across an IP-only WAN. GRE can encapsulate IPX packets, allowing the legacy protocol to coexist with modern IP networks. Although rare today, this was a key use case in the past.

A common misconfiguration is forgetting to set the tunnel source and destination correctly, or using an unreachable destination IP. Another issue is MTU mismatch: GRE adds 24 bytes of overhead, so the path MTU must be at least 1476 bytes for a 1500-byte payload. If the physical interface has an MTU of 1500, the router will fragment packets that exceed 1476 bytes. To avoid fragmentation, you can set ip mtu 1476 on the tunnel interface. In production, you might also use ip tcp adjust-mss 1436 on the tunnel interface to prevent TCP MSS issues.

Performance considerations: GRE tunneling adds CPU overhead due to encapsulation/decapsulation. On modern routers, this is minimal, but on low-end devices, it can impact throughput. Also, GRE tunnels do not have built-in QoS, so you need to apply QoS policies on the physical interface.

When a GRE tunnel is misconfigured (e.g., wrong destination IP), the tunnel interface may be up/up but no traffic flows because the outer IP packets are not reaching the destination. Using ping from the tunnel source to the tunnel destination over the physical interface can help diagnose reachability issues.