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.

Whitepapers

• Selecting Effective Virtual Directories
• A Modern Approach to On-Demand Email and Data Security
• Best Practices for HP Servers and HP Enterprise Virtual Array in a Microsoft Exchange
• Compliance, Protection, Recovery: A Layered Approach to Laptop Security
• Endpoint Security: Data Protection for IT, Freedom for Laptop Users
• IT Departments on Data Security: A Research Concepts Survey

View more SECURITY whitepapers

Webcasts

• Key Considerations for a Successful 802.11n Deployment
• Solutions to the Toughest IT Challenges in Remote Offices
• Lowering the Cost of Email Archives
• High Availability for SQL Server 2005 Using Array-Based Replication and Host-Based Mirroring Technologies
• Technical Overview of Exchange Server 2007 with HP Servers and Storage
• Bringing Order and Security to your Mobile Workforce: Corporate Mobility Policy and Device Management On-Demand

View more SECURITY webcasts

Special Reports

• The Evolution of Network Security
• Taking Virtualization Up a Notch
• Learn how to Keep your Mobile Workforce Connected
• The self-managed network

View more SECURITY special reports