Simulating realistic network environments for scalability testing with IXIA’s IxNetwork

Testing of new systems has become a crucial element in scalable and complex network architectures. This is why we at Xantaro have always invested in the testing capabilities of our famous XT³Lab located in Frankfurt. Our lab allows us to simulate our customers’ complex network scenarios or to test latest technologies before they implement them in their production networks. Besides customer projects, extensive testing enables us to research innovations and provide our customers with vendor-independent advice. Therefore, we can develop best solutions that meet our customers’ requirements and uncovers pitfalls, for example, concerning scalability.

Testing means more than generating packets

Generating packets to test data plane functionality is not usually a complicated process, and there are a plethora of tools available to do this up to a specific scale with standard x86 hardware. But when it comes to testing control plane functionality, it becomes much more complicated, and these complex scenarios require more than Layer 2 or Layer 3 packet generation. Testing scalability of protocols like BGP, ISIS or RSVP on routing platforms that support millions of routing entries is an excellent example.

The pinnacle of Layer 2 or Layer 3 testing is the combination of both, control and forwarding plane testing. Imagine a scenario, where you need to test a new software release for an MPLS PE device. The production device may hold millions of routing entries that it gets from the core network via BGP from other PE routers. Additionally, it uses an IGP like OSPF or ISIS to learn how to reach these PE routers and a label distribution protocol like LDP, RSVP or SPRING to build label-switch paths to these destinations.

Critical: Testing conditions as realistic as possible

For reliable test results, it is essential to consider the entire network environment of the Device Under Test (DUT) as realistically as possible. Typically, it is too expensive to do this with physical hardware. Using virtual appliances can help to simulate an accurate topology, but testing at a large-scale in both control and data plane is usually not possible.

Imagine how great it would be to have a tool available that could simulate a whole provider’s network on one physical port and an access network with customers on another physical port. Such a program should be able to generate a bunch of PE routers that advertise prefixes and at the same time send traffic from these prefixes, with the correct MPLS labels to our DUT. Once the packets leave our DUT towards the access network, our testing tool should be able to verify if all packets are received and if there was a loss, identify which services were affected.

Simulating complex network environments with IxNetwork

Fiction? No, because in our XT³Lab, we operate a 100G-capable testing environment, which exactly meets these requirements. The key element of our solution is IxNetwork, the network infrastructure testing tool of our technology partner IXIA. Many tests have already been successfully fulfilled using our solution – whether in our XT³Lab or on-site at the customer. Our test experts also tested new platforms such as the Arista Networks R-series.

The following will introduce the opportunities presented by generating a network environment based on customers and whole provider’s networks via IxNetwork:

a) Simulating customers

Let’s start by simulating customers’ CPE. We will use a single physical port with 100 VLANs, 100 IP Addresses, 100 BGP Sessions, and 100 Network Ranges, each propagating ten prefixes. The graphic below shows the user interface of IxNetwork with the corresponding visual CPE setting.

Upon completion, we notice that IxNetwork is simulating 100 customers, each with ten prefixes, a total of 1000 BGP Prefixes. As the CLI output from our Juniper MX480 router shows, the DUT will put the routing entries into the correct VRF based on the incoming interface:

xuser@friedberg> show bgp summary 
...
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.100.1.2                1        163        301       0       1     1:20:01 Establ
  VRF-1.inet.0: 10/10/10/0
10.100.2.2                2        164        304       0       1     1:20:03 Establ
  VRF-2.inet.0: 10/10/10/0
...

b) Simulating the whole provider’s network

Creating the core facing network environment is a bit more complicated. We use two physical ports here to simulate two P routers that communicate via ISIS, LDP, and BFD with our DUT. We generate 50 PE routers, which are behind the P routers with 100 VRFs, which correspond to the 100 customers on the other side. Each VRF will send out 50,000 Prefixes, so our DUT has to learn 5 million prefixes from the network core and program them on the line card.

During this test, we can check whether the system stays stable and what the memory utilisation looks like after the device learned all routes.

xuser@friedberg> show route summary table bgp.l3vpn.0    
Autonomous system number: 64512
Router ID: 10.255.255.1

bgp.l3vpn.0: 5000000 destinations, 5000000 routes (5000000 active, 0 holddown, 0 hidden)
                 BGP: 5000000 routes, 5000000 active

As we can see in the CLI output above, the router successfully loaded all prefixes. Therefore, control-plane scaling seems to be okay. Now we create some traffic items that will send bi-directionally between all the prefixes to test reachability.

Now imagine, that we see packet loss for one of the services and want to troubleshoot this further. We create a new traffic item for the specific faulty service and enable tracking of the destination IP address. The screenshot below displays the resulting prefixes overview, which indicates that traffic up to prefix 20.0.151.18 is working fine, but for 20.0.151.19 and higher, we have 100% packet loss. This information allows us to troubleshoot the problem further and efficiently identify the cause.

Xantaro_IXIA_IxNetwork_3

Test environment and expertise for reliable test results

Due to the complexity, it is not always possible to simulate the complete network of a customer. However, the demonstrated approach makes it possible to simulate large parts of the network infrastructure by minimising the use of physical devices.

This blog gives you a short introduction into the possibilities of our network test environment. If you are interested in this kind of testing or other test options, we are happy to discuss your requirements.