Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring GRE Keepalive Time

 

Generic routing encapsulation (GRE) tunnel interfaces do not have a built-in mechanism for detecting when a tunnel is down. Keepalive messages help the GRE tunnel interfaces to detect when a tunnel is down. The topics below discuss the working and configuration of GRE keepalive time.

Understanding GRE Keepalive Time

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.

Keepalive times are only configurable for the ATM-over-ADSL interface, which is no longer supported on SRX300, SRX320, SRX340, SRX345, SRX380, and SRX550HM starting in Junos OS Release 15.1X49-D10. Keepalive times are enabled by default for other interfaces.

Keepalives can be configured on the physical or on the logical interface. If configured on the physical interface, keepalives are sent on all logical interfaces that are part of the physical interface. If configured on a individual logical interface, keepalives are only sent to that logical interface. In addition to configuring a keepalive, you must configure the hold time.

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.

Note

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.

Configuring GRE Keepalive Time

Keepalive times are only configurable for the ATM-over-ADSL interface, which is no longer supported on SRX300, SRX320, SRX340, SRX345, SRX380, and SRX550HM starting in Junos OS Release 15.1X49-D10.

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.

Note

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

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:

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

show interfaces gr-3/3/0.3 extensive

user@host> show interfaces gr-3/3/0.3 extensive
Note

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.

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.

Example: GRE Configuration

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 encapsulates a payload as a GRE packet. This GRE packet is encapsulated in an outer protocol (delivery protocol). GRE tunnel endpoints forward payloads into GRE tunnels for routing packets to the destination. After reaching the end point, GRE encapsulation is removed and the payload is transmitted to its final destination. The primary use of GRE is to carry non-IP packets through an IP network; however, GRE is also used to carry IP packets through an IP cloud.

Requirements

  • Configure a GRE (gr-) interface. The gr- interface contains a local address and destination address. It comes up as soon as it is configured. You can even configure an IP address on the gr- interface.

  • Configure a route to reach the destination subnet (end-to-end connectivity). You can configure either a static route through the gr- interface or use an interior gateway protocol (IGP) such as OSPF.

Overview

GRE tunnels are designed to be completely stateless, which means that each tunnel endpoint does not keep any information about the state or availability of the remote tunnel endpoint. Normally, a GRE tunnel interface comes up as soon as it is configured, and it stays up as long as there is a valid tunnel source address or interface that is up.

Configuration

By default, the local subnet interface is ge-0/0/0 with IPv4 address as 10.10.11.1/24. The destination subnet is 10.10.10.0/24 with the tunnel endpoint IPv4 interface as 10.10.10.1/24.

Figure 1 shows the default configuration between the tunnel interfaces on SRX series devices.

Figure 1: GRE Configuration
GRE Configuration

Configuring a Route to Reach the Destination Subset

Step-by-Step Procedure

You can either configure a static route through the gr- interface or by using IGP.

  1. Configure the local subnet interface ge-0/0/0 interface.
  2. Configure the interface ge-0/0/1.
  3. Configure the gr- tunnel endpoints and specify the source address, destination address, and family as inet for the tunnel endpoints.
  4. The configured interfaces are bound to a security zone at the [edit security] hierarchy level. Use the show zones command to view the zones. Configure the zones as follows:
  5. View the configured interfaces at the [edit interfaces] hierarchy level using the show command.
  6. In case you do not want to define a static route, OSPF can be configured between gr-0/0/0 interfaces on both the sides and internal subnet as passive neighbor, to receive all the internal routes. Configure OSPF at the [edit protocols] hierarchy level and view it using the show command.

Results

In configuration mode, confirm your configuration on the devices by entering the show command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

GRE configuration using the static route:

GRE configuration using OSPF configured between interfaces gr-0/0/0 on both sides and internal subnet as passive neighbor:

Verification

To verify that the configuration of GRE on the SRX Series device is successful, perform the following tasks:

Verification of the GRE Interfaces

Purpose

Verify that the GRE interfaces are up.

Action

Run the show interfaces command at the [edit interfaces] hierarchy level:

show interfaces gr-0/0/0 terse

Verification of the Route

Purpose

Verify that the route for the destination network is reachable through the GRE tunnel interface.

Action

Run the show route forwarding-table matching 10.10.10.0/24 command at the [edit interfaces] hierarchy level:

Verification of Traffic Through GRE Tunnel

Purpose

Send the traffic to the destination subnet and verify when the GRE interface is up.

Action

Run the show interfaces gr-0/0/0 extensive operational command. Also verify that the packets are leaving through the gr- interface.

user@host> show interfaces gr-0/0/0 extensive

Example: Configuring GRE over IPsec Tunnels

Overview

GRE tunnels offer minimal security, whereas an IPsec tunnel offers enhanced security in terms of confidentiality, data authentication, and integrity assurance. Also, IPsec cannot directly support multicast packets. However, if an encapsulated GRE tunnel is used first, an IPsec tunnel can then be used to provide security to the multicast packet. In a GRE over IPsec tunnel, all of the routing traffic (IP and non-IP) can be routed through. When the original packet (IP/non-IP) is GRE encapsulated, it has an IP header as defined by the GRE tunnel, normally the tunnel interface IP addresses. The IPsec protocol can understand the IP packet; so it encapsulates the GRE packet to make it GRE over IPsec.

The basic steps involved in configuring GRE over IPsec are as follows:

  • Configure the route-based IPsec tunnel.

  • Configure the GRE tunnel.

  • Configure a static route with the destination as the remote subnet through the gr- interface.

  • Configure the static route for the GRE endpoint with the st0 interface as next hop.

Configuration

In this example, the default configuration has the local subnet interface as ge-0/0/0 with the IPv4 address as 10.10.11.1/24. The destination subnet is 10.10.10.0/24. The gr-0/0/0 interface tunnel endpoints are loopback addresses on both the sides, with the local loopback IPv4 address as 172.20.1.1 and the remote loopback IPv4 address as 172.20.1.2. The gr-0/0/0, st0 and lo0 interfaces are bound to a security zone and policies are created accordingly. Refer to Example: GRE Configuration for more information.

Configuring a GRE interface over an IPsec tunnel

Step-by-Step Procedure

  1. Configure the GRE at the [set interfaces interface-name unit unit-number] hierarchy level, where the interface name is ge-0/0/0, and the family is set as inet.
  2. Configure the gr- tunnel endpoints and specify the source address, destination address, and family as inet for the tunnel endpoints.
  3. Similarly configure the lo0 and st0 interface with the family set as inet.
  4. Confifure the GRE interfaces with security zones. Use the show zones command to view the zones, where the configured tunnel interfaces, lo0 and st0 are displayed.

Results

In configuration mode, confirm your interface configuration by entering the show command. The configured interfaces are bound to a security zone at the [edit security] hierarchy level. Use the show zones command to view the zones, where the configured interfaces (gr-, st0.0, and lo0) are displayed. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

Parameters for configuring the GRE interfaces:

user@host> show interfaces

Parameters for configuring the GRE interfaces with security zones:

Verification

Verification of the IPsec Tunnel

Purpose

Verify that the IPsec tunnel is up.

Action

Run the commands show security ike security-associations and show security ipsec security-associations commands.

Example: Configuring a GRE Tunnel When the Tunnel Destination Is in a Routing Instance

Overview

You can configure a GRE tunnel when the tunnel destination is in a default routing instance or non-default routing instance. Configuration of a GRE tunnel requires defining the tunnel source and the tunnel destination addresses. If the tunnel destination is in a routing instance, and there is more than one routing instance present, you need to specify the correct routing instance and also the routing table to be used to reach the configured tunnel destination address.

Note

The tunnel destination address is by default considered to be reachable using the default routing table "inet.0".

Configuration

In this example, you can configure a GRE tunnel between the gr- interfaces on SRX Series devices with two instances. The instances are when the tunnel destination is in a default routing instance and when the tunnel destination is in a non-default routing instance.

Configuring a GRE Tunnel When the Tunnel Destination Is in a Default Routing Instance

This example uses the default routing instance to reach the tunnel destination. Because of this, the routing table inet.0 is used by default.

Step-by-Step Procedure

  1. Specify the source and destination address of the tunnel.
  2. Configure the ge- interface and lo0 interface with the family set as inet.
  3. Configure the GRE tunnel interface for routing options as mentioned in the GRE Configuration topic.

Configuring a GRE Tunnel When the Tunnel Destination Is in a Non-default Routing Instance

For a non-default routing instance, ensure that you have already configured the gr-0/0/0 interface.

Step-by-Step Procedure

  1. Configure the GRE tunnel with the gr-0/00 interface and family set as inet.
  2. Specify the source and destination address of the tunnel.
  3. Configure the ge- interface and lo0 interface with the family set as inet.
  4. Configure the routing instances used for the tunnel interface.
  5. Configure the routing-instance for GRE tunnel interfaces.
  6. Add the static route for tunnel destination.
    Note

    When the SRX Series device is in packet mode, you do not need to configure a static route to make the tunnel destination reachable from inet.0. However, you still need to specify the correct routing instance under the gr-0/0/0 interface.

Results

In configuration mode, confirm your configuration on the devices by entering the show command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

When the tunnel destination is in a default routing instance:

When the tunnel destination is in a non-default routing instance:

Verification

Verification of Static Route Use

Purpose

Verify that the static route is used.

Action

Run the show route forwarding table command.

user@host> show route forwarding-table table test

Verification of Static Route Used in Default Instance

Purpose

Verify that the static route is used for the default instance.

Action

Run the show route forwarding table command.

user@host> show route forwarding-table matching 10.10.1.2