Skip to content
Все статьи
Маршрутизация и коммутация

Как мы тестируем коммутаторы: 64 байта, full mesh, таблица MAC

Alexander Zemskov 4 мин чтения
Как мы тестируем коммутаторы: 64 байта, full mesh, таблица MAC

В тендере на коммутатор агрегации про производительность обычно одна строка: «wire speed на всех портах». Каждый вендор из шорт-листа ставит галочку, и каждая галочка честная на кадрах 1518 байт и паре портов. Реальный трафик выглядит иначе: от 40 до 60% пакетов короче 128 байт, 48 портов работают одновременно, серверы шлют пачками, таблица MAC растет с каждой виртуальной машиной. Мы тестируем коммутатор или роутер в таком трафике до заказа и еще раз перед каждым обновлением прошивки.

Стенд

Устройство стоит в стойке CloudLAB, порты 1G, 10G или 100G (400G и быстрее – под проект) подключены к генератору. Для full mesh за каждым портом коммутатора под тестом стоит свой порт генератора, от 8 до 48, все на одних часах, поэтому каждый кадр считается с обеих сторон по номеру и метке времени. Сначала порты генератора закольцовываются через те же кабели и оптику: 100% line rate на 64 байтах без потерь, поэтому любая потеря потом относится к устройству.

Конфигурация та, с которой вы будете работать: VLAN и Q-in-Q, режим STP, члены LAG, ACL, QoS, время старения MAC. Трафик берем из вашей выгрузки NetFlow или дампа; без них используем 7 размеров кадра из RFC, от 64 до 1518 байт, IMIX и jumbo-кадры, если их гоняет ваша сеть хранения. Роутеры и фабрики EVPN идут на том же стенде, подробнее на странице маршрутизации и коммутации.

Что проверяем

  • Форвардинг по размерам кадра по RFC 2544: throughput без потерь бинарным поиском в 60-секундных прогонах, latency, доля потерь кадров от 100% нагрузки вниз, пачки back-to-back; один потерянный кадр, и шаг не засчитан
  • Full mesh по RFC 2889: каждый порт шлет на все остальные; throughput и forwarding rate против теоретической линии
  • Перегрузка: блок из 4 портов, на один порт подается 150%; потери на свободном порту означают head-of-line blocking, ноль потерь на перегруженном означает, что backpressure притормозил ваши источники
  • Таблица MAC: емкость бинарным поиском до первого кадра во flood, затем скорость обучения на этой емкости; строка «32K MAC» в даташите может превратиться в 16 384
  • Буферы и microburst: пачки many-to-one до 930 кадров, длина back-to-back, latency с пачками в миксе
  • Broadcast: forwarding rate и latency до каждого порта, 1% broadcast внутри unicast-прогона
  • VLAN, LAG и STP: распределение по членам LAG, отказ члена LAG и активного пути STP под трафиком, окно потерь в миллисекундах
  • Обновление прошивки: те же пункты на новом релизе, сдвиг по каждому KPI

Что обычно ломается

Колонка 64 байта. Типичный шорт-лист: 2 роутера агрегации, у обоих в даташите «wire speed». Первый держит line rate до 128 байт и дает 92% на 64. Второй на 64 байтах пропускает 38% line rate. Если 47% кадров в вашей сети короче 128 байт, более дешевая коробка с первого дня медленнее в 2,4 раза.

Фабрика. Leaf на 48 портов с отчетом вендора «wire speed на паре портов» в full mesh на 24 портах и 64 байтах пропускает 71% line rate. Блок перегрузки объясняет почему: 9% потерь на порту, где перегрузки не было, head-of-line blocking от общего входного буфера. В сети хранения это значит, что один занятый хост тормозит соседей.

Буфер. Latency держится на 1,2 мкс до 70% нагрузки и прыгает до 38 мкс на 80%, когда в микс добавлены microburst: общий буфер меньше, чем следует из даташита. Посекундные счетчики коммутатора это усредняют, метки времени генератора на каждом кадре ловят.

Что в отчете

Throughput, latency, потери и длину пачки по каждому размеру кадра, таблицами и графиками рядом с цифрой из даташита. Результаты full mesh и блока перегрузки с вердиктом по HOLB и backpressure. Емкость таблицы MAC и скорость обучения со счетчиками flood. Окна потерь при отказах LAG, STP и линков. Экспорт конфигурации и сырые счетчики по каждому прогону. Для шорт-листа: одну таблицу на всех кандидатов и тест-план для приложения к тендеру, чтобы победителя можно было проверить еще раз при поставке.

С чего начать

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

Автор

Alexander Zemskov

Эксперт по тестированию сетей и безопасности, продажи (19+ лет) | Performance & Load Testing | IXIA | Spirent | Keysight | Xena | Xinertel и другое

Блог

Читайте также

СХД и дата-центры

Как мы тестируем гиперконвергентные кластеры: отказ узла и p99

Сайзинг HCI отвечает на один вопрос: сколько VM поместится на 4 узла, если один держать в резерве. Считают его на здоровом кластере. Заказчик читает «N+1» и ждет, что отк…

Alexander Zemskov 4 мин чтения
СХД и дата-центры

Как мы тестируем NAS: NFS, SMB, метаданные и отказ контроллера

В даташите NAS одна цифра: последовательное чтение в GB/s, снятое на больших файлах с нескольких клиентов. На ресурсе с домашними каталогами или на сборочной ферме сотни …

Alexander Zemskov 4 мин чтения