Topology Examples

This section provides VPNv6 topology examples and relevant configurations. The first one is a CE-based VPNv6 example; the remaining examples are PE-based BGP-MPLS IPv6 VPN topologies, starting with a basic topology, then moving forward to more complex cases such as dual-stack VPNs, route reflectors, hub and spoke, Internet access, and inter-AS.

Using IPsec to Secure IPv6 over an IPv4 Tunnel

In this example, a preexisting IPv4 IPsec tunnel is used to create an IPv6 VPN. The tunnel type used is an IPv6 manually configured. Figure 7-7 illustrates the relevant topology.

Figure 7-7. Multiprotocol VRF

[View full size image]

Example 7-14 shows CE1's (Figure 7-7) configuration. The key elements of the configuration are preceded by highlighted comments.

Example 7-14. IPv6 over IPv4 IPsec Tunnel Configuration

hostname CE1 ipv6 unicast-routing ipv6 cef !IPsec configuration for the IPv4 tunnel crypto isakmp policy 1 authentication pre-share group 2 crypto isakmp key SECRET address 10.1.1.2 crypto ipsec transform-set IPSEC ah-sha-hmac esp-des ! crypto map IPV6TUNNEL 10 ipsec-isakmp set peer 9.100.17.1 set transform-set IPSEC match address 100 ! !Configuration of the IPv6 over ipv4 manual tunnel interface Tunnel0 no ip address ipv6 address 2001:100:2:1000::72a tunnel source Serial0/0 tunnel destination 9.200.17.1 tunnel mode ipv6ip crypto map IPV6TUNNEL ! interface Loopback0 ip address 200.14.14.1. 255.255.255.0 ! interface Serial0/0 ip address 9.100.27.1 255.255.255.0 crypto map IPV6TUNNEL ! router bgp 1001 neighbor 2001:100:2:1000::72e remote-as 1001 neighbor 9.100.27.2 remote-as 100 ! ! Configure eBGP-IPv4 to peer with the SP address-family ipv4 neighbor 9.100.27.2 activate ! ! Configure an iBGP-IPv6 routing protocol over the IPsec tunnel address-family ipv6 neighbor 2001:100:2:1000::72e activate network 2001:100:1::1000::/56 ! !Configure an extended IP access_list to allow IPv6 traffic access-list 100 permit 41 host 9.100.27.1 host 9.100.17.1

Basic MPLS VPNv6 Topology

The basic MPLS VPNv6 topology corresponds to an SP connecting two customer sites over its MPLS backbone. Figure 7-8 shows the steps necessary to design and configure the MPLS IPv6 VPN in the provider network.

Figure 7-8. Steps for Configuring the Provider Routers to Enable MPLS VPNv6

[View full size image]

Step 1 focuses on configuring the core MPLS network. This is not needed if the core network already runs MPLS to provide VPNv4 service. For details on how to set up an MPLS network, refer to the book MPLS and VPN Architectures.

Step 2 is driven by the customer needs and requirements. Typically, a new customer triggers the design and configuration of one or more VRFs per PE routers facing customer sites. The VRF configuration is essentially a matter of network design, similar to what is involved in configuring VRFs for VPNv4. VRF design is an important part of a migration scenario for those SPs that want to offer a VPNv6 service to their VPNv4 enterprise customers. Dual-stack VPNs are covered in a subsequent topology example, and the migration scenario is studied in detail in Chapter 13.

Figure 7-9 shows a basic VRF configuration, where each PE (PE1 and PE2) is attached to two sites, and three VPNs are designed (VPN-A, VPN-B and VPN-C).

Figure 7-9. Basic VRF Configuration

[View full size image]

Step 3 involves peering the PEs together. In the simple case, this is accomplished by a direct PE-PE peering. More often, however, this is done via one or more route reflectors. In the following example, the MPLS core network is IPv4 based, and the iBGP peer endpoints are IPv4 loopback (/32) addresses, configured at each PE and distributed by the IGP (OSPF, for instance) inside the provider network. Example 7-15 illustrates the relevant configuration at PE1 (Figure 7-9).

Example 7-15. BGP VPNv6 Peering Configuration

hostname PE1 interface Loopback0 ip address 200.11.11.1 255.255.255.255 ! router bgp 100 neighbor 200.10.10.1 remote-as 100 neighbor 200.10.10.1 update-source Loopback0 ! address-family vpnv6 neighbor 200.10.10.1 activate neighbor 200.10.10.1 send-community extended exit-address-family

Step 4 involves configuring routing between the PE and the CE. The simplest option is to configure static routes on the PE, using the ipv6 route command. With this command, you have the option of specifying the VRF in which it applies, as well as the next hop. You have several options when choosing the next hop:

• A VRF interface:

  ipv6 route vrf site1 2001:100:1:1000::/56 serial 0/0

• A next -hop address in the same VRF as the route being configured:

  ipv6 route vrf site1 2001:100:1:1000::/56 2001:100:1:1000::72a

• A next-hop address in a different VRF:

  ipv6 route vrf site2 2001:100:1:1000::/56 2001:100:2:1000::72a nexthop-
    vrf site3

Static routes are useful in deployments that involve stub sitesthat is, sites with only one access interface to the SP.

After static routes have been configured at the PE, they must be redistributed into MP-BGP, using the redistribute command shown in Example 7-16.

Example 7-16. Redistributing Static Route into BGP VRF

hostname PE1 router bgp 100 address-family ipv6 vrf site1 redistribute static

Another option is to use eBGP between the PE and the CE. This option is attractive because all routes learned from the PE are automatically redistributed to remote PEs and then to CEs participating in a given VPN. In the example shown in Figure 7-9, with four sites and three VPNs (VPN-A, VPN-B and VPN-C), you must configure the address family IPv6 for each VRF (site1 and site2 at PE1, site3 and site4 at PE2). Example 7-17 illustrates BGP configuration on PE1.

Example 7-17. Using eBGP on the PE-CE Interface

router bgp 100 address-family ipv6 vrf site1 neighbor 2001:100:1:1000::72a remote-as 65001 ! address-family ipv6 vrf site2 neighbor 2001:1001:2000::72a remote-as 65002

Along with the provider network configuration, the CE routers must be configured. From the CE routers' standpoint, the BGP configuration is a standard eBGP configuration, with no VRF reference.

The CE routers also participate in the site routing, and are therefore configured with an IPv6 IGP or static routes, and route redistribution between this IGP and eBGP.

Example 7-18 illustrates the corresponding eBGP configuration on CE1 at site1.

Example 7-18. eBGP Configuration Example at CE

hostname CE1 router bgp 65001 neighbor 2001:100:1:1000::72b remote-as 100 address-family ipv6 neighbor 2001:100:1:1000::72b activate redistribute ospf 1

Dual-Stack VPNs

Dual-stack VPNs are likely to be predominant in many of the MPLS IPv6 VPN deployment scenarios. As defined earlier, a dual-stack VPN connects IPv4-enabled sites together and IPv6-enabled sites together. In a typical deployment scenario, an MPLS SP will have to enable IPv6 on already-deployed IPv4 VPNs because existing customers will have migrated some or all of their sites to dual stack (IPv4 and IPv6). In such a scenario, the following provisioning steps must be taken:

Figure 7-10 shows the topology of a dual-stack VPN.

Figure 7-10. Dual-Stack VPN

[View full size image]

Example 7-19 illustrates the BGP configuration of a dual-stack VPN (IPv6-related configuration highlighted).

Example 7-19. BGP Configuration of Dual-Stack VPN

hostname PE1 router bgp 100 neighbor 200.10.10.1 remote-as 100 neighbor 200.10.10.1 update-source Loopback0 address-family ipv4 vrf site1 neighbor 10.100.1.1 remote-as 100 neighbor 10.100.1.1 activate ! address-family ipv6 vrf site1 neighbor 2001:100:1:1000::72a remote-as 100 neighbor 2001:100:1:1000::72a activate ! address-family vpnv4 neighbor 200.10.10.1 activate neighbor 200.10.10.1 send-community extended ! address-family vpnv6 neighbor 200.10.10.1 activates neighbor 200.10.10.1 send-community extended

And Example 7-20 shows the VRF configuration.

Example 7-20. Configuration Example of Dual-Stack VRF

vrf definition site1 rd 100:1 route-target import 100:1 route-target export 100:1 address-family ipv4 address-family ipv6 ! interface serial0/0 vrf forwarding site1 ip address 10.100.1.2 255.255.0.0 ipv6 address 2001:100:1:1000::72b/64

Route Reflectors

Route reflectors are discussed in the "Scaling IPv6 VPN" section. Figure 7-11 shows a simple topology with route reflectors.

Figure 7-11. Route Reflectors Topology

[View full size image]

Example 7-20 is an example of route reflector configuration.

Example 7-21. Route Reflector Configuration Example

router bgp 101 no bgp default route-target filter neighbor 200.11.11.1 remote-as 101 neighbor 200.10.10.1 remote-as 101 neighbor 200.11.11.1 update-source Loopback0 neighbor 200.10.10.1 update-source Loopback0 address-family vpnv6 neighbor 200.11.11.1 activate neighbor 200.11.11.1 route-reflector-client neighbor 200.11.11.1 send-community extended neighbor 200.10.10.1 activate neighbor 200.10.10.1 route-reflector-client neighbor 200.10.10.1 send-community extended

Note that no bgp default route-target filter command is necessary on the route reflector, because it does not maintain a VRF table (unless it is also a regular PE), and would not keep any entry otherwise, as described in the "Scaling IPv6 VPN" section.

Another remarkable element of the preceding configuration is that neither the IPv6 address nor IPv6 routing protocol need to be configured at the route reflector, if the SP chooses to deploy it in an IPv4-based backbone (6VPE). The only IPv6 configuration is in the VPNv6 address family under the BGP router configuration. It is still required to enable the address family, however, because route reflection is on a per-AFI/SAFI basis.

Hub and Spoke

Hub-and-spoke topology is one of the most widely deployed network topologies with VPNv4, and there is no reason why it should not be the same with VPNv6. Large corporations, with multiple sites distributed across the SP backbone, may want to centralize services such as Internet access, firewalls, server farms, and so on. To achieve this, a hub site is deployed with all the other sites forwarding traffic to it. Figure 7-12 shows this topology.

Figure 7-12. Hub-and-Spoke Topology

[View full size image]

Example 7-22 illustrates the BGP configuration of the Paris PE hub router.

Example 7-22. BGP VPNv6 Hub-and-Spoke Configuration Example

!Peering to each spoke site address-family vpnv6 neighbor 200.11.11.1 activate neighbor 200.11.11.1 send-community extended neighbor 200.17.17.1 activate neighbor 200.17.17.1 send-community extended !Peering to Paris central site CE hub address-family ipv6 vrf red-spoke neighbor 2001:2006::16 remote-as 400 neighbor 2001:2006::16 activate neighbor 2001:2006::16 allowas-in 2 !Peering to Paris central site CE spoke address-family ipv6 vrf red-hub neighbor 2001:2005::15 remote-as 400 neighbor 2001:2005::15 activate neighbor 2001:2005::15 allowas-in 2

As shown in Example 7-23, a traceroute command, initiated at one of the spoke sites (London-CE), shows the path used by traffic between spoke sites (the hops are highlighted).

Example 7-23. Traceroute Output Throughout the Hub-and-Spoke Topology

London-CE#traceroute 2001:201::1 1 London-PE-spoke 2001:100::11 2 P ::FFFF:40.1.1.13 [MPLS: Labels 16/36 Exp 0] 3 Paris-PE-hub 2001:2006::10 [AS 100] [MPLS: Label 36 Exp 0] 4 Paris-CE-hub 2001:2006::16 [AS 100] 5 Paris-CE-spoke 2001:2001::15 [AS 400] 6 Paris-PE-hub 2001:2005::10 [AS 400] 7 P ::FFFF:42.1.1.3 [MPLS: Labels 17/25 Exp 0] 8 Nice-PE-spoke 2001:200::17 [AS 100] [MPLS: Label 25 Exp 0] 9 Nice-CE 2001:200::18 [AS 100]

Note that P-routers have not been configured with an IPv6 address and must use an IPv4-mapped address (::FFFF:42.1.1, in this example) to source their ICMPv6 "time-exceeded" messages.

Internet Access

Most VPN sites require access to the Internet. Internet Draft draft-ietf-l3vpn-rfc2547bis describes in section 11 a set of models for enabling VPN access to the Internet. All these models (1 to 4) apply to IPv6 VPNs, too. Some are straightforward, such as model 1, in which an interface is used by the CE to connect to the Internet and a different one to connect to the VRF. In model 4 of section 11, 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 the case of model 3, 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 7-13 shows a scenario in which Internet access is provided to the customer in VRF red based on model 3.

Figure 7-13. Internet Access Topology

[View full size image]

For outbound traffic, the default route configured in the VRF table (red) at PE1 directs traffic for destinations outside the VPN to the Internet gateway. Example 7-24 shows PE1's relevant configuration in this scenario.

Example 7-24. Internet Access: (PE ) Static Route to Internet Gateway

PE1#show running ipv6 route vrf red ::/0 2001:BEEF:14::1 nexthop-vrf default PE1#show ipv6 route vrf red S ::/0 [1/0] via 2001:BEEF:14::1%default The next hop (2001:BEEF:14::1) is in the default routing table: PE1#show ipv6 route B 2001:BEEF:14::1/128 [200/0] via 200.14.14.1%Default-IP-Routing-Table, indirectly connected

It is expected that this next hop has been advertised by the Internet gateway (for instance, over MP-iBGP), based on the configuration in Example 7-25.

Example 7-25. Internet Access: (Internet Gateway) BGP Configuration

IGW#show running router bgp 100 address-family ipv6 neighbor 200.11.11.1 activate neighbor 200.11.11.1 send-label network 2001:BEEF:14::1/128

For inbound traffic, a route must exist at the Internet gateway to direct the traffic for customer site (site1 in Figure 7-13) via its PE of attachment (PE1 above). Assuming that site1 global prefix is 2001:100:1:1000::/64, the following route in Example 7-26 should be configured on the Internet gateway.

Example 7-26. Internet Access: (Internet Gateway) Route to the PE

IGW#show ipv6 route IPv6 Routing Table - default - 6 entries B 2001:100:1:1000 ::/56 [200/0] via 200.11.11.1%Default-IP-Routing-Table, indirectly connected

This route can be distributed by PE1, via MP-iBGP (IPv6 address family), so no specific configuration needs to be done on per-VPN PE basis at the Internet gateway. Nevertheless, for inbound traffic at PE1, a route must exist in the default table, for site1 global prefix (2001:100:1:1000::/64), pointing to site1 VRF.

Example 7-27. Internet Access: (PE) Route to Customer Site

PE1#show running ipv6 route 2001:100:1:1000::/56 2001:100:1:1000::72a/64 nexthop-vrf red PE1#show ipv6 route IPv6 Routing Table - default - 5 entries S 2001:100:1:1000::/56 [1/0] via 2001:100:1:1000::72a%red

Example 7-28 shows the BGP configuration for PE1.

Example 7-28. Internet Access: (PE) BGP Configuration Example

router bgp 100 ! Peering with remote VPN site address-family vpnv6 neighbor 200.10.10.1 activate neighbor 200.10.10.1 send-community extended ! Peering with internet Gateway address-family ipv6 neighbor 200.14.14.1 activate neighbor 200.14.14.1 send-label network 2001:100:1:1000::/56 ! Peering with local VPN site address-family ipv6 vrf red neighbor 2001:100:1:1000::72a remote-as 200 neighbor 2001:100:1:1000::72a activate

Interprovider VPNs

The challenge with interprovider VPNs is similar for IPv6 and IPv4, assuming IPv6 is deployed everywhere IPv4 is. That, however, is not the situation today.

In IPv6 deployments crossing AS boundaries, providers have to pick up a peering model. Figure 7-14 shows the interprovider scenarios (A, B, and C, specified in draft-ietf-l3vpn-rfc2547bis, section 10) in the VPNv6 case.

Figure 7-14. Interprovider Scenarios

[View full size image]

Depending on the network protocol used between ASBRs, the three scenarios described in draft-ietf-l3vpn-rfc2547bis, section 10, can face several implementation options. For instance, scenario B, which suggests an MP-eBGP-VPNv6 peering between ASBRs, could use an IPv6 link, or an IPv4 link. The following example illustrates these two cases. If the peering between ASBRs is performed over an IPv4 link, the BGP configuration on ASBR1 is as shown in Example 7-29.

Example 7-29. Inter-AS BGP Configuration, Scenario B, ASBRs Peering over IPv4

router bgp 1001 no bgp default ipv4-unicast no bgp default route-target filter neighbor 40.1.1.1 remote-as 1002 neighbor 200.11.11.1 remote-as 1001 neighbor 200.11.11.1 update-source Loopback1 ! address-family vpnv6 !Peering to ASBR2 over an IPv4 link neighbor 40.1.1.1 activate neighbor 40.1.1.1 send-community extended !Peering to PE1 over an IPv4 link neighbor 200.11.11.1 activate neighbor 200.11.11.1 next-hop-self neighbor 200.11.11.1 send-community extended

If the peering between ASBRs is performed over an IPv6 link, the BGP configuration on ASBR1 is as shown in Example 7-30.

Example 7-30. Inter-AS BGP Configuration, Scenario B, ASBRs Peering over IPv6

router bgp 1001 neighbor 2001:101::72d remote-as 1002 ! address-family vpnv6 !Peering to ASBR2 over an IPv6 link neighbor 2001:101::72d activate neighbor 2001:101::72d send-community extended

In inter-AS scenario C, multihop MP-eBGP redistributes VPNv6 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 LSP is set up end to end. Figure 7-15 shows inter-AS scenario C, both routing and forwarding paths.

Figure 7-15. Inter-AS Scenario C

[View full size image]

The label stack computed at ingress PE (PE2) contains the following labels:

• Label (Ld) to reach the first P-router in the same AS, and get to the ASBR (ASBR2)

• Label (L3) to traverse the AS boundary as a labeled packet

• Label (L1) to be switched at egress PE (PE1) to the VRF interface

On PE1, you can display the label stack imposed by the forwarding plane (CEF) to reach a destination (2001::2::1) located in remote VRF blue, as shown in Example 7-31.

Example 7-31. Inter-AS: Example of Three-Label Stack at the PE (Scenario C)

pe1#show ipv6 cef vrf blue 2001:201::/64 nexthop 10.1.1.2 Serial0/0 label 20 19 22

In Example 7-31, the values of labels Ld, L3, L1 are 20, 19, 22.

The commands in the following examples highlight the origin of each label.

• Example 7-32 is used to display to bottom label, L1 (22), used to identify the VRF interface at PE2.

  Example 7-32. Inter-AS: Looking at Bottom (BGP VPNv6) Label

  PE1#show bgp vpnv6 uni all 2001:201::/64 BGP routing table entry for [200:1]2001:201::/64, version 4 Paths: (1 available, best #1, table blue) Not advertised to any peer 200 65502 ::FFFF:7.7.7.7 (metric 20) from 2.2.2.2 (2.2.2.2) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:200:1, mpls labels in/out nolabel/22

• Example 7-33 is used to display the middle label, L3 (19), used to traverse the autonomous system boundary.

  Example 7-33. Inter-AS: Looking at Middle (BGP IPv4) Label

  PE1#show bgp ipv4 unicast 7.7.7.7 BGP routing table entry for 7.7.7.7/32, version 10 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 200 90.1.1.2 (metric 20) from 2.2.2.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 3.3.3.3, Cluster list: 2.2.2.2, mpls labels in/out nolabel/19

• Example 7-34 is used to display to top label, Ld (20), used to traverse the local autonomous system.

  Example 7-34. Inter-AS: Looking at Top (LDP) Label

  PE1#show mpls ldp bindings 90.1.1.2 32 lib entry: 90.1.1.2/32, rev 16 local binding: label: 21 remote binding: lsr: 30.1.1.2:0, label: 20

Finally, it is possible to understand the recursion process by analyzing in detail the way Cisco Express Forwarding (CEF) has built the label stack, as shown in Example 7-35.

Example 7-35. Inter-AS: Label Stack Recursive Resolution

PE1#show ipv6 cef vrf blue internal 2001:2::/64, epoch 0, RIB sources: RIB recursive via 7.7.7.7 label 22 recursive via 90.1.1.2 label 19 nexthop 10.1.1.2 Serial0/0 label 20, adjacency IP adj out of Serial0/0 output chain: label 22 label 19 label 20 TAG adj out of Serial0/0

The topology examples discussed in the last sections show the extent of the similarities between VPNv6 and VPNv4. Almost every topology found in the VPNv4 world has a correspondence in the VPNv6 world. The reverse is also true, except where coexistence leads to a more integrated scenario.

A full-scale IPv6 MPLS deployment is described in Chapter 13. It integrates some of the configuration examples from this chapter into a complete, end-to-end IPv6 deployment case study.