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





При разработке очередного роутера мы тестировали производительность сети с помощью полезной 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 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 думают и как используют коллеги-инженеры.




Комментарии (13):

  1. amarao
    /#21839294

    Последний раз, когда я тестировал на 20Г очень модную железку очень модного вендора (не сиськи), производительность стека Linux была наименьшей из проблем, с которой эта железка столкнулась.

    • Promwad
      /#21840372

      Согласны, можно разрабатывать и тестировать сетевые устройства и без DPDK. В нашем проекте реализация этой технологии была включена в список требований заказчика, благодаря чему и появилась эта заметка для Хабра. :)

  2. lelik363
    /#21839794

    В чем отличие решения Cisco TRex от решений IXIA, не считая стоимости?

    • Promwad
      /#21840402

      Вот тут есть отличная таблица — наглядное сравнение Cisco TRex vs. IXIA: trex-tgn.cisco.com/trex/doc/trex_stateless.html#_ixia_ixexplorer_vs_trex

      • lelik363
        /#21840734

        А если сравнивать с аппаратными решениями от IXIA?

        • mekhan
          /#21850014

          У Ixia несравнимо более продвинутые продукты, так как это лидер в индустрии testing. По ссылке выше TRex сравнивают c базовым софтом Ixia IxExplorer, естественно ничего не говоря о преимуществах Ixia, среди которых advanced tracking, sequence checking, обнаружение ошибок, наносекундная погрешность вычисления latency, что обеспечивается специализированной аппаратной платформой и зрелым функциональным софтом. Кроме этого Ixia имеет поддержку всех routing и MPLS протоколов, возможность эмулировать множество IPsec VPN, application flow с реалистичным payload из базы приложений, быстрые предконфигурированные тесты (RFC2889, RFC2544,. ...) и т.д.

          Ixia chassis
          image

          • lelik363
            /#21850872

            К примеру при разработке управляемого коммутатора L3 какой инструмент целесообразно использовать TRex, IxExplorer или аппаратные решения?

            • mekhan
              /#21851016

              Я бы однозначно рекомендовал использовать серьёзные коммерческие решения типа Ixia, тем более если вы вендор и делаете своё сетевое железо. Для тестирования L2-L3 существует продукт IxNetwork, который можно запускать как на аппаратной платформе, так и имеется виртуальная версия IxNetwork VE, которая запускается на VMware или KVM машинах. Виртуальной версии зачастую достаточно для как для compliance тестирования, так и нагрузочного. Если интересуетесь решением для тестирования сетевого оборудования, могу помочь с выбором, пишите в личные сообщения.

  3. Brak0del
    /#21840192

    Интересная вещь. Подскажите, а нагрузить по максимуму тестируемое устройство этой штукой можно? На практике проблем с производительностью нет? Также подскажите, умеет ли в rfc-2544? Поддерживает ли сети выше 10Гбит/с, например 40 и 100Гбит/с?

    • Promwad
      /#21840338

      Да, можно попробовать выжать до 40 Гбит/с, это заявлено на сайте разработчиков TRex. Они поддерживают интерфейсы до 100 Гбит/с, по скоростям — до 22 миллионов пакетов в секунду (mpps).

      На нашем железе — Intel® Core(TM) i7-7700 CPU @ 3.60GHz — получилось максимум выжимать 10 Гбит/с. Дальше при увеличении количества потоков скорость уже не росла. Это из-за того, что процессор поддерживает всего 8 потоков работы с данными.

      • select26
        /#21857540

        Выжать 10Gbps на 20 потоках можно и при помощи iperf3.
        А вот как получить 1,5Mpps?
        У меня насущная потребность…

        • Promwad
          /#21857594

          1,5 Mpps — это 1500000 пакетов в секунду. По коду есть параметры генерируемого потока «mode=STLTXCont(bps_L2=4500000000)»

          Параметр может быть задан в pps, bps_L1, bps_L2
          # pps: float
          # Packets per second
          #
          # bps_L1: float
          # Bits per second L1 (with IPG)
          #
          # bps_L2: float
          # Bits per second L2 (Ethernet-FCS)

          Что бы получить 1,5Mpps, соотвественно, необходимо задать bps_L2=1500000.