Как мы тестируем SD-WAN: brownout, выбор пути и MOS голоса

На слайде SD-WAN failover занимает меньше секунды, и замерен он выдернутым кабелем. Настоящие underlay так чисто умирают редко. На канале MPLS появляются 2 % потерь и 40 мс jitter, интерфейс остается поднятым, зонды продолжают считать линк здоровым, и голос едет по плохому пути. Мы измеряем, сколько каждый класс приложений остается на деградировавшем канале и что в это время слышали пользователи.

Стенд

CPE филиала SD-WAN или хаб ставится в стойку CloudLAB либо запускается как VM на стенде или в вашем тенанте. У каждой площадки 2 или 3 underlay, и каждый проходит через эмулятор WAN, который задает задержку, jitter, потери, переупорядочивание и ограничение полосы в каждом направлении. Потери бывают случайными или пачками по модели Гилберта–Эллиотта, так, как теряют пакеты радиоканалы и перегруженные линии. Наш собственный эмулятор WANemu, сейчас в бете на линках 1G и 10G, кладет искажения, трафик и счетчики устройства на одну временную шкалу; на больших скоростях в контур ставится коммерческий эмулятор. Перед каждым прогоном генератор сверяет примененные значения.

Генератор играет пользователей за CPE и филиалы за хабом: голосовые и видеопотоки с оценкой каждую секунду, SaaS-подобные потоки поверх TLS, туннели IPsec с overlay-маршрутами к хабу. Политика ваша: классы приложений, интервалы и пороги SLA-зондов, очереди QoS, правила breakout из вашей выгрузки.

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

• Brownout: потери, задержка или jitter растут на одном underlay в известную секунду таймлайна сценария; время от первой плохой секунды до первой хорошей после перехода, по каждому классу приложений
• Жесткий failover: underlay обрывается; разрыв голоса и видео, оборванные сессии, сходимость overlay-маршрутов
• Failback: канал восстанавливается; когда трафик возвращается и не скачет ли он туда-обратно, пока brownout то появляется, то пропадает
• Steering: каждый класс идет по пути, который назначает политика, под нагрузкой и с DIA breakout
• QoE голоса: MOS каждого звонка посекундно, через brownout, переход и перегруженный канал с включенным QoS
• Масштаб туннелей: сколько туннелей держит хаб при трафике во всех, новые соединения в секунду, сходимость при падении хаба
• Накладные расходы шифрования: throughput IPsec в каждом направлении и по размеру пакета, от голосовых до 1400 байт, против скорости канала филиала

Underlay получает свои числа: Y.1564 по каждому сервису против договора с оператором и RFC 6349 для TCP throughput поверх overlay. Рядом со временем переключения они показывают, где причина медленного перехода: в политике, в устройстве или в канале.

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

Зонды, которые ничего не видят. Типичная приемка перед миграцией нескольких сотен филиалов: при 2 % потерь и 40 мс jitter на MPLS зонды по умолчанию считают путь здоровым, и голос остается на нем 90 с при дизайне 5 с. Более короткий интервал зондов, ниже порог потерь и правило по jitter сокращают переход до 3 с. Тест с выдернутым кабелем прошел в первый день и проблемой не был.

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

Накладные расходы. CPE филиала подбирают по числу из даташита, снятому на больших пакетах без шифрования. Внутри IPsec, с заголовками туннеля поверх мелких пакетов, которые филиал шлет на самом деле, скорость падает, и чем меньше пакет, тем больше разница. У хаба та же история с туннелями: на пустом устройстве поднимаются все, а в расчет идет число, которое держится при трафике в каждом.

Что в отчете

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

С чего начать

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