OfficeConnect Secure Router and OfficeConnect VPN Firewall - Screening Router and Firewall from 3Com

Performance tests

We used the following testing method.

1. LAN-WAN segment performance, NetIQ Chariot

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

Both devices demonstrate good routing performance between the LAN-WAN segments. Of course faster speed would be better, but 25Mbit (one way) is more than enough for the most tasks (find 30Mbit DSL modems).

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

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

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

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

You can see the similar picture with smaller packet sizes.

2. LAN-WAN segment performance, NetPIPE

NetPipe: data transfer speeds between the LAN and WAN segments with different packet sizes (maximum - 48.8Mbit/sec).
3CR870 router

NetPipe: data transfer speeds between the LAN and WAN segments with different packet sizes (maximum - 49.28Mbit/sec).
3CR860 router

The NetPipe utility test did not reveal any anomalies, but the speed of both devices equalized (the high speed dropped, the low speed, on the contrary, rose).

3. IPSec performance

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 Core 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 Algorithm: SHA1
Exchange Key Using: DH-5 (1536-bit)
Use Prefect Security: off

3.1 IPSec performance, DES encryption

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

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

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

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

Looking at these figures and graphs you may notice two interesting points:

Data transfer speed from 3Com routers to the computer under Gentoo Linux is slower than in the opposite direction.
DES encryption speed is the same in both devices.

3.2 IPSec performance, 3DES encryption

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

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

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

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

The same picture. The speed dropped a little, but it is still up to the mark. Both observations (data transfer speed is different for the two directions and the performance of both devices is the same) remained.

Then, in order to clarify the strangely different figures in DES/3DES performance for bidirectional transfers between 3Com - Linux computer, I have established an IPSec 3DES tunnel between the two 3Com devices and tested its speed. Thus we exclude the computer under Gentoo Linux from our test (in case it corrupts something).

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

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

No, the problem was obviously not with the IPSec implementation in Linux. Even working with each other the 3Com routers demonstrate the speed three times as slow.

3.3 IPSec performance, tunnel scaling, 3DES encryption, two tunnels

One tunnel is good, but what will happen when we load our routers with two tunnels simultaneously (the device will terminate two IPSec 3DES tunnels). Let's see.

1. 3CR870 tests.

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR870 unit, Throughput.scr
two tunnels, half duplex mode (either "only there" in two tunnels or "only back")

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR870 unit, Throughput.scr
two tunnels, full duplex mode (the data is transferred along both tunnels in both directions simultaneously)

2. The same tests for 3CR860.

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR860 unit, Throughput.scr
two tunnels, half duplex mode (either "only there" in two tunnels or "only back")

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR860 unit, Throughput.scr
two tunnels, full duplex mode (the data is transferred along both tunnels in both directions simultaneously)

What conclusion can we draw from this situation? Both devices demonstrate the overall performance in the IPSec-3DES mode of about 10Mbit. When a number of tunnels grows, the data flow is divided proportionally.

Out of sheer curiosity we have carried out several more tests with two 3DES IPSec tunnels in 3CR870. In these tests the data transfer along tunnels does not start simultaneously but with a 30 seconds' delay.

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

Tunnel 1, 3Com -> Gentoo transfer
Tunnel 2, 3Com -> Gentoo transfer
Tunnel 1, Gentoo -> 3Com transfer
Tunnel 2, Gentoo -> 3Com transfer

Or in other words, at first both tunnels were operating in the half duplex mode, and then - in full duplex.

In the latter case, we changed the starting order of tests:

Tunnel 1, 3Com -> Gentoo transfer
Tunnel 1, Gentoo -> 3Com transfer
Tunnel 2, 3Com -> Gentoo transfer
Tunnel 2, Gentoo -> 3Com transfer

That is Tunnel 1 started the first, then it switched to full duplex, then Tunnel 2 started, and only then the second tunnel switched to full duplex.

The first sequence of tests

The second sequence of tests

And again the situation is similar to the previous one - overall IPSec performance is divided approximately equally among all the existing tunnels.

3.4 IPSec performance, tunnel scaling, 3DES encryption, three tunnels

Only 3CR870 is capable of three and more tunnels. We didn't test more than three tunnels.

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR870 unit, Throughput.scr
three tunnels, half duplex mode (either "only there" in three tunnels or "only back")

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR870 unit, Throughput.scr
three tunnels, full duplex mode (the data is transferred along the three tunnels in both directions simultaneously)

And to conclude this section about tunnel scaling, we carried out two more tests, similar to the tests for two tunnels (data transfer does not start simultaneously, but with a 20 seconds' delay).

At first the tunnels operated in half duplex mode and then they switched to full duplex.

Tunnel 1 starts a unidirectional transfer then it switches to full duplex, then the second tunnel starts, then Tunnel 2 switches to full duplex, then goes the third.

The situation confirms our previous observations. The channels are divided equally.

3.4 IPSec performance, AES-128 encryption

Unfortunately, we didn't manage to cross the AES-128 implementation of IPSec in Linux with the 3Com devices, Racoon would display the following error:

INFO: respond new phase 1 negotiation: 192.168.0.2[500]<=>192.168.0.1[500]
INFO: begin Identity Protection mode.
DEBUG: begin.
DEBUG: seen nptype=1(sa)
DEBUG: seen nptype=13(vid)
DEBUG: succeed.
DEBUG: received unknown Vendor ID
DEBUG: total SA len=48
 DEBUG: 00000001 00000001 00000028 01010001 00000020 01010000 80010007 80020002
80030001 80040005 800b0001 800c0258
DEBUG: begin.
DEBUG: seen nptype=2(prop)
DEBUG: succeed.
DEBUG: proposal #1 len=40
DEBUG: begin.
DEBUG: seen nptype=3(trns)
DEBUG: succeed.
DEBUG: transform #1 len=32
DEBUG: type=Encryption Algorithm, flag=0x8000, lorv=7
DEBUG: encription(aes)
DEBUG: type=Hash Algorithm, flag=0x8000, lorv=SHA
DEBUG: hash(sha1)
DEBUG: type=Authentication Method, flag=0x8000, lorv=pre-shared key
DEBUG: type=Group Description, flag=0x8000, lorv=1536-bit MODP group
DEBUG: hmac(modp1536)
DEBUG: type=Life Type, flag=0x8000, lorv=seconds
DEBUG: type=Life Duration, flag=0x8000, lorv=600
DEBUG: pair 1:
DEBUG: 0x80b0bb0: next=(nil) tnext=(nil)
DEBUG: proposal #1: 1 transform
DEBUG: prop#=1, prot-id=ISAKMP, spi-size=0, #trns=1
DEBUG: trns#=1, trns-id=IKE
DEBUG: type=Encryption Algorithm, flag=0x8000, lorv=7
DEBUG: type=Hash Algorithm, flag=0x8000, lorv=SHA
DEBUG: type=Authentication Method, flag=0x8000, lorv=pre-shared key
DEBUG: type=Group Description, flag=0x8000, lorv=1536-bit MODP group
DEBUG: type=Life Type, flag=0x8000, lorv=seconds
DEBUG: type=Life Duration, flag=0x8000, lorv=600
DEBUG: Compared: DB:Peer
DEBUG: (lifetime = 28800:600)
DEBUG: (lifebyte = 0:0)
DEBUG: enctype = 7:7
DEBUG: (encklen = 128:0)
DEBUG: hashtype = SHA:SHA
DEBUG: authmethod = pre-shared key:pre-shared key
DEBUG: dh_group = 1536-bit MODP group:1536-bit MODP group
DEBUG: type=Encryption Algorithm, flag=0x8000, lorv=7
DEBUG: type=Hash Algorithm, flag=0x8000, lorv=SHA
DEBUG: type=Authentication Method, flag=0x8000, lorv=pre-shared key
DEBUG: type=Group Description, flag=0x8000, lorv=1536-bit MODP group
DEBUG: type=Life Type, flag=0x8000, lorv=seconds
DEBUG: type=Life Duration, flag=0x8000, lorv=600
ERROR: no suitable proposal found.
ERROR: failed to get valid proposal.
ERROR: failed to process packet.

That's why the AES encryption was tested only between the two 3Com devices (they connected with each other perfectly). And thus we didn't manage to establish more than one tunnel.

NetIQ Chariot: IPSec tunneling, AES-128 encryption, 3CR860 & 3CR870, Throughput.scr

NetIQ Chariot: IPSec tunneling, AES-128 encryption, 3CR860 & 3CR870, Throughput.scr (full duplex only)

AES-128 encryption is resource-intensive, that's why the speed slumped so much (over three times).

Navigation:

Eugene Zaitsev (eightn@ixbt.com)
11.08.2004

Write a comment below. No registration needed!