200 likes | 302 Views
Helsinki University of Technology – Networking Laboratory. Label Switched VPNs – Scalability and Performance Analysis. Yavor Ivanov yavor.ivanov@hut.fi. Outline. Introduction Background Practical setup Results Conclusions. Introduction. Topic
E N D
Helsinki University of Technology – Networking Laboratory Label Switched VPNs – Scalability and Performance Analysis Yavor Ivanov yavor.ivanov@hut.fi
Outline • Introduction • Background • Practical setup • Results • Conclusions
Introduction Topic Label Switched VPNs – scalability and performance analysis Thesis Goal The scope of this study focuses on several major questions. How traffic engineering will affect the VPN performance? What is the scalability potential of Layer3 Label Switched VPNs? What is the impact of network failure on the VPN performance and how it can be minimized?
Background – Multiprotocol Label Switching • MPLS technology combines the performance of layer 2 switching with the flexibility of layer 3 routing. • Some of its main features include: improved forwarding mechanisms, introduction of label stack and constraint-based routing. • Notorious problems like: network scalability, traffic engineering, integrated recovery and simplified network management are addressed. • Mechanism: Label edge routers classify the incoming packets and based on certain criteria assign labels. After this, packets are forwarded along a label switched path towards the destination. At each hop, Label switch router makes forwarding decisions just by examining the appended MPLS label. • MPLS provides ground for Traffic engineering and Virtual private networking – two concepts with huge significance in the modern networks.
Background –MPLS Traffic Engineering • Provisioning of the limited resources, improved network utilization and service differentiation are required to guarantee desired QoS level in the network. • TE is an extension to MPLS for selecting the most efficient paths across an MPLS network, based on both bandwidth and administrative rules. It allows optimization of traffic flows and load balancing for underutilized paths. • Path establishment is constraint-based, allowing parameters like link bandwidth, current link utilization, resource requirements, link loads, etc. to be considered. • Constraint-based routing is used for path selection, meaning that traffic flows are routed across the network based on their service requirements, flow priority and the available resources.
Background – MPLS Virtual Private Networks • The term Virtual Private Network has been associated with a private communication within a company’s network over a public infrastructure. • L3VPNs - customer sites maintain relationship only with the provider edge routers. VPN routes are stored and maintained in the PEs, while the core routers do not have any knowledge of them. Increased network scalability! • VPN-IPV4 address family - Customer sites can use private addresses, which does not need to be advertised publicly and are independent of the addresses used by customers of other service providers • L2VPNs - Allows networks based on link-layer technology to be interconnected via an MPLS backbone (huge parts of the provider networks are based on legacy technology like ATM, Frame Relay or Ethernet). The difference between L3 and L2 VPNs can be found in the relation between Provider Edge (PE) and Customer Edge (CE) devices. In layer2 VPNs, the PE is not a peer of the CE. It does not store the customer routes, but just maps the incoming layer2 traffic into emulated pseudo wire/LSP.
Background – Protection and Restoration • Networks are complex entities with large number of devices and underlying infrastructure • To minimize the negative effect of failure events, MPLS-TE introduces variety of mechanism for network protection and restoration • Path protection – global protection scheme. This is a recovery mechanism providing 1:1 protection for the primary LSP. The head-end node pre-establishes a backup tunnel, which is used only in case of primary LSP failure. Poor scalability. • Fast reroute - local protection scheme. Two distinct mechanisms for protection and restoration – one-to-one backup and facility backup • In one-to-one protection scheme the PLR node establishes a separate backup tunnel (called Detour LSP) for each primary LSP it routes. • Facility backup establishes a single tunnel, called bypass tunnel in order to guarantee protection for a set of primary LSPs. Relies on the MPLS label stack to provide local protection against link or node failures. Node and link protection.
Background – Protection and Restoration • Point of local repair (PLR) - that is the router, which initiates the backup tunnel in order to protect link or a node. • Merge Point (MP) - that is the point where backup tunnel ends. • Next-hop router (NHop) - this is the router that is one hop away from the PLR. • Next-next-hop router (NNHop) - it is the node that is two hops ways from the PLR
Practical setup Goals: • Study the protection scalability of Label switched VPNs. • What is the effect of the described restoration mechanisms on the network performance? • The importance of these questions is growing proportionally to the adoption speed of MPLS in the core as well as the increasing demand for highly reliable service from the customers. That’s why this study was focused on the resiliency technologies and their application in MPLS VPNs. Simulations • Different simulations, in normal state and under failure conditions, were planed and performed
Practical setup Description • The practical part of the thesis was divided into three simulation scenarios. • The first one gives the comparison basis. It models an MPLS enabled network without any traffic engineering or protection mechanisms. • The second simulation implements TE in the core of the network, • And the last simulation includes protection and restoration mechanisms. • Simulation1 and Simulation2 were split each in two Runs. In the first one the network is in stable condition. In the second one, network failure was modeled.
Results – Simulation1 • The IP convergence time of both Simulation Runs differs significantly. In Simulation1_Run1 the average value is 0.00590s, while for Run2 it is 0.01835s. Indicates topology changes • In the first scenario, increased exchange of updates is monitored in the beginning of the run (until routing protocol converges) Different is the situation with the second scenario where next-hop updates mark several peaks in their activity
Results – Simulation1 • Data from the first simulation shows that VRF size increases proportionally to number of sites that participate in it. The larger the VPN, the more entries are included in the VRF table. Can increase the load over the hardware resources. • VPN signaling traffic - PEs should be fully meshed within a single AS in order to have a complete view of the transit routes. The number of IBGP sessions between all PEs can be expressed by following formula: (n) (n - 1)/2 ,where “n” is the number of PE routers. • This means that if there are 2 routers, only 1 BGP session is needed. If there are 4 routers, 6 sessions should be established and if there are 20 routers the number of IBGP sessions grows to 190! • To avoid such problems, BGP Route Reflectors were deployed in the network.
Results – Simulation2 • After the link failure at 1000s, VPN RED delay increases from approximately 0.0042 to 0.0058 and remains in this range until the end of the simulation. • For Simulation2_Run1 the highest average number of entries in the table was 109.82 registered at Area2_PE1. Almost double was the average table size in the second run: 209.88 entries, which were marked by Area3_PE4 • LSP Area1_PE3-Area3_PE5 in the first simulation had average recovery value of 16.678s with a peak reaching 30.011s. The same LSP in Simulation2_Run2 had average recovery time of 13.344s and a peak value of 20.012s.
Results – Simulation2 • The IP processing delay in the TE enabled network was reduced noticeably. Traffic was distributed more evenly across the network, which helped to take off load from some nodes and put it to another. The explicit path configuration of LSPs helped to balance the underutilized routes and to achieve more optimal traffic distribution. • The delay in some VPNs was reduced (VPN PURPLE) - traffic load was distributed more evenly over the network. This resulted in reduced delay for some links in favor of others. • The recovery times for some LSPs improved significantly.
Results – Simulation3 • The average number of updates taken from the Area3_PE4 for Simulation2 was 149.40, with a peak value reaching 198. Looking at the same node in Simulation3 could be seen that the average number of route updates was reduced to 145.20 and the peak was 186. • Average duration of the network convergence was also lowered from 30.007s to 26.320s in Simulation3.
Results – Simulation3 • The modeled failures did not have the negative impact on the network as in the first scenario and this was expected. • Considering the scalability potential of these resiliency mechanisms, path protection scheme lags behind. Reserving resources on an LSP-basis means too much wasted resources • Local protection takes care of multiple tunnels flowing over a protected link, which is much more scalable. • In some situations, the protection mechanisms might have a negative effect on the delivered service. Failure impact is minimized thanks to the backup LSPs, however if traffic is rerouted to a bypass tunnel with some capacity constraints, some LSPs will be dropped in favor of other (preempted).
Conclusions • The network performance was gradually improving through the different scenarios mainly because of the MPLS TE mechanisms and the implemented protection schemes. • Expanding the VPN network might cause some scalability concerns due to the fact that PE nodes should be connected in a full mesh. Solution: Route Reflectors • Local reroute might not be able to meet the TE requirements, when failure occurs, which can result in serious loss of quality. • Path protection mechanism is not as fast as the Fast reroute. Simulations analysis proved that path protection has poor scalability, which is the reason why it is not widely implemented. • Expanding the network with its VPN service requires support for different types of equipment and variety of protocols. Interoperability