Привет, Хабр! Меня зовут Сергей Бондарев, я старший инженер нагрузочного тестирования в InfoWatch ARMA. В компании я занимаюсь разработкой методик нагрузочного тестирования, разработкой новых сценариев тестирования NGFW и написанием скриптов тестирования под различные нагрузчики.
В последние годы многие компании активно переходят на отечественное оборудование для защиты информационной инфраструктуры. В InfoWatch Arma мы разрабатываем NGFW, подходящий как для промышленных предприятий, так и для корпоративного сегмента.
Чтобы клиент мог оценить возможность внедрения наших решений в свой бизнес, необходимо предоставить максимально приближенную к условиям эксплуатации производительность устройства.
Это одна из основных задач проведения нагрузочного тестирования.
Сегодня мы рассмотрим, как можно получить основную метрику производительности NGFW, а именно — пропускную способность EMIX-трафика (трафик, состоящий из смеси различных протоколов).
Для проведения тестирования в качестве генератора тестового трафика будет использоваться open-source-проект Cisco Trex (https://trex-tgn.cisco.com/).
Определения
Сразу определимся с некоторыми терминами и их сокращениями.
Список
СНТ — Средство нагрузочного тестирования, генератор трафика.
ПАК — Программно-аппаратный комплекс, объект тестирования.
ДУ — Дополнительное устройство, элемент стенда нагрузочного тестирования, сопутствующий проведению тестирования. К примеру, коммутатор.
NGFW — Межсетевой экран нового поколения (Next Generation Firewall).
1. Как работает Cisco Trex?
Для генерации тестового трафика Cisco Trex необходимы:
Сервер генерации трафика
Профиль трафика
Сервер генерации
Локальный сервер, написанный на C++, выполняет роль:
Захвата аппаратных ресурсов из системы
Генерации трафика на основе профиля трафика или pcap-файла
Ведение и отображение статистики
Захват аппаратных ресурсов
Захват аппаратных ресурсов определяет, сколько интерфейсов использовать при генерации, какое количество оперативной памяти и ядер CPU необходимо для работы сервера.
Все выделяемые аппаратные ресурсы по умолчанию описываются в конфигурационном файле /etc/trex_cfg.yaml
Где:
Interfaces — список PCI-адресов интерфейсов в формате bus:device.function. Возможно использовать несколько отдельных портов при генерации или агрегировать интерфейсы.
Port_info — IP-адреса интерфейсов Trex, а также IP-адреса тестируемого устройства. После успешного ARP-запроса по IP происходит замена MAC-адреса получателя в генерируемых пакетах тестового трафика
Platform — Раздел CPU, где:
Master_thread — Ядро CPU, на котором работает управляющий поток сервера генерации
Latency_thread_id — Ядро CPU, выделяемое для измерения задержки (latency).
Dual_if — Список ядер, используемых для генерации в формате socket NUMA (по умолчанию 0, если в сервере только один процессор), и список ядер в сокете.
Memory — Размер ОЗУ в КБ, резервируемых под генерацию. Рассчитывается по формуле: максимальное количество соединений * 2 КБ
Для работы Cisco Trex обязательно наличие сетевых карт с поддержкой DPDK. Именно на базе данной технологии происходят отправка и прием пакетов с сетевой карты для обхода ограничений сетевого стека Linux. Высокоскоростная генерация с DPDK обусловлена и тем, что генератор трафика производит всю работу с тестовым трафиком в UserSpace-пространстве.
Режимы работы сервера генерации:
ASTF (Advanced Stateful) — режим для эмуляции stateful-приложений, включая установку и поддержание TCP-сессий (а также stateful UDP, например, DNS или SIP). Подходит для тестирования сценариев «клиент–сервер», где требуется полное взаимодействие: handshake, передача данных, graceful shutdown. В этом режиме один или несколько портов TRex могут одновременно эмулировать как клиентские, так и серверные сессии (в зависимости от конфигурации профиля), но роли распределяются явно — через настройку виртуальных IP-адресов и поведения в скрипте.
STL (Stateless) — режим генерации stateless-трафика, при котором TRex не отслеживает состояние соединений (то есть не эмулирует TCP-стек, сессии, очереди и прочее). Благодаря минимизации overhead'а достигается максимальная производительность. Поддерживает как UDP, так и TCP-пакеты, но без поддержки end-to-end-сессий. Часто используется для стресс-тестирования, замеров PPS-производительности, проверки ACL/QoS/балансировщиков. В этом режиме каждый порт может независимо настраиваться на передачу, приём или дуплексный режим.
Профиль трафика
Профиль трафика — это конфигурационный файл или скрипт, задающий параметры генерируемого трафика: типы потоков (streams), их интенсивность (rate), продолжительность, заголовки пакетов, вариации полей (например, IP/TCP/UDP), а также поведение приложений (в stateful-режиме).
Именно в профиле задаются структура трафика и логика тестового сценария — от простой генерации потоков до эмуляции пользовательских сессий.
Профиль может быть описан двумя основными способами:
Через Python API — программное описание трафика:
В режиме STL пакеты обычно формируются с помощью библиотеки Scapy
В режиме ASTF описывается поведение клиентских и серверных сессий, а пакеты генерируются самим Cisco Trex. При данном описании значение multiple при запуске будет умножаться на одно описанное взаимодействие клиент-сервера
2. На основе PCAP-файлов — генерация трафика на основе заранее захваченных дампов трафика (одного или нескольких). При данном описании в ASTF-режиме для каждого PCAP указывается, сколько соединений в секунду (CPS) будет открыто с помощью этого PCAP, именно это значение умножается на multiple при запуске.
Синтаксис и структура профиля принципиально различаются между режимами STL и ASTF, поскольку они ориентированы на разные типы нагрузки.
Для проведения нагрузочного тестирования NGFW смешанным трафиком мы воспользуемся профилем трафика на основе PCAP-файлов.
2. Определение логики нагрузочного тестирования
Разобравшись с работой Cisco Trex, можно определить логику нахождения производительности NGFW при обработки смешанного трафика.
Заранее нам не известна фактическая производительность NGFW при заданных настройках. Но мы знаем максимально возможную производительность, она равна line-rate канала или же результату, полученным при меньшем количестве функции безопасности NGFW и настроек МЭ. Также нам известна минимально возможная производительность, обычно подразумевается 0 PPS.
Визуализируем исходные данные:
При поиске неизвестной фактической производительности можно воспользоваться несколькими способами, но самым быстрым является метод бинарного поиска, при котором каждым следующим измерением мы будем отсекать половину возможной производительности, пока не найдём фактическую. В таком случае сам тест будет представлять несколько последовательных измерений, между которыми необходимо приводить объект тестирования к изначальному консистентному состоянию (к примеру, с помощью перезагрузки NGFW или очистки таблицы состояний и рестарта сервисов), чтобы исключить влияние измерений друг на друга. Тестирование будет продолжаться, пока обнаруженная производительность NGFW не будет меньше или равна погрешности метода измерений.
У бинарного поиска есть один ключевой недостаток — это время, необходимое на проведение всего тестирования. В среднем перезагрузка занимает от 3 до 5 минут, плюс необходимое время на старт сервисов и продолжительность измерения. В таком случае тестирование может занимать до нескольких часов.
Оптимизируем закладываемую логику проведения тестирования:
Добавим самое первое измерение на максимально возможной производительности, чтобы исключить, что производительность NGFW не больше или равна максимально возможной производительности. Этим измерением мы также проверяем, снизилась ли производительность от дополнительных настроек NGFW. Если измерение успешное — завершаем тестирование и не проводим этап с бинарным поиском.
В середине каждой итерации производим предварительную проверку результата тестирования. Так мы сможем сократить в два раза время на заведомо неуспешные измерения. Для этой проверки умножим критерии успешности по потерям трафика в два раза и сравним с текущими потерями в измерении. Если фактические потери превышают критерии успешности, то считаем, что все измерение неуспешно.
В среднем необходимое время на выполнение всего теста с оптимизацией будет занимать пару часов.
3. Проведение EMIX-тестирования
Далее описана методология нахождения производительности объекта тестирования при обработке EMIX-трафика.
3.1 Критерии успешности проведенного тестирования:
Процент потерь трафика менее 1%
Процент всех ошибок TCP-соединений менее 5% (опционально)
Процент ошибок по пакетам менее 5% (опционально)
Процент закрытых TCP-соединений флагом RST менее 0.001% (опционально)
3.2 Описание метода тестирования
Процесс тестирования автоматизирован.
Метод нахождения производительности обработки EMIX-трафика состоит из двух этапов, выполняющихся последовательно:
Проверка максимально возможного результата на данной смеси (помогает обнаружить, нет ли ограничения среды передачи или отсутствия снижения производительности при усложнении настроек объекта тестирования)
Нахождение производительности с помощью метода дихотомии (бинарного поиска). Проведение измерения на половине скорости от интервала возможной производительности.
Интервал возможной производительности — разница между максимально возможной и минимально возможной производительностью.
Поиск результата с помощью дихотомии проводится только в случае, если результат проверки максимально возможной производительности неуспешный.
Измерения повторяются до того момента, пока:
Результат не станет подходить по критериям успешности
Разница между максимальной и минимально возможной производительностью станет меньше погрешности метода измерения.
Погрешность метода измерения — 2% от максимальной производительности в параметрах тестирования (max_mult).
3.3 Сборка стенда нагрузочного тестирования
Тестирование подразумевает передачу трафика через объект тестирования и его последующее получение.
В тестировании необходимо исключить или минимизировать отправку трафика извне, так как трафик оказывает влияние на производительность ПАК, в связи с чем необходимо собрать нагрузочный стенд в соответствии со схемой:
3.4 Настройка ПАК
Настройте IP-адрес интерфейсов, участвующих в нагрузочном тестировании на NGFW.
Пример настройки представлен для ПАК на базе Debian с установленным пакетом net-tools.
ifconfig ethX 11.11.11.11/24
ifconfig ethY 11.11.11.11/24
Настройте статическую маршрутизацию для тестового трафика .
ip route add 16.0.0.0/8 via 11.11.11.12
ip route add 48.0.0.0/8 via 22.11.11.12
Настройте межсетевой экран на вашем NGFW для регистрации проходящих TCP-соединений.
При необходимости сконфигурируйте IPS, DPI.
3.5 Настройка СНТ
Перед началом работы инсталлируйте Cisco Trex .
mkdir /opt/trex/
cd /opt/trex/
sudo wget https://trex-tgn.cisco.com/trex/release/v3.05/trex-v3.05.tar.gz
sudo tar -xzf trex-v3.05.tar.gz
Инсталлируйте актуальный git-репозиторий Cisco Trex для удобства работы, все изменения будут происходить в клонированном репозитории.
cd /opt/trex/
git clone https://github.com/cisco-system-traffic-generator/trex-core.git
Скачайте скрипты нагрузочного тестирования.
git clone https://gitlab.com/load_qa/trex_load.git
Скопируйте скрипты нагрузочного тестирования в рабочую директорию git trex.
cp trex_load/EMIX/mix_traf_tp.json /opt/trex/trex-core/scripts/automation/trex_control_plane/interactive/trex/examples/astf/mix_traf_tp.json
cp trex_load/EMIX/mix_traf_tp.json /opt/trex/trex-core/scripts/automation/trex_control_plane/interactive/trex/examples/astf/mix_traf_tp.json
Установите зависимые библиотеки.
pip install -r trex_load/EMIX/requirements.txt
Настройте скрипты нагрузочного тестирования.
3.6 Настройка скриптов нагрузочного тестирования
Все параметры нагрузочного тестирования изменяются с помощью конфигурационного файла mix_traf_tp.json
При проведении тестирования обязательно нужно заполнить параметры тестирования:
profile — абсолютный путь к профилю трафика
ignore_tcp_error — нужно ли игнорировать ошибки по пакетам и TCP-соединениям, включая проверку на закрытые соединения флагом RST. Возможные значения: True / False
max_mult — максимально возможный множитель профиля трафика при данных настройках. Необходимо проверять, что множитель не выставлен больше пропускной способности среды передачи или производительности генератора трафика.
Если необходимо, настройте параметры управления NGFW:
reboot — необходима ли перезагрузка перед каждым измерением? Возможные значения: True / False
ip — IP-адрес тестируемого устройства, необходимый для подключения.
login — логин для подключения к устройству по SSH.
password — пароль для подключения к устройству по SSH.
3.7 Запуск тестирования
На СНТ запустите сервер Trex в режиме ASTF, для этого перейдите в директорию trex.
cd /opt/trex/v3.05
./t-rex-64 -i -c Х --astf
Где Х – максимальное число ядер, выделенных под генерацию в /etc/trex_cfg.yaml
С нового терминала перейдите в директорию git trex.
cd /opt/trex/trex-core/scripts/automation/trex_control_plane/interactive/trex/examples/astf/
Запустите нагрузочное тестирование EMIX.
python3 mix_traf_tp.py --conf mix_traf_tp.json
Проследите, что перед тестированием выполняется перезагрузка ПАК.
Если перезагрузка не выполняется, необходимо переписать функцию перезагрузки под синтаксис вашего объекта тестирования.
В результате проведенного тестирования будет сформирован архив, выгрузите его на рабочий ПК.
4. Обработка и анализ результата тестирования
Результирующие значение пропускной способности EMIX всегда будет находится в папке последнего измерения c названием result_iteration_X.json.
Где Х – номер последнего измерения.
Откройте json-файл, максимальная пропускная способность EMIX указана в поле Total_Mbps
Также можно визуализировать данные из CSV c генератора трафика Cisco Trex, для этого перенесите в одну директорию скрипт обработки результата parse_emix_result.py и архив с результатами тестирования.
Визуализируйте результат финального измерения.
python3.11 parse_emix_result.py -f {Название архива с результатами}
5. Дополнения
Значение максимального множителя трафика для вашей смеси необходимо обнаружить до проведения тестирования.
В качестве примера — тестирование производилось на смеси, предустановленной в составе cisco trex, а именно: astf/emix2.py. Максимальный множитель профиля трафика (max_mult) для этой смеси на интерфейсах 10G – 12.6 mult, для интерфейсов 1G – 1.26 mult.
Для каждого набора настроек NGFW необходимо заново проводить тестирование. Для точности тестирования лучше заменять значение max_mult на полученное значение Multiple profile в результирующем json при более простых настройках NGFW.
Обработка результатов помогает в определении валидности проведенного тестирования. К примеру, можно сравнить графики по отправленному трафику с нагрузчика и трафику, прошедшему через NGFW, загрузку аппаратных ресурсов объекта тестирования. Для сбора метрик с NGFW можно воспользоваться готовыми шаблонами Grafana или самостоятельно написать скрипты сбора метрик.
К примеру, сравним графики с тестового измерения NGFW на 1Г.
В случае переданных данных графики должны быть почти идентичны. Если графики идентичны, необходимо убедиться, что в тестировании учавствовали лишь интерфейсы ПАК ethX и ethY.
Не все метрики напрямую соответствуют на объекте тестирования и генераторе трафика.
К примеру, сравним графики по активным соединениям на нагрузчике и объекте тестирования в одном измерении.
Разница в активных соединениях обусловлена работой межсетевого экрана на NGFW, так как после закрытия какое-то время NGFW продолжает отслеживать соединение. Cisco Trex сразу же закрывает соединение после передачи все пакетов.
6. Ограничения при использовании Cisco Trex
При проведении EMIX-тестирования с использованием Cisco TRex возникают существенные ограничения, связанные с отсутствием встроенной поддержки сбора ключевых KPI метрик, а именно задержки передачи NGFW тестового трафика.
По итогу в ASTF Trex отсутствуют метрики:
TTFB — время между запросом и получением первого байта ответа сервера.
TTLB — время между запросом и получением последнего байта ответа сервера.
Latency average — средняя задержка по всем тестовым потокам трафика.
В связи с этими ограничениями нельзя полностью покрыть требования из методологии сравнительного анализа производительности устройств сетевой безопасности RFC9411 (https://datatracker.ietf.org/doc/rfc9411/).
Надеюсь, этот туториал вам пригодится и станет полезным дополнением в вашей работе. А если у вас есть какие-то вопросы или уточнения — пишите.
