Library: Test Plans
MPLS L3 VPN Testing
Overview
The L3VPN test plans presented here include functional and performance tests designed for network and QA engineers testing L3VPN/RFC 2547-enabled devices. RFC 2547 VPNs are a key application for MPLS technology and must be thoroughly validated and tested against the device or system under test prior to deployment. These tests are intended as a baseline for L3VPN testing with further customization a natural step forward.
VRF Isolation and Scalability Test
Objective
This test verifies a DUT's capabilities for VRF isolation with multiple CEs, each with similar prefix advertisements. The test utilizes an IGP advertising a fixed prefix for each CE router. The device then forwards traffic to and from a CE pair in the same VRF. Verification includes counting received frames and ensuring that no cross talk has taken place. Scalability can then be achieved by increasing the number of CEs.
Figure 1. VRF isolation scalability test.
Setup
A minimum of two network connections is required from the test tool to the DUT - one port will emulate multiple CEs with each CE part of a different VRF. The second port will match the first port by advertising multiple CEs, each from a different VRF. The DUT is configured with a trunk 802.1q VLAN interface with a separate VLAN for each VRF instance.
Input Parameters
| Parameters |
Description |
| Route Distinguisher (RD) |
Route Distinguishers are used primarily to distinguish routes especially in overlapping VPN scenarios. The Route Distinguisher is made up of two parts, the "Admin part" and "AS number". |
| Route Targets Import/Export |
Route targets are appended to prefixes to establish destination VRFs and for import/export policies. This is applied to VPN prefixes to allow for import to other receiving VPN instances. |
| IGP/MPLS protocol |
IGP is the interior gateway protocol used to distribute the loopback address, and the MPLS protocol is used for signaling the LSP to destination loopback. |
Table 1. VRF isolation scalability test parameters.
Methodology
- CE tester port 1 brings up an IGP or customer speaking protocol advertising prefixes. The control plane is established; a peer or neighbor is adjacent representing a customer site or VPN acting CE. Figure 2 shows an example configuration of IGP and MPLS protocol.
- CE tester port 2 is configured similar to step 1 with CE emulation advertising a unique set of prefixes to the DUT.
- The tester sends traffic to each prefix advertised in the VRF from each emulated CE.
- Adding emulated CEs from the test tool protocol configuration scales this test. The configuration is matched on the DUT. Pairs of CEs are added to increase the VPN number and scale.
- Inject traffic flows to verify that each route is available as the test is scaled. Increase the number of CEs in the test until the desired size of network is successfully achieved.
Figure 2. L3 VPN CE router wizard configuration.
Results
The success of the result depends on the desired size of the network. A positive result will be received flows for traffic at specified rates or number of frames sent/received. Each CE should receive traffic based on the prefix it advertises. This can be done with verification of total frames received or a continuous rate test. Figure 3 shows four CEs - two from one VRF, the other two from a separate VRF. Each pair of CEs advertise identical routes, but from different VPNs. The DUT in this case has two identical route prefixes but must keep them separate. The graph in Figure 3 shows consistency with frames sent and received. No one CE is receiving more than its intended transmitter is sending it.
Figure 3. VRF isolation scalability test- results confirmation in graph.
Route Reflector PE Scalability Test
Objective
Confirm the number of configured PEs that a DUT can peer with and maintain the ability to reflect routes.
Setup
The test requires two tester ports - one to transmit traffic and one to receive. The transmit direction of traffic is unidirectional. Test port 2 is used to advertise the PE route-reflector clients, while test port 1 sends traffic to verify the advertised prefixes (Figure 4). During the test, tester port 2 increases the number of advertised PEs each with new NLRI. Ixia's new L3 VPN wizard utility in software release IxOS 3.80 can accomplish this setup with minimal configuration steps. Routes can be verified with flows of traffic streams from Ixia's automated traffic generator utility.
Figure 4. Route reflector PE scalability test topology
Input Parameters
| Parameters |
Description |
| Route Reflector |
If tested the DUT can be configured as reflector to all IBGP peers. |
| Tunnel Endpoint |
Ultimate tunnel destination for peering session, usually the device being tested loopback address. |
Table 2. Route reflector PE scalability test parameters.
Figure 5. L3VPN configuration wizard.
Methodology
- Tester port 1 emulates a single PE and establishes a session with the DUT PE. This port is also used as the traffic generator and for confirming reflected routes.
- The second port will be an 802.1q trunk with a separate VLAN-per-PE relationship. The control plane is established here, and the configured number of PEs is established, each with an L3 site. Each PE emulated by the test tool is advertising a number of prefixes to be reflected by the DUT. Figure 5 shows the Ixia wizard configuration for PE-specific parameters.
- The tester generates traffic streams sourced from tester port 1 with a destination of each PE's advertised prefixes on tester port 2.
- The number of PEs on tester port 2 is scaled and traffic flows re-run to all prefixes to include the additional PEs' route advertisements.
Results
A successful result during any given iteration is confirmation of the routes received on the single PE tester port 1 for all reflected routes in the VPN. To further verify that the DUT is able to forward at a given rate and to test the data plane, the received flows of traffic destined to each PE's prefix must be verified. Ixia's IxExplorer Learned VPN Routes view indicates the number of routes learned by tester port 1, and the IxExplorer Statistics and Latency views can be used to verify per flow received statistics. This information is useful for determining the MPLS forwarding capability to each prefix regardless of PE. Statistics can be filtered by the destination MAC, providing an individual PE received count.
Figure 6. Route reflector PE scalability test - BGP routes received statistics.
Figure 7. Route reflector PE scalability test - frames received per emulated PE.
Ingress/Egress Forwarding Performance Test
Objective
Determines the maximum rate at which a Label Switched Router (LSR) configured as a L3 VPN Provider Edge (PE) node can strip/pop or apply/push MPLS labels to and from incoming IP packets. The resulting throughput of this operation is then measured to the point of no loss.
Setup
This test requires two ports; one to simulate the PE router and another to simulate the customer edge (CE) router. Ixia's IxScriptMate application can be used to execute this test.
Figure 8. Ingress/egress forwarding performance test setup.
Input Parameters
| Parameters |
Description |
| OSPF Parameters |
Area ID and network type, Prefix/Mask information. |
| BGP parameters |
AS number, Peer address, Prefix/Mask information. |
| # Routes per CE |
Defined amount of routes for each CE to advertise. |
| Traffic rate |
Desired rate to send traffic to be popped or pushed. |
Table 3. Ingress/egress forwarding performance test input parameters.
Figure 9. IxScriptmate ingress/egress forwarding performance test configuration.
Methodology
- The port simulating the PE/P router establishes an IGP session with the DUT and advertises the loopback address of the simulated PE router. Traffic engineering parameters are advertised using OSPF-TE, IS-IS-TE, or LDP protocols.
- Bi-directional LSPs are established using RSVP-TE or LDP.
- A multi-protocol internal BGP (MP-iBGP) session is established with the DUT.
- The port simulating the PE router transmits MPLS traffic at the specified rate; if frame loss occurs, the transmission rate is alternately reduced/increased using a binary search algorithm to determine the maximum rate at which the DUT can forward traffic without loss.
Results
The test results given by Ixia's IxScriptmate will reflect and produce successful transmit rate, latency of the MPLS traffic popped/pushed, data errors in payload, and sequence errors. Figure 10 shows example test results.
Figure 10. IxScriptmate ingress/egress forwarding performance test results
VPN Merging Test
Objective
This test determines a PE's ability to import different VPNs to a single VPN by running traffic flows and verifying received statistics for each VRF instance.
Setup
This test requires at least two tester ports. Tester port 1 acts as a CE for traffic generation to all VPN routes learned while tester port 2 emulates a group of PE routers, each from a different VRF/VPN advertising unique prefixes. The DUT PE receives all routes and merges them into one common VPN to distribute to tester port 1.
Figure 11. L3 VPN merging test topology.
Input Parameters
| Parameters |
Description |
| PE configuration |
Number of PEs, loopback determination, route reflector address configuration. |
| VRF configuration |
Includes number of VRFs per PE, import/export definitions, and prefix advertisements. |
| P router setup |
Defines the IGP and signal protocol used to build local adjacency and learn the outer MPLS label. |
Table 4. L3 VPN merging test parameters
Methodology
- Tester port 1 advertises a CE device sending traffic to several destinations from the merged VPN.
- Tester port 2 advertises a configured number of PEs, each with a given amount of VRF sites. These site prefixes should be confirmed in the DUT's forwarding table for each VRF instance.
- The VRF instances are merged to one common VPN. This VPN is on the tester port 1 VRF, where traffic is being sent to each destination. Figure 11 shows Ixia VPN wizard configuration for VRF setup section. Each parameter is configured in the wizard setup pertaining to P, PE, and VRF specifics.
- Start traffic flows from the tester port 1 port and confirm the delivery of the flows on a per PE or VRF basis.
Figure 12. L3 VPN merging test VRF wizard configuration.
Results
The expected results of this test plan are confirmation that the desired rates of traffic being received on a per VRF basis. The results of this test can be viewed via the IxExplorer GUI interface. Figure 12 shows an example graph of received frame rates for each VRF being emulated by the Ixia protocol server. The correct result is each VRF receiving the same amount of total frames during the test.
Figure 13. L3 VPN merging test results graph.
[ back | top of page | back to test plans ]
Social Media