Configure GRE Tunnels

Tunneling provides a mechanism to transport packets of one protocol within another protocol. This chapter describes GRE tunneling protocol.

Release

Feature(s) Added

Release 7.3.1

GRE Tunnel feature was introduced.

GRE tunnels

Table 1. Feature History Table

Feature Name

Release Information

Description

Network Virtualization using Generic Routing Encapsulation hash field selections

Release 26.2.1

You can now improve load balancing for Network Virtualization using Generic Routing Encapsulation (NVGRE) traffic by excluding the NVGRE payload from the hash calculation. This feature optimizes traffic distribution across multiple paths, preventing uneven load caused by hashing on the NVGRE payload.

The feature works by modifying the Cisco Express Forwarding (CEF) load-balancing hash algorithm to exclude the NVGRE payload field. This adjustment ensures that the hash calculation uses only relevant header fields, leading to better traffic distribution and network performance.

This feature introduces these changes:

CLI:

  • cef platform load-balancing nvgre payload exclude

  • show cef platform load-balancing

GRE tunnel

 Release 26.1.1

Introduced in this release on: Centralized Systems (8400 [ASIC:K100]) )(select variants only*)

*This feature is now supported on Cisco 8404-SYS-D routers.

GRE tunnel

Release 25.4.1

Introduced in this release on: Fixed Systems (8700 [ASIC: K100], 8010 [ASIC: A100])(select variants only*)

*This feature is supported on:

  • 8711-48Z-M

  • 8011-32Y8L2H2FH

  • 8011-12G12X4Y-A/D

Disabling time-to-live (TTL) decrement at GRE encapsulation

Release 25.1.1

Introduced in this release on: Fixed Systems (8700 [ASIC: K100], 8010 [ASIC: A100])(select variants only*)

*This feature is supported on:

  • 8712-MOD-M

  • 8011-4G24Y4H-I

Disabling time-to-live (TTL) decrement at GRE encapsulation

Release 24.4.1

Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100])(select variants only*); Modular Systems (8800 [LC ASIC: P100])(select variants only*)

*This feature is now supported on:

  • 8212-48FH-M

  • 8711-32FH-M

  • 88-LC1-12TH24FH-E

  • 88-LC1-36EH

  • 88-LC1-52Y8H-EM

Disabling time-to-live (TTL) decrement at GRE encapsulation

Release 7.3.2

This feature allows you to disable the time-to-live (TTL) decrement of the incoming packets. The result is that encapsulation of the original incoming packet takes place without any change in the TTL value.

This feature avoids dropping incoming packets with a TTL value equal to one after GRE encapsulation.

Before this release, the TTL value of incoming packets was decremented by one before GRE decapsulation.

This feature introduces the tunnel ttl disable command.

GRE tunnel

Release 24.4.1

Introduced in this release on: Fixed Systems(8200, 8700)(select variants only*); Modular Systems (8800 [LC ASIC: P100])(select variants only*).

The Generic Routing Encapsulation (GRE) feature that transports packets of one protocol over another protocol in a simplified manner using encapsulation is now supported on the following hardware.

*This feature is now supported on:

  • 8212-48FH-M

  • 8711-32FH-M

  • 8712-MOD-M

  • 88-LC1-12TH24FH-E

  • 88-LC1-52Y8H-EM

  • 88-LC1-36EH

GRE tunnel

Release 7.3.1

Generic Routing Encapsulation (GRE) provides a simple approach to transporting packets of one protocol over another protocol using encapsulation. This capability is now extended to the Cisco 8000 Series Routers.

This feature supports:

  • Unidirectional GRE encapsulation

  • Unidirectional GRE decapsulation

And introduces the following commands:

  • show interface tunnel-ip <> accounting (encap)

  • show interface tunnel-ip <> accounting (decap)

Outer-header hashing support for MPLSoGRE and IPoGRE traffic

Release 7.3.1

This feature allows load-balancing of GRE traffic in transit routers. A transit node distributes incoming GRE traffic evenly across all available ECMP links in a GRE tunnel topology. A hashing function uses GRE outer and inner header tuples such as source IP, destination IP, protocol, and router ID to determine traffic entropy. This capability is now extended to the Cisco 8000 Series Routers.

Generic Routing Encapsulation (GRE) is a tunneling protocol that provides a simple generic approach to transport packets of one protocol over another protocol by means of encapsulation. GRE encapsulates a payload, that is, an inner packet that should be delivered to a destination network inside an outer IP packet. The GRE tunnel behaves as virtual point-to-point link that has two endpoints identified by the tunnel source and tunnel destination address. The tunnel endpoints send payloads through GRE tunnels by routing encapsulated packets through intervening IP networks. Other IP routers along the way do not parse the payload (the inner packet); they only parse the outer IP packet as they forward it toward the GRE tunnel endpoint. Upon reaching the tunnel endpoint, GRE encapsulation is removed and the payload is forwarded to the packet's ultimate destination.

A tunnel configured using encapsulation mode performs encapsulation of IPv4/IPv6 payload inside the GRE header. A tunnel configured using decapsulation mode performs the opposite. Here, outer GRE header is decapsulated and the inner IPv4/IPv6/MPLS payload is forwarded to the next hop router. Both encapsulation and decapsulation tunnel interfaces collect statistics periodically. The statistics can be displayed on demand using the CLI commands show interface tunnel-ip1 accounting and show policy-map type pbr address-family ipv4 statistics. For more information, see Unidirectional GRE Encapsulation (GREv4) and Unidirectional GRE Decapsulation (GREv4).

To perform load-balancing of GRE traffic in transit routers, a transit node distributes incoming GRE traffic evenly across all available ECMP links in a GRE tunnel topology. Furthermore, to determine traffic entropy, a hashing function uses GRE outer and inner header tuples such as source IP, destination IP, protocol, and router ID.

GRE encapsulation and decapsulation over BVI

Table 2. Feature History Table

Feature Name

Release Information

Description

GRE encapsulation and decapsulation over BVI

Release 24.4.1

Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100, K100])(select variants only*); Modular Systems (8800 [LC ASIC: P100])(select variants only*)

*This feature is now supported on:

  • 8212-48FH-M

  • 8711-32FH-M

  • 8712-MOD-M

  • 88-LC1-12TH24FH-E

  • 88-LC1-36EH+A8:B12

  • 88-LC1-52Y8H-EM

GRE encapsulation and decapsulation over BVI

Release 7.5.4

You can now transport packets using the GRE protocol over Bridge-Group Virtual Interfaces (BVI).

This feature uses GRE to encapsulate packets between two endpoints and transmit the encapsulated packets over a BVI interface. At the destination, the GRE packet is decapsulated.

GRE encapsulation and decapsulation over BVI allows transmitting packets securely using network layer protocols while maintaining Layer 2 connectivity between the physical interfaces.

From Cisco IOS XR Release 7.5.4, GRE packets are supported over a BVI interface. This support provides GRE encapsulation and decapsulation over the BVI interfaces.

The BVI is a virtual interface within the router that acts like a normal routed interface. The BVI does not support bridging itself, but acts as a gateway for the corresponding bridge-domain to a routed interface within the router. A BVI is associated with a single bridge domain and represents the link between the bridging and the routing domains on the router.

When using GRE over BVI, the GRE header is added to the original IP packet before it is sent to the BVI. The BVI then bridges the encapsulated packet to the destination interface, which is a BVI, physical interface, or a remote network.

When the encapsulated packet reaches its destination, the receiving interface performs GRE decapsulation, which involves removing the GRE header from the original IP packet. The resulting IP packet is then forwarded to its final destination.

For information on BVI, see the Integrated Routing and Bridging section in the L2VPN Configuration Guide for Cisco 8000 Series Routers.

Supported Features on a GRE Tunnel

GRE tunnel supports the following features:

  • GRE or IP-in-IP tunnels support 16 unique source addresses. These 16 unique source addresses are repeated multiple times to configure 1000 encapsulation tunnels or 64 decapsulation tunnels.

  • GRE encapsulation supports the following features:

    • IPv4/IPv6 over GRE IPv4 transport

    • MPLS PoP over GRE IPv4 transport

    • ABF (Access List Based Forwarding) v4/v6 over GRE

    • VRF (Virtual Routing and Forwarding) support over GRE

  • GRE decapsulation supports the following features:

    • PBR-based GRE decapsulation configuration

    • CLI-based GRE decapsulation configuration

    • IPv4/IPv6 over GRE decapsulation

    • MPLS/SRTE over GRE decapsulation

    • A GRE tunnel in decapsulation mode has only tunnel source configured, without any tunnel destination address. This decapsulated GRE tunnel behaves like a P2MP (Point-to-multipoint) tunnel, which means that an incoming GRE packet can have any source IP address and matching destination IP address to the tunnel source configured. However, once a source IP address is used for decapsulated P2MP tunnel, it cannot be re-used with other decapsulation tunnels.

  • The command tunnel ttl disable is supported. This command controls TTL decrement of a packet being encapsulated. After configuring this command fo a tunnel interface, TTL value of incoming packet is not decremented by one, and original incoming packet is encapsulated without changing the TTL. By default, tunnel ttl disable isn’t configured. This means that the TTL of incoming packets is decremented by one before GRE encapsulation.

    For example, consider an incoming packet that had the TTL value equal to one. On GRE encapsulation, the TTL value is decremented by one and becomes zero. Therefore the router will discard the packet and send an ICMP message back to the originating host. Using this feature, you can disable TTL decrement and avoid the packet discard.

    Configuration Example
    Router#configure
Router(config)#interface tunnel-ip30016
Router(config-if)#tunnel ttl disable
Router(config-if)#commit

Limitations for Configuring GRE Tunnels

This list describes the limitations for configuring GRE tunnels:

  • GRE tunnels configured without any decapsulation or encapsulation mode support only ERPSAN feature.

  • Don't create multiple GRE/IP-in-IP tunnels with the same pair of source and destination IP address or interface name. Configure all tunnels with unique source-destination pairs. In an encapsulation or decapsulation tunnel where only either source or destination is mentioned, the source-destination pair should also be unique when compared to other encapsulation or decapsulation tunnels.

  • Bi-directional GRE tunnel isn't supported.

  • Routing protocols over GRE tunnels aren't supported.

  • Multicast over GRE isn't supported.

  • GRE KA (Keep Alive) isn't supported.

  • GRE parameters such as MTU (Maximum Transmission Unit) and key functionalities aren't supported.

Configure GRE Tunnels

Configuring a GRE tunnel involves creating a tunnel interface and defining the tunnel source and destination. This example shows how to configure a GRE tunnel between source and destination. The router supports only uni-directional GRE with either encapsulation or decapsulation mode. 

Router# configure
Router(config)# interface tunnel-ip1
Router(config-if)# ipv4 address 101.0.1.2 255.255.255.0
Router(config-if)# ipv6 address 101:0:1::2/64
Router(config-if)# tunnel mode gre ipv4 [encap | decap]
Router(config-if)# tunnel source 2.2.1.1 
Router(config-if)# tunnel destination 2.2.2.1/32
Router(config-if)# commit
Router(config-if)# exit

To configure ABFv4/v6 over GRE:

router static
  address-family ipv4 unicast
  201.0.1.0/24 tunnel-ip1
  address-family ipv6 unicast
  201:0:1::0/64 tunnel-ip1

ipv4 access-list abf-gre 
  1 permit ipv4 any any nexthop1 ipv4 201.0.1.2
ipv6 access-list abf6-gre 
  1 permit ipv6 any any nexthop1 ipv6 201:0:1::2

interface HundredGigE0/0/0/24 
  ipv4 address 24.0.1.1/24 
  ipv6 address 24:0:1::1/64 
  ipv4 access-group abf-gre ingress 
  ipv6 access-group abf6-gre ingress
!

To configure MPLS PoP label over GRE:

router static
  address-family ipv4 unicast
  201.0.1.0/24 tunnel-ip1
  address-family ipv6 unicast
  201:0:1::0/64 tunnel-ip1

mpls static 
  interface HundredGigE0/0/0/24 
  lsp gre  
    in-label 30501 allocate  
    forward path 1 resolve-nexthop 201.0.1.2 out-label pop  
!

Note

Bi-directional GRE tunnel supports only ERSPAN.

Unidirectional GRE Encapsulation (GREv4)

A tunnel configured using encapsulation mode performs encapsulation of IPv4/IPv6 payload inside the GRE header. The following figure shows GRE encapsulation. Routers in the IP cloud have no knowledge of encapsulated IP source address or destination address.

Configuration

The following example shows how to configure GRE tunnel encapsulation:

interface tunnel-ip1 
  ipv4 address 101.0.1.1/24
  ipv6 address 101:0:1::1/64 
  tunnel mode gre ipv4 encap 
  tunnel source [ loopback1 | <any-ipaddres> | any-interface] 
  tunnel destination [ 20.0.1.1/32 | 20.0.1.0/24 | 20.0.1.0/28]

router static
  address-family ipv4 unicast
  201.0.1.0/24 tunnel-1

router static
  address-family ipv6 unicast
  201:0:1::0/64 tunnel-1

Unidirectional GRE Decapsulation (GREv4)

In unidirectional GRE decapsulation, the outer GRE header is decapsulated and the inner IPv4/IPv6/MPLS payload is forwarded to the next hop router. The following figure shows GRE decapsulation. In the figure, PE1 strips off outer GRE header and inner payload is forwarded as regular IPv4/IPv6/MPLS forwarding.

Configuration

There are two methods to configure GRE tunnel decapsulation:

  1. CLI-based tunnel decapsulation configuration

    interface tunnel-ip1 
  ipv4 address 101.0.1.1/24
  ipv6 address 101:0:1::1/64 
  tunnel mode gre ipv4 decap 
  tunnel source [ loopback1 | <any-ipaddres> | any-interface] 
  tunnel destination [ 20.0.1.1/32 | 20.0.1.0/24 | 20.0.1.0/28]

  2. PBR-based tunnel decapsulation configuration

    class-map type traffic match-all test_gre1 
                 match protocol gre 
                 match destination-address ipv4 10.0.1.2 255.255.255.255 
                 match source-address ipv4 10.10.10.1 255.255.255.255 
                 end-class-map
policy-map type pbr P1-test 
                 class type traffic test_gre1  decapsulate gre 
vrf-policy vrf default address-family ipv4 policy type pbr input P1-test

ECMP and LAG Hashing for NVGRE Flows

Table 3. Feature History Table

Feature Name

Release Information

Feature Description

ECMP and LAG Hashing for NVGRE Flows

Release 25.4.1

Introduced in this release on: Fixed Systems (8010 [ASIC: A100])(select variants only*)

*This feature is supported on:

  • 8011-32Y8L2H2FH

  • 8011-12G12X4Y-A/D

ECMP and LAG Hashing for NVGRE Flows

Release 25.1.1

Introduced in this release on: Fixed Systems (8700 [ASIC: K100], 8010 [ASIC: A100])(select variants only*)

*This feature is supported on:

  • 8712-MOD-M

  • 8011-4G24Y4H-I

ECMP and LAG Hashing for NVGRE Flows

Release 24.4.1

Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100])(select variants only*); Modular Systems (8800 [LC ASIC: P100])(select variants only*)

*This feature is now supported on:

  • 8212-48FH-M

  • 8711-32FH-M

  • 88-LC1-12TH24FH-E

  • 88-LC1-36EH+A8:B12

  • 88-LC1-52Y8H-EM

ECMP and LAG Hashing for NVGRE Flows

 Release 7.5.2

This feature allows transit routers to load balance the GRE traffic, based on GRE payload.

A transit node distributes incoming GRE traffic across ECMP and LAG paths in a GRE tunnel topology. A hashing function uses GRE payload that consists of inner Ethernet frame with destination MAC and source MAC addresses, to derive the traffic entropy.

ECMP and LAG hashing is enabled on Cisco 8000 series routers by default.

Network Virtualization using Generic Routing Encapsulation (NVGRE) endpoints are network devices that act as interfaces between physical and virtual networks. NVGRE endpoint encapsulates Ethernet data frames to and from GRE tunnel. The encapsulated GRE packet is bridged and routed to the destination. On the destination, the NVGRE endpoint decapsulates the GRE packet to recover the original Ethernet frame. NVGRE is described in RFC 7637.

NVGRE uses the following header information for encapsulation:

Header Parameters
Outer Ethernet Header Destination MAC address, Source MAC address
Outer IP Header IPv4 and IPv6 addresses as delivery protocol for GRE
GRE Header GRE protocol type 0x6558 (transparent Ethernet bridging)
GRE Payload Inner Ethernet frame with Destination MAC address and Source MAC address

For load balancing the GRE traffic, the transit router uses GRE payload that consists of inner Ethernet frame with destination MAC and source MAC addresses. The transit router derives the traffic entropy information from the GRE payload.

The hashing function considers the following parameters of GRE packets, along with Router ID, for load balancing the GRE traffic:

Header Parameters
Outer IPv4 Header Source IP address, Destination IP address, IP Protocol (GRE)
Outer IPv6 Header Source IP address, Destination IP address, Flow Label, IP Next Header (GRE)
Inner Header Destination MAC address, Source MAC address, Ether Type

Restrictions for ECMP and LAG Hashing for NVGRE Flows

ECMP and LAG hashing does not support:

  • Outer IPv4 header with Options field.

  • Outer IPv6 header with extension headers.

Network Virtualization using Generic Routing Encapsulation hash field selections

Network Virtualization Generic Routing Encapsulation (NVGRE) hash field selections are load-balancing configuration options that

  • provides the ability to control whether NVGRE inner payload fields are included in the hash calculation, and

  • configures hash field selection to consider only the outer headers, ensuring deterministic load distribution when the NVGRE payload is non-IP.

Benefits of NVGRE hash field selections

These are the benefits of NVGRE hash field selections:

  • Balances NVGRE traffic load across Equal Cost Multipath (ECMP) and Link Aggregation Group (LAG) paths.

  • Reduces traffic congestion and bottlenecks in virtualized network environments.

  • Enhances network efficiency by using inner Ethernet frame information for hashing.

Configuration guidelines for NVGRE hash field selection

These guidelines apply for configuring NVGRE hash field selection:

  • Use the GRE payload fields, including inner Ethernet frame source and destination MAC addresses, for hash computation.

  • Supported only Cisco Silicon One Q100 and Q200 ASIC-based systems.

  • Use the feature to distribute NVGRE traffic across multiple physical paths for better resource utilization.

Restrictions for NVGRE hash field selection

These restrictions apply to NVGRE hash field selection:

  • It does not support outer IPv4 headers that contain options.

  • It does not support outer IPv6 headers with extension headers.

How NVGRE hash field selection works

Summary

NVGRE hash field selection works by allowing configurable hash field selection, ensuring predictable load distribution for NVGRE traffic across network links.

The key components involved in the NVGRE hash field selection process are:

  • ASIC (Q100/Q200): Performs packet inspection and hash calculation as directed by configuration.

  • Network administrator: Chooses the hash field mode to optimize NVGRE deployment outcomes.

  • Forwarding engine: Uses the calculated hash to make load-balancing decisions for NVGRE traffic.

Workflow

These stages describe how a router with a Cisco Silicon One Q100 or Q200 ASIC-based systems process NVGRE traffic and selects header fields for load-balancing hash calculations:

  1. The router receives an incoming packet and determines whether it is an NVGRE-encapsulated packet by checking the protocol value.
    • Packet arrives at the device ingress interface.
    • ASIC inspects the protocol value for 0x6558 (NVGRE).
    This identification is necessary to apply the NVGRE-specific hash field selection logic. Once the NVGRE packet is detected, the device prepares the hash selection procedure as configured for NVGRE traffic.
  2. The ASIC checks the device configuration to determine which headers should be used for hash calculation on NVGRE packets.
    • Device configuration is queried for the presence of cef platform load-balancing nvgre payload exclude.
    Configuration specifies whether only the NVGRE outer header or both outer and inner headers will participate in hashing. This is a static setting, chosen for deployment needs. No hash calculation occurs until the mode is identified.
  3. The ASIC performs the hash calculation according to the selected mode:
    • If nvgre payload exclude is enabled: Only the outer header fields (such as source and destination IP) are included in the hash.
    • If nvgre payload exclude is disabled (default): Both outer and inner header fields (including inner MAC or IP) are included.
    This stage determines load-balancing accuracy, especially when handling non-IP payloads.
  4. The forwarding engine applies the computed hash to select the egress path for the packet.
    • Hash value is used by ECMP or port-channel logic to assign the packet to a specific link.
    The outcome is consistent forwarding of NVGRE flows according to deployment requirements and traffic type. Traffic forwarding completes based on the device's hash selection, ensuring predictable NVGRE load-balancing behavior.

Result

The process enables deterministic, user-directed load-balancing for NVGRE traffic on Cisco Q100 and Q200 ASIC platforms.

Configure NVGRE hash field selection

  • NVGRE hash field selection is relevant primarily to transit devices that do not decapsulate NVGRE traffic.

  • Only applicable to Cisco Silicon One Q100 and Q200 ASIC-based systems.

Before you begin

Follow these steps to configure NVGRE hash field selection and control NVGRE load-balancing behavior.

Procedure

Step 1

Enter global configuration mode.

Example:

Router# configure

Access the global configuration prompt to apply platform-wide settings. Ensure you have the necessary privilege level for configuration changes.

Step 2

Set NVGRE load-balancing to use only the outer header, exclude inner payload fields.

Example:

Router(config)# cef platform load-balancing nvgre payload exclude

This command configures the ASIC to ignore inner payload fields for NVGRE traffic when calculating the load-balancing hash, ensuring predictable balancing especially with non-IP NVGRE payloads.

The router now hashes only outer IP headers for NVGRE traffic when making load-balancing decisions.

Step 3

Save the configuration.

Example:

Router(config)# commit
Router(config)# end