Click here to load reader

Putting the Layer 3 into Layer 3 MPLS VPN 2547bis MPLS VPNs Putting the Layer 3 into Layer 3 MPLS VPN Management MPLS VPN Route Analytics 2013 Packet Design, Inc. 1 Executive Summary

  • View
    215

  • Download
    0

Embed Size (px)

Text of Putting the Layer 3 into Layer 3 MPLS VPN 2547bis MPLS VPNs Putting the Layer 3 into Layer 3 MPLS...

  • Route Analytics for

    RFC 2547bis MPLS VPNs

    Putting the Layer 3 into

    Layer 3 MPLS VPN Management

  • M P L S V P N R o u t e A n a l y t i c s

    2013 Packet Design, Inc. 1

    E x e c u t i v e S u m m a r y

    Layer 3 MPLS VPNs are an important component of most service provider WAN offerings today, and represent a major revenue stream. Yet while service providers enjoy a level of maturity in service delivery of RFC 2547bis MPLS VPNs, they still suffer from immature MPLS VPN service management capabilities. Management systems have focused on traditional device-oriented connectivity and performance statistics, and are unable to provide the per-customer visibility needed to ensure customers site-to-site IP reachability, VPN privacy and correct VPN routing policy. These key customer and operational concerns can be addressed by a new technology for IP Layer 3 network management.

    The lack of a Layer 3 management capability has significant operational impacts such as reducing service assurance and operational efficiency, and bottom-line impacts such as lost revenue when Service Level Agreements are not met and longer time to verified customer provisioning and revenue. This white paper examines the current operational state of MPLS VPN management, introduces IP route analytics technology and explains how Packet Designs VPN Explorer provides the missing Layer 3 management needed to help service providers maximize efficiency, productivity and profitability in their MPLS VPN service offerings.

    The State of MPLS VPN Management

    RFC 2547bis MPLS VPNs are based on the notion of a virtualized network infrastructure where each customers traffic is routed through the providers network based on information maintained in separate Virtual Routing and Forwarding (VRF) tables. Customer edge (CE) routers peer with service provider edge (PE) routers, where each VRF acts as a private container for an individual customers VPN routing information, directing the flow of traffic between that customers sites, while maintaining the privacy of their site addresses from other customers. This virtualized, per-customer routing information is distributed between the PE routers participating in each customers VPN using an extended version of the BGP routing protocol known as MBGP. Customer traffic between any two PE routers participating in their VPN is forwarded across one or more provider (P) routers in the MPLS core of the service providers network. For a more detailed introduction to MPLS VPNs, see the Resources section at the end of this paper.

    Despite the virtualized, logical nature of the MPLS VPN architecture, MPLS VPN management solutions have been remarkably device oriented. Management of MPLS networks and services has so far been accomplished using SNMP polling of router interfaces, and is focused on router connectivity or performance issues. Connectivity-oriented management solutions identify affected VPNs when there is a device or interface failure on a CE, PE or P router, while performance management solutions provide periodic data on delay, jitter, and packet loss within the MPLS core. Ironically, the excess bandwidth and path redundancy available in most service provider core networks mean that relatively few problems result from device failures or traffic congestion. Together, connectivity and performance management tools deliver some visibility into VPN status, but they both miss

  • M P L S V P N R o u t e A n a l y t i c s

    2013 Packet Design, Inc. 2

    necessary visibility into the virtualized, distributed routing upon which the individual customer VPNs are built.

    MPLS VPN Routing is a Key Management Challenge

    Most of the problems in managing RFC 2547bis MPLS VPN services are due to the complex virtualized routing configurations required. Today, the configuration and validation of MPLS VPNs is largely a manual process, which is error-prone due to the lack of uniformity in configurations across the aggregate set of customer VPNs.

    Each customer VPN requires configuration of many devices, possibly from multiplevendors

    Each PE router hosts a large number of VRFs

    PE participation in customer VPNs varies based on site locations

    Customer VPN routing policy variessome are full-mesh connectivity WANs andsome are hub and spoke topologies

    Both design as well as human errors can cause configuration problems, and these errors can occur at multiple stages in the life of the service:

    During new service provisioning

    When making a change to a customers service

    As a result of changes to other customers services

    Competing configurations with other services, such as Internet access service

    During routine router maintenance or upgrades

    Due to vendor soft failures or bugs

    In addition to configuration errors, MPLS VPNs are prone to routing problems due to the fact that customers are in essence peering directly with the service providers core BGP routing operation. This CE to PE peering is vulnerable to the same problems that are common to all router peerings, yet may have greater impact due to the multiple VPNs supported by a common BGP mesh. For example:

    Route leakage: A CE router may mistakenly redistribute incorrect routes, or eventhe full Internet routing table and advertise those routes to its corresponding PErouter. If proper filtering is not enabled, this can consume the memory in the PErouter, possibly disrupting service to all VPNs supported by the PE router. Inaddition, the leaked Internet routes may be advertised to other PE routersparticipating in that customers VPN, further affecting the VPN network or theentire BGP mesh. This is a complex problem, since there can be a wide variance inthe number of prefixes per customer VPNservice providers have observedanywhere from 5 to 50,000 prefixes being routed within a customer VPN.

    Route flapping: A CE router may inject a flapping route from the customers siteinto the service providers network, which would not be visible to an SNMP-basedmanagement system, and could impact CPU utilization of the PE routers anddisrupt multiple customer VPNs.

  • M P L S V P N R o u t e A n a l y t i c s

    2013 Packet Design, Inc. 3

    The complexity of problems that can occur in MPLS VPN routing is exacerbated by the fact that BGP, which manages the VPN routing, is itself a very complex and difficult to manage routing protocol. Even in a pure MPLS VPN network, BGP can easily generate hundreds of thousands of messages per second, creating a problem for network engineers who have to sort through large volumes of BGP events to detect or isolate reported customer problems.

    New Metrics for MPLS VPN Management Required

    In the face of these VPN routing challenges, a new set of service management metrics are needed for VPN visibility beyond devices and interfaces. Following are three VPN service metrics that must be proactively managed in order to deliver reliable Layer 3 MPLS VPN service, and which are not addressed by traditional, SNMP-based management tools.

    Per-Customer VPN Reachability: Reachability expresses whether VPN prefixes are properly distributed between each customers sites by the service providers BGP routing, enabling the site-to-site connectivity expected by the customer. Reachability management requires an historical understanding and baselining of customer advertised prefixes and PE router participation in each VPN so that deviations such as dropped/added prefixes can be immediately detected and investigated to ensure that they do not signify a disruption of service. In addition, monitoring of active versus baseline PE routers per customer VPN shows any dropped PE routers, which may signify a service disruption due to a misbehaving router, or a peering problem with a particular site.

    Per-Customer VPN Privacy: A fundamental requirement of an MPLS VPN service is that customer traffic and routing are kept private. MPLS VPN privacy management ensures that there is no route leakage between individual customer VPNs. Since MPLS VPNs allow different customers to use the same IP address space, such as private addresses (RFC 1918), Route distinguishers (RDs) are used to distinguish customer routes as they are distributed across the BGP mesh between PE routers. Yet RDs can be misconfigured or assigned to the wrong customer, causing overlapping routes between two customer VPNs. Historical baselining and deviation monitoring of per-customer PE router participation and prefixes advertised by each participating PE router allow operators to catch rogue or misconfigured RDs that would otherwise escape detection until a customer reports a privacy violation.

    Per-Customer VPN Policy: Customer WANs are not all configured as full-mesh networks, so MPLS VPNs must be configured according to the customers chosen policy (e.g. hub and spoke). Route targets (RTs) are utilized to set routing policy within each customers VPN. As with other VPN routing parameters, RTs can easily be misconfigured, causing sub-optimal or disrupted connectivity within the customer VPN. Historical baselining and monitoring of deviations in per-customer RTs helps operators immediately notice any routing policy changes and investigate them.

    These metrics are more problematic for service providers than core connectivity or performance issues, yet are un-addressed by traditional management solutions.

  • M P L S V P N R o u t e A n a l y t i c s

    2013 Packet Design, Inc.4

    Coping with the Rate of Change in VPN Routing Management

    The rate and constancy with which routing changes can occur in an IP network is high when compared to the typical rate of change in device and interface status. This makes SN

Search related