W4_JTO_Ph2_Datacom_IT-part-5.pdf

JTO Phase II Data Network & IT MPLS Based Layer-3 VPN 5 MPLS based layer-3 VPN 5.1 Learning objectives The objective of this chapter is to understand:  Virtual Private Networks  Overlay and peer-to-peer VPN models  Overview o...

JTO Phase II Data Network & IT MPLS Based Layer-3 VPN 5 MPLS based layer-3 VPN 5.1 Learning objectives The objective of this chapter is to understand:  Virtual Private Networks  Overlay and peer-to-peer VPN models  Overview of MPLS VPN components and architecture  VRFs, route distinguishers, and route targets  MP-BGP operation and interaction  Control plane and data plane operation in MPLS VPN 5.2 introduction MPLS technology is being widely adopted by service providers worldwide to implement VPNs to connect geographically separated customer sites. Previous chapters introduce the basic concepts of MPLS and its operation, as well as configuring MPLS for data forwarding. This chapter builds on that foundation and shows how to use MPLS to provide VPN services to customers. This chapter also presents the terminology and operation of various devices in an MPLS network used to provide VPN services to customers. In an MPLS Layer 3 VPN, routing occurs on the service provider's routers. The provider routers route and forward VPN traffic at the entry and exit points of the transit network. Based on the source address, the PE router filters route advertisements and imports them into the appropriate VRF table. 5.3 Virtual Private Network A Virtual Private Network (VPN) is a technology that helps to create a private network across a public network (e.g., the Internet), collection of virtual links which logically interconnect the different network components over a physical network and also is a network in which information is transmitted using cryptographic and authentication algorithms. It is virtual since there is no real physical connection between the sites. A VPN uses shared public telecom infrastructure, such as the Internet, to provide secure access to remote offices and users in a cheaper way than an owned or leased line. The virtual private network is mainly used to establish connections between different corporate branches or remote activities when using less secure network lines. With the help of data encryption, a network inside the Internet, for example, can only be accessed by those who have the necessary addresses and passwords. One of the most capability of MPLS is to possibility to build Virtual Private Networks (VPNs). MPLS has the capability to construct both Layer 2 and Layer 3 MPLS VPNs. Both types of VPNs have their own merits and demerits. VPNs became popular during past two decades because of the evolution of related technologies. Primarily, the implementation cost of virtual networks had dropped drastically as a result of the availability of low-cost network equipment and communication systems JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 57 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN 5.4 VPN Categories VPNs were originally introduced to enable service providers to use common physical infrastructure to implement emulated point-to-point links between customer sites. A customer network implemented with any VPN technology would contain distinct regions under the customer's control called the customer sites connected to each other via the service provider (SP) network. In traditional router-based networks, different sites belonging to the same customer were connected to each other using dedicated point-to- point links. The cost of implementation depended on the number of customer sites to be connected with these dedicated links. A full mesh of connected sites would consequently imply an exponential increase in the cost associated. Frame Relay and ATM were the first technologies widely adopted to implement VPNs. These networks consisted of various devices, belonging to either the customer or the service provider, that were components of the VPN solution. Generically, the VPN realm would consist of the following regions:  Customer network— Consisted of the routers at the various customer sites. The routers connecting individual customers' sites to the service provider network were called customer edge (CE) routers.  Provider network— Used by the service provider to offer dedicated point-to- point links over infrastructure owned by the service provider. Service provider devices to which the CE routers were directly attached were called provider edge (PE) routers. In addition, the service provider network might consist of devices used for forwarding data in the SP backbone called provider (P) routers. Depending on the service provider's participation in customer routing, the VPN implementations can be classified broadly into one of the following:  Overlay model  Peer-to-peer model When Frame Relay and ATM provided customers with emulated private networks, the provider did not participate in customer routing. The service provider was only responsible for providing the customer with transport of customer data using virtual point-to-point links. As a result, the service provider would only provide customers with virtual circuit connectivity at Layer 2; this implementation was referred to as the Overlay model. If the virtual circuit was permanent or available for use by the customer at all times, it was called a permanent virtual circuit (PVC). If the circuit was established by the provider on-demand, it was called a switched virtual circuit (SVC). The primary drawback of an Overlay model was the full mesh of virtual circuits between all customer sites for optimal connectivity (except in the case of hub and spoke or partial hub and spoke deployments). If the number of customer sites was N, N(N-1)/2 was the total number of circuits that would be necessary for optimal routing. Overlay VPNs were initially implemented by the SP by providing either Layer 1 (physical layer) connectivity or a Layer 2 transport circuit between customer sites. In the Layer 1 implementation, the SP would provide physical layer connectivity between customer sites, and the customer was responsible for all other layers. In the Layer 2 JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 58 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN implementation, the SP was responsible for transportation of Layer 2 frames (or cells) between customer sites, which was traditionally implemented using either Frame Relay or ATM switches as PE devices. Therefore, the service provider was not aware of customer routing or routes. Later, overlay VPNs were also implemented using VPN services over IP (Layer 3) with tunneling protocols like L2TP, GRE, and IPSec to interconnect customer sites. In all cases, the SP network was transparent to the customer, and the routing protocols were run directly between customer routers. Figure 31: Overlay and Peer-to-Peer Models JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 59 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN The peer-to-peer model was developed to overcome the drawbacks of the Overlay model and provide customers with optimal data transport via the SP backbone. Hence, the service provider would actively participate in customer routing. In the peer-to-peer model, routing information is exchanged between the customer routers and the service provider routers, and customer data is transported across the service provider's core, optimally. Customer routing information is carried between routers in the provider network (P and PE routers) and customer network (CE routers). The peer-to-peer model, consequently, does not require the creation of virtual circuits. As illustrated in Figure above, the CE routers exchange routes with the connected PE routers in the SP domain. Customer routing information is propagated across the SP backbone between PE and P routers and identifies the optimal path from one customer site to another. Separation of customer-specific routing information is achieved by implementing packet filters at the routers connecting to the customer network. Additionally, IP addressing for the customer is handled by the service provider. This process is also referred to as the shared PE peer-to-peer implementation. Figure below depicts the various implementations of the peer-to-peer model. Figure 32: Peer-to-Peer Model Implementations Controlled route distribution was another method of implementing the peer-to-peer model; routers in the core of the service provider's network contained network layer reachability information for all customers' networks. The PE routers (connecting customer network to provider network) in the provider network would contain only information pertaining to their connected customers. A dedicated PE router was required for each customer's site connecting to the provider network, and controlled route distribution would occur between P and PE routers in the SP backbone network. Only pertinent customer routes would be propagated to PE routers that were connected to sites belonging to a specific customer. BGP with communities was usually used in the SP backbone because it offered the most versatile route-filtering tools. This implementation is often referred to as the dedicated PE peer-to-peer model. This implementation, however, did not prove to be a viable operating business model due to the higher equipment costs that were incurred by the provider to maintain dedicated edge routers for JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 60 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN customer sites connecting into the provider backbone. A need arose for deploying efficient VPN architectures that could implement a scalable peer-to-peer model. 5.5 MPLS VPN Architecture and Terminology In the MPLS VPN architecture, the edge routers carry customer routing information, providing optimal routing for traffic belonging to the customer for inter-site traffic. The MPLS-based VPN model also accommodates customers using overlapping address spaces, unlike the traditional peer-to-peer model in which optimal routing of customer traffic required the provider to assign IP addresses to each of its customers (or the customer to implement NAT) to avoid overlapping address spaces. MPLS VPN is an implementation of the peer-to-peer model; the MPLS VPN backbone and customer sites exchange Layer 3 customer routing information, and data is forwarded between customer sites using the MPLS-enabled SP IP backbone. The MPLS VPN domain, like the traditional VPN, consists of the customer network and the provider network. The MPLS VPN model is very similar to the dedicated PE router model in a peer-to-peer VPN implementation. However, instead of deploying a dedicated PE router per customer, customer traffic is isolated on the same PE router that provides connectivity into the service provider's network for multiple customers. The components of an MPLS VPN shown in figure below, are highlighted next. Figure 33: MPLS VPN Network Architecture The main components of MPLS VPN architecture are  Customer network, which is usually a customer-controlled domain consisting of devices or routers spanning multiple sites belonging to the customer. In figure below, the customer network for Customer A consists of the routers CE1-A and CE2-A along with devices in the Customer A sites 1 and 2.  CE routers, which are routers in the customer network that interface with the service provider network. In Figure below, the CE routers for Customer A are CE1-A and CE2-A, and the CE routers for Customer B are CE1-B and CE2-B. A CE resides on a JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 61 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN customer network and has one or more interfaces directly connected with service provider networks. It can be a router, a switch, or a host. It can neither "sense" the existence of any VPN nor does it need to support MPLS.  Provider network, which is the provider-controlled domain consisting of provider edge and provider core routers that connect sites belonging to the customer on a shared infrastructure. The provider network controls the traffic routing between sites belonging to a customer along with customer traffic isolation. In Figure 3-3, the provider network consists of the routers PE1, PE2, P1, P2, P3, and P4.  PE routers, which are routers in the provider network that interface or connect to the customer edge routers in the customer network. PE1 and PE2 are the provider edge routers in the MPLS VPN domain for customers A and B in Figure below. A PE resides on a service provider network and connects one or more CEs to the network. On an MPLS network, all VPN processing occurs on the PEs.  P routers, which are routers in the core of the provider network that interface with either other provider core routers or provider edge routers. Routers P1, P2, P3, and P4 are the provider routers in Figure below. A P device is a core device on a service provider network. It is not directly connected with any CE. It only needs to be equipped with basic MPLS forwarding capability. Figure 34: Routers in MPLS VPN 5.6 MPLS VPN Routing Model An MPLS VPN implementation is very similar to a dedicated router peer-to-peer model implementation. From a CE router's perspective, only IPv4 updates, as well as data, are forwarded to the PE router. The CE router does not need any specific configuration to enable it to be a part of a MPLS VPN domain. The only requirement on the CE router is a routing protocol (or a static/default route) that enables the router to exchange IPv4 routing information with the connected PE router. In the MPLS VPN implementation, the PE router performs multiple functions. The PE router must first be capable of isolating customer traffic if more than one customer is JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 62 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN connected to the PE router. Each customer, therefore, is assigned an independent routing table similar to a dedicated PE router in the initial peer-to-peer discussion. Routing across the SP backbone is performed using a routing process in the global routing table. P routers provide label switching between provider edge routers and are unaware of VPN routes. CE routers in the customer network are not aware of the P routers and, thus, the internal topology of the SP network is transparent to the customer. Figure below depicts the PE router's functionality. Figure 35: MPLS VPN Architecture The P routers are only responsible for label switching of packets. They do not carry VPN routes and do not participate in MPLS VPN routing. The PE routers exchange IPv4 routes with connected CE routers using individual routing protocol contexts. To enable scaling the network to large number of customer VPNs, multiprotocol BGP is configured between PE routers to carry customer routes. a) VRF: Virtual Routing and Forwarding Table Customer isolation is achieved on the PE router by the use of virtual routing tables or instances, also called virtual routing and forwarding tables/instances (VRFs). In essence, it is similar to maintaining multiple dedicated routers for customers connecting into the provider network. The function of a VRF is similar to a global routing table, except that it contains all routes pertaining to a specific VPN versus the global routing table. The VRF also contains a VRF-specific CEF forwarding table analogous to the global CEF table and defines the connectivity requirements and protocols for each customer site on a single PE router. The VRF defines routing protocol contexts that are part of a specific VPN as well as the interfaces on the local PE router that are part of a specific VPN and, hence, use the VRF. The interface that is part of the VRF must support CEF switching. The number of interfaces that can be bound to a VRF is only limited by the number of interfaces on the router, and a single interface (logical or physical) can be associated with only one VRF. The VRF contains an IP routing table analogous to the global IP routing table, a CEF table, list of interfaces that are part of the VRF, and a set of rules defining routing protocol exchange with attached CE routers (routing protocol contexts). In addition, the VRF also contains VPN identifiers as well as VPN membership information (RD and RT are covered in the next section). Figure below shows the function of a VRF on a PE router to implement customer routing isolation. JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 63 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN Figure 36: VRF Implementation on PE Router As shown in Figure below, Cisco IOS supports a variety of routing protocols as well as individual routing processes (OSPF, EIGRP, etc.) per router. However, for some routing protocols, such as RIP and BGP, IOS supports only a single instance of the routing protocol. Therefore, to implement per VRF routing using these protocols that are completely isolated from other VRFs, which might use the same PE-CE routing protocols, the concept of routing context was developed. Routing contexts were designed to support isolated copies of the same VPN PE-CE routing protocols. These routing contexts can be implemented as either separated processes, as in the case of OSPF, or as multiple instances of the same routing protocol (in BGP, RIP, etc.). If multiple instances of the same routing protocol are in use, each instance has its own set of parameters. Cisco IOS currently supports either RIPv2 (multiple contexts), EIGRP (multiple contexts), OSPFv2 (multiple processes), and BGPv4 (multiple contexts) as routing protocols that can be used per VRF to exchange customer routing information between CE and PE. Note that the VRF interfaces can be either logical or physical, but each interface can be assigned to only one VRF. b) Route Distinguisher, Route Targets, MP-BGP, and Address Families In the MPLS VPN routing model, the PE router provides isolation between customers using VRFs. However, this information needs to be carried between PE routers to enable data transfer between customer sites via the MPLS VPN backbone. The PE router must be capable of implementing processes that enable overlapping address spaces in JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 64 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN connected customer networks. The PE router must also learn these routes from attached customer networks and propagate this information using the shared provider backbone. This is done by the association of a route distinguisher (RD) per virtual routing table on a PE router. A RD is a 64-bit unique identifier that is prepended to the 32-bit customer prefix or route learned from a CE router, which makes it a unique 96-bit address that can be transported between the PE routers in the MPLS domain. Thus, a unique RD is configured per VRF on the PE router. The resulting address, which is 96-bits total (32-bit customer prefix + 64-bit unique identifier or RD), is called a VPN version 4 (VPNv4) address. VPNv4 addresses are exchanged between PE routers in the provider network in addition to IPv4 (32-bit) addresses. The format of an RD is shown in Figure below. As shown in Figure below, RD can be of two formats. If the provider does not have a BGP AS number, the IP address format can be used, and, if the provider does have an AS number, the AS number format can be used. Figure below also shows the same IP prefix, 172.16.10.0/24, received from two different customers, is made unique by prepending different RD values, 1:100:1 and 1:101, prior to propagating the addresses as VPNv4 addresses on the PE router. Figure 37: RD Operation in MPLS VPN The protocol used for exchanging these VPNv4 routes between PE routers is multiprotocol BGP (MP-BGP). BGP capable of carrying VPNv4 (96-bit) prefixes in addition to other address families is called MP-BGP. The IGP requirement to implement iBGP (internal BGP) still holds in the case of an MPLS VPN implementation. Therefore, the PE router must run an IGP that provides NLRI information for iBGP if both PE routers are in the same AS. Cisco currently supports both OSPFv2 and ISIS in the MPLS provider network as the IGP. MP-BGP is also responsible for assignment of a VPN label. JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 65 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN Packet forwarding in an MPLS VPN mandates that the router specified as the next hop in the incoming BGP update is the same router that assigns the VPN label. Scalability was a primary reason for the choice of BGP as the protocol to carry customer routing information. In addition, BGP enables the use of VPNv4 address in an MPLS VPN router environment that enables overlapping address ranges with multiple customers. An MP-BGP session between PE routers in a single BGP AS is called an MP-iBGP session and follows rules as in the implementation of iBGP with regards to BGP attributes. If the VPN extends beyond a single AS, VPNv4 routes will be exchanged between AS at the AS boundaries using an MP-eBGP session. Route targets (RTs) are additional identifiers used in the MPLS VPN domain in the deployment of MPLS VPN that identify the VPN membership of the routes learned from that particular site. RTs are implemented by the use of extended BGP communities in which the higher order 16 bits of the BGP extended community (64 total bits) are encoded with a value corresponding to the VPN membership of the specific site. When a VPN route learned from a CE router is injected into VPNv4 BGP, a list of VPN route target extended community attributes is associated with it. The export route target is used in identification of VPN membership and is associated to each VRF. This export route target is appended to a customer prefix when it is converted to a VPNv4 prefix by the PE router and propagated in MP-BGP updates. The import route target is associated with each VRF and identifies the VPNv4 routes to be imported into the VRF for the specific customer. The format of a RT is the same as an RD value. The interaction of RT and RD values in the MPLS VPN domain as the update is converted to an MP-BGP update is shown in Figure below. Figure 38: RT and RD Operation in an MPLS VPN JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 66 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN When implementing complex VPN topologies, such as extranet VPN, Internet access VPNs, network management VPN, and so on, using MPLS VPN technology, the RT plays a pivotal role. A single prefix can be associated to more than one export route target when propagated across the MPLS VPN network. The RT can, as a result, be associated to sites that might be a member of more than one VPN. The following processes occur during route propagation in an MPLS VPN, as shown in Figure: 1. The prefix 172.16.10.0/24 is received from CE1-A, which is part of VRF CustomerA on PE1-AS1. 2. PE1 associated an RD value of 1:100 and an export RT value of 1:100 as configured in the VRF definition on the PE1-AS1 router. 3. Routes learned from connected CE routers CE1-A are redistributed into the MP-BGP process on PE1-AS1 where the prefix 172.16.10.0/24 is prepended with the RD value of 1:100 and appended with the route target extended community value (export RT) of 1:100 prior to sending the VPNv4 prefix as part of the MP-iBGP update between PE routers. The VPN label (3 bytes) is assigned for each prefix learned from the connected CE router's IGP process within a VRF by the PE router's MP-BGP process. MP-BGP running in the service provider MPLS domain thus carries the VPNv4 prefix (IPv4 prefix + prepended RD) in addition to the BGP route target extended community. Note that although the RT is a mandatory configuration in an MPLS VPN for all VRFs configured on a router, the RT values can be used to implement complex VPN topologies in which a single site can be a part of more than one VPN. In addition, RT values can also be used to perform selective route importing into a VRF when VPNv4 routes are learned in MP-iBGP updates. The VPN label is only understood by the egress PE (data plane) that is directly connected to the CE router advertising the prefix. Note that the next hops on PE routers must not be advertised in the BGP process but must be learned from the IGP for MPLS VPN implementation. The VPN label has been depicted by the entries V1 and V2 in Figure. 4. The MP-BGP update is received by the PE router PE2, and the route is stored in the appropriate VRF table for Customer A based on the VPN label. 5. The received MP-BGP routes are redistributed into the VRF PE-CE routing processes, and the route is propagated to CE2-A. In addition, other BGP extended community attributes such as site of origin (SoO) can also be applied to the MP-iBGP update prior to propagation. The SoO attribute is used to identify the specific site from which the PE learns the route and is used in the identification and prevention of routing loops. The SoO extended community is a BGP extended community attribute used to identify routes that have originated from a site so that the re-advertisement of that prefix back to the source site can be prevented, thus preventing routing loops. The SoO extended community uniquely identifies the site from JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 67 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN which a PE router has learned a route. SoO enables filtering of traffic based on the site from which it was originated. SoO filtering manages MPLS VPN traffic and prevents routing loops from occurring in complex and mixed network topologies in which the customer sites might possess connectivity across the MPLS VPN backbone as well as possess backdoor links between sites. The implementation of a MPLS VPN in which all VPN sites belonging to a customer can speak to all other sites in the same customer domain is called a simple VPN implementation or intranet VPN. As mentioned earlier, RTs can be used to implement complex VPN topologies in which certain sites that are part of one customer's domain are also accessible by other customers' VPN sites. This implementation is called an extranet VPN. In addition, variants of extranet VPN, such as network management VPN as well as central services VPN and Internet access VPN, can also be deployed. It is important to understand the concept of address families and their place in the operation of MP-BGP to enable the transport of VPNv4 routes with extended community attributes. Prior to RFC 2283, "Multiprotocol Extensions for BGP-4," BGP version 4 was capable of carrying routing information only pertaining to IPv4. RFC 2283 defines extensions to BGP-4 that enable BGP-4 to carry information for multiple network layer protocols. RFC 2283 states that to enable BGP-4 to support routing for multiple network layer protocols, the additions to BGP-4 must account for the ability of a particular network layer protocol to be associated with a next hop as well as the NLRI (network layer reachability information). The two new attributes that were added to BGP were Multiprotocol Reachable NLRI (MP_REACH_NLRI), and Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI). MP_REACH_NLRI carries the set of reachable destinations together with the next-hop information to be used for forwarding to these destinations. MP_UNREACH_NLRI carries the set of unreachable destinations. Both of these attributes are optional and nontransitive. Therefore, a BGP speaker that does not support these multiprotocol capabilities will just ignore the information carried in these attributes and will not pass it to other BGP speakers. An address family is a defined network layer protocol. An address family identifier (AFI) carries an identity of the network layer protocol associated with the network address in the multiprotocol attributes in BGP. (Address family identifiers for network layer protocols are defined in RFC 1700, "Assigned Numbers.") The PE router, in essence, is an Edge LSR and performs all the functions of an Edge LSR. The PE router requires LDP for label assignment and distribution as well as forward labeled packets. In addition to the functions of an Edge LSR, the PE implements a routing protocol (or static routes) with connected CE routers per virtual routing table and requires MP-BGP to propagate prefixes learned from CE routers as VPNv4 prefixes in MP-iBGP updates to other PE routers along with the VPN label. The P router's requirements are to run an IGP (either OSPF or ISIS) as well as have MPLS enabled to forward labeled packets (data plane) between PE routers. The IGP is used to provide, as well as propagate, NLRI to connected P and PE routers to implement an MP-iBGP session between PE routers (control plane). LDP is run on the P router for label assignment and distribution. JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 68 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN c) MPLS VPN Control Plane Operation The control plane in MPLS VPN implementation contains all the Layer 3 routing information and the processes within to exchange reachability information for a specific Layer 3 IP prefix in addition to label assignment and distribution using LDP. The data plane performs the functions relating to the forwarding of both labeled as well as IP packets to the next hop toward a destination network. Figure below outlines the interactions of protocols in the control plane in an MPLS VPN implementation. Figure 39: Control Plane Interactions in MPLS VPN The CE routers are connected to the PE routers, and an IGP, BGP, or static route is required on the CE routers in conjunction with attached PE routers to gather and advertise NLRI information. In the MPLS VPN backbone consisting of P and PE routers, an IGP (usually either OSPF or ISIS) in addition to LDP is used between PE and P routers. LDP is used for allocation as well as distribution of labels in the MPLS domain. The IGP is used for NLRI information exchange as well as to map this NLRI into MP-BGP. MP- BGP sessions are maintained between PE routers in an MPLS VPN domain and exchange MP-BGP updates consisting of unique VPNv4 addresses in addition to BGP extended community attributes associated with specific VPNv4 addresses. Packets from CE to PE are always propagated as IPv4 packets. Operation of the MPLS VPN control plane is shown in Figure below. The Figure shows a simple VPN implementation with two sites belonging to Customer A connected to one another across a service provider's MPLS backbone. JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 69 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN Figure 40: Control Plane Operation The following are the steps for control plane operation in MPLS VPN. The steps are outlined for prefixes advertised by the CEA-1 router and are shown in the Figure: Step 1. IPv4 update for network 172.16.10.0 is received by the egress PE router (data plane). Step 2. PE1-AS1 accepts and transforms the IPv4 route, 172.16.10.0/24, to a VPNv4 route by assigning an RD 1:100, SoO, and RT 1:100 based on the VRF configuration on PE1-AS1. It then allocates a VPNv4 label V1 to the 172.16.10.0/24 update and rewrites the next-hop attribute to the PE1-AS1 loopback0 IP address 10.10.10.101. PE1-AS1 loopback 10.10.10.101 is reachable via IGP (OSPF) and LDP. Figure shows the control plane operation and the label propagation for prefix 10.10.10.101/32 from PE1-AS1 to PE2- AS1 inside the provider network. This propagation takes place as soon as the MPLS VPN provider network is established and is always in place prior to any VPNv4 prefix being propagated across the MPLS VPN provider network. The following steps are performed in the label propagation process for prefix 10.10.10.101/32. This operation is shown for clarity: a. 2a: In Figure, Edge LSR PE2-AS1 requests a label for the 10.10.10.101/32 prefix using the LDP label mapping request from its downstream neighbor, LSR P2-AS1. P2-AS1 requests a label for the 10.10.10.101/32 prefix using the LDP label mapping request from its downstream neighbor LSR P1-AS1. P1-AS1, in turn, requests a label for the 10.10.10.101/32 prefix using the LDP label mapping request from its downstream neighbor, Edge LSR PE1-AS1. Edge LSR PE1- AS1 allocates a label of implicit-null (penultimate hop popping) to 10.10.10.101/32, modifies the entry in the LFIB corresponding to 10.10.10.101/32, and sends it to P1-AS1 using an LDP reply. b. 2b: P1-AS1 uses the implicit-null label received from PE1-AS1 as its outbound label value, allocates a label (L1) to prefix 10.10.10.101/32, and modifies the LFIB entry for 10.10.10.101/32. P1-AS1 then sends JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 70 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN this label value to P2-AS1 via an LDP reply. c. 2c: P2-AS1 uses the label (L1) received from P1-AS1 as its outbound label value, allocates a label (L2) to prefix 10.10.10.101/32, and modifies the LFIB entry for 10.10.10.101/32. P2-AS1 then sends this label value to PE2-AS1 via an LDP reply. Step 3. PE1-AS1 has the VRF configured to accept routes with RT 1:100 and therefore translates the VPNv4 update to IPv4 and inserts the route in VRF for Customer A. It then propagates this route to the CE2-A. d) MPLS VPN Data Plane Operation The prior section discussed update propagation along with the label assignment and distribution, both for MPLS packet forwarding as well as the VPN label. MPLS VPN data plane operation involves the usage of the label stack in which the top label in the label stack is the label assigned for the egress PE routers (data plane) next-hop address, and the second label in the label stack is the VPN label as assigned by the egress PE router connected to the CE router advertising the prefix. When using the label stack in an MPLS VPN implementation, the ingress/upstream PE router thus labels the incoming IP packet for a remote VPN destination with two labels. The second label in the stack points toward an outgoing interface whenever the CE router is the next hop of the VPN route. The second label in the stack points to the VRF table for aggregate VPN routes, VPN routes pointing to null interface, and routes for directly connected VPN interfaces. This will be explained in more detail in the section "MPLS VPN Basic Configuration." P routers perform label switching on the LDP-assigned label toward the egress PE router. The egress PE router identifies the VPN label assigned with a VRF (that it has previously assigned) and either forwards the IP packet toward the CE router or performs another IP lookup in the VRF table to identify the next hop toward the destination. Figure below depicts the various steps in the data plane forwarding of customer data from one customer site CE2-A to CE1-A connected using the SP's infrastructure. Figure 41: MPLS VPN Data Plane Operation JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 71 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN When data is forwarded to a specific prefix belonging to a VPN across the MPLS-enabled core, the top label in the label stack is the only one swapped as the packet traverses the backbone. The VPN label is kept intact and is removed only in the egress/downstream PE router. The resulting prefix is associated with an outgoing interface belonging to a specific VRF on the router depending on the value in the VPN label. Here are the steps in the data plane forwarding shown in Figure above: Step 1. CE2-A originates a data packet with the source address of 172.16.20.1 and destination of 172.16.10.1. Step 2. PE2-AS1 receives the data packet and appends the VPN label V1 and LDP label L2 and forwards the packet to P2-AS1. Step 3. P2-AS1 receives the data packet destined to 172.16.10.1 and swaps LDP label L2 with L1. Step 4. P1-AS1 receives the data packet destined to 172.16.10.1 and pops the top label because it receives an implicit-null label mapping for 10.10.10.101/32 from PE1-AS1. The resulting labeled packet (with VPN Label V1) is forwarded to PE1-AS1. Step 5. PE1-AS1 pops the VPN label and forwards the data packet to CE1-A where the 172.16.10.0 network is located. The key to understanding the operation of MPLS VPN is that the VPN label is never touched until it reaches the egress PE router toward the FEC. All the forwarding of traffic is done as explained; the next-hop label mapping to the downstream PE router's loopback is used to forward the packet (in this case, labeled IP because of the presence of a VPN label) through the MPLS domain. 5.7 Conclusion MPLS L3VPN is a type of PE-based L3VPN technology for service provider VPN solutions. It uses BGP to advertise VPN routes and uses MPLS to forward VPN packets on service provider backbones. MPLS L3VPN provides flexible networking modes, excellent scalability, and convenient support for MPLS QoS and MPLS TE. MPLS VPN is a family of methods for using multiprotocol label switching (MPLS) to create virtual private networks (VPNs). MPLS VPN is a flexible method to transport and route several types of network traffic using an MPLS backbone. MPLS L3VPN is a technology where the traffic is carried over pseudowires (PW) over MPLS Label Switch Paths (LSPs) tunnels. The forwarding is L3-based. The infrastructure comprises routers that are MPLS-capable. Such a network can provide connectivity service to subscribers, in a similar manner to the way CEN provides Ethernet services. JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 72 of 174 For Restricted Circulation JTO Phase II Data Network & IT MPLS Based Layer-3 VPN These L3 services are non-standard, and there is currently no standards development organization that is attempting to create standards for such services. In contrast to L3VPN, Ethernet services are built on the concept of Ethernet based forwarding, hence can be referred to as L2VPN. When we consider L3VPN Vs. L2VPN the following comparison can be made. JTO Phase II (DNIT) Version 1.0 Aug 2021 Page 73 of 174 For Restricted Circulation