Cisco ASR 9000 Series Aggregation Services Router MPLS Layer 3 VPN Configuration Guide, Release 6.0.x
Bias-Free Language
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.
Feature History
for Configuring Link Bundling on Cisco IOS XR Software
Release
Modification
Release
4.3.0
These
feature were supported on the Cisco ASR 9000 Series Aggregation Services
Routers:
MPLS/L3VPNoGRE on ASR 9000
Enhanced Ethernet Line Card and Cisco ASR 9000 Series SPA Interface
Processor-700
RSVP/TEoGRE on ASR 9000
Enhanced Ethernet Line Card and Cisco ASR 9000 Series SPA Interface
Processor-700
VRF aware GRE on ASR 9000
Enhanced Ethernet Line Card and Cisco ASR 9000 Series SPA Interface
Processor-700
L2VPN (VPWS and VPLS) on GRE
for ASR 9000 Enhanced Ethernet Line Card only
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.
Prerequisites for Configuring Generic Routing Encapsulation
Before configuring Link Bundling, be sure that these tasks and
conditions are met:
You must be in a user group
associated with a task group that includes the proper task IDs. The command
reference guides include the task IDs required for each command.
If you suspect user group assignment is preventing you from using a
command, contact your AAA administrator for assistance.
Information About Generic Routing Encapsulation
To implement the GRE feature, you must understand these concepts:
GRE Overview
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.
GRE Features
The following sections
list the GRE features:
Note
An IPv6 GRE tunnel does not support features that involve transport
of MPLS packets through a GRE tunnel.
MPLS/L3VPN over
GRE
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.
PE-to-PE
Tunneling
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.
Figure 1. PE-to-PE
Tunneling
P-to-PE
Tunneling
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.
Figure 2. P-to-PE
Tunneling
P-to-P
Tunneling
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.
Figure 3. P-to-P
Tunneling
6PE/6VPE
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.
6PE/6VPE over GRE
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.
MPLS Forwarding
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.
6PE/6VPE over GRE
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:
After the LDP and BGP
sessions are established, the PEs exchange IPv6 prefixes that they learn from
the CEs and the corresponding IPv6 labels, just as in the case of IPv4 VPN.
The IPv6 labels occupy
the inner most position in the label stack.
The IPv4 labels
corresponding to the PE IPv4 addresses occupy the outer position in the stack.
When IPv6 traffic needs
to be forwarded from PE1 to PE2, the outer PE2 IPv4 label is used to label
switch the traffic to PE2, and the inner IPv6 label is used to send the packet
out of the interface connected to the CE.
GRE Tunnel
Key
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
GRE tunnel key
feature is supported only on Cisco ASR 9000 Enhanced Ethernet line cards. It is
mandatory to have ingress and egress line cards as Enhanced Ethernet line
cards.
Either the same
key or different keys can be configured under multiple GRE tunnels for a given
router. However, more than one tunnel, having the same tunnel source and
destination but a different tunnel key is not supported because the source and
destination pair for various configured tunnels must be unique irrespective of
the key value. Also, two tunnels with the same tunnel source and destination,
but one tunnel being with key and the other tunnel being without key is not
supported.
Different
traffic streams passing through the same GRE tunnel contains the same GRE key
configured for that tunnel.
Use the
tunnelkey command to configure the key value at both
ends of a GRE tunnel.
The following figure
shows a simple representation of the GRE tunnel key configuration:
Figure 4. GRE Tunnel with
Key
The following figure
shows the complete format of the GRE header with the key field:
Figure 5. GRE
Header
GRE Tunnel
Key-Ignore
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.
GRE tunnel in VRF
domains
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.
Figure 6. GRE tunnel in
a VRF instance
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
vrfvrf-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.
Restrictions on a
GRE tunnel
The following
restrictions are applicable for a GRE tunnel:
MPLS packets
cannot be transported within an IPv6 GRE tunnel. Therefore, the following
features are not supported on an IPv6 GRE tunnel:
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.
GRE
IPv4/IPv6 Transport Over MPLS
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
Limitations
GRE
IPv4/IPv6 transport over MPLS-TE tunnels
is not supported.
Specifies the
IPv4 address and subnet mask for the interface.
ipv4-address specifies the
IP address of the interface.
subnet-mask specifies the
subnet mask of the interface.
Step 5
tunnelmodegre{ ipv4
| ipv6}
Example:
RP/0/RSP0/CPU0:router(config-if)# tunnel mode gre ipv4
Specify
whether the transport network is an IPv4 or IPv6 network. The default GRE
tunnel mode is IPv4.
Note
The tunnel
source and destination addresses should match the tunnel mode. A mismatch in
configuration causes the tunnel to fail without any error message.
It is
recommended that the tunnel source is identified using the interface ID and not
the IP address. Using the interface ID enables the router to mark the tunnel as
down when the interface is down and the routing protocol tries to find and use
an alternate route to the tunnel route.
(Optional) Associates the transport VRF with the tunnel. The
transport VRF contains the interfaces over which the tunnel sends as well as
receives packets (outer IP packet routing).
Note
This step is
not required if the tunnel endpoints belong to the global routing table.
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:
Yes - Saves configuration
changes and exits the configuration session.
No - Exits the
configuration session without committing the configuration changes.
Cancel - Remains in the
configuration mode, without committing the configuration changes.
Configuring the
Tunnel Key
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.
commit -
Saves the configuration changes and remains within the configuration session.
end - Prompts
user to take one of these actions:
Yes - Saves
configuration changes and exits the configuration session.
No - Exits the
configuration session without committing the configuration changes.
Cancel - Remains in the
configuration mode, without committing the configuration changes.
Configuring the
Tunnel Key-Ignore
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.