-
Cisco IOS IPv6 Configuration Library
-
Start Here: Cisco IOS Software Release Specifics for IPv6 Features
-
Implementing IPv6 Addressing and Basic Connectivity
-
Implementing ADSL and Deploying Dial Access for IPv6
-
Implementing Multiprotocol BGP for IPv6
-
Implementing DHCP for IPv6
-
Implementing EIGRP for IPv6
-
Configuring First Hop Redundancy Protocols in IPv6
-
Implementing IPSec in IPv6
-
Implementing IS-IS for IPv6
-
Managing Cisco IOS Applications over IPv6
-
Implementing Mobile IPv6
-
Implementing IPv6 over MPLS
-
Implementing IPv6 VPN over MPLS (6VPE)
-
Implementing IPv6 Multicast
-
Implementing NAT-PT for IPv6
-
Implementing NetFlow for IPv6
-
Implementing OSPF for IPv6
-
Implementing Policy-Based Routing for IPv6
-
Implementing QoS for IPv6
-
Implementing RIP for IPv6
-
Implementing Static Routes for IPv6
-
Implementing Traffic Filters and Firewalls for IPv6 Security
-
Implementing Tunneling for IPv6
-
Table Of Contents
Implementing IPv6 VPN over MPLS (6VPE)
Prerequisites for Implementing IPv6 VPN over MPLS
Restrictions for Implementing IPv6 VPN over MPLS
Information About IPv6 VPN over MPLS
Addressing Considerations for IPv6 VPN over MPLS (6VPE)
Basic IPv6 VPN over MPLS Functionality
IPv6 VPN Architecture Overview
Advanced IPv6 MPLS VPN Functionality
Multi-Autonomous-System Backbones
How to Implement IPv6 VPN over MPLS (6VPE)
Configuring a Virtual Routing and Forwarding Instance for IPv6
Configuring a Static Route for PE-to CE-Routing
Configuring eBGP PE-to-CE Routing Sessions
Configuring the IPv6 VPN Address Family for iBGP
Configuring Route Reflectors for Improved Scalability
Configuring the Internet Gateway
Configuring a Multi-Autonomous-System Backbone for IPv6 VPN
Configuring the PE VPN for a Multi-Autonomous-System Backbone
Configuring the Route Reflector for a Multi-Autonomous-System Backbone
Verifying and Troubleshooting IPv6 VPN
Verifying and Troubleshooting Routing
Verifying and Troubleshooting Forwarding
Debugging Routing and Forwarding
Configuration Examples for Implementing IPv6 VPN over MPLS
IPv6 VPN Configuration Using IPv4 Next Hop: Example
Feature Information for Implementing IPv6 VPN over MPLS
Implementing IPv6 VPN over MPLS (6VPE)
First Published: February 28, 2007Last Updated: May 31, 2007The Border Gateway Protocol (BGP)-Multiprotocol Label Switching (MPLS) virtual private network (VPN) feature represents an implementation of the provider edge (PE)-based VPN model. This document describes the IPv6 VPN over MPLS (6VPE) feature.
In principle, there is no difference between IPv4 VPNs and IPv6 VPNs. In both IPv4 and IPv6, the multiprotocol BGP is the centerpiece of the MPLS VPN for IPv6 (VPNv6) architecture. It is used to distribute IPv6 routes over the service provider backbone, with the same set of mechanisms to work with overlapping addresses, redistribution policies, and scalability issues.
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for Implementing IPv6 VPN over MPLS" section or the "Start Here: Cisco IOS Software Release Specifics for IPv6 Features" document.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for Implementing IPv6 VPN over MPLS
•
•
•
•
•
Prerequisites for Implementing IPv6 VPN over MPLS
This document assumes that you are familiar with IPv4. Refer to the publications listed in the "Additional References" section for IPv4 configuration and command reference information.
Your network must be running the following Cisco IOS services before you configure IPv6 VPN operation:
•
•
•
•
•
Restrictions for Implementing IPv6 VPN over MPLS
6VPE supports an MPLS IPv4-signaled core. An MPLS IPv6-signaled core is not supported.
Information About IPv6 VPN over MPLS
Multiprotocol BGP is the centerpiece of the MPLS IPv6 VPN architecture in both IPv4 and IPv6. It is used to distribute IPv6 routes over the service provider backbone, with the same set of mechanisms to work with overlapping addresses, redistribution policies, and scalability issues.
Although IPv6 should not have overlapping address space, IPv6 addresses are still prepended with a route distinguisher (RD). A network layer reachability information (NLRI) 3-tuple format (which contains length, IPv6 prefix, and label) is defined to distribute these routes using multiprotocol BGP. The extended community attribute—the route target—is used to control redistribution of routing information by tagging exported routes and filtering imported ones.
For scalability, route reflectors can be used to concentrate routing paths and avoid a full PE mesh. Similar to IPv4, BGP features in IPv6 such as route refresh, automatic route filtering, and outbound route filtering help reduce the number of routes held in each PE.
This document focuses on the following differences between IPv4 and IPv6:
•
•
•
Some IPv6 VPN features, such as interprovider and Carrier Supporting Carrier (CSC) topologies, are specific to BGP-MPLS IPv6 VPN. For instance, the link between Autonomous System Boundary Routers (ASBRs) might support IPv4 only, IPv6 only, or both, independently of the address family being transported.
Before you configure IPv6 VPN over MPLS, you should understand the following concepts:
•
•
•
Addressing Considerations for IPv6 VPN over MPLS (6VPE)
Regardless of the VPN model deployed (such as customer edge [CE]-based, PE-based), an addressing plan must be defined for the VPN that allows hosts to communicate with other sites using one site within one VPN, and with public resources.
VPN IPv4 sites often use private addressing for their addressing plan. These addresses need not be registered, and they are not routable on the public network. Whenever a host within a private site needs to access a public domain, it goes through a device that finds a public address on its behalf. With IPv4, this can be a network address translator or an application proxy.
Given the larger address space available with IPv6, the easiest approach to IPv6 addressing is to use IPv6 global addresses for the private addressing plan. Another approach is to use unique local addresses (ULAs). ULAs are easy to filter at site boundaries based on their scope. ULAs are also Internet service provider (ISP)-independent and can be used for communications inside a site without any permanent or intermittent Internet connectivity.
In 6VPE, ULAs are treated as regular global addresses. The router configuration filters, wherever useful, ULA prefixes to prevent them from being leaked in the public domain. Link-local addresses on the other end will not be announced by BGP (IPv6 or IPv6 VPN) speakers.
A host within a private site needs to access a public domain can do so through an IPv6 application proxy (such as a web proxy for accessing web pages), which accesses the public resource on the host's behalf with a global routable address, or the host can use a public address of its own. In the latter case, if ULAs have been deployed, the IPv6 host is configured with a routable global address as well. A source address selection algorithm is used to select one or the other, based on the destination address.
Basic IPv6 VPN over MPLS Functionality
The transition to IPv6 is expected to lead to a long period of coexistence between IPv4 and IPv6. A method for deploying IPv6 VPN takes advantage of this coexistence by leveraging an existent MPLS IPv4 core network. This approach is called 6VPE.
The following sections describe concepts for basic IPv6 MPLS VPN functionality:
•
IPv6 VPN Architecture Overview
Figure 1 illustrates the important aspects of the IPv6 VPN architecture.
Figure 1 Simple IPv6 VPN Architecture
The CE routers are connected to the provider's backbone using PE routers. The PE routers are connected using provider (P1 and P2 in Figure 1) routers. The provider (P) routers are unaware of VPN routes, and, in the case of 6VPE, may support only IPv4. Only PE routers perform VPN-specific tasks. For 6VPE, the PE routers are dual-stack (IPv4 and IPv6) routers.
The routing component of the VPN operation is divided into core routing and edge routing. Core routing, which involves PE routers and P routers, typically is performed by an IPv4 Interior Gateway Protocol (IGP) such as Open Shortest Path First (OSPF) or Intermediate System-to-Intermediate System (IS-IS). In Figure 1, the IGP distributes only routes internal to the provider's autonomous system. The core routing enables connectivity among P and PE routers.
Edge routing takes place in two directions: routing between PE pairs and routing between a PE and a CE. Routing between PE pairs is achieved using multiprotocol internal BGP (iBGP) using the IPv6 VPN address family. This method distributes routes learned from CEs through PE-CE routing, using appropriate route export policies at the ingress PE router and appropriate route import policies at the egress PE router.
Routing between the CE and its PE is achieved using a routing protocol that is VRF aware. Only static routes and external BGP (eBGP) are VPN routing and forwarding instance (VRF) aware. In Figure 1, eBGP is used between the CE (CE1) and the PE (PE1). At the same time, the CE runs an IPv6 IGP (such as OSPFv3 or IS-IS for IPv6) within the VPN site (site1 in Figure 1). The CE redistributes IGP routes into MP-eBGP address family IPv6. At the PE, these routes are installed in the VRF named red, and forwarded to the remote PEs (PE2 in Figure 1), according to export policies defined for this VRF.
IPv6 VPN Next Hop
When announcing a prefix using the MP_REACH_NLRI attribute, multiprotocol BGP running on one PE inserts a BGP next hop in the update message sent to a remote PE. This next hop is either propagated from the received update (for instance, if the PE is a route reflector), or it is the address of the PE sending the update message (the egress PE).
For the IPv6 VPN address family, the next hop has to be a IPv6 VPN address, regardless of the nature of the network between the PE speakers. Because the RD has no significance (the address is not part of any VPN), it is set to 0. If the provider network is a native IPv6 network, the remaining part of the next hop is the IPv6 address of the egress PE. Otherwise, it is an IPv4 address used as an IPv6-mapped address (for example, ::FFFF:IPv4-address).
See the "IPv6 VPN Configuration Using IPv4 Next Hop: Example" section for an example of IPv6 VPN next-hop configuration.
MPLS Forwarding
Upon receiving IPv6 traffic from one customer site, the ingress PE router uses MPLS to tunnel IPv6 VPN packets over the backbone toward the egress PE router identified as the BGP next hop. The ingress PE router typically prepends the IPv6 packets with the outer and inner labels before putting the packet on the egress interface.
Under normal operation, a P router along the forwarding path does not look inside the frame beyond the first label. The P router either swaps the incoming label with an outgoing one, or removes the incoming label if the next router is a PE router. 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. It also hides the protocol version (IPv6) from the last P router, which would otherwise need to forward an IPv6 packet.
A P router is ignorant about IPv6 VPN routes. The IPv6 header remains hidden under one or more MPLS labels. When the P router receives an MPLS-encapsulated IPv6 packet that cannot be delivered, it has two options. If the P router 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 router is not IPv6 aware, it drops the packet.
6VPE Over GRE Tunnels
In the 12.2(33)SRB1 release, the ingress PE router uses IPv4 generic routing encapsulation (GRE) tunnels combined with 6VPE over MPLS to tunnel IPv6 VPN packets over the backbone toward the egress PE router identified as the BGP next hop.
VRF Concepts
A VRF is a virtual routing and forwarding entity, which works with a private customer-specific Routing Information Base (RIB) and Forwarding Information Base (FIB). While IPv4 and IPv6 routing tables are distinct, it is convenient for the two protocols to share the same VRF for a specific customer.
IPv6 VPN customers are likely to be existing VPNv4 customers that are either deploying dual-stack hosts and routers or shadowing some of their IPv4 infrastructure with IPv6 nodes. Several deployment models are possible. Some customers use separate logical interfaces for IPv4 and IPv6 and define separate VRFs on each. Although this approach provides flexibility to configure separate policies for IPv4 and IPv6, it prevents sharing the same policy. Another approach, the multiprotocol VRF, keeps a single VRF on the PE-CE interface, and enables it for IPv4, IPv6, or both. It is then possible to define common or separate policies for each IP version. With this approach, a VRF is better defined as the set of tables, interfaces, and policies found at the PE, used by sites of a particular VPN connected to this PE.
Figure 2 illustrates the multiprotocol VRF, in which the VRF named red is enabled for both IPv4 and IPv6 and is associated with two interfaces (IF1, IF2), two sets of tables (IPv4 RIB and FIB and IPv6 RIB and FIB), and a set of common or distinct policies.
For information on how to configure a VRF in IPv6, see the "Configuring a Virtual Routing and Forwarding Instance for IPv6" section.
Figure 2 Multiprotocol VRF
IPv6 VPN Scalability
PE-based VPNs such as BGP-MPLS IPv6 VPN scale better than CE-based VPNs. A network designer must consider scaling when designing the network. Scaling a BGP-MPLS IPv6 VPN is similar to scaling a BGP-MPLS IPv4 VPN. The following points need to be considered:
•
•
Routing table size concerns occur with PEs that handle many customer sites. Not only do these PEs have one RIB and FIB per connected customer, but the PEs' BGP tables, which total all entries from individual VRFs, grow accordingly. Another scalability issue arises when the number of PEs in the provider network grows beyond a certain level. Assuming that a significant number of sites belonging to the same VPN are spread over many PEs, the number of multiprotocol BGP sessions may rapidly become prohibitive: (N-1) x N/2, where N is the number of PEs.
Identical concerns faced by both IPv6 and IPv4 drive similar solutions. The most common solutions are as follows:
•
•
•
Advanced IPv6 MPLS VPN Functionality
Advanced MPLS features such as accessing the Internet from a VPN for IPv4, multi-AS backbones, and CSCs are generally the same for IPv6 as for IPv4. However, there are differences in addressing and in the way 6VPE operates over an IPv4 backbone.
The following sections describe concepts for advanced IPv6 MPLS VPN functionality:
•
Internet Access
Most VPN sites require access to the Internet. RFC 4364 describes a set of models for enabling VPN access to the Internet. All these models apply to IPv6 VPNs as well. In one approach, one interface is used by the CE to connect to the Internet and a different one to connect to the VRF. Another model is in which all internet routes are redistributed into the VRF. This approach has the disadvantage of requiring the Internet routes to be replicated in each VRF.
In one scenario, a static route is inserted into the VRF table, with a next hop that points to the Internet gateway found in the IPv6 default table. Figure 3 illustrates this scenario, in which Internet access is provided to the customer in the VRF named red.
Figure 3 Internet Access Topology
For a customer site (site1 in Figure 3) to access public resources over the Internet, this site must be known by public prefix. Unlike IPv4, IPv6 does not offer a NAT mechanism that allows translating private addresses into public addresses when leaving the site boundaries. Not only does that imply that hosts within the site speak with public addresses, but these addresses (or at least the prefix they belong to) must leak to the public domain.
For outbound traffic, the default route configured in the VRF table at ingress PE (PE1) directs traffic for destinations outside the VPN to the Internet gateway.
For inbound traffic, a route must exist at the Internet gateway to direct the traffic for customer site via its PE of attachment (PE1 above). This route can be distributed by the ingress PE (PE1) using multiprotocol iBGP (with the IPv6 address-family configuration), so no specific configuration needs to be done on a per VPN PE basis at the Internet gateway. Nevertheless, for inbound traffic at PE1, a route must exist in the default table for the customer site global prefix, pointing to the VRF of the site.
Multi-Autonomous-System Backbones
The problem of interprovider VPNs is similar for IPv6 and IPv4, assuming that IPv6 was deployed everywhere IPv4 was deployed. That, however, is not the situation today.
In IPv6 deployments that cross autonomous system boundaries, providers may have to obtain a peering model, or work with the peering model put in place for VPNv4.
Figure 4 illustrates interprovider scenarios in IPv6 VPN.
Figure 4 Interprovider Scenarios
Depending on the network protocol used between ASBRs, the three scenarios shown in Figure 4 can have several implementation options. For instance, scenario B, which suggests an multiprotocol eBGP IPv6 VPN peering between ASBRs, could use either an IPv6 or an IPv4 link.
In scenario C, multihop multiprotocol eBGP redistributes IPv6 VPN routes across route reflectors in different autonomous systems. Labeled IPv4 routes to the PEs (in the 6VPE case) need to be advertised across ASBRs so that a complete labeled switch path is set up end to end.
Carrier Supporting Carriers
The CSC feature provides VPN access to a customer service provider, so this service needs to exchange routes and send traffic over the ISP MPLS backbone. The only difference from a regular PE is that it provides MPLS-to-MPLS forwarding on the CSC-CE to CSC-PE interface, rather than IP-to-MPLS forwarding.
Figure 5 highlights the two ISPs' interface:
Figure 5 CSC 6VPE Configuration Example
For information on configuring CSC for BGP-MPLS VPN for IPv6, see Configuring CSC for IPv6 VPN.
How to Implement IPv6 VPN over MPLS (6VPE)
•
•
•
•
•
•
•
•
Configuring a Virtual Routing and Forwarding Instance for IPv6
Configuring a virtual routing and forwarding instance (VRF) for IPv6 is no different from configuring a VRF for IPv4. A VRF is an address family-independent object that can be enabled and configured for each of the supported address families. Configuring a VRF consists of three steps:
1.
2.
3.
First, a VRF is given a name and a route distinguisher (RD). The RD is configured outside the context of the address family, although the RD is used to distinguish overlapping addresses within the context of a particular BGP address family. Having separate RDs for IPv4 VPN addresses and IPv6 VPN addresses does not matter. On Cisco routers, the RDs are the same in order to simplify configuration and VPN management.
Users can configure policies in common between IPv4 and IPv6 when outside any address-family context. This feature is shared route targets (import and export), and it is useful in a migration scenario, where IPv4 policies already are configured and IPv6 policies should be the same as the IPv4 policies.
The IPv4 and IPv6 address family can each be enabled and configured separately. Note that the route-target policies entered at this level override global policies that may have been specified during address family-independent configuration.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
DETAILED STEPS
Binding a VRF to an Interface
The following task describes how to bind a VRF to an interface. In order to specify which interface belongs to which VRF, use the vrf forwarding command for both IPv4 and IPv6. An interface cannot belong to more than one VRF. When the interface is bound to a VRF, previously configured addresses (IPv4 and IPv6) are removed, and they must be reconfigured.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Configuring a Static Route for PE-to CE-Routing
The following task describes how to configure a static route for PE-to-CE routing.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Configuring eBGP PE-to-CE Routing Sessions
The following task describes how to configure eBGP PE-to-CE routing sessions.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Configuring the IPv6 VPN Address Family for iBGP
The following task describes how to configure the IPv6 VPN address family for iBGP.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
DETAILED STEPS
Configuring Route Reflectors for Improved Scalability
Deploying RRs improves scalability by drastically reducing the number of BGP sessions. One RR usually peers with many iBGP speakers, preventing a full mesh of BGP sessions.
In an MPLS-based core, RRs are not part of the label switch paths and can be located anywhere in the network. For example, in a flat RR design, RRs can be deployed at Level 1 points of presence (POPs) and peer together in a full-mesh topology. In a hierarchical RR design, RRs could be deployed at Level 1 and Level 2 POPs, with Level 1 POPs peering together and with Level 2 RRs.
In a typical case where 6VPE is deployed in a preexisting MPLS network (e.g., providing VPNv4 services), it is likely that some RR design is already in place, and a similar RR infrastructure for IPv6 VPN services can be deployed. Figure 6 illustrates the main peering points between the RR in the ISP POP and the set of its RR clients.
Figure 6 Route Reflector Peering Design
In this task, note that two RRs are being configured for redundancy reasons.
The following list of BGP RR clients must be configured at each IPv6 RR (RR6 and RR6_1 in Figure 6) router, at each POP:
•
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
DETAILED STEPS
