Русский
Русский
English
Статистика
Реклама

Генератор трафика Cisco TRex запускаем нагрузочное тестирование сетевых устройств



При разработке очередного роутера мы тестировали производительность сети с помощью полезной 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_forwardsudo route add -net 16.0.0.0 netmask 255.0.0.0 gw 192.168.253.106sudo route add -net 48.0.0.0 netmask 255.0.0.0 gw 192.168.254.106

4) Запускаем TRex-сервер в режиме astf:
cd v2.XXsudo ./t-rex-64 -i --astf

При успешном запуске TRex-сервера, увидим информацию о Ethernet-портах, занятых под тестирование:

The ports are bound/configured.port : 0 ------------link         :  link : Link Up - speed 10000 Mbps - full-duplexpromiscuous  : 0 port : 1 ------------link         :  link : Link Up - speed 10000 Mbps - full-duplexpromiscuous  : 0 number of ports         : 2 max cores for 2 ports   : 1 tx queues per port      : 3

5) Запускаем консоль TRex

С помощью консоли в отдельном окне запускаем генерацию потока из готовых примеров (папка с примерами astf есть в архиве к TRex):

cd v2.XX./trex-consolestart -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 enabledCpu 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.XXsudo ./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/sStream 1 TX: 4487179200 Bit/s RX: 4487179200 Bit/sStream 2 TX: 2492873600 Bit/s RX: 2492873600 Bit/sStream 3 TX: 1994294400 Bit/s RX: 1994294400 Bit/sStream 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 APIsfrom 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
К списку статей
Опубликовано: 13.07.2020 10:06:40
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Высокая производительность

Производство и разработка электроники

Разработка под linux

Сетевые технологии

Тестирование it-систем

Разработка сетевой инфраструктуры

Сетевое оборудование

Нагрузочное тестирование

Trex

Cisco

Promwad

Разработка электроники

Iperf

Intel

Dpdk

Linux

Категории

Последние комментарии

© 2006-2020, personeltest.ru