IP Virtual Private Network Services

A VPN is a set of sites that is allowed to communicate with each other as a closed user group (CUG). There are many different VPN architectures. This section covers the benefits of the MPLS VPN architecture, as well as its operation.

I'll start by defining some terms used in an MPLS VPN environment:

• Provider (P) router A router that resides in the provider network. It is an LSR in pure MPLS terminology.

• Provider edge (PE) router A router that sits at the edge of the provider network and interfaces with customer edge routers. It is an eLSR using pure MPLS terminology.

• Customer (C) router A router that resides in the customer network.

• Customer edge (CE) router A router that resides at the edge of the customer network and interfaces with a PE router.

Figure 4-24 shows the MPLS VPN definitions.

Figure 4-24. MPLS VPN Definitions

The major goal of an MPLS VPN solution is to overcome the limitations of an overlay VPN model, while maintaining its strengths. An overlay VPN model presents scalability limitations because the CE routers peer with each other, and the number of Layer 2 connections in the provider network increases with the square of the number of CE routers.

The MPLS VPN model is a peer model in which all the customer sites peer with the PE devices, guaranteeing optimum routing between sites and simplifying the provisioning of additional VPNs. This peer model lets the service provider support very large-scale VPN service offeringsup to millions of VPNs in a single network. Purchasing VPN services allows a VPN customer to rely on the service provider to deal with routing, scalability, QoS, and performance issues. Service providers can support customers with different needs using VPNs.

Figure 4-25 shows how a peer model works.

Figure 4-25. MPLS VPN Route Distribution

In summary, the MPLS VPN model combines the strengths of the overlay and peer-to-peer VPN models:

• Peer-to-peer model Simplifies customer routing, as well as eliminates the requirement of maintaining full IP routing in the MPLS core.

• Overlay model Provides isolation between customers, privacy, and security.

Service providers implementing MPLS VPNs distribute customer routes using the following steps (which are illustrated in Figure 4-25):

Step 1.	The CE router for customer A sends routing updates to the ingress PE in the MPLS network using an IGP, such as OSPF, RIP, or eBGP. Note that no routing updates are sent if static routes are used.
Step 2.	At the ingress PE, these routes are inserted into a separate routing table for this VPN and then are exported into the provider's multiprotocol BGP.
Step 3.	These routes are then advertised within the provider's network among all the PEs using the MP-BGP extensions.
Step 4.	At the egress PE, all the routing information is imported to customer A's VPN routing table from the provider's iBGP.
Step 5.	The routing information is sent to the destination CE. As in Step 1, no routing updates are sent if static routes are used.

A new concept can be inferred from the MPLS VPN peer model functionality: CE devices have point-to-network connections, as opposed to the point-to-point connections in the overlay VPN model. In the MPLS VPN model, sites are configured, whereas in the overlay VPN model, links are configured. This is shown in Figure 4-26.

Figure 4-26. Point-to-Cloud Connections

VPN Route Distribution and Filtering

VPN route distribution and filtering happen in the application plane on top of MPLS. VPN routes need to be distributed and VPN labels assigned to VPNv4 routes using multiprotocol BGP (MP-BGP) before user traffic can traverse the MPLS VPN network and MPLS is used to switch labeled packets through the provider network. You can control the routing information distribution using route filtering based on the BGP extended community attributes.

You can apply the filters in Steps 2 and 4 from the preceding section. Route filtering is performed against the route target (RT), which is a 64-bit value attached to MP-BGP VPNv4 routes.

This kind of operation is also used to ensure a secure VPN for each customer. Each PE has multiple VPN routing and forwarding (VRF) tables, one for each VPN customer. This is shown in Figure 4-27.

Figure 4-27. MPLS VPN with Two Customers

Each VRF is populated with routes received from directly connected CE routers, as well as routes received from other PEs via BGP filtering based on BGP extended community attributes.

Customer packets traversing a provider VPN MPLS network carry two labels. An inner VPN label called bottom label distributed by MP-BGP indicates VPN membership. MPLS uses an outer label called top label distributed by the IGP and LDP to switch the packet from ingress PE to egress PE. These two labels have the following characteristics:

• Top label Distributed by LDP and derived from an IGP route. Corresponds to a PE address, which in turn is the MP-BGP next hop of VPNv4 routes.

• Bottom label Distributed by MP-BGP. It corresponds to a VPNv4 route and identifies the outgoing interface or VRF to be used to reach the VPN destination.

This can be seen in Figure 4-28.

Figure 4-28. MPLS VPN Label Stack

As a side note regarding Figure 4-28, in a frame-based MPLS environment, provider LSR P2 would perform PHP to remove the top label. PE LSR PE2 using LDP would request this action. In this case, PE2 eLSR would do only a single lookup and would forward the IP packet to CE2.

One of the reasons for the great scalability of an MPLS VPN solution is that provider routers do not have MP-BGP or VPN knowledge.

VPN IP Addressing

In an MPLS VPN network, different customers can use the same IPv4 address space, as well as private IP addresses (see RFC 1918). VPN-IPv4 addresses make each customer's IPv4 address unique within the provider's network. A VPN-IPv4 or VPNv4 address has a 64-bit field called a route distinguisher (RD) that is prepended to the 32-bit IPv4 address to make a unique 96-bit VPNv4 address. This is shown in Figure 4-29.

Figure 4-29. VPNv4 Address

The RD is never carried in packetsonly in label tables. PE routers perform the conversion between customer IPv4 addresses and provider VPNv4 addresses. This happens only in the control plane before the routes are exported into MP-BGP.

The RD can be seen as a VRF identifier that solves the overlapping address space problem.

MP-BGP lets BGP handle routes for multiple VPNv4 addresses. The general process is no different from handling traditional IPv4 addresses. The different addresses, such as IPv4, IPv6, NSAP, IPv4 multicast, and VPNv4, are called address families. Multiprotocol extensions for BGP-4 are defined in RFC 2283 and RFC 2858, using address families from RFC 1700, "Assigned Numbers." The VPN-IPv4 address family is defined in Section 4.1 of RFC 2547, "BGP/MPLS VPNs."

BGP tables can have a mixture of both VPN-IPv4 routes and normal IPv4 routes. CE routers have no knowledge of VPN-IPv4 addressing. CEs send and receive regular IPv4 routing updates.

The presence of RDs and independent RTs gives the MPLS VPN model great flexibility in implementing complex VPN scenarios.