BGP-MPLS IPv6 VPNs: A PE-Based VPN Solution


BGP-MPLS VPNs are specified in the Internet Draft draft-ietf-l3vpn-rfc2547bis, by E. Rosen and Y. Rekhter. This solution represents an implementation of the PE-based VPN model. Because this type of VPN technology has become by far the most popular technology for deploying VPN in a peer-to-peer model, the remainder of the chapter focuses on its application to IPv6.

The following terminology is used for the remainder of this chapter:

  • 6VPE router PE router providing BGP-MPLS IPv6 VPN service over an IPv4-based MPLS core. It is basically a VPNv6 PE, dual stack (IPv4+IPv6) that implements 6PE concepts on the core-facing interfaces.

  • VPNv6 addresses A VPNv6 address is a 24-byte identifier, beginning with an 8-byte route distinguisher (RD) and ending with a 16-byte IPv6 address. Sometimes it is called an VPN IPv6 address.

  • VPNv6 address family The Address Family Identifier (AFI) identifies a particular network layer protocol and the Subsequent AFI (SAFI) provides additional information. The AFI IPv6, SAFI VPN (AFI=2, SAFI=128) is referred to as a VPNv6 address family; similarly, AFI IPv4, SAFI VPN is the VPNv4 address family. Sometimes it is called a VPN IPv6 address family.

  • VRF (virtual routing and forwarding) A VPN routing and forwarding instance in a PE.

  • VRF table A routing and a forwarding table associated to a VRF. This is a customer-specific table, enabling the PE router to maintain independent routing states for each customer.

In principle, no difference exists between IPv4 VPNs, as described in "BGP-MPLS IP VPNs," and IPv6 VPNs, as specified in "BGP-MPLS IP VPN Extension for IPv6 VPN" (Internet Draft, draft-ietf-l3vpn-bgp-ipv6). Similar to IPv4, MP-BGP is the centerpiece of the MPLS VPNv6 architecture. It is used to distribute IPv6 routes over the SP backbone, with the same set of mechanisms to deal with overlapping addresses, redistribution policies, and scalability issues. Even though we do not expect overlapping address space in IPv6, addresses are still prepended with an RD. A new Network Layer Reachability Information (NLRI) 3-tuple format <length, IPv6-prefix, label> is defined to distribute these routes using MP-BGP. The extended community attribute (Route-Target) is used to control redistribution of routing information, by tagging exported routes and filtering imported ones. For scalability, you can use route reflectors to concentrate routing paths, and avoid a full PE mesh. Similar to IPv4, BGP features such as route refresh, automatic route filtering, and outbound route filtering help reduce the number of routes held in each PE.

The Internet Draft "BGP-MPLS IP VPN Extension for IPv6 VPN" focuses solely on the following differences between IPv4 and IPv6:

  • Creation of a new MP-BGP VPNv6 address family, and specification of VPNv6 address format

  • Specification of a new VPN IPv6 NLRI

  • Specification of the BGP next-hop encoding in the case of an IPv4-based MPLS core

A VPNv6 address is a 16-byte IPv6 address, prepended with an 8-byte RD, to form a 24-byte address. As in VPN IPv4, the VPNv6 prefix (network portion of the address) is only meaningful within MP-BGP, and only the IPv6 part of this prefix is kept when redistributed into IPv6 routing protocols.

Example 7-1 shows the VPNv6 prefix 2001:100::/64.

Example 7-1. Showing BGP VPNv6 Address

sa14-72b# show bgp vpnv6 unicast all  2001:100::/64 BGP routing table entry for [100:1]2001:100::/64, version 15 Paths: (1 available, best #1, table red)   Advertised to update-groups:     2001:100::72a (FE80::A8BB:CCFF:FE01:F500) from 2001:100::72a (200.14.14.1)       Origin incomplete, metric 0, localpref 100, valid, external, best       Extended Community: RT:100:1

Note

The notation RD:IPv4-prefix, used for VPNv4 prefixes, cannot be used for VPNv6 prefixes because it conflicts with the IPv6 prefix notation. For instance, 100:1:2001::/64 could be interpreted as an IPv6 prefix or a VPNv6 prefix with an RD of 100:1. For that reason, VPNv6 prefixes use the notation [RD]IPv6-prefix.


In the latter part of "BGP-MPLS IP VPN Extension for IPv6 VPN" (draft-ietf-l3vpn-bgp-ipv6), transitioning and coexistence aspects are covered, with emphasis on the 6PE approach applied to VPNv6. The main aspects of this approach have been discussed at length in Chapter 3 (in the "IPv6 over 6PE" section), and the implications and mechanisms are the same here.

Other aspects of coexistence, in particular 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. This creates a new set of variations in the list of cases listed in "BGP/MPLS IP VPNs" (draft-ietf-l3vpn-rfc2547bis) section 10 (Multi-AS backbone).

The "Topology Examples" section of this chapter provides examples of both interprovider topology and Internet access topology.

Routing Table Segregation

The SP network provides connectivity between "same-customer" sites, while isolating customers from each other. The keystone of the PE-based VPN model is the isolation between routing tables, achieved at two levels:

  • Isolation between customers Customer-specific routing tables (VRF tables) are used on the edge routers. At any particular edge router, one VRF routing table is associated with each site connected to that router, and entries from one VRF table do not leak to another, unless explicitly configured to do so.

  • Isolation between core and edge routing Provider's routes, used by PE routers to reach each other over the provider backbone are kept separated from customer's routes. As a matter of fact, most provider core routers (P-routers) only store these routes and never see customer routes.

To achieve routing segregation, a routing tunnel must be established between PE routers to exchange customer routes. This routing tunnel is transparent to the core routers. This is achieved using MP-BGP between the PE routers. In addition, a forwarding tunnel must be available throughout the provider core network, so that datagrams can be forwarded by P-routers, without requiring the P-routers to keep routing tables for each VPN. In theory, the tunneling mechanism chosen for traffic forwarding could be any of the following kinds: GRE, IPsec, L2TP, MPLS, and so forth. In practice, MPLS has been used for the most part in deployment so far. L2TP has been specified for P-networks that do not use MPLS, and it is deployed in few environments. Figure 7-1 illustrates how routing segregation is achieved.

Figure 7-1. Routing Tables in BGP-MPLS IPv6 VPN Model


In Figure 7-1, the following routing tables are being used at PE1:

  • A set of customer-specific IPv6 routing tables (red and blue) contains customer routes (customer#1 and customer#2, respectively). Each of these routing tables contains routes received from the CE routers as well as routes from remote sites in the same VPN. For example, the content of table red in node PE1 is shown in Example 7-2.

    Example 7-2. IPv6 VRF Table red

    PE1#show ipv6 route vrf red IPv6 Routing Table - red - 10 entries C   2001:100:1:1000::/64      via Serial0/0, directly connected B   2001:100:1:1000::/56      via 200.14.14.1 B   2001:100:1:2000::/56      via 200.10.10.1%Default-IP-Routing-Table, indirectly connected

    Note that these customer-specific tables are also referred to as VRF tables.

  • A default routing table that is exclusively used to reach routers inside the provider network. It is an IPv4 table if the MPLS core is IPv4 based, and IPv6 otherwise. For example, the content of the default table (IPv4) in node PE1 is shown in Example 7-3.

    Example 7-3. IPv4 Default Table

    PE1#show ip route      200.10.10.0/32 is subnetted, 1 subnets i L1    200.10.10.1 [115/30] via 40.1.1.3, Serial1/0      31.0.0.0/24 is subnetted, 1 subnets i L1    31.1.1.0 [115/30] via 40.1.1.3, Serial1/0      200.11.11.0/32 is subnetted, 1 subnets C       200.11.11.1 is directly connected, Loopback0

  • A BGP table, which contains entries from all the customer-specific IPv6 routing tables. An example of the BGP table in node PE1 is shown in Example 7-4.

    Example 7-4. VPNv6 BGP Table

    PE1#show bgp vpnv6 unicast all    Network          Next Hop            Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf red) *  2001:100:1:1000::/562001:100:1:1000::72a0          0 200 ? *>                 ::0          32768 ? *>i2001:100:1:2000::/56::FFFF:200.10.10.1 Route Distinguisher: 200:1 (default for vrf blue) *> 2001:100:2:1000::/56::0         32768 ? *> 2001:100:2:2000::/56::FFFF:200.10.10.10         32768 ?

A BGP session is established between edge routers, and entries from the BGP table are carried over that session. The following steps, illustrated in Figure 7-1, allow route distribution between sites:

1.

The CE router (CE1) announces a customer prefix to the provider router (PE1). Although this entry belongs to the default routing table at the CE, it is installed in a VRF IPv6 table (red) at the PE. The interface on which these entries are received determines into which table they should get installed.

2.

PE1 redistributes this entry into its MP-iBGP table, after prefixing it with the RD referencing the VRF table the entry is coming from (RD 100:1 for entries from table red above).

3.

Once in the BGP table, the entry is announced to the BGP peer at PE2.

4.

Once installed in the PE2 BGP table, the entry is redistributed into one or more VRF tables, after stripping off the RD. Note that the RD is used solely to distinguish entries in BGP, not as a policy mechanism to determine which entry from which VRF table is to be redistributed in which VRF table on the remote PE. Instead, BGP communities (route targets) are used for that purpose.

5.

From the VRF table, the entry is finally redistributed into the customer site (customer#1, site#2).

Routing Protocols for BGP-MPLS IPv6 VPN

For those unfamiliar with MPLS-VPN, a good book to start with is MPLS and VPN Architectures by Ivan Pepelnjak and Jim Guichard. That book provides enough background to appreciate fully the following two sections.

The transition to IPv6 is expected to lead to a long period of coexistence between IPv4 and IPv6. An attractive method for deploying MPLS-VPN IPv6 takes advantage of this coexistence by leveraging an existent MPLS IPv4 core network. This approach, referred to as 6VPE, is similar to the one described in Chapter 3 in the section "IPv6 over 6PE."

Figure 7-2 lists the most important aspects of the 6VPE architecture.

Figure 7-2. Simple 6VPE Architecture


The CE routers are connected to the provider's backbone via PE routers. The PE routers are connected via P-routers. P-routers are unaware of VPN routes, and in the 6VPE case 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. The core routing, which involves PE routers and P-routers is typically performed by an IPv4 IGP such as OSPFv2 or IS-IS. In the simple topology illustrated in Figure 7-2, the IGP distributes only routes internal to the provider's AS. 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. The former is achieved via Multiprotocol Internal Border Gateway Protocol (MP-iBGP) using a specific address family (VPNv6). It distributes routes learned from CEs via the 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. On Cisco routers, at the time of this writing, only static routes, and eBGP, are VRF aware. In the example shown in Figure 7-2, eBGP is used between the CE (CE1) and the PE (PE1). At the same time, the CE runs an IPv6 IGPfor instance, OSPFv3 or IS-IS for IPv6within the VPN site (site1). The CE redistributes IGP routes into MP-eBGP address family IPv6. At the PE, these routes are installed in the VRF red, and forwarded to remote PEs (PE2), according to export policies defined for this VRF.

BGP Next Hop

When announcing a prefix (using the MP_REACH_NLRI attribute), MP-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 (egress PE). For the VPNv6 address family, it has to be a VPNv6 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 just set to zero. 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, masqueraded into an IPv6-mapped address (::FFFF:IPv4-address).

Example 7-5 illustrates the case of a 6VPE next hop.

Example 7-5. VPNv6 Configuration Example Using IPv4 Next Hop

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

By default, the next hop advertised will be the VPNv6 address:

[0:0]::FFFF:200.11.11.1


Note that it is a 192-bit address in the following form:

[RD]::FFFF:IPv4-address.


In this particular case, only 32 bits are significant out of 192 bits sent on the wire.

Example 7-6 shows that BGP configuration can be used when peering takes place over a native IPv6 network.

Example 7-6. VPNv6 Configuration Example Using an IPv6 Next Hop

router bgp 100  neighbor 2001:100:1:1000::72d remote-as 100 !  address-family vpnv6  neighbor 2001:100:1:1000::72d activate  neighbor 2001:100:1:1000::72d send-community extended

By default, the next hop advertised is the VPNv6 address:

[0:0]2001:100:1:1000:0:0:0:72b


Note that it is a 192-bit address in the following form:

[RD]IPv6-address.


Even though current Cisco routers do not provide support for LDPv6, the preceding example can still be deployed, in the interprovider VPN case, when the two providers exchange VPNv6 routes over an IPv6 link using MP-eBGP. See the section "Interprovider VPNs" later in the chapter for details.

When the BGP VPNv6 peers share a common subnet, the MP_REACH_NLRI attribute contains a link-local address next hop, in addition to the global-address next hop. This will typically happen in inter-AS topology, scenario B (see the section "Interprovider VPNs" in the topology examples later in this chapter), when AS boundary routers are facing each other. In that case, the link-local next hop is used locally, and the global next hop is eventually re-advertised by BGP.

Building the Label Stack

Figure 7-3 shows how the label stack is computed by combining information obtained from routing and label distribution protocols.

Figure 7-3. Building the Label Stack for 6VPE


The idea is that ingress PE router (PE2) obtains two separate labels, and combines them into a label stack, which it can impose when forwarding traffic to a given VPN IPv6 destination. Each of these labels is learned via a specific mechanism, and has a specific role in the LSP. The outer label (Lc in Figure 7-3) is used to label switch packets from the ingress PE (PE2) to the egress PE (PE1). This label is obtained through a label distribution protocol, such as Label Distribution Protocol (LDP) or ReSerVation Protocol (RSVP). The inner label (L1 in Figure 7-3) is used to reach the appropriate CE router (CE1) from the egress PE (PE1). MP-iBGP distributes this label.

The BGP "next hop" (described in the previous section) is the keystone for building the label stack, because it is used to tie the inner and the outer label together at the ingress PE. A recursion is performed to combine the two labels: the prefix (net1) is reachable via PE1, using label L1, and PE1 itself is reachable via P2, using label Lc. This recursion takes place as soon as labels are available, and the resulting label stack (Lc+L1) is stored in the Forwarding Information Base (FIB).

In the case of 6VPE (IPv6 MPLS VPN over an IPv4 core), a cross-table resolution (IPv6, then IPv4) is performed to build the label stack, just like for 6PE.

The outer label and inner label are sometimes referred to as "BGP next hop" label and VPN label, respectively.

Note

There is no mechanism to force MP-iBGP to follow the same labeled switching path as IPv6 traffic. In fact, for scalability reasons, the MP-iBGP control traffic is moved away from the Label Switching Path and directed to concentrators such as route reflectors (see the "Scaling IPv6 VPN" section later in the chapter). MP-iBGP control traffic can take advantage of the labeled paths but does not need to. On the other hand, IPv6 traffic between VPN sites requires labeled paths to traverse P-routers (because these are unaware of IPv6 addresses).

This is a fundamental difference from other tunneling techniques, in which the routing updates are sent inside the forwarding tunnel. Should the tunnel break, these updates stop, and edge routers remove corresponding entries from their routing table.

With VPNv6 (and VPNv4), the labeled path may be broken, while the path between PEs is still usable. The MP-iBGP session will keep exchanging IPv6 routes even though packets for corresponding destinations will not be able to traverse the core network. The result is that the traffic is black holed.


Forwarding in BGP-MPLS IPv6 VPN

Upon receiving IPv6 traffic from one customer site, the ingress PE router (PE2) will MPLS tunnel IPv6 VPN packets over the backbone toward the egress PE router (PE1) identified as the BGP next hop. Figure 7-4 shows the forwarding tables (IPv6 and MPLS) built as the result of the label distribution across P- and PE routers.

Figure 7-4. MPLS Forwarding Tables


In Figure 7-4, the network net1 (2001:100:1:1000::/56) is announced by iBGP from PE1 to PE2, with label L1=24. At the same time, LDP is announcing PE1 reachability to PE2 with label Lc=18. The complete label stack (18, 24) for reaching net1 is shown in Example 7-7, via the show ipv6 cef vrf red command. The label forwarding table at routers P2, P1, and PE1 is shown in Example 7-7 via the show mpls forwarding command.

Example 7-7. Showing MPLS Labels Along the LSP

PE2#show ipv6 cef vrf red 2001:100:1:1000::/56   nexthop 31.1.1.1 Ethernet0/0 label 18 24 P2#show mpls forwarding Local  Outgoing  Prefix         Outgoing   Next Hop Label  Label                    interface 18     16        200.11.11.1/3  Et0/0      30.1.1.3 P1#show mpls forwarding Local  Outgoing  Prefix         Outgoing   Next Hop Label  Label                    interface 16     Pop Label 200.11.11.1/32 Et0/0      40.1.1.2 PE1#show mpls forwarding Local  Outgoing   Prefix                    Outgoing   Next Hop Label  Label                                interface 24     No Label   2001:100:1:1000::/56[V]   Et0/0      FE80::A8BB:CCFF:FE01:F500

Figure 7-5 shows the MPLS encapsulation taking place at the ingress PE, and the label swapping occurring at P-routers.

Figure 7-5. MPLS VPNv6 Forwarding Operation


In Figure 7-5, an IPv6 packet for 2001:100:1:1000::1 is being encapsulated at PE2 and sent to PE1, via P2 and P1. MPLS packet traces are enabled (using the debug mpls packet command) at P2, P1, and PE1, and you can see the label stack being received and transmitted at each router.

Under normal operation, a P-router along the forwarding path does not look inside the frame beyond the first label. It either swaps the incoming label with an outgoing one, or removes it (for instance, P1 in Figure 7-5) if the next router is a PE. The latter action is called penultimate hop popping. The remaining label (L1 in the example) has a side function (other than identifying the egress PE interface toward the customer site). It also hides the protocol version (IPv6) from the P-router, which would need to otherwise forward an IPv6 packet. The following output, shown in Example 7-8, via debug mpls packet enabled all along the LSP, illustrates the label swapping happening at each router.

Example 7-8. Tracing MPLS IPv6 Packets Along the LSP

P2#debug mpls packet 00:07:25: MPLS les: Et1/0: rx: Len 122 Stack {18 0 63} {24 0 63} - ipv6 data 00:07:25: MPLS les: Et0/0: tx: Len 122 Stack {16 0 62} {24 0 63} - ipv6 data P1#debug mpls packet 00:07:25: MPLS les: Et1/0: rx: Len 122 Stack {16 0 62} {24 0 63} - ipv6 data 00:07:25: MPLS les: Et0/0: tx: Len 118 Stack {24 0 61} - ipv6 data PE1#debug mpls packet 00:07:25: MPLS les: Et1/0: rx: Len 118 Stack {24 0 61} - ipv6 data

Note

You may have noticed that a P-router is ignorant about IPv6 VPN routes. In fact, with 6VPE, it is an IPv6 ignoramus. The IPv6 header remains hidden under one or more MPLS labels. An interesting issue arises when the P-router receives an MPLS-encapsulated IPv6 packet that cannot be delivered. This scenario can occur if the Time To Live (TTL) in the label expires or if the maximum transmission unit (MTU) is exceeded. The P-router then has to expose the IPv6 header, build an ICMPv6 message, and send it to the source of the original packet. At a minimum, this process requires the P-router to be capable of building an ICMPv6 message; otherwise, it would have to drop silently the undeliverable MPLS-encapsulated IPv6 packet. However, two more issues must be solved:

  • The IPv6 source address found in the packet belongs to a VPN unknown to the P-router and cannot be IPv6 routed from there.

  • The P-router must select an IPv6 source address to use in its ICMPv6 message.

RFC 3032 describes in section 2.3.2 ("Tunneling Private Addresses through a Public Backbone") a mechanism applicable to IPv6 similar to IPv4. The original undeliverable packet carried a label stack that can be imposed to the ICMPv6 message, to enable it to reach the egress PE. The egress PE knows how to reach the private IPv6 network so it can route the packet to the destination. Amazingly, in most cases, the ICMPv6 datagram turns back and traverses the MPLS backbone again before reaching its destination.

For selecting an IPv6 source address, source address selection can be used. However, the P-router may not have any IPv6 address, and even when it has one, it does not belong to the private space of the destination of the packet. In that case, it sets the source address to the v4-mapped address built from the v4 address configured on the incoming interface. See an example of such ICMPv6 packet in the section "Hub and Spoke."


VRF Concepts and IPv6 Implementation

VRF concepts are discussed at length in MPLS and VPN Architectures by Ivan Pepelnjak and Jim Guichard. However, with the introduction of IPv6 VPNs, some of these concepts deserve clarification. A VRF is defined as a virtual routing and forwarding entity, which ties up to a private "customer-specific" routing and forwarding table (RIB and FIB, respectively).

One could conclude that, since IPv6 is carrying its own routing and forwarding tables, there should be distinct IPv4 and IPv6 VRFs. However, although IPv4 and IPv6 routing tables are indeed distinct, it is convenient, from a deployment standpoint to share the same VRF between the two protocols for a given customer.

VPNv6 customers are likely to be existing VPNv4 customers, 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 also prevents sharing the same policy. Another more attractive model is to keep one single VRF on the PE-CE interface, and enable it for IPv4, IPv6, or both. It is then possible to define common or separate policies for each IP version. With this model, a VRF is better defined as the set of tables, interfaces, and policies found at the PE, privately used by sites of a particular VPN connected to this PE.

Figure 7-6 shows the latter model, where VRF red is enabled for both IPv4 and IPv6, and is associated with two interfaces (IF1, IF2), two sets of tables (IPv4 Routing and Forwarding tables and IPv6 Routing and Forwarding tables), and a set of common or distinct policies. Such a VRF that is defined for both IPv4 and IPv6 will be referred to as multiprotocol VRF. Examples of such multiprotocol VRFs are provided in the "Dual-Stack VPNs" section.

Figure 7-6. Multiprotocol VRF


Configuring a VRF

Configuring a VRF for IPv6 is no different from configuring a VRF for IPv4. In fact, it could have been exactly the same, if IPv4 and IPv6 VRFs had been kept separate. For the reasons mentioned previously, a VRF is an address-family-independent object that can be enabled and configured for each of the supported address families. Configuring a VRF includes three steps:

1.

Configuring the AF-independent part of the VRF

2.

Enabling and configuring IPv4 for the VRF

3.

Enabling and configuring IPv6 for the VRF

In Step 1, a VRF is first given a name and an RD. This is achieved using the command vrf definition <name>, and then rd <ASN:nn>.

Note

Interestingly, the RD is configured outside the context of the address family. A careful reader might wonder why this is the case, when 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 should not matter. Indeed it does not. And the same or different RDs for two different address families do not make any difference. On Cisco routers, it was decided to keep the RDs the same to simplify configuration and VPN management.


Still, in Step 1 of the configurationthat is, outside any address family contextyou can configure policies in common between IPv4 and IPv6. This is basically shared route targets (import and export). This feature proves especially useful in a migration scenario, where IPv4 policies already are configured, and IPv6 policies should be the same as the IPv4 ones.

In Step 2 and Step 3, you can configure and enable each address family separately. The address family configuration includes the usual import and export policies, maximum number of routes in the VRF, and so on. Note that the policies (route map and route target) entered at this level override global policies specified in the address-family-independent part.

Example 7-9 is a simple example of enabling and configuring each address family separately.

Example 7-9. Multiprotocol VRF Configuration Example

vrf definition site1 rd 1000:1 address-family ipv4  route-target export 100:1  route-target import 100:1 address-family ipv6  route-target export 200:1  route-target import 200:1

Associating a VRF to an Interface

To specify which interface belongs to which VRF, you must use the interface command vrf forwarding <name>. The meaning and effect of this command on an interface is the same as the ip vrf forwarding command used for VPNv4, with the difference that it is multiprotocol. 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. Example 7-10 is an example of the interface configuration.

Example 7-10. Multiprotocol VRF Configuration on the Interface

hostname PE-1 ! vrf definition site1 rd 100:1 route-target export 100:1 address-family ipv4 address-family ipv6 ! interface Serial0/0  vrf forwarding site1   ipv6 address 2001:100:1:1000::72b/64  ip address 200.11.11.1 255.255.255.0

VRF-Aware Router Commands

Many of the commands to display or troubleshoot Cisco routers are VRF aware for IPv6, similar to IPv4. Here are a few key examples:

  • To show the routing table:

    show ipv6 route vrf red

  • To show the forwarding table:

    show ipv6 cef vrf red

A number of applications available at the router (PE) have to be VRF aware to enable the operator to use them within the scope of a particular VRF. Two notations can be used, either vrf <name> or %<name> after the address, referencing VRF tables in the context of an IPv6 address.

Here is the list of such applications:

  • Ping

    ping vrf red 2001:100:1:1000::72e ping 2001:100:1:1000::72e%red

  • Traceroute

    traceroute vrf red 2001:100:1:1000::72e traceroute 2001:100:1:1000::72e%red

  • Telnet

    telnet /vrf red 2001:100:1:1000::72e telnet 2001:100:1:1000::72e%red

Scaling IPv6 VPNs

PE-based VPNs such as BGP-MPLS IPv6 VPNs scale better than CE-based VPNs. A network designer still has to 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, including the size of VRF tables, and the size of BGP tables

  • Number of BGP sessions, growing as the square of the number of PEs

The first issue arises at PEs handling many customer sites. Not only do these PEs have to deal with one routing and one forwarding table per connected customer, but their BGP tables, which sum up all entries from individual VRFs, are growing 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 MP-BGP sessions may rapidly become prohibitive: (N 1) * N/2, where N is the number of PEs.

Identical issues faced by both IPv6 and IPv4 tend to drive similar solutions. The most common ones are the following:

  • Route refresh and automatic route filtering Limit the size of routing tables because only routes imported into a VRF are kept locally. When the import policy changes, a route refresh can be sent to query a retransmission of routing updates.

  • Outbound route filtering (ORF) Allows the ingress PE to advertise filters to the egress PE so that updates are not unnecessarily sent over the network.

  • Route reflectors These are iBGP peers that propagate iBGP routes learned from other iBGP peers. Route reflectors are used to concentrate the iBGP sessions.

The following example illustrates the route refresh received at PE2, in a situation where PE1 exports routes with route target 500:1 and PE2 imports it. The initial BGP table at PE2 is shown in Example 7-11.

Example 7-11. BGP Table Before the Route Refresh

PE2#show bgp vpnv6 unicast all    Network          Next Hop Route Distinguisher: 100:1 (default for vrf red) *>i2001:100:1:1000::/56    ::FFFF:200.11.11.1 *> 2001:100:1:1000::/64    :: Route Distinguisher: 200:1 (default for vrf blue) *>i2001:100:1:2000::/56    ::FFFF:200.11.11.1 *> 2001:100:1:2000::/64    ::

In one VRF, entries with a route target 500:1 are set up for import as shown here:

PE2(config)#vrf definition red PE2(config-vrf)#route-target import 500:1


The following trace (obtained using the debug bgp command) shows the route refresh being sent, and the BGP update being received and installed:

01:09:28: BGP: 200.11.11.1 sending REFRESH_REQ(5) for afi/safi: 2/128 01:09:28: BGP: 200.11.11.1 send message type 5, length (incl. header) 23 01:09:36: BGP IPv6: Updating route (not batched) 2001:100:1:5000::/56 m/d 0/200,   flags 0


Example 7-12 shows the BGP table.

Example 7-12. BGP Table After the Route Refresh

PE2#show bgp vpnv6 unicast all    Network          Next Hop Route Distinguisher: 100:1 (default for vrf red) *>i2001:100:1:1000::/56    ::FFFF:200.11.11.1 *> 2001:100:1:1000::/64    :: *>i2001:100:1:5000::/56    ::FFFF:200.11.11.1 Route Distinguisher: 200:1 (default for vrf blue) *>i2001:100:1:2000::/56    ::FFFF:200.11.11.1 *> 2001:100:1:2000::/64    :: Route Distinguisher: 500:1 *>i2001:100:1:5000::/56    ::FFFF:200.11.11.1

The route-refresh feature is negotiated during the initial BGP peer negotiation. Example 7-13 shows how to display it.

Example 7-13. Route-Refresh Capability Display

PE2#show bgp vpnv6 unicast all neighbors BGP neighbor is 200.11.11.1,  remote AS 100, internal link   BGP version 4, remote router ID 200.11.11.1   BGP state = Established, up for 2d17h   Last read 00:00:55, hold time is 180, keepalive interval is 60 seconds   Neighbor capabilities:     Route refresh: advertised and received(new)     Address family IPv4 Unicast: advertised and received     Address family VPNv6 Unicast: advertised and received

Note

Although route reflectors solve the problem of the explosion of BGP sessions, they tend to make the issue of BGP table size worse. Because the route reflectors do not have any VRFs themselves, they cannot filter routes based on import policies. Because they can store BGP routes for many clients PEs, they tend to accumulate routes from many sites. Finally, they can easily become a single point of failure for the sessions that they reflect. To alleviate these issues, the design of the network using route reflectors must be carefully studied. Several route reflectors are generally used in parallel, sometimes in a hierarchy. And of course, the provider backbone topology may be partitioned in such a way that a given route reflector serves only a limited numbers of PEs.


MP-BGP for VPNv6 at a Glance

As mentioned earlier in the chapter, MP-BGP is a centerpiece of the MPLS-VPNv6 architecture. Table 7-3 summarizes the list of BGP features applicable to VPNv6 in various deployment scenarios.

Table 7-3. BGP VPNv6 Features

MP-BGP Feature

Description

Base IPv6 MPLS VPN functionality

Support of VRF for IPv6.

Handling of labeled IPv6 VPN address family in MP-BGP.

Appropriate route handling (import/export) taking into account RT.

Automatic inbound route filtering.

EBGP as PE-CE routing protocol

eBGP can run on a VRF basis.

Source of origin (SOO)

SOO is used to prevent routing loops in case of dual-homed CE.

ASN override

If a global ASN is specified, BGP automatically replaces the ASN with a unique number to ensure the site is uniquely identified.

Allow-AS-in

The hub-and-spoke topology widely deployed with VPNv4 is equally useful with VPNv6. This feature enables BGP speakers to accept updates that contain their own ASN in the AS_PATH attribute.

BGP prefix list filtering

Filter MP-BGP IPv6 advertisement based on configured IPv6 prefix.

BGP AS path filtering

Filter MP-BGP IPv6 advertisement based on configured AS path.

BGP max prefix

Upper limit on the number of BGP routes learned from a given CE.

BGP route refresh

Using this technique, a MP-BGP speaker (PE/CE) can request another BGP speaker to resend its MP-BGP updates.

Route target rewrite at AS boundary

Allows rewrite of RT values at AS boundary for inter-AS operations.

BGP multipath

Support eBGP multipath, iBGP multipath, eiBGP multipath and DMZ-link-bandwidth-based load balancing.





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