Technology Overview

In network-based VPNs, the VPN is built in to the provider network. The service provider defines the rules and policies for connectivity. The customer routers (CE devices) that are connected to the provider network forward IP packets toward the network core. The provider network is responsible for maintaining and distributing customer routes. No tunnel adjacencies are required between customers' routers, and the provider network is responsible for maintaining the route separation from one customer's VPN to another.

The three main components to MPLS-based VPNs are as follows:

• Separation of routing information between VPNs

• Constrained distribution of routing information to sites within a VPN

• Forwarding of packets through the network core

Let us now examine each of those components in some detail.

Separation of Routing Information Between VPNs

Separation of routing information between VPNs is a fundamental requirement for a network-based VPN service. If the routing information were to intermingle, packets from one VPN would be forwarded to another VPN, and this goes against the fundamental definition of the VPN network itself.

Within each VPN, the VPN customer advertises routes and addresses that are carried by a routing protocol. The routes advertised in one VPN by the routing protocol need to be separate from another VPN's.

The provider edge (PE) routers are responsible for keeping VPN A routes separate from VPN B routes. The PE devices hold each VPN's routes in a table called the virtual routing and forwarding (VRF) table. Each VRF within the PE holds customers' routes. All the PEs that connect to the same VPN must have a VRF for that VPN, and all routes within the VRF must be unique. However, because a separate routing and forwarding table is maintained per VPN in the PE device, the IP addressing can be reused between VPNs. For example, VPN A can have a 10.20/16, VPN B can also have a 10.20/16 prefix in its routing tables, and both VPNs can be on the same PE box. The PE always maintains the routing context of the VPN and forwards packets appropriately, without mixing the traffic from one VPN to another.

Routes are imported into a VRF or exported from a VRF. Routes can also be imported into multiple VRFs, creating overlapping VPNs or extranets. More details on extranets are provided later in this chapter. The PE always routes packets within a VPN unless by configuration, in which case it can send packets to a global table or other VPNs (extranets). The VRF table grows with the number of routes within a VPN. The VRF table is maintained only on the PE router, and no provider core router has any knowledge of the VRF table. (Subsequent sections examine how the core router forwards VPN packets.)

When CEs connect to PE routers, as shown in Figure 5-1, the CEs distribute routing information. The local PE then learns the information from the attached CEs and populates the VRF table. After all the PEs in the network learn the attached CE routes, they need to communicate with each other to exchange routes so that packets can be forwarded within the VPN.

Figure 5-1. Control Plane Path

Constrained Distribution of Routing Information

As stated earlier, after the PEs learn local information from the CE either through dynamic routing protocols or through static configuration, they need to distribute the routing information to other PEs in the network. For this routing distribution to happen, the following two things are required:

• A core addressing plan to separate routing information from VPNs is required. Remember that IP addresses can be reused within VPNs or even private addresses can be used within VPNs.

• A protocol for distribution of routing information between PEs is required. It must provide a peering relationship between PEs so that routing information about VPNs can easily be exchanged between the PEs without having to propagate/redistribute all this into the provider core.

The first problem can be solved by creating an addressing scheme that makes VPN addresses unique by prepending the VPN IP address by a route distinguisher (RD)for the lack of a better name, we can call this a VPN identifier. The details and formats of RD are the Cisco Press book MPLS and VPN Architectures, Vol 1, by I. Pepelnak and J. Guichard. By prepending the RD to the VPN IP addresses, by virtue of assignment, these VPN IP addresses become globally unique.

• VPNv4 prefix = RD + VPN IPv4 prefix

• RD = * byte field uniquely assigned by the providersignificant to the provider network only

These globally unique VPN addresses are also referred to as VPNv4 addresses. The PE routers exchange these VPNv4 addresses between themselves and learn about the remote routes and sites that require connectivity within the VPN. For more details on the allocation of RDs and an explanation of VPN addresses, you can also refer to the IETF RFC 4364.

The protocol used for distributing routing information is Multi-Protocol BGP (MP-BGP). BGP has been extended to carry VPNv4 addresses as part of the extended community attributes in the BGP network layer reacheability information (NLRI). An extended community attribute is an attribute carried in the NLRI. The PE receives the BGP updates, processes them, and populates the VRFs with the remote routes. To receive the updates, the PEs must peer with each other or peer with a route reflector.

A route reflector is a dedicated device that helps in BGP scalability by distributing routing information to the PE routers. MPLS labels are also distributed along with the VPNv4 addresses. The PE routers identify a VPN prefix by looking up the associated label and forward packets. We provide more information on packet forwarding behavior later in this chapter.

It might have been theoretically possible to use another protocol, such as LDP, for VPN routing distribution. However, the use of another protocol requires scaling properties for route updates to support a large number of sessions and requires a mechanism, such as a route reflector, to scale the number of sessions and information/routing distribution. The protocol must also be capable of providing mechanisms for filtering and creating flexible routing maps and policies. BGP is the only protocol that has proven to scale for IP routing with the Internet and to be capable of providing flexible routing policy configuration. BGP is naturally suited for the distribution of VPN routing information because it is currently used for Internet routing distribution.

For details of the routing relation ships between PEs, refer to Figure 5-1.

Forwarding Packets Through the Network Core

As stated earlier, labels are distributed with the VPN prefixes. However, for packets to reach the destination PEand ultimately the destination CEthe reachability information for the BGP next-hop must be available through an Interior Gateway Protocol (IGP). Examples of IGPs include OSPF, IS-IS, EIGRP, and the Routing Information Protocol (RIP). A label distribution protocol, such as LDP or RSVP-TE (when using traffic engineering), is needed to distribute labels for reachability of the PEs. The label-switched paths (LSP) established between PEs provide a path for forwarding VPN packets between them. This LSP is formed by the first label (outermost label) in the label stack. Remember that VPN packets themselves have a VPN label; this is usually the second label in label stack. The VPN-labeled packets are forwarded onto the LSP that has been set up between PE routers. The resulting MPLS packet carries multiple labels. The outermost label is called the IGP label, and the innermost label is called the VPN label.

Packet Flow Through the Network

To explain the forwarding of packets clearly, refer to the Figure 5-2.

Figure 5-2. Data Plane Path

The CEs in VPN A have a single routing relationship with only the attached PEs. The dual-attached CEs (CEs attached to two PEs) maintain two routing relationships with the attached PEs. The routing information is distributed to the CE by the PE via this routing relationship. The CEs wanting to send packets to other CEs in the VPN forward plain IP packets toward the PE. When the PE receives the packet, the PE knows from which VPN the packet is received, and it imposes the VPN label, which was distributed to other PEs. The PE now must forward the VPN labeled packet to the destination, and the ingress PE then imposes the IGP label and forwards the VPN packets on the LSP toward the network core. Thus, the PE imposes two labels (a VPN label and an IGP label) on the VPN IP packet. The core routers (P routers in the diagram) forward the packets toward the destination PE based on the outermost label. The penultimate hop along the LSP can remove the IGP label and forward the VPN-labeled packet to the destination PE. This is called the penultimate hop pop (PHP) operation. In some devices, the penultimate hop pop might be disabled, in which case the egress PE first pops the IGP label and then looks up the VPN label. The destination PE looks up the VPN label, removes the label, and forwards the IP frame to the attached CE.

When routes are withdrawndepending on the type of routes that changereconvergence must occur in the IGP or BGP. The LDP must also reconverge for any IGP changes. However, the LDP will not reconverge if only the BGP routes change, and BGP will not converge if the IGP routes change (unless the BGP next-hop changes). This provides some level of isolation of VPN routes from the provider core network. We investigate the convergence and how this can affect the offered SLA in Chapter 13, "Design Considerations: Putting it All Together."