Skip to content

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

RFC 2889: тест коммутатора, в котором каждый порт говорит с каждым

RFC 2544 измеряет пару портов. RFC 2889 нагружает весь коммутатор: full mesh на N портах, перегрузка по плану, таблица MAC, заполненная до флуда. 10 тестов, прогоны по 30 секунд, forwarding rate в отчете рядом с теоретической линией. На этой странице метод в том виде, в каком мы прогоняем его в CloudLAB, и что входит в отчет.

  • Full mesh: каждый порт шлет всем остальным по кругу, так что нагрузку несет вся фабрика сразу
  • Блок перегрузки из 4 портов показывает head-of-line blocking и backpressure за один прогон в 30 с
  • 10 тестов: 4 сетки трафика, перегрузка, forward pressure, емкость таблицы адресов, скорость обучения, битые кадры, broadcast
Получить тест-план RFC 2889 К 10 тестам
ZERO-LOSS THROUGHPUT % OF LINE RATE PER PORT · RFC 2889 §5.1 PORT PAIR · RFC 2544 24-PORT FULL MESH · RFC 2889 LINE RATE · 100% 50% 71% 86% 96% 100% 100% 100% 100% FABRIC-BOUND: BUFFER + 24 LOOKUPS PER SLOT 64 B 128 B 256 B 512 B 1024 B 1280 B 1518 B Every port to every port, or the claim is untested

Типичный результат на 24 портах. В паре портов коммутатор держит line rate на любом размере. В full mesh на 64 байтах фабрика и общий буфер обслуживают 24 lookup за слот, и цифра падает до 71%. В даташите напечатан первый график.

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

Коммутатор продают за фабрику, значит тестировать надо фабрику

RFC 2889 расширяет RFC 2544 на коммутаторы LAN: те же размеры кадра, тот же шаблон теста, но трафик идет через все порты сразу, а список тестов покрывает то, что коммутатор делает помимо пересылки: учит адреса, переживает перегрузку, отбрасывает битые кадры и размножает broadcast.

Коммутаторы ToR и кампуса

Любое устройство, которое коммутирует на уровне MAC: leaf 48×25 GbE, spine 100 GbE, стек доступа в кампусе, коммутатор СХД. Full mesh и many-to-one: именно эти схемы трафика их покупатели и гоняют.

Заявления «non-blocking» и «wire speed»

Оба берутся из пары портов или из даташита ASIC. Сетка на 24 портах при 64 байтах проверяет матрицу коммутации, буфер и движок lookup вместе, и другого способа подтвердить эти слова нет.

Маршрутизаторы и межсетевые экраны идут в другие RFC

Пересылка L3 относится к RFC 2544 и RFC 5180, межсетевые экраны и NGFW к RFC 9411. RFC 2889 нужен там, где результат решают обучение MAC, VLAN и перегрузка.

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

N портов тестера, один тактовый генератор, один коммутатор

За каждым портом DUT стоит порт тестера. Все порты тактирует один прибор, поэтому они стартуют в пределах 300 мс, каждый кадр несет сигнатуру и метку времени, а счетчик флуда снимается на каждом порту, включая те, которые должны были молчать.

HARDWARE TESTER · PORTS 1 … N/2 TX + RX ON EVERY PORT · ONE CLOCK FRAME STREAM, PER PORT 64 · 128 · 256 · 512 · 1024 · 1280 · 1518 B 1 to 256 MAC addresses per port Round robin to all other ports, fixed order Signature field + timestamp in every frame ALL PORTS START WITHIN 300 ms N/2 PORTS BIDIRECTIONAL DUT · LAN SWITCH ONE FABRIC · ONE MAC TABLE · N PORTS STORE & FORWARD CUT-THROUGH 802.1Q · VLAN FLOW CONTROL AGING TIME AS AGREED STP · LLDP · SNMP OFF OR FILTERED N/2 PORTS COUNTED · TIMED HARDWARE TESTER · PORTS N/2+1 … N RX + TX · SAME INSTRUMENT, SAME CLOCK PER-PORT COUNTING Received: right port + right signature Flood count: frames on the wrong port DUT's own frames (STP, LLDP) excluded Timestamp delta: latency, every frame RECEIVED ≠ FLOODED ≠ MISFORWARDED LEARNING FIRST, VERIFIED a learning frame per address at 50 fps, one verification frame each, zero floods required · aging time > learning + 30 s trial + setup

Аппаратный тестер, от 8 до 48 портов

Порты 1, 10, 25, 100 и 400 GbE в одном шасси. У каждого порта свои MAC-адреса, от 1 до 256, и он шлет всем остальным портам по кругу, как требует §5.1.3. Программные генераторы не удерживают 48 портов на 64 байтах в пределах 1% друг от друга, поэтому для этого RFC мы их не используем.

Коммутатор в том виде, в каком он встанет в сеть

Боевая конфигурация: VLAN, режим STP, flow control, время старения, QoS, port security. Все это выгружается в отчет. Протоколы, которые коммутатор шлет сам (STP, LLDP, SNMP), выключены или вычтены из счетчиков, как советует §5.7.

Сетка трафика с сигнатурой

Размеры кадра от 64 до 1518 байт, тегированные 802.1Q до 1522, если коммутатор их принимает, поле сигнатуры после 56-го байта в каждом кадре. «Принят» значит нужный порт назначения и нужная сигнатура. Все остальное считается флудом или ошибкой пересылки.

Сначала обучение, и с проверкой

Перед каждым прогоном тестер шлет обучающий кадр на каждый адрес, 50 кадров в секунду или медленнее, если коммутатору так нужно, и проверяет, что ничего не флудит. Время старения на коммутаторе ставится больше, чем обучение плюс прогон плюс подготовка, иначе адреса истекут посреди прогона, и вместо forwarding rate в отчете будет счетчик флуда.

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

8 параметров, которые RFC просит зафиксировать до первого кадра

RFC 2889 не добавляет размеров кадра, он добавляет форму трафика. Каждое значение ниже попадает в тест-план и в отчет, потому что любое из них меняет цифру.

Параметр Значение RFC 2889 Диапазон На что влияет
Размер кадра64, 128, 256, 512, 1024, 1280, 1518 Бтегированные до 1522 Б; jumbo по договоренностиLookup в секунду: 64 Б это 14,88 млн на порт 10 GbE
Межкадровый интервал96 бит, минимум среды88 бит только в тесте forward pressureНиже 96 бит предложенная нагрузка превышает MOL на 1 байт на кадр
Intended load (ILoad)% от MOL на портпоиск от 100% внизFull mesh на 100% на N портах ничего не переподписывает; many-to-one переподписывает намеренно
Размер пачки1 кадр (постоянная нагрузка)от 1 до 930 кадровПачки бьют по буферу, постоянная нагрузка по движку lookup
Адресов на порт11, 2, 4 … 256 (степени двойки)Больше адресов, больше lookup на кадр, случайные пары источник и назначение
Длительность прогона30 сот 1 до 300 сДостаточно коротко для 10 тестов × 7 размеров и достаточно долго, чтобы заполнить буферы
Скорость обучения50 кадров/с или нижезависит от коммутатораСлишком быстро, и таблица пропускает записи; каждый пропуск превращается во флуд
Время старениябольше, чем обучение + прогон + подготовказависит от коммутатораАдреса, истекшие посреди прогона, превращают пересылку во флуд

RFC 2544 гоняет прогон 60 секунд; RFC 2889 рекомендует 30, потому что 10 тестов на 7 размерах кадра и нескольких схемах трафика иначе заняли бы дни. Если в тендере нужны прогоны по 60 с для throughput в сетке, мы гоняем 60 и пишем об этом в отчете.

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

  • Learning verified before every trial (§3)
  • Signature field per port (§4)
  • Round-robin destinations, fixed order (§5.1.3)
  • All ports start within 300 ms (§5.1.3)
  • Flood count on every port (§5.1.4)
  • Loopback pre-test of the bed

Обучение проверено, сигнатура на порт, адреса назначения по кругу и без изменений под перегрузкой, счетчики флуда везде. Это то, что в RFC помечено как MUST, и то, что отличает forwarding rate от догадки.

По договоренности в проекте

  • 2 to 256 addresses per port (§5.1.2)
  • Burst sizes 1 to 930 frames (§5.1.2)
  • Half-duplex legacy ports (§5.1.2)
  • Tagged frames to 1522 B (§4)
  • Two switches over one uplink (§5.3)
  • Jumbo frames to 9216 B

Каждый из этих пунктов двигает цифру. 256 адресов на порт в full mesh: самый тяжелый случай из описанных в RFC, и его мы рекомендуем для leaf-коммутатора; пачки по 930 кадров: так сеть СХД выглядит для коммутатора.

10 тестов

Что измеряет RFC 2889, раздел за разделом

Каждый тест идет на каждом размере кадра. Первые 4 нагружают фабрику разными формами трафика; 5.5 и 5.6 провоцируют ее; 5.7 и 5.8 измеряют таблицу MAC; 5.9 и 5.10 проверяют, что коммутатор делает с кадрами, которые должен отбросить, и с кадрами, которые обязан размножить.

  1. 5.1Сетка трафика

    Full mesh: throughput, потери кадров и forwarding rate

    Каждый порт шлет каждому другому по кругу с одинаковой intended load. Поиск находит throughput: максимальную нагрузку с нулевыми потерями на всех портах. Forwarding rate записывается также при максимальной предложенной нагрузке (FRMOL) и в пике (MFR), потому что коммутатор, теряющий 2% на 100%, может пересылать больше кадров, чем на 95%.

    Результат: throughput, FR, FRMOL и MFR на каждый размер кадра, на графике рядом с теоретической линией
  2. 5.2Сетка трафика

    Частичная сетка one-to-many и many-to-one

    Один порт шлет N портам, затем N портов шлют одному. Вторая половина: схема СХД и резервного копирования, N источников в один порт, пачками по природе. Размер пачки и ILoad ставятся так, чтобы сумма оставалась ниже принимающего порта, или выше него, когда заказчик хочет измерить буфер.

    Результат: throughput и потери кадров по направлениям и размерам кадра, размер пачки указан
  3. 5.3Сетка трафика

    Частичная сетка: два коммутатора через один аплинк

    Два DUT с множеством портов доступа и одним аплинком между ними, трафик с портов одного коммутатора на порты другого. Аплинк узкое место по замыслу; тест показывает, делят ли коммутаторы его честно и сколько теряют, когда трафик доступа его превышает.

    Результат: throughput, потери кадров и forwarding rate через аплинк, на каждый размер кадра
  4. 5.4Сетка трафика

    Частичная сетка с однонаправленным трафиком

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

    Результат: throughput и forwarding rate на каждый размер кадра; обычно лучшая цифра, которую получает коммутатор
  5. 5.5Перегрузка

    Контроль перегрузки: head-of-line blocking и backpressure

    Блок из 4 портов. Источник A шлет на 100%, чередуя неперегруженный и перегруженный приемник; источник B шлет 100% на перегруженный. Неперегруженный порт должен получить каждый кадр: потеря там и есть head-of-line blocking. Перегруженный порт получает 150% и должен потерять 33%: ноль потерь там означает, что коммутатор применил backpressure (flow control) и притормозил источники.

    Результат: потери кадров на неперегруженном и перегруженном порту; вердикт: HOLB есть или нет, backpressure есть или нет
  6. 5.6Перегрузка

    Forward pressure и максимальный forwarding rate

    Две части. Forwarding rate измеряется, пока intended load шагами растет от throughput до MOL; наибольшее значение и есть MFR. Затем кадры идут с интервалом 88 бит вместо 96, перегружая вход на 1 байт на кадр. Forwarding rate выше MOL на выходе означает, что коммутатор передает с недопустимым интервалом: forward pressure обнаружен.

    Результат: MFR с указанием ILoad; FR при интервале 88 бит; «Forward pressure detected», если FR превышает MOL
  7. 5.7Таблица адресов

    Емкость таблицы адресов

    3 порта: обучающий, тестовый и контрольный. Обучающий порт предлагает N адресов источника, затем тестовый порт шлет N кадров обратно на них. Если контрольный порт видит хоть один кадр или обучающий порт получает меньше, чем отправлено, таблица была полна на N. Бинарный поиск между 0 и максимумом вендора, с полной паузой на старение между итерациями, заканчивается на реальной емкости.

    Результат: адресов на порт, со счетчиком флуда на каждой итерации на всех 3 портах
  8. 5.8Таблица адресов

    Скорость обучения адресов

    Та же схема на 3 портах, число адресов зафиксировано на емкости из 5.7, меняется скорость обучающих кадров. Наибольшая скорость, при которой выучен каждый адрес и ноль флуда на контрольном порту, и есть скорость обучения. Она решает, как долго коммутатор остается слепым после смены топологии или волны миграций ВМ.

    Результат: обучающих кадров в секунду при 0 флуда; таблица скорость, предложено, переслано, флуд
  9. 5.9Целостность

    Фильтрация битых кадров

    5 типов кадров через коммутатор: oversize (больше 1518 Б), undersize (меньше 64 Б), ошибка CRC, dribble bits и ошибка выравнивания. Undersize, CRC и ошибка выравнивания не должны выйти с другой стороны; oversize не должен, если только не поддерживаются тегированные кадры до 1522 Б; dribble bits должны быть исправлены, а кадр переслан. Pass или fail по каждому, счетчики сохраняются для протокола.

    Результат: pass / fail × 5, счетчики кадров приложены; коммутатор cut-through обычный кандидат на fail по CRC
  10. 5.10Целостность

    Пересылка broadcast и задержка

    Один порт шлет broadcast-кадры с заданной нагрузкой; каждый другой порт измеряет forwarding rate и потери. Затем отправляется один broadcast-кадр, и измеряется задержка до каждого принимающего порта. Размножение broadcast в ASIC отдельная функция, и 1 порт из 48, который получает кадр на 40 мкс позже, ровно то, ради чего этот тест.

    Результат: forwarding rate и потери broadcast на каждый размер кадра; задержка на каждый принимающий порт

Процедура

Как идет прогон: от пустого стенда до подписанного отчета

5 этапов. Тесты в сетке забирают большую часть времени лаборатории; блок перегрузки и адресные тесты забирают большую часть инженерной работы.

  1. 00

    Стенд без DUT

    Порты тестера замкнуты через те же кабели, оптику и панель. Full mesh на 64 байтах должен вернуть 100% с нулем потерь и нулем флуда, иначе сначала чинится стенд.

  2. 01

    Обучение, затем проверка

    Время старения считано с коммутатора и выставлено больше обучения + 30 с + подготовки. Обучающие кадры на адрес при 50 кадр/с. Проверочный кадр на адрес; любой флуд, и обучение повторяется медленнее.

  3. 02

    Прогоны в сетке

    Full mesh, one-to-many, many-to-one, однонаправленный. Бинарный поиск throughput на каждый размер кадра, затем FR при MOL и проход на MFR. Прогоны по 30 с, все порты стартовали в пределах 300 мс.

  4. 03

    Перегрузка и давление

    Блок из 4 портов на HOLB и backpressure на каждом размере кадра, затем прогон с интервалом 88 бит. Счетчики снимаются с коммутатора после каждого прогона и сверяются с тестером.

  5. 04

    Таблица, фильтры, broadcast

    Бинарный поиск емкости таблицы с паузой на старение на каждой итерации, проход по скорости обучения на этой емкости, 5 типов битых кадров и пара broadcast-тестов. Отчет собирается в тот же день.

CONGESTION CONTROL · 4-PORT BLOCK · RFC 2889 §5.5 100% OF MOL PER SOURCE · 30 s · EVERY FRAME SIZE SOURCE A · 100% 1st frame to the uncongested port, 2nd to the congested one, repeat SOURCE B · 100% every frame to the congested port same frame count as source A 50% → UNCONGESTED 50% → CONGESTED 100% → CONGESTED DUT OUTPUT QUEUES UNCONGESTED · 50% IN, 50% OUT +50% CONGESTED · 150% IN, 100% OUT Where does the 50% go: dropped here, or elsewhere? 50% OUT 100% OUT, LINE RATE UNCONGESTED PORT receives 50% of source A's frames expected loss: 0 CONGESTED PORT offered 150%, can carry 100% expected loss: 33% LOSS ON THE UNCONGESTED PORT = HEAD-OF-LINE BLOCKING 0 LOSS ON THE CONGESTED PORT = BACKPRESSURE (FLOW CONTROL) 33% CONGESTED, 0 UNCONGESTED = CLEAN OUTPUT QUEUING

Блок перегрузки, как его рисует RFC: два источника, два приемника, 150% line rate в один из них. Где окажется потеря, говорит о том, как устроен коммутатор. Только на перегруженном порту: чистая схема с выходными очередями. На обоих: head-of-line blocking из общего входного буфера. Нигде: flow control, который притормозил ваши источники.

4 цифры, которые решают pass или fail

  • 0

    Потерянных кадров на неперегруженном порту блока перегрузки. Любая потеря там и есть head-of-line blocking, а коммутатор с HOLB позволяет одному занятому серверу тормозить порт, который к нему не имеет отношения.

  • 33%

    Ожидаемые потери на перегруженном порту при 150% предложенной нагрузки без flow control. 0% означает backpressure: коммутатор притормозил источники вместо того, чтобы отбрасывать кадры. Само по себе ни то ни другое не ошибка; отчет говорит, что именно у вас.

  • ≤ MOL

    Forwarding rate на выходном порту, пока вход кормят интервалом 88 бит. Значение выше MOL означает, что коммутатор пересылает с недопустимым интервалом, который следующее устройство может посчитать ошибками.

  • 0

    Кадров на контрольном порту во время адресных тестов. Один кадр там означает, что таблица была полна и коммутатор зафлудил; так заявление «поддерживает 32K MAC» на практике превращается в 16 384.

Анатомия 30-секундного прогона

  • ОбучениеОбучающий кадр на адрес при 50 кадр/с, таймеры старения сброшены, DUT дано время дофлудить.
  • ПроверкаОдин кадр на адрес; флуд на любом порту возвращает прогон к обучению.
  • Прогон, 30 сВсе порты передают в пределах 300 мс друг от друга; кадры считаются как принятые или флуд на каждом порту, метки времени сохраняются.
  • Слив и счетчики2 с на кадры в пути, счетчики тестера заморожены, счетчики интерфейсов коммутатора считаны и приложены.

Отчет

Что вы получаете после прогона

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

Результаты, на каждый размер кадра

  • Throughput, FRMOL и MFR в full mesh, на графике рядом с теоретической линией
  • Throughput one-to-many, many-to-one и однонаправленный с указанием размера пачки и ILoad
  • Блок перегрузки: потери на обоих приемных портах, вердикты по HOLB и backpressure
  • Forward pressure: FR при интервале 88 бит против MOL
  • Емкость таблицы адресов и скорость обучения со счетчиками флуда на каждой итерации
  • Битые кадры: 5 строк pass/fail; forwarding rate broadcast и задержка по портам

Контекст, чтобы прогон можно было повторить

  • Модель коммутатора, ревизия железа, версия ПО и полная выгрузка конфигурации
  • Карта портов: какой порт тестера на каком порту DUT, скорость, оптика, членство в VLAN
  • Адресов на порт, скорость обучения, время старения и размер пачки для каждого теста
  • Модель тестера, прошивка и скорости портов; результат loopback-претеста
  • Кадры самого DUT (STP, LLDP, SNMP) и как они были исключены из счетчиков
  • Длительность прогона и разброс старта между портами, по каждому тесту
RFC 2889 · TEST REPORT 24 × 25 GbE · FULL MESH · 30 s TRIALS 5.1Full mesh throughput, 64 B 5.1Full mesh throughput, 1518 B 5.5Head-of-line blocking, 64 B 5.5Backpressure 5.6Forward pressure, 88-bit IFG 5.7Address caching capacity 5.8Address learning rate 5.9Errored frames filtering 71.4% 100% 9% lost none ≤ MOL 16,384 1,200/s 4 of 5 26.6 Mfps per port of 37.2 · datasheet: wire speed, non-blocking 2.03 Mfps per port · 0 lost of 1.46 G sent uncongested port lost 9% · shared input buffer congested port lost 33% at 150% offered · no flow control FR 37,202,380 fps at 88-bit gap · MOL 37,202,381 datasheet: 32K · floods on Mport from 16,385 · 15 iterations 16,384 addresses, 0 floods · 1,500/s floods 212 CRC-errored frames forwarded in cut-through mode ATTACHED CONFIG EXPORT PORT MAP GRAPHS PER SIZE COUNTERS · PCAP Values are illustrative. Your report carries your numbers, per frame size and per traffic pattern.

Когда кандидатов 2

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

Из практики

Non-blocking на бумаге, 71% в сетке

Заказчик выбирал leaf на 48 портов 25 GbE для фабрики СХД, и у него был отчет RFC 2544 от вендора: wire speed на каждом размере кадра, пара портов, в обе стороны. Мы прогнали RFC 2889 на 24 портах. Full mesh на 1518 байтах: 100%. Full mesh на 64 байтах: 71% line rate, 29% кадров пропало.

Блок перегрузки все объяснил. 9% потерь на неперегруженном порту: head-of-line blocking из общего входного буфера. Для фабрики СХД с пачками many-to-one весь день это один занятый хост, который тормозит остальные. Второй кандидат потерял 33% на перегруженном порту и 0 на другом, ровно то, чего RFC ждет от коммутатора без HOLB. Он стоил на 12% дороже, и купили его.

Фабрика и есть продукт. Тестируйте фабрику.

SAME SWITCH · 64 B · TWO TRAFFIC SHAPES PORT PAIR · THE RFC 2544 RUN 37.2 Mfps of 37.2 per port · wire speed, as printed 100% 24-PORT FULL MESH · THE RFC 2889 RUN 26.6 Mfps of 37.2 per port · 29% of frames lost at line rate 71% LOSS ON THE UNCONGESTED PORT 9% Head-of-line blocking: one busy host slowed down the other 23.

Что мы прогоняем

RFC 2889 как услуга, в CloudLAB или у вас на площадке

Аппаратный тестер с достаточным числом портов для вашего коммутатора, инженер, который 20 лет гонял этот RFC на вендорском железе, и отчет, который можно положить в тендер.

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

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

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

Шорт-лист из 2 или 3

Один план, один стенд, один день на каждого кандидата. Таблица результатов, где full mesh, HOLB и емкость таблицы адресов стоят рядом, и названо, где более дешевый достаточно хорош.

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

Приемка перед внедрением

Ваш коммутатор, ваша конфигурация, ваши схемы трафика, прогон как pass или fail против цифр в контракте. До оплаты счета, вендор может присутствовать.

Организовать приемочный прогон

Ваши инженеры, наш стенд

Доступ в CloudLAB к портам тестера с загруженным планом RFC 2889. Гоняйте сами, сколько нужно раз, с нашим инженером в чате.

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

Читать дальше

FAQ

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

У нас есть отчет вендора по RFC 2544. RFC 2889 правда отличается?

RFC 2544 нагружает одну пару портов; RFC 2889 нагружает все порты сразу и добавляет тесты перегрузки, таблицы MAC и фильтрации. Коммутатор проходит 2544 на одном только ASIC порта. 2889 он проходит на фабрике, общем буфере и движке lookup вместе. «Non-blocking» это заявление из 2889, а в большинстве даташитов гоняли только 2544.

Вы тестируете все 48 портов?

Столько, сколько есть у тестера на этой скорости, обычно от 16 до 32 на 25 GbE и от 8 до 16 на 100 GbE. RFC допускает сетку на любом подмножестве; в отчете написано, на каких портах. Для заявления «non-blocking» мы заполняем всю полосу ASIC, а на 100 GbE для этого нужно меньше портов, чем на 10.

Почему прогоны по 30 секунд, когда RFC 2544 говорит 60?

RFC рекомендует 30 с и допускает от 1 до 300. С 10 тестами, 7 размерами кадра и несколькими схемами трафика прогоны по 60 с удвоили бы 2-дневный прогон. Буферы современных коммутаторов заполняются за миллисекунды, так что 30 с хватает, чтобы увидеть потери. Если в тендере стоит 60 с, гоняем 60 с.

Коммутатор флудит во время теста. Кто виноват?

Обычно настройка: обучающие кадры предложены слишком быстро, время старения короче прогона или схема хеширования не вмещает выбранный шаблон MAC. RFC описывает все 3, поэтому мы замедляем обучение до 50 кадр/с, ставим старение больше прогона и меняем формат адресов, прежде чем винить коммутатор. Если он все еще флудит на N адресах, это и есть цифра емкости.

Head-of-line blocking или backpressure: что хуже?

HOLB хуже для большинства сетей. Он означает, что перегруженный порт заставляет терять кадры порт, к нему не относящийся, так что один занятый сервер тормозит соседей. Backpressure означает, что коммутатор притормаживает источники вместо отбрасывания, что подходит сети СХД и мешает сети, чувствительной к задержке. Отчет показывает, что у вас; выбор за вами.

RFC 2889 применим к коммутаторам 100 GbE и 400 GbE?

Да. RFC писали вокруг 10, 100 и 1000 Мбит/с, но каждый параметр в нем задан относительно среды: минимальный межкадровый интервал, MOL, размеры кадра из RFC 2544. Мы гоняем его на 25, 100 и 400 GbE по той же процедуре. Единственная поправка: шаг около MOL, где предел задает разрешение интервала на тестере.

Поставьте коммутатор в сетку

Пришлите модель или шорт-лист, число и скорость портов и схему трафика, которую вы гоняете: СХД, кампус, leaf-spine. В ответ получите тест-план RFC 2889: тесты, адресов на порт, лабораторные дни и цена. Test. Compare. Decide.

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

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

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

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

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

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