customer sites without any special design or configuration effort.

Easy provisioning of additional VPNs or customer sites because the SP provisions only individual sites, not the links between individual customer sites.

The major drawbacks of peer-to-peer VPNs arise from SP involvement in customer routing, such as the following situations:

The SP becomes responsible for correct customer routing and for fast convergence of the customer network (C-network) following a link failure.
The SP PE routers have to carry all customer routes that were hidden from the SP in the overlay VPN model.
The SP needs detailed IP routing knowledge, which is not readily available in traditional SP teams.

Non-Service Provider-Related Drawbacks of Peer-to-Peer VPNs
In addition to SP-related drawbacks, peer-to-peer VPNs have other common drawbacks as shown in Figure . Customers have to share the same global address space, either using their own public IP addresses or relying on provider-assigned IP addresses. In both cases, connecting a new customer to a peer-to-peer VPN service usually requires IP renumbering inside the C-network. This is an operation that most customers are reluctant to perform. Peer-to-peer VPNs that are based on packet filters also incur high operational costs. These costs are associated with packet filter maintenance and performance degradation. Peer-to-peer VPNs that are implemented with per-customer PE routers are easier to maintain and can provide optimum routing performance. However, they are usually more expensive because every customer requires a dedicated router in every point of presence (POP). Therefore, this approach is usually used if the SP has only a small number of large customers.

Content 4.4 Describing MPLS VPN Technology 4.4.3 MPLS VPN Architecture The MPLS VPN architecture offers SPs a peer-to-peer VPN architecture that combines the best features of overlay VPNs (support for overlapping customer address spaces) with the best features of peer-to-peer VPNs. Figure lists the MPLS VPN features:

PE routers participate in customer routing, guaranteeing optimum routing between customer sites.
PE routers use a separate virtual routing table for each customer, resulting in perfect isolation between customers.
Customers can use overlapping addresses.

For the sake of understanding terms, Figure illustrates a simple MPLS VPN:

There are two parts of the network: a customer-controlled part (the C-network) and a provider-controlled part (the P-network).
Contiguous portions of the C-network are called sites and are linked with the P-network via CE routers (Customer A Site 2, Customer A Site 3, and so on). The CE routers connect to the PE routers that serve as the edge devices of the P-network. The core devices in the P-network provide transport across the provider backbone and do not carry customer routes.

Figure shows that the architecture of a PE router in an MPLS VPN is very similar to the architecture of a POP in the dedicated PE router peer-to-peer model. The only difference is that the whole PE router architecture is condensed into one physical device. Each customer is assigned an independent routing table, or virtual routing and forwarding (VRF) table. This routing table corresponds to the dedicated PE router in the traditional peer-to-peer model. Routing across the provider backbone is performed by another routing process that uses a global IP routing table. The MPLS VPN architecture offers the best features of both overlay VPNs and peer-to-peer VPNs. The next topic describes propagation of routing information across the P-Network. Note
Cisco IOS software implements isolation between customers via VRF tables. The whole PE router is still configured and managed as a single device, not as a set of virtual routers.

Content 4.4 Describing MPLS VPN Technology 4.4.4 Propagation of Routing Information Across the P-Network Although VRFs provide isolation between customers, the data from these routing tables still needs to be exchanged between PE routers to enable data transfer between sites that are attached to different PE routers. Therefore, you must choose a routing protocol that will transport all customer routes across the P-network, while maintaining the independence of individual customer address spaces. The best solution to the customer route propagation issue is to run a single routing protocol between PE routers that will exchange all customer routes without the involvement of the P routers. This solution, as shown in Figure , is scalable. There are benefits to this approach:

The number of routing protocols running between PE routers does not increase with an increasing number of customers.
The P routers do not carry customer routes.

The next design decision is the choice of the routing protocol running between PE routers. Because the total number of customer routes is expected to be very large, the only well-known protocol with the required scalability is Border Gateway Protocol (BGP). Therefore, BGP is used in MPLS VPN architecture to transport customer routes directly between PE routers.

Content 4.4 Describing MPLS VPN Technology 4.4.5 Using RDs in an MPLS VPN MPLS VPN architecture differs from traditional peer-to-peer VPN solutions in the support of overlapping customer address spaces. By deploying the BGP single routing protocol to exchange all customer routes between PE routers, an important question arises. How can BGP propagate several identical prefixes belonging to different customers between PE routers? Figure poses a question and introduces a solution. The only solution to this dilemma is the expansion of customer IP prefixes with a unique prefix that makes the addresses unique even if the addresses had previously overlapped. MPLS VPNs use a 64-bit prefix called the route distinguisher (RD) to convert non-unique 32-bit customer IPv4 addresses into 96-bit unique addresses that can be transported between PE routers. The RD is used only to transform non-unique 32-bit customer IPv4 addresses into unique 96-bit VPN version 4 (VPNv4) addresses. These addresses are also called VPN IPv4 addresses. VPNv4 addresses are exchanged only between PE routers; the addresses are never used between CE routers. The BGP session between PE routers must therefore support the exchange of traditional IPv4 prefixes and the exchange of VPNv4 prefixes. A BGP session between PE routers must support multiple protocols, so an MPBGP session is established. Figure shows the first three steps for customer route propagation across an MPLS VPN network: Step 1 The CE router sends an IPv4 routing update to the PE router. Step 2 The PE router prepends a 64-bit RD to the IPv4 routing update, resulting in a globally unique 96-bit VPNv4 prefix. Step 3 The VPNv4 prefix is propagated via an MPBGP session to other PE routers. Figure shows the next two steps: Step 4 The receiving PE routers strip the RD from the VPNv4 prefix, resulting in an IPv4 prefix. Step 5 The IPv4 prefix is forwarded to other CE routers within an IPv4 routing update. Figure summarizes the use of RDs in an MPLS VPN. The RD has no special meaning or role in MPLS VPN architecture. The only function of the RD is to make overlapping IPv4 addresses globally unique. Note
Because there has to be a unique one-to-one mapping between RD and VRFs, the RD could be viewed as the VRF identifier in the Cisco implementation of an MPLS VPN. The RD is configured at the PE router as part of the setup of the VPN site. The RD is not configured on the CE and is not visible to the customer. Simple VPN topologies require only one RD per customer. This requirement makes it possible for the RD to serve as a VPN identifier. This design, however, would not allow for the implementation of more complex VPN topologies, such as when a customer site belongs to multiple VPNs. VoIP Service in VPN