Тему нагрузочного тестирования сетевого оборудования принято как-то обходить стороной, обычно упоминается вскользь в разрезе жутко дорогого специализированного железа. Не нашел информации про данный open-source продукт на русском языке так что позволю себе слегка популяризировать. В статье опишу небольшой HOWTO с целью познакомить людей с софтварными трафик генераторами.

Cisco TREX — высокопроизводительный генератор трафика. Для своей работы использует dpdk. Аппаратные требования — 64-bit архитектура, совместимая сетевая карта, поддерживаемые ос * Fedora 18-20, 64-bit kernel (not 32-bit) * Ubuntu 14.04.1 LTS, 64-bit kernel (not 32-bit). Вы можете запустить на другом линуксе, запилив себе необходимые драйвера и собрав свою версию из файлов, которые лежат в репозитории на гитхабе, здесь все стандартно.

DPDK

Data Plane Development Kit (DPDK), изначально разработанный Intel и переданный в открытое сообщество.
DPDK это фреймворк который предоставляет набор библиотек и драйверов для ускорения обработки пакетов в приложениях, работающих на архитектуре Intel. DPDK поддерживается на любых процессорах Intel от Atom до Xeon, любой разрядности и без ограничения по количеству ядер и процессоров. В настоящее время DPDK портируется и на другие архитектуры, отличные от x86 — IBM Power 8, ARM и др.
Если не углубляться в технические подробности, DPDK позволяет полностью исключить сетевой стек Linux из обработки пакетов. Приложение, работающее в User Space, напрямую общается с аппаратным обеспечением.
Помимо поддержки физических карточек имеется возможность работать с paravirtualized картами VMware (VMXNET /
VMXNET3, Connect using VMware vSwitch) и E1000 (VMware/KVM/VirtualBox).

DEPLOY

Скачаем, распакуем, соберем trex.

WEB_URL=http://trex-tgn.cisco.com/trex # или csi-wiki-01:8181/trex (Cisco internal)
mkdir trex
cd trex
wget --no-cache $WEB_URL/release/v2.05.tar.gz
tar -xzvf v2.05.tar.gz
cd v2.05
cd ko/src  
make  
make install  
cd -  

Интерфейсы, с которых будет производиться тестирование, необходимо вытащить из линукса и передать под управление dpdk, для этого необходимо выполнить команду, которая выведет PCI id всех интерфейсов.

 $>sudo ./dpdk_setup_ports.py --s

 Network devices using DPDK-compatible driver
 ============================================

 Network devices using kernel driver
 ===================================
 0000:02:00.0 '82545EM Gigabit Ethernet Controller (Copper)' if=eth2 drv=e1000 unused=igb_uio *Active*
 0000:03:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv= unused=ixgb #1
 0000:03:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv= unused=ixgb #2
 0000:13:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv= unused=ixgb #3
 0000:13:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv= unused=ixgb #4


 Other network devices
 =====================

Затем добавить их в конфигурационный файл, рекомендуется скопировать, потому что тогда trex будет его автоматически подхватывать, без необходимости указывать путь в ручную при каждом запуске.

cp  cfg/simple_cfg.yaml /etc/trex_cfg.yaml

Как вы успели заметить, конфигурация хранится в популярном ныне формате YAML, забегая вперед, в нем же хранятся конфигурационные файлы тестов. В нем так же рекомендуется задать мак адреса.
На всякий случай пример того, как файл должен выглядеть:

        - port_limit      : 2
          version       : 2
          interfaces    : ["03:00.0","03:00.1"]   2
          port_info       :  # set eh mac addr
                  - dest_mac        :   [0x1,0x0,0x0,0x1,0x0,0x00]  # port 0
                    src_mac         :   [0x2,0x0,0x0,0x2,0x0,0x00]                                     1
                  - dest_mac        :   [0x2,0x0,0x0,0x2,0x0,0x00]  # port 1                           1
                    src_mac         :   [0x1,0x0,0x0,0x1,0x0,0x00

port 0 — src
port 1 — dst

Давайте уже нагрузим что-нибудь

Физические интерфейсы необходимо подключить куда-нибудь по схеме вход-выход. Один интерфейс будет отсылать пакеты другой принимать (на самом деле генератор умеет эмулировать полноценные честные tcp сессии, но сейчас не об этом)

Следующая команда запустит тест, который будет нагружать железо dns запросом в одном и том же направлении на протяжении 100 секунд, кстати, если вы захотите чтобы шаблон отрабатывал на всех интерфейсах(данный пакет уходил в обоих направлениях), то можно добавить ключ -p

sudo ./t-rex-64 -f cap2/dns.yaml -c 4 -m 1 -d 100 -l 1000

-c — число ядер процессора.
-m — множитель cps каждого шаблона пакетов.
-d — время теста.
-l — частота (в Hz) latency пакетов, много параметров считается без их учета.

В данном случае вывод будет содержать что-то такое (слегка ужал, выбрав самое интересное)

 -Global stats enabled
 Cpu Utilization : 0.0  %  29.7 Gb/core 
 Platform_factor : 1.0
 Total-Tx        :     867.89 Kbps                                             
 Total-Rx        :     867.86 Kbps                                             
 Total-PPS       :       1.64 Kpps
 Total-CPS       :       0.50  cps

 Expected-PPS    :       2.00  pps   9
 Expected-CPS    :       1.00  cps   10
 Expected-BPS    :       1.36 Kbps   11

 Active-flows    :        0 6 Clients :      510   Socket-util  : 0.0000 %
 Open-flows      :        1 7 Servers :      254   Socket   :        1  Socket/Clients :  0.0
 drop-rate       :       0.00  bps   
 current time    : 5.3 sec
 test duration   : 94.7 sec

Cpu Utilization — среднее значение нагрузки на CPU передающими тредами. Для налучшей производительности рекомендуется держать меньше 80%.
Total-Tx — суммарная скорость на передающем интерфейсе (в данном случае port 0)
Total-Rx — суммарная скорость на принимающем интерфейсе (в данном случае port 1)
Total-PPS — packets per second число пакетов на интерфейсах
Total-CPS — connections per second по сути этот параметр означает число запуска шаблонов, которые указаны в конфигурационном файле в секунду.

Expected-PPS — Ожидаемое число пакетов в секунду, в теории стремится к cps*число пакетов шаблона.
Expected-CPS — cps указанный в yaml файле теста.
Expected-BPS — суммарный трафик, объем шаблона * cps.

Active-flows — число внутренних потоков t-rex. По сути этот параметр является числом сессий, за которыми следит t-rex. например, если вы запустите тест с pcap длительность сессии в котором равна 30 сек, то это показатель должен стремится к 30*Expected-CPS.

При желании действительно «нагрузить» сеть, можно увеличить множитель шаблона и добавить -p.

sudo ./t-rex-64 -f cap2/dns.yaml -c 4 -m 9000 -d 100 -l 1000 -p

Будет увеличено число потоков с одним и тем же IP, если критично разнообразие трафика (src адресов), то необходимо увеличивать CPS в конфигурационном файле, кстати, о нем.

Конфигурации тестов

Рассмотрим cap2/dns.yaml:

- duration : 10.0
  generator :  
          distribution : "seq"
          clients_start : "16.0.0.1"
          clients_end   : "16.0.1.255"
          clients_end : "48.0.0.1"
          servers_end   : "48.0.0.255"
          clients_per_gb : 201
          min_clients    : 101
          dual_port_mask : "1.0.0.0" 
          tcp_aging      : 1
          udp_aging      : 1
  mac        : [0x00,0x00,0x00,0x01,0x00,0x00]
  #vlan       : { enable : 1  ,  vlan0 : 100 , vlan1 : 200 }
  #mac_override_by_ip : true
  cap_info : 
     - name: cap2/dns.pcap
       cps : 1.0
       ipg : 10000
       rtt : 10000
       w   : 1

clients_start — clients_end — диапазон rsc адерсов.
clients_start — clients_end — диапазон dst адресов.

— name: cap2/dns.pcap — задаем pcap файл, который будет использоваться в качестве шлаблона.
cps — число соединений в секунду, по сути равняется числу одновременно последовательно запущенных потоков из вашего шаблона. Т.е. если в тесте у вас инкрементируется адрес, а cps: 10 то будет одновременно запущено 10 потоков с разными адресами.
ipg — должен быть таким же как rtt.

В общем случае логика тирекса выглядит так: он проходит по всему диапазону IP адресов, на каждой итерации меняя dst и src адреса, когда они заканчиваются, цикл повторяется с инкрементом порта и так 64к раз.

Тестируем NAT

Серьезные парни из циски реализовали очень важную функцию, они позволили генератору создавать честные tcp сессии и следить за ними. Например, если между нашими интерфейсами будет NAT, то можно сказать «у нас нат» и трафик будет учитываться с детектированием трансляции.
Всего есть три режима:
mode 1 Данный режим работает только на TCP. Смотрим на ACK, который приходит за первым SYN и таким образом обучаемся. Это хороший честный режим.
mode 2 Работает с IP option.
mode 3 Работает как режим 1, только не учит Sequence Number на сервере в сторону клиента. Может дать прирост cps относительного первого режима.

sudo ./t-rex-64 -f cap2/http_simple.yaml -c 4  -l 1000 -d 100000 -m 30  --learn-mode 1

-Global stats enabled 
 Cpu Utilization : 0.1  %  13.4 Gb/core 
 Platform_factor : 1.0  
 Total-Tx        :      24.12 Mbps   Nat_time_out    :        0 
 Total-Rx        :      24.09 Mbps   Nat_no_fid      :        0 
 Total-PPS       :       5.08 Kpps   Total_nat_active:        1 
 Total-CPS       :      83.31  cps   Total_nat_open  :     1508 

 Expected-PPS    :       3.08 Kpps  
 Expected-CPS    :      83.28  cps  
 Expected-BPS    :      22.94 Mbps  

 Active-flows    :       11  Clients :      252   Socket-util : 0.0001 %    
 Open-flows      :     1508  Servers :    65532   Socket :       11 Socket/Clients :  0.0 
 drop-rate       :       0.00  bps   
 current time    : 18.7 sec  
 test duration   : 99981.3 sec  

Nat_time_out — должно быть ноль, число потоков, за которыми тирекс по каким-то причинам не смог уследить, обычно происходит если пакеты где-то дропают.
Nat_no_fid — должно быть ноль, обычно происходит при слишом больших таймаутах внутри тестируемого оборудования.
Total_nat_active: активное число потоков, должно быть низким при низком rtt.
Total_nat_open: общее число потоков, может отличаться пр однонаправленном (uni-directional) шаблоне.

На самом деле есть еще один важный параметр, который мы не указали --l-pkt-mode нужна эта штука для указания типа пакетов, которыми мы измеряем latency, именно к нему относится ключ -l, к слову, они не учитываются нигде кроме вывода latency, т.е. на параметры типа open-flows влиять не должны.
0 (default) SCTP packets;
1 ICMP с обеих сторон;
2 Stateful, отправляет ICMP с одной стороны и матчит их с другой. Этот параметр имеет смыл, если ваше оборудование дропает пакеты снаружи;
3 отправляет ICMP пакеты всегда с 0 sequence number.

Конец.

Если будет заинтересованность в следующий раз расскажу про изменения в версии 2.06.
Настоятельно рекомендую рассмотреть данный генератор для тестирования ваших проектов, он неприхотлив, доступен, и, самое главное, open source.

Источники

trex-tgn.cisco.com/trex/doc
sdnblog.ru/what-is-intel-dpdk
github.com/cisco-system-traffic-generator/trex-core