Definitive MPLS Network Designs [Electronic resources] نسخه متنی

IPv6 VPN Service Design

In response to requests from some customers with important VPN sites located in countries with early adoption of IPv6, Globenet introduced an IPv6 VPN service. The most fundamental customer requirement behind the need for an IPv6 VPN service to enable the construction of its IPv6 intranet, as opposed to an IPv6 global reachability service, is the need for the same isolation and security as provided in the IPv4 VPN service. In the future, when access to the IPv6 Internet is also required from these IPv6 intranets, another key benefit of the VPN service will be its ability to route IPv6 Internet traffic independently within each intranet. This is essential, because customers often want to ensure that all the traffic to and from the public IPv6 Internet is forced to transit via one of their own central sites providing IPv6 firewall services.

Globenet offers a very similar VPN service for IPv6 as for IPv4. Its objective is to ultimately offer exactly the same VPN services for IPv4 and IPv6. For example, although Globenet initially offered a more restricted QoS service to the IPv6 traffic, it planned to later extend the full QoS services to IPv6.

A given VPN site may request IPv4-only support, IPv6-only support, or both IPv4 and IPv6 support. Even when both IPv4 and IPv6 support are required, the site needs only a single (physical or logical) access link to the Globenet POP.

Customer requests for IPv6 VPN service have been identified to date in only the Asia Pacific and EMEA regions. Therefore, the IPv6 VPN service is currently offered only within these two regions, as well as across these two regions because a few customers have VPNs with sites spanning both regions. Globenet currently supports 15 IPv6 VPNs, for a total of 500 IPv6 VPN routes.

IPv6 VPN Design Within a Globenet Region

IPv6 VPN Provider Edge" in Chapter 1. This approach involves activating an additional address family (VPN-IPv6) in MP-BGP on the PE routers to advertise the IPv6 routes belonging to the VPNs and then relying on the same mechanisms as used for IPv4 VPNs for route distribution and control such as VRFs, route distinguishers, and route targets. A key characteristic of the 6VPE approach is that it can operate over an IPv4 MPLS backbone that remains entirely IPv6-unaware and, even more generally, completely unaware of the IPv6 VPN service. So Globenet did not need to carry an upgrade or configuration change on its P routers that keep operating as pure IPv4 MPLS P routers.

In line with its shared PE router philosophy (in which all PE routers support all Globenet's services), and because most IPv6 VPN customers also need IPv4 support in the VPN anyway, Globenet supports IPv6 VPNs from the same PE routers as IPv4 VPNs and IPv4 Internet access.

However, because the number of POP locations where there is currently a demand for IPv6 VPN service is quite low, Globenet decided to deploy this service incrementally. This means that the 6VPE functionality is activated only on the subset of PE routers that actually need to support the service today. This saved additional configuration on the many PE routers that do not need to support that service. Also, this considerably reduced the MP-BGP meshing level for the VPN-IPv6 address family so that only two route reflectors (located in two different Type 1 POPs) are used to reflect this address family within a region. Globenet elected to use a dedicated mesh of route reflectors for IPv6 VPN prefixes mainly for the same reason it used a separate route reflection mesh for IPv4 Internet and IPv4 VPN in the first placeisolation across services from a convergence viewpoint. The incremental deployment of the 6VPE functionality on selected PE routers as well as the dedicated set of route reflectors for IPv6 VPN is illustrated in Figure 5-29.

To support IPv6 VPN as per the 6VPE approach, the concept of VRF used for IPv4 VPN was extended in Cisco IOS into the concept of "multiprotocol VRF," which applies to both IPv4 and IPv6. The multiprotocol VRF can now comprise routing and forwarding tables for both IPv4 and IPv6. Also, it lets Globenet naturally define VRF attributes that are independent of the protocol (such as the route distinguisher, which can be used by both the VPN-IPv4 and the VPN-IPv6 address families). Globenet also can define, where applicable, policies that are intended to apply to all protocols (such as RT import/export rules when the same VPN topology is sought for both IPv4 and IPv6 in the considered VPN). At the same time, this concept allows Globenet to define, where needed, policies that are specific to a protocol (for example, when a hub-and-spoke topology is required for both IPv4 and IPv6 in the VPN but where the hubs for IPv4 and IPv6 are located in different VPN sites).

Figure 5-29 shows two multiprotocol VRFs on the PE router PE-Tokyo1. Customer1 VRF attaches a VPN site that runs IPv6 only, and customer2 VRF attaches a VPN site that runs both IPv6 and IPv4.

Example 5-9 shows the corresponding configuration for PE-Tokyo1. For customer1 VRF, which is used only for IPv6 traffic, the RT import and export policy is applied at the level of the multiprotocol VRF. Hence, in case IPv4 support was added later at the customer's request, this policy would also apply to IPv4 (unless a different policy is needed for IPv4, in which case an IPv4-specific policy would be configured under the IPv4 address family). For the customer2 VRF, it is assumed that the customer requires different RT import and export policies for IPv4 and IPv6. Globenet applied those at the level of the address family.

Example 5-9. PE Router Configuration Template for IPv6 VPN Service

hostname PE-Tokyo1
!
vrf definition customer1
rd 32761: customer1-and-PE-Tokyo1-specific-value
route-target import 32761: customer1-specific-value
route-target export 32761: customer1-specific-value
address-family ipv6
!
vrf definition customer2
rd 32761: customer2-and-PE-Tokyo1-specific-value
address-family ipv4
route-target import 32761: customer2-specific-value-for-v4
route-target export 32761: customer2-specific-value-for-v4
address-family ipv6
route-target import 32761: customer2-specific-value-for-v6
route-target export 32761: customer2-specific-value-for-v6
!
router bgp 32761
!
!BGP configuration for exchange of IPv6 VPN address family with Route
!Reflectors (over IPv4)
neighbor IPv4-address-of-v6-VPN-RR1 remote-as 32761
neighbor IPv4-address-of-v6-VPN-RR1 update-source loopback0
neighbor IPv4-address-of-v6-VPN-RR2 remote-as 32761
neighbor IPv4-address-of-v6-VPN-RR2 update-source loopback0
address-family vpnv6
neighbor IPv4-address-of-v6-VPN-RR1 activate
neighbor IPv4-address-of-v6-VPN-RR1 send-community extended
neighbor IPv4-address-of-v6-VPN-RR2 activate
neighbor IPv4-address-of-v6-VPN-RR2 send-community extended
exit-address-family
!
!BGP configuration for exchange of v6 address family with CE1 of
!Customer1 (over IPv6)
address-family ipv6 vrf customer1
neighbor IPv6-address-of-CE1-of-customer1 remote-as CE1-Site-AS
neighbor IPv6-address-of-CE1-of-customer1 update-source loopback0
neighbor IPv4-address-of-CE1-of-customer1 activate
no synchronization
exit-address-family
!
!BGP configuration for exchange of v4 address family with CE2 of
!Customer2 (over IPv4)
address-family ipv4 vrf customer2
neighbor IPv4-address-of-CE2-of-customer2 remote-as CE2-Site-AS
neighbor IPv4-address-of-CE2-of-customer2 update-source loopback0
neighbor IPv4-address-of-CE2-of-customer2 activate
no synchronization
exit-address-family
!
!BGP configuration for exchange of v6 address family with CE2 of
!Customer2 (over IPv4)
address-family ipv6 vrf customer2
neighbor IPv4-address-of-CE2-of-customer2 remote-as CE2-Site-AS
neighbor IPv4-address-of-CE2-of-customer2 update-source loopback0
neighbor IPv4-address-of-CE2-of-customer2 activate
no synchronization
exit-address-family
!
!attachment of customer1 vrf on the PE-CE interface to CE1 of customer1
int serial0/0.1
frame-relay interface-dlci 1001
description "to CE1 of customer1"
vrf forwarding customer1
ipv6 address IPv6-address-of-interface-towards-CE1/length
!
!attachment of customer2 vrf on the PE-CE interface to CE2 of customer2
int serial0/0.2
frame-relay interface-dlci 1002
description "to CE2 of customer2"
vrf forwarding customer2
ip address IPv4-address-of-interface-towards-CE2 mask
ipv6 address IPv6-address-of-interface-towards-CE2/length

[IPv6-DEPLOY].

Globenet currently does not have a specific offer for IPv6 Internet access from IPv6 VPNs because it has not received any customer request for this to date. However, all the same methods currently offered for IPv4 Internet access from IPv4 VPNs (and described previously in the section "Layer 3 MPLS VPN Service Design") could also be offered for IPv6 Internet access from IPv6 VPNs as customer demand materializes for those. Specifically, Internet access via injection of a default route inside the VRF from the CE router of a customer hub site, as well as injection of a default route toward an IPv6 Internet gateway into a customer VRF, would operate in exactly the same way for IPv6 as for IPv4. Internet access via Globenet firewall services would also operate for IPv6 as for IPv4, with the exception that NAT generally is not applicable to IPv6 and that Globenet firewall services would, of course, have to support IPv6. Full Internet access via the PE-CE access link could be supported in the same manner. The full IPv6 Internet routes could be stored in the PE router's global routing table. Also, a separate (physical or logical) connection between PE router and CE router could be used to advertise the IPv6 Internet routes to the CE router from the connection used for the VPN traffic. The same connection would be used for both IPv4 and IPv6 traffic inside the VPN, and the other connection would be used for IPv4 and IPv6 Internet traffic.

One difference between IPv4 and IPv6 operations with respect to Internet routes is that in IPv4, the full Internet routes are stored by all P routers in the core. In IPv6 the P routers would not participate in the MP-BGP exchange of Internet IPv6 routes. Only the PE routers that actually have to offer full IPv6 Internet access would participate in the MP-BGP exchange of those routes. They would do so in accordance with the 6PE approach presented in the "IPv6 Provider Edge" section in Chapter 1. This approach allows the exchange of global IPv6 reachability information among PE routers interconnected by an IPv4-only MPLS core and accordingly forwards IPv6 traffic over this core.

IPv6 VPN Design Across Globenet Regions

Globenet supports IPv6 VPNs that have sites spanning both its EMEA and AsiaPac regions. Just as with IPv4 VPNs, it uses inter-AS option B for IPv6 VPN operations across regions so that the ASBRs of the two regions exchange (labeled) IPv6 VPN reachability information. To support interregion IPv4 VPNs across AsiaPac and EMEA, Globenet uses MP-BGP sessions between the two pairs of ASBRs supporting the direct intercontinental linksnamely, Tokyo/London and Hong Kong/Frankfurt. Globenet uses the same ASBRs for inter-AS operations for IPv6 VPNs.

With inter-AS option B for IPv6 VPNs, to exchange IPv6 VPN reachability, Globenet had a choice between using the peering between the ASBRs over IPv6 or over IPv4. Because Globenet ASBRs were already peering over IPv4 for IPv4 VPN inter-AS support, Globenet elected to also use the same IPv4 peering for the IPv6 VPN inter-AS support. The BGP next-hop attribute is encoded as an IPv4-mapped IPv6 address.

Disabling the ARF feature that you saw earlier for IPv4 VPN inter-AS operation directly applies to IPv6 VPNs. The inter-AS route filtering (based on customer-specific route target values), as Layer 3 MPLS VPN Service Design" section), has also been applied by Globenet to the IPv6 VPN routes.