How we did it

We tested the Nortel Contivity 1740 with the SSL VPN Module 1000 in both our Westlake Village, Calif., and Tucson, Ariz., labs. In Westlake Village, David Newman focused on SSL VPN performance testing. In Tucson, Joel Snyder checked out compatibility with applications and usability of the SSL VPN module.

In the performance tests, we measured SSL setup and teardown rate, maximum concurrent users and forwarding rate.

To measure SSL setup and teardown rate, Nortel remotely configured the Contivity 1740 that included Nortel's SSL VPN Module 1000 with 1,000 local user accounts.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

We tested the Nortel Contivity 1740 with the SSL VPN Module 1000 in both our Westlake Village, Calif., and Tucson, Ariz., labs. In Westlake Village, David Newman focused on SSL VPN performance testing. In Tucson, Joel Snyder checked out compatibility with applications and usability of the SSL VPN module.

In the performance tests, we measured SSL setup and teardown rate, maximum concurrent users and forwarding rate.

To measure SSL setup and teardown rate, Nortel remotely configured the Contivity 1740 that included Nortel's SSL VPN Module 1000 with 1,000 local user accounts.

We attached an Avalanche client emulator and Reflect or server emulator, both from Spirent Communications, to the Contivity box with Gigabit Ethernet copper interfaces. We attached all systems using a Foundry Networks 12GCF Layer-2 copper Gigabit Ethernet switch, and configured two virtual LANs on the Foundry switch - one each for the trusted and untrusted sides of the Contivity 1740.

For all tests, Avalanche emulated Microsoft Internet Explorer clients and Reflector emulated Microsoft Internet Information Server servers. Both clients and servers used HTTP Version 1.1, with persistence enabled.

We configured the Avalanche to emulate more than 64,000 unique source IP addresses. Each client would attempt to request a 1K-byte object from Reflector, first logging on using one of the user accounts set up on the Contivity.

The Avalanche iterated randomly over the 1,000-user account list, rolling back to the first account when it had gone through 1,000 source IP addresses. We chose this test to determine how quickly the Contivity's SSL module would set up and tear down SSL connections.

The test ran in steady state for 60 seconds. By using different load specifications on Avalanche, we determined the maximum rate at which Contivity could set up and tear down SSL sessions (see Terminology sidebar for further discussion of this term) with no failures.

For the maximum concurrent users test, we configured Reflector to return the first object immediately (to validate the test was working), and then to wait 60 seconds before returning each subsequent object. This delay built up a large number of pending requests, and therefore increased the number of concurrent logons the Contivity would need to maintain state for.

For the forwarding rate test, we configured Avalanche to request 5M-byte objects from Reflector. This object size is far larger than the typical average object size of 1K byte, and thus represents a practical upper limit of the rate at which an SSL-enabled device can forward traffic.

Avalanche reports real-time results in 4-second increments. To determine forwarding rate, we averaged rates for the final 60 seconds of a 120-second steady-state phase. We also used progressively larger numbers of users to determine the maximum user count with no failures.

For compatibility testing and usability testing, we installed the Contivity 1740 with the SSL VPN 1000 Module in our Tucson testbed. We started by configuring the Contivity to talk to a variety of applications. An Intel-based server with dual 2.8-GHz CPUs and 4G bytes of memory was used to host a small variety of servers and applications, including Microsoft Exchange 2003, IPSwitch What'sUp, Cisco Call Manager, NetScreen Manager, and several home-grown JavaScript, Java and Flash-based applications. We used VMware's ESX server to host all these applications.