Tackling the Challenges of MPLS VPN Testing

Todd Law Product Manager Advanced Networks Division

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

Why Test MPLS-VPN Anyway? s Anyway

Service Providers
n

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) n 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

Testing Issues
n

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

Testing Issues: Possible Solutions

n n n n

NEMs build multiple sets of equipment to test SPs obtain multiple NEM equipment on a long-term s 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:
n n

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 rarely have access to detailed results s

SP need continuous testing 5 s and complete answers

Network Emulation: The Need

Full network emulation on MLS-VPNs is critical: n The PE router contains the protocol smartsand has the most responsibility:
n n n n

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

n n n

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

How to: BGP/MPLS VPNs

n n

Set up over an MPLS Label Switched Path Setting up VPN

n

n n

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

n n

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

Visually - Layer 3 BGP/MPLS VPN

VPN B VPN A PE PE-CE exchange Device 1

CE
PE

CE
CE Device 1

PE

PE Device 4

Service Provider Network with an IGP: OSPF or ISIS

MP-iBGP MPLS LSP 1 MPLS LSP 2 VPN Tunnels VPN A VPN B

P Device

PE Device 1 & PE Device 2 are BGP peers, and PE PE Device 2 support VPN

P/ PE

PE Device 3

CE Device 2

CE
VPN A

CE
VPN B
LSP Label BGP Label

IP Packet

BGP/MPLS VPN Test Scenario

VPN A n n n 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?
VPN A

PE router

SUT Provider Network

PE router PE router

VPN B

VPN B

VPN C

Functionality Test Scenario

VPN A
Test CE 1 PO RT

VPN B
CE 2 Test RIP
PO RT OSPF

VPN C
Test RT

CE 3 PO

VPN A: RT = RD = A VPN B: RT = RD = B VPN C: RT = RD = C

EBGP Table A: RT=A Table B: RT = B Table C: RT = C

SUT

PE router
IS-IS/OSPF Provider Network

LDP/RSVP MP-iBGP

Test Test PO PO RT RT

MP-iBGP

Multiple Protocols involved: PE-CE Protocols: RIP, OSPF, EBGP PE-PE Protocols: MP-iBGP Provider Network Protocols: IS-IS, OSPF, LDP/CR-LDP, RSVP

Table A: RT = A Table B: RT = B

Simulated PE router

Table B: RT = B Table PE Simulated C: RT = router C

VPN A

VPN B

VPN B 10

VPN C

Scalability & Performance Test Scenario

The Tester 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 as s independent VPN sites and force a large number of VRF s ii) Make one site a member of many VPN and force a large VRF on the s 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 VPN 1 Packet delay Packet jitter
VPN 1 CE/ VLAN 1 VPN 3000 CE/ VLAN 3000

Test PO RT Ethernet

SUT needs to maintain 3,000 VRF tables

Interface SUT IS-IS Provider Network

Test PO RT

VPN 3000

PE 3
VPN 2001

PE 1

PE 2
VPN 2000

VPN 1000

VPN 1001

11

How to: Layer 2 MPLS (Martini) VPNs

n n

Set up over an MPLS Label Switched Path Setting up the Point-to-Point Layer 2 VPN
n

n n

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 Wordencapsulation may be used to replace the Layer 2 packet header VC are set up only between PE routers which have an LSP set s 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

Visually - Layer 2 over MPLS (Martini)

Layer2 link MPLS LSP Targeted LDP (To set up VC) VPN Tunnels (inside LSP) VPN A VPN B

VPN A

CE
PE Device 1

VPN B

CE
CE Device

PE

P Device Service Provider Network

P

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?

PE Device 2
PE PE

PE Device 1 & PE Device 2 support VPN

PE Device 3

CE Device

CE
VPN A

CE
VPN B

LSP Label VC LabelControl Word

Layer 2 Payload

13

Functionality Test Scenario

LDP advertises VC label Bluefor VCID 100 LDP advertises VC label Redfor VCID 100 LSP Blue Ethernet

VPN A
Ethernet Red LSP 10.10.10.1 SUT
Test Port

PE Device 1 CE Device 1 Test

Port
Port 1A, VLAN 200 -> peer 10.10.10.100, VCID 100

1A, 200

P Device

Service Provider Ta to rge Network a

MPLS LSP in both directions

dv ted er LD tis P e VC ses la sion be ls

PE Device 2
10.10.10.100
Port 2A, VLAN 400 -> peer 10.10.10.1, VCID 100

CE Device 2 VPN A

14

Scalability & QoS Test Scenario

VC ID 1 .3000 Ethernet Interface SUT T3

Test PO RT

Test PO RT

VC ID 2001 .3000 PE 4

PE 1

SUT has to manage 3000 VCs Traffic can be sent over each of these VCs and QoS measurements can be made

T2 PE 2

T2 VC ID 1001 .2000 PE 3

VC ID 1 .1000

15

Interoperability: Recent Experience with RFC 2547bis

M10 OC3c POS Topology as shown - LDP network ERX140 0 GbE OC3c GSR POS C 7206 Successfully set up BGP VPNs with the other PE routers

PE

Agilent participated in the N+I iLabs at Atlanta, Sept 2001

PE

P
OC48c POS

PE

AGI Emulated PE L RT

Emulated CE
VPN A 16

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

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
17

Tester 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

Service Restoration & QoS Test Scenario

The QoS guarantees for the VPN needs to be maintained in case of an LSP failure.

VPN A
CE 1 Test
Port

PE router

SUT

Test Port

Provider Network

Test Port

Backup LSP
VPN info

Primary LSP PE router Measure delay from time of failure to time of arrival of stream on new port, measure packet loss during this switchover.

L3

L1 Data Packet

CE 2

L2

L1 Data Packet

VPN A 18

To summarize
n n

MPLS VPN testing is a complicated and ongoing exercise SP and NEMs need to ensure functionality, robustness, s 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 Tester must have the following capabilities:
Usability Make fine-grain measurements for packet exchanges (control and data planes) Capture / Decode exchanges in real time Intuitive and familiarGUI Reporting/logging facility Automation for regression testing

n n

Functionality Emulate all network elements (CE, P and PE) Emulate all required protocols Integrate the preceding functionality e.g. Set up LSP and VPN tunnels s Send line rate traffic over VPN tunnels

19

MPLS VPN Testing Related Industry Activity

n n n

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 network emulators were used to facilitate testing s very successfully at two recent public BGP/MPLS VPN Interoperability events have occurred
n

Advanced Internet Labs, GMU has been the first on BGP/MPLS Interoperability
n

Agilent, Cisco, Unisphere and Alcatel acted as PE

Networld+Interop (N+I) iLABs

20

Thank You!

E-mail: todd_law@agilent.com

21