Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Configuring GRE Tunnel Interfaces

Understanding Generic Routing Encapsulation

Generic routing encapsulation (GRE) provides a private, secure path for transporting packets through an otherwise public network by encapsulating (or tunneling) the packets.

This topic describes:

Overview of GRE

GRE encapsulates data packets and redirects them to a device that de-encapsulates them and routes them to their final destination. This allows the source and destination routers to operate as if they have a virtual point-to-point connection with each other (because the outer header applied by GRE is transparent to the encapsulated payload packet). For example, GRE tunnels allow routing protocols such as RIP and OSPF to forward data packets from one router to another router across the Internet. In addition, GRE tunnels can encapsulate multicast data streams for transmission over the Internet.

GRE is described in RFC 2784 (obsoletes earlier RFCs 1701 and 1702). The routers support RFC 2784, but not completely. (For a list of limitations, see Configuration Limitations.)

As a tunnel source router, the router encapsulates a payload packet for transport through the tunnel to a destination network. The payload packet is first encapsulated in a GRE packet, and then the GRE packet is encapsulated in a delivery protocol. The router performing the role of a tunnel remote router extracts the tunneled packet and forwards the packet to its destination.


Service chaining for GRE, NAT, and IPSec services on ACX1100-AC and ACX500 routers is not supported.


Layer 2 over GRE is not supported in ACX2200 router.

ACX routers support OSPF routing protocol when a GRE tunnel is configured on a WAN interface.

GRE Tunneling

Data is routed by the system to the GRE endpoint over routes established in the route table. (These routes can be statically configured or dynamically learned by routing protocols such as RIP or OSPF.) When a data packet is received by the GRE endpoint, it is de-encapsulated and routed again to its destination address.

GRE tunnels are stateless-–that is, the endpoint of the tunnel contains no information about the state or availability of the remote tunnel endpoint. Therefore, the router operating as a tunnel source router cannot change the state of the GRE tunnel interface to down if the remote endpoint is unreachable.

For details about GRE tunneling, see:

Encapsulation and De-Encapsulation on the Router

Encapsulation—A router operating as a tunnel source router encapsulates and forwards GRE packets as follows:

  1. When a router receives a data packet (payload) to be tunneled, it sends the packet to the tunnel interface.

  2. The tunnel interface encapsulates the data in a GRE packet and adds an outer IP header.

  3. The IP packet is forwarded on the basis of the destination address in the outer IP header.

De-encapsulation—A router operating as a tunnel remote router handles GRE packets as follows:

  1. When the destination router receives the IP packet from the tunnel interface, the outer IP header and GRE header are removed.

  2. The packet is routed based on the inner IP header.

Number of Source and Destination Tunnels Allowed on a Router

ACX routers support as many as 64 GRE tunnels between routers transmitting IPv4 or IPv6 payload packets over GRE.

Configuration Limitations

Some GRE tunneling features are not currently available on ACX Series routers. Be aware of the following limitations when you are configuring GRE on an ACX router:

  • Unsupported features—GRE on the ACX routers does not support the following features:

    • Virtual routing over GRE

    • Bidirectional Forwarding Detection (BFD) protocol over GRE distributed mode

    • MPLS over GRE tunnels

    • GRE keepalives

    • GRE keys, payload packet fragmentation, and sequence numbers for fragmented packets

    • BGP dynamic tunnels

    • RFC 1701 and RFC 1702

    • RFC 2890—Key and sequence number extensions to GRE

    • IPv6 as delivery header

    • GRE path MTU discovery

    • Load balancing when NNI is ECMP

    • Interface statistics on GRE interfaces

    • Class of service and firewall on GRE tunnel

  • Routing Protocol—ACX routers do not support routing protocols on GRE interfaces. You need to disable routing on GRE interfaces under the [edit protocols] hierarchy. For example,


    This limitation is applicable for all routing protocols (such as OSPF, ISIS).

Configuring Generic Routing Encapsulation Tunneling

Tunneling provides a private, secure path for transporting packets through an otherwise public network by encapsulating packets inside a transport protocol known as an IP encapsulation protocol. Generic routing encapsulation (GRE) is an IP encapsulation protocol that is used to transport packets over a network. Information is sent from one network to the other through a GRE tunnel.

GRE tunneling is accomplished through routable tunnel endpoints that operate on top of existing physical and other logical endpoints. GRE tunnels connect one endpoint to another and provide a clear data path between them.

This topic describes:

Configuring a GRE Tunnel Port

To configure GRE tunnels on a router, you convert a network port or uplink port on the router to a GRE tunnel port for tunnel services. Each physical tunnel port, named gr-fpc/pic/port, can have one or more logical interfaces, each of which is a GRE tunnel.

After conversion to a GRE tunnel port, the physical port cannot be used for network traffic.

To configure a GRE tunnel port on an router, you need to create logical tunnel interfaces and the bandwidth in gigabits per second to reserve for tunnel services. Include the tunnel-services bandwidth (1g | 10g) statement at the [edit chassis fpc slot-number pic number] hierarchy level.

To configure a GRE tunnel port , use any unused physical port on the router to create a logical tunnel interface as shown below:

This also creates a gr- interface.

Configuring Tunnels to Use Generic Routing Encapsulation

Normally, a GRE tunnel port comes up as soon as it is configured and stays up as long as a valid tunnel source address exists or an interface is operational. Each logical interface you configure on the port can be configured as the source or as the endpoint of a GRE tunnel.

To configure a tunnel port to use GRE:

  1. Configure a physical GRE port with a logical interface name and address:
    • For IPv4 over GRE, specify the protocol family inet:

    • For IPv6 over GRE, specify the protocol family inet6:

  2. Specify the tunnel source address for the logical interface:
  3. Specify the destination address:

GRE Keepalive Time Overview

Generic routing encapsulation (GRE) tunnel interfaces do not have a built-in mechanism for detecting when a tunnel is down. You can enable keepalive messages to serve as the detection mechanism.

When you enable a GRE tunnel interface for keepalive messages, the interface sends out keepalive request packets to the remote endpoint at regular intervals. If the data path forwarding for the GRE tunnel works correctly at all points, keepalive response packets are returned to the originator. These keepalive messages are processed by the Routing Engine.

You can configure keepalive messages on the physical or logical GRE tunnel interface. If configured on the physical interface, keepalive messages are sent on all logical interfaces that are part of the physical interface. If configured on an individual logical interface, keepalives are sent only on that logical interface.

You configure how often keepalive messages are sent and the length of time that the interface waits for a keepalive response before marking the tunnel as operationally down.

The keepalive request packet is shown in Figure 1.

Figure 1: Keepalive Request PacketKeepalive Request Packet

The keepalive payload includes information to ensure the keepalive response is correctly delivered to the application responsible for the GRE keepalive process.

The outer GRE header includes:

  • Source IP Address—IP address of the endpoint that initiates the keepalive request

  • Destination IP Address—IP address of the endpoint that receives the keepalive request

  • GRE Protocol ID—IP

The inner GRE header includes:

  • Source IP Address—IP address of the endpoint that receives the keepalive request

  • Destination IP Address—IP address of the endpoint that initiates the keepalive request

  • GRE Protocol ID—A value that the packet forwarding engine recognizes as a GRE keepalive packet


Starting in Junos OS Release 17.3R1, you can configure IPv6 generic routing encapsulation (GRE) tunnel interfaces on MX Series routers. This lets you run a GRE tunnel over an IPv6 network. Packet payload families that can be encapsulated within the IPv6 GRE tunnels include IPv4, IPv6, MPLS, and ISO. Fragmentation and reassembly of the IPv6 delivery packets is not supported.

To configure an IPv6 GRE tunnel interface, specify IPv6 addresses for source and destination at the [interfaces gr-0/0/0 unit 0 tunnel] hierarchy level.

Keepalive is not supported for GRE IPv6.

Configuring GRE Keepalive Time

Configuring Keepalive Time and Hold time for a GRE Tunnel Interface

You can configure the keepalives on a generic routing encapsulation (GRE) tunnel interface by including both the keepalive-time statement and the hold-time statement at the [edit protocols oam gre-tunnel interface interface-name] hierarchy level.


For proper operation of keepalives on a GRE interface, you must also include the family inet statement at the [edit interfaces interface-name unit unit] hierarchy level. If you do not include this statement, the interface is marked as down.

To configure a GRE tunnel interface:

  1. Configure the GRE tunnel interface at [edit interfaces interface-name unit unit-number] hierarchy level, where the interface name is gr-x/y/z, and the family is set as inet.
  2. Configure the rest of the GRE tunnel interface options as explained in Configuring a GRE Tunnel Interface Between a PE and CE Router or Configuring a GRE Tunnel Interface Between PE Routers based on requirement.

To configure keepalive time for a GRE tunnel interface:

  1. Configure the Operation, Administration, and Maintenance (OAM) protocol at the [edit protocols] hierarchy level for the GRE tunnel interface.

  2. Configure the GRE tunnel interface option for OAM protocol.

  3. Configure the keepalive time from 1 through 50 seconds for the GRE tunnel interface.

  4. Configure the hold time from 5 through 250 seconds. Note that the hold time must be at least twice the keepalive time.

Display GRE Keepalive Time Configuration


Display the configured keepalive time value as 10 and hold time value as 30 on a GRE tunnel interface (for example, gr-1/1/10.1).


To display the configured values on the GRE tunnel interface, run the show oam gre-tunnel command at the [edit protocols] hierarchy level:

Display Keepalive Time Information on a GRE Tunnel Interface


Display the current status information of a GRE tunnel interface when keepalive time and hold time parameters are configured on it and when the hold time expires.


To verify the current status information on a GRE tunnel interface (for example, gr-3/3/0.3), run the show interfaces gr-3/3/0.3 terse and show interfaces gr-3/3/0.3 extensive operational commands.

show interfaces gr-3/3/0.3 terse

show interfaces gr-3/3/0.3 extensive


When the hold time expires:

  • The GRE tunnel will stay up even though the interface cannot send or receive traffic.

  • The Link status will be Up and the Gre keepalives adjacency state will be Down.


The current status information of a GRE tunnel interface with keepalive time and hold time parameters is displayed as expected when the hold time expires.

Enabling Fragmentation on GRE Tunnels

To enable fragmentation of IPv4 packets in generic routing encapsulation (GRE) tunnels, include the clear-dont-fragment-bit statement and a maximum transmission unit (MTU) setting for the tunnel as part of an existing GRE configuration at the [edit interfaces] hierarchy level:

This statement clears the Don’t Fragment (DF) bit in the packet header, regardless of the packet size. If the packet size exceeds the tunnel MTU value, the packet is fragmented before encapsulation. The maximum MTU size configurable on the AS or Multiservices PIC is 9192 bytes.


The clear-dont-fragment-bit statement is supported only on MX Series routers and all M Series routers except the M320 router.


On SRX platforms the clearing of the DF bit on a GRE tunnel is supported only when the device is in packet or selective packet mode; This feature is not supported in flow mode. As a result, when in flow mode, a packet that exceeds the MTU of the GRE interface with the DF bit set is dropped, despite having the clear-dont-fragment-bit configured on the GRE interface.

Fragmentation is enabled only on IPv4 packets being encapsulated in IPv4-based GRE tunnels.


This configuration is supported only on GRE tunnels on AS or Multiservices interfaces. If you commit gre-fragmentation as the encapsulation type on a standard Tunnel PIC interface, the following console log message appears when the PIC comes online:

The Packet Forwarding Engine updates the IP identification field in the outer IP header of GRE-encapsulated packets, so that reassembly of the packets is possible after fragmentation. The previous CLI constraint check that required you to configure either the clear-dont-fragment-bit statement or a tunnel key with the allow-fragmentation statement is no longer enforced.

When you configure the clear-dont-fragment-bit statement on an interface with the MPLS protocol family enabled, you must specify an MTU value. This MTU value must not be greater than maximum supported value (9192).