Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Generic Routing Encapsulation (GRE)

 

Generic routing encapsulation (GRE) provides a secure path for transporting packets of data by tunneling the packets. The below topics discusses the tunneling of GRE, encapsulation and de-capsulation process, configuring GREs and verifying the working of GREs.

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 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. (For a list of limitations, see Configuration Limitations.)

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.

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.

Number of Source and Destination Tunnels Allowed on a Switch

QFX5100 and OCX Series switches support as many as 512 GRE tunnels, including tunnels created with a firewall filter. That is, you can create a total of 512 GRE tunnels, regardless of which method you use.

EX switches support 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.

An EX switch 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.

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.

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

Applying 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 InterfaceEgress Interface

Source (encapsulating)

inner header

outer header

Remote (de-encapsulating)

Cannot filter packets on ingress interface

inner header

Using a Firewall Filter to De-encapsulate GRE Traffic on a QFX5100, QFX10000, and OCX Series Switches

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.

Configuration Limitations

Table 2 lists features that are not supported with GRE.

Table 2: Features Not Supported with GRE

EX SwitchesQFX Switches

MPLS over GRE tunnels

MPLS over GRE tunnels

GRE keepalives

GRE keepalives

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

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

BGP dynamic tunnels

BGP dynamic tunnels

Outer IP address must be IPv4

Outer IP address must be IPv4

Virtual routing instances

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

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.

QFX series switches do not support configuring GRE interface and the underlying tunnel source interface in two different routing instances. If you try this configuration, it will result in a commit error.

Configuring Generic Routing Encapsulation Tunneling

Generic routing encapsulation (GRE) provides a private, secure 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.

You can also use a firewall filter to de-encapsulate GRE traffic on QFX5100 and OCX Series 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. For more information on 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:
    [edit chassis]

    user@switch# set fpc slot pic pic-number tunnel-port port-number tunnel-services

This topic describes:

  1. Configuring a GRE Tunnel

Configuring a GRE Tunnel

To configure a GRE tunnel interface:

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

    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.

Note

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.

Note

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

Verifying 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.

user@switch> show interfaces gr-0/0/0.0

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.