12.1 GRE & IP-IP Tunneling Architecture

GRE & IP-IP Tunneling Architecture

In enterprise campus and wide area networks, network engineers frequently need to interconnect isolated IP network segments across intermediate transit networks that do not share the same addressing scheme, routing protocols, or administrative policies. IP tunneling addresses this challenge by encapsulating original payload packets inside a standard outer delivery protocol. Junos OS provides enterprise support for two fundamental point-to-point tunneling protocols: Generic Routing Encapsulation (GRE) and IP-in-IP (IP-IP).

---

1. Enterprise IP Tunneling Fundamentals & Use Cases

An IP tunnel functions as a logical point-to-point connection uniting two distant endpoints over an intervening routed IP network. While the physical path between endpoints may span multiple intermediate routers, firewalls, and service provider hops, the tunnel behaves as a direct, single-hop Layer 3 link from the perspective of the participating edge devices.

Enterprise architectures leverage IP tunneling for several critical deployment use cases:

1. Interconnecting Discontiguous Private Networks: Organizations operating isolated private IPv4 or IPv6 subnets across a public Internet transit provider or third-party service provider backbone use tunnels to route internal traffic transparently without acquiring public address allocations for all internal nodes.
2. Transporting Non-Routable or Multicast Traffic: Many transit backbones support only standard unicast IPv4 forwarding. OSPF uses link-local IP multicast for ordinary broadcast/P2P Hello exchange; IS-IS instead uses ISO Layer 2 framing to form neighbor adjacencies. A GRE tunnel encapsulates these multicast packets within standard unicast outer headers, allowing routing protocol neighbors to establish adjacencies across unicast-only transit fabrics.
3. Multiprotocol Transport (IPv6 over IPv4): During campus migrations, isolated IPv6 islands can be joined over an existing IPv4-only core by tunneling IPv6 payloads across IPv4 transport networks.
4. Secure Transport Substrates: GRE tunnels frequently serve as the underlying transport layer for IPsec encryption (GRE-over-IPsec). While GRE provides multi-protocol and multicast transport, standard IPsec tunnel mode natively lacks multicast capabilities; encapsulating GRE within IPsec combines dynamic routing support with cryptographic security.

---

2. Generic Routing Encapsulation (GRE) vs. IP-in-IP

Junos OS supports both GRE and IP-in-IP tunneling. Selecting between them requires understanding their protocol differences, header structures, and encapsulation constraints.

Generic Routing Encapsulation (GRE, RFC 2784 & RFC 2890)

GRE is a versatile, multiprotocol encapsulation framework formalized by the IETF in RFC 2784 and extended in RFC 2890. In GRE encapsulation, the outer delivery packet uses IP Protocol 47. The fundamental strength of GRE lies in its generic nature: it can encapsulate virtually any Layer 3 network protocol within its payload, including IPv4, IPv6, MPLS labels, and ISO CLNP.

The standard RFC 2784 GRE header is 4 bytes (32 bits) in length and contains:

• C (Checksum Present) bit (bit 0): Indicates whether a 4-byte checksum field is appended.
• Reserved bits (bits 1–12): Reserved for future standardization; set to zero.
• Version field (bits 13–15): Specifies the GRE version (set to 000 for standard GRE).
• Protocol Type field (bits 16–31): A 16-bit field containing the Ethertype value of the encapsulated payload (e.g., 0x0800 for IPv4, 0x86DD for IPv6, 0x8847 for MPLS unicast).

Because the Protocol Type field explicitly identifies the internal payload, GRE natively supports multicast routing traffic, enabling OSPF, IS-IS, and BGP peering across the logical link.

IP-in-IP Encapsulation (RFC 2003)

IP-in-IP is a much simpler, lightweight tunneling mechanism defined in RFC 2003. IP-in-IP encapsulates an internal IPv4 packet directly within an outer IPv4 delivery header. In the outer IP header, the Protocol field is set to IP Protocol 4 (indicating an encapsulated IPv4 payload).

Unlike GRE, IP-in-IP does not insert any intermediate encapsulation header between the outer IP header and the inner IP header. Consequently, IP-in-IP imposes less overhead than GRE. The inner protocol in this example is IPv4. That does not imply an inner multicast destination is forbidden: Junos documents IP-IP multicast tunnels. GRE’s additional Protocol Type field provides broader payload identification, while support for each payload and routing protocol still depends on platform. Do not infer native IS-IS support from an IPv4 tunnel example; ISO-family transport needs explicit support.

---

3. Encapsulation Overhead, MTU & TCP MSS Clamping

Encapsulating packets inside outer IP and GRE headers increases total frame size, presenting significant Maximum Transmission Unit (MTU) and Maximum Segment Size (MSS) challenges across transit networks.

Encapsulation Overhead Calculation

Consider a standard enterprise host transmitting an IPv4 packet containing a TCP segment across an Ethernet segment with the standard MTU of 1500 bytes:

+-----------------------------------------------------------------------------+
| Standard Host Frame:                                                        |
| [ IP Header: 20 bytes ] [ TCP Header: 20 bytes ] [ TCP Data: 1460 bytes ]   |
| Total Packet Length = 1500 bytes                                            |
+-----------------------------------------------------------------------------+
                                      |
                              GRE Encapsulation
                                      |
+-----------------------------------------------------------------------------+
| GRE Encapsulated Frame:                                                     |
| [ Outer IP: 20B ] [ GRE: 4B ] [ Inner IP: 20B ] [ TCP: 20B ] [ Data: 1460B] |
| Total Packet Length = 1524 bytes                                            |
+-----------------------------------------------------------------------------+

Standard GRE adds 24 bytes of overhead: a 20-byte outer IPv4 header plus a 4-byte GRE header. (If GRE keys or sequence numbers are enabled via RFC 2890, the GRE header expands to 8 or 12 bytes, yielding 28 to 32 bytes of overhead). IP-in-IP adds 20 bytes of overhead (the outer IPv4 header alone).

MTU Fragmentation vs. PMTUD Black Holes

When a tunnel ingress router receives an original 1500-byte packet and appends 24 bytes of GRE overhead, the resulting outer packet reaches 1524 bytes. If the physical outgoing interface has an MTU of 1500 bytes, the router faces two forwarding decisions:

1. Permitted fragmentation: Fragmentation behavior depends on inner DF, outer DF handling, tunnel options and hardware. If a 1524-byte outer IPv4 packet with a 20-byte header is fragmented over a 1500-byte IP MTU, fragment payloads must align to eight bytes: one valid pair has total lengths 1500 and 44 bytes. Reassembly adds work, and losing either fragment loses the original packet.
2. PMTUD: If applicable DF handling prohibits fragmentation, the router drops an oversized packet and returns an ICMP fragmentation-needed indication. For the basic 24-byte overhead example, the effective inner MTU is 1476. Filtering ICMP errors can cause small packets to work while large transfers stall.
3. Do not conflate layers: The 1500-byte value here is an IP MTU, not an Ethernet frame length. Outer options, GRE keys, additional encryption and provider encapsulation can reduce the usable inner size further.

Junos Solutions: Interface MTU & TCP MSS Clamping

Junos OS provides two complementary strategies to eliminate PMTUD black holes:

1. Adjusting Tunnel Interface MTU

For a measured 1500-byte underlay IP MTU and the stated no-options headers, configure a 1476-byte GRE inner MTU or a 1480-byte IP-IP inner MTU. These are calculated design values, not universal Junos interface defaults. Verify the actual interface MTU:

[edit interfaces gr-0/0/0 unit 0]
user@R1# set family inet mtu 1476

Additionally, Junos can clear the DF bit from incoming packets, permitting the ingress router to fragment transit packets if necessary:

[edit interfaces gr-0/0/0 unit 0]
user@R1# set clear-dont-fragment-bit

2. Junos TCP MSS Clamping (tcp-mss)

Because hosts calculate their Maximum Segment Size (MSS) during TCP connection establishment ($MSS = MTU - 20\text{ [IP]} - 20\text{ [TCP]} = 1460\text{ bytes}$), adjusting the tunnel MTU does not prevent hosts from advertising an MSS of 1460 bytes. Junos can dynamically intercept passing TCP SYN packets traversing the router and rewrite the MSS option to a smaller value (such as 1436 bytes: $1476 - 40 = 1436$).

On SRX branch gateways and enterprise security devices, TCP MSS clamping is configured globally:

[edit security flow]
user@SRX# set tcp-mss all-tcp mss 1436

MSS adjustment support and configuration on other platforms must be verified separately. A standard stateless filter policer does not rewrite TCP MSS. MSS clamping helps TCP; it does not repair arbitrary oversized UDP or ICMP traffic.

Output note: Command output shown here is a schematic teaching example, not a captured device session. Field names and feature support depend on platform and Junos release.

4. Configuring GRE Tunnels in Junos OS

In Junos OS, GRE tunnels are instantiated using dedicated pseudo-interfaces named with the gr- prefix (gr-fpc/pic/port). On modular routers or switches, the FPC and PIC indicate the physical slot hosting the tunnel services PIC or built-in ASIC forwarding engine (e.g., gr-0/0/0).

Step-by-Step Configuration Workflow

Configuring a functional GRE tunnel between Router 1 (WAN IP 198.51.100.1) and Router 2 (WAN IP 203.0.113.2) requires four sequential parameters under interfaces gr-0/0/0 unit 0:

1. Define the local public or routable IP address as the tunnel source.
2. Define the remote peer's public or routable IP address as the tunnel destination.
3. Assign an internal point-to-point IP address to the tunnel interface under family inet address.
4. Optionally tune the MTU and keepalive parameters.

Router 1 (R1) Junos Configuration:

[edit interfaces gr-0/0/0]
user@R1# show
unit 0 {
    description "Point-to-Point GRE Tunnel to Branch R2";
    tunnel {
        source 198.51.100.1;
        destination 203.0.113.2;
    }
    family inet {
        mtu 1476;
        address 10.10.10.1/30;
    }
}

Router 2 (R2) Junos Configuration:

[edit interfaces gr-0/0/0]
user@R2# show
unit 0 {
    description "Point-to-Point GRE Tunnel to Headquarters R1";
    tunnel {
        source 203.0.113.2;
        destination 198.51.100.1;
    }
    family inet {
        mtu 1476;
        address 10.10.10.2/30;
    }
}

Exam Trap & Operational Gotcha: In Junos, the tunnel destination address must be reachable via a valid route in the active routing table (inet.0). If the route to the tunnel destination resolves through the tunnel interface itself (a recursive routing loop), Junos disables the tunnel interface and marks it operationally DOWN to prevent routing thrashing.

---

5. Tunnel Keepalives & Running Dynamic Routing Protocols (OSPF/BGP)

The Silent Failure Problem & GRE Keepalives

Standard GRE is a stateless encapsulation protocol. By default, a GRE tunnel interface remains in the operationally UP/UP state as long as the local physical outgoing interface is up and a route to the tunnel destination exists in the routing table. If the remote peer router crashes, loses power, or suffers an intermediate path failure, the local router continues forwarding traffic into the tunnel, silently blackholing all packets.

On supported Junos platforms, GRE OAM keepalives provide additional liveness detection. Configure them under protocols oam gre-tunnel interface, not a Cisco-style tunnel keepalives interval count stanza:

[edit]
set protocols oam gre-tunnel interface gr-0/0/0.0 keepalive-time 5
set protocols oam gre-tunnel interface gr-0/0/0.0 hold-time 15

Verify supported intervals and behavior for the device. A five-second send interval and fifteen-second holdtime illustrate probe/liveness budgeting; they do not guarantee detection of every application failure. The GRE interface must include family inet. An operationally up tunnel without remote liveness verification only proves local readiness, not that the far endpoint can forward customer traffic.

For IP-IP, use the applicable ip- interface with the same source/destination pattern and an explicitly configured inner address:

[edit]
set interfaces ip-0/0/0 unit 0 tunnel source 198.51.100.1
set interfaces ip-0/0/0 unit 0 tunnel destination 203.0.113.2
set interfaces ip-0/0/0 unit 0 family inet address 10.10.20.1/30
set interfaces ip-0/0/0 unit 0 family inet mtu 1480

Reverse the outer endpoints on the peer and use 10.10.20.2/30. Confirm this tunnel interface is supported and instantiated on the hardware. Verify independent underlay reachability to the remote outer address, permit protocol 4 for IP-IP or 47 for GRE across transit filters, and add routes for the remote customer prefixes. Neither protocol encrypts or authenticates customer traffic by itself.

Compare show interfaces ip-0/0/0 extensive, show interfaces gr-0/0/0 extensive, underlay routes and overlay routes. Use ping with the tunnel source and appropriate packet size/DF to test inner delivery; use traceroute to distinguish underlay hops from overlay forwarding. Consult tunnel OAM state, show log messages, and supported bounded protocol traceoptions when the routing session over the tunnel is the failing component.

Running Dynamic Routing Protocols over GRE

Because GRE preserves multicast headers, enterprise engineers can bind dynamic routing protocols directly to the logical tunnel interface. Running OSPF across gr-0/0/0.0 enables dynamic prefix exchange between headquarters and remote branch networks:

[edit protocols ospf]
user@R1# show
area 0.0.0.0 {
    interface gr-0/0/0.0 {
        interface-type p2p;
        metric 100;
    }
    interface lo0.0 {
        passive;
    }
}

By default, Junos treats tunnel interfaces as point-to-point (p2p) OSPF links, which avoids the overhead of Designated Router (DR) and Backup Designated Router (BDR) elections on the tunnel segment.

---

6. Operational Verification & Troubleshooting Diagnostics

To verify the operational status and encapsulation counters of a GRE tunnel in Junos, execute show interfaces gr-0/0/0 extensive:

user@R1> show interfaces gr-0/0/0 extensive
Physical interface: gr-0/0/0, Enabled, Physical link is Up
  Interface index: 145, MTU: Unlimited
  Type: GRE, Link-level type: GRE, MTU: 0, Clock: Unspecified, Speed: Unspecified
  Device flags   : Present Running
  Interface flags: Point-To-Point

  Logical interface gr-0/0/0.0 (Index 78) (SNMP ifIndex 542)
    Flags: Point-To-Point SNMP-Traps Encapsulation: GRE-IPv4
    Bandwidth: 0
    Input packets : 14250
    Output packets: 14312
    Protocol inet, MTU: 1476
      Flags: None
      Addresses, Flags: Is-Preferred Is-Primary
        Destination: 10.10.10.2/30, Local: 10.10.10.1
    Tunnel:
      Source: 198.51.100.1, Destination: 203.0.113.2
      Keepalive: Enabled, Interval: 5 sec, Count: 3
      Keepalive status: Up

Key diagnostic fields to check during troubleshooting:

• Physical link is Up: Confirms local hardware tunnel services are functional.
• Logical interface gr-0/0/0.0 Flags: Point-To-Point: Confirms the interface’s local point-to-point type, not a negotiated peer session.
• Keepalive status: Up: Validates bidirectional packet receipt between the tunnel endpoints.
• Protocol inet, MTU: 1476: Confirms the 24-byte MTU deduction is active, safeguarding against unfragmentable oversized frames.

Official references checked 2026-10-18: GRE configuration and OAM, IP-IP multicast support.