Всем привет!
Сейчас многие компании активно ищут замену сетевому оборудованию. Наиболее остро вопрос замены присутствует в сегменте NGFW (Next-Generation Firewall, межсетевой экран следующего поколения). Важным этапом выбора является нагрузочное тестирование, которое позволяет убедиться, справится ли устройство с обработкой боевого трафика в инфраструктуре. В прошлой своей статье я рассказывал про нюансы проведения пилотного проекта NGFW и кратко описал способы нагрузочного тестирования (вот она: Вредные советы для пилота NGFW). В этой статье я затронул практику и описал подробную настройку стенда для проведения нагрузочного тестирования межсетевого экрана следующего поколения. Мы с командой инженеров Positive Technologies часто применяем эти знания для демонстрации возможностей продукта PT NGFW, настало время рассказать об этом вам!
Для быстрой навигации по статье
В статье содержится подробная инструкция по установке и настройке генератора трафика TRex для запуска тестирования и отображения его результатов в Grafana, а также подробное описание распространенных тестов. Инструкция не содержит информации о тонкой настройке Cisco TRex для тестирования высокопроизводительных активных сетевых устройств.
Коротко о том, кто такой Cisco TRex: это свободно распространяемый проект Cisco, применяемый для нагрузочного тестирования различных активных сетевых устройств. В руках умелого инженера TRex становится мощным сервисом, который помогает протестировать основные характеристики производительности, а именно:
пропускную способность для трафика UDP (UDP часто используется для DNS-запросов и работы IP-телефонии);
пропускную способность для трафика TCP HTTP с различными размерами HTTP-ответов (весь вебчик это HTTP);
максимальное значение скорости открытия новых HTTP-сессий каждую секунду (скорость трафика в сети непостоянна, всегда возникают всплески и просадки, вызванные открытием или закрытием сессий);
максимальное количество открытых HTTP-сессий без их закрытия (чтобы понять, сколько сессий одновременно может обрабатывать тестируемое устройство)
-
и так далее.
Исходные данные
Мой стенд состоит из трех виртуальных машин:
vm1 — NGFW
vm2 — Debian 11 с установленными InfluxDB и Grafana:
CPU: 4
RAM: 8 Gb
HDD: 20 Gbvm3 — Debian 11 с установленным генератором трафика TRex:
CPU: 4
RAM: 8 Gb
HDD: 20 Gb
По синим линкам передается телеметрия. По зеленым — полезный трафик. Оранжевым отмечены логические подсети, которые создаются на TRex в процессе настройки.
Адресация интерфейсов указана также на рисунке. Вся настройка производится от имени пользователя с правами root.
Этап 1. Настройка операционной системы на VM3
-
Создать необходимые символьные ссылки:
cd /usr/lib/x86_64-linux-gnu/ && sudo ln -s -f libc.a liblibc.a -
Установить требуемые пакеты:
sudo apt-get install -y python3-pip tshark wget -
Отредактировать параметры grub:
sudo nano /etc/default/grubВставить:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"Пример:
GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt" GRUB_CMDLINE_LINUX="" -
Обновить параметры grub:
sudo update-grub -
Перезагрузить сервер:
sudo reboot now
Этап 2. Установка TRex на VM3
-
Создать папку и перейти в нее:
sudo mkdir -p /opt/trex && cd /opt/trex -
Скачать TRex:
sudo wget --no-check-certificate --no-cache https://173.36.109.208/trex/release/v3.00.tar.gzВскрыть архив:
sudo tar xvf v3.00.tar.gz -C /opt/trex --strip-components 1 -
Создать сервис:
sudo nano /etc/systemd/system/trex.serviceВставить в созданный trex.service
[Unit]
Description=TREX Service Instance 1
[Service]
StandardOutput=journal
StandardError=journal
WorkingDirectory=/opt/trex
ExecStart=/opt/trex/t-rex-64 -c 2 -i --astf --tso-disable --lro-disable --iom 0
[Install]
WantedBy=multi-user.target5. Перезагрузить systemd:
sudo systemctl daemon-reload
6. Задать размер (больших страниц) виртуальной памяти:
sudo sysctl vm.nr_hugepages=2048
Справка по nr_hugepages
Команда "sudo sysctl vm.nrhugepages=2048" используется для управления количеством huge pages (больших страниц) в системе. Huge pages используются для увеличения производительности и эффективности работы с большими объемами данных, такими как базы данных и виртуальная память.
Когда вы устанавливаете значение vm.nrhugepages, вы резервируете определенное количество больших страниц для использования в системе. Это может быть полезно для оптимизации работы определенных приложений и уменьшения фрагментации памяти. Однако устанавливать это значение следует с осторожностью, так как большие страницы занимают больше памяти и их использование может привести к неэффективному использованию ресурсов.
Этап 3. Настройка и запуск TRex на VM3
-
Перейти в папку и запустить конфигуратор:
cd /opt/trex && sudo ./dpdk_setup_ports.py -i1.1 Отказаться от MAC based config
1.2 Выбрать интерфейсы для использования в DPDK
1.3 Задать IP-адрес и шлюз по умолчанию для каждого интерфейса
1.4 Перезаписать конфигурацию
-
Перезапустить сервис:
sudo systemctl restart trex.service -
Проверить статус (через 1–2 минуты)
sudo systemctl status trex.serviceВозможно возникновение ошибки: Faled resolveng dest MAC for deafult gateway
Эта ошибка возникает, когда TRex не может обнаружить шлюз по умолчанию, заданный в параметрах.
Проверьте конфигурацию или коммутацию.
Успешный старт выглядит так:
Справка
Отредактировать самостоятельно конфигурацию можно тут:
sudo nano /etc/trex_cfg.yaml
Этап 4. Настройка передачи телеметрии TRex в Grafana
Настройка на VM3
-
Перейти в домашний каталог пользователя:
cd ~ Скачать вспомогательные данные (профили трафика, РСАР-файлы, скрипт запуска)
Вот ссылка на Githab: https://github.com/alksegrv/Trex_install_and_start_tests.git
Вот ссылка на ЯДиск: https://disk.yandex.ru/d/gLlPXpTo8VBCfw
Вот ссылка на позитивную хранилку: https://storage.ptsecurity.com/f/0d6769d05265455e8366/?dl=1
(не знаю, что из этого проживет дольше, оставляю три источника для наших потомков?)-
Вскрыть архив:
tar pxf trex_conf.tar -
Отредактировать скрипт запуска:
cd ~/trex_conf/trex/ && nano trex_run.pyОбязательно нужно задать:
IP-адрес сервера с базой данных InfluxDB (в моем случае InfluxDB установлен вместе с Grafana на сервере 172.16.0.100);
порт для InfluxDB (по умолчанию 8086);
логин пользователя для подключения к InfluxDB (задается на этапе настройки InfluxDB);
пароль пользователя для подключения к InfluxDB (задается на этапе настройки InfluxDB);
название базы данных (в моем случае telegraf).
parser.add_argument('--influx_addr',
dest='influx_addr',
help='InfluxDB address',
default='172.16.0.100',
type=str)
parser.add_argument('--influx_port',
dest='influx_port',
help='InfluxDB port',
default=8086,
type=int)
parser.add_argument('--influx_admin',
dest='influx_admin',
help='InfluxDB admin user',
default='admin',
type=str)
parser.add_argument('--influx_passwd',
dest='influx_passwd',
help='InfluxDB admin password',
default='321admin',
type=str)
parser.add_argument('--influx_db',
dest='influx_db',
help='Influx DB name',
default='telegraf',
type=str)5. Создать файл для установки необходимых компонентов:
sudo nano /opt/trex/requirements.txt
Записать в файл:
influxdb~=5.3.1
PyYAML~=6.0.1
pyshark~=0.5.3
humanize~=4.7.0
requests~=2.28.2
artifactory~=0.1.17
urllib3~=1.26.14
prettytable~=3.8.0
flatten_json~=0.1.136. Установить необходимые пакеты:
sudo pip3 install -r /opt/trex/requirements.txt
7. Зайти в каталог:
cd /home/<ПОЛЬЗОВАТЕЛЬ>/trex_conf/trex/
8. Сделать скрипт запуска исполняемым файлом:
sudo chmod +x trex_run.py
Настройка на VM2
1. Для подключения к Grafana ввести в браузере:
http://<IP_Grafana>:3001
(по умолчанию Grafana использует порт 3000, у меня 3001)
2. Перейти к настройке. Добавить новый источник данных (data source):
3. Применить изменения и протестировать доступность:
4. Импортировать новый дашборд и привязать его к источнику данных.
Дашборд лежит в папке trex_conf
Готово.
Если хотите передать шаблон другу, экспортируйте его с умом.
Этап 5. Запуск тестов
Тест 1: UDP
Задача тестирования
Определить максимальную пропускную способность для трафика UDP IMIX.
Профиль эмулирует DNS-запросы (если задать соответствующий размер фрейма, например 512 байт) по протоколу UDP.
Задание параметров запуска
nano ~/trex_conf/trex/trex_profiles/imix.py
Задать подсети источника и назначения:
# ip generator
ip_gen_c = ASTFIPGenDist(ip_range=["15.0.0.1", "15.0.255.199"], distribution="rand")
ip_gen_s = ASTFIPGenDist(ip_range=["48.0.0.1", "48.1.255.199"], distribution="rand")
ip_gen = ASTFIPGen(glob=ASTFIPGenGlobal(ip_offset="1.0.0.0"),
dist_client=ip_gen_c,
dist_server=ip_gen_s)Где: 15.0.0.1, 15.0.255.199 — диапазон адресов клиентов
48.0.0.1, 48.1.255.199 — диапазон адресов серверов
ip_offset="1.0.0.0" — прирост по адресации подсетей на следующий интерфейс (не используется в моих тестах)
Можно задать порт, но это не обязательно:
# template
assoc = ASTFAssociationRule(port=53)
temp_c = ASTFTCPClientTemplate(program=prog_c, ip_gen=ip_gen, port=53)
temp_s = ASTFTCPServerTemplate(program=prog_s, assoc=assoc)
template = ASTFTemplate(client_template=temp_c, server_template=temp_s)
parser.add_argument('--frame_size_b',
type=int,
default=64,
help='Frame size with FCS, bytes')
parser.add_argument('--delay',
type=int,
default=None,
help='Server response delay (usec)')
parser.add_argument('--flow_size',
type=int,
default=2,
help='Flow size (packets)')
parser.add_argument('--ramp_up',
type=int,
default=0,
help='Ramp up period (sec)')Где: --frame_size_b — размер UDP-фрейма (включая поле FEC)
--delay — задержка между транзакциями
--flow_size — количество фреймов (запросов) в одном UDP-потоке
--ramp_up — время, за которое количество соединений в секунду достигнет целевого показателя
Строка запуска
./trex_run.py --drp 0.105 -f trex_profiles/udp_imix.py -t flow_size=10 frame_size_b=1518 -d 600 -m 2 Параметры для trex_run.py:
- m 1 — множитель, определяет количество конкурентных соединений в секунду
На рисунке ниже на первом интервале тестирования m=2, на втором второй m=5
Пример
./trex_run.py -d 30 --drp 0.105 -f trex_profiles/udp_imix.py -t frame_size_b=1518 flow_size=10 ramp_up=30 -m 5Этот тест запустит трафик с размером UDP-фрейма (включая поля FEC), равным 1518 байт (frame_size_b=1518), и количеством фреймов в одном UDP-потоке, равным 10 штук (flow_size=10).
За одну секунду прошло 5 UDP-потоков (-m 5), в каждом по 10 фреймов.
Что подтверждает количество новых соединений в секунду (-m 5).
Всего в секунду: 1518 × 10 × 5 = 75 900 байт (то есть 607 Кбит/с).
Показатели пропускной способности зафиксированы.
Тест считается успешно пройденным, если доля дропов соединений не превышает 1,05%.
Чтобы увеличить объем трафика, можно изменить множитель m (количество сессий в секунду) или количество сессий в секунду flow_size (количество фреймов в UDP-потоке).
Не рекомендуется увеличивать frame_size_b=1518, чтобы не попасть под ограничение MTU.
При выполнении тестов на UDP основной интерес вызывают результаты, полученные на фреймах разного размера. Поэтому рекомендуется замерять полосу пропускания на минимальном размере фрейма (64 байта), максимальном (1518 байт) и паре промежуточных. Более подробно с методикой проведения таких тестов можно ознакомиться в RFC 2544.
Тест 2: TCP, HTTP, 16 КБ
Задача тестирования
Определить максимальную пропускную способность для трафика TCP HTTP c размером HTTP-ответа 16 КБ.
Задание параметров запуска
nano ~/trex_conf/trex/trex_profiles/tcp_http_16KB.py
Задать подсети источника и назначения:
def __init__(self):
self.p1_src_start_ip = '15.0.0.1'
self.p1_src_end_ip = '15.0.255.199'
self.p1_dst_start_ip = '48.0.0.1'
self.p1_dst_end_ip = '48.0.255.199'Где: 15.0.0.1, 15.0.255.199 — диапазон адресов клиентов;
48.0.0.1, 48.1.255.199 — диапазон адресов серверов.
# ip generator
ip_gen_c = ASTFIPGenDist(ip_range=[self.p1_src_start_ip, self.p1_src_end_ip], distribution="rand")
ip_gen_s = ASTFIPGenDist(ip_range=[self.p1_dst_start_ip, self.p1_dst_end_ip], distribution="rand")
ip_gen = ASTFIPGen(glob=ASTFIPGenGlobal(ip_offset="1.0.0.0"),
dist_client=ip_gen_c,
dist_server=ip_gen_s)ip_offset="1.0.0.0" -— прирост по адресации подсетей на следующий интерфейс (не используется в моих тестах).
parser.add_argument('--response_size_kb',
type=int,
default=16,
help='The response size in KB')
parser.add_argument('--delay',
type=int,
default=None,
help='Server response delay (usec)')
parser.add_argument('--flow_size',
type=int,
default=10,
help='Flow size (transactions)')
parser.add_argument('--ramp_up',
type=int,
default=0,
help='Ramp up period (sec)') --response_size_kb — размер HTTP-ответа сервера;
--delay — задержка между полученным запросом и отправленным ответом;
--flow_size — количество HTTP-транзакций в одной сессии;
--ramp_up — время, за которое скорость трафика достигнет целевого показателя.
Пример
./trex_run.py --drp 0.105 -f trex_profiles/tcp_http_16KB.py -t response_size_kb=16 flow_size=5 -d 600 -m 1При таких параметрах запустится обмен данными между клиентом и сервером по протоколу HTTP с размером HTTP-ответа, равным 16 КБ.
Между одной парой «клиент — сервер» будет выполнено 5 HTTP-сессий (flow_size=5), после чего IP-адреса клиента и сервера будут изменены.
В результате за 1 секунду инициируется один обмен между уникальными парами «клиент — сервер» (параметр -m 1), каждый обмен — это 11 HTTP-транзакций (не считая открытия и завершения сессии) с полем данных, равным 1448 байт. За 11 транзакций передается 16 КБ данных (тонкие расчеты не делал). Один обмен — это 5 сессий (80 КБ), за секунду будет один такой обмен, 80 КБ (это примерно 640 Кбит/с).
Тест считается успешно пройденным, если доля дропов соединений не превышает 1,05%.
Чтобы увеличить объем трафика, можно изменить множитель m или количество сессий в секунду flow_size.
Тест 3: TCP, HTTP, 64 КБ
Задача тестирования
Определить максимальную пропускную способность для трафика TCP HTTP c размером HTTP-ответа 64 КБ.
Задание параметров запуска
nano ~/trex_conf/trex/trex_profiles/tcp_http_64KB.py
Задать подсети источника и назначения:
def __init__(self):
self.p1_src_start_ip = '15.0.0.1'
self.p1_src_end_ip = '15.0.255.199'
self.p1_dst_start_ip = '48.0.0.1'
self.p1_dst_end_ip = '48.0.255.199'Где: 15.0.0.1, 15.0.255.199 — диапазон адресов клиентов;
48.0.0.1, 48.1.255.199 — диапазон адресов серверов
# ip generator
ip_gen_c = ASTFIPGenDist(ip_range=[self.p1_src_start_ip, self.p1_src_end_ip], distribution="rand")
ip_gen_s = ASTFIPGenDist(ip_range=[self.p1_dst_start_ip, self.p1_dst_end_ip], distribution="rand")
ip_gen = ASTFIPGen(glob=ASTFIPGenGlobal(ip_offset="1.0.0.0"),
dist_client=ip_gen_c,
dist_server=ip_gen_s)ip_offset="1.0.0.0" -— прирост по адресации подсетей на следующий интерфейс (не используется в моих тестах)
parser.add_argument('--response_size_kb',
type=int,
default=64,
help='The response size in KB')
parser.add_argument('--delay',
type=int,
default=None,
help='Server response delay (usec)')
parser.add_argument('--flow_size',
type=int,
default=10,
help='Flow size (transactions)')
parser.add_argument('--ramp_up',
type=int,
default=0,
help='Ramp up period (sec)') --response_size_kb — размер HTTP-ответа сервера;
--delay — задержка между полученным запросом и отправленным ответом;
--flow_size — количество HTTP-транзакций в одной сессии;
--ramp_up — время, за которое скорость трафика достигнет целевого показателя
Пример
./trex_run.py --drp 0.105 -f trex_profiles/tcp_http_64KB.py -t response_size_kb=64 flow_size=5 -d 600 -m 1При таких параметрах запустится обмен между клиентом и сервером по протоколу HTTP с размером HTTP-ответа, равным 64 КБ.
Между одной парой «клиент — сервер» будет выполнено 5 HTTP-сессий (flow_size=5), после чего IP-адреса клиента и сервера будут изменены.
В результате получаем: за 1 секунду инициируется один обмен между уникальными парами «клиент — сервер» (параметр -m 1), каждый обмен — это 45 HTTP-транзакций (не считая открытия и завершения сессии) с полем данных, равным 1448 байт. За 45 транзакций передается 64 КБ данных (тонкие расчеты не делал). Один обмен — это 5 сессий (320 КБ), за секунду один обмен, 320 КБ (это примерно 2,6 Мбит/c).
График с данными пропускной способности:
Тест считается успешно пройденным, если доля дропов соединений не превышает 1,05%.
Чтобы увеличить скорость трафика, можно изменить множитель m или количество сессий в секунду flow_size.
Тест 4: MAX_CPS
Задача тестирования
Определить максимальное значение скорости открытия новых HTTP-сессий каждую секунду без потерь, connections per second (CPS).
Задание параметров запуска
nano ~/trex_conf/trex/trex_profiles/http_max_cps.py
Задать подсети источника и назначения:
# ip generator
ip_gen_c = ASTFIPGenDist(ip_range=["15.0.0.1", "15.0.255.199"], distribution="rand")
ip_gen_s = ASTFIPGenDist(ip_range=["48.0.0.1", "48.1.255.199"], distribution="rand")
ip_gen = ASTFIPGen(glob=ASTFIPGenGlobal(ip_offset="1.0.0.0"),
dist_client=ip_gen_c,
dist_server=ip_gen_s)Где: 15.0.0.1, 15.0.255.199 — диапазон адресов клиентов;
48.0.0.1, 48.1.255.199 — диапазон адресов серверов;
ip_offset="1.0.0.0" — прирост по адресации подсетей на следующий интерфейс (не используется в моих тестах)
parser.add_argument('--response_size_kb',
type=float,
default=1,
help='The response size in KB')
parser.add_argument('--delay',
type=int,
default=None,
help='Server response delay (usec)')
parser.add_argument('--ramp_up',
type=int,
default=0,
help='Ramp up period (sec)')
--response_size_kb — размер HTTP-ответа сервера;
--delay — задержка между полученным запросом и отправленным ответом;
--ramp_up — время, за которое количество открытых сессий достигнет целевого показателя.
Пример
./trex_run.py --drp 0.105 -f trex_profiles/http_max_cps.py -t response_size_kb=0.001 -d 90 -m 5При таких параметрах запустится обмен между клиентом и сервером по протоколу HTTP с размером HTTP-ответа, равным 1 байт (response_size_kb).
Одна сессия представляет из себя открытие соединения, одну транзакцию с передачей данных и закрытие соединения.
Тестируемый параметр, количество новых соединений в секунду, зависит от множителя (-m).
За обработку сессий в NGFW отвечает оперативная память, выделенная под этот процесс.
Тест считается успешно пройденным, если доля дропов соединений не превышает 1,05%.
Чтобы увеличить количество конкурентных соединений в секунду, нужно изменить множитель m. При реальном тестировании рекомендуется использовать параметр ramp_up, для ступенчатого возрастания нагрузки.
Тест 5: MAX_CC
Задача тестирования
Определить максимальное количество открытых HTTP-сессий без их закрытия, concurrent connections (CC).
Смысл теста
С определенной скоростью открытия новых соединений в секунду (-m) за определенное время (-d) выйти на заданное число открытых соединений (d × m) и держать соединения с помощью периодических транзакций.
Задание параметров запуска
nano ~/trex_conf/trex/trex_profiles/ max_cc.py
Задать подсети источника и назначения:
def __init__(self):
self.p1_src_start_ip = '15.0.0.1'
self.p1_src_end_ip = '15.0.255.199'
self.p1_dst_start_ip = '48.0.0.1'
self.p1_dst_end_ip = '48.1.255.199'Где: 15.0.0.1, 15.0.255.199 -— диапазон адресов клиентов;
48.0.0.1", "48.1.255.199" -— диапазон адресов серверов.
# ip generator
ip_gen_c = ASTFIPGenDist(ip_range=[self.p1_src_start_ip, self.p1_src_end_ip], distribution="seq")
ip_gen_s = ASTFIPGenDist(ip_range=[self.p1_dst_start_ip, self.p1_dst_end_ip], distribution="seq")
ip_gen = ASTFIPGen(glob=ASTFIPGenGlobal(ip_offset="1.0.0.0"),
dist_client=ip_gen_c,
dist_server=ip_gen_s)ip_offset="1.0.0.0" -— прирост по адресации подсетей на следующий интерфейс (не используется в моих тестах).
parser.add_argument('--response_size_kb',
type=int,
default=1,
help='The response size in KB')
parser.add_argument('--delay',
type=float,
default=30,
help='Delay between transactions in sec')
parser.add_argument('--flow_size',
type=int,
default=10,
help='Flow size (transactions)')
args, unknown = parser.parse_known_args(tunables)
if unknown:
raise Exception('unrecognized arguments {0}\n{1}'.format(unknown, parser.format_usage()))
resp_size = args.response_size_kb * 1024
delay = int(args.delay * 1_000_000)
return self.create_profile(resp_size, delay, args.flow_size) --response_size_kb — размер HTTP-ответа сервера;
--delay — задержка между полученным запросом и отправленным ответом;
--flow_size — количество HTTP-транзакций в одной сессии.
Примечание. При тестировании межсетевых экранов максимальная скорость открытия новых соединений (-m), согласно RFC 9411, должна составлять 50% от измеренного в предыдущем тесте значения.
Пример строки запуска
./trex_run.py --drp 0.105 --cc-dur 600 -f trex_profiles/max_cc.py -t flow_size=40 delay=15 -d 150 -m 9000При таких параметрах за 150 секунд (d) будут открыты 150 × 9000 (d × m) = 1 350 000 соединений, и они будут держаться 600 секунд (cc-dur). После открытия каждого соединения каждые 15 секунд (delay) в нем будет инициироваться HTTP-транзакция с передачей данных объемом 1 КБ (response_size_kb по умолчанию 1), всего за 615 секунд будет инициировано 40 транзакций.
delay = (d + cc-dur) / flow_size
Пример:
./trex_run.py --cc-dur 300 -f trex_profiles/max_cc.py -t flow_size=36 delay=10 -d 60 -m 2Этот тест за 60 секунд (d) откроет 120 (d × m) соединений и будет их держать 300 секунд (cc-dur).
После открытия каждого соединения каждые 10 секунд (delay) в нем будет инициироваться HTTP-транзакция с передачей данных объемом 1 КБ (response_size_kb по умолчанию 1), всего за 360 секунд будет 36 транзакций в одной сессии.
На графиках видно, как прирастает общее число соединений до целевого значения 120, после этого новые соединения не открываются, а поддерживаются уже установленные.
Установленные сессии поддерживаются HTTP-транзакциями каждые 10 секунд.
В итоге получаем последовательные прирост, удержание и закрытие сессий.
Тест считается успешным, если доля дропов соединений не превышает 1,05%.
Общее количество установленных и закрытых соединений (с учетом дропов) можно увидеть тут:
Чтобы повысить количество конкурентных соединений, можно изменять параметры m и d, не забывая при этом корректировать параметры flow_size и delay, чтобы тестируемый межсетевой экран не закрыл сессию по тайм-ауту прежде, чем инициируется новая транзакция или чем ее закроет сам генератор.
За обработку сессий в NGFW отвечает оперативная память, выделенная под этот процесс.
Тест 6: EMIX
Задача тестирования
Определить максимальную пропускную способность для трафика EMIX (набор распространенных L7-протоколов).
Профиль использует РСАР-файлы с трафиком.
Таблица с параметрами трафика представлена ниже.
Полоса пропускания 9,35 Мбит/с получается при множителе m=1.
Соотношение протоколов в полосе пропускания ниже на рисунке.
Соотношение количества соединений ниже на рисунке.
Соотношения количества соединений в секунду для каждого РСАР-файла задаются в профиле, пункт номер 2.
Задание параметров запуска
nano ~/trex_conf/trex/trex_profiles/emix.py
Задать подсети источника и назначения:
# ip generator
ip_gen_c = ASTFIPGenDist(ip_range=["15.0.0.1", "15.0.255.199"], distribution="rand")
ip_gen_s = ASTFIPGenDist(ip_range=["48.0.0.1", "48.1.255.199"], distribution="rand")
ip_gen = ASTFIPGen(glob=ASTFIPGenGlobal(ip_offset="1.0.0.0"),
dist_client=ip_gen_c,
dist_server=ip_gen_s)Где: 15.0.0.1, 15.0.255.199 — диапазон адресов клиентов;
48.0.0.1, 48.1.255.199 — диапазон адресов серверов;
ip_offset="1.0.0.0" — прирост по адресации подсетей на следующий интерфейс (не используется в моих тестах)
Проконтролировать, что корректно указаны пути к РСАР-файлам:
#TLS
ASTFCapInfo(file="../trex-pcaps/https-tls1.2-nginx-trex-256kb.pcap", cps=3, port=443),
#NFS
ASTFCapInfo(file="../trex-pcaps/NFS.CB-NFS-RPC-TCP-dst-port-2049-pkts-61.pcap",cps=5),
#HTTP
ASTFCapInfo(file="../trex-pcaps/DATA-HTTP-TCP-dst-port-80-pkts-34.pcap", cps=2),
#SMB
ASTFCapInfo(file="../trex-pcaps/SMB-TCP-dst-port-139-pkts-36.pcap", cps=2),
#DNS
ASTFCapInfo(file="../trex-pcaps/DNS-UDP-dst-port-53-pkts-39.pcap", cps=1.5),
#SMTP
ASTFCapInfo(file="../trex-pcaps/SMTP-TCP-dst-port-25-pkts-36.pcap", cps=1),
#POP3
ASTFCapInfo(file="../trex-pcaps/POP-IMF-TCP-dst-port-110-pkts-72.pcap", cps=0.5),
#Imap
ASTFCapInfo(file="../trex-pcaps/IMAP-TCP-dst-port-143-pkts-62.pcap", cps=2),
#SIP
ASTFCapInfo(file="../trex-pcaps/SIP-UDP-dst-port-5060-pkts-27.pcap", cps=1),
#RDP
ASTFCapInfo(file="../trex-pcaps/RDPUDP-UDP-dst-port-3389-pkts-9.pcap", cps=5),
#SYSLOG
ASTFCapInfo(file="../trex-pcaps/SYSLOG-UDP-dst-port-514-pkts-58.pcap", cps=1),
#SYSLOG
ASTFCapInfo(file="../trex-pcaps/SSH-TCP-dst-port-22-pkts-47.pcap", cps=1)Где: cps — количество соединений в секунду для трафика из данного РСАР-файла
Строка запуска
./trex_run.py --drp 0.105 -d 120 -f trex_profiles/emix.py -t ramp_up=20 -m 1Параметры для скрипта для запуска тестов trex_run.py:
--drp 0.105 — доля ошибок в процентах, при которой тест признается неуспешным и завершается со статусом Failed;
-f trex_profiles/emix.py — путь к профилю тестирования;
-d 120 — длительность тестирования;
-m 1 — множитель (в конце, чтоб удобно было менять);
--send_stats false — выключить передачу телеметрии в InfluxDB (опционально).
Параметры для emix.py:
-t ramp_up=20 — время, за которое скорость трафика достигнет целевого показателя (что не моментально, а ступенчато)
Пример
./trex_run.py --drp 0.105 -d 120 -f trex_profiles/emix.py -t ramp_up=20 -m 10Множитель 10 дает 250 соединений в секунду и скорость 92 Мбит/с.
Тест считается успешно пройденным, если доля дропов соединений не превышает 1,05%.
Для увеличения скорости трафика нужно изменить параметр m.
Вместо заключения
На этом наша лабораторная работа подходит к концу и нужно делать выводы.
Думаю, вы догадались, но я все же подытожу, что для проведения полноценного нагрузочного тестирования с помощью генератора трафика cisco TRex нужно
-
Заранее добыть параметры боевого трафика, а именно:
1) скорость трафика UDP - пример 2 Гбит/с
2) скорость трафика http 16kb (размер ответа сервера) - пример 3 Гбит/с
3) скорость трафика http 64kb (размер ответа сервера) - пример 5 Гбит/с
4) количество одновременных конкурентных соединений - пример 100тыс
5) количество соединений в секунду (прирост) - пример10тыс
6) количество соединений в L7 протоколах в emix трафике для tls, nfs, http, smb, dns, smtp, pop, imap, sip, rdp, syslog, ssh протоколов - пример tls 3cps, nfs 5cps, http 2cps, smb 2cps, dns 1,5cps, smtp 1cps, pop 0.5cps, imap 2cps, sip 1cps, rdp 5cps, syslog 1cps, ssh 1cps (это рекомендуемый набор, который мы используем в тестах)
7) средняя и пиковая полосы пропускания ngfw - пример Средняя 10Гбит/с, пиковая 14 Гбит/с
Подготовить стенд для тестирования
Предварительно рассчитать параметры запускаемых тестов
Это позволит провести качественное тестирование производительности межсетевого экрана и убедиться в его пригодности для последующего внедрения.
В следующих статьях я расскажу, как адаптировать лабораторный стенд для тестирования производительности межсетевого экрана с настроенным NAD или DNAT, а также, как с помощью TRex запускать различные атаки и анализировать качество детектирования в IPS.
До новых встреч.