[Sysadmins] сравнение производительности тунелей

[Alexey Shabalin]

Это поверхностное сравнение с целью выбора платформы для реализации.
Специализированные железяки, способные прокачать, зашифровать 1Гб
достаточно дороги (если есть не по космическим ценам - подскажите)


Задача: организация шифрованного тунеля site-to-site по ethernet-каналу 1Гб.

Описание стенда:
2 одинаковых blade-сервера IBM HS-21XM с характеристиками:
CPU: 2 x 4-ядерных Intel E5345 2.33GHz
RAM: 16 Гб
NIC: Broadcom NetXtreme II BCM5708 1000Base-SX (B2) PCI-X 64-bit 133MHz
ОС: Linux 2.6.18-std-smp-alt12 x86_64
Сервера подключены к одному сетевому коммутатору.

Для определения скорости передачи данных использовалась утилита iperf
Инфраструктура SA не разворачивалась, все тесты проводились на
pre-shared ключах.
Результаты iperf:
950 "чистый" канал без шифрования
478 openvpn(BF-CBC-128 + lzo)
241 openvpn(BF-CBC-128)
166 openvpn(RC2-40-CBC - MD2 +lzo)
31 openvpn(RC2-40-CBC - MD2)
429 openvpn(AES + lzo)
247 openvpn(AES)
234 openssh тунель
247 ipsec-tools(BF+deflate)
191 ipsec-tools(DES+deflate)
100 ipsec-tools(3DES+deflate)

Выводы:
1. Использовать сжатие трафика перед шифрованием выгодно, несмотря на
загрузку процессора.
2. Ограничением является производительность процессора. Причём
предположительно (уточнить не удалось - top отказался показывать 8
ядер) только одного ядра - скорее всего остальные ядра при шифровании
канала незадействовались.

Господа, подскажите, возможно ли для шифрования одного тунеля
задействовать несколько ядер процессора. И почему так плохо повёл себя
raсoon по сравнению с openvpn? Я расчитывал, что ipsec, работающий на
уровне ядра окажется производительней.
Что ещё можно посмотреть из vpn для получения большей
производительности(скорости).

-- 
Alexey Shabalin