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


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


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


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:

1.

By the customer: Migrate site (or part of it) to dual stack, and configure CE-PE interface with IPv6.

2.

By the SP: Migrate PE routers to dual stack, migrate existing IPv4 VRFs to dual-stack VRF (including specific IPv6 VRF policies configuration if any), and configure PE-CE interface with IPv6.

3.

By the SP: Enable MP-BGP VPNv6 address family between PE pairs connecting IPv6-enabled sites.

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

Figure 7-10. Dual-Stack VPN


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


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


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


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


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


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.




Deploying IPv6 Networks
Deploying IPv6 Networks
ISBN: 1587052105
EAN: 2147483647
Year: 2006
Pages: 130

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net