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

Как мы тестируем QoS: DSCP, очереди и голос на забитом канале

Alexander Zemskov 4 мин чтения
Как мы тестируем QoS: DSCP, очереди и голос на забитом канале

В даташите роутера написано: 8 очередей на порт, strict priority, WRED, иерархический шейпинг. В проектной документации голос помечен как EF и стоит в приоритетной очереди. Все это правда, и звонок все равно рассыпается в 9 утра. На свободном канале QoS ничего не делает. Он начинает работать, когда на выходной порт приходит больше, чем порт успевает отправить, поэтому мы тестируем его только в таком состоянии.

Стенд

Устройство под тестом (DUT): роутер или коммутатор либо SD-WAN edge с портами 1G, 10G или 100G (400G и быстрее – под проект), подключенными к генератору трафика. Генератор шлет по потоку на каждый класс: голос, видео, бизнес-приложения, массовая передача данных. У каждого потока своя маркировка DSCP или 802.1p, порядковый номер и метка времени в каждом кадре. Три входных порта нагружают один выходной, это переподписка 3:1 (пример; на стенде ставим соотношение ваших аплинков). У SD-WAN edge сторона WAN идет через эмулятор WAN с контрактной скоростью, задержкой и jitter каждого underlay.

Политика ваша: class map, границы доверия, веса очередей, policer и shaper из экспорта конфигурации. Фоновый трафик идет настоящим TCP и забирает все, что оставил планировщик, поэтому голосовая очередь конкурирует с тем же трафиком, что и в продакшене.

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

  • Маркировка: значения DSCP и 802.1p на выходе для каждого класса, на доверенных и недоверенных портах; сохраняется ли метка в туннеле, при перезаписи VLAN или под заголовком IPsec, если этого требует дизайн
  • Классификация: каждый класс попадает в свою очередь; счетчики очередей устройства сверяем с подсчетом по классам на генераторе
  • Планировщик при 3:1: доставленная скорость каждого класса против его доли в политике и лимит приоритетной очереди, чтобы она не задушила остальные
  • Задержка и jitter по классам: перцентили по каждому потоку, голос и видео против бюджета вашего дизайна, пока фоновый трафик забивает канал
  • Policing: нагрузка на 25% выше лимита; принятая скорость должна упасть до лимита без потерь среди кадров в пределах контракта
  • Shaping: тот же излишек ждет в буфере; измеряем добавленную задержку и размер пачки, которую шейпер поглощает до начала отбрасывания
  • H-QoS, если он есть в дизайне: родительский шейпер на филиал или абонента с очередями классов внутри; проверяем, достает ли фоновый трафик одного филиала до голоса другого

У каждого пункта критерий прохождения записан до старта, например максимальный jitter для голоса или ноль потерь для кадров в пределах контракта.

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

Метка. По отдельности все работает: VXLAN, выходной ACL, перемаркировка DSCP. Включите все три на одном порту, и значение DSCP теряется на выходе, а каждый следующий узел обрабатывает голос как best effort. Тест одной функции за раз этого не ловит, поэтому наш функциональный чек-лист гоняет функции вместе.

Второе: шейпер. У edge филиала порт 1G и контракт на 200 Мбит/с (пример). Без шейпера на 200 Мбит/с устройство никогда не видит перегрузки, его очереди пусты, а policer провайдера отбрасывает что попало, голос тоже. С шейпером очередь переезжает в устройство, которое настраивали вы.

Третье: классы проходят по одному и падают вместе. Типичная активация по Y.1564: CIR трех сервисов в сумме 620 Мбит/с, а policer на узле агрегации стоит на 450 Мбит/с, цифра из старой версии заказа. По отдельности ни один сервис до нее не доходит. Вместе доходят, и класс данных начинает терять кадры.

Что в отчете

Таблица по каждому классу: предложенная и доставленная скорость, потери, задержка и jitter по перцентилям, на каждой ступени нагрузки и при 3:1. Таблица маркировки: значение на входе и на выходе по каждому порту и узлу. Точность policer и шейпера относительно настроенной скорости. Счетчики очередей устройства рядом со счетчиками генератора. Экспорт политики, прошивка и план портов, чтобы вендор мог воспроизвести любой пункт.

С чего начать

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

Автор

Alexander Zemskov

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

Блог

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

СХД и дата-центры

Как мы тестируем гиперконвергентные кластеры: отказ узла и p99

Сайзинг HCI отвечает на один вопрос: сколько VM поместится на 4 узла, если один держать в резерве. Считают его на здоровом кластере. Заказчик читает «N+1» и ждет, что отк…

Alexander Zemskov 4 мин чтения
СХД и дата-центры

Как мы тестируем NAS: NFS, SMB, метаданные и отказ контроллера

В даташите NAS одна цифра: последовательное чтение в GB/s, снятое на больших файлах с нескольких клиентов. На ресурсе с домашними каталогами или на сборочной ферме сотни …

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