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
- Number of Source and Destination Tunnels Allowed on a Router
Encapsulation and De-Encapsulation on the Router
Encapsulation—A router operating as a tunnel source router encapsulates and forwards GRE packets as follows:
When a router receives a data packet (payload) to be tunneled, it sends the packet to the tunnel interface.
The tunnel interface encapsulates the data in a GRE packet and adds an outer IP header.
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:
When the destination router receives the IP packet from the tunnel interface, the outer IP header and GRE header are removed.
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,
[edit] user@host# show protocols ospf { area 0.0.0.0 { interface all; interface gr-0/0/10.0 { disable; } } }Note:This limitation is applicable for all routing protocols (such as OSPF, ISIS).
See Also
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:
user@host# edit chassis
fpc 0 {
pic 0 {
tunnel-services {
port port-number;
}
}
}
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:
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.
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.
See Also
Configuring GRE Keepalive Time
- Configuring Keepalive Time and Hold time for a GRE Tunnel Interface
- Display GRE Keepalive Time Configuration
- Display Keepalive Time Information on a GRE Tunnel Interface
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:
To configure keepalive time for a GRE tunnel interface:
Configure the Operation, Administration, and Maintenance (OAM) protocol at the
[edit protocols]hierarchy level for the GRE tunnel interface.[edit] user@host# edit protocols oam
Configure the GRE tunnel interface option for OAM protocol.
[edit protocols oam] user@host# edit gre-tunnel interface interface-name
Configure the keepalive time from 1 through 50 seconds for the GRE tunnel interface.
[edit protocols oam gre-tunnel interface interface-name] user@host# set keepalive-time seconds
Configure the hold time from 5 through 250 seconds. Note that the hold time must be at least twice the keepalive time.
[edit protocols oam gre-tunnel interface interface-name] user@host# set hold-time seconds
Display GRE Keepalive Time Configuration
Purpose
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).
Action
To display the configured values on the GRE tunnel interface,
run the show oam gre-tunnel command at the [edit protocols] hierarchy level:
[edit protocols]
user@host# show oam gre-tunnel
interface gr-1/1/10.1 {
keepalive-time 10;
hold-time 30;
}
Display Keepalive Time Information on a GRE Tunnel Interface
Purpose
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.
Action
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
user@host> show interfaces gr-3/3/0.3 terse
Interface Admin Link Proto Local Remote
gr-3/3/0.3 up up inet 192.0.2.1/24
mpls show interfaces gr-3/3/0.3 extensive
user@host> show interfaces gr-3/3/0.3 extensive
Logical interface gr-3/3/0.3 (Index 73) (SNMP ifIndex 594) (Generation 900)
Flags: Point-To-Point SNMP-Traps 0x4000 IP-Header 10.1.19.11:10.1.19.12:47:df:64:0000000000000000 Encapsulation: GRE-NULL
Gre keepalives configured: On, Gre keepalives adjacency state: down
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Traffic statistics:
Input bytes : 15629992
Output bytes : 15912273
Input packets: 243813
Output packets: 179476
Local statistics:
Input bytes : 15322586
Output bytes : 15621359
Input packets: 238890
Output packets: 174767
Transit statistics:
Input bytes : 307406 0 bps
Output bytes : 290914 0 bps
Input packets: 4923 0 pps
Output packets: 4709 0 pps
Protocol inet, MTU: 1476, Generation: 1564, Route table: 0
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Destination: 192.0.2/24, Local: 192.0.2.1, Broadcast: 192.0.2.255, Generation: 1366
Protocol mpls, MTU: 1464, Maximum labels: 3, Generation: 1565, Route table: 0When the hold time expires:
The GRE tunnel will stay up even though the interface cannot send or receive traffic.
The
Linkstatus will beUpand theGre keepalives adjacency statewill beDown.
Meaning
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:
[edit interfaces]
gr-fpc/pic/port {
unit logical-unit-number {
clear-dont-fragment-bit;
...
family inet {
mtu 1000;
...
}
}
}
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:
gr-fpc/pic/port: does not support this encapsulation
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).