Skip to content

Методология · Бенчмаркинг коммутаторов и маршрутизаторов

RFC 2544: тест без единого потерянного кадра для коммутаторов и маршрутизаторов

RFC 2544 с 1999 года остаётся стандартным тестом forwarding plane: 7 размеров кадра, 60-секундные прогоны и одно правило для throughput, ноль потерянных кадров. На этой странице метод в том виде, в каком мы прогоняем его в CloudLAB: откуда обычно берётся цифра в даташите и что вы получаете в отчёте.

  • 7 размеров кадра от 64 до 1518 байт, каждый тестируется отдельно: честная колонка та, что на 64 байтах
  • Throughput ищется бинарным поиском; 1 потерянный кадр за 60 с проваливает шаг
  • 6 тестов в RFC: throughput, latency, frame loss, back-to-back, system recovery и reset
Получить тест-план RFC 2544 К 6 тестам
ZERO-LOSS THROUGHPUT % OF LINE RATE · RFC 2544 §26.1 LINE RATE · 100% 50% 41% 68% 99% 100% 100% 100% 100% PPS-BOUND: THE LOOKUP ENGINE 64 B 128 B 256 B 512 B 1024 B 1280 B 1518 B Zero frames lost, or the step does not count

Типичный результат L3-устройства. На 1518 байтах провод никогда не предел. На 64 байтах forwarding engine должен обработать 14,88 млн lookup в секунду на порту 10 GbE, и настоящая цифра живёт именно там.

Где применяется

Один метод, один вопрос: сколько кадров в секунду коробка пропустит, не потеряв ни одного?

RFC 2544 (Benchmarking Methodology for Network Interconnect Devices) опирается на термины RFC 1242 и считает устройство чёрным ящиком: кадры вошли в один порт, вышли из другого, счётчики с обеих сторон. Stateless, L2 и L3, только лаборатория.

Что измеряет

Forwarding plane: throughput, latency, frame loss и ёмкость back-to-back burst по каждому размеру кадра, плюс время recovery и reset. Коммутаторы, маршрутизаторы, L3 ASIC, виртуальные маршрутизаторы, SD-WAN в режиме pass-through, DPU.

Чего не измеряет

Ничего stateful и ничего на живой сети. Firewall и NGFW идут в RFC 9411, carrier Ethernet сервис в ITU-T Y.1564, поведение TCP в RFC 6349. RFC 6815 говорит это прямо в заголовке: RFC 2544 на production-сети considered harmful.

Семейство вокруг него

RFC 2889 добавляет специфику LAN-коммутаторов: изучение адресов, congestion control, head-of-line blocking, full mesh. RFC 5180 переносит те же тесты на IPv6. RFC 3918 закрывает multicast. Когда устройство того требует, мы собираем их в один тест-план.

Бесплатный шаблон

Шаблон тест-плана RFC 2544

План, который мы заполняем перед каждым тестом коммутатора или маршрутизатора, в PDF: устройство и стенд, 6 тестов с параметрами, лист результатов для всех 7 размеров кадра, таблица line rate и чек-лист отчёта.

  • Готов к приложению к тендеру или запросу предложений
  • Одинаковые параметры и критерии для всех вендоров и лабораторий
  • В конце перечислены ошибки, которые меняют результат

PDF на английском. Нужна только почта.

Тестовый стенд

2 порта тестера, 1 устройство, счётчики на обоих концах

RFC 2544 §4 требует тестер, который отправляет и принимает на одном приборе: каждый кадр считается с обеих сторон по одним часам. Программный генератор на сервере эту планку не берёт, аппаратный порт берёт.

HARDWARE TESTER · PORT A TX + RX · ONE CLOCK FOR BOTH SIDES FRAME STREAM 64 · 128 · 256 · 512 · 1024 · 1280 · 1518 B Sequence number + hardware timestamp per frame 256 source and destination addresses per port Learning frames first, counters cleared, 60 s trial 1 GbE · 10 · 25 · 100 · 400 GbE PORTS BIDIRECTIONAL DUT SWITCH · ROUTER · L3 ASIC · VIRTUAL ROUTER Production configuration, exported to the report Interface counters read after every trial BLACK BOX · FRAMES IN, FRAMES OUT STORE & FORWARD CUT-THROUGH L2 · L3 IPv4 · IPv6 · VLAN ACL · QoS AS IN PROD PHYSICAL OR VNF ON OUR HOSTS COUNTED · TIMED HARDWARE TESTER · PORT B RX + TX · SAME INSTRUMENT AS PORT A PER-FRAME VERIFICATION Sent vs received: lost frames, per trial Sequence check: misordered and duplicated CRC and payload check: corrupted frames Timestamp delta: latency, every frame LOSS ≠ MISORDER ≠ CRC ERROR LOOPBACK PRE-TEST FIRST port A to port B through the same cables and optics · 64-byte throughput must be 100% with zero loss before the DUT goes in

Тестер

Аппаратные порты Keysight, Spirent или Xena на скорости интерфейса DUT, от 1 GbE до 400 GbE. Каждый кадр несёт порядковый номер и аппаратную метку времени; приёмник проверяет оба, поэтому переупорядоченные, дублированные и битые кадры отделяются от потерянных.

Тестируемое устройство

Сконфигурировано так, как вы будете его эксплуатировать: VLAN, таблица маршрутизации, ACL, QoS, если в проде они включены. Одна конфигурация на весь прогон, выгружается и прикладывается к отчёту. Версия ПО и ревизия железа на первой странице.

Трафик

Размеры кадра 64, 128, 256, 512, 1024, 1280 и 1518 байт, по умолчанию двунаправленно (RFC 2544 §14), 256 MAC- или IP-адресов на порт (§12), чтобы коробка делала lookup, а не кэшировала. Сначала learning frames (§8), потом старт прогона и сброс счётчиков.

Pre-test: стенд без устройства

Соединяем порты тестера напрямую через те же кабели, оптику и патч-панель и прогоняем полный поиск throughput на 64 байтах. Ожидаемый ответ: 100% line rate без потерь. Если ответ другой, стенд чинится до того, как в него встанет DUT, потому что каждая потеря, которую мы увидим позже, должна принадлежать устройству, а не грязному LC-коннектору.

Условия теста

Размеры кадра, line rate и модификаторы, которые делают прогон реалистичным

RFC 2544 §9 фиксирует размеры кадра для Ethernet. В таблице максимальное число кадров в секунду, которое порт способен нести на каждом размере (20 байт преамбулы и межкадрового интервала на кадр учтены). Устройство, которое пропускает их все на каждом размере, работает на wire speed.

Размер кадра 1 GbE
frames/s		 10 GbE
frames/s		 100 GbE
frames/s		 Доля полезных бит в проводе
64 B1,488,09514,880,952148,809,52476.2%
128 B844,5958,445,94684,459,45986.5%
256 B452,8994,528,98645,289,85592.8%
512 B234,9622,349,62423,496,24196.2%
1024 B119,7321,197,31811,973,18098.1%
1280 B96,154961,5389,615,38598.5%
1518 B81,274812,7438,127,43898.7%

Кадров в секунду на 100% line rate, Ethernet: размер плюс 8 байт преамбулы и 12 байт межкадрового интервала, поделённые на скорость порта. 64-байтные кадры занимают 76% провода битами кадра и 24% накладными расходами, поэтому порт 10 GbE на 64 байтах это задача на 14,88 Mpps и в лучшем случае ответ 7,6 Gbit/s.

Всегда в наших прогонах

  • Bidirectional traffic (§14)
  • Trial duration 60 s (§24)
  • Learning frames before each trial (§8)
  • 256 addresses per port (§12)
  • Sequence, CRC and payload check on RX
  • Loopback pre-test of the bed

Двунаправленный трафик на всех парах, 60-секундный прогон на каждом шаге, learning frames перед каждым прогоном, проверка последовательности и CRC на каждом принятом кадре. Это минимум, который требует RFC 2544, и минимум для цифры, под которой мы готовы подписаться.

Добавляем по договорённости

  • 1% broadcast frames (§11.1)
  • SNMP query every second (§11.2)
  • 25 filters, last one permits (§11.3)
  • Full mesh, multiple port pairs (RFC 2889)
  • IPv6 frame sizes (RFC 5180)
  • Jumbo frames to 9216 B

Модификаторы RFC 2544 §11, которые вендоры в своих прогонах обычно пропускают: 1% broadcast-кадров в потоке, management-запрос (SNMP) каждую секунду, 25 правил фильтра, из которых поток пропускает только последнее. На одном кремнии они стоят производительности, на другом ничего, и именно это вы хотите знать до покупки.

6 тестов

RFC 2544 §26: что спрашивает каждый тест и какая цифра получается

Каждый тест прогоняется для каждого размера кадра. Первые 4 стандартный набор в тендерах и даташитах; recovery и reset те два, о которых чаще всего забывают, и те два, которые описывают, что чувствует ваша сеть при failover.

  1. 26.1Стандартный набор

    Throughput

    Максимальная предложенная нагрузка, при которой DUT пропускает каждый кадр. Бинарный поиск по каждому размеру кадра: старт с line rate, деление пополам при потере, сужение интервала до заданного разрешения. Один кадр потерян за 60-секундный прогон, и шаг провален. Отчитывается в кадрах в секунду и в процентах от line rate, с графиком по размеру кадра.

    Ноль потерь, по каждому размеру кадра · разрешение 0,1% line rate или 1 fps, на ваш выбор
  2. 26.2Стандартный набор

    Latency

    На скорости throughput 120-секундный поток с одним помеченным кадром на 60-й секунде; latency DUT это время между входом и выходом этого кадра. Store-and-forward устройства измеряются от последнего бита на входе до первого бита на выходе (LIFO), cut-through от первого бита до первого бита (FIFO). 20 повторов, отчитывается среднее.

    По размеру кадра, на скорости throughput · сверху добавляем min, max и гистограммы по каждому кадру
  3. 26.3Стандартный набор

    Frame loss rate

    Что коробка теряет при перегрузке. Трафик на 100% line rate, затем вниз шагами по 10% или мельче, пока 2 прогона подряд не покажут ноль потерь. Форма кривой говорит больше числа: чистое колено это воспитанная очередь, ранний склон это сдающийся планировщик или движок lookup.

    Потери в процентах от предложенных кадров, по каждому шагу нагрузки · график по размеру кадра
  4. 26.4Стандартный набор

    Back-to-back frames

    Пачка кадров с минимально допустимым межкадровым интервалом. Тест ищет самую длинную пачку, которую DUT поглощает без потери кадра, а это прямая мера его буферизации. Не меньше 2 секунд на пачку, 50 повторов, отчитывается средняя длина пачки в кадрах и во времени.

    Длина пачки по размеру кадра · единственная цифра, которая предсказывает поведение на microburst
  5. 26.5Устойчивость

    System recovery

    Сколько DUT нужно, чтобы вернуться в норму после перегрузки. Трафик на 110% измеренного throughput (или на line rate) 60 секунд, затем сброс до 50%. Время recovery отсчитывается от смены нагрузки до последнего потерянного кадра. Коробки, которые сбрасывают нагрузку аккуратно, восстанавливаются за микросекунды; коробки с глубокими медленными очередями за миллисекунды и теряют по дороге много.

    Время от сброса нагрузки до последнего потерянного кадра · по размеру кадра
  6. 26.6Устойчивость

    Reset

    Время от сброса, аппаратного или программного, до первого пропущенного кадра. Трафик на скорости throughput, DUT перезагружается по питанию или командой, и пауза между последним кадром до и первым кадром после и есть цифра. Это время перезагрузки, с которым будет жить ваш NOC, измеренное, а не заявленное.

    Секунды от сброса до первого пропущенного кадра · минимальный размер кадра, аппаратный и программный сброс отдельно

Процедура

Как идёт прогон и почему 60 секунд это нижняя граница

RFC 2544 §23 и §24 описывают прогон; всё остальное повторение. 5 ходов для каждого теста и каждого размера кадра, со сбросом и проверкой счётчиков между ними.

  1. 00

    Стенд без DUT

    Loopback через те же кабели и оптику. Throughput на 64 байтах должен вернуть 100% line rate без потерь, иначе сначала чинится стенд.

  2. 01

    Learning frames

    Тестер отправляет кадры с каждого адреса, который будет в прогоне, чтобы таблица MAC или ARP-кэш DUT были заполнены. Без этого первые секунды прогона запишут flooding и промахи на счёт устройства.

  3. 02

    Прогон, 60 секунд

    Счётчики сброшены, трафик на предложенной нагрузке минимум 60 с (§24). Потом 2 секунды тишины, чтобы стекли остаточные кадры, и 5 секунд, чтобы DUT успокоился перед следующим шагом (§23).

  4. 03

    Поиск и повторы

    Throughput сходится бинарным поиском; latency прогоняется 20 раз, back-to-back 50. У каждого шага свои счётчики, поэтому один нестабильный прогон виден, а не усреднён.

  5. 04

    Следующий размер кадра

    Весь цикл заново для 128, 256, 512, 1024, 1280 и 1518 байт. Полный прогон 4 тестов на одной паре портов это 3–5 часов времени тестера; такова цена цифр, за которыми стоит стандарт.

BINARY SEARCH · THROUGHPUT, 64 B, 10 GbE OFFERED LOAD, % OF LINE RATE · 60 s PER TRIAL 100% 75% 50% 25% TRUE ZERO-LOSS RATE · 83.6% 100% · 16.4% LOST 50% · 0 75% · 0 87.5% · 3.9% LOST 81.3% · 0 84.4% · 12 FRAMES 82.8% · 0 83.6% · 0 · RESULT TRIAL 1 TRIAL 2 TRIAL 3 TRIAL 4 TRIAL 5 TRIAL 6 TRIAL 7 TRIAL 8 8 trials × (60 s + 2 s drain + 5 s settle) ≈ 9 minutes for one frame size · result: 83.6% of line rate = 12,440,476 frames/s

Бинарный поиск на порту 10 GbE, кадры 64 байта. 8 прогонов по 60 секунд: красные шаги потеряли хотя бы один кадр, зелёные ни одного. Последний зелёный шаг в пределах разрешения 0,1% и есть throughput. Вендоры, которые гоняют 2-секундные прогоны, получают с той же коробки цифру выше: первые секунды буферы прячут потери.

4 цифры, которые решают, засчитывается ли шаг

  • 0

    Кадров потеряно в прогоне throughput. Не 0,01%, не «в пределах шума». RFC 1242 определяет throughput как скорость без потерь, а найденная скорость с допустимой потерей это другой тест с другим названием.

  • 60 с

    Минимальная длительность прогона (§24). Достаточно, чтобы заполнились буферы, разогрелся forwarding на CPU, а потеря 1 на миллион проявилась 890 раз на 64 байтах на 10 GbE.

  • 7

    Размеров кадра на тест (§9). Пропустить маленькие самый ходовой способ сделать медленную коробку быстрой; RFC разрешает добавлять размеры, но не убирать.

  • 20 / 50

    Повторов для latency и для back-to-back (§26.2, §26.4). Один прогон это анекдот. Разброс между повторами идёт в отчёт рядом со средним.

Анатомия одного прогона (RFC 2544 §23)

  • LearningКадры с каждого адреса-источника, таблицы DUT заполнены, тестер ждёт, пока DUT закончит flooding.
  • Сброс счётчиковСчётчики TX и RX и метки времени на тестере обнулены; счётчики интерфейсов DUT считаны и сохранены для перекрёстной проверки.
  • Прогон, от 60 сПредложенная нагрузка на скорости шага. Единственный измеряемый интервал: кадры отправлены, приняты, потеряны, переупорядочены, latency по каждому кадру.
  • Слив и пауза2 с на сбор кадров, которые ещё в пути, затем 5 с тишины перед следующим шагом, чтобы один прогон не протёк в следующий.

Отчёт

Что вы получаете обратно и что с этим можно сделать

RFC 2544 §26 требует таблицу и график на каждый тест и каждый размер кадра. Мы добавляем контекст, который превращает таблицу в решение: что было сконфигурировано, что намерил сам стенд и где коробка не дотянула до даташита.

Цифры, по каждому размеру кадра

  • Throughput в кадрах в секунду и в процентах от line rate, с разрешением поиска
  • Latency: среднее по RFC 2544 из 20 прогонов плюс min, max и распределение по кадрам
  • Frame loss rate на каждой предложенной нагрузке от 100% до шага без потерь
  • Длина пачки back-to-back в кадрах и в микросекундах, среднее из 50
  • Время system recovery и reset (аппаратного, программного), если заказаны
  • Переупорядоченные, дублированные кадры и кадры с ошибкой CRC считаются отдельно от потерь

Контекст, чтобы цифры держались

  • Модель DUT, ревизия железа, версия ПО и полная выгрузка конфигурации
  • Модель тестера, тип портов, оптика, прошивка; результат loopback pre-test
  • Формат кадра и протокол: только L2, IPv4, IPv6, с VLAN-тегом, с раскладкой заголовков
  • Действующие модификаторы: двунаправленность, число адресов, доля broadcast, management-нагрузка, фильтры
  • Заявка из даташита рядом с измеренным значением по каждому тесту, с разрывом в процентах
  • Сырые счётчики по каждому прогону и дампы пакетов проваленных шагов
RFC 2544 · TEST REPORT 10 GbE · BIDIRECTIONAL · 60 s TRIALS 26.1Throughput, 1518 B 26.1Throughput, 64 B 26.2Latency, 64 B, store & forward 26.3Frame loss at 100%, 64 B 26.4Back-to-back, 64 B 26.5System recovery, 64 B 100% 83.6% 4.8 µs 16.4% 18,900 fr 0.42 ms 812,743 fps · 0 lost of 48.8 M sent · datasheet: wire speed 12,440,476 fps · datasheet: 14,880,952 fps · gap 16.4% avg of 20 · min 4.1 · max 7.9 · LIFO at the throughput rate clean knee at 84% · 0 loss from 83.6% down · 2 trials confirmed avg of 50 · 1.27 ms of line-rate burst absorbed · buffer ≈ 1.2 MB 110% for 60 s, then 50% · last lost frame at +0.42 ms ATTACHED DUT CONFIG EXPORT GRAPHS PER SIZE LOOPBACK PRE-TEST RAW COUNTERS · PCAP Values are illustrative. Your report carries your numbers, per frame size and per modifier set.

Если вы сравниваете 2 коробки и больше

  • Один тест-план, один стенд, один тестер для всех кандидатов; результаты в одной таблице с одинаковыми размерами кадра и модификаторами
  • Прямая рекомендация: какая коробка отвечает вашему требованию, на каком размере кадра она останавливается и на сколько
  • Сам тест-план, оформленный как приложение к тендеру, чтобы победителя можно было перепроверить при поставке

Из практики

Wire speed на 1518 байтах, 38% на 64. Та же коробка, тот же даташит.

У заказчика был шорт-лист из 2 агрегирующих маршрутизаторов и даташит на каждый со словами «wire-speed forwarding на всех портах». Оба не врали, на 1518 байтах. На нашем стенде по 7 размерам кадра один держал line rate до 128 байт и дал 92% на 64. Второй сорвался ниже 512 байт и на 64 байтах пропускал 38% line rate с 62% потерь, двунаправленно, без модификаторов.

В их профиле трафика, по выгрузке NetFlow, 47% кадров были короче 128 байт: VoIP, DNS, TCP ACK, мониторинг. Более дешёвая коробка оказалась бы медленнее в 2,4 раза в первый же день в проде. Тест занял 2 лабораторных дня и стоил меньше разницы в цене между двумя устройствами.

Тестируйте на своих размерах кадра, а не на вендорских.

SAME BOX · TWO FRAME SIZES 1518 B · THE DATASHEET RUN 812,743 fps of 812,743 · wire speed, as printed 100% 64 B · THE PRODUCTION RUN 5.65 Mfps of 14.88 Mfps · 62% of frames lost at line rate 38% SIZING GAP 2.6× 47% of the customer's frames were under 128 bytes. The box was sized for the other 53%.

Как мы это делаем для вас

RFC 2544 в CloudLAB: тест-план, стенд и отчёт с подписью

Метод открытый. Тестер, стенд, дисциплина гонять 60-секундные прогоны на 7 размерах кадра и опыт читать кривую потерь: вот что вы у нас арендуете.

Бенчмарк одного устройства

4 стандартных теста или все 6, на ваших размерах кадра и модификаторах, на аппаратном тестере под скорость порта. Физическое устройство подключаем в Армении или ваш виртуальный маршрутизатор на наших хостах. Результаты у вас в браузере, пока идёт прогон.

Запросить тест-план

Сравнение шорт-листа

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

Сравнить кандидатов

Тест-план для тендера или приёмки

Письменная процедура RFC 2544 с вашими размерами кадра, скоростями, критериями pass и форматом отчёта, готовая как приложение к RFP или протоколу приёмки. Дальше приёмку при поставке проводим мы или ваша команда по нашему плану.

Заказать тест-план

Прогоните сами в CloudLAB

Забронируйте пару портов тестера по часам, подключите своё устройство или загрузите VNF, используйте нашу автоматизацию RFC 2544 и скачайте отчёт. Наши инженеры в чате, когда результат выглядит странно.

Войти в CloudLAB
  • Независимость: мы продаём тест, вендор продаёт коробку
  • Аппаратные тестеры с метками времени на каждом кадре: latency и потери измерены, а не оценены
  • Каждый прогон воспроизводим: план, конфигурация и сырые счётчики остаются у вас

По теме

FAQ

Вопросы, которые нам задают перед прогоном RFC 2544

Вендор уже опубликовал результаты RFC 2544. Зачем тестировать снова?

Потому что в опубликованном прогоне размеры кадра, длительность, конфигурацию и модификаторы выбирал он, и редко говорит какие. В нашем прогоне они ваши. Когда цифры сходятся, у вас подтверждённое число для тендера. Когда расходятся, вы узнали об этом до счёта на оплату.

Можете прогнать RFC 2544 на нашей production-сети или через канал оператора?

Нет. RFC 6815 объясняет почему: поиск throughput намеренно перегружает путь и роняет реальный трафик. Для сервисного канала правильный метод ITU-T Y.1564: он тестирует на контрактных CIR и EIR и никогда выше; он тоже есть у нас в меню.

Результат throughput с потерей 0,01% приемлем?

По RFC 2544 нет: throughput по определению скорость без потерь. Некоторые тестеры предлагают «поиск с допустимой потерей»; он даёт цифру выше и другую метрику. Мы отчитываем значение по RFC и, если попросите, рядом значение с допуском, подписанное как таковое.

Наше устройство firewall. RFC 2544 подходящий тест?

Только для его сырого forwarding path с выключенными функциями безопасности, а так вы его эксплуатировать не будете. Для firewall и NGFW используйте RFC 9411: HTTP- и HTTPS-транзакции, TLS-инспекция и IPS включены. Мы прогоняем оба, когда тендер просит пакетную цифру, а решению нужна настоящая.

Сколько занимает полный прогон и что вам нужно от нас?

4 теста, 7 размеров кадра, двунаправленно, на одной паре портов: 3–5 часов времени тестера, 1–2 лабораторных дня с настройкой и отчётом. Нам нужно устройство (или его виртуальный образ), конфигурация, с которой вы собираетесь работать, скорость порта и размеры кадра или профиль трафика, которые вам важны.

IPv6, VLAN-теги, MPLS, jumbo-кадры?

IPv6 идёт по RFC 5180 с теми же тестами и своими размерами кадра. Заголовки VLAN и MPLS добавляются в формат кадра и указываются в отчёте. Jumbo-кадры до 9216 байт добавляем как дополнительные размеры, когда ваша сеть их использует; RFC разрешает добавлять размеры и никогда не убирать 7 базовых.

Положите даташит на стенд

Пришлите модель или шорт-лист, скорость порта и размеры кадра, которые реально ходят в вашем трафике. В ответ получите тест-план RFC 2544: тесты, модификаторы, лабораторные дни и цена. Test. Compare. Decide.

Запросить тест-план Войти в CloudLAB

Пришлите шорт-лист

Методика есть. Осталось получить цифры.

Пришлите шорт-лист и ключевые показатели. Инженер ответит в течение рабочего дня черновиком плана тестов и оценкой.

Удобнее в чате? Написать инженеру в WhatsApp

Мы используем присланное только чтобы вам ответить. См. политику конфиденциальности.