Core Issue
A Virtual Private Network (VPN) is as a network in which connectivity a customer’s
multiple sites is deployed on a shared infrastructure with the same access or security
policies as in a private network. VPNs allow multiple customers to share a common
public infrastructure similar to the Internet, with the same level of security as in a
private network. This results in cost savings and flexibility in connectivity options for
the customer. VPNs can be implemented by using either an overlay or a peer-to-peer
model. Each model has its own advantages and disadvantages.
The Multiprotocol Label Switching (MPLS) VPN architecture provides the service
providers with a peer-to-peer model which combines the best features of overlay and
peer-to-peer models. The MPLS VPN terminology divides the overall network into a
customer controlled part (C-network) and a provider controlled part (P network). The
contiguous portions of the C-network are called sites and are linked with the P
network through Customer Edge (CE) routers. The CE routers are connected to the
Provider Edge (PE) routers, which serve as the edge device of the P network. The core
devices, or the P-routers, in the P network provide the transit transport across the
service provider backbone. In MPLS VPN, PE routers participate in customer routing,
providing optimum routing between sites and easy provisioning of sites. It also allows
customers to use overlapping addresses. The PE routers contains separate set of routes
for each customer, which results in perfect isolation between them.
Resolution
The MPLS VPN architecture is designed to address these requirements:
The customer routers need not be MPLS-VPN aware.
The P routers should not carry customer routes (otherwise called as VPN routes) to
make the solution more scalable.
The PE routers should support MPLS VPN services.
These requirements are addressed in these ways:
The CE routers use static routing or run any standard IP routing protocol, such as Routing Information Protocol version 2 (RIPv2), Open Shortest Path First (OSPF) or Border Gateway Protocol (BGP) with the PE devices to exchange routing information.
The P routers do not carry VPN routes. They run Interior Gateway Protocol (IGP) with other P and PE devices to learn about the subnets within the P network and use MPLS for forwarding packets.
The PE routers learn about the VPN routes from CE routers through any of the above routing protocols. They provide isolation between different customers by installing these routes in separate routing tables called Virtual Routing and Forwarding (VRF) instances. The PE routers exchange these VPN routes with other PE devices using Multiprotocol BGP (MBGP) as the routing protocol. The PE routers also run an IGP with other P and PE devices in the P network and use MPLS for forwarding packets across the P network. The PE router still has a global routing table for forwarding packets to destinations in the P network.
Configuring MPLS VPN can be broken down into these sub-tasks:
Configure an IGP and enable MPLS in the P network. Enable Cisco Express Forwarding (CEF) and MPLS on all the devices in the P network, and configure an IGP to exchange routes for networks available in the P network. These routes are stored in the global routing table on the PE devices and have a label associated with them. They are distributed using Label Distribution Protocol (LDP) or Tag Distribution Protocol (TDP).
Configure VRF on the PE devices. A VRF consists of an IP routing table, a derived CEF table, and a set of interfaces that use the forwarding table. There can be multiple VRFs on the same PE device. Sites that have identical routing requirements and are connected to the same PE router can use the same VRF. Each VRF should be configured with the Route Distinguisher (RD) and Route Target (RT) parameters.
Since the MPLS VPN architecture allows the customers to use overlapping IP addresses, the addresses from different customers must be distinguished when they are advertised across the P network using MBGP. RD is a 64-bit value, which is prefixed to the 32-bit Information Protocol version 4 (IPv4) routes. These are learned from the customer to make them a unique 96-bit address called a VPNv4 address, which is then advertised to other PE devices. Each VRF on the PE device must be assigned a unique value as an RD, and a VRF can have only one RD assigned.
The RT parameter indicates the VPN membership of a route. There can be complex VPN requirements where some customer sites could be part of a single VPN, but other sites of the same customer could be part of multiple or overlapping VPNs. Since the RD only makes the addresses unique and does not indicate VPN membership, the RT parameter is used for this purpose. RTs are represented using Extended BGP Community Attributes which are 64 bits long. Any number of RTs can be attached to a route to indicate membership in more than one VPN. RTs are attached to a route when they are converted from an IPv4 address to a VPNv4 address by the PE router. These RTs are called export RTs, and they are configured for each VRF on the PE device. When the VPNv4 routes are propagated to other PE devices, those routers should select the routes to be inserted into the appropriate VRF. This selection is based on import RTs, and it is configured for each VRF.
Configure MBGP between PE devices. While the VRFs provide the isolation between different customers, the routes in these routing tables need to be exchanged with other PE devices to enable data transfer between sites attached to different PE routers. A routing protocol which transports all the customer routes across the P network is needed. The P-routers should not know about the VPN routes to make it more scalable. This is one of the requirements to be addressed by the MPLS VPN architecture. Since the number of VPN routes can be large, BGP is the only protocol which provides the required scalability.
BGP is required in MPLS VPN setup to transport customer routes directly between PE routers and to use MPLS labels to exchange packets between PE routers. Since BGP was capable of carrying only traditional IPv4 prefixes, it has been enhanced to carry the 96-bit VPNv4 prefixes, along with extended community attributes like RTs. This enhanced version is called MBGP. Since the PE routers have multiple routing tables associated with different VRFs, the MPLS label called VPN label (carried in the MBGP update along with the prefix) is used for identifying the VRF that must be used while receiving packets to forward to the destination.
Configure the PE-CE routing protocol on PE and CE devices. Cisco devices support using either static routes or RIPv2, OSPF and BGP to exchange IPv4 routes between the PE and CE devices. These protocols are VRF aware which allow to run separate instances of the same protocol for each VRF on the PE device. The routes that are learned via the interface belonging to a particular VRF are populated in the routing table for that particular VRF and provide isolation.
Configure redistribution between PE-CE routing protocol and MBGP on the PE devices. The PE devices learn about the VPN routes as IPv4 prefixes from the attached CE devices using a PE-CE routing protocol or through static routing. They are stored in the routing table of the corresponding VRF. These routes are then advertised to other PE devices as VPNv4 routes through MBGP. This is done by redistributing the static routes (or the PE-CE routing protocol) into MBGP. While redistributing from the PE-CE routing protocol to MBGP, the RD corresponding to the VRF is prefixed to the IPv4 routes and converted into VPNv4 routes. The RT value configured as export RT for the VRF is attached to the VPNv4 routes. These VPNv4 routes are then advertised to other PE routers through MBGP.
When a PE router receives VPNv4 routes from another PE router, it imports routes that have an RT value that matches at least one import RT configured for a VRF, into the routing table of that VRF as IPv4 routes learned through BGP. These routes are then advertised to the attached CE devices using the PE-CE routing protocol. This is achieved by redistributing MBGP into the PE-CE routing protocol. The VPN routes are propagated between different sites of the customers.
Since the P routers are not running BGP and do not learn about the VPN routes belonging to customers, they drop any packets that are received without any label or with just the VPN label. The packet forwarding from one site to another site still must be done through the PE devices, which are connected across the P network through the P routers. Label the packets with a second label, which is assigned by Tag Distribution Protocol (TDP) or Label Distribution Protocol (LDP) for reaching the BGP next-hop, which is the other PE to which the destination site is connected. The BGP next-hop reachability is known to all the routers in the P network through the IGP.
There are labels for that address through TDP and LDP. The outer label learned through TDP or LDP is used for forwarding packets across the P network to the other PE device. The P routers forward the packets from one PE to the other, based on this outer label. They do not know about the inner VPN label or the VPN destination address. When the packet reaches the other PE device, the inner VPN label advertised through MBGP is used for finding the outgoing interface or the VRF routing table to be used for forwarding the packets.
When a CE device of a site needs to send a packet to another site, it sends a normal, unlabeled packet to the attached PE device. The PE device acting as the ingress Label Switch Router (LSR), which receives this unlabeled packet, adds a label stack of two labels by looking at its Forwarding Information Base (FIB) table, and forwards it inside the P network. The inner label is the VPN label learned through MBGP from the egress PE device. It is used for tagging the data packets for that particular VPN destination. The outer label is the one learned through TDP or LDP, and it is learned from the next-hop P router used for reaching the egress PE device.
The P-router receives labeled packets, performs a lookup in the Incoming FIB (IFIB) table, swaps the incoming label in the outer label with the Outgoing label, and forward the packets towards the next-hop router. The P router, which is one hop before the egress PE device, removes the outer label due to Penultimate Hop Popping (PHP) and forwards the packet with just the VPN label to the egress PE device. The egress PE device uses the Label Forwarding Information Base (LFIB) table to perform the label lookup, removes the VPN label in the incoming packets, and forwards the unlabeled packets towards the destination site.
