[Высокая производительность, Производство и разработка электроники, Разработка под Linux, Сетевые технологии, Тестирование IT-систем] Генератор трафика Cisco TRex: запускаем нагрузочное тестирование сетевых устройств
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
При разработке очередного роутера мы тестировали производительность сети с помощью полезной open-source-штуки — генератора трафика Cisco TRex. Что это за инструмент? Как им пользоваться? И чем он может пригодится инженерам-разработчикам? Под катом — ответы на эти вопросы.
1. Что такое Cisco TRex
Это программный генератор трафика с открытым исходным кодом, работает на стандартных процессорах Intel на базе DPDK, поддерживает режимы с контролем состояния потока и без (stateful / stateless modes). Сравнительно простой и полностью масштабируемый.
Англоязычная документация для этого инструмента доступна на сайте https://trex-tgn.cisco.com/trex/doc
Trex позволяет генерировать разные типы трафика и анализировать данные при их получении. Поддерживается работа на уровне MAC и IP. Можно задавать размер пакетов и их количество, контролировать скорость передачи данных.
Работа с генератором организована в среде Linux.
Одно из важных отличий генератора Trex — использование технологии DPDK, которая позволяет обойти «узкие места» в производительности сетевого стека Linux. DPDK или Data Plane Development Kit — это целый набор библиотек и драйверов для быстрой обработки пакетов, который позволяет исключить сетевой стек Linux из процесса обработки пакетов и взаимодействовать с сетевым устройством напрямую.
DPDK превращает процессор общего назначения в сервер пересылки пакетов. Благодаря этой трансформации отпадает необходимость в дорогостоящих коммутаторах и маршрутизаторах. Однако DPDK накладывает ограничения на использование конкретных сетевых адаптеров, список поддерживаемого железа указан на http://core.dpdk.org/supported — тут самая популярная платформа от Intel, т.е. обеспечена поддердка железа, которое работает с linux-драйверами e1000, ixgbe, i40e, ice, fm10k, ipn3ke, ifc, igc.
Также важно понимать, что для работы TRex-сервера на скоростях 10 Гбит/с необходим многоядерный процессор — от 4 ядер и выше, желательно CPU семейства Intel c поддержкой одновременной многопоточности (hyper-threading).
2. Как получить и попробовать TRex
1) Загружаем архив с сервера trex-tgn.cisco.com:
https://trex-tgn.cisco.com/trex/release/
Распаковываем архив в домашней директории пользователя «/home/user», где user — имя пользователя.
[bash]>wget --no-cache https://trex-tgn.cisco.com/trex/release/latest
[bash]>tar -xzvf latest
2) Настраиваем интерфейсы отправки и приема данных
Выполним настройку с помощью утилиты «dpdk_setup_ports.py», которая идет в архиве с TRex. Конфигурировать сетевые интерфейсы, которые использует TRex, можно на уровне MAC или IP. Для старта необходимо запустить данную утилиту с ключом интерактивной настройки «sudo ./dpdk_setup_ports.py –i».
Первым шагом откажемся от конфигурации на MAC-уровне (Do you want to use MAC based config? (y/N) n).
Вторым шагом необходимо выбрать пару сетевых интерфейсов, с которыми будем работать, в нашем случае сетевая карта Intel X710 работает с 4 сетевыми интерфейсами, будем использовать 1-е и 4-е гнездо сетевой карты.
Третьим шагом система предложит автоматически создать замкнутую конфигурацию – когда данные уходят с порта 1 и приходят в порт 2 (и обратно), все на одном ПК. Нам пришлось отказаться от данной схемы и настроить схему маршрутизации на 2 ПК.
Четвертым и пятым шагом даем согласие на сохранение конфигурации в файл /etc/trex_cfg.yaml.
Для примера рассмотрим конфигурацию на IP-уровне для следующей схемы подключения:
Файл конфигурации находится тут: «/etc/trex_cfg.yaml». Простой конфигурационный файл показан ниже для сетевой карты с 2 портами и CPU, поддерживающем 8 потоков:
### Config file generated by dpdk_setup_ports.py ###
- version: 2
interfaces: ['01:00.0', '01:00.3']
port_info:
- ip: 192.168.253.106
default_gw: 192.168.253.107
- ip: 192.168.254.106
default_gw: 192.168.254.107
platform:
master_thread_id: 0
latency_thread_id: 1
dual_if:
- socket: 0
threads: [2,3,4,5,6,7]
В конфигурации:
- '01:00.0', '01:00.3' — наименование Eth-интерфейсов в используемой системе Linux.
- ip: 192.168.253.106 — адрес порта ПК Server TRex, с которого генерируется трафик.
- default_gw: 192.168.253.107 — адрес 1 порта ПК DUT (Device under test).
- ip: 192.168.254.106 — адрес порта ПК Server TRex, с которого возвращается трафик после прохождения через правила QOS.
- default_gw: 192.168.253.107 — адрес 2 порта ПК DUT.
Внимание! Система TRex запрещает использование той же подсети при генерации потоков, что используются системой, для этого при генерации пакетов используются подсети 16.0.0.0 и 48.0.0.0.
3) Настраиваем интерфейсы на удаленной машине
Необходимо настроить пересылку (forwarding) и маршруты, чтобы система (DUT), через которую будем пропускать трафик, знала, откуда принимать и куда отправлять пакеты.
Настраиваем на ПК DUT правила маршрутизации потоков:
sudo echo 1 > /proc/sys/net/ipv4/ip_forward
sudo route add -net 16.0.0.0 netmask 255.0.0.0 gw 192.168.253.106
sudo route add -net 48.0.0.0 netmask 255.0.0.0 gw 192.168.254.106
4) Запускаем TRex-сервер в режиме astf:
cd v2.XX
sudo ./t-rex-64 -i --astf
При успешном запуске TRex-сервера, увидим информацию о Ethernet-портах, занятых под тестирование:
The ports are bound/configured.
port : 0
------------
link : link : Link Up - speed 10000 Mbps - full-duplex
promiscuous : 0
port : 1
------------
link : link : Link Up - speed 10000 Mbps - full-duplex
promiscuous : 0
number of ports : 2
max cores for 2 ports : 1
tx queues per port : 3
5) Запускаем консоль TRex
С помощью консоли в отдельном окне запускаем генерацию потока из готовых примеров (папка с примерами astf есть в архиве к TRex):
cd v2.XX
./trex-console
start -f astf/http_simple.py -m 1
start (options):
-a (all ports)
-port 1 2 3 (ports 1 2 3)
-d duration (-d 100 -d 10m -d 1h)
-m stream strength (-m 1 -m 1gb -m 40%)
-f load from disk the streams file
При успешном запуске увидим статистику по прохождению трафика в консоли TRex-сервера:
Global stats enabled
Cpu Utilization : 0.3 % 0.6 Gb/core
Platform_factor : 1.0
Total-Tx : 759.81 Kbps
Total-Rx : 759.81 Kbps
Total-PPS : 82.81 pps
Total-CPS : 2.69 cps
Expected-PPS : 0.00 pps
Expected-CPS : 0.00 cps
Expected-L7-BPS : 0.00 bps
Active-flows : 2 Clients : 0 Socket-util : 0.0000 %
Open-flows : 641
3. Автоматизация разработки и тестирования с помощью TRex
В процессе разработки сетевого роутера мы написали много тестов для TRex, соответственно встал вопрос по их прогону в автоматическом режиме с помощью python. Как мы это организовали:
Запустили TRex-сервер в режиме stl:
cd v2.XX
sudo ./t-rex-64 -i --stl
Задали переменную окружения для python, так как TRex работает в связке с python.
export PYTHONPATH=/home/!!!user!!!/v2.XX/automation/trex_control_plane/interactive,
где, «!!!user!!!» — имя пользователя и домашняя директория, v2.XX — версия ПО TRex, загруженная и распакованная в данную папку.
Запустили генератор трафика с помощью python, листинг примера конфигурации приведен ниже.
python example_test_2bidirectstream.py
Ожидаемый результат:
Transmit: 10000.24576MByte/s Receive: 10000.272384MByte/s
Stream 1 TX: 4487179200 Bit/s RX: 4487179200 Bit/s
Stream 2 TX: 2492873600 Bit/s RX: 2492873600 Bit/s
Stream 3 TX: 1994294400 Bit/s RX: 1994294400 Bit/s
Stream 4 TX: 997147200 Bit/s RX: 997147200 Bit/s
Разберем данный пример:
c = STLClient(server = '127.0.0.1')
Создаем подключение к TRex-серверу, в данном случае подключение создается к той же машине, где и сервер.
- «base_pkt_dir_a, base_pkt_dir_b, base_pkt_dir_c, base_pkt_dir_d» — шаблоны пакетов, в которых указаны адреса источника и получателя, и порты источника и получателя. В данном примере создается 4 потока, 2 в одну сторону и 2 в обратную.
- «s1, s2, s3, s4» — у класса STLStream запрашиваем параметры генерируемого потока, такие как ID потока и bitrate, в нашем случае ID1=4.5 Гбит/с, ID2=2.5 Гбит/с, ID3=2 Гбит/с, ID4=1 Гбит/с.
Листинг файла конфигурации потоков example_test_2bidirectstream.py
# get TRex APIs
from trex_stl_lib.api import *
c = STLClient(server = '127.0.0.1')
c.connect()
try:
# create a base packet with scapy
base_pkt_dir_a = Ether()/IP(src="16.0.0.1",dst="48.0.0.1")/UDP(dport=5001,sport=50001)
base_pkt_dir_b = Ether()/IP(src="48.0.0.1",dst="16.0.0.1")/UDP(dport=50001,sport=5001)
base_pkt_dir_c = Ether()/IP(src="16.0.0.2",dst="48.0.0.2")/UDP(dport=5002,sport=50002)
base_pkt_dir_d = Ether()/IP(src="48.0.0.2",dst="16.0.0.2")/UDP(dport=50002,sport=5002)
# pps : float
# Packets per second
#
# bps_L1 : float
# Bits per second L1 (with IPG)
#
# bps_L2 : float
# Bits per second L2 (Ethernet-FCS)
packet_size = 1400
def pad(base_pkt):
pad = (packet_size - len(base_pkt)) * 'x'
return pad
s1 = STLStream(packet=STLPktBuilder(base_pkt_dir_a/pad(base_pkt_dir_a)), mode=STLTXCont(bps_L2=4500000000), flow_stats=STLFlowStats(pg_id=1))
s2 = STLStream(packet=STLPktBuilder(base_pkt_dir_b/pad(base_pkt_dir_b)), mode=STLTXCont(bps_L2=2500000000), flow_stats=STLFlowStats(pg_id=2))
s3 = STLStream(packet=STLPktBuilder(base_pkt_dir_c/pad(base_pkt_dir_c)), mode=STLTXCont(bps_L2=2000000000), flow_stats=STLFlowStats(pg_id=3))
s4 = STLStream(packet=STLPktBuilder(base_pkt_dir_d/pad(base_pkt_dir_d)), mode=STLTXCont(bps_L2=1000000000), flow_stats=STLFlowStats(pg_id=4))
my_ports = [0, 1]
c.reset(ports = [my_ports[0], my_ports[1]])
# add the streams
c.add_streams(s1, ports = my_ports[0])
c.add_streams(s2, ports = my_ports[1])
c.add_streams(s3, ports = my_ports[0])
c.add_streams(s4, ports = my_ports[1])
# start traffic with limit of 10 seconds (otherwise it will continue forever)
# bi direction
testduration = 10
c.start(ports=[my_ports[0], my_ports[1]], duration=testduration)
# hold until traffic ends
c.wait_on_traffic()
# check out the stats
stats = c.get_stats()
# get global stats
totalstats = stats['global']
totaltx = round(totalstats.get('tx_bps'))
totalrx = round(totalstats.get('rx_bps'))
print('Transmit: {}MByte/s Receive: {}MByte/s'.format((totaltx / 1000000), (totalrx / 1000000)))
c.clear_stats(ports = [my_ports[0], my_ports[1]])
# get flow stats
totalstats = stats['flow_stats']
stream1 = totalstats[1]
stream2 = totalstats[2]
stream3 = totalstats[3]
stream4 = totalstats[4]
totaltx_1 = stream1.get('tx_pkts')
totalrx_1 = stream1.get('rx_pkts')
print('Stream 1 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_1['total'] / testduration * packet_size * 8),
(totalrx_1['total'] / testduration * packet_size * 8)))
totaltx_2 = stream2.get('tx_pkts')
totalrx_2 = stream2.get('rx_pkts')
print('Stream 2 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_2['total'] / testduration * packet_size * 8),
(totalrx_2['total'] / testduration * packet_size * 8)))
totaltx_3 = stream3.get('tx_pkts')
totalrx_3 = stream3.get('rx_pkts')
print('Stream 3 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_3['total'] / testduration * packet_size * 8),
(totalrx_3['total'] / testduration * packet_size * 8)))
totaltx_4 = stream4.get('tx_pkts')
totalrx_4 = stream4.get('rx_pkts')
print('Stream 4 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_4['total'] / testduration * packet_size * 8),
(totalrx_4['total'] / testduration * packet_size * 8)))
except STLError as e:
print(e)
finally:
c.disconnect()
Заключение
При подготовке этого руководства для Хабра мы запустили и проверили работу системы DUT с 4 потоками, собрали информацию по потокам и глобальную статистику.
Описанная выше операция запускается с помощью python, значит с помощью TRex можно автоматизировать тестирование и отладку сетевых устройств и программных продуктов — в цикле или при последовательном запуске тестов на python.
Так чем же TRex компании Cisco лучше или хуже других аналогичных генераторов трафика? Например, популярной клиент-серверной программы iperf? В сценарии использования TRex мы видим описание настройки и работы с потоками. Оба средства тестирования и отладки хороши: iperf — для быстрой проверки функциональности на ходу, а TRex отлично справляется с автоматизацией тестирования и разработки сложных сетевых устройств и систем, где важна возможность настройки многопоточных стримов, чтобы каждый поток конфигурировать под конкретную задачу и анализировать результаты на выходе.
TRex позволяет создавать шаблоны практически любого вида трафика и усиливать их для генерации крупномасштабных DDoS-атак, в том числе TCP-SYN, UDP и ICMP-потоков. Возможность генерации массивных потоков трафика позволяет моделировать атаки от различных клиентов на множество целевых серверов.
Так что если вы еще не пробовали этот инструмент — можно взять на заметку. А если пробовали — поделитесь своими примерами и отзывами в комментариях. Интересно узнать, что о TRex думают и как используют коллеги-инженеры.
===========
Источник:
habr.com
===========
Похожие новости:
- [*nix, Open source] FOSS News №24 – обзор новостей свободного и открытого ПО за 6–12 июля 2020 года
- [Информационная безопасность, Разработка для интернета вещей, Сетевые технологии] Простой UDP hole punching на примере IPIP-туннеля
- Линус Торвальдс подключился к обсуждению начальной реализации поддержки Rust в ядре Linux
- [*nix, Python, Разработка на Raspberry Pi, Разработка под Linux] Разработка zond-а для замера скорости интернета
- В состав ядра Linux 5.8 приняты рекомендации по инклюзивной терминологии
- [История IT, Разработка под Linux, Терминология IT] Линус Торвальдс одобрил замену части терминов в коде Linux на нейтральные названия
- [Lua, Алгоритмы, Высокая производительность] Создаём с нуля высоконагруженное приложение на Tarantool
- [IT-инфраструктура, Open source, Разработка под Linux, Учебный процесс в IT] Мастер-курсы по Istio и Kafka, книга про Python и немного про навыки веб-разработки
- [Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений] Как найти границы на клиенте и сервере
- Предложение по обсуждению вопроса добавления в ядро Linux средств для разработки на языке Rust
Теги для поиска: #_vysokaja_proizvoditelnost (Высокая производительность), #_proizvodstvo_i_razrabotka_elektroniki (Производство и разработка электроники), #_razrabotka_pod_linux (Разработка под Linux), #_setevye_tehnologii (Сетевые технологии), #_testirovanie_itsistem (Тестирование IT-систем), #_razrabotka_setevoj_infrastruktury (разработка сетевой инфраструктуры), #_setevoe_oborudovanie (сетевое оборудование), #_nagruzochnoe_testirovanie (нагрузочное тестирование), #_trex, #_cisco, #_promwad, #_razrabotka_elektroniki (разработка электроники), #_iperf, #_intel, #_dpdk, #_linux, #_vysokaja_proizvoditelnost (
Высокая производительность
), #_proizvodstvo_i_razrabotka_elektroniki (
Производство и разработка электроники
), #_razrabotka_pod_linux (
Разработка под Linux
), #_setevye_tehnologii (
Сетевые технологии
), #_testirovanie_itsistem (
Тестирование IT-систем
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:24
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 При разработке очередного роутера мы тестировали производительность сети с помощью полезной open-source-штуки — генератора трафика Cisco TRex. Что это за инструмент? Как им пользоваться? И чем он может пригодится инженерам-разработчикам? Под катом — ответы на эти вопросы. 1. Что такое Cisco TRex Это программный генератор трафика с открытым исходным кодом, работает на стандартных процессорах Intel на базе DPDK, поддерживает режимы с контролем состояния потока и без (stateful / stateless modes). Сравнительно простой и полностью масштабируемый. Англоязычная документация для этого инструмента доступна на сайте https://trex-tgn.cisco.com/trex/doc Trex позволяет генерировать разные типы трафика и анализировать данные при их получении. Поддерживается работа на уровне MAC и IP. Можно задавать размер пакетов и их количество, контролировать скорость передачи данных. Работа с генератором организована в среде Linux. Одно из важных отличий генератора Trex — использование технологии DPDK, которая позволяет обойти «узкие места» в производительности сетевого стека Linux. DPDK или Data Plane Development Kit — это целый набор библиотек и драйверов для быстрой обработки пакетов, который позволяет исключить сетевой стек Linux из процесса обработки пакетов и взаимодействовать с сетевым устройством напрямую. DPDK превращает процессор общего назначения в сервер пересылки пакетов. Благодаря этой трансформации отпадает необходимость в дорогостоящих коммутаторах и маршрутизаторах. Однако DPDK накладывает ограничения на использование конкретных сетевых адаптеров, список поддерживаемого железа указан на http://core.dpdk.org/supported — тут самая популярная платформа от Intel, т.е. обеспечена поддердка железа, которое работает с linux-драйверами e1000, ixgbe, i40e, ice, fm10k, ipn3ke, ifc, igc. Также важно понимать, что для работы TRex-сервера на скоростях 10 Гбит/с необходим многоядерный процессор — от 4 ядер и выше, желательно CPU семейства Intel c поддержкой одновременной многопоточности (hyper-threading). 2. Как получить и попробовать TRex 1) Загружаем архив с сервера trex-tgn.cisco.com: https://trex-tgn.cisco.com/trex/release/ Распаковываем архив в домашней директории пользователя «/home/user», где user — имя пользователя. [bash]>wget --no-cache https://trex-tgn.cisco.com/trex/release/latest
[bash]>tar -xzvf latest 2) Настраиваем интерфейсы отправки и приема данных Выполним настройку с помощью утилиты «dpdk_setup_ports.py», которая идет в архиве с TRex. Конфигурировать сетевые интерфейсы, которые использует TRex, можно на уровне MAC или IP. Для старта необходимо запустить данную утилиту с ключом интерактивной настройки «sudo ./dpdk_setup_ports.py –i». Первым шагом откажемся от конфигурации на MAC-уровне (Do you want to use MAC based config? (y/N) n). Вторым шагом необходимо выбрать пару сетевых интерфейсов, с которыми будем работать, в нашем случае сетевая карта Intel X710 работает с 4 сетевыми интерфейсами, будем использовать 1-е и 4-е гнездо сетевой карты.  Третьим шагом система предложит автоматически создать замкнутую конфигурацию – когда данные уходят с порта 1 и приходят в порт 2 (и обратно), все на одном ПК. Нам пришлось отказаться от данной схемы и настроить схему маршрутизации на 2 ПК. Четвертым и пятым шагом даем согласие на сохранение конфигурации в файл /etc/trex_cfg.yaml. Для примера рассмотрим конфигурацию на IP-уровне для следующей схемы подключения:  Файл конфигурации находится тут: «/etc/trex_cfg.yaml». Простой конфигурационный файл показан ниже для сетевой карты с 2 портами и CPU, поддерживающем 8 потоков: ### Config file generated by dpdk_setup_ports.py ###
- version: 2 interfaces: ['01:00.0', '01:00.3'] port_info: - ip: 192.168.253.106 default_gw: 192.168.253.107 - ip: 192.168.254.106 default_gw: 192.168.254.107 platform: master_thread_id: 0 latency_thread_id: 1 dual_if: - socket: 0 threads: [2,3,4,5,6,7] В конфигурации:
Внимание! Система TRex запрещает использование той же подсети при генерации потоков, что используются системой, для этого при генерации пакетов используются подсети 16.0.0.0 и 48.0.0.0. 3) Настраиваем интерфейсы на удаленной машине Необходимо настроить пересылку (forwarding) и маршруты, чтобы система (DUT), через которую будем пропускать трафик, знала, откуда принимать и куда отправлять пакеты. Настраиваем на ПК DUT правила маршрутизации потоков: sudo echo 1 > /proc/sys/net/ipv4/ip_forward
sudo route add -net 16.0.0.0 netmask 255.0.0.0 gw 192.168.253.106 sudo route add -net 48.0.0.0 netmask 255.0.0.0 gw 192.168.254.106 4) Запускаем TRex-сервер в режиме astf: cd v2.XX
sudo ./t-rex-64 -i --astf При успешном запуске TRex-сервера, увидим информацию о Ethernet-портах, занятых под тестирование: The ports are bound/configured.
port : 0 ------------ link : link : Link Up - speed 10000 Mbps - full-duplex promiscuous : 0 port : 1 ------------ link : link : Link Up - speed 10000 Mbps - full-duplex promiscuous : 0 number of ports : 2 max cores for 2 ports : 1 tx queues per port : 3 5) Запускаем консоль TRex С помощью консоли в отдельном окне запускаем генерацию потока из готовых примеров (папка с примерами astf есть в архиве к TRex): cd v2.XX
./trex-console start -f astf/http_simple.py -m 1 start (options): -a (all ports) -port 1 2 3 (ports 1 2 3) -d duration (-d 100 -d 10m -d 1h) -m stream strength (-m 1 -m 1gb -m 40%) -f load from disk the streams file При успешном запуске увидим статистику по прохождению трафика в консоли TRex-сервера: Global stats enabled
Cpu Utilization : 0.3 % 0.6 Gb/core Platform_factor : 1.0 Total-Tx : 759.81 Kbps Total-Rx : 759.81 Kbps Total-PPS : 82.81 pps Total-CPS : 2.69 cps Expected-PPS : 0.00 pps Expected-CPS : 0.00 cps Expected-L7-BPS : 0.00 bps Active-flows : 2 Clients : 0 Socket-util : 0.0000 % Open-flows : 641 3. Автоматизация разработки и тестирования с помощью TRex В процессе разработки сетевого роутера мы написали много тестов для TRex, соответственно встал вопрос по их прогону в автоматическом режиме с помощью python. Как мы это организовали: Запустили TRex-сервер в режиме stl: cd v2.XX
sudo ./t-rex-64 -i --stl Задали переменную окружения для python, так как TRex работает в связке с python. export PYTHONPATH=/home/!!!user!!!/v2.XX/automation/trex_control_plane/interactive, где, «!!!user!!!» — имя пользователя и домашняя директория, v2.XX — версия ПО TRex, загруженная и распакованная в данную папку. Запустили генератор трафика с помощью python, листинг примера конфигурации приведен ниже. python example_test_2bidirectstream.py Ожидаемый результат: Transmit: 10000.24576MByte/s Receive: 10000.272384MByte/s
Stream 1 TX: 4487179200 Bit/s RX: 4487179200 Bit/s Stream 2 TX: 2492873600 Bit/s RX: 2492873600 Bit/s Stream 3 TX: 1994294400 Bit/s RX: 1994294400 Bit/s Stream 4 TX: 997147200 Bit/s RX: 997147200 Bit/s Разберем данный пример: c = STLClient(server = '127.0.0.1') Создаем подключение к TRex-серверу, в данном случае подключение создается к той же машине, где и сервер.
Листинг файла конфигурации потоков example_test_2bidirectstream.py # get TRex APIs
from trex_stl_lib.api import * c = STLClient(server = '127.0.0.1') c.connect() try: # create a base packet with scapy base_pkt_dir_a = Ether()/IP(src="16.0.0.1",dst="48.0.0.1")/UDP(dport=5001,sport=50001) base_pkt_dir_b = Ether()/IP(src="48.0.0.1",dst="16.0.0.1")/UDP(dport=50001,sport=5001) base_pkt_dir_c = Ether()/IP(src="16.0.0.2",dst="48.0.0.2")/UDP(dport=5002,sport=50002) base_pkt_dir_d = Ether()/IP(src="48.0.0.2",dst="16.0.0.2")/UDP(dport=50002,sport=5002) # pps : float # Packets per second # # bps_L1 : float # Bits per second L1 (with IPG) # # bps_L2 : float # Bits per second L2 (Ethernet-FCS) packet_size = 1400 def pad(base_pkt): pad = (packet_size - len(base_pkt)) * 'x' return pad s1 = STLStream(packet=STLPktBuilder(base_pkt_dir_a/pad(base_pkt_dir_a)), mode=STLTXCont(bps_L2=4500000000), flow_stats=STLFlowStats(pg_id=1)) s2 = STLStream(packet=STLPktBuilder(base_pkt_dir_b/pad(base_pkt_dir_b)), mode=STLTXCont(bps_L2=2500000000), flow_stats=STLFlowStats(pg_id=2)) s3 = STLStream(packet=STLPktBuilder(base_pkt_dir_c/pad(base_pkt_dir_c)), mode=STLTXCont(bps_L2=2000000000), flow_stats=STLFlowStats(pg_id=3)) s4 = STLStream(packet=STLPktBuilder(base_pkt_dir_d/pad(base_pkt_dir_d)), mode=STLTXCont(bps_L2=1000000000), flow_stats=STLFlowStats(pg_id=4)) my_ports = [0, 1] c.reset(ports = [my_ports[0], my_ports[1]]) # add the streams c.add_streams(s1, ports = my_ports[0]) c.add_streams(s2, ports = my_ports[1]) c.add_streams(s3, ports = my_ports[0]) c.add_streams(s4, ports = my_ports[1]) # start traffic with limit of 10 seconds (otherwise it will continue forever) # bi direction testduration = 10 c.start(ports=[my_ports[0], my_ports[1]], duration=testduration) # hold until traffic ends c.wait_on_traffic() # check out the stats stats = c.get_stats() # get global stats totalstats = stats['global'] totaltx = round(totalstats.get('tx_bps')) totalrx = round(totalstats.get('rx_bps')) print('Transmit: {}MByte/s Receive: {}MByte/s'.format((totaltx / 1000000), (totalrx / 1000000))) c.clear_stats(ports = [my_ports[0], my_ports[1]]) # get flow stats totalstats = stats['flow_stats'] stream1 = totalstats[1] stream2 = totalstats[2] stream3 = totalstats[3] stream4 = totalstats[4] totaltx_1 = stream1.get('tx_pkts') totalrx_1 = stream1.get('rx_pkts') print('Stream 1 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_1['total'] / testduration * packet_size * 8), (totalrx_1['total'] / testduration * packet_size * 8))) totaltx_2 = stream2.get('tx_pkts') totalrx_2 = stream2.get('rx_pkts') print('Stream 2 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_2['total'] / testduration * packet_size * 8), (totalrx_2['total'] / testduration * packet_size * 8))) totaltx_3 = stream3.get('tx_pkts') totalrx_3 = stream3.get('rx_pkts') print('Stream 3 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_3['total'] / testduration * packet_size * 8), (totalrx_3['total'] / testduration * packet_size * 8))) totaltx_4 = stream4.get('tx_pkts') totalrx_4 = stream4.get('rx_pkts') print('Stream 4 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_4['total'] / testduration * packet_size * 8), (totalrx_4['total'] / testduration * packet_size * 8))) except STLError as e: print(e) finally: c.disconnect() Заключение При подготовке этого руководства для Хабра мы запустили и проверили работу системы DUT с 4 потоками, собрали информацию по потокам и глобальную статистику. Описанная выше операция запускается с помощью python, значит с помощью TRex можно автоматизировать тестирование и отладку сетевых устройств и программных продуктов — в цикле или при последовательном запуске тестов на python. Так чем же TRex компании Cisco лучше или хуже других аналогичных генераторов трафика? Например, популярной клиент-серверной программы iperf? В сценарии использования TRex мы видим описание настройки и работы с потоками. Оба средства тестирования и отладки хороши: iperf — для быстрой проверки функциональности на ходу, а TRex отлично справляется с автоматизацией тестирования и разработки сложных сетевых устройств и систем, где важна возможность настройки многопоточных стримов, чтобы каждый поток конфигурировать под конкретную задачу и анализировать результаты на выходе. TRex позволяет создавать шаблоны практически любого вида трафика и усиливать их для генерации крупномасштабных DDoS-атак, в том числе TCP-SYN, UDP и ICMP-потоков. Возможность генерации массивных потоков трафика позволяет моделировать атаки от различных клиентов на множество целевых серверов. Так что если вы еще не пробовали этот инструмент — можно взять на заметку. А если пробовали — поделитесь своими примерами и отзывами в комментариях. Интересно узнать, что о TRex думают и как используют коллеги-инженеры. =========== Источник: habr.com =========== Похожие новости:
Высокая производительность ), #_proizvodstvo_i_razrabotka_elektroniki ( Производство и разработка электроники ), #_razrabotka_pod_linux ( Разработка под Linux ), #_setevye_tehnologii ( Сетевые технологии ), #_testirovanie_itsistem ( Тестирование IT-систем ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:24
Часовой пояс: UTC + 5