How we did it

How we tested the Inkra 1518TX Virtual Service Switch.

We used Spirent Communications’ Avalanche and Reflector load-testing appliances to generate HTTP traffic across the Inkra 1518TX chassis.

Our core testing profile presented a load of HTTP transactions to the Inkra chassis. Each HTTP transaction had three parts: the TCP handshake to establish the connection, an HTTP GET to retrieve either 1K or 32K bytes of data, and the TCP handshake to close the connection. We ran two sets of benchmarks for every configuration: one with 1K Web pages, the other with 32K Web pages. In each test, we gradually increased the load of HTTP transactions per second to the Inkra chassis until the chassis was unable to handle the offered load, as evidenced by a transaction completion rate significantly lower than the offered load (more than 100 transaction/sec lost measured over a 5-second interval).

We presented early results of the performance tests to Inkra and asked it for performance-tuning advice, and we followed its advice in reconfiguring the chassis. All reported performance numbers include Inkra’s tuning advice.

We ran each test three times and averaged the results. We also discarded one test run that showed some anomalous statistics. All other tests had substantially similar results.

During VPN testing, we used 100M bit/sec Fast Ethernet interfaces and looped the traffic through the Inkra chassis twice. This helped to ensure VPN interoperability by building an Inkra-to-Inkra tunnel. All VPN numbers have been doubled to recognize that the system processed the traffic twice. Before the VPN testing, we ran a “pre-test” to give the Inkra chassis time to establish the VPN tunnels.

During firewall and intrusion-prevention testing, we switched from the 100M bit/sec Fast Ethernet interfaces to fiber-based Gigabit Ethernet to measure performance that we hoped would be well above 100M bit/sec. Because the 1518TX chassis only has two Gigabit Ethernet ports, we did not loop the traffic through the chassis as we did in the VPN testing.

In configuring the firewall, we used one rule to pass the specific traffic we used for testing. We did not enable malicious URL filtering. All other traffic was denied. In configuring the intrusion-prevention system, we used a default rule set provided to us by Inkra with 89 policies. For VPN configuration, we created one tunnel with AES-128/SHA-1 encryption and authentication parameters. We couldn’t configure the VPN tunnel to use a more common (but less secure) Triple-DES encryption because of bugs in the configuration system.

Results of our VPN performance tests gave a maximum throughput of 15,160K bit/sec (about 210 transaction/sec) with combined firewall, VPN and intrusion prevention. In this case, the firewall was on the inside of the VPN, so it saw the traffic in unencrypted form.

Results of our firewall plus intrusion-prevention tests appear in the table below:

Back to review: Inkra’s 1518TX