The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco Systems that encapsulates a wide variety of network layer protocols inside virtual point-to-point links over an Internet Protocol internetwork.
|
Release |
Modification |
|---|---|
|
Release 4.3.0 |
These feature were supported on the Cisco ASR 9000 Series Aggregation Services Routers:
|
|
Release 5.1.1 |
Support for GRE Tunnel Key and Tunnel Key-Ignore was introduced. |
| Release 5.2.2 |
Support for GRE tunnel on an IPv6 transport network. |
|
Release 5.3.2 |
Support for GRE IPv4 Transport Over MPLS was introduced. |
|
Release 6.0.1 |
Support for GRE IPv6 Transport Over MPLS was introduced. |
Before configuring Link Bundling, be sure that these tasks and conditions are met:
If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.
To implement the GRE feature, you must understand these concepts:
Generic Routing Encapsulation (GRE) tunneling protocol 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 needs to be delivered to a destination network inside an outer IP packet. GRE 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 towards the GRE tunnel endpoint. Upon reaching the tunnel endpoint, GRE encapsulation is removed and the payload is forwarded to it’s ultimate destination.
MPLS networks provide VPN functionality by tunneling customer data through public networks using routing labels. Service Providers (SP) provide MPLS L3VPN, 6PE/6VPE and L2VPN services to their customers who have interconnected private networks.
MPLS and L3VPN are supported over regular interfaces on Cisco ASR 9000 Series Aggregation Services Routers through GRE tunnels over an IPv4 transport network. MPLS support is extended over IPv4 GRE tunnels between routers as the provider core may not be fully MPLS aware.
 Note |
An IPv6 GRE tunnel does not support features that involve transport of MPLS packets through a GRE tunnel. |
The MPLS VPN over GRE feature provides a mechanism for tunneling Multiprotocol Label Switching (MPLS) packets over a non-MPLS network. This feature utilizes MPLS over generic routing encapsulation (MPLSoGRE) to encapsulate MPLS packets inside IP tunnels. The encapsulation of MPLS packets inside IP tunnels creates a virtual point-to-point link across non-MPLS networks.
L3VPN over GRE basically means encapsulating L3VPN traffic in GRE header and its outer IPv4 header with tunnel destination and source IP addresses after imposing zero or more MPLS labels, and transporting it across the tunnel over to the remote tunnel end point. The incoming packet can be a pure IPv4 packet or an MPLS packet. If the incoming packet is IPv4, the packet enters the tunnel through a VRF interface, and if the incoming packet is MPLS, then the packet enters through an MPLS interface. In the IPv4 case, before encapsulating in the outer IPv4 and GRE headers, a VPN label corresponding to the VRF prefix and any IGP label corresponding to the IGP prefix of the GRE tunnel destination is imposed on the packet. In the case of MPLS, the top IGP label is swapped with any label corresponding to the GRE tunnel destination address.
The provider-edge-to-provider-edge (PE-to-PE) tunneling configuration provides a scalable way to connect multiple customer networks across a non-MPLS network. With this configuration, traffic that is destined to multiple customer networks is multiplexed through a single GRE tunnel.
Note |
A similar nonscalable alternative is to connect each customer network through separate GRE tunnels (for example, connecting one customer network to each GRE tunnel). |
As shown in the following figure, the PE devices assign VPN routing and forwarding (VRF) numbers to the customer edge (CE) devices on each side of the non-MPLS network.
The PE devices use routing protocols such as Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), or Routing Information Protocol (RIP) to learn about the IP networks behind the CE devices. The routes to the IP networks behind the CE devices are stored in the associated CE device's VRF routing table.
The PE device on one side of the non-MPLS network uses the routing protocols (that operate within the non-MPLS network) to learn about the PE device on the other side of the non-MPLS network. The learned routes that are established between the PE devices are then stored in the main or default routing table.
The opposing PE device uses BGP to learn about the routes that are associated with the customer networks that are behind the PE devices. These learned routes are not known to the non-MPLS network.
The following figure shows BGP defining a static route to the BGP neighbor (the opposing PE device) through the GRE tunnel that spans the non-MPLS network. Because routes that are learned by the BGP neighbor include the GRE tunnel next hop, all customer network traffic is sent using the GRE tunnel.
As shown in the following figure, the provider-to-provider-edge (P-to-PE) tunneling configuration provides a way to connect a PE device (P1) to an MPLS segment (PE-2) across a non-MPLS network. In this configuration, MPLS traffic that is destined to the other side of the non-MPLS network is sent through a single GRE tunnel.
As shown in the following figure, the provider-to-provider (P-to-P) configuration provides a method of connecting two MPLS segments (P1 to P2) across a non-MPLS network. In this configuration, MPLS traffic that is destined to the other side of the non-MPLS network is sent through a single GRE tunnel.
Service Providers (SPs) use a stable and established core with IPv4/MPLS backbone for providing IPv4 VPN services. The 6PE/6VPE feature facilitates SPs to offer IPv6 VPN services over this backbone without an IPv6 core. The provide edge (PE) routers run MP-iBGP (Multi-Protocol iBGP) to advertise v6 reachability and v6 label distribution. For 6PE, the labels are allocated per IPv6 prefix learnt from connected customer edge (CE) routers and for 6VPE, the PE router can be configured to allocate labels on a per-prefix or per-CE/VRF level.
While IPv4/MPLS allows SPs to transport IPv6 traffic across IPv4 core (IPv6 unaware), MPLS over GRE allows MPLS traffic to be tunneled through MPLS unaware networks. These two features together facilitate IPv6 traffic to be transported across IPv6 as well as MPLS unaware core segments. Only the PE routers need to be aware of MPLS and IPv6 (Dual stack).
The 6PE/6VPE over GRE feature allows the use of IPv4 GRE tunnels to provide IPv6 VPN over MPLS functionality to reach the destination v6 prefixes via the BGP next hop through MPLS & IPv6 unaware core.
When IPv6 traffic is received from one customer site, the ingress PE device uses MPLS to tunnel IPv6 VPN packets over the backbone toward the egress PE device identified as the BGP next hop. The ingress PE device prefixes the IPv6 packets with the outer and inner labels before placing the packet on the egress interface.
Under normal operation, a P device along the forwarding path does not lookup the frame beyond the first label. The P device either swaps the incoming label with an outgoing one or removes the incoming label if the next device is a PE device. Removing the incoming label is called penultimate hop popping. The remaining label (BGP label) is used to identify the egress PE interface toward the customer site. The label also hides the protocol version (IPv6) from the last P device, which it would otherwise need to forward an IPv6 packet.
A P device is ignorant of the IPv6 VPN routes. The IPv6 header remains hidden under one or more MPLS labels. When the P device receives an MPLS-encapsulated IPv6 packet that cannot be delivered, it has two options. If the P device is IPv6 aware, it exposes the IPv6 header, builds an Internet Control Message Protocol (ICMP) for IPv6 message, and sends the message, which is MPLS encapsulated, to the source of the original packet. If the P device is not IPv6 aware, it drops the packet.
As discussed earlier, 6PE/6VPE over GRE basically means enabling IPv6/IPv6 VPN over MPLS over GRE.
The ingress PE device uses IPv4 generic routing encapsulation (GRE) tunnels combined with 6PE/6VPE over MPLS to tunnel IPv6 VPN packets over the backbone toward the egress PE device identified as the BGP next hop.
The PE devices establish MP-iBGP sessions and MPLS LDP sessions just as in the case of 6PE/6VPE. The difference here is that these sessions are established over GRE tunnels, which also means that the PEs are just one IGP hop away. The P routers in the tunnel path only need to forward the traffic to the tunnel destination, which is an IPv4 address.
This is how the IPv6 LSP is setup for label switching the IPv6 traffic:
The GRE Tunnel Key feature enables the encapsulation router to add a four-byte key, as part of the GRE header, during encapsulation. In the decapsulation router, the GRE key of an incoming packet should match the key value configured under the GRE tunnel. During decapsulation, if a mismatch between the key value of the incoming GRE packet and the key value configured under the GRE tunnel is identified, the incoming packet is dropped.
Note |
|
The following figure shows a simple representation of the GRE tunnel key configuration:
The following figure shows the complete format of the GRE header with the key field:
If a GRE key is configured on only one endpoint router of a GRE tunnel, the other router that has no GRE key configured discards any incoming tunnel packet that has a GRE key. To enable this router to ignore GRE keys and accept incoming data plane packets on the GRE tunnel, run the tunnel key-ignore command. Control plane packets over a GRE tunnel are accepted only if there is no GRE tunnel key configured on both the tunnel endpoints or both the endpoints are configured with a GRE key and the control plane packet passes the GRE key validation. Hence, in the above scenario, both the routers discard any incoming control plane packets from the GRE tunnel.
Note |
Do not configure a GRE key on the GRE tunnel endpoint router if you have configured the router to ignore GRE keys. Configuring a GRE key overrides the tunnel key-ignore command and thus cancels the skipping of GRE key validation. This results in the router accepting from the incoming tunnel traffic only those packets that have the matching GRE key. |
You can configure an IPv4/IPv6 GRE tunnel between two interfaces that belong to a Virtual Forwarding and Routing (VRF) instance. This contains or limits the tunnel path within this specific VRF instance. For example, packets can be sent internally within a default or non-default VRF instance separated through an intermediate VRF that contains the GRE tunnel.
In the above topology, a GRE tunnel is configured in the core network, which is an IPv4 cloud. For packets entering through Interface1, the provider edge (PE) devices PEi and PEe are the tunnel head and tunnel exit respectively.
The VRF configured on Interface1 is the customer VRF. Packets entering this interface are routed using this customer VRF to the tunnel. The routing by the customer VRF is called inner IP packet routing. You can configure the tunnel to be visible to the customer VRF instance using the vrf vrf-name command. This enables only the configured VRF instance to use the tunnel, that is, forward traffic from PEi into this tunnel and also receive all incoming PEi tunnel packets.
The VRF configured on the tunnel using the tunnel vrf command is the transport VRF. The packet entering the tunnel is encapsulated with the tunnel source and destination addresses. The transport VRF routes this encapsulated payload between the tunnel endpoints. The routing by the transport VRF is the outer IP packet routing. If no transport VRF is configured for the tunnel, the PEi device looks up the tunnel endpoint addresses in the default VRF instance, that is, the global routing table.
GRE over BVI is not supported.
MPLS/L3VPN over GRE
6PE/6VPE
6PE/6VPE over GRE
Multicast packets cannot be transported within an IPv6 GRE tunnel.
Multicast packets cannot be transported within an IPv4 GRE tunnel that is configured in a transport VRF.
Keep-Alive packets are not supported on an IPv6 GRE tunnel. You can use the Bidirectional Forwarding Detection (BFD) protocol to detect link failures in an IPv6 GRE tunnel.
The IPv4 addresses are mandatory for configuring GRE tunnels under the VRF, as this would ensure the traffic flows through the tunnel in an expected manner. Use either an IP unnumbered interface or a loopback interface belonging to that VRF for establishing the GRE tunnels under a VRF. Though the tunnel may come up without the aforementioned configuration, the traffic may not pass over the GRE tunnel, since the IP information on the tunnel interface is not available for forwarding the traffic correctly. Also, for the VRF information to be written in hardware database the IP information is required. Therefore, the IP unnumbered GRE tunnels may not work as expected as they may not forward traffic on the device.
The Generic Routing Encapsulation (GRE) IPv4/IPv6 transport over Multiprotocol Label Switching (MPLS) feature provides a mechanism to configure GRE tunnels, where the tunnel destination IPv4/IPv6 address is reachable through an MPLS label switched path (LSP). With this feature, IPv4, IPv6, routing protocols - OSPF, ISIS, and L2VPN and L3VPN packets are accepted as payload packets for GRE encapsulation . IPv4/IPv6 is supported as the GRE delivery protocol.
This feature overcomes the restriction of not being able to configure the tunnel destination endpoint through an MPLS LSP during tunnel configuration.
The GRE IPv4/IPv6 transport over MPLS feature facilitates creation of GRE tunnels over LSPs, through L3VPN inter-AS (autonomous system) options:
External Border Gateway Protocol (EBGP) redistribution of labeled VPN IPv4/IPv6 routes from an AS to a neighboring AS.
Multi-hop EBGP redistribution of labeled VPN IPv4/IPv6 routes between source and destination ASs, with EBGP redistribution of labeled IPv4/IPv6 routes from an AS to a neighboring AS.
Multipoint GRE IPv4/IPv6 transport over MPLS is also supported.
The GRE IPv4/IPv6 transport over MPLS feature is supported on the following types of Cisco ASR 9000 line cards:
Cisco ASR 9000 Enhanced Ethernet line card
Cisco ASR 9000 High Density 100GE Ethernet line card
GRE IPv4/IPv6 transport over MPLS-TE tunnels is not supported.
GREoMPLS with IP Fast Reroute (IPFRR).
How to Configure Generic Routing Encapsulation
Perform this task to configure a GRE tunnel.
|
Step 1 |
configure Example:Enters the Global Configuration mode. |
||
|
Step 2 |
interface tunnel-ip number Example:Enters tunnel interface configuration mode.
|
||
|
Step 3 |
vrf vrf-name Example:
|
||
|
Step 4 |
ipv4 address ipv4-address mask Example:Specifies the IPv4 address and subnet mask for the interface.
|
||
|
Step 5 |
tunnel mode gre { ipv4 | ipv6} Example:
|
||
|
Step 6 |
tunnel source { ip-address | type path-id } Example:
|
||
|
Step 7 |
tunnel destination ip-address Example:Defines the tunnel destination. |
||
|
Step 8 |
tunnel vrf transport-vrf-name Example:
|
||
|
Step 9 |
Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions:
|
Perform this task to configure the tunnel key for the GRE encapsulated packets. You need to perform same configuration steps on the other endpoint router of the tunnel ensuring that the key value is the same at both the local and remote GRE interfaces.
|
Step 1 |
configure Example:Enters the Global Configuration mode. |
|
Step 2 |
interface tunnel-ip number Example:Enters tunnel interface configuration mode.
|
|
Step 3 |
ipv4 address ipv4-address subnet-mask Example:Specifies the IPv4 address and subnet mask for the interface.
|
|
Step 4 |
tunnel key value Example:Enables tunnel key. |
|
Step 5 |
(Optional) tunnel tos tos-value Example:Specifies the value of the TOS field in the tunnel encapsulating packets. |
|
Step 6 |
tunnel source type path-id Example:Specifies the source of the tunnel interface. |
|
Step 7 |
tunnel destination ip-address Example:Defines the tunnel destination. |
|
Step 8 |
Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions:
|
Perform this task to configure the tunnel key-ignore for the GRE encapsulated packets. You need to perform same configuration steps on the other endpoint router of the tunnel.
|
Step 1 |
configure Example:Enters the Global Configuration mode. |
|
Step 2 |
interface tunnel-ip number Example:Enters tunnel interface configuration mode.
|
|
Step 3 |
ipv4 address ipv4-address subnet-mask Example:Specifies the IPv4 address and subnet mask for the interface.
|
|
Step 4 |
tunnel key-ignore Example:Enables tunnel key-ignore. |
|
Step 5 |
(Optional) tunnel tos tos-value Example:Specifies the value of the TOS field in the tunnel encapsulating packets. |
|
Step 6 |
tunnel source type path-id Example:Specifies the source of the tunnel interface. |
|
Step 7 |
tunnel destination ip-address Example:Defines the tunnel destination. |
|
Step 8 |
Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions:
|
Perform this task to configure a VRF interface.
|
Step 1 |
configure Example:Enters the Global Configuration mode. |
|
Step 2 |
interface type interface-path-id Example:Enters interface configuration mode. |
|
Step 3 |
vrf vrf-name Example:Configures a VRF instance and enters VRF configuration mode. |
|
Step 4 |
ipv4 address ipv4-address mask Example:Configures a primary IPv4 address for the specified interface. |
|
Step 5 |
Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions:
|
Perform this task to configure the VRF routing protocol.
|
Step 1 |
configure Example:Enters the Global Configuration mode. |
|
Step 2 |
router ospf process-name Example:Enters OSPF configuration mode allowing you to configure the OSPF routing process. |
|
Step 3 |
vrf vrf-name Example:Configures a VPN routing and forwarding (VRF) instance and enters VRF configuration mode for OSPF routing. |
|
Step 4 |
router-id {router-id | type interface-path-id} Example:Configures the router ID for the OSPF routing process. |
|
Step 5 |
area area-id Example:Configures the OSPF area as area 0. |
|
Step 6 |
interface type interface-path-id Example:Associates interface GigabitEthernet 0/3/0/0 with area 0. |
|
Step 7 |
Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions:
|
Perform this task to configure IGP for remote PE reachability.
|
Step 1 |
configure Example:Enters the Global Configuration mode. |
||
|
Step 2 |
router ospf process-name Example:Enables OSPF routing for the specified routing process and places the router in router configuration mode. |
||
|
Step 3 |
router-id {router-id} Example:Configures a router ID for the OSPF process.
|
||
|
Step 4 |
area area-id Example:Enters area configuration mode and configures an area for the OSPF process. |
||
|
Step 5 |
interface tunnel-ip number Example:Enters tunnel interface configuration mode.
|
||
|
Step 6 |
Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions:
|
Perform this task to configure LDP on a GRE tunnel.
|
Step 1 |
configure Example:Enters the Global Configuration mode. |
||
|
Step 2 |
mpls ldp Example:Enables MPLS LDP configuration mode. |
||
|
Step 3 |
router-id {router-id} Example:Configures a router ID for the OSPF process.
|
||
|
Step 4 |
interface tunnel-ip number Example:Enters tunnel interface configuration mode.
|
||
|
Step 5 |
Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions:
|
Perform this task to configure MP-iBGP to exchange VPN-IPv4 routes.
|
Step 1 |
configure Example:Enters the Global Configuration mode. |
|
Step 2 |
router bgp as-number Example:Specifies the autonomous system number and enters the BGP configuration mode, allowing you to configure the BGP routing process. |
|
Step 3 |
router-id ip-address Example:Configures the local router with a specified router ID. |
|
Step 4 |
neighbor ip-address Example:Places the router in neighbor configuration mode for BGP routing and configures the neighbor IP address as a BGP peer. |
|
Step 5 |
remote-as as-number Example:Creates a neighbor and assigns a remote autonomous system number to it. |
|
Step 6 |
update-source type interface-path-id Example:Allows sessions to use the primary IP address from a specific interface as the local address when forming a session with a neighbor. |
|
Step 7 |
address-family { vpnv4 | vpnv6 unicast } Example:Enters address family configuration submode for the specified address family. |
|
Step 8 |
Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions:
|
This section provides examples to configure GRE:
This example shows how to configure an IPv4 GRE tunnel:
configure
interface tunnel-ip1
ipv4 address 12.0.0.1 255.255.255.0
tunnel source Loopback0
tunnel destination 200.200.200.1
endinterface tunnel-ip 1
vrf RED
ipv4 address 10.1.1.2/24
ipv6 address 10::2/64
tunnel mode gre ipv6
tunnel source GigabitEthernet 0/0/0/0
tunnel destination 100::1
tunnel vrf BLUE
!
vrf blue
description connected to IXIA in blue VRF
address-family ipv4 unicast
import route-target
100:1
!
export route-target
100:1
!
vrf red
description connected to core interface in red VRF
address-family ipv4 unicast
import route-target
200:1
!
export route-target
200:1
!
interface tunnel-ip1
vrf blue
ipv4 address 10.10.10.1 255.255.255.0
tunnel source Loopback0
keepalive
tunnel vrf red
tunnel destination 12.12.12.12
RP/0/RSP0/CPU0:ios#ping vrf red 12.12.12.12
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.12.12.12, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
RP/0/RSP0/CPU0:ios#ping vrf blue 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/19 ms
This example shows how to configure global VRF:
configure
vrf VRF1
address-family ipv4 unicast
import route-target 120:1
export route-target 120:2
exit
exit
router bgp120
vrf VRF1
rd auto
end This example shows how to configure a VRF interface:
configure
interface tunnel-ip 100
vrf VRF1
ipv4 address 1.1.1.1 255.255.255.0
ipv6 address 100::2/64
endThis example shows how to configure VRF routing protocol:
configure
router ospf109
vrf VRF1
router-id 172.20.10.10
area0
interface GigabitEthernet0/3/0/0
endThis example shows how to configure IGP for remote provider edge (PE) reachability:
configure
router ospf109
router-id 172.20.10.10
area0
interface tunnel-ip1
endThis example shows how to configure LDP on a GRE tunnel:
configure
mpls ldp
router-id 172.20.10.10
interface tunnel-ip1
endThis example shows how to configure MP-iBGP to exchange VPN-IPv4 routes:
configure
router bgp100
router-id 172.20.10.10
neighbor 2.2.2.2 remote-as 100
update-source Loopback0
address-family vpnv4 unicast
end
Feedback