Implementing IPv6 VPN Provider Edge Transport over MPLS
This module describes how to implement IPv6 VPN Provider Edge Transport over MPLS on Cisco ASR 9000 Series Aggregation Services Routers.
IPv6 VPN Provider Edge (6PE/VPE) uses the existing MPLS IPv4 core infrastructure for IPv6 transport. 6PE/VPE enables IPv6 sites to communicate with each other over an MPLS IPv4 core network using MPLS label switched paths (LSPs).
This feature relies heavily on multiprotocol Border Gateway Protocol (BGP) extensions in the IPv4 network configuration on the provider edge (PE) router to exchange IPv6 reachability information (in addition to an MPLS label) for each IPv6 address prefix. Edge routers are configured as dual-stack, running both IPv4 and IPv6, and use the IPv4 mapped IPv6 address for IPv6 prefix reachability exchange.
For detailed information about the commands used to configure L2TP functionality, see the Cisco ASR 9000 Aggregation Services Router Routing Command Reference .
Feature History for Implementing 6PE on Cisco ASR 9000 Series Routers
This feature was introduced.
Support was added for the 6PE and 6VPE features for IPv6 L3VPN on A9K-SIP-700.
Support was added for the BGP per VRF/CE label allocation for 6PE feature.
Support for the Open Shortest Path First version 3 (OSPFv3) IPv6 VPN Provider Edge (6VPE) feature was added.
Multiple techniques are available to integrate IPv6 services over service provider core backbones:
Dedicated IPv6 network running over various data link layers
Dual-stack IPv4-IPv6 backbone
Existing MPLS backbone leverage
These solutions are deployed on service providers’ backbones when the amount of IPv6 traffic and the revenue generated are in line with the necessary investments and the agreed-upon risks. Conditions are favorable for the introduction of native IPv6 services, from the edge, in a scalable way, without any IPv6 addressing restrictions and without putting a well-controlled IPv4 backbone in jeopardy. Backbone stability is essential for service providers that have recently stabilized their IPv4 infrastructure.
Service providers running an MPLS/IPv4 infrastructure follow similar trends because several integration scenarios that offer IPv6 services on an MPLS network are possible. Cisco Systems has specially developed Cisco 6PE or IPv6 Provider Edge Router over MPLS, to meet all those requirements.
Inter-AS support for 6PE requires support of Border Gateway Protocol (BGP) to enable address families and to allocate and distribute PE and ASBR labels.
Benefits of 6PE/VPE
Service providers who currently deploy MPLS experience these benefits of Cisco 6PE:
Minimal operational cost and risk—No impact on existing IPv4 and MPLS services.
Only provider edge routers upgrade—A 6PE/VPE router can be an existing PE router or a new one dedicated to IPv6 traffic.
No impact on IPv6 customer edge routers—The ISP can connect to any customer CE running Static, IGP or EGP.
Production services ready—An ISP can delegate IPv6 prefixes.
IPv6 introduction into an existing MPLS service—6PE/VPE routers can be added at any time.
Deploying IPv6 over MPLS Backbones
Backbones enabled by 6PE (IPv6 over MPLS) allow IPv6 domains to communicate with each other over an MPLS IPv4 core network. This implementation requires no backbone infrastructure upgrades and no reconfiguration of core routers because forwarding is based on labels instead of the IP header itself. This provides a very cost-effective strategy for IPv6 deployment.
Additionally, the inherent virtual private network (VPN) and traffic engineering (TE) services available within an MPLS environment allow IPv6 networks to be combined into VPNs or extranets over an infrastructure that supports IPv4 VPNs and MPLS-TE.
IPv6 on the Provider Edge and Customer Edge Routers
Service Provider Edge Routers
6PE is particularly applicable to service providers who currently run an MPLS network. One of its advantages is that there is no need to upgrade the hardware, software, or configuration of the core network, and it eliminates the impact on the operations and the revenues generated by existing IPv4 traffic. MPLS is used by many service providers to deliver services to customers. MPLS as a multiservice infrastructure technology is able to provide layer 3 VPN, QoS, traffic engineering, fast re-routing and integration of ATM and IP switching.
Customer Edge Routers
Using tunnels on the CE routers is the simplest way to deploy IPv6 over MPLS networks. It has no impact on the operation or infrastructure of MPLS, and requires no changes to the P routers in the core or to the PE routers. However, tunnel meshing is required as the number of CEs to connect increases, and it becomes difficult to delegate a global IPv6 prefix for an ISP.
Figure 1 illustrates the network architecture using tunnels on the CE routers.
Figure 1 IPv6 Using Tunnels on the CE Routers
IPv6 Provider Edge Multipath
Internal and external BGP multipath for IPv6 allows the IPv6 router to balance load between several paths (for example, the same neighboring autonomous system (AS) or sub-AS, or the same metrics) to reach its destination. The 6PE multipath feature uses multiprotocol internal BGP (MP-IBGP) to distribute IPv6 routes over the MPLS IPv4 core network and to attach an MPLS label to each route.
When MP-IBGP multipath is enabled on the 6PE router, all labeled paths are installed in the forwarding table with available MPLS information (label stack). This functionality enables 6PE to perform load balancing.
The Open Shortest Path First version 3 (OSPFv3) IPv6 VPN Provider Edge (6VPE) feature adds VPN routing and forwarding (VRF) and provider edge-to-customer edge(PE-CE) routing support to Cisco IOS XR OSPFv3 implementation. This feature allows:
Multiple VRF support per OSPFv3 routing process
OSPFV3 PE-CE extensions
Multiple VRF Support
OSPFv3 supports multiple VRFs in a single routing process that allows scaling to tens and hundreds of VRFs without consuming too much route processor (RP) resources.
Multiple OSPFv3 processes can be configured on a single router. In large-scale VRF deployments, this allows partition VRF processing across multiple RPs. It is also used to isolate default routing table or high impact VRFs from the regular VRFs. It is recommended to use a single process for all the VRFs. If needed, a second OSPFv3 process must be configured for IPv6 routing.
NoteThe maximum of four OSPFv3 processes are supported.
OSPFv3 PE-CE Extensions
IPv6 protocol is being vastly deployed in today's customer networks. Service Providers (SPs) need to be able to offer Virtual Private Network (VPN) services to their customers for supporting IPv6 protocol, in addition to the already offered VPN services for IPv4 protocol.
In order to support IPv6, routing protocols require additional extensions for operating in the VPN environment. Extensions to OSPFv3 are required in order for OSPFv3 to operate at the PE-CE links.
VRF lite feature enables VRF deployment without BGP or MPLS based backbone. In VRF lite, the PE routers are directly connected using VRF interfaces. For OSPFv3, the following needs to operate differently in the VRF lite scenario, as opposed to the deployment with BGP or MPLS backbone:
DN bit processing—In VRF lite environment, the DN bit processing is disabled.
ABR status—In VRF context (except default VRF), OSPFv3 router is automatically set as an ABR, regardless to it’s connectivity to area 0. This automatic ABR status setting is disabled in the VRF lite environment.
NoteTo enable VRF Lite, issue thecapabilityvrf-lite command in the OSPFv3 VRF configuration submode.
How to Implement 6PE/VPE
This section includes these implementation procedures:
This task describes how to configure 6PE/VPE on PE routers to transport the IPv6 prefixes across the IPv4 cloud.
Ensure that you configure 6PE/VPE on PE routers participating in both the IPv4 cloud and IPv6 clouds.
NoteFor 6PE, you can use all routing protocols supported on Cisco IOS XR software such as BGP, OSPF, IS-IS, EIGRP, RIP, and Static to learn routes from both clouds. However, for 6VPE, you can use only the BGP, EIGRP and Static routing protocols to learn routes. Also, 6VPE supports OSPFv3 routing protocol between PE and CE routers.
2. router bgp as-number
3. neighbor ip-address
4. address-family ipv6 labeled-unicast
7. address-family ipv6 unicast
8. allocate-label [ all | route-policy policy_name ]
9. end or commit
Command or Action
Enters global configuration mode.
router bgp as-number
RP/0/RSP0/CPU0:router(config)# router bgp 1
Enters the number that identifies the autonomous system (AS) in which the router resides.
Range for 2-byte numbers is 1 to 65535. Range for 4-byte numbers is 1.0 to 65535.65535.
RP/0/RSP0/CPU0:router(config-bgp-af)# allocate-label all
Allocates MPLS labels for specified IPv4 unicast routes.
Note The route-policy keyword provides finer control to filter out certain routes from being advertised to the neighbor.
Saves configuration changes.
When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before exiting(yes/no/cancel)?
– Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
– Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
– Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Configuring PE to PE Core
This task describes how to configure a Provider Edge (PE) to PE Core.
For information on configuring VPN Routing and Forwarding (VRF), refer to the Implementing BGP on Cisco ASR 9000 Series Router module of the Cisco ASR 9000 Series Aggregation Services Router Routing Configuration Guide .
Configures the per-CE label allocation mode to avoid an extra lookup on the PE router and conserve label space (per-prefix is the default label allocation mode). In this mode, the PE router allocates one label for every immediate next-hop (in most cases, this would be a CE router). This label is directly mapped to the next hop, so there is no VRF route lookup performed during data forwarding. However, the number of labels allocated would be one for each CE rather than one for each VRF. Because BGP knows all the next hops, it assigns a label for each next hop (not for each PE-CE interface). When the outgoing interface is a multiaccess interface and the media access control (MAC) address of the neighbor is not known, Address Resolution Protocol (ARP) is triggered during packet forwarding.
The per-vrf keyword configures the same label to be used for all the routes advertised from a unique VRF.
Configures the site-of-origin (SoO) extended community. Routes that are learned from this CE neighbor are tagged with the SoO extended community before being advertised to the rest of the PEs. SoO is frequently used to detect loops when as-override is configured on the PE router. If the prefix is looped back to the same site, the PE detects this and does not send the update to the CE.
Allows an AS path with the PE autonomous system number (ASN) a specified number of times.
Hub and spoke VPN networks need the looping back of routing information to the HUB PE through the HUB CE. When this happens, due to the presence of the PE ASN, the looped-back information is dropped by the HUB PE. To avoid this, use the allowas-in command to allow prefixes even if they have the PEs ASN up to the specified number of times.
The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.