Supporting IPv6 Traffic Transport in MPLS Layer 3 VPNs Using 6VPE






Supporting IPv6 Traffic Transport in MPLS Layer 3 VPNs Using 6VPE

So far in this book, it has been assumed that traffic transiting between customer MPLS Layer 3 VPN sites consists of IPv4 packets. But, what if customers (also) want to send IPv6 traffic between their VPN sites? In this case, an extension to the standard MPLS Layer 3 VPN model (RFC 4364/RFC2547bis) can be used to support customer IPv6 route exchange and traffic transport. This extension to the basic MPLS Layer 3 VPN model is called 6VPE.

Note

6VPE should not be confused with another mechanism called 6PE. 6PE (IPv6 Provider Edge Router) does not support IPv6 route exchange and traffic transport between customer VPN sites. Instead, it offers global reachability between IPv6 domains via an IPv4/MPLS backbone network.

For more information on 6PE, refer to the following URL:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_data_sheet09186a008052edd3.html


Figure illustrates 6VPE. In this figure, there are two IPv6-enabled VPN sites, mjlnet_VPN sites 1 and 2. PE routers London_PE1 and Brussels_PE1 maintain IPv6 VRFs corresponding to mjlnet_VPN sites 1 and 2.

6VPE


6VPE does not require the deployment of IPv6 in the service provider backbone network. IPv6 routes are exchanged between CE and PE routers and between PE routers (using a new VPN-IPv6 address family with MP-BGP [AFI=2, SAFI=128]). P routers, however, do not need to be IPv6 enabled, and this fact enables service providers to smoothly introduce IPv6 MPLS Layer 3 VPNs without too much disruption.

To understand 6VPE more fully, it is necessary to examine how routes are exchanged and how packets are forwarded. These elements of 6VPE are described in the following two sections.

6VPE Route Exchange

As previously mentioned, 6VPE introduces a new VPN-IPv6 address family that is similar to the VPN-IPv4 address family used with IPv4 MPLS Layer 3 VPNs.

As with IPv4 MPLS Layer 3 VPNs, in IPv6 MPLS Layer 3 VPNs, the PE and CE router exchange IPv6 routes using regular IPv6-capable routing protocols (BGP, OSPFv3, RIPng, IS-IS) or can alternatively use static routes. PE routers redistribute customer IPv6 routes into MP-BGP and advertise these routes via MP-BGP to their peer 6VPE PE routers. Customer routes are stored in the normal way in VRFs on PE routers.

The BGP routing updates used to advertise customer IPv6 routes between PE routers indicate the VPN-IPv6 address family and include and RD, route target(s), a VPN label, and a next hop (per prefix).

The next hop of the customer IPv6 routes as they are advertised between PE routers is this:

::FFFF:<IPv4_address [update_source]>.

Figure depicts route exchange with 6VPE.

Route Exchange with 6VPE


As shown in Figure, London_PE1 and Brussels_PE1 exchange IPv6 routes with the CE routers at mjlnet_VPN site 1 and 2, respectively, using a PE-CE IPv6 routing protocol. Alternatively, IPv6 static routes can be used. London_PE1 and Brussels_PE1 redistribute the IPv6 routes received from their connected CE routers (or IPv6 static routes) into MP-BGP, and then exchange these routes over the MPLS backbone network.

When a PE router receives customer IPv6 routes advertised in MP-BGP by another PE router, it extracts the IPv4 address from the next hop and looks for this address in the global IPv4 routing table. This address is the update source of the PE router that advertised the routes, and after the PE router that received the routes has found the address in the routing table, it attempts to find a corresponding IGP label (and LSP) to this address. If both a route to the IPv4 address/update source (and metric) and an IGP label are found, the customer IPv6 routes are inserted into the customer IPv6 VRF.

6VPE Data Packet Forwarding

When an ingress PE router receives an IPv6 data packet from a CE router, it does a lookup in the IPv6 VRF associated with the PE-CE router interface, and assuming that it finds a valid route, prepends the appropriate VPN label and IGP label onto the IPv6 data packet and forwards it over the MPLS backbone to the egress PE router. The IGP label is, as usual, used to transport the data packet to the egress PE router, and the VPN label is used by the egress PE router to associate the data packet with the appropriate IPv6 VRF. The egress PE router removes the VPN label and forwards the unlabeled IPv6 packet to the connected CE router.

Figure shows IPv6 data packet forwarding with 6VPE.

IPv6 Data Packet Forwarding with 6VPE


The CE router at mjlnet_VPN site 1 forwards an IPv6 packet to London_PE1. London_PE1 then encapsulates this packet using a VPN label and an IGP label and transmits the labeled packet to London_P. London_P, being the penultimate hop, pops the IGP label and forwards the packet to Brussels_PE1 (the VPN label is unchanged). Finally, Brussels_PE1 removes the VPN label and forwards the IPv6 packet to mjlnet_VPN site 2.

Configuring and Verifying 6VPE

If you have a reasonable understanding of the configuration MPLS Layer 3 VPNs for IPv4 (you should by now!), you will find the configuration of 6VPE straightforward.

The configuration steps for 6VPE on PE routers are as follows:

Step 1.
Enable IPv6 routing and IPv6 CEF.

Step 2.
Configure MP-BGP for VPN-IPv6/VPN-IPv4 route exchange with other PE routers or route reflectors.

Step 3.
Configure the customer IPv6 VRFs.

Step 4.
Configure the customer VRF interfaces.

Step 5.
Configure the customer VRF (PE-CE) IPv6 routing protocols or static IPv6 routes.

Step 6.
Redistribute the CE-PE routing protocol or static VRF routes into MP-BGP (and vice-versa, as appropriate).

Note that it is assumed that a loopback interface has already been configured for use as the PE router's BGP router ID/LDP router ID, that LDP is already configured, that MPLS is already enabled on interfaces connected to other PE or P routers, and that the backbone IGP is already configured. More information on these tasks is contained in the section "Configuration of PE Routers" in Chapter 4. It is also assumed that P routers are already configured as described in the section "Configuration of P Routers," also in Chapter 4 (remember that IPv6 does not need to be enabled on P routers).

Before taking a look at a configuration example, it is worth noting that 6VPE can be configured on PE routers that are also configured for IPv4 MPLS Layer 3 VPNs. And, as you will see, it is even possible to configure VRF interfaces to support both IPv4 and IPv6 (VRF interfaces can be IPv4 only, IPv6 only, or IPv4/IPv6).

Figure shows a sample 6VPE configuration for two (peer) PE routers.

Sample 6VPE Configuration for Two (Peer) PE Routers

!
hostname London_PE1 (line 1)
!
ip cef
ipv6 unicast-routing (line 2)
ipv6 cef (line 3)
!
!
vrf definition mjlnet_VPN (line 4)
 rd 64512:100
 route-target export 64512:100
 route-target import 64512:100
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family
!
!
!
mpls ldp router-id Loopback0 force
mpls label protocol ldp
!
!
interface Loopback0
 ip address 10.1.1.1 255.255.255.255
!
!
interface Serial2/0 (line 5)
 description Customer VRF interface
 vrf forwarding mjlnet_VPN
 ip address 172.16.4.1 255.255.255.0
 ipv6 address 2003:410:210:1::/64 eui-64
!
interface Serial2/3
 description backbone interface
 ip address 10.20.10.1 255.255.255.0
 ip router isis
 mpls ip
!
!
! Core IGP configuration (line 6)
!
router isis
 net 49.0001.0000.0000.0001.00
 is-type level-2-only
 metric-style wide
 passive-interface Loopback0
!
!
! PE-CE IPv4 routing protocol configuration (line 7)
!
router rip
 version 2
 !
 address-family ipv4 vrf mjlnet_VPN
 redistribute bgp 64512 metric transparent
 network 172.16.0.0
 no auto-summary
 exit-address-family
!
!
!
router bgp 64512 (line 8)
 no synchronization
 neighbor 10.1.1.4 remote-as 64512
 neighbor 10.1.1.4 update-source Loopback0
 no auto-summary
 !
 address-family vpnv6 (line 9)
 neighbor 10.1.1.4 activate
 neighbor 10.1.1.4 send-community both
 exit-address-family
 !
 address-family vpnv4 (line 10)
 neighbor 10.1.1.4 activate
 neighbor 10.1.1.4 send-community both
 exit-address-family
 !
!
 address-family ipv4 vrf mjlnet_VPN (line 11)
 redistribute connected
 redistribute rip
 no auto-summary
 no synchronization
 exit-address-family
 !
 address-family ipv6 vrf mjlnet_VPN (line 12)
 redistribute connected
 redistribute static
 no synchronization
 exit-address-family
!
!
!
! IPv6 static route for PE-CE reachability
!
ipv6 route vrf mjlnet_VPN 2003:430:210:1::/64 Serial2/0 (line 13)
!

!
hostname Brussels_PE1 (line 14)
!
!
ip cef
ipv6 unicast-routing (line 15)
ipv6 cef (line 16)
!
!
vrf definition mjlnet_VPN (line 17)
 rd 64512:100
 route-target export 64512:100
 route-target import 64512:100
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family
!
!
mpls ldp router-id Loopback0 force
mpls label protocol ldp
!
!
interface Loopback0
 ip address 10.1.1.4 255.255.255.255
!
!
interface Serial3/0
 description backbone interface
 ip address 10.20.30.2 255.255.255.0
 ip router isis
 mpls ip
!
!
!
interface Serial3/3 (line 18)
 description Customer VRF interface
 vrf forwarding mjlnet_VPN
 ip address 172.16.8.1 255.255.255.0
ipv6 address 2003:420:210:1::/64 eui-64
!
!
 ! Core IGP configuration (line 19)
!
router isis
 net 49.0001.0000.0000.0003.00
 is-type level-2-only
 metric-style wide
 passive-interface Loopback0
!
!
! PE-CE IPv4 routing protocol configuration (line 20)
!
router rip
 version 2
 !
 address-family ipv4 vrf mjlnet_VPN
 redistribute bgp 64512 metric transparent
 network 172.16.0.0
 no auto-summary
 exit-address-family
!
!
!
router bgp 64512
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.1 remote-as 64512
 neighbor 10.1.1.1 update-source Loopback0
 no auto-summary
 !
 address-family vpnv6
 neighbor 10.1.1.1 activate
 neighbor 10.1.1.1 send-community both
 exit-address-family
 !
 address-family vpnv4
 neighbor 10.1.1.1 activate
 neighbor 10.1.1.1 send-community both
 exit-address-family
 !
!
 address-family ipv4 vrf mjlnet_VPN
 redistribute connected
 redistribute rip
 no auto-summary
 no synchronization
 exit-address-family
 !
 address-family ipv6 vrf mjlnet_VPN
 redistribute connected
 redistribute static
 no synchronization
 exit-address-family
!
!
! IPv6 static route for PE-CE reachability
!
ipv6 route vrf mjlnet_VPN 2003:440:210:1::/64 Serial3/3 (line 21)
!
!

The configuration of PE router London_PE1 begins in highlighted line 1. The ipv6 unicast-routing and ipv6 cef commands in highlighted lines 2 and 3 are used to enable IP6 routing and enable CEF for IPv6, respectively.

Below highlighted line 4, you can see the configuration of an IPv4/IPv6 VRF. The vrf definition vrf-name command is used to configure a VRF, which in this case is called mjlnet_VPN.

Next, the RD and RTs are defined as usual using the rd and route-target commands.

The address-family [ipv4 | ipv6] command is then used to specify whether this VRF will be an IPv6 or an IPv4/IPv6 VRF. In this example, because the address-family command is used to specify both IPv4 and IPv6, VRF mjlnet_VPN will be an IPv4/IPv6 VRF.

Note that if you want to use different RTs for IPv4 and IPv6, you should specify these within the appropriate address families rather than globally under the VRF definition.

A customer VRF interface is configured starting in highlighted line 5. Notice that both IPv4 and IPv6 addresses are applied to this interface, and that this interface is associated with the VRF created in highlighted line 4 (using the vrf forwarding vrf-name command).

Configuration of BGP begins in highlighted line 8, and below highlighted lines 9 and 10, MP-BGP is configured for VPN-IPv6 (VPNv6) and VPN-IPv4 (VPNv4) route exchange with peer PE router 10.1.1.4 (Brussels_PE1) using the address-family {vpnv6 | vpnv4} and neighbor ip-address activate commands.

Below highlighted lines 11 and 12, IPv4 RIP (the VRF mjlnet_VPN IPv4 PE-CE routing protocol) and IPv6 static routes (used for VRF mjlnet_VPN IPv6 PE-to-customer site reachability) are redistributed into MP-BGP using the redistribute command under the VPN-IPv4 and VPN-IPv6 address families (address-family {ipv4 | ipv6}vrf vrf-name). Notice that in this example, connected (VRF) interface addresses are also redistributed into MP-BGP.

Finally, in highlighted line 13, an IPv6 VRF static route (VRF mjlnet_VPN) is configured for PE router to customer site reachability using the ipv6 route vrf vrf-name customer-site-ipv6-prefix {ipv6-next-hop | output-vrf-interface}.

Note that if you want to use BGP for PE-CE IPv6 reachability, you should configure and activate the CE router as a BGP neighbor under the VPN-IPv6 address family (address-family ipv6 vrf vrf-name, neighbor ce-ipv6-address remote-as as-number, neighbor ce-ipv6-address activate).

The configuration of peer PE router Brussels_PE1 begins in highlighted line 14. Notice that the only real differences are the IP addresses (interfaces, BGP neighbors [10.1.1.1, London_PE1], routes) configured using the various commandslogically, the configuration is identical to that for London_PE1.

So, that's configuration.

You can use a number of commands to verify 6VPE, including show ipv6 route vrf vrf-name, show bgp vpnv6 unicast vrf vrf-name, show bgp vpnv6 unicast vrf vrf-name labels, and show ipv6 cef vrf vrf-name.

Figure shows the output of the show ipv6 route vrf vrf-name command on PE router London_PE1.

Figure. show ipv6 route vrf Command Output on PE Router London_PE1

London_PE1#show ipv6 route vrf mjlnet_VPN
IPv6 Routing Figure mjlnet_VPN - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
       IA - ISIS interarea, IS - ISIS summary
       O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C   2003:410:210:1::/64 [0/0]
     via Serial2/0, directly connected
L   2003:410:210:1:2D0:63FF:FE54:7000/128 [0/0]
     via Serial2/0, receive
B   2003:420:210:1::/64 [200/0] (line 1)
     via 10.1.1.4%Default-IP-Routing-Table, indirectly connected
S   2003:430:210:1::/64 [1/0] (line 2)
     via Serial2/0, directly connected
B   2003:440:210:1::/64 [200/0] (line 3)
     via 10.1.1.4%Default-IP-Routing-Table, indirectly connected
L   FF00::/8 [0/0]
     via Null0, receive
London_PE1#

Highlighted lines 1 and 3 show two routes to IPv6 networks at the mjlnet_VPN Brussels site. Notice that these two routes are BGP routes, and that the next hop of these routes is 10.1.1.4. 10.1.1.4 is the (IPv4) BGP update source on Brussels_PE1.

In highlighted line 2, notice that there is a static route to an IPv6 network at the connected mjlnet_VPN London site.

The show bgp vpnv6 unicast vrf vrf-name command supplies more information about the VPN-IPv6 routes (see Figure).

Figure. show bgp vpnv6 unicast vrf Command Output

London_PE1#show bgp vpnv6 unicast vrf mjlnet_VPN
BGP table version is 9, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 64512:100 (default for vrf mjlnet_VPN)
*> 2003:410:210:1::/64
                    ::                       0         32768 ?
*>i2003:420:210:1::/64
                    ::FFFF:10.1.1.4          0   100       0 ? (line 1)
*> 2003:430:210:1::/64
                    ::                       0         32768 ?
*>i2003:440:210:1::/64
                    ::FFFF:10.1.1.4          0   100       0 ? (line 2)
London_PE1#

Highlighted lines 1 and 2 show the two VPN-IPv4 routes received from Brussels_PE1 for VRF mjlnet_VPN. Notice the format of the next hops of these routes (::FFFF:<IPv4_address [update_source]>).

As shown in Figure, you can see the VPN labels associated with VPN-IPv6 routes using the show bgp vpnv6 unicast vrf vrf-name labels command.

Verifying VPN Labels Associated with VPN-IPv6 Routes

London_PE1#show bgp vpnv6 unicast vrf mjlnet_VPN labels
   Network          Next Hop      In label/Out label
Route Distinguisher: 64512:100 (mjlnet_VPN)
   2003:410:210:1::/64
                    ::              23/nolabel
   2003:420:210:1::/64
                    ::FFFF:10.1.1.4 nolabel/23
   2003:430:210:1::/64
                    ::              24/nolabel
   2003:440:210:1::/64
                    ::FFFF:10.1.1.4 nolabel/24

London_PE1#

The VPN labels associated with VPN-IPv6 routes 2003:420:210::/64 and 2003:440:210:1::/64 (advertised by Brussels_PE1 to London_PE1) are 23 and 24, respectively.

If you want to see the complete label stack that will be imposed on customer IPv6 data packets as they transit the MPLS backbone network between PE routers, you can use the show ipv6 cef vrf vrf-name command (see Figure).

Verifying the Label Stack for 6VPE Data Packets

London_PE1#show ipv6 cef vrf mjlnet_VPN
::/0
  no route
2003:410:210:1::/64
  attached to Serial2/0
2003:410:210:1:2D0:63FF:FE54:7000/128
  attached to Serial2/0, receive
2003:420:210:1::/64
  nexthop 10.20.10.2 Serial2/3 label 18 23 (line 1)
2003:430:210:1::/64
  attached to Serial2/0
2003:440:210:1::/64
  nexthop 10.20.10.2 Serial2/3 label 18 24 (line 2)
FF00::/8
  attached to Null0, receive
London_PE1#

Highlighted line 1 shows that the label stack imposed on customer IPv6 data packets by London_PE1 as they transit the MPLS backbone toward Brussels_PE1 and mjlnet_VPN site 2 network 2003:420:210:1::/64 consists of labels 18 (the IGP label) and 23 (the VPN label). The IGP label (18) corresponds to a route to 10.1.1.4 (Brussels_PE1's BGP update source).

Similarly, in highlighted line 2, you can see that the label stack imposed on customer IPv6 data packets destined for network 2003:440:210:1::/64 consists of labels 18 (the IGP label) and 24 (the VPN label).



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows