И снова здравствуйте, коллеги!

Продолжаем испытывать на прочность российское железо. В прошлый раз мы строили фабрику на коммутаторах Eltex. Поняли на практике, как ее правильно собирать и настраивать. 

Так вот, эта фабрика  до сих пор работает и радует моё инженерное сердце!

Но, как любая игрушка, через неделю она становится просто чем-то, что у тебя есть, а тебе хочется чего-то нового. И тут я вспомнил, как в детстве, вдоволь напускавшись бумажных самолетиков с друзьями, мы придумали сделать что-то ЯРКОЕ. И решили, что горящие самолетики – это круто! Было здорово. 

Знаю, о чем вы могли подумать. Нет, мы не будем поджигать нашу фабрику. ? Но устроим что-то жаркое… Нагрузочное тестирование! Зальем порты доступа гигабайтами трафика.

Что ж, давайте вспомним нашу схему – в оригинале наш оверлей выглядел так:

Вот эти черные прямоугольники с IP-адресами и есть наше конечное оборудование. Те, кто читал статью про фабрику, могут  вспомнить, что для эмуляции конечного оборудования использовался коммутатор Maipu, но он не сгенерирует нужный нам объем трафика.

IXIA, iPerf или TRex. Выбираем генератор трафика

Значит, нужен генератор трафика. IXIA? Дорого. iPerf? Да, но нет. И тут мой коллега (Даниил Селютин, огромное спасибо за помощь!) подсказал, что только-только закончил развертывание  ПО TRex на выделенном сервере, и как раз для целей нагрузочного тестирования (до 100Gbps).

Думаю, уместно будет объяснить такой выбор.

Что такое IXIA? Это прежде всего аппаратная платформа (которой у меня нет), где генерация трафика выполняется на платах аппаратно. Грубо говоря, если вы тестируете 10Gbps интерфейс, то ПО управления формирует только параметры трафика, передает их на модуль 10Gbps, где уже аппаратно, только средствами этого модуля, генерируется трафик. В чем фишка? В отсутствии любой операционной системы и драйверов сетевой карты, которые могут вносить хоть какую-то задержку или не допустить отправку трафика с интерфейса. Но необходимость аппаратно поддерживать такой функционал как раз и делает IXIA дорогой.

iPerf. Это клиент-серверное приложение, которое легко устанавливается, позволяет сгенерировать разный трафик (ограничен уровнем L4), изучить так интересные нам jitter, latency, drop count и прочее, но… Это приложение, использующее ресурсы операционной системы, а значит, весь трафик перед отправкой непосредственно из интерфейса пройдет полный стек драйверов и обработку всякими антивирусами. А нам это надо? (правильный ответ – нет).

А вот что такое TRex?

Не путать с T-Rex:

и T.Rex:

TRex – это генератор трафика, который использует DPDK (Data Plane Development Kit). И именно DPDK отвечает за то, что трафик будет генерироваться средствами самой сетевой карты в обход операционной системы и драйверов. Как это работает и чем отличается от iPerf? Тут всё просто – сетевая карта должна поддерживать DPDK. И по факту, сервер с сетевой картой, которая поддерживает DPDK, становится чем-то вроде IXIA. А чтобы управлять всем этим, как раз и ставится ПО TRex, которое умеет обращаться к DPDK сетевой карты.

Схемы тестирования

Итак, у нас есть сервер TRex с сетевой картой с поддержкой DPDK. Общая схема тестирования с помощью сервера TRex будет выглядеть так:

Для теста мы будем использовать… Тёплая вода – 200 мл, сахар – 1,5 ч.л., соль – 0,5 ч.л., сухие дрожжи – 1,5 ч.л., мука – 300 г, растительное масло – 2 ст.л.

Что-то пиццы захотелось…

Нет, давайте так – для тестОВ у нас будут: 1 Leaf коммутатор, фабрика из одного Pod, Multi-Pod фабрика. То есть наши тесты будут выглядеть так:

Для того, чтобы сервер TRex отправлял и принимал трафик, необходимо на его интерфейсах прописать IP-адреса (за счет использования DPDK TRex напрочь игнорирует прописанные в ОС IP-адреса и генерирует пакеты с требуемыми заголовками пакетов прямо на сетевой карте). Поэтому дополним нашу схему параметрами L1 и L3:

А что будем генерировать-то? Есть целые методики нагрузочного тестирования, разные RFC на эту тему и прочее, но мы (инженеры) — люди простые, поэтому сгенерируем что-то простое:

1. 10G, UDP/1025, frame length 64-1518 (random)

2. 10G, UDP/4789, frame length 64-1518 (random)

3. 10G, UDP/4789+VxLAN, frame length 1518

4. 10G, UDP/4788+VXLAN, frame length 1518

5. 10G, UDP/random, frame length random

Заметили особенность тестов? В первом тесте мы просто сгенерируем трафик, а в тестах 2-4 мы попробуем прогнать трафик VxLAN и псевдотрафик VxLAN через фабрику VxLAN. Другими словами, мы попробуем узнать – можно ли использовать фабрику Eltex для связки других фабрик. У некоторых производителей (например, Huawei) гонять через фабрику пакеты VxLAN запрещено без включения специального режима на порту доступа. А тест номер 5 у нас рассчитан на приближенный к среднему профилю трафика в сети, где разные размеры пакетов и разные Source/Destination порты.

А почему 10G? Да просто потому, что мы тестируем порты доступа на Leaf-коммутаторе, которые работают на MES5410-48 в режиме 10/25, и у нас есть сервер TRex с портами 10G и 100G. И хотя мы можем протестировать на скорости 100G, но ведь это будут уже не порты доступа. Так что тестируем на 10G.

Для управления TRex мы воспользуемся специальной утилитой trex-stateless-gui, скриншоты из которой я и буду проводить.

Тестирование коммутатора Leaf

Схема тестирования коммутатора будет выглядеть следующим образом:

Тест 1.1. 10G, UDP/1025, frame length 64-1518 (random)

Параметры тестирования настроим в упрощенном режиме.

Укажем протокол UDP и размер пакета от 64 до 1518:

Укажем источник и назначение трафика (помните, мы ранее прописали эти IP-адреса на интерфейсах?):

Запустим генератор и посмотрим на результат:

Ой… Выглядит так, будто мы передаем 10G (9.75), а получаем только 1,5М (1.56). Почти весь трафик сбрасывается?!

Быстренько смотрим конфигурацию коммутатора Leaf:

ip vrf A

 vni 30000

 route-target both 1.2.3.4:3000

exit

!

vlan database

 vlan 10-11,20,3000-3001

exit

!

vxlan VLAN10

 vni 20010

 arp-suppression

 vlan 10

 route-target both 10.1.10.0:10

exit

!

vxlan VLAN11

 vni 20011

 arp-suppression

 vlan 11

 route-target both 10.1.11.0:11

exit

!

vxlan VRF_A

 vni 30000 ip-routing

 vlan 3000

exit

anycast-gateway mac-address 12:34:56:78:ab:cd

interface TwentyFiveGigaEthernet1/0/20

 switchport access vlan 10

exit

interface TwentyFiveGigaEthernet1/0/21

 switchport access vlan 11

exit

interface vlan 10

 name CustomerA-1

 ip vrf A

 ip address 10.1.10.1 255.255.255.0

 anycast-gateway

exit

interface vlan 11

 name CustomerA-2

 ip vrf A

 ip address 10.1.11.1 255.255.255.0

 anycast-gateway

exit

Вроде всё стандартно. CPU?

eLeaf1-1#sh cpu utilization

Memory usage

---------------

Total/Free: 8589934592 B/2701144464 B (31%)

CPU utilization service is on.

CPU utilization

---------------

five seconds: 8%; one minute: 8%; five minutes: 9%

Тоже в норме. Забегая наперед, вывод еще одной команды (внимание на «route unknown»):

eLeaf1-1#show cpu input-rate detailed

Traffic type       Rate in pps  Packets count

---------------------- ------------- -------------

stack                  0             0

http                   0             0

telnet                 0             0

ssh                    0             0

snmp                   0             0

ip                     7             7943

arp                    6             14557

arp inspection         0             50

stp                    2             2930

ieee*                  0             439

route unknown          255           724483

ip hop by hop          0             0

mtu exceeded           0             0

ipv4 multicast         0             712

ipv6 multicast         0             0

dhcp snooping          0             0

igmp snooping          0             0

mld snooping           0             0

ttl exceeded           0             0

ipv4 illegal address   0             0

ipv4 header error      0             0

ip DA mismatch         0             0

sflow                  0             0

log deny ACEs          0             0

vrrp                   0             0

log permit ACEs        0             0

ipv6 header error      0             0

multicast routing      0             0

multicast rpf fail     0             0

tcp syn                0             3

vpc                    0             0

* - IEEE: GVRP, LLDP, LACP, etc.

Тогда непонятно.

eLeaf1-1#sh arp | i twe

vlan 10    twe1/0/20       10.1.10.111     b8:3f:d2:28:83:17   dynamic

vlan 11    twe1/0/21       10.1.11.222     b8:3f:d2:28:83:16   dynamic

У всех инженеров, когда всё должно работать, но не работает, мышление примерно одинаковое: «давайте упростим и проверим» или «давайте поменяем и проверим». Вот и давайте упростим – никаких настроек фабрики:

vlan database

 vlan 50-51

ip vrf C

 route-target both 1.2.3.4:3002

exit

interface TwentyFiveGigaEthernet1/0/20

 switchport access vlan 50

exit

!

interface TwentyFiveGigaEthernet1/0/21

 switchport access vlan 51

exit

interface vlan 50

 ip vrf C

 ip address 10.1.10.1 255.255.255.0

exit

!

interface vlan 51

 ip vrf C

 ip address 10.1.11.1 255.255.255.0

exit

Проверим?

Отлично! Работает!

И параметр «route unknown» теперь равен 0:

eLeaf1-1#sh cpu input-rate detailed

     Traffic type       Rate in pps  Packets count

---------------------- ------------- -------------

stack                  0             0

http                   0             0

telnet                 0             0

ssh                    0             0

snmp                   0             0

ip                     5             13022

arp                    2             19860

arp inspection         0             58

stp                    1             4068

ieee*                  0             610

route unknown          0             888767

ip hop by hop          0             0

mtu exceeded           0             0

ipv4 multicast         1             1012

ipv6 multicast         0             0

dhcp snooping          0             0

igmp snooping          0             0

mld snooping           0             0

ttl exceeded           0             0

ipv4 illegal address   0             0

ipv4 header error      0             0

ip DA mismatch         0             0

sflow                  0             0

log deny ACEs          0             0

vrrp                   0             0

log permit ACEs        0             0

ipv6 header error      0             0

multicast routing      0             0

multicast rpf fail     0             0

tcp syn                0             3

vpc                    0             0

* - IEEE: GVRP, LLDP, LACP, etc.

eLeaf1-1#

 Тогда какие настройки начинают сбрасывать пакеты? Накрутим сверху L3VNI:

vlan database

 vlan 3002

vxlan VRF_C

 vni 30002 ip-routing

 vlan 3002

ip vrf C

 vni 30002

interface vlan 3002

 name VRF_C

 ip vrf C

exit

Всё еще работает на полной скорости.

Добавим настройки L2VNI:

vxlan VLAN50

 vni 20050

 arp-suppression

 vlan 50

 route-target both 10.1.10.0:50

exit

!

vxlan VLAN51

 vni 20051

 arp-suppression

 vlan 51

 route-target both 10.1.11.0:51

exit

Работает на полной скорости. Но одной команды ведь не хватает? Включаем:

interface vlan 50

 anycast-gateway

interface vlan 51

 anycast-gateway

И-и-и-и-и???????? Работает?! Да, работает... Но ведь не работало же?

Ладно, обновим таблицу ARP на TRex:

Теперь MAC-адрес соответствует нашей настройке (anycast-gateway mac-address 12:34:56:78:ab:cd). Постойте, а куда делся трафик?! Вот оно!

eLeaf1-1#sh cpu input-rate detailed | i route

route unknown          256           1087802

Получается, что даже после применения команды «anycast-gateway» на интерфейсе Vlan, коммутатор всё равно продолжает отвечать на пакеты, адресованные для MAC-адресов самого интерфейса VLAN и обрабатывает 100% трафика, но как только начинают прилетать пакеты для MAC-адреса anycast gateway – коммутатор сбрасывает их все и параметр «route unknown» становится вместо 0 равен 256. Звоним разработчикам…

Как же приятно общаться с технически грамотными инженерами! Причину проблемы мы определили за 5 минут, и чтобы не вдаваться в подробности, расскажу суть: как только мы включаем функционал Anycast gateway и используем VxLAN фабрику для передачи трафика, то из-за того, что адрес VTEP source и VTEP destination – это один и тот же адрес,  – то коммутатор (из-за внутренней архитектуры) выводит обработку трафика с аппаратной части на CPU. Это мы и видим, когда используем команду «sh cpu input-rate detailed». Параметр «route unknown» имеет значение 256 (это максимальное значение для данного параметра), включается защитный механизм и пакеты сбрасываются.

То есть пока я обращаюсь на MAC-адреса интерфейсов VLAN – механизм фабрики не используется, а как только я обращаюсь на MAC-адрес Anycast gateway и IP-адрес VTEP source и VTEP destination – это один и тот же IP-адрес (то есть передача трафика в рамках одного коммутатора Leaf), то трафик уходит на обработку CPU и сбрасывается. Я, на самом деле, рад, что в ПО заложен механизм, защищающий Management plane и Control Plane коммутатора, потому как зачастую CPU бы просто ушел в 100% загрузки и у меня пропал бы доступ. За это лайк. Но проблема есть, а ее надо решать. К счастью, разработчики уже знают об этой проблеме и исправили ее в новой версии ПО, которой со мной поделились (на момент написания статьи данная версия еще не была опубликована и проходила внутреннее тестирование). Ладно, побудем бета-тестерами. К тому же нам это очень нужно и важно.

<здесь пропущен процесс обновления коммутатора, который, на секундочку, я выполнил с помощью ECCM!>

После перезагрузки на новой версии ПО:

eLeaf1-1#sh cpu input-rate detailed | i route

route unknown          0             59661

Работает!

Теперь понимаете, в чем преимущество нагрузочного тестирования в отличие от проверки связности? Можно собрать полностью рабочую схему, где все друг друга видят, но как только пойдет реальный трафик…

Для чистоты дальнейшего эксперимента я верну все предыдущие настройки, оставлю новую версию ПО (и обновлю остальные коммутаторы). Дальнейшее тестирование будет именно в рамках настроенной нами фабрики. Всё работает.

А еще мы можем проверить с помощью перехваченных пакетов, что профиль трафика реально соответствует тому, что мы настроили:

Да, очень похоже.

Тест 1.2. 10G, UDP/4789, frame length 64-1518 (random)

Тест, фактически, полностью идентичен тесту 1, но есть нюанс. Когда пакет от конечного оборудования приходит на порт доступа, он упаковывается в VxLAN заголовок, который имеет вид UDP/4789. А что, если мы сразу отправим в такой порт трафик, уже имеющий заголовок UDP/4789, но пока не имеющий самого заголовка VxLAN (как Upper Layer протокол)?

Параметры потока:

Результаты тестирования:

Трафик полностью передается.

Тут есть интересный момент:  если заглянем внутрь любого пакета, то, несмотря на то, что мы не добавляли заголовок VxLAN, там есть пустой заголовок VxLAN:

К этому моменту мы еще вернемся.

Тест 1.3. 10G, UDP/4789+VxLAN, frame length 1518

Здесь мы прямо в параметрах пакета сразу добавили заголовок VxLAN:

Получаем такой же результат – 100% прохождение трафика:

Тест 1.4. 10G, UDP/4788+VXLAN, frame length 1518

А вот тут немного интереснее. Мы используем другой порт UDP (4788), но добавим Upper Layer заголовок VxLAN:

Проверим как коммутатор отрабатывает:

Потерь нет. Трафик соответствует ожиданиям:

Но если откроем любой пакет, то:

Где наш заголовок VxLAN?

Захватим несколько пакетов и откроем их в Wireshark. Общий список совпадает:

И содержимое пакета тоже не содержит данных о VxLAN:

Для сравнения – вот так выглядит содержимое пакета в Wireshark, когда мы просили TRex отправлять просто пакеты UDP/4789 без VxLAN заголовка:

Отложим немного обсуждение данного поведения.

Тест 1.5. 10G, UDP/random, frame length random

Результаты тестирования:

Выводы

В любом случае мы видим, что все тесты выполняются на полной скорости без потерь: это основная задача, которую мы хотели проверить.

Но почему же тесты 2 и 4 показывают нам информацию, которую мы не закладывали в генератор трафика? Давайте подумаем: из чего состоит наш тестовый стенд?

1. Коммутатор. Он не вносит никаких изменений в пакеты данных.

2. Генератор трафика. Может он генерировать трафик, который мы не ожидаем? Да.. Но доверия к таким генераторам трафика уже не было бы. Только если это какая-то внутренняя ошибка.

3. Утилита для запуска генерации трафика trex-stateless-gui. Может она передавать на TRex неправильную конструкцию пакета данных? Несомненно. Опять же, если есть какая-то ошибка в коде.

4. Догадаетесь об еще одном компоненте? На который и подумать-то сразу не получится… Packet viewer/Wireshark!

Проведем пару забавных тестов: там, где мы в тесте 1 нормально отправляли UDP/1025 (какой-то no-name порт), просто поменяем порт на 53 (well known DNS port) и 67 (well known BOOTP server port aka DHCP), и проверим в Packet viewer/Wireshark.

UDP/53 в Packet Viewer:

UDP/67 в Wireshark:

И тот и другой (на одном и том же движке) сами додумывают на основании номера порта (только well known), что выше должен быть соответствующий заголовок, хотя, если разбирать пакет побайтно (не стал здесь приводить выкладку), то пакет генерируется именно в том формате, как мы его и придумали. То есть именно просмотрщики выдают фейковую информацию! Всегда учитывайте в своих лабораторных стендах ВСЕ компоненты, участвующие в тестировании, иначе, несмотря на реально успешный результат, вы можете ошибочно выдать неправильное заключение.

Ну а нам есть смысл свести в таблицу полученные результаты:

Далее для сокращения текста я не буду дублировать параметры профилей сетевого трафика, так как содержимое тестов одинаково.

Тестирование фабрики

Схема тестирования фабрики будет выглядеть следующим образом:

Тест 2.1. 10G, UDP/1025, frame length 64-1518 (random)

Сразу результат:

Для честности приведу вывод с коммутаторов eLeaf1-1 и eLeaf1-2:

eLeaf1-1#sh int twe1/0/20 | i rate

  15 second input rate is 9749434 Kbit/s

  15 second output rate is 0 Kbit/s

eLeaf1-2#sh int twe1/0/20 | i rate

  15 second input rate is 0 Kbit/s

  15 second output rate is 9597473 Kbit/s

Всё хорошо. Пробежимся по остальным тестам.

Тест 2.2. 10G, UDP/4789, frame length 64-1518 (random)

Результаты тестирования:

Трафик полностью передается.

Тест 2.3. 10G, UDP/4789+VxLAN, frame length 1518

Результаты тестирования:

100% потеря трафика?! А что на интерфейсах вообще творится?

eLeaf1-1#sh lldp neighbors

System capability legend:

B - Bridge; R - Router; W - Wlan Access Point; T - telephone;

D - DOCSIS Cable Device; H - Host; r - Repeater;

TP - Two Ports MAC Relay; S - S-VLAN; C - C-VLAN; O - Other

   Port        Device ID          Port ID               System Name           Capabilities  TTL

---------- ----------------- ----------------- ------------------------------ ------------ -----

hu1/0/5    90:54:b7:82:53:80      hu1/0/1                eSpine1-1                B, R      95

hu1/0/6    90:54:b7:82:6a:c0      hu1/0/1                eSpine1-2                B, R      114

eLeaf1-1#sh int hu1/0/5 | i rate

  15 second input rate is 4 Kbit/s

  15 second output rate is 3 Kbit/s

eLeaf1-1#sh int hu1/0/6 | i rate

  15 second input rate is 78 Kbit/s

  15 second output rate is 10184527 Kbit/s

Ага, трафик уходит через интерфейс Hu1/0/6 в сторону eSpine1-2. А на самом Spine?

eSpine1-2#sh int hu1/0/1 | i rate

  15 second input rate is 10193554 Kbit/s

  15 second output rate is 80 Kbit/s

Входящий трафик есть. А вот трафика в сторону eLeaf1-2 уже нет:

eSpine1-2#sh int hu1/0/2 | i rate

  15 second input rate is 2 Kbit/s

  15 second output rate is 3 Kbit/s

А давайте попробуем уменьшить размер пакета, чтобы понять: у нас трафик сбрасывается из-за типа трафика или размера пакетов?

Интересненько. То есть VxLAN пакеты пролетают, если размер пакета сделать меньше… А что там у нас с MTU?

eLeaf1-1#show ports jumbo-frame

 Jumbo frames are disabled (current MTU 2048 bytes)

 Jumbo frames will be disabled after reset (MTU 2048 bytes after reset)

 Default protocol MTU will be set to 1500 after reset

eSpine1-1#show ports jumbo-frame

 Jumbo frames are disabled (current MTU 2048 bytes)

 Jumbo frames will be disabled after reset (MTU 2048 bytes after reset)

 Default protocol MTU will be set to 1500 after reset

Не было, не было, и вот опять… Ладно, настраиваем:

eSpine1-1(config)#port jumbo-frame

This setting will take effect only after copying running configuration to startup configuration and resetting the device

После перезагрузки:

eLeaf1-1#show ports jumbo-frame

 Jumbo frames are enabled (current MTU 10240 bytes)

 Jumbo frames will be enabled after reset (MTU 10240 bytes after reset)

 Default protocol MTU will be set to 9000 after reset

eSpine1-1#show ports jumbo-frame

 Jumbo frames are enabled (current MTU 10240 bytes)

 Jumbo frames will be enabled after reset (MTU 10240 bytes after reset)

 Default protocol MTU will be set to 9000 after reset

Теперь снова ставим размер пакета 1518 и запускаем тест:

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

Побежали дальше!

Тест 2.4. 10G, UDP/4788+VXLAN, frame length 1518

Результаты тестирования:

Потерь нет. Трафик соответствует ожиданиям:

Тест 2.5. 10G, UDP/random, frame length random

Результаты тестирования:

Выводы

Обратили внимание, что при тестировании фабрики мы выявили проблему, которую не определили при тестировании одного коммутатора? И опять же выяснили с помощью нагрузочного тестирования. То есть при организации тестирования очень важны методологии и понимание правильного размещения тестирующего оборудования.

Сведем в таблицу полученные результаты (после исправления, конечно):

Тестирование фабрики Multi-Pod

Схема тестирования фабрики Multi-Pod будет выглядеть следующим образом:

Тест 2.1. 10G, UDP/1025, frame length 64-1518 (random)

Сразу результат:

Для честности приведу вывод с коммутаторов eLeaf1-1 и eLeaf2-1:

eLeaf1-1#sh int twe1/0/20 | i rate

  15 second input rate is 9752889 Kbit/s

  15 second output rate is 0 Kbit/s

eLeaf2-1#sh int twe1/0/20 | i rate

  15 second input rate is 0 Kbit/s

  15 second output rate is 9740784 Kbit/s

Выглядит здорово.

А помните, как в прошлой статье мы с вами рассматривали, почему балансировка по Port-Channel – это плохо? Давайте посмотрим, как на eSpine2-1 выглядит загрузка интерфейсов под нагрузкой?

eSpine2-1#sh lldp neighbors

System capability legend:

B - Bridge; R - Router; W - Wlan Access Point; T - telephone;

D - DOCSIS Cable Device; H - Host; r - Repeater;

TP - Two Ports MAC Relay; S - S-VLAN; C - C-VLAN; O - Other

   Port        Device ID          Port ID               System Name           Capabilities  TTL

---------- ----------------- ----------------- ------------------------------ ------------ -----

hu1/0/1    90:54:b7:4e:58:00      hu1/0/5                 eLeaf2-1                B, R      117

hu1/0/2    90:54:b7:4e:58:00      hu1/0/6                 eLeaf2-1                B, R      117

<пропущено>

eSpine2-1#sh int hu1/0/1 | i rate

  15 second input rate is 0 Kbit/s

  15 second output rate is 0 Kbit/s

eSpine2-1#sh int hu1/0/2 | i rate

  15 second input rate is 0 Kbit/s

  15 second output rate is 10373645 Kbit/s

Только 1 из 2-х интерфейсов в Port-Channel передает трафик.

Вендор, кстати, обещает в будущих версиях исправить такое поведение, чтобы трафик балансировался равномерно.

Тест 2.2. 10G, UDP/4789, frame length 64-1518 (random)

Результаты тестирования:

Трафик полностью передается.

Тест 2.3. 10G, UDP/4789+VxLAN, frame length 1518

Результаты тестирования:

Тест 2.4. 10G, UDP/4788+VXLAN, frame length 1518

Результаты тестирования:

Потерь нет. Но… Постойте, а куда делись еще 3 Gb/s ?! Нормально же общались, что началось-то? А почему CPU взлетел?

Кажется, наш TRex немного устал…

Ладно, бывает. Рестартанем TRex и повторим тест.

Ну вот, другое дело!

И вот что мы смогли опять интересного заметить – всегда следует анализировать все факторы, которые могут повлиять на результаты тестирования, ведь если бы мы не заметили, что объем трафика упал до 6 Gb/s, то дальнейшие тестирования были бы недействительными, так как тесты проходили бы уже на меньшей скорости.

Тест 2.5. 10G, UDP/random, frame length random

Результаты тестирования:

Выводы

Самые скучные тесты – Multi-Pod… Не, ну а что, всё уже работает как часы, всё стабильно, всё надежно, всё ожидаемо. Ладно, пусть будет…

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

Сведем в таблицу полученные результаты:

Выводы

Самое главное для нас и для производителя – это рабочее оборудование, рабочий дизайн, соответствие заявленным характеристикам производительности. Мы это увидели, доказали, а заодно познакомились с видами генераторов трафика и даже воспользовались одним из них для того, чтобы понять несколько важных моментов:

• нагрузочное тестирование очень важно при проектировании/внедрении ЛВС. Если у вас есть возможность заложить в проект нагрузочное тестирование – воспользуйтесь этой возможностью;

• нагрузочное тестирование важно выполнять до запуска ЛВС в промышленную эксплуатацию. Исправлять что-то после боевого запуска информационных систем может стать большой проблемой для бизнеса;

• очень важно грамотно определить схемы тестирования и параметры тестов. Для этого можно, конечно, воспользоваться специальными методиками и RFC, но цели тестирования, тем не менее, определяются именно вами;

• очень важно постоянно отслеживать все параметры и характеристики тестируемого оборудования (например, трафик проходит по ожидаемому пути?) и тестирующего оборудования (а точно генерируется 10 Gb/s ?)

Конец

Надеюсь, что вы открыли для себя нагрузочное тестирование как очень продуктивный инструмент диагностики. Если это так, то цель достигнута, а значит, можно переключиться на написание следующей статьи. Мы с вами попробуем понять, насколько совместимо оборудование Eltex с другими вендорами (пусть это будут вендоры «C» и «H»), ведь вопросы импортозамещения всё еще актуальны. Да и чем-то надо заменять вышедшее из строя оборудование.