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

Как мы тестируем пакетные брокеры: дедупликация и slicing

Alexander Zemskov 4 мин чтения
Как мы тестируем пакетные брокеры: дедупликация и slicing

В даташите пакетного брокера перечислены line rate на всех портах, дедупликация, packet slicing, снятие туннельных заголовков и несколько тысяч правил фильтрации. Каждая строка верна, пока функцию проверяют отдельно. Служба ИБ рассчитывает на большее: IDS, система записи и APM-зонд видят каждый пакет один раз и целым. Загрузите полную таблицу правил, включите 3 функции, сведите 12 сетевых портов в один порт инструмента, и брокер начинает сам решать, что выбросить. Мы измеряем, что доходит до каждого инструмента, пакет за пакетом, и сверяем с тем, что вошло в брокер.

Стенд

Брокер ставится на стенд CloudLAB с портами 1G, 10G или 100G (400G – под проект). Порты генератора стоят с обеих сторон: со стороны сети они заменяют TAP и SPAN-сессии, со стороны инструментов играют роль IDS, системы записи и зондов. Каждый пакет, который получил бы инструмент, считается, сверяется побайтно и получает метку времени. В нашей собственной лаборатории брокеры тоже работают на захвате 10G и 100G, и их счетчики потерь редко показывают всю картину, поэтому на стенде обе стороны считает генератор.

Трафик повторяет вашу сеть: микс из выгрузки NetFlow или дампа, теги VLAN и Q-in-Q, VXLAN, стеки меток MPLS и GRE там, где они есть в ваших линках, IPv4 и IPv6. Дубликаты закладываются специально, с тем сдвигом, который дают ваши точки SPAN, от микросекунд до миллисекунд. Конфигурация – ваша карта фильтров с реальным числом правил, группами инструментов и цепочкой функций.

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

  • Фильтрация на полной таблице: ваше число правил, от L2 до L4, IPv4 и IPv6, line rate по размерам кадра бинарным поиском по RFC 2544; каждый порт инструмента получает все пакеты, подходящие под его правила, и ничего лишнего
  • Дедупликация: доля удаленных дубликатов против настройки окна, копии, пришедшие позже окна, оригиналы, удаленные по ошибке, включая повторные передачи TCP
  • Packet slicing: длина среза держится точно, у обрезанного кадра корректный FCS, исходная длина сохраняется там, где она нужна инструменту
  • Снятие заголовков: VXLAN, GRE, стеки MPLS из 1–3 меток и глубже, теги VLAN; внутренний пакет без искажений и судьба незнакомой инкапсуляции
  • Балансировка на инструменты: оба направления сессии попадают на один инструмент, распределение по группе, отказ одного инструмента и число разорванных сессий
  • Метки времени: метка брокера против времени отправки на генераторе для каждого пакета, смещение и разброс; если брокер берет время по PTP, генератор эмулирует источник, а полный анализ time error согласуется под проект
  • Агрегация: много сетевых портов в один порт инструмента при средней нагрузке ниже line rate и с microburst; потери по длине всплеска и глубина буфера, которую они показывают
  • Изменение правил под нагрузкой: правило добавлено или удалено при идущем трафике, провал на нетронутых правилах, время до срабатывания нового правила

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

Функции вместе. В типичном проекте брокер дедуплицирует на line rate 10G, пока дедупликация единственная функция на порту. Со снятием VXLAN перед ней и полной таблицей правил тот же модуль пропускает 6,2 Гбит/с пакетов по 128 байт, дальше теряет. В даташите обе функции заявлены на line rate, отдельными строками.

Порт инструмента. 12 сетевых портов 10G сведены в один порт IDS 10G, средняя нагрузка 55%. Поминутный счетчик брокера показывает 0,02% потерь. Генератор насчитывает 4% потерянных пакетов внутри каждого всплеска, всегда в начале самой нагруженной секунды, ровно тогда, когда запись нужнее всего. Дыры в дампе никто не замечает до дня, когда он понадобился. Механика буфера та же, что у коммутатора, подробнее в посте как мы тестируем коммутаторы.

Коммит правил. Один новый фильтр в таблице из 2 000 перекомпилирует всю таблицу, и все порты инструментов теряют трафик на 180 мс, включая правила, которые никто не трогал. Раз в неделю это незаметно. При автоматизации, которая отправляет изменения каждые несколько минут, это постоянный провал в доказательной базе.

Что в отчете

По каждому порту инструмента: пакеты ожидаемые, доставленные, потерянные, задвоенные и измененные, для каждой комбинации функций и размера кадра, рядом с цифрой из даташита. Дедупликация против настройки окна, потери по длине всплеска для каждого коэффициента агрегации, распределение хеша и разорванные сессии, смещение и разброс меток времени, провал при каждом коммите правил. Экспорт конфигурации, сырые счетчики по каждому прогону и дампы тех секунд, где пропали пакеты. Для шорт-листа: одну таблицу на всех кандидатов и тест-план для приложения к тендеру.

С чего начать

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

Автор

Alexander Zemskov

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

Блог

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

Маршрутизация и коммутация

Как мы тестируем PoE: бюджет мощности, приоритеты и отказ БП

В даташите PoE-коммутатора покупатель читает две строки: «PoE+ на всех 48 портах» и бюджет мощности, например 740 Вт. 48 портов по 30 Вт дают 1440 Вт. Обе строки честные,…

Alexander Zemskov 4 мин чтения
Стандарты и методика

Как мы автоматизируем регрессию сети: каждая сборка и один diff

В release notes новой прошивки написано «исправления ошибок и улучшения производительности». Вторую половину фразы никто не измеряет. Ручная регрессия занимает у инженера…

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