При разработке очередного роутера мы тестировали производительность сети с помощью полезной open-source-штуки — генератора трафика Cisco TRex. Что это за инструмент? Как им пользоваться? И чем он может пригодится инженерам-разработчикам? Под катом — ответы на эти вопросы.
1. Что такое Cisco TRex
Это программный генератор трафика с открытым исходным кодом, работает на стандартных процессорах Intel на базе DPDK, поддерживает режимы с контролем состояния потока и без (stateful / stateless modes). Сравнительно простой и полностью масштабируемый.
Англоязычная документация для этого инструмента доступна на сайте.
Trex позволяет генерировать разные типы трафика и анализировать данные при их получении. Поддерживается работа на уровне MAC и IP. Можно задавать размер пакетов и их количество, контролировать скорость передачи данных.
Работа с генератором организована в среде Linux.
Одно из важных отличий генератора Trex — использование технологии DPDK, которая позволяет обойти «узкие места» в производительности сетевого стека Linux. DPDK или Data Plane Development Kit — это целый набор библиотек и драйверов для быстрой обработки пакетов, который позволяет исключить сетевой стек Linux из процесса обработки пакетов и взаимодействовать с сетевым устройством напрямую.
DPDK превращает процессор общего назначения в сервер пересылки пакетов. Благодаря этой трансформации отпадает необходимость в дорогостоящих коммутаторах и маршрутизаторах. Однако DPDK накладывает ограничения на использование конкретных сетевых адаптеров, список поддерживаемого железа указан на на ссылке — тут самая популярная платформа от 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: trex-tgn.cisco.com/trex/release/
Распаковываем архив в домашней директории пользователя «/home/user», где user — имя пользователя.
[bash]>wget --no-cache https://trex-tgn.cisco.com/trex/release/latest [bash]>tar -xzvf latest2) Настраиваем интерфейсы отправки и приема данных
Выполним настройку с помощью утилиты «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.1064) Запускаем 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 : 35) Запускаем консоль 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 думают и как используют коллеги-инженеры.
ссылка на оригинал статьи https://habr.com/ru/post/510086/
Добавить комментарий