Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

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

    You can also use a firewall filter to de-encapsulate GRE traffic on a QFX5100 switch. 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 on a QFX5100 Switch 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

    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.

    Published: 2014-07-23