Кратко

  • Результат RFC 5180 относится к объявленному лабораторному профилю: размерам кадров, адресному распределению, длинам префиксов, состоянию соседей, направлению, цепочке заголовков, фильтрам, портам и сборке устройства.
  • Hop-by-Hop проверяется нагрузкой 1%, 10% и 50% с наблюдением ресурсов, поскольку цель — стоимость обработки, а не обычный throughput. После RFC 8200 требуется также доказать явную конфигурацию обработки на узле.

На разборе аварии прозвучал сильный аргумент: это оборудование проходило IPv6 benchmark на полной скорости. Затем инженеры открыли профиль. Лаборатория использовала один порт, крупные кадры, один destination, статических соседей и пустую политику. Авария возникла на нескольких портах, в одном направлении, с малыми пакетами и фильтром, который искал Layer 4 за extension headers.

Результат не был ложным. Он оказался квитанцией от другой исполняемой машины.

RFC 5180 опубликован в 2008 году как Informational RFC, дополняющий RFC 2544 и использующий терминологию RFC 1242. Документ требует учитывать повторяемость, разброс и статистическую значимость малого числа trials. Он не утверждает, что все поставщики и операторы применили один профиль. Тем более он не переносит лабораторную характеристику в production без отдельного наблюдения.

Реконструкция начинается с кадров

Для Ethernet методика называет 64, 128, 256, 512, 1024, 1280 и 1518 байт. При одинаковой битовой скорости малые кадры создают намного больше решений в секунду. Большие кадры удобны для высокой цифры Gbit/s. Поэтому первый вопрос после инцидента — какая точка кривой соответствует проблемному трафику.

Сама физическая граница имеет допуск. Теоретические Ethernet rates требуют учёта clock slop плюс-минус 100 ppm. На Packet over SONET bit stuffing способен менять frame rate. Две цифры после запятой в отчёте не могут отменить неопределённость среды.

Следом восстанавливается destination set. Один source-destination pair может удерживать cache и узкий lookup path в тёплом состоянии. Random destination исполняет другую работу. RFC 5180 предлагает оба варианта и рекомендует /48, /64, /126 и /128 как важные prefix boundaries. Без range и распределения максимальный результат нельзя сопоставить с аварийным потоком.

Направление указывает на механизм

RFC рекомендует bidirectional traffic, но предупреждает: такой тест показывает лишь меньшую производительность двух направлений. Для асимметрии нужны unidirectional runs. Это особенно важно при расследовании: ingress и egress могут иметь разные ACL, classification и размер пакетов.

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

Port scale даёт ещё одну развилку. Single-port измеряет interface, multi-port — масштабирование platform. Общими могут быть fabric, memory, lookup или software path. Умножение результата порта на их число не доказывает поведение chassis.

IPv4/IPv6 mix тоже меняет исполняемый механизм. Матрица содержит IPv4-only, IPv6-only, а также 90/10, 50/50 и 10/90. Успех чистого IPv6 не оправдывает совместные ресурсы под смешанной нагрузкой. При расследовании нужно найти именно тот ratio, который действовал, а не наиболее удобную строку старого отчёта.

Hop-by-Hop требует доказательства пути

RFC 5180 предлагает тестировать extension headers по отдельности и затем цепочкой. Для честного сравнения при малых размерах трафик с заголовками и без них использует общий минимальный frame size. Иначе изменение геометрии пакета будет ошибочно названо стоимостью протокола.

Для Hop-by-Hop цель иная. Трафик подаётся на 1%, 10% и 50% интерфейсной полосы, а ресурсы наблюдаются. Это не поиск обычного максимального throughput, а измерение processing impact. CPU и memory собираются out-of-band, независимо от тестовых interfaces. Такие данные помогают отличить hardware path от recirculation, software forwarding или давления на control plane.

Временная граница принципиальна. RFC 5180 опирался на модель RFC 2460. RFC 8200 позднее сформулировал ожидание: промежуточные узлы рассматривают и обрабатывают Hop-by-Hop только при явной конфигурации. RFC 7045 уже допускал игнорирование или slow path на высокопроизводительных routers. RFC 9098 описывает ограничения lookup depth, повторный проход, software path и drop.

Значит, packet capture без configuration receipt не завершает расследование. Нужны option content, offered rate, duration, protection policy и resource curve. Одинаковый пакет может запустить разные механизмы. Падение throughput само не доказывает ни тип пути, ни устойчивость к атаке.

Neighbor state и filters восстанавливают контекст

RFC разрешает статических соседей и dynamic Neighbor Discovery. Динамический режим предпочтителен, если tester поддерживает cache активным. Эмулированные endpoints расположены на один hop за DUT, чтобы не вызвать NS/NA storm из-за Neighbor Unreachability Detection.

Это делает neighbor mode частью профиля. Static entry, постоянное refresh и cache expiry создают разные transitions. Если production сбой произошёл при перестроении cache, статический лабораторный run не является алиби.

Filters и routing-table size работают так же. Устройство, которому нужно добраться до upper-layer информации за цепочкой заголовков, может включить глубокий parser или другой stage. Один filter и двадцать пять filters могут иметь разные пути. Тест без policy не измеряет систему, ценность которой заключается в policy enforcement.

System recovery после overload следует отличать от recovery после device или software reset. RFC также не рекомендует back-to-back frames для IPv6 из-за существенной краткосрочной variance. Отсутствие нестабильной метрики — не отсутствие инженерной дисциплины.

Изолированный стенд не видел production

Benchmark topology должна быть независимой и не иметь пути для тестового traffic в production или management network. Наблюдение ведётся как black box снаружи DUT/SUT. Специальных benchmark-only функций быть не должно.

Эти правила защищают чистоту опыта. Одновременно они ограничивают его авторитет. Лаборатория намеренно убирает routing churn, queue interaction, общие failure domains, неоднородные builds, операционные политики и пользователей. После аварии нельзя вернуть их в вывод одной фразой.

Даже address space отмечает границу. Опубликованный текст RFC содержал verified technical erratum. Текущий IANA registry указывает 2001:2::/48 для benchmarking и отмечает его как not globally reachable. Корректный префикс помогает не смешать стенд с эксплуатационным пространством.

Scope технологии тоже проверяется. RFC 8219 выносит translation и encapsulation за пределы RFC 5180 и добавляет методику для state и overload. Dual stack можно оценивать RFC 2544 и RFC 5180; stateful transition gateway требует других receipts.

Как закрыть расследование

Сохранить immutable profile ID и связать с ним device, build, features, ports, media, topology, tester, clocks, frame series, destination distribution, prefixes, neighbor mode, extension headers, filters, routes, control traffic, direction, IP mix, load, duration, trial count, loss, latency, samples, out-of-band resources, recovery method и deviations.

Затем сопоставить профиль с аварийным путём. Method owner отвечает за вопрос, lab operator — за выполнение, statistics reviewer — за разброс, release owner — за эквивалентность build, operations — за безопасное production observation. Только цепочка может показать, применим ли старый результат.

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

Источники

  1. RFC 5180 — HTML
  2. RFC 5180 — текст
  3. Информация RFC Editor
  4. Документ IETF Datatracker
  5. История Datatracker
  6. Ссылки Datatracker
  7. Errata RFC 5180
  8. RFC 2544
  9. RFC 1242
  10. RFC 8200
  11. RFC 7045
  12. RFC 9098
  13. RFC 4861
  14. RFC 8201
  15. RFC 6890
  16. IANA IPv6 Special-Purpose Address Registry
  17. RFC 8219
  18. Heng Lu — слои реальности
  19. Heng Lu — минимальная спецификация и добровольное принятие
  20. Heng Lu — приоритет работающего кода