_______________________________________________________________________
Summary Report Juniper Networks MPLS Plug And Play Functionality Verification and Validation Dynamic and Fast Plug And Play Provisioning Auto-Discovery of MPLS Service End Points Ethernet Unnumbered Interfaces Rapid Activation of Ethernet Services
Isocore Internetworking Lab Isocore Technical Document Reference: ITD-13002 Version (v1.6): 1/15/08
Isocore Internetworking Lab
1
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
12359 Sunrise Valley Drive, STE 100 Reston, VA 20191 Phone: 703.860.1777 Fax: 703.860.1682 www.isocore.com © 2007 by ISOCORE. All rights reserved. For more information about the testing capabilities of the Internetworking Lab, please email
[email protected] This document should not be reproduced as a certification or a validation reference from ISOCORE. The reproduction of this document to the third party requires written approval from ISOCORE Corporation.
About Isocore Isocore provides technology validation, certification and product evaluation services in emerging and next generation Internet and wireless technologies. Isocore is leading validation and interoperability of novel technologies including Carrier Ethernet, IPv6, IP Optical Integration, wireless backhauling, Layer 2/3 Virtual Private Networks (VPNs) and IPTV service. Major router and switch vendors, Service Providers, and test equipment suppliers participate in Isocore activities. Isocore has major offices in the USA (Washington DC area), Europe (Paris, France) and Asia (Tokyo, Japan).
Isocore Internetworking Lab
2
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
Executive Summary This summary report presents the results of an independent test conducted by Isocore to evaluate the capabilities of the Juniper Networks MPLS Plug And Play (MPLS PnP) solution. The testing focused on an elaborate functionality evaluation of the Juniper Networks feature set related to MPLS PnP solution and enhanced scripting capabilities for automated discovery mechanisms, pre-configurations of protocols, and network interfaces. The testing is a first of its kind which independently validates a unique and simplified way to deploy large Ethernet networks using the existing carrier infrastructure with minimal configuration overhead and dynamic discovery of provider edge devices. Testing was conducted on a large testbed representing a true carrier class network comprising of Juniper Networks MX-Series Ethernet Service Routers (ESR) and M-Series Multi-Service Edge Routers (MSER). The basic network consisted of 4 MX-Series ESRs and 2 M-Series MSERs that demonstrated successful auto-provisioning of Layer 2 Point-to-Point BGP based VPNs and VPLS services with 4 sites. Both products performed well during the test cycle and met the specifications of a plug-and-play environment and Isocore’s stringent Ethernet service creation verification test plan. Based on this detailed evaluation of Juniper Networks MPLS PnP solution it is evident to Isocore that MPLS PnP significantly simplifies the provisioning of large scale Ethernet services using MPLS as the transport technology and eases the management and troubleshooting of Metro Ethernet networks. The consistency of observations made as part of the functionality tests using both commit and operation scripts on all nodes in the testbed assures the carrier class grade readiness of the MPLS PnP for a large scale real time deployment.
Test Result Highlights The Juniper Networks MPLS PnP functionality verification demonstrated what it promises to deliver - a reduced configuration and provisioning overhead by using a combination of commit scripts, event policies, and diagnostic or operation scripts. The key findings of the evaluation include: • • • • • •
MPLS PnP successfully established the support of error-resilient configurations on both edge and core routers used in the test It successfully demonstrated the functionality of commit and operation scripts when used as part of the MPLS PnP to apply configurations and to diagnose failures in the network Ethernet Unnumbered Interfaces and their discovery within IGP, BGP and MPLS were faultless during the test and demonstrated the ease of plug and play similar to that of the LAN world while having the advantage of using hardened core transport technologies such as MPLS. Configuration suppression: Juniper MPLS PnP successfully passes all the tests laid out to verify the condensed abstract configurations which could be applied to all same types of nodes in the network rather than configuring each node individually in the network. Considering the preliminary alpha release of the MPLS PnP solution, Juniper Networks JUNOS operation software demonstrated considerable stability and zero packet loss forwarding verification for all functionality test cases verified during the testing effort. Features consisted of the same set of scripts being applied to all nodes in the network. This greatly simplified the tasks required during the testing
Isocore Internetworking Lab
3
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
Table of Contents EXECUTIVE SUMMARY .....................................................................................3 1 TEST OVERVIEW AND SUMMARY...........................................................5 1.1
2
TEST ENVIRONMENT AND SETUP ..................................................................................... 6
TESTING DETAILS AND RESULTS ...........................................................7 2.1 VERIFICATION OF JUNIPER MPLS PLUG-AND-PLAY AUTO-DISCOVERY ........................... 8 2.1.1 Verification of auto-discovery capabilities of MPLS Plug-and-Play for L2VPN and VPLS ................................................................................................................................ 8 2.1.2 Verification of LSP auto-bandwidth feature of MPLS Plug-and-Play ................... 9 2.1.3 Verification of dynamic provisioning of routing protocols on unnumbered Interfaces in MPLS Plug-and-Play ......................................................................................... 9 2.2 VERIFICATION OF JUNIPER MPLS PLUG-AND-PLAY ABILITY TO ADAPT TO NETWORK CHANGES.................................................................................................................................... 11 2.2.1 Verification of Juniper MPLS Plug-And-Play ability to recover from Network Failures using MPLS Fast Reroute techniques ..................................................................... 11 2.2.2 Verification of Juniper Networks MPLS PnP to detect the new links in the IGP and Traffic Engineering Database ........................................................................................ 12 2.2.3 Dynamic logging of alarms, traps, and logs through automated event policies ... 14 2.3 VERIFICATION OF DYNAMIC PROVISIONING AND NETWORK MANAGEMENT USING COMMIT AND OPERATION SCRIPTS ............................................................................................................ 14 2.4 VERIFICATION OF RAPID ACTIVATION OF ETHERNET SERVICES USING MPLS PLUG-ANDPLAY MECHANISM ...................................................................................................................... 17
3 4
CONCLUSION................................................................................................18 LIST OF ABBREVIATIONS ........................................................................19
Isocore Internetworking Lab
4
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
1 TEST OVERVIEW AND SUMMARY As part of its Ethernet services benchmarking program, Isocore evaluated Juniper Networks MPLS Plug and Play solution to ease the deployment and provisioning of carrier-class Metro Ethernet networks using MPLS as the core network technology. The test cases were carefully designed to evaluate each feature offering Juniper Networks MPLS PnP solution while keeping the key Isocore requirements for benchmarking a Metro Ethernet solution intact and independent of the solution under test. Isocore selected Agilent N2X Multi-service Test Solution for this testing to verify the data plane capabilities of Juniper MPLS PnP solution. The base network included 4 Juniper Networks MX-480 ESRs configured as Network Provider Edge routers (N-PE), and 2 M-10 MSERs configured as core routers to emulate a service provider MPLS based core network. Table 1 provides an overview of the executed test scenarios and the associated results. Table 1: Summary of Test Scenarios and Observations Test Scenario Auto-Discovery capabilities of MPLS PnP for BGP based Layer 2 VPNs, and VPLS New Site discovery and activation with MPLS PnP commit scripts Auto-Bandwidth feature functionality verification for Label Switched Paths (LSP) carrying Ethernet Services Total Provisioning time to enable a VPLS site Total Provisioning time to enable a P2P Layer 2 VPN circuit using MPLS PnP The total time to provision this Full Mesh L2VPN for a single site Automatic provisioning of OSPF and MPLS on Unnumbered Interfaces Dynamic creation of Bypass LSPs and the failover time under 50ms Ability to detect new links coming up using MPLS PnP macro configuration and handling of new links in traffic engineering (TE) database Automatic logging of alarms, traps, and logs through automated scripts Verification of LSP states using
Isocore Internetworking Lab
Observations Successfully demonstrated this test by discovering 4 sites based on the commit scripts triggered configuration. The data plane also was verified successfully. Successfully demonstrated this test with all ESRs in the setup discovering the new site within the context of VPLS, and P2P Layer 2 VPNs. Successfully demonstrated the auto-bandwidth feature automatically adjusted the RSVP reservation associated with the LSP when increasing the traffic mapped to LSPs. 30 seconds
Results Pass
40 seconds
Pass
60 seconds versus 262 seconds when full mesh of L2VPN for single site was configured using CLI. Successfully utilized MPLS PnP capabilities to apply macros which built out the core interfaces and required protocols. The interfaces on which the macro was applied successfully allowed the LSP setup. The test verified that MPLS PnP offered SONET like recovery of Ethernet Services from a link or node failures MPLS PnP successfully discovered the new links added to the test network. Both OSPF and TE database were updated.
Pass
MPLS PnP successfully detected the failure of LSP and was reported as a monitoring tool, and the automatic uploading of the log file to the offsite server capturing system logs. MPLS PnP successfully performed all OAM
Pass
Pass Pass
Pass
Pass
Pass Pass
Pass
5
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
operation scripts
Ethernet Service activation – data plane benchmarking Auto-provisioning of all Ethernet infrastructure with no IP addressing used and enabling Ethernet services across MPLS transport
functionality for service ping, LSP ping, Ethernet Access circuit liveliness detection using just one operation script, and same scrip was executed on all the nodes in the testbed MPLS PnP was able to demonstrate that activation of a Point-to-Point Ethernet service at 34 seconds and Multipoint Ethernet service within 28 seconds Successfully demonstrated that no link addresses were used and all links used in the testbed were unnumbered interfaces and all BGP, OSPF, MPLS, LSPs were configured using unnumbered interfaces satisfying the basic Ethernet plug and play requirement
Pass Pass
Under a completely independent testing environment, Isocore performed a thorough analysis of all available aspects of Juniper MPLS PnP solution and its ability to simplify the provisioning and management of a carrier-class metro Ethernet network. The analysis included benchmarking failure recovery time, time to activate any Ethernet service using MPLS PnP versus a CLI configured provisioning, management capabilities of MPLS PnP using operation scripts and how MPLS PnP can bring the Plug-and-Play capabilities of LAN world into an IP/MPLS based network infrastructure. The test was the first of its kind in the industry that leveraged the proven capabilities of MPLS with the simplicity of Ethernet LAN plug and play environment. Juniper Networks MPLS Plug and Play provided all the capabilities to automate the provisioning and troubleshooting a carrier class MPLS metropolitan Ethernet Network. The overall results of the tests confirmed that the MPLS Plug-and-Play can be readily deployed to provision and manage metro Ethernet network that offers enhanced services such as VPLS, Layer 2 VPNs or Layer 3 VPNs over Ethernet. Juniper Networks MPLS PnP offers the simplicity which mitigates the complexity of enabling MPLS over another layer technology such as Ethernet. Juniper Networks MPLS PnP offers much needed tools to reduce the configuration burden and offer excellent troubleshooting mechanisms that may help in quick recovery from network changes. In short, the Juniper Networks MPLS PnP solution passed all tests set forth during this testing phase and demonstrated how a typical multi-step provisioning of MPLS-based Ethernet services can be deployed in a few steps across the entire nodes.
1.1
TEST ENVIRONMENT AND SETUP
Figure 1 provides an overview of the test network setup that was used for this evaluation. The setup used 4 MX-480 ESRs provisioned as N-PE routers and 2 M10i MSERs as MPLS (P) core routers. Each ESR is provisioned with Gigabit Ethernet (GigE) interfaces both core facing and access facing. Two M10i are also provisioned with only GigE interfaces and emulated the core running MPLS traffic engineering. The N-PE routers connect to the Agilent N2X ports emulating the access terminations and customers of Ethernet services. Parallel links are configured to the core from the N-PE routers to offer a comprehensive testbed to evaluate the recovery scenarios on the same setup. Furthermore, dual uplinks have been used from each N-PE router to the P routers ensuring a carrier class test setup for verification of MPLS PnP solution in a large scale carrier environment. Only one setup shown in Figure 1 has been used for the entire test effort. This further confirms the flexibility of the MPLS PnP solution to enable all different types of Ethernet Services across the same infrastructure, making it a deployable solution in any carrier network running MPLS as the core technology. Isocore tested Juniper Networks MPLS PnP on JUNOS 9.0 baseline.
Isocore Internetworking Lab
6
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
Figure 1: Juniper Networks MPLS Plug-and-Play Functionality Verification Testbed Isocore selected the Agilent N2X multi-service test solution as it offers a platform to comprehensively verify the control and data plane functionality across the same ports using one window to capture the traffic flow, packet loss, stream configurations and other parameters to successfully pass the tests. Only Gigabit Ethernet ports were used on the N2X platform for this test. The virtual LAN interfaces were configured to emulate Ethernet service subscribers. No triple-play type of traffic was configured during this test, since performance measurement was not the focus of this test.
2 TESTING DETAILS AND RESULTS One of the key parameters that needed to be examined as the basic functionality building block for successful verification of MPLS PnP was application of commit script and operation scripts which can be applied to a group of routers for simplifying the configuration and management of the nodes in the network. These scripts are typically written in two application programming interfaces (APIs), XML and the JUNOS script API. All the tests used XML based scripts and same set of service scripts were applied to all the nodes in the testbed. Commit scripts were used to apply configurations to the nodes, and validate the configuration parameters. The commit scripts were combined with macro configuration statements to achieve abstract configuration without typing detailed element but calling a detailed profile whenever it is needed. This to a great extent can be applied to all nodes in the network performing similar functions in the network. Isocore’s testing covered the entire breadth of MPLS PnP solution by focusing on the verification of the following JUNOS capabilitiesa.
MPLS PnP solution to support unnumbered interfaces and auto-discovery of service end points at the network edge within the context of point-to-point and multipoint Ethernet services b. MPLS PnP to adapt to Network changes and assistance in troubleshooting the network issues c. MPLS PnP support of commit and operation scripts to prevent procedural errors and simplification of configuration of nodes in the network d. Benchmarking provisioning times for activating a Metro Ethernet services using MPLS PnP solution
Isocore Internetworking Lab
7
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
2.1
VERIFICATION OF JUNIPER MPLS PLUG-AND-PLAY AUTO-DISCOVERY
The objective of this test was to verify the auto-discovery capabilities of MPLS PnP solution, and how JUNOS discovers the remote PE devices when either a point-to-point or a multipoint service is configured using MPLS PnP techniques. The test plan included test cases for evaluating the functionality of Layer 2 VPNs, and VPLS using MPLS PnP solution. To show flexibility of the MPLS PnP solution to provision auto-discovery, and application of error free configuration on all the nodes using the same set of basic MPLS PnP commands, the following tests were conducted: 1. Test to verify discovering capabilities of the ESRs in Figure 1 for Layer 2 VPNs 2. Test to verify that the MPLS PnP can detect addition or insertion of new site within a VPLS domain 3. Test to verify if the MPLS PnP automatically helps in adjusting RSVP reservation on the fly for an MPLS LSP when the traffic hits the threshold 4. Test to verify that MPLS PnP capability to automatically provision protocols on unnumbered Ethernet interfaces To perform auto-discovery tests using MPLS PnP, layer 2 point-to-point VPN (L2VPN) was configured on one of the four ESRs shown in Figure 1. Following application of macro configuration an assortment of operational commands were used to validate that the information for this instance was automatically discovered on the node. 2.1.1
Verification of auto-discovery capabilities of MPLS Plug-and-Play for L2VPN and VPLS
Figure 2 shows the set of 4 macro commands that were issued on one of the edge node (R144 – refer Figure 1) in combination with commit scripts for L2VPN test to enable the full mesh of L2VPNs across 4 N-PE routers in the testbed. Following the issuance of the commit command node R144 successfully dynamically discovered remote nodes within “cust-20” instance of L2VPN and connections were up with three sites (R141, R142, and R143). set set set set
routing-instances routing-instances routing-instances routing-instances
apply-macro apply-macro apply-macro apply-macro
config-fml2vpn-cust-20 config-fml2vpn-cust-20 config-fml2vpn-cust-20 config-fml2vpn-cust-20
ce-int1 ge-5/0/3.141 ce-int2 ge-5/0/3.142 ce-int3 ge-5/0/3.143 site 4
Figure 2: Macro commands for provisioning Layer 2 VPN Figure 3 shows the single command that was issued on one of the edge node (R144 – refer figure 1) to provision the VPLS mesh including all four ESRs in the testbed. Following the issuance of commit command after the macro listed in Figure 2, N-PE R144 was successfully able to discover all other nodes in “cust-3” and displayed information about other 3 sites part of the same VPLS instance. lab@MX480-R144# set routing-instances apply-macro config-vpls-cust-3 ce-int1 ge5/0/2.5
Figure 3: Macro commands for provisioning VPLS The data plane verification was performed by sending and receiving traffic from each access port on the ESR connected to the Agilent N2X platform. No line rate performance measurements were performed however no traffic loss was observed during the test and latency measurements were made during the test, which were in the range of 31 to 40 µseconds.
Isocore Internetworking Lab
8
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
2.1.2
Verification of LSP auto-bandwidth feature of MPLS Plug-and-Play
JUNOS offers LSP auto-bandwidth feature which allows the LSP to automatically adjust its bandwidth based on the traffic flowing through this LSP. In our test initial reserved bandwidth of the LSP was set to 10Mbps, with maximum bandwidth configuration set at 200Mbps. Once the traffic passing through the LSP was increased the reserved bandwidth readjusted automatically to allow the traffic flow. This bandwidth adjustment takes place over “adjust-interval,” which is a configurable parameter, and in our test it was set to 300 seconds. This value was chosen to keep the re-signaling events to minimum.
lab@MX480-R141# run show rsvp interface RSVP interface: 2 active Active Subscr- Static Interface State resv iption BW ge-5/0/0.0 Up 2 100% 1000Mbps ge-5/0/1.0 Up 3 100% 1000Mbps
Available BW 990Mbps 980Mbps
Reserved BW 10Mbps 20Mbps
Highwater mark 492.954Mbps 567.926Mbps
Figure 4.a: Snapshot of RSVP Interface Statistics Before the traffic was passed (Test Node – R141) lab@MX480-R141# run show rsvp interface RSVP interface: 2 active Active Subscr- Static Interface State resv iption BW ge-5/0/0.0 Up 2 100% 1000Mbps ge-5/0/1.0 Up 3 100% 1000Mbps
Available BW 822.09Mbps 684.336Mbps
Reserved BW 177.91Mbps 315.664Mbps
Highwater mark 492.954Mbps 567.926Mbps
Figure 4.b: Snapshot of RSVP Interface Statistics after the traffic was passed (Test Node – R141) Figure 4.a and 4.b show the snapshot from the test on the DUT (Test node – R141) CLI used in the setup illustrating the RSVP interface reservations before and after the traffic starts passing over the network respectively. The bandwidth adjustment process uses the “make-before-break” signaling method and hence no interruption of traffic was observed during the test. Figure 3b shows that the “Reserved BW” increased from 10mbps to 177.91 Mbps without any additional administrative intervention. Isocore successfully verified following the completion of this test that JUNOS adjusted the LSP bandwidth when configured with auto-bandwidth under the label switched path hierarchy. 2.1.3
Verification of dynamic provisioning of routing protocols on unnumbered Interfaces in MPLS Plug-and-Play
Unnumbered Links are point-to-point links that do not have an IP address configured, however they use loopback interface addresses and unique link identifier for identification. In MPLS PnP all links on the core routers, and edge routers were configured with unnumbered interfaces, and IP addresses were used to configure the loopback addresses. One of the key advantages that MPLS PnP offered while executing this test was the usage of configuration templates for the interfaces on each node, since no pre-planned IP addressing scheme needed to be developed, and this further minimized the provisioning time drastically when these templates were applied using commit scripts. All links used in the test were configured for unnumbered interfaces, and the template used could be applied to any number of ports on any router.
Isocore Internetworking Lab
9
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________ ----State before application of macro configuration---lab@MX480-R141# run show ospf neighbor OSPF instance is not running lab@MX480-R141# run show bgp summary BGP is not running ----Macro configuration for enabling interfaces, protocols, and MPLS TE---lab@MX480-R141# set apply-macro config-core-interfaces AS 100 lab@MX480-R141# set apply-macro config-core-interfaces int1 ge-5/0/0 lab@MX480-R141# set apply-macro config-core-interfaces int2 ge-5/0/1 lab@MX480-R141# set apply-macro config-core-interfaces peer1 10.10.10.142 lab@MX480-R141# set apply-macro config-core-interfaces peer2 10.10.10.143 lab@MX480-R141# set apply-macro config-core-interfaces peer3 10.10.10.144 ----Commit is applied to activate all macro commands using backend commit scripts--lab@MX480-R141# commit config-core-interfaces: configuring interfaces ge-5/0/0 ge-5/0/1 warning: commit complete ---After application of commit scripts---lab@MX480-R141# run show ospf neighbor Address Interface State 10.10.10.124 ge-5/0/0.0 Full 10.10.10.125 ge-5/0/1.0 Full lab@MX480-R141# run show bgp summary Groups: 1 Peers: 3 Down peers: 1 Table Tot Paths Act Paths Suppressed bgp.l2vpn.0 0 0 0 Peer AS InPkt State|#Active/Received/Damped... 10.10.10.142 100 0 2 10.10.10.143 100 4 4 bgp.l2vpn.0: 0/0/0 10.10.10.144 100 3 4 lab@MX480-R141# run show rsvp session Ingress RSVP: 6 sessions To From State 10.10.10.142 10.10.10.141 Up 10.10.10.142 10.10.10.141 Up 10.10.10.143 10.10.10.141 Up 10.10.10.143 10.10.10.141 Up 10.10.10.144 10.10.10.141 Up 10.10.10.144 10.10.10.141 Up Total 6 displayed, Up 6, Down 0
ID 10.10.10.124 10.10.10.125
Pri 128 128
Dead 33 33
History Damp State Pending 0 0 0 OutPkt OutQ Flaps Last Up/Dwn 0 0
0 0
41 Active 33 Establ
0
0
26 Establ
Rt Style Labelin Labelout LSPname 0 1 SE 307888 R141-R142 0 1 SE 308400 R141-R142 0 1 SE 307872 R141-R143 0 1 SE 308384 R141-R143 0 1 SE 307856 R141-R144 0 1 SE 308368 R141-R144
Figure 5: Macro configuration for provisioning unnumbered interfaces, and routing protocols at R141 Figure 5 shows the macro commands that were used as part of the MPLS PnP. MPLS PnP reduced the number of CLI commands to 6 for provisioning unnumbered interfaces, routing protocols (including BGP, and OSPF), RSVP and MPLS TE to as compared to 68 commands when using a CLI approach. It is worth mentioning that the number of commands issued for 6 nodes to dynamically enable all the necessary protocols needed for the test to be executed was reduced by 90%. This when translated to saved provisioning time, MPLS PnP does meet its promised end goal of faster and dynamic provisioning.
Isocore Internetworking Lab
10
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
Furthermore, the usage of macro commands minimizes the risk of wrong configuration due to human errors considering the number of commands to be issued has reduced drastically. Isocore confirms through the result of this test that MPLS PnP does help in making the configurations error proof and offer simplification of provisioning by using same templates across multiple nodes in the network.
2.2
VERIFICATION OF JUNIPER MPLS PLUG-AND-PLAY ABILITY TO ADAPT TO NETWORK CHANGES
For any solution to be qualified as reliable and resilient, it needs to support SONET like failure recovery, be able to detect any node or link failures quickly, detect new links being added to the network, and OAM capabilities to check the health of the entire network. In order to evaluate MPLS PnP being able to meet these stringent high-availability requirements, the following tests were carried out within the scope of this section. Once again the motive of this evaluation to check the basic functionality of MPLS PnP to meet these requirements – 1. Automatic detection of link failures in MPLS PnP enabled network using MPLS fast reroute techniques 2. Automatic detection of new links coming up in OSPF, and Traffic Engineering Database 3. Dynamic logging of alarms, traps, and logs through automated event policies To perform network recovery tests the motive was to ensure that SONET like recovery times are observed and one node is considered as DUT for all snapshot capturing purposes. Several show commands, and operation scripts were used to validate the MPLS PnP behavior in various link failure scenarios including local interface deactivation, and fiber pull, but only few snapshots are included in this report for illustration purposes. 2.2.1
Verification of Juniper MPLS Plug-And-Play ability to recover from Network Failures using MPLS Fast Reroute techniques
The test involved verification of link protection capabilities of MPLS PnP when using fast reroute techniques to dynamically creating bypass LSPs, and recovering from a failure within 50msec, as required to offer SONET like failure recovery. The test results confirm that MPLS PnP did meet this requirement by maintaining the traffic loss during the process of failure recovery below 50 milliseconds. Multiple tests of link failures were carried out during the tests, which primarily involved failing one of the core facing links on R-141. No visible signs of performance degradation were observed on any of the nodes in the testbed during the execution of failure recover scenarios. The system gracefully recovered from the failure, and minimal traffic loss was observed which translated into SONET recovery bounds. Figure 6 shows the dynamic Bypass LSPs that were created to protect the primary LSPs.
Isocore Internetworking Lab
11
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________ lab@MX480-R141# run show rsvp session Ingress RSVP: 12 sessions To From State 10.10.10.142 10.10.10.141 Up 10.10.10.142 10.10.10.141 Up 10.10.10.142 10.10.10.141 Up >10.10.10.142 10.10.10.142 10.10.10.141 Up >10.10.10.142 10.10.10.143 10.10.10.141 Up 10.10.10.143 10.10.10.141 Up 10.10.10.143 10.10.10.141 Up >10.10.10.143 10.10.10.143 10.10.10.141 Up >10.10.10.143 10.10.10.144 10.10.10.141 Up 10.10.10.144 10.10.10.141 Up 10.10.10.144 10.10.10.141 Up >10.10.10.144 10.10.10.144 10.10.10.141 Up >10.10.10.144 Total 12 displayed, Up 12, Down 0
Rt Style Labelin Labelout LSPname 0 1 SE 307888 R141-R142 0 1 SE 308400 R141-R142 0 1 SE 308464 Bypass->10.10.10.1250
1 SE
-
307936 Bypass->10.10.10.124-
0 0 0
1 SE 1 SE 1 SE
-
307872 R141-R143 308384 R141-R143 308448 Bypass->10.10.10.125-
0
1 SE
-
307904 Bypass->10.10.10.124-
0 0 0
1 SE 1 SE 1 SE
-
307856 R141-R144 308368 R141-R144 308480 Bypass->10.10.10.125-
0
1 SE
-
307952 Bypass->10.10.10.124-
Figure 6: Dynamic Bypass LSP creation within MPLS PnP 2.2.2
Verification of Juniper Networks MPLS PnP to detect the new links in the IGP and Traffic Engineering Database
This test verified the ability of Juniper Networks MPLS PnP solution to detect the introduction of a new link in the stable topology and updated the IGP and traffic engineering database. To verify this capability we added a link using the “config-core-interface” macro. The link that we added during the test was ge5/0/1 as on one of the edge nodes in the testbed, R-141. Figure 7 illustrates that initially ge-5/0/1 did not exist in the OSPF neighbor information, and in the IGP database. ----OSPF/RSVP information does not show presence of interface ge-5/0/1--lab@MX480-R141# run show ospf neighbor Address Interface State ID Pri Dead 10.10.10.124 ge-5/0/0.0 Full 10.10.10.124 128 36 lab@MX480-R141# run show rsvp interface RSVP interface: 1 active Active Subscr- Static Interface State resv iption BW ge-5/0/0.0 Up 3 100% 1000Mbps
Available BW 970Mbps
Reserved BW 30Mbps
Highwater mark 30Mbps
lab@MX480-R144# run show ospf database router advertising-router 10.10.10.141 detail OSPF link state database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Router 10.10.10.141 10.10.10.141 0x800000b3 831 bits 0x0, link count 4 id 10.10.10.124, data 10.10.10.141, Type PointToPoint (1) Topology count: 0, Default metric: 10 id 10.10.10.124, data 255.255.255.255, Type Stub (3) Topology count: 0, Default metric: 10 id 10.10.10.141, data 255.255.255.255, Type Stub (3) Topology count: 0, Default metric: 0 id 10.10.10.141, data 255.255.255.255, Type Stub (3) Topology count: 0, Default metric: 0
Opt Cksum Len 0x22 0xfdb0 72
Figure 7: Pre-test IGP and TE database state without any information about the new link ge-5/0/1
Isocore Internetworking Lab
12
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
The snapshot of three command output is shown in figure 7 to confirm the before test database and neighbor state. ---Insertion of the new link on DUT (R-141) by adding config-core-interface macro-lab@MX480-R141# set apply-macro config-core-interfaces int2 ge-5/0/1 --- Committing the action---lab@MX480-R141# commit config-core-interfaces: configuring interfaces ge-5/0/0 ge-5/0/1 warning: commit complete ----Snapshot of the output of show commands lab@MX480-R141# run show ospf interface Interface State Area ge-5/0/0.0 PtToPt 0.0.0.0 ge-5/0/1.0 PtToPt 0.0.0.0 lab@MX480-R141# run show rsvp interface RSVP interface: 2 active Active Subscr- Static Interface State resv iption BW ge-5/0/0.0 Up 6 100% 1000Mbps ge-5/0/1.0 Up 3 100% 1000Mbps
confirming detection of a new link--DR ID 0.0.0.0 0.0.0.0
Available BW 970Mbps 970Mbps
BDR ID 0.0.0.0 0.0.0.0
Reserved BW 30Mbps 30Mbps
Nbrs 1 1
Highwater mark 30Mbps 30Mbps
---Note that link id 10.10.10.125 (ge-5/0/1) did not exist before, refer figure 7--lab@MX480-R144# run show ospf database router advertising-router 10.10.10.141 detail OSPF link state database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Router 10.10.10.141 10.10.10.141 0x800000b6 48 bits 0x0, link count 7 id 10.10.10.124, data 10.10.10.141, Type PointToPoint (1) Topology count: 0, Default metric: 10 id 10.10.10.124, data 255.255.255.255, Type Stub (3) Topology count: 0, Default metric: 10 id 10.10.10.141, data 255.255.255.255, Type Stub (3) Topology count: 0, Default metric: 0 id 10.10.10.125, data 10.10.10.141, Type PointToPoint (1) Topology count: 0, Default metric: 10 id 10.10.10.125, data 255.255.255.255, Type Stub (3) Topology count: 0, Default metric: 10 id 10.10.10.141, data 255.255.255.255, Type Stub (3) Topology count: 0, Default metric: 0 id 10.10.10.141, data 255.255.255.255, Type Stub (3) Topology count: 0, Default metric: 0
Opt Cksum Len 0x22 0x29b1 108
lab@MX480-R144# run show ted database detail TED database: 0 ISIS nodes 6 INET nodes NodeID: 10.10.10.141 Type: Rtr, Age: 99 secs, LinkIn: 2, LinkOut: 2 Protocol: OSPF(0.0.0.0) To: 10.10.10.124, Local: 10.10.10.141, Remote: 10.10.10.124 Local interface index: 69, Remote interface index: 0 To: 10.10.10.125, Local: 10.10.10.141, Remote: 10.10.10.125 Local interface index: 70, Remote interface index: 0
Figure 8: Post-test IGP and TE database detecting the insertion of the new link ge-5/0/1
Isocore Internetworking Lab
13
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
Figure 8 illustrates that following the addition of one command line “config-core-interface” macro which simulated addition of new link into the network enabled all protocols, and led to automatic update in the OSPF and traffic engineering databases. 2.2.3
Dynamic logging of alarms, traps, and logs through automated event policies
The focus of this test was to verify the ability of Juniper Networks MPLS PnP solution to offer assistance in detection of failure and accordingly generate logs or traps based on the configurations and upload the log file to the remote location. For this test JUNOS software event process was exercised that receives event notifications from other JUNOS software process. The event process can be triggered based on a policy called event policy that determines what actions should be performed once the event process receives an event notification. For this test to trigger an event policy both core facing interfaces were unplugged at one of the DUTs in the testbed (R-141) causing the MPLS LSPs to fail. The specific trigger was the presence of the “rpd_mpls_lsp_down” syslog showing up. Once this is detected the event policy triggered the log file to be copies of the remote FTP server. This was verified by the FTP connection initiation at the FTP server. Figure 9 illustrates the configuration that was verified as part of this test. The configuration included the event description that triggers the policy to execute the commands and the name of the file that will be uploaded to the destination FTP server. The test results successfully verified JUNOS event process capabilities to dynamically log events such as LSP down event. lab@MX480-R141# show event-options generate-event { upload-messages time-of-day "09:17:00 -0500"; } policy lsp-down-show-commands { events rpd_mpls_lsp_down; then { execute-commands { commands { "show interface terse"; "show mpls lsp extensive"; "show ted protocol"; } user-name lab; output-filename lsp-show-commands; destination randy-ftp { transfer-delay 30; retry-count 3 retry-interval 5; } output-format text; } } }
Figure 9: Event policy configuration for dynamic logging of events
2.3
VERIFICATION OF DYNAMIC PROVISIONING AND MANAGEMENT USING COMMIT AND OPERATION SCRIPTS
NETWORK
The Juniper Networks MPLS PnP offers provisioning simplification of Ethernet Service through a combination of commit and operation scripts. For all the tests conducted as part of this effort, commit scripts with the configuration macros was extensively used and the functionality was repeatedly verified. In the event of network failures, operations
Isocore Internetworking Lab
14
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
scripts are used to detect the failure and recommend what steps should be taken to recover from the network anomaly. The commit script which is one of the most important parts of the Juniper Networks MPLS PnP helped us in repeatedly using the same configuration template on multiple nodes. Commit script is executed every time configuration change is committed on the JUNOS CLI, and during this process it verifies configuration rules. During the test in addition to commit scripts we used macros, which allowed creating customer configuration syntax which simplifies the provisioning of Ethernet services. This macro is used as input to the commit script for generating standard JUNOS configuration statements which are not part of the main configuration. Juniper Networks MPLS PnP solution supports Extensible Stylesheet Language Transformations (XSLT), or Stylesheet Language Alternative syntax (SLAX). The XSLT, and SLAX scripts are based on Juniper XML API and the JUNOScript API. Figure 10 shows parts of the output of a VPLS commit script and the associated macro that was used in the testing. This script builds VPLS instances based on the following apply-macro layout * * routing-instances { * apply-macro config-vpls-cust-x { // 'x' value to determine RT and RD; must be globally unique * ce-int1 ge-1/0/0.512; // mandatory to have at least one * ce-int2 ge-2/0/0.512; // optional * ce-int3 ge-3/0/0.512; // ... and so on * } * Sample configuration used in the test is the output associated with the above macro * * vpls-cust-1 { * instance-type vpls; * interface ge-5/0/2.1; * route-distinguisher 10.10.10.141:1; * vrf-target target:100:1; * protocols { * vpls { * site pe-141-cust-1 { * site-identifier 141; * interface ge-5/0/2.1; * } * } * } * }
Figure 10: Commit script macro and sample configuration created for VPLS Operation Scripts, similar to the commit scripts, are either written in XSLT or SLAX scripts format. The MPLS PnP uses operation scripts to automatically diagnose and recommend issues to any problems. During the test three operation scripts used to verify the status of routing protocols, LSP states and Ethernet Services for monitoring the operational state of the node under test. Figure 11 shows a snapshot of the LSP-test operation script when the interfaces are up and when the core facing interfaces are disabled. The operation scripts were used by issuing the names of the script file on the JUNOS CLI under the “systems scripts op” hierarchy level or directly using the “run” command as shown in figure 11. Operation scripts can also be used to generate changes to the router configurations depending on the output of the operation script. However, this was not tested as part of this test. Only execution of the operation script within the context of detecting the events was verified. Based on the results observed, Isocore confirms the utility and importance of using operation scripts as it allows automating the network troubleshooting and network management.
Isocore Internetworking Lab
15
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________ ----Snapshot of execution snapshot of an operation script, when the links are up--lab@MX480-R141# run op lsp-test lsp-name R141-R142 egress-interface ge-5/0/0.0 Validating LSP Name -Valid LSP Checking the status of the LSP -LSP is up Checking the status of the Egress Interface -Egress interface is up Validating that a /32 route exists for the LSP endpoint -Valid route exists for LSP endpoint Pinging LSP Endpoint (standard) 10.10.10.142 -Ping Successful! Checking OSPF status on egress interface: ge-5/0/0.0 -OSPF is up on egress interface with a state of "Full" Verifying that OSPF traffic engineering is enabled -TE is enabled Verifying RSVP is enabled on egress interface -RSVP is enabled Checking whether MPLS is configured on Egress Interface -MPLS configured on egress interface ----Snapshot of execution snapshot of an operation script, when the links are down--lab@MX480-R141# run op lsp-test lsp-name R141-R142 egress-interface ge-5/0/0.0 Validating LSP Name -Valid LSP Checking the status of the LSP -LSP is down Checking the status of the Egress Interface -Egress interface is down Validating that a /32 route exists for the LSP endpoint -No route for endpoint Pinging LSP Endpoint (standard) 10.10.10.142 -Ping Failed Checking OSPF status on egress interface: ge-5/0/0.0 -OSPF not up on egress interface Verifying that OSPF traffic engineering is enabled -TE is enabled Verifying RSVP is enabled on egress interface -RSVP down on egress interface Checking whether MPLS is configured on Egress Interface -MPLS configured on egress interface
Figure 11: Operation Scripts used in the test
Isocore Internetworking Lab
16
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
2.4
VERIFICATION OF RAPID ACTIVATION OF ETHERNET SERVICES USING MPLS PLUG-AND-PLAY MECHANISM
The objective of this test was to measure the approximate time that MPLS PnP takes to activate an endto-end Ethernet service and pass the traffic across it. This time was then compared with the time required to type in all the CLI commands to activate the same service. Two methods that were used to determine the service activation times are as follows– 1. Using the system event logging to confirm the time when the initial macro statement or the CLI command to enable a service was applied and service became operational. The total time lapse between the two events is the provisioning time. No data verification involved, only the time stamps in the system log file used. 2. Using the traffic forwarding across the data plane to determine the approximate time required to activate the service until sent traffic rate equals the received traffic rate. Table 1 summarizes all the activation times observed during this test by using both above methods. One needs to consider the human factor when service was activated using CLI commands considering how fast an operator enters the CLI commands based on which the actual time may be more or less than measured and provided in the table. The variation could be more as the number of CLI commands increases. The time provided in Table 2 is the actual time measured during our tests and may be subjected to minor variation 1 . The Table 2 only provides the actual measured time for an average operator with average typing speed. All times are measured across a 6 node testbed shown in Figure 1, but the commands are issued on one node to make the service operational. Table 2: Observations for Service Activation Times for Enabling Ethernet Services
Service Type Configuring Full Mesh L2VPN Configuring Point-to-Point L2VPN instance via macro Configuring VPLS instance via macro Service Activation for a Point to Point L2VPN Ethernet Service using traffic lost as time to activate the service. Refer figure 12.a Service Activation for a VPLS instance using traffic lost as time to activate the service. Refer figure 12.b.
Total Measured time (seconds)
No. of CLI commands issued
Using Macro (MPLS PnP)
Using CLI
Using Macro (MPLS PnP)
Using CLI
60
262
4
22
40
195
2
12
30
210
1
12
36
NA
2
NA
31
NA
1
NA
Measurement type Time stamps in the system log file Time stamps in the system log file Time stamps in the system log file Time for which the traffic is lost, from provisioning to activation
Time for which the traffic is lost, from provisioning to activation
The comparison offered by the results in Table 2 confirm that MPLS PnP saves the provisioning times significantly over manually configuring the Ethernet services in addition to reducing the number of 1
The time measured in other tests may be less or more depending upon how fast the operator enters the command. The numbers are provided for reference and does not confirm or set guidelines of minimum or maximum time frame within which a service will be activated. These are actual measured times during our test and are subjected to human typing speed.
Isocore Internetworking Lab
17
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
configuration errors introduced by the human factor. The times observed during the test and provided in the Table 2 are per platform basis made on one of the DUT ((R-141) in the testbed shown in Figure 1. As the number of the edge nodes increases in the network the provisioning times tend to increase as well in case of the manual CLI configurations. MPLS PnP simplifies the configurations since same macro templates and commit scripts are applied to the multiple nodes using unnumbered Ethernet interfaces thus reducing the provisioning time in the large metro Ethernet networks. Furthermore it reduces the risk of configuration errors, hence minimizing the troubleshooting times. Figure 12.a. Service Activation times for P2P L2VPN Service
Figure 12.b. Service Activation times for a VPLS Instance
Figures 12.a and 12.b represent the traffic graphs captured from Agilent N2X, show the time to deactivate a service followed by activation of a VPLS instance and a L2VPN point to point Ethernet service on the node R-141.
3 CONCLUSION Based on this evaluation, it is clear that Juniper Networks MPLS Plug-and-Play solution offers a complete end-to-end dynamic provisioning model which saves provisioning time by shortening the number of steps needed to activate a service, and safeguarding the provisioning process from configuration errors by using a combination of macro templates and commit scripts. MPLS plug-and-Play was extensively tested in this effort for configuring MPLS traffic engineered LSPs, provisioning multipoint and point-to-point metro Ethernet services without dealing with the design and planning of IP addressing schemes, routing protocols, and eliminating configuration errors through the automation offered by commit scripts. Furthermore, verification of capability of operation scripts within the context of MPLS plug-and-Play in this test confirmed the automatic end-to-end management of metro Ethernet networks is a reality and can be deployed in a carrier-class environment. During the testing period many scenarios and iterations were carried out confirming the capabilities of Juniper Networks MPLS Plug-and-Play solution. A large testbed was built for this effort to ensure whether the tested solution is deployable in a realistic environment. The testing confirms that flexibility offered by the unnumbered interfaces coupled with the combination of commit and operation scripts really brought the advantages of MPLS as the transport technology and plug-and-play capabilities of Ethernet together to simplify the roll out of carrier-class metro Ethernet networks with minimal configuration overheads. The consistency of results observed in many iterations and the stability offered by the alpha level JUNOS code used in this test is worth mentioning. To summarize, Isocore feels comfortable in stating that the elaborate feature set offered by Juniper Networks MPLS Plug-and-Play solution brings together the best of the hardened MPLS technology and Ethernet, thus simplifying the provisioning and deployment of metro Ethernet networks in a true carrierclass environment.
Isocore Internetworking Lab
18
Isocore Verification of Juniper Networks MPLS Plug-And-Play Solution - Summary Report _______________________________________________________________________________________________
4 LIST OF ABBREVIATIONS MPLS PnP JUNOS FRR GigE L2VPN VPLS LAN Op ESR MSER LSP N-PE
Multiprotocol Label Switching Plug-and-Play Juniper Operating Systems Fast Reroute Gigabit Ethernet Layer 2 Virtual Private Network Virtual Private LAN Service Local Area Network Operation Script Ethernet Service Router Multi-Service Edge Router Label Switched Path Network Provider Edge (Routers)
Isocore Internetworking Lab
19
