Kingston University London

Transcription

1 Kingston University London Thesis Title Implementation and performance evaluation of WAN services over MPLS Layer-3 VPN Dissertation submitted for the Degree of Master of Science in Networking and Data Communications Networking and Data Communications By KONSTANTINOS GEORGAKAKOS SUPERVISOR ANDREAS PAPADAKIS KINGSTON UNIVERSITY, SCHOOL OF COMPUTING AND INFORMATION SYSTEMS ΤEI OF PIRAEUS, DEPARTMENTS OF ELECTRONICS AND AUTOMATION JANUARY 2012

2 Contents Pages Abstract Introduction Objectives Research Methods MPLS VPN Overlay VPN Model Peer VPN Model Layer 3 VPNs VPN Routing and Forwarding Tables (VRFs) Routing Distribution with the use of BGP VPN-IPv4 Addresses and Route Distinguisher (RD) RTs Route Propagation in an MPLS VPN Package Forwarding in an MPLS VPN Conclusion Label Distribution Protocols with IGP Label Distribution Protocol (LDP) Finding LSRs that run LDP (LDP Discovery) LDP and IGP Synchronization Simulation Scenario Simulation program which is going to be used Technology for the scenario implementation Network Topology Scenario Implementation Scenario Results Customer A Customer B ISP ISP MPLS Backbone Change of IGP in the ISP MPLS Backbone ~ 1 ~

3 4.7. Conclusions for the simulation scenario Conclusions References ~ 2 ~

4 Abstract In the mid 90's has come the rapid spread of the Internet. Prior to the Internet the traditional way of routing, storing and forwarding was serving satisfactorily the classic applications of IP (ftp, telnet, mail). Followingly, the desire for the use of IP protocol for others applications which are more demanding (video, audio, videoconference) brought to surface the deficiencies of the traditional way of routing. Now there is a requirement for the provision of differential services and guarantees for the applications. A new technology called Multi Protocol Label Switching (MPLS) changes the data. [1] 1. Introduction The MPLS technology is developed by IETF, in order to improve the flexibility and performance of the traditional IP and also to provide new services on the Internet. To MPLS combines the transfer with the label and the traditional routing with IP. This technique uses generally, 'labels' which are created and placed during importation of packets in Network Switching / Core for their promotion to the final destination. The labels indicate both the routing of packets as well as the quality characteristics of the services provided by the network. The main components of MPLS technology are as follows [1] [2]: Label: Is the title / label used by the LSR (Label Switch Router) for the packet forwarding. The LSRs only read the tags of this type, not headings of IP packets. The labels are meaningful only at local level that is to say, only between two devices which communicate. Label Switch Router (LSR): It is the backbone of the network which transfers packets equipped with the appropriate label in accordance to the budgeted tables. Edge Label Switch Router (Edge LSR): This is the device that is placed on the edge of the main network, which performs the initial processing and classification of each packet and assigns to the packet the first label. Label Switched Path (LSP): It is the "path" defined by the labels created and assigned to each packet, between the endpoints of the network. An LSP can be specified either statically or dynamically. The last one is determined automatically using routing information. Static LSPs are used rarely. ~ 3 ~

5 Label Distribution Protocol (LDP): This is the protocol having as a role the attribution of labels to packages as well as the translation of information from the LSRs. It confers labels to packets from the network devices at the edges and the core of the network in order to define the necessary LSPs. The label attribution is performed in conjunction with some routing protocols such as Interior Gateway Protocol IGP: Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP) or Exterior Gateway Protocol (EGP): Border Gateway Protocol (BGP). The Network Layer Virtual Private Networks which are based on the MPLS technology (MPLS Layer 3 VPNs) allow the creation of VPNs by using MPLS backbone network of the Internet Service Provider (ISP). The VPNs are on IP-level and therefore the information transfer is achieved by using exclusively the IP protocol. Three different types of routers are found in MPLS VPNs [3] [4]: 1. Routers CE (customer edge): Routers which are managed by the client and they usually belong to him. 2. Routers PE (provider edge): Routers which form the entry and exit points of VPNs. They belong to the ISP administratively. They are the most important part of the MPLS VPNs "logic". 3. Routers P (provider): Routers that form the backbone of the ISP and they belong to the ISP administratively. They are not involved in VPN logic their main purpose is to transfer the MPLS label to the PE routers. The following figure 1 depicts a typical MPLS VPN deployment: Figure 1: A common example of MPLS VPN [3] ~ 4 ~

6 As shown in the figure above, the network provider (Service Provider backbone) consists of routers of P and PE type. Four sites are connected to the provider's backbone network, two of them belong to VPN1 and two other sites are owned by the VPN2 (where a site can be a local network Ethernet). PE routers are the ones that share the routing information of different VPNs and update the routing tables belonging to each VPN. PE routers carry such information to each other by using the protocol BGP (Border Gateway Protocol). Generally, BGP is a reliable and efficient protocol and the exclusive protocol for exchanging routing tables between providers. It provides great flexibility since it allows or prohibits with various mechanisms to exchange partial or full the routing table, or selects between different routes which will be the principal and what secondary one (backup). The P routers do not participate in the routing VPNs.They are only involved in the exchange of labels in order to create MPLS LSPs between the routers. These LSPs are used by PEs in order to carry traffic between "members" of VPNs. The MPLS packets contain 2 labels - one for the routing of the packet between the nodes of the provider and a second one for the identification of a VPN. The BGP is the protocol of choice for the information routing transfer in the implementation of MPLS VPNs. With the usage of BGP, PE routers «know» the routing tables of different VPNs which are linked to other PE routers. For example, if part 1 (let's call site 1) of a company network is connected to the ISP router PE1 while Annex 2 of the same company, connects to PE2 through BGP, as a result PE1 knows that PE2 is connected to site 2 and respectively PE2 knows that PE1 is connected to site 1. Thus the company (and apparently its annexes) is IP connected through provider s public network provider's MPLS [4]. It is also clear that more than one customer are connected to each PE router. Thus, each PE router maintains a sub-table which contains routing information exclusively for a specific customer. This provides maximum security, because the routing table is owned only by a particular customer. In other words, each PE is like a group of virtual routers. Each routing table refers to a different customer and constitutes an ~ 5 ~

7 independent virtual routing table called VRF (Virtual Routing & Forwarding Instance). It is important to emphasize in conclusion that the company subnet created through the MPLS network of the ISP is a network which, although it is based on a public network the MPLS, is in essence a private and isolated network data. The connection Mbps speed of different customers depends on the speed of the connection via CE & PE Objectives Our project s aim will be to focus on the following points; a) To design and implement a VPN based on Level 3 MPLS and demonstrate the collaboration of the individual involved technologies. There was a first discussion on the topology with the supervisor and concluded that the topology will be generally consisted of 3 PE routers which give access to clients in the IP CORE of ISP, 3 P routers that will be connected together in full mesh and CE routers which will be 2 for the customer A which consists of 2 sites Head Quarter and the Branch office, each site wants to advertise to the other two subnets and request from the Internet Service Provider (ISP) the communication between them to be implemented with the Point to Point Layer 3 VPN and 4 CEs Routers for customer B, which consists of 3 sites, the central Head Quarter (2 CEs) and 2 Branch Offices (1 CE Router each), in the Head Quarter and in the first remote site there is one subnet with web servers which should be advertised to the customer's network as well as to the internet. In the second remote site is advertised a subnet in which users found in it should have access to the web server of the company as well as to the internet through NAT for safety reasons but also in order to save address range. The client for the communication between those sites requires the ISP to use the Hub and Spoke topology, with the Hub, the Head Quarter and as Spoke the 2 remote sites. Finally for access to the internet we use another router assuming that is a remote ISP. The above topology has been designed using a PC-based simulation environment but is also adequately elaborated in order to fully demonstrate the provision of the VPN services and allow us to perform useful evaluation. Malfunctions may occur during the simulation implementation such as: Inefficiency of the simulation ~ 6 ~

8 environment, inability (of our pc-based environment) to perform the test. Due to the limitations in the scenarios (mainly the low traffic we can achieve with the available technical means) that will be performed, we expect that there will be difficult to demonstrate clear benefits of one solution or another. b) To investigate and select the appropriate tool/ framework for performing the simulations c) To define comparative scenarios in order to evaluate the performance of the MPLS VPN. d) The difference in how quickly an MPLS network can recover, after the shutdown of a Link in the MPLS Backbone of our scenario, by using different Interior Gateway Protocols (IGPs) in the MPLS Core. e) The advantages of L3 MPLS VPN compared to other IP VPN. The reason we chose this particular project is because MPLS VPN technology is now widely used in almost all ISPs, ensuring compatibility with the IP protocol and other effectively providing demanding applications (video, audio, videoconference), since the traditional way of routing brought on surface its deficiencies. I estimate that the MPLS will have significant impact on the provision of VPN services in the forthcoming years and that in this phase extensive simulation and evaluation of its potential benefits are needed. Another reason is that I work in a company (provider) which provides services using Layer 3 MPLS VPN, so it is quite interesting and important to me to deal with this issue and enrich my knowledge Research Methods Research will be based on literature study of journal articles, periodicals and web publications. Furthermore, presentations from big Vendors like Cisco, possible users, forum, companies that are involved, provide or use products, researchers etc. An important piece of work will involve the practical application, which will be implemented with the use of the simulation framework, indicatively the Graphical Network Simulator - GNS3 to which we can load real Cisco IOS and simulate the IP Core of an ISP which consists of P and PE Routers also there are going to be two clients asking for specific services for their site. ~ 7 ~

9 2. MPLS VPN The BGP / MPLS IP VPNs, known as MPLS L3 VPNs or L3VPN, are one of the most widespread applications of MPLS networks. Speaking of MPLS is not the TE or FRR (Fast Reroute) that come straight to mind, but the VPNs. The L3VPNs is the main and often the only reason for a service provider to implement an MPLS network. The VPNs were existing before the MPLS. The L3VPNs success lies in the simplicity and extensibility provided by the combination of BGP and MPLS in the various VPN scenarios. The L3VPNs have been extended to the L2VPNs and VPLS. The BGP / MPLS VPNs are based on VPN Peer Model, which will be presented below. The main cause of this association is because the VPNs that are based on PE routers (Provider Edge Router), such as VPN Peer Model, are easy to routing for its customers and also easy to adding new VPN sites. The first publication of BGP / MPLS VPN model has been informally in RFC 2547, to which a VPN solution from Cisco was presented. Then a working group in IETF was launched which is called ppvpn (Provider-Provisioned VPNs). The working group then was divided in L2VPN and L3VPN groups. [6] [7] 2.1. Overlay VPN Model In the Overlay VPN model the service provider offers point-to-point links between routers of different areas. The point-to-point connections could be Frame Relay or ATM (Asynchronous Transfer Mode) circuit, leased lines, IP-over-IP Tunnels such as the GRE (Generic Route Encapsulation / Figure 2). This leads to a virtual backbone for the network of customers, which is above the network structure of the provider. This way the neighborhood relations are designed between routers of different customer areas (CE Routers, Customer Edge Routers), in order to exchange routing information and allow communication between different areas. In this way neighborhood relations are not created between customer routers (CE Routers) and the service provider (PE Routers). So the paths of CE Routers do not appear to PE Routers. In Figure 1 is shown an Overlay Model with GRE Tunnels. [4] [6] [7] ~ 8 ~

10 The VPN service in the Overlay model is provided by CE Routers. A VPN whose control and decisions are provided by CE Routers is called CE-Based VPN. So in essence the customers design and run their own VPN, something for which may not have the will and capacity. Thus, each provider may assume the management of the customer s virtual backbone and so ends up managing a large amount of CE routers. This is certainly not desirable from administrative point of view. Regardless of who manages the CE routers, a model which puts the control in customers' appliances has limitations. Consider a scenario where there are several client areas and all routers are virtually connected together. In any such case the number of equal relationships between routers is high. This can cause problems in the IGP (Interior Gateway Protocol), because of large routing information which should be exchanged in case of a change. Another restriction relates to the large number of arrangements to be made in case of introduction of a new area in VPN. Figure 2 Overlay VPN Model (Overlay Model on GRE Tunnels) The overlay model achieves its main goals for the creation of a VPN. It provides communication between different client areas allows the existence of private addresses and ensures the safety of traffic between areas of the VPN. Certainly, the administrative cost is quite large where it is necessary to manage large number of routers and settings in case of a change. ~ 9 ~

11 2.2. Peer VPN Model The Peer Model attempts to overcome the drawbacks of the Overlay Model. There is no need to directly exchange routing information between routers of customers. The neighborhood relationships which are developed relate to the directly connected routers. Thus a CE Router installs a neighboring relationship with the directly connected PE Router. The full central connectivity (especially of virtual connections) which was in the Overlay Model is disproved. By the side of the service provider the routing is easy. The management of the routing information distribution moves to the provider s side and generally the functionality is assigned the PE Routers. [4] [6] The introduction of a new site in a VPN requires adjustments to the PE Router and CE Router of the new area and not to all CE Routers customer. Furthermore, if an increase in the bandwidth between some areas is required, this could be achieved with the connection of PE and CE Router and does not need upgrading of several circuits or leased lines. Figure 3 presents a Peer Model VPN scenario, in which the PE routers have now the control. Figure 3 Peer VPN Model The Peer Model technique therefore is a more appropriate solution, provided that guarantees the connectivity and security required in a VPN figure. The traffic must flow between regions of a single VPN and be prohibited between different VPNs, So we need to introduce some restrictions on the movement. This can be achieved either by introducing some restrictions on the movement at the time of promotion, ie, by ~ 10 ~

12 using access lists on links between CE and PE, or introducing restrictions on the distribution of routing information. One of the original Peer Model VPN solutions used to guarantee the security of information between different VPN sites is through the use of access lists. The access lists act on IP packets at the moment of promotion, by permitting or not the move based on criteria such as source address and destination. The solution based on the access lists based, however, soon became difficult to manage. The result was an attempt to free the access lists and the discovery of a technique that would guarantee that the traffic arriving to PE Routers would be destined for a particular VPN. This goal can be achieved by connecting each area s VPN to its exclusive physical or virtual PE router. Yet, someone must guarantee that there will be a routing state, which will allow traffic between PE routers of different VPNs. As a consequence of this thought, another Peer Model VPN solution has been developed which was based on criteria of routing information distribution and specifically based on BGP Communities. In this model, the PE routers receive and install routes belonging to specific VPNs that they serve. This model is the background for BGP / MPLS-based VPNs 2.3. Layer 3 VPNs In order to achieve the implementation of a Layer 3 MPLS VPN certain basic elements are required to PE routers. These are the following: VPN Routing and Forwarding Tables (VRFs) Distribution of routes by using the BGP Route Distinguisher (RD) Route Target (RT) Forward of labeled packets VPN Routing and Forwarding Tables (VRFs) The isolation of traffic between different VPNs implies that a customer of a VPN should not be able to send information to another VPN. In the scenario of Figure 4 there are two customer VPNs, the VPN RED and VPN BLUE. [9] ~ 11 ~

13 Figure 4 MPLS Network with two VPNs Each PE router is connected to areas of both VPNs. Assuming that there is a routing / promotion table on each PE Router, then there is a problem in the case of overlapping private addresses between two VPNs (as in the case of CE2 and CE4). Moreover, one problem still exists also, in case that there is not overlap. So if there is overlap between the two VPN addresses, then it cannot be installed the promotion information for both VPNs, because it would be difficult to separate the two destinations. In any other case that there is not overlap, it is possible for a station in the VPN RED to send certain information to the VPN BLUE, simply by sending IP traffic destined to BLUE VPN. Thereby when the PE Router views a packet with destination address the VPN BLUE, it just forwards the packet. Both the above problems can be solved if each client area is connected to its own physical or virtual PE Router. However the increase in the number of PE routers for each new customer in the network does not favor the scalability neither the management of the network. Therefore a more efficient way is to use routing / promotion tables per VPN (per- VPN routing and forwarding tables VRFs), in order to maintain individually the routing and promotion information for each VPN. Those tables coexist with the general routing table, which is used for packet traffic except VPNs, and include routes for local and remote clients. [1] [4] [9] When an IP packet arrives from a client area, a PE Router must be aware of which VRF to use. This can be achieved if we associate each interface to a VRF through configuration to PE routers. The interface in this situation is not necessarily physical ~ 12 ~

14 interface. It could be a reasonable interface such as an ATM VPI / VCI or a Frame Relay DLCI (Data Link Connection Identifier). When an IP packet reaches a PE router which is not associated with any VRF, then the search is performed in the general routing table. Figure 5 shows a PE router interconnection and settings that have been made in order to be associated to a VRF table named cust-one. Figure 5: Setting the table for a VRF interconnection Use of multiple promotion tables to PE routers is a prerequisite for the existence of similar private addresses between different VPNs. Nevertheless, the existence of several promotion tables does not directly guarantee that traffic can be forwarded from one VPN to another. If in the scenario of Figure 3, the promotion table of VPN RED somehow contains information for VPN BLUE destinations, then nothing can prevent the promotion of information from the VPN RED to the VPN BLUE. Eventually, it is necessary the control of information installed in each VPN. This is accomplished by distributing routing information based on criteria, so that potential destinations of customer sites being advertised only there, where they should be Routing Distribution with the use of BGP In order to accomplish restricted distribution of routing information, the VPN routes have to be transported through a routing protocol to the SP and limit the distribution of destination information in the PE Routers. This is also the method used in BGP / MPLS VPNs, where BGP is the protocol that transfers the VPN routes. Some of the properties which make BGP ideal for VPN scenarios are: [9] ~ 13 ~

15 It supports filtration of routes by using the community feature. So it might make limited distribution of routing information. It has the ability to carry a large number of routes, and thus can transfer tracks from several customers. It can exchange information between routers, which are not directly connected. Consequently, the exchange of routing information can be made between PE Routers. It is competent to carry labels in accordance with the routes. It can operate between the marginal devices of a service provider VPN-IPv4 Addresses and Route Distinguisher (RD) As stated above, the BGP has several properties which make it tempting for the transfer of VPN routes in the network of service provider. However, all it does is to install and distribute a route for a network prefix which however can cause problems for private VPN addresses that may be overlapped between the VPNs. [4] [9] The solution is to make a private address unique. The uniqueness of a private address is achieved through the RD (route distinguisher). The main purpose is each network prefix from each customer to receive a unique identification (RD), to stand out themselves from other customer prefixes. The result is a new prefix, which is a combination of IPv4 prefix and RD, and is called VPN-IPv4 prefix. The BGP has to transfer the VPN-IPv4 prefixes among routers. The RD is a 64 bit field, which is utilized to make the VRF prefixes unique when BGP carries them. Certainly, the RD will not indicate the VRF table that owns the prefix. This function is not like VPN identifier, because in some more sophisticated VPN scenarios may not be enough only one RD per VPN. Each VRF table in a PE router must have an RD related to it. This field of 64 bit may have two forms: ASN: nn or IP-Address: nn, where nn is a number. The most common form is the ASN: nn, where ASN is the autonomous system number. Typically service providers use ASN: nn, where the autonomous system number has been assigned by the Internet Assigned Numbers Authority (IANA) and nn is the unique number allocated to the VRF. ~ 14 ~

16 The combination of RD and IPv4 prefix which is the VPN-IPv4 prefix has length 96 bit. For example, if the RD identifier for IPv4 prefix /24 is 1:1, then the VPN-IPv4 prefix is 1:1: / 24. When an area is connected to two PE routers then the routes from the VPN region may have two different RDs, depending on how PE Router obtains the routes. Each IPv4 route can take two different RDs, so there can be two completely different VPN-IPv4 routes. This enables BGP to consider them as two different routes and apply different policies to each one RTs The RD, therefore, are used to separate the VPNs. However it is possible to be required communication between different VPN areas. An A customer region would not be able to communicate with a of client B region because their RDs would not fit. The communication function of specific different VPN areas is called extranet VPN. On the contrary, intranet VPN is called the simple communication between regions of a single VPN. Communication between different VPN areas is monitored by another term, the RTs. [4] [9] [15] An RT (Route Target) is an extended community of BGP, which indicates which routes should be entered from the BGP to VRF table. Exporting a RT (RT Export) means that the outgoing VPN-IPv4 prefixes receive an additional BGP extended community when they are distributed with BGP (the RT, which is set in the PE Router). The introduction of an RT (RT Export) means that the incoming VPN-IPv4 prefixes from the BGP are checked if they match to an extended community (the RT, which is set in the PE Router). If there is match, the prefix is placed in the VRF table, if not the prefix is discarded. Figure 6 shows the RTs control of routes imported in VRF tables from the remote PE Routers and with which RTs VPN-IPv4 prefixes are exported. ~ 15 ~

17 Figure 6 Import and export of RT 1 Obviously, with regard to the scenario depicted in figure 8, the regions A and B of the VPN BLUE are able to communicate, as well as areas A and B of the VPN RED. The RT used by the VPN BLUE is 1:1, while the VPN RED uses the RT 1:2. In the event of region A being the only one from VPN BLUE which wants to contact the area A and is the only one from VPN RED, it can be adjusted to fit RTs VRF tables and PE1 PE2 respectively. As a result, the RT 100:1 can be imported and exported from areas A of the VRF RED and BLUE in order to accomplish the communication of specific areas of both VPNs. So this is called extranet. Figure 7 shows the settings for VRFs of routers PE1 and PE2. Figure 7: Settings for VRF tables in routers PE1 and PE2 ~ 16 ~

18 Figure 8: Import and export of RT Route Propagation in an MPLS VPN The VRF tables divide routes of customers to PE routers. The BGP seems to be the ideal routing protocol to transmit all these tracks (possibly hundreds or thousands). The addition of RD in the IPv4 routes, namely the creation of VPN-IPv4 prefixes, contributes to the safe transportation of routes through the MPLS VPN network. [7] [8] [9] With the use of an Interior Gateway Protocol (IGP) the PE Router receives IPv4 routes from a CE Router, these routes are placed in the VRF routing table. The VRF table being used for a particular VPN region depends on the settings made on the PE Router (i.e. under which VRF table is set the interface that connects to the specific VPN area). In a VRF table routes is added the RD that is configured for this board in order to form the VPN-IPv4, which are advertised with BGP to other PE routers of the MPLS VPN network. From the PE routers the RD is removed from the VPN- IPv4 prefixes and the IPv4 routes now are placed in the VRF table. Certainly the introduction to the VRF tables depends on the imported RTs. Then the IPv4 routes are advertised to CE Routers with an IGP protocol. The entire process is shown in Figure 9: 1. IGP advertises customer s IPv4 Routes from CE to PE Router. 2. IPv4 customer s Routes are inserted into the VRF Routing Table of PE Router. ~ 17 ~

19 3. IPv4 customer s Routes are redistributed into BGP, RD is added to the IPv4 Routes to make it VPN-IPv4 Routes, RTs are added too. 4. BGP advertises customer s VPN-IPv4 routes with MPLS Label and RTs. 5. RTs indicate to which VRF the routes are imported and RD is removed from VPN-IPv4 routes. 6. IPv4 customer routes are inserted into the VRF routing table. 7. IGP advertises customer s IPv4 Route from PE to CE Router. Figure 9: Proliferation of IPv4 routes in a MPLS network Package Forwarding in an MPLS VPN The packet forwarding in the MPLS VPN is based on the labels. The P Routers (Provider's Routers / intermediate LSRs) require only the appropriate information for the replacement of labels to forward packets. The usual way is to configure the LDP between intermediate LSRs and PE routers in order to be that traffic be based on the labels. It can certainly be used the RSVP with TE Extensions for an implementation of MPLS VPN with TE, but the most common label distribution protocol for MPLS VPN is the LDP. Packets are forwarded to the MPLS core network with a label that defines the LSP from the ingress and egress (Provider Edge) PE router. Each ~ 18 ~

20 intermediate LSR should never have to do some search for the network address. That is how is carried out the transfer of packets from the ingress PE Router to the egress PE. The above label carried by the packages, is called IGP label. [4] [6] [8] The manner in which the egress PE router understands to which VRF the package belongs is not in the IP packet header neither in the results from the IGP label but what needs to be done is to add another label to MPLS label stack, this label determines which VRF table owns the package. So every customer s package is forwarded with two different labels, the IGP label on top and the VPN label at the base of the stack. The VPN label must be imported from the ingress PE so the egress PE is able to match the package with a VRF table. The manner, in which the egress PE router informs the ingress PE for the VPN label to be used for a particular VRF prefix, has already been discussed. The reason is that the existing BGP advertises VPN-IPv4 prefixes, and also advertises a label (VPN label or the label BGP) associated with a particular VPN-IPv4 prefix. Summing up, in the traffic between VRF, two labels are added to each packet in the MPLS Network. At the top is the IGP label which is distributed from node to node with the LDP or RSVP TE among all the PE and P routers. The label at the base of the stack is the VPN or BGP label which is distributed with BGP from one PE to another. The top label (IGP label) is used by the P routers in order to forward the packet to the suitable PE router (egress Router). The egress PE routers use the bottom label (VPN label) to forward an IP packet to the appropriate CE router Conclusion The subject of chapter was the MPLS VPN which is one of the most important applications of MPLS. In order to achieve the implementation of a Layer 3 MPLS VPN, some basic information to PE routers are required. These are: VPN Routing and Forwarding Tables (VRFs), distribution of routes with the use of BGP, Route Distinguisher (RD), Route Targets (RT) and the promotion of labeled packets. All of the packets in the MPLS VPN network are forwarded with two different labels, the IGP label and the VPN label at the top and the base of the stack respectively. ~ 19 ~

21 3. Label Distribution Protocols with IGP Suppose one simple IP network which integrates MPLS (IP over MPLS). This specific network consists of LSRs that run an IGP (e.g. OSPF, IS-IS, EIGRP). While entering a packet in the network, the ingress LSR seeks for the destination address in the packet, adds a label and forwards the packet. The following LSR and each intermediary LSR receives the marked packet, replaces the incoming label using an outgoing and promotes the package. The egress LSR in turn removes the label of the packet and forwards it in accordance with IP address. To perform this process, the neighboring LSRs must agree on what label will be used for each IGP prefix, meaning with which outgoing label will be replaced every incoming one. Hence, a mechanism guiding the LSRs decision is needed about the required function, they have to execute on the marked packets. This mechanism is the distribution label protocol. As mentioned above there are two ways of a distribution label protocol implementation: [1] [4] [9] Integration of the distribution function to an existing routing protocol Usage of a separate protocol for the distribution of labels As it regards the first case, an IGP (Interior Gateway Protocol) has not been converted in order to support the distribution of labels. On the contrary, BGP is one routing protocol which can simultaneously carry prefixes and distribute labels. The BGP is mainly used for the distribution of labels in MPLS VPN. In the second case, which is more concerned, there are protocols such as LDP, CR-LDP and RSVP. These protocols run simultaneously and cooperate with some routing protocol. 3.1 Label Distribution Protocol (LDP) The LDP is used to distribute labels matched with the FEC according to specific s LSRs requirements (on demand) or are simply distributed when new routes become known. The aim of the distributing label is the matching with one FEC. Two LSRs which exchange such mappings are called LDP Peers and LDP Session is called this session for those two, which takes place in both directions. [4] [9] There are four types of messages in the LDP: ~ 20 ~

22 Discovery messages, messages which communicate and maintain the presence of an LSR in the network Session messages, messages for establishing, maintenance and termination of sessions between LDP peers Advertisement messages, messages for the creation, change and deletion of matches between labels and FECs. Notification messages, messages which provide error directions and information Finding LSRs that run LDP (LDP Discovery) The LSRs, which run the LDP, send LDP Hello messages from all interfaces where LDP is enabled. The Hello messages are UDP messages which are sent to all routers of the subnet (multicast/all routers on this subnet), namely with IP address The UDP door used for the LDP is 646. [4] [9] [15] When an LSR receives a Hello message in a specific interface, then it concludes that on the other side of the connection is located another LSR which runs the LDP. Thus two LSRs involved in the connection, install a LDP neighborhood relation between them (LDP adjacency). The Hello message contains one reverse time mechanism, which is called Holdtime. If a Hello message is not received before the Holdtime expire, the LSR maintaining the Holdtime deletes the other LSR from the list of LDP neighbors. The default value of the Holdtime variable for Hello messages is 15 seconds, while every 5 seconds the LSRs send Hello messages from their LDP interfaces. If two LDP peers have different values for the Holdtime variables, then the lowest of them is chosen for this specific session. Also LSRs, to which the LDP has been activated, have an ID LDP (LDP Identifier) or LDP ID. The LDP ID is advertised through the Hello messages. The ID consists of 6 byte, of which the 4 byte uniquely identify each LSR and the other 2 byte indicate the type of the label performance, that is to say if labels are assigned per unit (perplatform) or per interface (per-interface). So if the two latest bytes are 0 then the space between labels shall be per-platform, while if it is different than 0 shall be per ~ 21 ~

23 interface. In the last case multiple LDP IDs could be used from an LSR for different LDP sessions, of which the first 4 bytes are identical and the two latest indicate the different space of labels. As far as about the first 4 byte of the LDP ID, they are usually the IP address of an active interface. Certainly if there are configured loopback interfaces then this with the largest IP address is selected as LDP ID LDP and IGP Synchronization One problem which may occur in MPLS networks is the non-simultaneous synchronization of LDP and the IGP of the network. The synchronization here means that the promotion of a package from an interface will occur only if the LDP and the IGP comply that this is the interface that should be used. A common problem in MPLS networks running the LDP is that if an LDP session fails on a link, the IGP does not cease to see this connection as the best route to the routing table, of which continues forwarding packets for some prefixes. Thus the marked packages which would be promoted through this connection will now be promoted without a label. In the most frequent situation where the network is a simple IPv4 over MPLS there is not a significant problem, because the LSRs know how to forward packets on the basis of their IP address. Therefore the label is removed until they are traced again to a next LSR. However in cases such as MPLS VPN LSRs which do not have the knowledge to promote their packets, so as a result they are rejected (Figure 10). [4] [9] Figure 10: Rejection of the packet because of non LDP and IGP synchronization ~ 22 ~

24 In the case of MPLS VPN packets are based on IP, however they must be promoted in accordance with the VRF Table. However, the VRF table is personal for each client and only occurs in marginal LSRs. So if the label of the packets is removed within the MPLS network, they will be rejected. Generally, if the LDP session is down, while the IGP adjacency is up between two LSRs, considerable problems can arise and several packets could be lost. A similar problem is likely to occur in a LSRs reboot. The IGP installs faster relations with the neighbor devices than the LDP the sessions, implying that the IGP promotion occurs before the LFIB table gather the information required to forwarding, based on the label. The solution therefore to the above problem is to synchronize the LDP and IGP, that is to say the guarantee that there will be no promotion of the non-labeled information when the LDP session is down for a connection and will also be made the promotion of another link where the establishment of the LDP session has taken place. The problem of synchronization does not take place in the case of BGP, because the BGP itself arranges the distribution of assignments too. So BGP whether it is active or not, has no synchronization problem, since the prefix installation in the routing table is directly related to the assignment of a label for this prefix. When the LDP and IGP synchronization technique is enabled for an interface, the IGP advertises this link with a maximum metric until synchronization is achieved or until the LDP session is activated in this connection. One of the IGP protocols to which the LDP and IGP synchronization technique is carried out is the OSPF. The maximum metric for OSPF is (hex 0xFFFF). Therefore no route through this interface, where the LDP is inactive, is used unless it is the only route (no other routes with better metric). When the LDP session is finally installed and matches have been distributed, the IGP advertises the link with its actual metric. [4] [16] ~ 23 ~

25 4. Simulation Scenario The virtual scenario which will be simulated basically deals with 2 clients who require from an ISP certain services, in more details: Customer A: The client A consists of 2 sites the Head Quarter and the Branch office (remote site), each site wants to advertise to the other two subnets (Branch office: /24 & and Head Quarter: /20 & /24). The client since he has two sites, request from the Internet Service Provider (ISP) the communication between them to be implemented with Point to Point Layer 3 VPN. Costumer B: The customer B consists of 3 sites, the central Head Quarter and 2 Branch Offices (Remote Site), in the Head Quarter and in the first remote site there is one subnet with web servers ( /24 and /24 respectively) which should be advertised to the customer's network as well as to the internet. In the second remote site is advertised a subnet ( /24) in which users found in it should have access to the web server of the company as well as to the internet through NAT (Network Address Translation) for safety reasons but also in order to save address range. The client for the communication between those sites requires the ISP to use the Hub and Spoke topology, with the Hub, the Head Quarter and as Spoke the 2 remote sites. Now, regarding the access to the internet the customer has requested be implemented via the Head Quarter, this means that this site will have 2 circuits, one for the communication with the two Remote Sites (which whether it is internet or VPN traffic, will send and receive through the Head Quarter) and 1 for access to the internet. It should be noted that in the central site for better safety and redundancy, the customer has requested to be implemented the multihomed BGP technology, that means that are used 2 Customer Edge Routers with which is implemented load sharing, more specifically, the first CE Router is the primary one for Internet traffic and backup for VPN traffic and the second CE Router is the primary for VPN traffic and backup for Internet traffic. Finally, to illustrate the internet access we assume a second ISP which will advertise 2 internet routes ( /24 & /32). ~ 24 ~

26 Figure 11: Network Topology of customers A and B 4.1. Simulation program which is going to be used The simulation program which will be used to implement the scenario is the Graphical Network Simulator 3 (GNS3). [18] GNS3 is a graphical network simulator that allows simulation of complex networks, it can also be used to experiment features of Cisco IOS or to check configurations that need to be deployed later on real routers. The reason this simulation was chosen, as explained above, is because it can simulate the functions of a real Cisco Router since it is able to load an actual IOS. The selected router model is the 2691 and the IOS c2691-adventerprisek9-mz bin, with this IOS we can implement almost any technology available. Nevertheless we could choose a newer Router model with more features such as the 3745 or 7200, but this would result in more intensive usage of computer CPU and due to this the number of the Routers should be reduced Technology for the scenario implementation In this chapter we shall refer to the technologies that will be used in the Core provider's network but also for every customer. [4] [10] ~ 25 ~

27 ISP Core: In the Provider s Core there are three P (Provider) Routers and three PE (Provider Edge) Routers, the Interior Gateway Protocol (IGP) used in order to advertise their subnets the Routers of the Core network between them (such as directly connected networks and Loopback IP addresses) is the OSPF (Open Shortest Path First). The reason this Routing Protocol was chosen is because it is able to support large demanding networks, such as a provider s network which needs fast network convergence and network scalability. Next the MPLS protocol was activated in all the Core Routers of the network, where each Router using the LDP protocol trades the Labels corresponding to each subnet and this way they make up Label Information Base (LIB) and Label Forwarding Information Base (LFIB) tables. The VRFs were activated to PE Routers (Virtual Routing and Forwarding) for each client, two for the A (Point to Point topology with Route distinguisher 1:1 and Route Target import / export 1:1) and three for customer B (Hub and Spoke topology with Route distinguisher for both remote branch offices 2:1 and 2:2, respectively and Route target import 2:1/exprt 2:2, for the central site Head Quarter was defined Route distinguisher 2:3 and Route target import 2:2 / exprt 2:1,by the way the route targets are defined to the client B, the remote branch offices will send and receive traffic whether it is VPN or Internet traffic through the central Head Quarter). Finally the Exterior Gateway Protocol (EGP) was activated more specifically the Border Gateway Protocol (BGP) to PE Routers, so as to set up the i-bgp sessions between PEs to carry the VPN traffic of customers through the Multi Protocol-BGP Protocol (MP-BGP) as well as the Internet traffic via the global BGP routing table. Customer A: Client A consists of 2 sites (a central one and a remote site) that want to advertise the one to another 2 subnets. Because the individual customer in the future intends to enlarge his domestic network (therefore and the subnets will grow) has requested from the provider to use the dynamic routing protocol EIGRP (Enhanced Interior Gateway Routing Protocol) between CE and PE Router. The EIGRP is a Cisco proprietary routing protocol that is based on IGRP, some of the advantages of which is that it has fast network converges good fault tolerance and ~ 26 ~

28 scalability as well as a function that characterizes it as unequal cost load balancing, though its main disadvantage is that it is not supported by other providers since it is a Cisco protocol. Customer B: The client B as mentioned in the previous chapter consists of three sites, 2 branch offices and one central, with Hub and Spoke topology. In the first remote site because of the need to advertise 1 subnet to the main Head Quarter site, we will use static route between CE and PE Router, in particular a default gateway to the provider and in the PE Router a static route to the subnet of the client. In the second remote site the dynamic routing protocol RIPv2 will be used for the CE and the PE Router communication so that the customer can advertise his internal network to the Head Quarter. Finally in the central site where apart from the VPN traffic to and from the remote sites, is also requested to give access to the Internet, the customer has requested to have redundancy and load balancing for safety and efficiency reasons. To implement it two CE Routers will be used, where through the EBGP routing protocol will communicate with the PE Router. Those two Routers which will advertise a default route to the remote sites, so that there is a spoke to spoke communication as well as communication with the Internet, will have two links each, one for VPN Traffic and another for Internet Traffic (meaning four different EBGP sessions). Behind them there will also be the CPE Router which will be interconnected to both CEs with IBGP sessions for redundancy reasons. The client has asked from the provider to advertise a summary address from CPE to the Internet, which would involve local subnet as well as the subnet from the first remote site so that Internet users can have access to them. In order to implement the load sharing we will use the BGP attributes, more specifically AS-Prepend for the input traffic and Local Preference for the output traffic. The way in which, this will be achieved,will have as a final result the first CE Router to be the primary one for the Internet traffic, and the second CE to be the primary one for the VPN Traffic. ~ 27 ~

29 4.3. Network Topology The following figure (figure 12) shows the network topology as well as the design of IP Addressing, from the virtual scenario that will be implemented. Figure 12: Network Topology As shown in Figure 12 for the CE and PE Routers interconnection we have used Serial Links, while for the interconnection of Routers in the MPLS Backbone of the Service Provider as well as the interconnection of the three Routers to the Head Quarter of customer B, we have used Fast Ethernet Links. In the tables below (Table 1, 2 and 3) are reported the Routers of each customer and the Internet Service Provider s Routers too. Costumer A: Routers Remote Site 1: CE_RS_A (Costumer Edge _ Remote Site _ A) Head Quarter: CE_HQ_A (Costumer Edge _ Head Quarter _ A) Table 1 Customer B: Routers Remote Site 1: CE_RS_B1 (Customer Edge _ Remote Site _ B1) Remote Site 2: CE_RS_B2 (Customer Edge _ Remote Site _ B2) Head Quarter: CE1_HQ_B (Customer Edge _ Head Quarter _ B) CE2_HQ_B (Customer Edge _ Head Quarter _ B) CPE_HQ_B (Customer Premises Equipment_Head Quarter _B) _B) Table 2 ~ 28 ~

30 ISP: Routers MPLS Backbone: PE1 (Provider Edge 1) PE2 (Provider Edge 2) PE3 (Provider Edge 3) P1 (Provider) P2 (Provider) P3 (Provider) Table Scenario Implementation In this chapter shall be reported the steps followed for the implementation of the scenario. [4] [10] [14] I. The OSPF Routing Protocol was enabled on P and PE Routers (OSPF Routing Process 1 and Area 0) of the MPLS Backbone, in this way they advertise to each other the subnets of the Core Network and the Loopback IP Addresses of each Provider Router. (Figure 13) Figure 13: Activation of the OSPF Routing Process 1 on the directly connected networks and Loopback Interface II. We activated the MPLS Protocol to the Core Routers of the Provider and the LDP protocol for the exchange of Labels. In this way the P and PE Router will create the LIB and LFIB tables. (Figure 14) ~ 29 ~

31 Figure 14: Activation of the MPLS and LDP Protocol III. The BGP Routing Protocol was enabled on the PE Routers of the Provider (Autonomous System 1) in order to create MP-IBGP Sessions between the PE Routers, for the transportation of the customers VPN Routes from PE to PE and subsequently to the customer's CE Router. (Figure 15) Figure 15: We activated the BGP and MP-IBGP to the PE Routers of the Provider IV. We have created the VRF Routing Tables for each site of every client and stated the Route Target and Route Distinguishes. (Figure 16) ~ 30 ~

32 Figure 16: VRFs for every customer (A & B) and each site. V. ISP2: We enabled an EBGP Session between PE and Router of the ISP 2, which through the BGP Routing process advertises two Internet Routes. (Figure 17) Figure 17: We enabled an EBGP Session between PE and the ISP2 Router, as well as the advertisement of 2 Internet Routes from the IPS2 VI. Remote Site of Client A: We activated the EIGRP Routing Protocol (Autonomous System 1) between the CE and PE Router and through EIGRP Routing Process the client advertises two VPN Routes. (Figure 18) ~ 31 ~

33 Figure 18: Activation of the EIGRP between CE and PE, including redistribution of VPN Routes into EIGRP and into MP-IBGP. VII. Head Quarter of customer A: EIGRP Routing Protocol was enabled (Autonomous System 2) between CE and PE Router and through EIGRP Routing Process the customer advertises two VPN Routes. (Figure 19) Figure 19: Activation of the EIGRP between CE and PE, including redistribution of VPN Routes into EIGRP and into MP-IBGP. VIII. Remote Site 1 of Customer B: On the CE Router of the customer we stated a Default Static Route to the ISP and to the PE Router we stated, through the ~ 32 ~

34 client s VRF, a Static Route towards the subnet to which the client wants to advertise. (Figure 20) Figure 20: Default Static Route of the CE Router, as well as redistribution Static and Connected Routes into MP-IBGP IX. Remote Site 2 of customer B: The RIPv2 Routing Protocol was activated between CE and PE Router and through RIPv2 Routing Process the customer advertises one VPN Routes. (Figure 21) Figure 21: Activation of RIPv2 between CE and PE including redistribution of VPN Routes into EIGRP and into MP-IBGP. X. Head Quarter of customer B: At the central site of client B the BGP Routing Protocol was activated, more specifically: ~ 33 ~

35 Two EBGP Sessions between CE1 and PE Router Two EBGP Sessions between CE2 and PE Router One IBGP Session between CE1 and CE2 Router One IBGP Session between CPE and CE1 Router One IBGP Session between CPE and CE2 Router From the CPE Router and through BGP Routing Process a Summary Address is advertised to the Internet, which includes the Local Subnet as well as the Subnet from the first Remote Site. In addition we should note that in CE1 and CE2 Routers we have used the NAT technology (Network Address Translation) in order, the private IP Addresses of users which are located in the subnet ( /24) of the second Remote Site of customer B, to be translated into public IP Addresses of the WAN Serial interface of CE1 and CE2, respectively, which are used for Internet. (Figure 22, 23 and 24) Figure 22: Activation of the BGP and NAT to the CE1 and CE2, advertisement of a Default Route from both CEs towards the Remote Sites of customer B as well as using BGP attributes (AS-Prepend and Local Preference) for the implementation of Load Sharing. ~ 34 ~

36 Figure 23: Activation of the IBGP as well as advertisement of the summary network address to the Internet. Figure 24: Activation of the EBGP between PE3 and CEs Routers, as well as advertisement of a Default Route in both CEs from the Internet Scenario Results In this chapter we shall present the results from the virtual scenario using commands such as Show IP Route (in order to see the routing tables of each router), Trace Route (in order to see the Label Switched Path), Debug (in order to check the function of several protocols such as NAT Protocol) and Extended Ping (in order to check the network availability). [3] [10] [14] Customer A We will begin with the customer A and we shall present the Routing Tables of the CEs Routers for each site and the Label Switched Path (LSP) between these two ~ 35 ~

37 sites. (Remote Site and Head Quarter). In the figure below (figure 25) we can see the Routing Tables of Routers (CE_RS_A) and (CE_HQ_A) in the Remote Site Head Quarter, respectively. Figure 25: Routing Tables of CE_RS_A and CE_HQ_A From the above Routing Tables it is obvious that the two CEs of customer A also include the directly connected networks as well as the routes from the opposite edge (External Routes). For example in the Router (CE_RS_A) the local networks are: / / /24 the External Routes (from Head Quarter) are: / / /24. Figure 26 shows the Label Switched Path between the sites of customer A, using the Trace Route command from the Router of Head Quarter (CE_HQ_A) and as a ~ 36 ~

38 Source uses the Loopback 1 (as a Source one of the two customer s LAN in this site) and with destination the LAN /24 of the Remote Site. Figure 26: Trace Route from "CE_HQ_A Loopback 1" to "CE_RS_A Loopback 1" From the figure 26 we can see that the Label Switched Path is: CE_HQ_A PE3 P3 P1 PE1 CE_RS_A We also notice that in PE3 Router are added the two Labels, the first is the IGP Label which changes from hop to hop (from 19 to 16) and is removed in the penultimate Router of the Core (P1) and remains the second Label (VPN Label 34) which then is removed from the PE1 Router and finally clear IP Packets are promoted to the customer Customer B To the customer B will be presented the Routing Tables of the CEs Routers as well as the Label Switched Path between the Sites and the Availability at the Head Quarter too. In Figure 27 we can see the Routing Tables of the two CEs Routers of both Remote Sites. ~ 37 ~

39 Figure 27: Routing Tables of CE_RS_B1 and CE_RS_B2 From the figure above we can see that in the Routing Table of the CEs exist the directly connected networks as well as the default routes for Spoke to Spoke and Internet Communication by the Head Quarter. In Figure 28 we can see the Routing Tables of the CEs Routers at the Head Quarter. Figure 28: Routing Tables of CE1_HQ_B and CE2_HQ_B ~ 38 ~

40 From the Routing Tables of figure 28 it is a fact that the CEs are aware of the networks of Head Quarter and Remotes Sites. In addition are also presented the default routes that are advertised from PE3 about the traffic towards the Internet. In Figure 29 is shown the Routing Table of CPE Router at the Head Quarter. Figure 29: Routing Table of CPE_HQ_B In the Routing Table of CPE Router (figure 29) we can see that are contained the Routes of Head Quarter, the Routes of the two Remote Sites as well as the default route which is advertised by both CEs of the central site having as primary the CE1_HQ_1 Router, for the traffic to the Internet. In Figure 32 is presented the Label Switched Path from Router CE_RS_B1 with the Loopback 1 as Source on Router CE_RS_B2 Loopback 1. ~ 39 ~

41 Figure 30: Trace Route from "CE_RS_B1 Loopback 1" to "CE_RS_B2 Loopback 1" From Figure 30 we can see that the Label Switched Path is as follows: CE_RS_B1 PE1 P1 P3 PE3 CE2_HQ_B PE3 P3 P1 PE1 CE_RS_B2 In Figure 31 we see the Label Switched Path from Router CE_RS_B2 Loopback 1 to the Internet (ISP2 Loopback 1). By using the command Ping with the same destination and the command "Debug IP NAT" in CE1_HQ_B Router, we can see the operation of NAT protocol (Figure 32) which translates the privet IP Address (Loopback of CE_RS_B2) into public (IP Address of WAN Serial Interface of Router CE1_HQ_B) as the client has requested (Chapter 5: Simulation Scenario). ~ 40 ~

42 Figure 31: Trace Route From "CE_RS_B2 Loopback 1" to "ISP2 Loopback 1" From Figure 31 we can see that the Label Switched Path is as follows: CE_RS_B2 PE1 P1 P3 PE3 CE2_HQ_B CE1_HQ_B PE3 P3 P2 PE2 ISP2 Figure 32: Ping from "CE_RS_B2 Loopback 1" to ISP2 "Loopback 1 (Internet)" and "IP NAT Debugging" from CE1_HQ_B ~ 41 ~

43 In order to check the availability at the Head Quarter site for Internet traffic, we will use an Extended Ping (200 packets figure 33) from Router CE_RS_B2 Loopback 1 to Router ISP2 Loopback 1 (Internet), and shut down the Link between the Routers CE1_HQ_B CE2_HQ_B which are located at the Head Quarter figure 33: Extended Ping from "CE_RS_B2 Loopback 1" to "ISP2 Loopback 1" (Internet) From Figure 33 we find that only 10 Packets were lost until the rerouting has been complete. According to Figure 31 and Figure 34 we can compare the Label Switched Path before and after rerouting Figure 34: Trace Route From "CE_RS_B2 Loopback 1" to "ISP2 Loopback 1" ~ 42 ~

44 From Figure 31 as shown earlier the Label Switched Path before the rerouting is as follows: CE_RS_B2 PE1 P1 P3 PE3 CE2_HQ_B CE1_HQ_B PE3 P3 P2 PE2 ISP2 After rerouting (Figure 34) the Label Switched Path is: CE_RS_B2 PE1 P1 P3 PE3 CE2_HQ_B PE3 P3 P2 PE2 ISP2 From the aforementioned results we conclude that after the shutdown of Link (CE1_HQ_B CE2_HQ_B) is used for the Internet traffic the backup Router (CE2_HQ_B). In order to check the availability at the Head Quarter site for VPN traffic, we will use an Extended Ping (200 packets figure 35) from Router CE_RS_B1 with the Loopback 1 as Source to Router CE_RS_B2 Loopback 1, and shut down the Link between the Routers CE2_HQ_B PE3 located at the Head Quarter (namely the Primary Link that is used for VPN traffic). Figure 35: Extended Ping from " CE_RS_B1 Loopback 1" to " CE_RS_B2 Loopback 1" From Figure 35 we can see that only 1 Packet was lost until the rerouting is complete. According to Figure 30 and Figure 36 we can compare the Label Switched Path before and after rerouting. ~ 43 ~

45 Figure 36: Trace Route From "CE_RS_B1 Loopback 1" to "CE_RS_B2 Loopback 1" From Figure 30, as shown earlier, the Label Switched Path before the rerouting is as follows: CE_RS_B1 PE1 P1 P3 PE3 CE2_HQ_B PE3 P3 P1 PE1 CE_RS_B2 After rerouting (Figure 36) the Label Switched Path is: CE_RS_B1 PE1 P1 P3 PE3 CE1_HQ_B PE3 P3 P1 PE1 CE_RS_B2 From the above results we infer that after the shutdown of the Link (CE2_HQ_B PE3) was used for VPN traffic the backup Router (CE1_HQ_B) ISP 2 For Internet Service Provider 2 (Internet), we will present the Routing Table as well as the Label Switched Path between ISP2 and sites of client B to which users from the Internet want access. In Figure 37 we can see Routing Table of ISP2 Router. ~ 44 ~

46 Figure 37: Routing Table of ISP2 From the Routing Table above we see that ISP2 Router incorporates the directly connected networks ( / / /32) as well as the remote routes /16 (summary route that is advertised through the BGP Routing Protocol of customer B CPE_HQ_B Router so that the Internet users have access to the local networks of the first Remote Site and Head Quarter) and / /30 (remotes routes which are advertised via BGP Routing Protocol from the Routers at the Head Quarter CE2_HQ_B and CE1_HQ_B respectively, those public routes are used for the translation of the NAT protocol, from the private IP Address of Loopback 1 of the second Remote Site, into the public IP Address). In Figure 38 we can see the Label Switched Path between the Router ISP2 with the Loopback 1 as Source and Loopback 1 of the Router CE_RS_B1 from the first Remote Site of client B. ~ 45 ~

47 Figure 38: Trace Route from Router ISP2 to CE_RS_B1 From Figure 38 we can see that the Label Switched Path is: ISP2 PE2 P2 P3 PE3 CE1_HQ_B CE2_HQ_B PE3 P3 P1 PE1 CE_RS_B ISP MPLS Backbone In this chapter we will present the Routing Table of P Routers (Providers Routers), and by the use of "show ip bgp vpnv4 vrf x" command to the Core PEs Routers we will see the VPN Routes for each VRF Routing Table of each customer (A and B). In Figure 39 is presented the Routing Table of P1 Router from the ISP MPLS Backbone. ~ 46 ~

48 Figure 39: Routing Table of P1 Router From the figure above we can see the Routing Table of P1 Router which includes the directly connected networks ( / / / /30) as well as the not directly connected networks and Loopback IP Addresses of P and PE Routers of ISP MPLS Backbone ( / / / / / / / /30) which are advertised through the OSPF dynamic Routing Protocol. It should also be noted that, as we see from the Routing Table in Figure 39 the P Routers do not need and do not know the networks of customers. In Figure 40 we can see the VPN Routes of client A for the Remote Site and for the Head Quarter which are redistributed in BGP Domain of the Core and are advertised by PE to PE Router via the MP-IBPG. Figure 40: VPN Routes of customer Α ~ 47 ~

49 In Figure 41 we can see customer's B VPN Routes of the two Remotes Sites and Head Quarter. Figure 41: VPN Routes of customer B From Figure 41 we observe that the VRF b1 and b2 has the VPN Routes of the two Remotes Sites of customer B as well as the Default Gateway from the Head Quarter. Also the VRF b which corresponds to the Head Quarter has all the VPN Routes of the Remotes Sites that are advertised by PE1 through MP-IBGP but also the Default Routes which are advertised by Routers CE1_HQ_B and CE2_HQ_B respectively through the Exterior Routing Protocol EBGP Change of IGP in the ISP MPLS Backbone As mentioned in a previous chapter the IGP that we have used in the MPLS Backbone of the ISP is the OSPF dynamic routing protocol. The MPLS may cooperate with any Routing Protocol (eg OSPF, EIGRP IS-IS) and along with it to "inherit" its features, such as fast network convergence and network scalability, etc. In this subchapter we shall present the difference in how quickly an MPLS network can recover, after the shutdown of a Link in the MPLS Backbone of our scenario, which from the start uses for IGP the OSPF, which we will then alter to EIGRP. In Figure 42 we can see the results from Extend Ping (200 packets) from PE1 to PE2 Router. ~ 48 ~

50 Figure 42: Extend Ping from PE1 to PE2 with IGP the OSPF The primary path according to the topology of MPLS Backbone (Figure 43) and the IGP OSPF is: PE1 P1 P2 PE2 Figure 43: Primary Path, from PE1 to PE2 In the case of a link from the primary path shutting down (in this case we'll shut down the link between P1 and P2 Router) the backup path is (Figure 44): PE1 P1 P3 P2 PE2 Figure 44: Backup Path, from PE1 to PE2 ~ 49 ~

51 From Figure 42 we notice that after the shutdown of the link between P1 and P2, until the network recovers and rerouting is completed three packets will be lost. Now by changing the IGP from OSPF to EIGRP in the MPLS Backbone of the ISP we will use again the Extend Ping (200 packets figure 45). Figure 45: Extend Ping from PE1 to PE2 with IGP the EIGRP From the figure above we see that by using the protocol EIGRP and by shutting down the link between P1 and P2 Router only one package will be lost. This is due to the support of the unequal cost path load balancing of the specific routing protocol that means to use both paths (primary and backup) for load balancing regardless if they have not the same cost. From the above experiment we have seen how an MPLS Backbone network "depends on" how quickly network converges it will have from the IGP routing protocols features with which it cooperates in order to create the LIB and LFIB tables Conclusions for the simulation scenario The subject of Chapter 4 was the implementation of the MPLS VPN which is one of the most significant applications of the MPLS. In order to achieve the implementation of a Layer 3 MPLS VPN, some basic information is required from the PE routers. Those are: VPN Routing and Forwarding Tables (VRFs), distribution of routes by using the BGP, Route Distinguisher (RD), Route Targets (RT), and promotion of labeled packets. All packets are forwarded with two labels: the IGP label at the top of the label stack and the VPN label on the basis of the stack. [4] Also on this point we should note that with MPLS VPN technology has simplified the implementation of the VPN service compared to other IP VPN technologies and ~ 50 ~

52 this has resulted in an easier management of customers from a service provider, such as removing or adding new customers or new VPN services (eg, Point to Point VPN, Full mesh VPN, Point to Multipoint VPN and Partial mesh VPN), since he does not need to intervene in all Network Routers of the Core but only on Edge Routers (PE Routers) and this of course makes increasingly easier the troubleshooting too. [10] [14] ~ 51 ~

53 5. Conclusions The MPLS has become popular over the last years and an increasing number of service providers apply it to their networks. One of the major advantages of the MPLS is that it provides to network operators a great number of Traffic Engineering tools. In addition it offers and ensures high quality of service data such as ATM connection technologies and Frame Relay, but without requiring devoted connections. MPLS technology has been created specifically to provide great extensibility opportunities to build VPNs resulting in giving the ability to create VPNs, which are made up of hundreds of points with reduced management costs. The MPLS VPN is one of the most popular applications of MPLS. [3] [4] [9] Similarly, the use of IP MPLS technology for the construction of enterprise VPNs provides a number of significant advantages which are required for the smooth operation of private network, given the data of current business: Security: The VPNs created by the MPLS technology provide an increased level of protection of corporate data from the risk of spyware, as traffic between points belonging to the VPN is completely isolated from the traffic of other VPNs. In order to reach the goal of isolation, the MPLS standard requires each MPLS VPN having its own routing table as well as the doors which are directly fixed to belong to it. Therefore is not possible the communication between two MPLS VPNs without the direct intervention of the provider. In conclusion we can say that IPSec VPNs have an acceptable escalation and support QoS mechanisms. If there is a need for interconnection between sites, such as in the case of the connection between remote offices and headquarters of a company, the IPSec VPNs are the best option. [12] If on the other hand, the company or the customer wants a more economic solution in order to add several regional sites, then the MPLS VPNs are what is needed, because the cost of their addition is much lower and there is no need to buy licenses. ~ 52 ~

54 The SSL VPNs provide high security for the interface between a server and a customer. They are mainly used to connect users to services and applications via networks and are widely supported by all commercial browsers. In the following table (table 4) we compare MPLS NPN, IPSec VPN and SSL VPN. [11] [12] MPLS VPN IP Sec VPN SSL VPN Based on the use of unique Route distinguisher. Provides access to Via digital User the group that Via digital certificate or preshared key Authentication uses the Service certificate and discarded any other unauthorized access Confidentiality Mechanisms of Traffic separation Encryption encryption at the through the RDs mechanisms IP network layer Escalation Acceptable. It There is no matter High. Capable of may require scalability. The supporting dozens additional network of the of thousands of planning for key ISP does not VPNs over the distribution, key know the SSL same network management traffic Equipment. It can be Not required. The Elements of the developed over network of the MPLS network of existing IP ISP does not the ISP backbone networks or the know the SSL are required. Internet. traffic QoS They support They do not They do not SLAs by support. support ~ 53 ~

55 providing QoS mechanisms, with guaranteed bandwidth Required for the VPN Client Not required. The MPLS VPN is a service implemented at the network layer, and users do not remote access of a user via IPSec VPN. (eg software Cisco VPN Client which is supported by Not required. Based on the Web Browser need VPN Clients to interact with the network operating systems such as Microsoft Windows, Solaris Linux...) Table 4: Comparison between MPLS NPN, IPSec VPN and SSL VPN Flexibility: The MPLS enables the creation of enclosed private networks whose members can be linked together by any desirable logical topology (e.g. star, partial mesh, full mesh). This makes easier the service of different business processes over the same network. For example the service of voice communication of presence points requires direct interconnectivity of a point to any else point of business. (full mesh logical topology). This is not desirable for the organization's network data which can choose star topology or partial mesh. By using MPLS VPN both solutions can coexist over a single network. The flexibility of MPLS VPN will enable the integration of future claims which may arise from the evolving and dynamic business environment, in short time and at a controlled cost. Flexible addressing scheme: Through the use of MPLS VPN it is possible to maintain the addressing scheme which has been adopted internally by significantly reducing, this way, the cost of adopting new technology. ~ 54 ~

56 Quality of Services: The MPLS technology allows the creation of level of service policy, end to end ensuring this way that the sensitive operational data of the company will have preferential treatment at all stages of their transition (edge network and backbone network). Multiple ways of access: With the use of MPLS technology is given the opportunity to organizations to create private networks by using a variety of interconnection technologies such as leased circuits, a DSL, Dialup and GPRS so as to expand their network in an efficient and effective manner. MPLS technology constitutes the historical evolution of technologies in the creation of enclosed corporate networks and therefore offers advantages compared with previous platforms implementing enterprise VPN. Generally, IP VPNs are an attractive solution because: [12] 1. They reduce the cost of connecting the offices of a company or organization, telecommunication devices and mobile users within an intranet, which operates over a public infrastructure of the internet 2. They are cheaper than public networks that use leased lines. In addition the usual types of VPN networks are very difficult to upgrade. This is because they are based on complete topologies of cryptographic tunnels or permanent virtual circuits which make the addition of new customers extremely difficult. These types of VPNs are: IPSec Layer 2 tunneling protocol (L2TP) Layer 2 forwarding protocol (L2F) Generic routing encapsulation (GRE) Frame relay ATM protocols The extra overhead that must be added in order to secure the connection-oriented services of these VPNs creates significant problems for a provider that has to support hundreds or thousands of VPNs each of which may have hundreds or even thousands of sites and thousands or tens of thousands of routes. ~ 55 ~

57 The MPLS VPNs which are level 3 protocols and non-oriented to connection are substantially more upgradeable and easier to create and be managed than the conventional VPNs. In addition, each MPLS VPN may provide services of added value, such as data storage and applications, business networks and telephone services. [12] [13] Summing up the MPLS VPNs offer: A platform for very rapid development of added value IP services such as intranets, extranets, voice, multimedia and networking companies. Privacy and security equivalent of Layer-2 VPNs by limiting the VPN routes only between those routers which are members of the VPN. Integration of customer intranets without any cut. Increased scalability so that thousands of sites can be accommodated per VPN and dozens or even thousands of VPN per provider. IP - Class of Service (CoS), support of multiple classes of services and priorities within the VPN or between the VPNs. Easy management of the members a VPN. Scalable interface of external intranets and extranets that enclose many businesses. MPLS technology is the historical development of technologies which create enclosed corporate networks and therefore offers advantages compared with previous platforms that implement corporate VPNs. In the following table (table 5) is presented the comparison of technologies for the providing of corporate networks. ~ 56 ~

58 Frame Relay, ATM Layer 3 IP VPN Tunnels (GRE) MPLS Layer 3 VPN Ease to maintenance Low Medium High Security High High High Flexibility / Scalability QoS Ability to support multiple logical topologies Capabilities access VPN with multiple technologies (dialup, adsl, leased line) Medium Medium High Medium Low Not natively supported Low High High Medium High High Table 5: General comparison of technologies for the providing of corporate networks In general terms the MPLS provides an effective backbone network solution. Not only it makes the network simpler and more flexible and scalable, but also offers flexibility in terms of service provisions to customers. ~ 57 ~

59 6. References 1. Minei, I., & Lucek, J. (2005). MPLS Enabled Applications. England: John Wiley & Sons Ltd. 2. Sharma, V., Hellstrand, F., Nortel Networks et al. (2003). IETF RFC Framework for Multi-Protocol Label Switching (MPLS)-based Recovery. 3. Configuring a basic MPLS VPN. Nov 16, Ivan Pepelnjak, Jim Guichard, Jeff Apcar. Published by Cisco Press. (Jun 6, 2003) MPLS and VPN Architectures, Volume II 5. MPLS Best Network Solution (2009) Ulysses D. Black (2000) MPLS and Label Switching Networks 7. Davie, B. S., & Farrel, A. (2008). MPLS Next Steps. Burlington: Elsevier Inc. 8. Ghein, L. D. (2006). MPLS Fundamentals. Street Indianapolis: Cisco Press. 9. Eric C. Rosen et al., "BGP/MPLS VPNs", Internet draft (draft-ietf-ppvpnrfc2547bis-00.txt), July Lobo, L., & Lakshman, U. (2005). MPLS Configuration on Cisco IOS Software. Indianapolis: Cisco Press. 11. Dave Kosiur Building and Managing Virtual Private Networks. 12. Mike Erwin, Charlie Scott, Paul Wolfe Virtual Private Networks, 2 nd Edition (O Reilly Nutshell) 13. Ruixi Yuan and W. Timothy Strayer, Virtual Private Networks: Technologies and Solutions 14. Rosen, E., Callon, R., Cisco Systems Inc et al. (2001). IETF RFC Multiprotocol Label Switching Architecture. 15. Rosen, E., Tappan, D., Fedorkow, G et al. (2001). IETF RFC MPLS Label Stack Encoding. 16. Sharma, V., Hellstrand, F., Nortel Networks et al. (2003). IETF RFC Framework for Multi - Protocol Label Switching (MPLS)-based Recovery. WikiPedia. Multi - Protocol Label Switching. tching 17. Shivlu Jain. Implementation of MPLS. ~ 58 ~

60 18. GNS-3 (Graphical Network Simulator) Copyright ~ 59 ~