MPLS cisco QOS VPN full 139923 presentation

TM MPLS Virtual Private Networks Peter Joy Senior Product Marketing Manager Presentation Title 10/18/19 Lucent Technologies – Proprietary The IP VPN Challenge IP MPLS VPNs Emulate a Private Network Over a Shared IP Network Branch/Regional Offices Remote Workers Shared IP Network Corporate Headquarters • • • Internet Customers, Suppliers Layer - Any to Any connectivity Security, reliability, performamce, management No manual configuration of PVCs VPN forecasted growth $B 10 • 73% of Fortune 1000 companies are moving away from private networks • 51% of companies plan to outsource VPNs • All ISPs will have a VPN solution by end 1999 • 80% of service provider profits will come from data most of it from VPN services (Tom Nolle, CIMI Group) $0 1998 1999 2000 IP VPN Services VPN Equipment Management 2001 CAGR 81% 42% 16% 2002 2003 Source : IDC July 31999 Networking industry trends Circuit Switch Voice Private Networks Frame Relay Internet ATM IP VPNs Growth Rate IP Voice/Fax Introduction Early Growth Majority Adoption Maturity Decline Time IP Navigator/MPLS Layer edge routing lookup to determine cut through path GX550, CBX 500, B-STDX 9000 Multiservice QoS core IP Fast Layer switching along quality of service connection • • • • • • The industry’s First baseline MPLS implementation Uses standard IP protocols - OSPF, BGP-4, RIP-2 Maps connectionless IP through switched core Entire backbone appears as single QoS aware hop Uses advanced label switch path aggregation technology (MPT) to minimize the use of virtual circuit resources Provides Absolute QoS in the core-mapping IP to ATM class of service Lucent’s MPLS IP VPN approach - Key Features • • • • • • • • Submitted to IETF for RFC approval Unique VPNID within the Service Provider network Use of existing routing protocols without modification Easy configuration/adding of new sites - equivalent to adding a new logical port User Security - uses industry standard router security Dynamic of discovery of virtual routers within the VPN Highly scalable - no pre-allocation of resources Use of private and unregistered address space allows for ease of enterprise adoption What are Virtual Routers? • • • • Logically independent routing domain for each VPN Each virtual router is NOT a separate operating system“task” Resides only at edge of SP network Logically equivalent to a physical router (filters, interfaces, access lists, configuration, management, monitoring,) • Virtual Routers in a VPN represent a virtual routing domain and dynamically discover each other in the service provider network • Customer view is similar to Ethernet LAN connected routers • Carrier management similar to layer services Traditional IP Enterprise Network Traditional method: -PVC or leased line connections -Fully meshed cost prohibitive or difficult to manage Customer A Headquarters Customer A Boston Branch Company A’s Enterprise Network Customer A LA Branch Customer A Dallas Branch Multiple MPLS IP VPNs Physical Topology View Customer A Headquarters Customer B Dallas Branch CE Router Customer B Headquarters Logical VPN View CE Router CE Router HQ Customer A VPN B-STDX 9000 B-STDX 9000 CBX 500 Boston CBX 500 HQ B-STDX 9000 B-STDX 9000 CE Router Customer B LA Branch CE Router Customer A LA Branch LA Customer B VPN CE Router Customer A Boston Branch Dallas LA Accessing the VPN Customer B HQ (NY) Customer C HQ (NY) Customer A Branch (Boston) Router • VR VR VR • • • • VR Customer B Branch (Peoria) VR Customer A HQ (Chicago) VR Ingress IP interfaces allow IP VPN traffic to access the Lucent network For IP logical ports that use frame relay, each IP VPN that uses the lport has one or more DLCIs A DLCI is associated with a particular VPN For ATM, each VPI/VCI is associated with each VPN For PPP or Ethernet, a single IP VPN owns the port When a DCLI or VPI/VCI is assigned to a VPN for the first time in a switch, a VR is created for the VPN Customer C Branch (Dallas) 10 Comparison to BGP “overlay” model -Rules for network configuration and operation- CE peering requirements • Since the VR approach is based on standard routing protocols and routing domains, there are no special rules for how to connect customer sites to the core network • The overlay approach requires network administrator and CPE administrator implementation of special configuration rules 23 Comparison to BGP “overlay” model -Rules for network configuration and operation (CE peering requirements) • If RIP is run to the CE, it is required that the PNA configure the multi-homed CE correctly to NOT leak routes distributed from PE to another PE • If OSPF is run to the CE, it is required that the site be run as large OSPF area with the CE being the area border router • Additionally, it is required that the PE should be in a different area and the PE report no inter-CE links • RFC 2547 does not specify if other special rules apply for other protocols, e.g., ISIS • A new and special parameter "SOI" has to be configured to ensure routing loops are avoided 24 Comparison to BGP “overlay” model -Dynamic discovery of VPN endpoints • The VR approach specifies a methodology for the dynamic discovery of other VRs in the network using IP multicast facilities A manual override for completeness is also specified • The overlay approach does not use dynamic discovery of other PEs involved in a VPN The RT attribute only suggests a Closed User Group It does not specify who the members are 25 Comparison to BGP “overlay” model -Routing protocols between VPN endpoints • The VR approach does not mandate the use of a specific protocol within the cloud Examples of protocols include RIP, BGP, OSPF, ISIS • The Service Provider and/or the Private Network Adminstrator (PNA) may use any combination of protocols • The overlay model mandates the use of BGP within the network Per VPN customization based on protocol suitability is unavailable 26 Comparison to BGP “overlay” model -Extensibility • Since the VR approach merely seeks to provide real IP router facilities to all VPNs, it is automatically extensible to support other IP applications and technologies such as Multicast • No new architecture will be required Every new application is simply an add-on • The overlay model is specific to BGP and new services will require new architectures 27 Comparison to BGP “overlay” model -VPN endpoint granularity • The VR approach treats the VRs as independent IP routers • VRs can be of any size - one VR could use memory for a 1000 routes while all others use memory for only routes each • The overlay model requires that all routes in a VPN be stored in all PEs that participate in that VPN This implies that the size of the routing table in the PE having the largest number of routes in the VPN determines how much memory is used up in ALL PEs 28 Comparison to BGP “overlay” model -Private network autonomy • The VR approach allows the full range of autonomy from none to full - Private Network Administrator (PNA) may be allowed to fully manage the Layer resources provisioned for that VPN by the Service Provider Administrator (SPNA) • The overlay model does not allow the PNA to configure and manage the VPN end-to-end This is not configurable from VPN to VPN Specifically, IP savvy SPs who buy VPN services from a larger SP will be unable to control their destiny - applies to provisioning as well as end to end troubleshooting and monitoring 29 Comparison to BGP “overlay” model -Interconnection of VPNs • Both approaches allow for the interconnection of different VPNs to be fully configurable • In the VR approach, the interconnection of VPNs is simply a matter of provisioning a connection between the VRs • In the overlay model, all the sites in an extranet have to be pre-selected and placed in a unique VPN 30 Comparison to BGP “overlay” model -Data security • The VR approach utilizes a separate routing table for each VPN Packet processing has to utilize Layer markings to select the routing table to be used for further forwarding This implies that for a VPN to accidentally leak a route or data from to another intentional corruption will be necessary • The overlay model utilizes an integrated per-site forwarding routing table This has the implication that accidentally leaking a route or data is easy since only specific fields of the routing table entry need to be corrupt 31 Comparison to BGP “overlay” model -QoS • The VR approach specifies that forwarding quality is configurable for each pair of VRs and on a VR port-byport level This implies that forwarding data could be configured to utilize policy-based forwarding or point to point VPN private LSPs or use the backbone best effort LSP • The Overlay approach does not specify any specific QOS methods available for VPN data forwarding and indeed is best efforts only 32 Comparison to BGP “overlay” model -Performance • With the VR approach, the VPN databases are separate from the perVPN forwarding tables This means that the cost of the lookup algorithm is the sum of the lookup algorithm to find the specific VPN's routing table and the cost of looking up the route in the routing table (The VPN number space is likely to be much smaller than the IP address space, it is possible to make the aggregate cost be something much less) • In general, memory accesses for routing table and link state databases • The overlay model utilizes an integrated forwarding table This means that the aggregate cost of finding the correct forwarding entry is necessarily much higher 33 Comparison to BGP “overlay” model -Performance • In the VR approach, standard routing protocols is used end to end Routing performance is fully dependant on standard factors • For instance, if ISIS is chosen, the Djikstra cost is dependant on the number of links and the number of nodes This cost is simply additive across all VPNs • The overlay model utilizes non-standard BGP routing and routing performance is partially unknown 34 Comparison to BGP “overlay” model -Performance • The overlay model utilizes inbound route filtering which is very inefficient on router receive memory, router transmit memory, network bandwidth and with respect to memory used for routing information bases • Since the overlay model does not utilize a dynamic neighbor discovery mechanism, when an existing VPN is added to a PE, it has to use the route refresh mechanism to seek routes from other PEs that have routes in this VPN • This is a non- scalable utilization of network bandwidth 35 Comparison to BGP “overlay” model -Control bandwidth usage • The VR approach uses approximately 50 bytes per VPN per SPED per hour This is the only overhead Since standard routing protocols are used and since neighbor discovery is dynamic, outbound route filtering is employed to minimize usage of core bandwidth • The overlay approach uses only inbound route filters This means that much network bandwidth is wasted on sending routes to routers that don’t need them 36 Comparison to BGP “overlay” model -Upgrade to network based VPN service • The VR approach treats the new VR as simply an additional VR in an existing IP domain This means that tunnels (IPSEC etc) are not disrupted • The overlay model hides CE addresses from other CEs, breaking the operation of tunnels 37 ... associated with each VPN For PPP or Ethernet, a single IP VPN owns the port When a DCLI or VPI/VCI is assigned to a VPN for the first time in a switch, a VR is created for the VPN Customer C Branch... approach allows the full range of autonomy from none to full - Private Network Administrator (PNA) may be allowed to fully manage the Layer resources provisioned for that VPN by the Service Provider... does not allow the PNA to configure and manage the VPN end-to-end This is not configurable from VPN to VPN Specifically, IP savvy SPs who buy VPN services from a larger SP will be unable to control