RB750Gr3 – IPsec perfomance (part 2)

Итак, проверим, изменилось ли что-то у RB750Gr3 после обзора в плане IPsec

Потому как данные с форума Микротик по-прежнему очень противоречивые.

Сперва что тестируем.

С одной стороны роутер CCR1009-8G-1S с 1G/1G интернет каналом (статика, никаких PPPoE, PPtP, L2TP и прочей ереси, что может повлиять на тесты). С другой стороны старый знакомый hEX aka RB750Gr3 (та же железка, что и в прошлый раз, лежал на полке с того времени), 100М/100М (через сеть обмена трафиком Giganet-IX ). Прямой пинг между роутерами порядка 10мс. Это отличается от прошлого теста, где роутеры были разнесены дальше, пинг больше, каналы были нессиметричные с одной стороны. Но тем не менее мы так и не смогли добраться до планки 100М. Посему самый главный вопрос этого теста – сможем ли мы наконец выжать всё из 100М/100М. Если да, то второй этап будет – сможем ли выжать больше 100М (понятно, что для этого роутер придется перенести роутер к каналу пошире).

На обоих последняя на данный момент прошивка из ветви Current – 6.41.2 .

Кроме того, меня лично больше всего интересует не чистый IPsec с UDP пакетами 1400 байт на железке с минимумом правил (Микротик уже протестировал этот вариант ), а более практичную ситуацию – NAT + прилетающие на роутер пакеты в 1500 + в один и много потоков (имеет значение, особенно для tcp/ip пакетов).

И более того – GRE+IPsec 128/256 , то есть шифруем GRE туннель между офисами (нужен мультикаст и нормальный роутинг с помощью OSPF).

Проверяем с помощью встроенного в ROS Tools->Bandwidth Test. С одной стороны это не свосем правильно (вернее, совсем неправильно), ибо нагружает CPU. С другой стороны в жизни на роутере вполне может быть сотня-другая правил в фаерволле – и нагрузив CPU при тестах мы получим не синтетические результаты а-ля  UDP+1400+no rules+no NAT, а что-то более менее приюближенное к жизни %)

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

А пока ниже результаты замеров. Замеры производились как внутри туннеля (то есть скорость передачи полезной информации), так и смотрели одновременно на скорость на Wan канале. В некоторых тестах перед результатом стоит “~” или результат вообще не указан. Это значит, что скорость сильно нестабильная (изменялась в несколько раз в течении секунды), а потому бралось усреденное за минуту значение. Прочерки – это значит тест отказался запускаться при данных параметрах (то есть запускался, но ничего не происходило).

Сперва просто тестируем прямой линк между роутерами:

Как видим, имеем странность в передаче одиночного потока TCP/IP. Возможно, причина в Bandwidth Test, который запускался прямо на тестируемом роутере.

Далее устанавливаем GRE канал между роутерами, без шифрования. Тестируем для “обычных” (MTU=1500) и укороченных (MTU=1476) пакетов:

Для пакетов 1500, на первый взгляд, видим странность – внешний канал при тесте нагружен практически на все 100%, внутри канала проходит “всего” 76М. Ничего странного – смысл любого VPN состоит в том, что исходный пакет “заворачивается” в другой пакет. То есть прибавляется новый хидер. Для GRE это 24 байта. А так как в общем случае через Интернет гарантированно могут пройти пакеты размером до 1500 байт, то исходный пакет дробится на два. То есть в нашем случае исходный пакет 1500 байт будет разбивать на два пакета размерами 1476 и … 44 байт. Почему 44 – к 24 байтам данных, что не поместились, необходимо добавить 20 байт IP заголовка. В результате имеем два IP пакета размерами 1476 и 44 байт. Каждый из них будеть заворачиваеться в GRE (+24 байта), и по внешнему каналу будут посланы уже два пакета, размером 1500 и 68 байт. Вроде бы немного – но как видим, эффект существенен. Поэтому всегда нужно проверять и выставлять правильный MTU на туннеле дабы избегать лишней дефграгментации.

Более детально относительно дефрагментации при GRE/IPsec можно почитать у Cisco .
Также в протокол TCP встроен механизм TCP MSS Clamping – почитать можно там же у Cisco .
Где и как это делается и Микротик – читаем тут и тут .

А пока включаем шифрование и смотрим результаты:

AES-CBC – официально заявлен, как хардварно кодируемый. Судя по цифрам – вполне похоже на правду. Как видим – такое же, как и без шифрования, проседание на одиночных TCP/IP потоках. Плюс при многопоточных тестах мы так и не выбираем все 100% для TCP/IP. Упираемся в CPU. Но результаты значительно лучше тех, что мы наблюдали в прошлом тесте . И если убрать лишнюю нагрузку с CPU в виде самого Bandwidth Test – вполне вероятно таки увидим заветные 100М. Хотя, возможно, придется еще и NAT отключить – но то тема совсем другого обзора.

Смотрим, как у нас с AES-CTR. По непроверенной информации он реализован чисто софтверно (ну или если не полностью, то частично). Смотрим:

Как видим, результаты сильно просели и сравнимы с тем, что мы видели в прошлом тесте. Похоже, что AES-CTR таки реализован чисто программно.

Давайте глянем Camelia. Одно время он давал заметно лучшие результаты по сравнению с AES-CTR, а для некоторых роутеров – даже по сравнению с аппаратно реализованным AES-CBC. Итак:

Хм, плюс-минус те же результаты, что и для AES-CTR.

 

Итак, резюмируем:

  1. RB750Gr3 таки поддерживает аппартное шифрование, как минимум для AES-CBC.
  2. Использовать другие типы шифрования, реализованные чисто программно (AES-CTR, Camelia), на данном роутере не имеет никакого смысла.
  3. Несмотря на высокий потенциал – узкое место CPU. При наличии большого количества правил, NATа, мы никогда в реальном применении не выйдем на заявленные 400M (https://mikrotik.com/product/RB750Gr3#fndtn-testresults ), особенно для TCP.
  4. По непонятным причинам я так и не увидел на CPU нагрузку более 50% %) – то ли баг при отображении (двухядерный процессор), то ли при тестах используется только одно ядро. Непонятно.

А пока всё. Но продолжение следут…

 

One Comment