Arial Georgia Tahoma Times New Roman Verdana

OfficeConnect Secure Router и OfficeConnect VPN Firewall — маршрутизатор с функциями защиты и брандмауэр от 3Com

Тестирование производительности

Тестирования проводится по этой методике.

1. Производительность LAN-WAN сегмента, NetIQ Chariot

NetIQ Chariot: передача данных между LAN-WAN сегментами,
Throughput.scr, packet size=max, 3CR870 router

  

NetIQ Chariot: передача данных между LAN-WAN сегментами,
Throughput.scr, packet size=max, 3CR870 router

Оба устройства обладают неплохой производительностью между LAN-WAN. Конечно, хотелось бы большего, но 25Мбит (в одну сторону) более чем достаточно, для большинства задач (найдите DSL модемы на 30Мбит).

NetIQ Chariot: передача данных между LAN-WAN сегментами,
Throughput.scr, packet size=512b, 3CR870 router

NetIQ Chariot: передача данных между LAN-WAN сегментами,
Throughput.scr, packet size=512b, 3CR860 router

NetIQ Chariot: передача данных между LAN-WAN сегментами,
Throughput.scr, packet size=64b, 3CR870 router

NetIQ Chariot: передача данных между LAN-WAN сегментами,
Throughput.scr, packet size=64b, 3CR860 router

На меньших размерах пакетов производительность обоих устройств так же примерно равна.

2. Производительность LAN-WAN сегмента, NetPIPE

NetPipe: скорости передачи данных между сегментами LAN и WAN на пакетах различной длины (максимальная — 48,8Mbit/sec).
3CR870 router

NetPipe: скорости передачи данных между сегментами LAN и WAN на пакетах различной длины (максимальная — 49,28Mbit/sec).
3CR860 router

Тест утилитой NetPipe аномалий не выявил, но тут скорость обоих устройств сравнялась (высокая — упала, низкая — наоборот поднялась).

3. Производительность IPSec

Производительность IPSec туннелирования измерялась следующим образом.

• с одной стороны ставилось тестируемое устройство
• с другой — компьютер (стендовый, описанный в методике выше) под управлением Gentoo Linux с ядром 2.6.7 и ipsec tools версии 0.3.3
• между ними настраивался туннель (типа хост-хост)
• endpoint-сенсоры Chariot ставились в сети со стороны 3Com и в сети со стороны стендового компьютера
• после чего осуществлялись обычные тесты на генерацию трафика, описанные выше

При тестировании скорости IPSec, характеристики туннелей не изменялись, за исключением метода шифрования (Encryption Type). Эти характеристики были такими:

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

3.1 Производительность IPSec, DES шифрование

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)

Глядя на эти цифры и графики, можно заметить два интересных момента:

• Скорость передачи данных от 3Com маршрутизаторов к компьютеру под управлением Gentoo Linux ниже, чем в обратную сторону.
• Скорости шифрования алгоритмом DES одинаковы у обоих устройств.

3.2 Производительность IPSec, 3DES шифрование

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)

Картина полностью аналогична предыдущей. Скорость немного упала, но все равно остается на высоте. Оба наблюдения (скорости передачи туда и обратно различаются и производительность обоих устройств равна) остались прежними.

Далее, для выяснения странно разных цифр в производительности DES/3DES туда-обратно в режиме 3Com — Linux computer был построен IPSec 3DES туннель между двумя 3Com устройствами и протестирована скорость в нем. Таким образом, мы убираем из теста компьютер под управлением Gentoo Linux (вдруг он что-то портит?).

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)

Нет IPSec реализация в Linux явно не была виновата. В связке друг с другом маршрутизаторы 3Com показывают на треть меньшую скорость.

3.3 Производительность IPSec, масштабирование туннелей, 3DES шифрование, два туннеля

Один туннель, это конечно хорошо, но что будет, если мы нагрузим тестируемые маршрутизаторы двумя туннелями одновременно (устройство будет терминировать два IPSec 3DES туннеля). Посмотрим.

1. Тестируем 3CR870.

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR870 unit, Throughput.scr
два туннеля, полудуплексная передача данных (или «только туда» под двум туннелями, или «только обратно»)

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR870 unit, Throughput.scr
два туннеля, полнодуплексная передача данных (данные передаются в обоих туннелях по обоим направлениям одновременно)

  

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR870 unit, Throughput.scr
два туннеля, полнодуплексная передача данных (данные передаются в обоих туннелях по обоим направлениям одновременно)

2. Все тоже самое для 3CR860.

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR860 unit, Throughput.scr
два туннеля, полудуплексная передача данных (или «только туда» под двум туннелями, или «только обратно»)

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR860 unit, Throughput.scr
два туннеля, полнодуплексная передача данных (данные передаются в обоих туннелях по обоим направлениям одновременно)

  

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR860 unit, Throughput.scr
два туннеля, полнодуплексная передача данных (данные передаются в обоих туннелях по обоим направлениям одновременно)

Какий вывод можно сделать, глядя на эту картину? Общая производительность в режиме IPSec-3DES обоих устройств равна примерно 10Мбит-ам. При увеличении кол-ва туннелей потоки данных делятся примерно в равных долях.

Ради интереса было проделано еще несколько тестов с двумя 3DES IPSec туннелями на примере 3CR870. В этих тестах передача данных по туннелям стартует не одновременно, а с задержкой около 30 секунд.

В первом случае тесты стартовали в такой последовательности:

• 1 туннель, передача 3Com -> Gentoo
• 2 туннель, передача 3Com -> Gentoo
• 1 туннель, передача Gentoo -> 3Com
• 2 туннель, передача Gentoo -> 3Com

Во втором случае последовательность старта тестов изменилась:

• 1 туннель, передача 3Com -> Gentoo
• 1 туннель, передача Gentoo -> 3Com
• 2 туннель, передача 3Com -> Gentoo
• 2 туннель, передача Gentoo -> 3Com

  

первая последовательность тестов

  

вторая последовательность тестов

Картина опять аналогична предыдущей — общая производительность IPSec делится примерно поровну между всеми существующими каналами.

3.4 Производительность IPSec, масштабирование туннелей, 3DES шифрование, три туннеля

  

Три и более туннелей умеет лишь 3CR870. Больше трех туннелей не тестировалось.

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR870 unit, Throughput.scr
три туннеля, полудуплексная передача данных (или «только туда» под трем туннелями, или «только обратно»)

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR870 unit, Throughput.scr
три туннеля, полнодуплексная передача данных (данные передаются в трех туннелях по обоим направлениям одновременно)

NetIQ Chariot: IPSec tunneling, 3DES encryption, 3CR870 unit, Throughput.scr
три туннеля, полнодуплексная передача данных (данные передаются в обоих туннелях по обоим направлениям одновременно)

В заключении раздела о масштабировании туннелей, еще два теста, аналогичных тестам в разделе тестирования двух туннелей (передача данных стартует не одновременно, а с задержкой около 20 секунд).

  

Cначала в туннелях включалась полудуплексная передача, а уже потом полнодуплексная.

  

Cначала стартует однонаправленная передача в первом канале, потом в нем включался полный дуплекс, потом стартовал второй, а потом уж в нем (втором) включался полный дуплекс, а потом и третий.

Картина повторяет предыдущие наблюдения. Каналы делятся примерно поровну.

3.4 Производительность IPSec, AES-128 шифрование

К сожалению, скрестить IPSec реализацию AES-128 в Linux с 3Com устройствами не удалось, Racoon всегда выдавал вот такую ошибку:

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.

Поэтому AES шифрование тестировалась только между двумя 3Com устройствами (друг с другом они связались на ура). А соответственно, более одного туннеля сделать не получилось.

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 более ресурсоемко, поэтому скорость так сильно (в три с лишним раза) проседает.

Навигация:

• общее описание, схемотехника и спецификации;
• экскурс в настройки;
• тестирование производительности
• тестирование traffic shaping, безопасности; доступность и выводы