U.S.Robotics Secure Storage Router Pro (USR8200)

Performance tests

The tests were carried out according to this technique.

1. LAN-WAN segment performance, NetIQ Chariot

NetIQ Chariot: data transfer between LAN-WAN segments,
Throughput.scr, packet size=max

LAN-WAN routing performance is up to the mark.

NetIQ Chariot: data transfer between LAN-WAN segments,
Throughput.scr, packet size=512b

NetIQ Chariot: data transfer between LAN-WAN segments,
Throughput.scr, packet size=64b

Above are performance diagrams at smaller packet sizes.

2. LAN-WAN segment performance, NetPIPE

NetPipe: data transfer speed between LAN and WAN segments with packets of different sizes (maximum – 89.5Mbit/sec)

NetPipe test results are similar to the previous ones.

3. IPSec performance

USR8200 is equipped with FreeSwan 1.99 implementation of IPSec (another proof that the device uses Linux kernel from Branch 2.4).

IPSec tunneling performance was measured in the following way.

the device to be tested is placed at one end
at the other end – computer (the testbed is described in the method above) under Gentoo Linux with Kernel 2.6.7 and ipsec tools v0.3.3
a tunnel is established between them (host-host type)
Chariot endpoint-sensors are placed in the network at the 3Com end and at the end of the testbed
then we run usual traffic generation tests, which are described above

During IPSec speed benchmarks, tunnel characteristics were not modified except for the encryption type. Here is the list of these characteristics:

Tunnel Type: IPSec
Hash Algoritm: SHA1
Exchange Key Using: DH-5 (1536-bit)
Use Prefect Security: off

3.1 IPSec performance, DES encryption

NetIQ Chariot: IPSec tunneling, DES encryption, Throughput.scr

NetIQ Chariot: IPSec tunneling, DES encryption, Throughput.scr (full duplex only)

IPSec performance with DES encryption is rather high.

3.2 IPSec performance, 3DES encryption

NetIQ Chariot: IPSec tunneling, 3DES encryption, Throughput.scr

NetIQ Chariot: IPSec tunneling, 3DES encryption, Throughput.scr (full duplex only)

IPSec performance in 3DES mode is impressive.

3.3 IPSec scalability, two tunnels, 3DES encryption

In case of one tunnel, IPSec encryption in USR820 works fast. What will happen, if we increase the number of tunnels?

NetIQ Chariot: IPSec 2 tunnels, 3DES encryption, Throughput.scr

The speed dropped in each tunnel, but overall performance even increased and reached 20 Mbit/sec.

3.4 IPSec scalability, three tunnels, 3DES encryption

Let's add another tunnel (to get three tunnels).

NetIQ Chariot: IPSec 3 tunnels, 3DES encryption, Throughput.scr

Performance has not dropped in comparison with two tunnels, the speed in each tunnel keeps at 4.5 Mbit. The overall encryption performance practically reached 30 Mbit. It's a very good result.

Then we carried out a couple of tests, in which generators of traffic, transferred via three tunnels, were not started simultaneously but with a 30 seconds' delay.

In the first case the tests were started in the following order:

Tunnel 1, USR –> Gentoo transfer
Tunnel 1, USR <– Gentoo transfer
Tunnel 2, USR –> Gentoo transfer
Tunnel 2, USR <– Gentoo transfer
Tunnel 3, USR –> Gentoo transfer
Tunnel 3, USR <– Gentoo transfer

In other words, the traffic was initiated sequentially in the first tunnel (at first in half duplex and then in full duplex mode), then the second and the third tunnels were activated (to be more exact, data transfer in these tunnels) in the same manner.

In the second case, the traffic generators were started in a different order:

Tunnel 1, USR –> Gentoo transfer
Tunnel 2, USR –> Gentoo transfer
Tunnel 3, USR –> Gentoo transfer
Tunnel 1, USR <– Gentoo transfer
Tunnel 2, USR <– Gentoo transfer
Tunnel 3, USR <– Gentoo transfer

That is at first the half duplex (unidirectional) data transfer was started sequentially in each of the tunnels, after that the duplex data transfer was initiated (also sequentially) in each tunnel.

First case, NetIQ Chariot: IPSec, 3DES encryption, Throughput.scr

Second case, NetIQ Chariot: IPSec 3DES encryption, Throughput.scr

These two tests demonstrate an interesting picture: When half duplex transfers in tunnels are started sequentially, the performance of previous tunnels does not drop, at least when the number of tunnels does not exceed three.

By the way, the tests revealed a funny bug in the implementation of IPSec: if you try to activate a third tunnel when the two tunnels are already operating (exactly to activate, that is before this moment there were only two tunnels activated), the performance of some existing tunnels drops almost to zero for several seconds.

4. PPTP server performance

As USR8200 can operate as a PPTP server, we measured its encryption performance using this protocol as well.

The results were taken similar to the IPSec tests, we measured the speed in the MPPE 128-bit mode with stateful compression.

NetIQ Chariot: PPTP 2 tunnels, MPPE-128 encryption, Throughput.scr

NetIQ Chariot: PPTP 2 tunnels, MPPE-128 encryption, Throughput.scr (full duplex only)

Strange as it may seem, the speed is a little slower than in IPSec, but still high enough.

4.2 PPTP performance, two tunnels

Let's add another user (to get two working tunnels).

NetIQ Chariot: PPTP, MPPE-128 encryption, Throughput.scr (full duplex only)

The overall performance still didn't exceed 9 Mbit, and the speeds in each tunnel were distributed approximately in even shares of the overall performance.

4.3 PPTP performance, three tunnels

In this case the traffic generators were started sequentially, with 30 seconds' delay each. To be more exact, they were started in the following order:

Tunnel 1, USR –> Gentoo transfer
Tunnel 1, USR <– Gentoo transfer
Tunnel 2, USR –> Gentoo transfer
Tunnel 2, USR <– Gentoo transfer
Tunnel 3, USR –> Gentoo transfer
Tunnel 3, USR <– Gentoo transfer

NetIQ Chariot: PPTP, MPPE-128 encryption, Throughput.scr (full duplex only)

And again it didn't manage to exceed 9 Mbit. The tunnels shared the overall 9 Mbit throughput in approximately equal shares.

Navigation:

Evgeniy Zaitsev (eightn@ixbt.com)
24 August, 2004