Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Generic Routing Encapsulation (GRE)

Learn about GRE, GRE tunneling, encapsulation and de-encapsulation, and configuration of GRE.

Generic routing encapsulation (GRE) is a virtual point to point link that encapsulates data traffic in a tunnel . The below topics discusses the tunneling of GRE, encapsulation and de-capsulation process, configuring GREs and verifying the working of GREs.

GRE Overview

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

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 switches 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 switch to another switch 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 switches support RFC 2784, but not completely.

As a tunnel source router, the switch 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 switch performing the role of a tunnel remote router extracts the tunneled packet and forwards the packet to its destination. Note that you can use one firewall term to terminate many GRE tunnels on a QFX5100 switch.

Review Platform-Specific GRE Behavior section for notes related to your plaform.

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 switch 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 Switch

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

  1. When a switch 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 switch operating as a tunnel remote router handles GRE packets as follows:

  1. When the destination switch 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.

Class of Service on GRE Tunnels

When a network experiences congestion and delay, some packets might be dropped. Junos OS class of service (CoS) divides traffic into classes to which you can apply different levels of throughput and packet loss when congestion occurs and thereby set rules for packet loss. For details about CoS, see Junos OS CoS for EX Series Switches Overview.

The following CoS components are available on a switch operating as a GRE tunnel source router or GRE tunnel remote router:

  • At the GRE tunnel source—On a switch operating as a tunnel source router, you can apply CoS classifiers on an ingress port or on a GRE port, with the following results on CoS component support on tunneled packets:

    • Schedulers only—Based on the CoS classification on the ingress port, you can apply CoS schedulers on a GRE port of the switch to define output queues and control the transmission of packets through the tunnel after GRE encapsulation. However, you cannot apply CoS rewrite rules to these packets.

    • Schedulers and rewrite rules—Depending on the CoS classification on the GRE port, you can apply both schedulers and rewrite rules to the encapsulated packets transmitted through the tunnel.

    You cannot configure BA classifiers on gr- interfaces. You must classify traffic on gr- interfaces using firewall filters (multifield classifiers).

  • At the GRE tunnel endpoint—When the switch is a tunnel remote router, you can apply CoS classifiers on the GRE port and schedulers. You can also rewrite rules on the egress port to control the transmission of a de-encapsulated GRE packet out from the egress port.

Apply Firewall Filters to GRE Traffic

Firewall filters provide rules that define whether to permit, deny, or forward packets that are transiting an interface on a switch. (For details, see Firewall Filters for EX Series Switches Overview.) Because of the encapsulation and de-encapsulation performed by GRE, you are constrained as to where you can apply a firewall filter to filter tunneled packets and which header will be affected. Table 1 identifies these constraints.

Table 1: Firewall Filter Application Points for Tunneled Packets
Endpoint Type Ingress Interface Egress Interface

Source (encapsulating)

inner header

outer header

Remote (de-encapsulating)

Cannot filter packets on ingress interface

inner header

Use a Firewall Filter to De-Encapsulate GRE Traffic

You can also use a firewall filter to de-encapsulate GRE traffic on switches . This feature provides significant benefits in terms of scalability, performance, and flexibility because you don't need to create a tunnel interface to perform the de-encapsulation. For example, you can terminate many tunnels from multiple source IP addresses with one firewall term. See Configuring a Firewall Filter to De-Encapsulate GRE Traffic for information about how to configure a firewall filter for this purpose.

Configure Generic Routing Encapsulation (GRE) Tunneling

Generic routing encapsulation (GRE) provides a private path for transporting packets through an otherwise public network by encapsulating (or tunneling) the packets. GRE tunneling is accomplished through tunnel endpoints that encapsulate or de-encapsulate traffic.

Use GRE to confirm platform and release support for specific features.

You can also use a firewall filter to de-encapsulate GRE traffic. This feature provides significant benefits in terms of scalability, performance, and flexibility because you don't need to create a tunnel interface to perform the de-encapsulation. For example, you can terminate many tunnels from multiple source IP addresses with one firewall term. For more information about this feature, see Configuring a Firewall Filter to De-Encapsulate GRE Traffic.

To configure a GRE tunnel port on a switch:

  1. Determine the network port or uplink port on your switch to convert to a GRE tunnel port.

  2. Configure the port as a tunnel port for GRE tunnel services:

For QFX10000, gr-0/0/0 interface is created by default. Also, you need not configure the set fpc slot pic pic-number tunnel-port port-number tunnel-servicesstatement.

This topic describes:

Configure a GRE Tunnel

To configure a GRE tunnel interface:

  1. Create a GRE interface with a unit number and address:

    The base name of the interface must be gr-0/0/0.

    This is a pseudo interface, and the address you specify can be any IP address. The routing table must specify gr-0/0/0.x as the outgoing interface for any packets that will be tunneled.

    If you configure a GRE interface on a QFX5100 switch that is a member of a Virtual Chassis and later change the Virtual Chassis member number of the switch, the name of the GRE interface does not change in any way (because it is a pseudo interface). For example, if you change the member number from 0 to 5, the GRE interface name does not change from gr-0/0/0.x to gr-5/0/0.x.

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

    The destination address must be reachable through static or dynamic routing. If you use static routing, you must get the destination MAC address (for example, by using ping) before user traffic can be forwarded through the tunnel.

On QFX10002 and QFX10008 switches, If you configure GRE tunneling with the underlying ECMP next-hop instead of Unicast next-hop, GRE tunnel encapsulation fails and the network traffic is dropped.

Indirect egress next-hops is currently not supported in the GRE implementation for QFX10000 switches.

Verify That Generic Routing Encapsulation Tunneling Is Working Correctly

Purpose

Verify that the generic routing encapsulation (GRE) interface is sending tunneled traffic.

Action

Display status information about the specified GRE interface by using the command show interfaces .

Meaning

The output indicates that the GRE interface gr-0/0/0 is up. The output displays the name of the physical interface and the traffic statistics for this interface---the number of and the rate at which input and output bytes and packets are received and transmitted on the physical interface.

Platform-Specific GRE Behavior

Use Generic routing encapsulation (GRE) to confirm platform and release support for specific features.

Use the following table to review platform-specific behaviors for your platform:

Platform Difference
QFX Series Switches

  • On QFX10002, QFX10008, and QFX5K Series switches that support GRE, If you configure GRE tunneling with the underlying ECMP next-hop instead of a Unicast next-hop, GRE tunnel encapsulation fails. This causes network traffic to drop.

  • QFX Series switches that support GRE do not configure the GRE interface and the tunnel source interface in separate routing instances. Attempting this setup causes a commit error.

  • QFX5100 Series switches that support GRE can accommodate a total of 512 tunnels, including tunnels created with a firewall filter. between switches transmitting IPv4 or IPv6 payload packets over GRE. If a passenger protocol in addition to IPv4 and IPv6 is used, you can configure up to 333 GRE tunnels between the switches.

  • QFX Series switches that support GRE do not support the following features:

    • MPLS over GRE tunnels

    • GRE keepalives

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

    • BGP dynamic tunnels

    • Outer IP address must be IPv4
EX Series Switches

EX Series switches that support GRE:

  • Can accommodate as many as 500 GRE tunnels between switches transmitting IPv4 or IPv6 payload packets over GRE. If a passenger protocol in addition to IPv4 and IPv6 is used, you can configure up to 333 GRE tunnels between the switches.

  • Can have a maximum of 20 tunnel source IP addresses configured, and each tunnel source IP can be configured with up to 20 destination IP addresses on a second switch. As a result, the two connected switches can have a maximum of 400 GRE tunnels. If the first switch is also connected to a third switch, the possible maximum number of tunnels is 500.

  • Do not support the following features:

    • MPLS over GRE tunnels

    • GRE keepalives

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

    • BGP dynamic tunnels

    • Outer IP address must be IPv4

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

    • OSPF limitation—Enabling OSPF on a GRE interface creates two equal-cost routes to the destination: one through the Ethernet network or uplink interface and the other through the tunnel interface. If data is routed through the tunnel interface, the tunnel might fail. To keep the interface operational, we recommend that you use a static route, disable OSPF on the tunnel interface, or configure the peer not to advertise the tunnel destination over the tunnel interface.