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

Я отлаживаю случай потери UDP-пакетов в гигабитном коммутаторе с промежуточным хранением и хотел визуализировать, что происходит внутри коммутатора, чтобы лучше понять суть проблемы.

Сценарий простой — два пакетных потока данных приходят через 2 порта внутри коммутатора и оба хотят выйти из него через третий порт (общий для обоих). Таким образом, коммутатору необходимо какое-то время удерживать некоторые данные в буфере пакетов.

Проблема в том, что, исходя из моих простых расчетов, буферы должны быть достаточно большими, чтобы справиться с рассматриваемым мной случаем. Один поток данных отправляет пакеты по 25 кБ (разделенные на пакеты по 1514 Б) каждые 1,56 мс, другой отправляет пакеты по 60 кБ каждые 1 мс. Теперь даже такой коммутатор Soho, как Netgear GS105E, имеет размер буфера 128 КБ. Таким образом, простая математика (25 + 60 < 128) говорит, что это должно работать, даже если потоки приходят на вход в одно и то же время (при условии отсутствия другого значительного трафика).

Реальные тесты показывают, что на некоторых коммутаторах теряется много пакетов из обоих потоков (видимо, это связано с размером буфера, но не только с ним). В моем моделировании я не могу заставить буфер переполняться, если установлено значение 128 КБ.

Я записал эту анимацию для буфера размером 24 КБ, где есть переполнение. Однако легко увидеть, что увеличение буфера всего на несколько байт решит проблему, и все пакеты будут проходить.

Я сделал несколько упрощений в этой симуляции. Все пакеты имеют одинаковый QoS (то есть и в реальном случае). Поэтому я исключил очереди QoS из моделирования и рассматриваю весь трафик как одинаково важный. Затем я исключил управление памятью буфера. Я могу представить, что это важная часть проблемы, но я был бы удивлен, если бы мое упрощение с идеальным распределением было бы более чем на 10% неверным по сравнению с реальным случаем. Я также делаю вид, что коммутатор знает длину кадра, когда он получает свои первые байты, поэтому он резервирует всю необходимую память в начале. Поскольку я не смог найти никакой документации о размере входных/выходных очередей портов, я предполагаю, что все они помещаются в общий буфер пакетов и могут занимать столько буфера, сколько необходимо (хотя я думаю, что виновником может быть где-то здесь).Я установил задержку обработки каждого пакета на 512 нс (задержка распространения пакета 64 байта).

Я не уверен, играет ли это роль, но потоки состоят из фрагментированных UDP-пакетов (т. е. 25-килобайтный пакет — это один UDP-пакет, фрагментированный на 17 IP-фрагментов). Второй поток создает пакет в виде 2 или 3 пакетов UDP по 20 КБ, каждый из которых фрагментирован на 14 фрагментов IP.

Команды Iperf 3.7 для репликации потоков, похожих на настоящие:

iperf3 -c приемник -u -b 128M -t 600 -l 25256 --pacing-timer 1560
iperf3 -c приемник -u -b 400M -t 600 -l 20k --pacing-timer 1000

У вас есть идеи, что еще я забыл принять во внимание, что могло привести к тому, что симуляция была так далека от реальности? Спасибо за помощь!

Исходный код анимации находится по адресу https://gist.github.com/peci1/a0346538acc6c289b2c6d596b184ad21 .

Вот моя таблица результатов реальных экспериментов. Первый поток данных фиксированный - 128 Мбит/с в пакетах UDP по 25 кБ каждые 1,56 мс. Я менял параметры второго потока, пытаясь найти предел, при котором пакеты первого потока начнут теряться коммутатором. я менял -л (длина) параметр, определяющий размер UDP-пакета, и -б (пропускная способность) параметр, указывающий, какую пропускную способность должны генерировать эти пакеты. --pacing-таймер всегда был установлен на 1000 для второго потока. Как видите, D-Link и Netgear GS105 вообще не справляются с пакетами по 60 кБ. GS108 работает намного лучше, чем GS105, при этом у него почти такой же чип коммутатора (то же самое «семейство», только другое количество портов и немного больший буфер).

(Этот вопрос был перенесен из https://networkengineering.stackexchange.com/questions/78529/how-to-simulate-what-happens-inside-the-packet-buffer-of-a-simple-switch где это было помечено как не по теме).