Tackling the Challenges of MPLS VPN Testing. Todd Law Product Manager Advanced Networks Division

Transcription

1 Tackling the Challenges of MPLS VPN ing Todd Law Product Manager Advanced Networks Division

2 Agenda Background Why test MPLS VPNs anyway? ing Issues Technical Complexity and Service Provider challenges Possible Solutions Network Emulation ing MPLS-VPN s BGP/MPLS VPN Layer 2 MPLS VPN Interoperability Experience Service Level Verification Conclusions Summary Industry Activity 2

3 Why MPLS-VPN s Anyway? Service Providers Worldwide end-user VPN product and service expenditures will grow 275%, from $12.8 billion to $48.0 billion between 2001 and 2005 (Source: Infonetics, May 2001) Network Equipment Manufacturers (NEM) US and Canadian service provider expenditures for metro network equipment will grow 175%, from $6.3 billion to $17.2 billion between 2000 and 2003 (Source: Infonetics, April 2001) (and VPN is a key requirement for this equipment) In the current market conditions, this is a serious opportunity! 3

4 ing Issues For SP s MPLS-VPN are one of the key revenue generating technologies..but it s complex! To protect that revenue stream (ie. meet SLA s) SP s need to prove their infrastructure Almost every IP network today uses Routers from multiple vendors. SP s don t want to be limited to single source - interoperability is necessary SP s cannot simply believe competing vendors claims. Need to test functionality, robustness, scalability and performance Cisco GSR series Juniper M series Needs to be done quickly and costeffectively Not just once, but any time software or hardware is upgraded/changed 4 Unisphere ERX series Riverstone 8000 series

5 ing Issues: Possible Solutions NEMs build multiple sets of equipment to test SPs obtain multiple NEM s equipment on a long-term evaluation Typically, the evaluation period gets extended as the engineers from different NEMs try to troubleshoot. Sometimes the engineers from different NEMs get together at Interoperability events (e.g. GMU AIL, UNH, EANTC, ilabs at N+I, etc.) A number of Interoperability events are held, but still issues exist: A week of testing may yield only a few answers Event is representative of only a single point release in time (h/w & s/w) SP s rarely have access to detailed results SP s need continuous testing and complete answers 5

6 Network Emulation: The Need Full network emulation on MLS-VPNs is critical: The PE router contains the protocol smarts and has the most responsibility: MPLS LSPs are end to end (PE to PE) Customer traffic flow is controlled at PE VPNs are completely managed and configured at the PE Various other services may also originate at the PE Hence, emulating the PE is essential to exercising the other PE routers It is also necessary to emulate the end-users of the SP network, i.e., the CE devices Emulating all network elements enables control and data flows to fully exercise the system under test - which can be a single device or a network 6

7 How to: BGP/MPLS VPNs Set up over an MPLS Label Switched Path Setting up VPN ibgp protocol with multiprotocol extensions exchanges VPN information between PE routers A BGP label is used to identify the VPN New scheme to handle overlapping address space: VPN-IPv4 Address = [ Route Distinguisher + IPV4 Address] Every PE maintains VPN Routing & Forwarding (VRF) tables, one VRF table per site (CE router) attached to the PE Reachability information for a given VPN is propagated only to members of that VPN using BGP multi-protocol extensions No special security except inherent security due to the BGP label & unique VRF table, and the LSP between the PE routers 7

8 Visually - Layer 3 BGP/MPLS VPN VPN B PE-CE exchangepe Device 1 CE CE CE Device 1 PE PE PE Device 4 MP-iBGP MPLS LSP 1 MPLS LSP 2 VPN Tunnels VPN B Service Provider Network with an IGP: OSPF or ISIS VPN B CE P P / PE P Device PE Device 3 PE PE Device 1 & PE Device 2 are BGP PE Device peers, 2 and support VPN CE Device 2 LSP Label BGP Label CE IP Packet 8

9 BGP/MPLS VPN Scenario VPN B VPN C How many VRF tables can the PE manage? Is the router able to effectively manage each VRF table? Does the router push the correct VPN and PE labels onto traffic destined for different customer sites? Can the router forward labeled traffic destined for customer sites at wire-speed? Can the router switch over VPN traffic to back up tunnels effectively? PE router PE router SUT PE router Provider Network VPN B VPN B VPN C 9

10 Functionality Scenario VPN B VPN C : RT = RD = A VPN B: RT = RD = B VPN C: RT = RD = C CE 2 PO PO CE 1 CE 3 PO RT RTOSPF RT RIP EBGP MP-iBGP LDP/RSVP SUT PO RT PE router IS-IS/OSPF Provider Network MP-iBGP Table A: RT=A Table B: RT = B Table C: RT = C Multiple Protocols involved: Table A: RT = A Table B: RT = B Simulated PE router Table B: RT = B Simulated Table C: PERT = router C PE-CE Protocols: RIP, OSPF, EBGP PE-PE Protocols: MP-iBGP Provider Network Protocols: IS-IS, OSPF, LDP/CR-LDP, RSVP VPN B VPN B VPN C 10

11 Scalability & Performance Scenario The er must be able to: Establish a large number of VPN connections to the SUT, thus stressing the control plane. Two ways to do this: i) Connect many emulated CE s as independent VPN sites and force a large number of VRF s ii) Make one site a member of many VPN s and force a large VRF on the SUT Also need to stress the data plane by sending traffic at line rate and then measure key QoS parameters (per VPN or per interface) Packet loss Packet delay Packet jitter VPN 1 VPN 1 CE/ VLAN 1 PE 1 PO RT SUT PO RT VPN 1000 Ethernet Interface VPN 3000 CE/ VLAN 3000 IS-IS Provider Network PE 3 PE 2 VPN 1001 VPN 2000 SUT needs to maintain 3,000 VRF tables VPN 3000 VPN

12 How to: Layer 2 MPLS ( Martini ) VPNs Set up over an MPLS Label Switched Path Setting up the Point-to-Point Layer 2 VPN LDP protocol with extensions exchanges VPN information between PE routers (extended discovery) A special Virtual Circuit (VC) label is used to identify the VPN A Control Word encapsulation may be used to replace the Layer 2 packet header VC s are set up only between PE routers which have an LSP set up between them Reachability information for a VC to a target CE is propagated to the source PE from the destination PE using a targeted LDP session No special security except inherent security due to the VC label and the LSP between the PE routers 12

13 Visually - Layer 2 over MPLS ( Martini ) CE CE Device Layer2 link PE Device 1 PE CE P Device VPN B MPLS LSP Targeted LDP (To set up VC) VPN Tunnels (inside LSP) VPN B How many Virtual Circuits can the PE manage? Does the router push the correct VC and PE labels onto traffic destined for different customer sites? Can the router forward labeled traffic destined for customer sites at wire-speed? Service Provider Network VPN B CE P PE PE Device 3 13 PE PE Device 2 CE Device CE LSP Label VC LabelControl Word PE Device 1 & PE Device 2 support VPN Layer 2 Payload

14 Functionality Scenario CE Device 1 Port Port 1A, VLAN 200 -> peer , VCID 100 LDP advertises VC label Blue for VCID 100 LDP advertises VC label Red for VCID 100 Ethernet Red LSP LSP Blue Ethernet 1A, 200 PE Device SUT Port P Device MPLS LSP in both directions Service Provider Network Targeted LDP session to advertise VC labels PE Device 2 Port 2A, VLAN 400 -> peer , VCID 100 CE Device 2 14

15 Scalability & QoS Scenario VC ID PO RT Ethernet Interface VC ID SUT has to manage 3000 VCs Traffic can be sent over each of these VCs and QoS measurements can be made PE 1 SUT PE 2 VC ID T2 PO RT T3 T2 PE 3 PE 4 VC ID

16 Interoperability: Recent Experience with RFC 2547bis ERX140 0 PE GbE Emulated CE M10 OC3c POS OC3c GSR C 7206 POS P OC48c POS AGI L RT PE PE Emulated PE Agilent participated in the N+I ilabs at Atlanta, Sept 2001 Topology as shown - LDP network Successfully set up BGP VPNs with the other PE routers Note that another part of the ilabs event highlighted those vendors with early L2 VPN ( Martini draft) capability. Here test equipment were used only as traffic sources 16

17 Service Verification Typical SLA Parameters a) QoS and Traffic: - PE-PE round-trip-delay - Delay Variation (jitter) - Packet Loss ratio b) Access link load c) Availability * d) Total traffic offered * e) Non Conforming traffic * f) Service Activation time g) Service Restoration time * Per site, per VPN or per access connection er Requirements Per VPN site or VPN route measurement Highly granular traffic measurement Distributed traffic measurement Synchronized measurement: Correlate traffic sent from and received at end points 17

18 Service Restoration & QoS Scenario The QoS guarantees for the VPN needs to be maintained in case of an LSP failure. CE 1 Port PE router SUT Port Provider Network Port Backup LSP Primary LSP VPN info L3 L1 Data Packet Measure delay from time of failure to time of arrival of stream on new port, measure packet loss during this switchover. L2 L1 Data Packet PE router CE 2 18

19 To summarize MPLS VPN testing is a complicated and ongoing exercise SP s and NEMs need to ensure functionality, robustness, scalability and performance Integration of the control plane and data plane is essential Emulation is a cost effective and proven way to obtain real world answers er must have the following capabilities: Functionality Emulate all network elements (CE, P and PE) Emulate all required protocols Integrate the preceding functionality e.g. Set up LSP s and VPN tunnels Send line rate traffic over VPN tunnels Usability Make fine-grain measurements for packet exchanges (control and data planes) Capture / Decode exchanges in real time 19 Intuitive and familiar GUI Reporting/logging facility Automation for regression testing

20 MPLS VPN ing Related Industry Activity The MPLS Forum Interoperability WG was formed to promote conformance and Interoperability testing Recent contribution on BGP/MPLS VPN testing in this Working Group from Global One Agilent s network emulators were used to facilitate testing very successfully at two recent public BGP/MPLS VPN Interoperability events have occurred Advanced Internet Labs, GMU has been the first on BGP/MPLS Interoperability Agilent, Cisco, Unisphere and Alcatel acted as PE Networld+Interop (N+I) ilabs 20

21 Thank You! 21