Преамбула
Ранее мной уже был опубликован цикл статей по теме SD-WAN. В некоторых статьях раскрывались детали работы решения Kaspersky SD-WAN. Делюсь, если интересно: первая, вторая, третья.
Новая статья – их продолжение. В конце 2025 года был выпущен новый релиз продукта Касперский SD-WAN версия 2.5, в который были внесены существенные изменения в функционал, обеспечивающий стабильность связи. Здесь детально разберу механизмы балансировки в режиме нестабильности связи и способы борьбы с такими проблемами в версии 2.5.
Введение
Ситуацию, когда все работает идеально, оставим для рекламных буклетов и презентаций вендора. В нашем тесте мы смоделируем «деградацию» интернет-канала одного из провайдеров.
К сожалению, сбои случаются, как правило, в самый неподходящий момент, и перегрузка одного из активных каналов может негативно сказаться на производительности пользовательского трафика. Пользователи SD-WAN ждут, что сеть сама адаптируется к изменениям. В большинстве случаев это происходит именно так, как обещает производитель, но бывают ситуации, неочевидные даже для опытных специалистов. Как сеть Kaspersky SD-WAN среагирует на такие события, и будем разбираться в этой статье.
Описание тестового стенда и ограничения
Для целей тестирования в нашей лаборатории была развернута сеть, состоящая из двух SD-WAN CPE:
Kaspersky SD-WAN ESR (R) Model 1 (железка с LTE модемом и 5ю Ethernet портами) на стороне клиента IPERF;
Kaspersky SD-WAN Virtual M1 развернутый в «облаке» на гипервизоре, на стороне сервера IPERF.
На стороне клиента подключены два провайдера – проводной и LTE. На проводном провайдере установлено ограничение входящего и исходящего трафика, имитирующее «деградацию» интернет-канала. Случай, при котором вроде и связь есть, и трекинг не выключает порт, но и работать с таким каналом невозможно.
Между двумя CPE установлены 2 линка (Link в терминах SD-WAN) в каждую сторону (всего 4), которые формируют отказоустойчивый сегмент (Segment) для прохождения трафика.
Для генерации трафика и измерения скорости передачи использовалась утилита Iperf3. В дан��ой статье рассматривается только TCP трафик, как наиболее распространённые в интернет (для UDP картина будет другой).
С тестового компьютера по очереди запускается два теста в 8 параллельных потоков. Тестирование в один поток не показательно, так как скорее всего может исказить результаты балансировки – из-за того, что весь трафик может попасть в один канал провайдера. Примечание: одновременные прием и передача не исследовались в данной статье, так как тесты запускали один за одним. Графики отражают трафик от сервера к клиенту.
Система мониторинга на основе Zabbix снимает метрики потребления сетевого трафика каждые 10 секунд c виртуальной и физической CPE. На стороне клиента метрики снимаются с портов sdwan0 и sdwan1. На стороне сервера суммированный трафик измеряется на интерфейсе ближе к серверу, чтобы визуализировать итоговый результат.
Таким образом, графики мониторинга Zabbix позволяют оценить загрузку каналов и результирующий трафик для каждого варианта балансировки трафика, рассмотренного далее.
На стороне IPERF сервера трафик TCP исследуется с помощью встроенных средств программы Wireshark.
Балансировка по пакетам (Per-packet)
Adaptive balancing: выключена
Режим, в котором пакеты равномерно распределяются между каналами без учета «деградации». Канал, который «не может», просто теряет пакеты. Даже при стабильной работе, с точки зрения TCP, такая балансировка является самым неудачным решением. Механизм TCP не может рассчитать оптимальную скорость для каждого канала в отдельности, и канал останется недозагруженным.
Стоимость итогового пути и вес канала зависят от физической скорости порта и могут быть сконфигурированы вручную на основе SLA провайдера. В этом случае трафик будет балансироваться неравномерно, а на основе стоимости вычисленной по формуле:
Cost = 10 000 000 / Speed, где Speed берется с физического порта интерфейса или может быть задана в параметре «max rate».
Хотел особо подчеркнуть, что в идеальных условиях и работающих каналах интернета необходимо сконфигурировать реальные скорости для определения правильного баланса. Если скорости каналов разных интернет-провайдеров портов SD-WAN заметно отличаются, то включение балансировки покажет неоптимальные результаты без такого конфига.
Примечание: здесь разбирается случай, когда канал первого провайдера работает, на «сильно пониженной скорости», поэтому результат будет максимально приближен. Далее увидим, что при некоторых вариантах балансировки передача трафика может даже полностью остановится.
После запуска Iperf анализируем загрузку портов SD-WAN:
Скорость низкая, пропускная способность второго провайдера «подравнивается» под первого. Итоговый трафик суммируется, но не поднимается выше х2 «деградировавшего» канала.
График TCP-сессий на сервере показывает огромное количество ошибок TCP-соединения и объясняет медленную скорость:
Замеры IPERF показывают и подтверждают грустные результаты:
Трафик от сервера к клиенту (на его основе построены графики выше):
[ ID] Interval Transfer Bitrate
[ 5] 0.00-840.00 sec 7.62 MBytes 76.1 Kbits/sec sender
[ 8] 0.00-840.00 sec 23.9 MBytes 238 Kbits/sec sender
[ 10] 0.00-840.00 sec 19.4 MBytes 193 Kbits/sec sender
[ 12] 0.00-840.00 sec 16.9 MBytes 169 Kbits/sec sender
[ 14] 0.00-840.00 sec 896 KBytes 8.74 Kbits/sec sender
[ 16] 0.00-840.00 sec 21.1 MBytes 211 Kbits/sec sender
[ 18] 0.00-840.00 sec 14.9 MBytes 149 Kbits/sec sender
[ 20] 0.00-840.00 sec 22.0 MBytes 220 Kbits/sec sender
[SUM] 0.00-840.00 sec 127 MBytes 1.26 Mbits/sec sender
Трафик от клиента к серверу:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-240.12 sec 4.75 MBytes 166 Kbits/sec receiver
[ 8] 0.00-240.12 sec 1.62 MBytes 56.8 Kbits/sec receiver
[ 10] 0.00-240.12 sec 2.12 MBytes 74.2 Kbits/sec receiver
[ 12] 0.00-240.12 sec 4.00 MBytes 140 Kbits/sec receiver
[ 14] 0.00-240.12 sec 4.38 MBytes 153 Kbits/sec receiver
[ 16] 0.00-240.12 sec 4.62 MBytes 162 Kbits/sec receiver
[ 18] 0.00-240.12 sec 4.25 MBytes 148 Kbits/sec receiver
[ 20] 0.00-240.12 sec 4.38 MBytes 153 Kbits/sec receiver
[SUM] 0.00-240.12 sec 30.1 MBytes 1.05 Mbits/sec receiver
Текущий вариант оказался худшим вариантом балансировки для трафика TCP, и не просто не способен бороться с деградацией каналов, а даже останавливает работу рабочих. Замечу, что в штатном режиме, когда все каналы работают, мы увидим адекватный результат. Решения проблемы есть, и одно из них будет рассмотрено в данной статье.
Все на дно!
Балансировка по потокам (Per-flow)
Adaptive balancing: выключена
Распределение пакетов между каналами осуществляется на основе хэш-функции, вычисляемой от 5 значений: IP и Port отправителя, IP и Port получателя, и протокола. Такой режим позволяет одному TCP потоку оставаться на одном канале от начала и до конца. В нашем случае мы ожидаем что половина TCP сессий попадет на «хороший» канал, а половина – на «деградировавший».
По мониторингу трафика на SD-WAN портах мы видим существенное увеличение скорости по сравнению с «балансировкой по пакетам»:
Если смотреть очень внимательно, мы даже можем заметить, что трафик на двух каналах суммируется, и мы довольно хорошо «утилизируем» оба канала.
График TCP сессий на сервере показывает большое количество ошибок TCP-соединения:
Но на самом деле, картина складывается очень печальная. «Средняя температура по больнице в норме, если сложить мертвых с больными», а вот если анализировать потоки TCP, мы увидим проблемы.
Трафик от сервера к клиенту:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-678.62 sec 113 MBytes 1.40 Mbits/sec sender
[ 8] 0.00-678.62 sec 4.00 MBytes 49.4 Kbits/sec sender
[ 10] 0.00-678.62 sec 4.12 MBytes 51.0 Kbits/sec sender
[ 12] 0.00-678.62 sec 5.50 MBytes 68.0 Kbits/sec sender
[ 14] 0.00-678.62 sec 384 KBytes 4.64 Kbits/sec sender
[ 16] 0.00-678.62 sec 7.00 MBytes 86.5 Kbits/sec sender
[ 18] 0.00-678.62 sec 158 MBytes 1.95 Mbits/sec sender
[ 20] 0.00-678.62 sec 8.75 MBytes 108 Kbits/sec sender
[SUM] 0.00-678.62 sec 301 MBytes 3.72 Mbits/sec sender
Трафик от клиента к серверу:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-420.08 sec 5.62 MBytes 112 Kbits/sec receiver
[ 8] 0.00-420.08 sec 3.25 MBytes 64.9 Kbits/sec receiver
[ 10] 0.00-420.08 sec 73.0 MBytes 1.46 Mbits/sec receiver
[ 12] 0.00-420.08 sec 77.6 MBytes 1.55 Mbits/sec receiver
[ 14] 0.00-420.08 sec 58.2 MBytes 1.16 Mbits/sec receiver
[ 16] 0.00-420.08 sec 5.50 MBytes 110 Kbits/sec receiver
[ 18] 0.00-420.08 sec 4.12 MBytes 82.4 Kbits/sec receiver
[ 20] 0.00-420.08 sec 73.5 MBytes 1.47 Mbits/sec receiver
[SUM] 0.00-420.08 sec 301 MBytes 6.01 Mbits/sec receiver
-----------------------------------------------------------
Видно, что часть сессий работает с приемлемой скоростью, а часть фактически стоит. С точки зрения пользователей – это максимально «негативный опыт». Что-то иногда работает, а что-то – нет.
Аналогично случаю с пакетной балансировкой, данный механизм не может бороться с деградацией канала оптимальным способом, хотя «графики» и показывают «результат».
Балансировка в широковещательном режиме (Broadcast)
Пакеты отправляются во все доступные каналы провайдеров. Обрабатывается первый полученный пакет: фактически он не является «балансировкой», и получить суммирование пропускной способности не получится. Применяется, когда требуется максимальная отказоустойчивость трафика с минимальной задержкой в ущерб скорости и стоимости.
Мониторинг трафика на SD-WAN портах (показаны оба направления передачи):
Несмотря на то, что канал первого провайдер «шейпится», мы видим «всплеск» трафика намного выше пропускной способности канала. Это связано с тем, что клиент отправляет пакет независимо от того, дойдет он до получателя или нет. Ограничение срабатывает уже после того, как трафик вышел от клиента.
Анализ ТСР потока показывает, что скорость умеренно хорошая, но в трафике присутствует большое количество дублированных пакетов (DUP).
Трафик от сервера к клиенту:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-360.21 sec 37.1 MBytes 865 Kbits/sec receiver
[ 8] 0.00-360.21 sec 37.6 MBytes 876 Kbits/sec receiver
[ 10] 0.00-360.21 sec 37.8 MBytes 879 Kbits/sec receiver
[ 12] 0.00-360.21 sec 37.5 MBytes 873 Kbits/sec receiver
[ 14] 0.00-360.21 sec 37.5 MBytes 873 Kbits/sec receiver
[ 16] 0.00-360.21 sec 38.2 MBytes 891 Kbits/sec receiver
[ 18] 0.00-360.21 sec 37.6 MBytes 876 Kbits/sec receiver
[ 20] 0.00-360.21 sec 37.5 MBytes 873 Kbits/sec receiver
[SUM] 0.00-360.21 sec 301 MBytes 7.01 Mbits/sec receiver
Трафик от клиента к серверу:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-261.10 sec 38.0 MBytes 1.22 Mbits/sec sender
[ 8] 0.00-261.10 sec 36.5 MBytes 1.17 Mbits/sec sender
[ 10] 0.00-261.10 sec 37.6 MBytes 1.21 Mbits/sec sender
[ 12] 0.00-261.10 sec 37.9 MBytes 1.22 Mbits/sec sender
[ 14] 0.00-261.10 sec 38.4 MBytes 1.23 Mbits/sec sender
[ 16] 0.00-261.10 sec 36.6 MBytes 1.18 Mbits/sec sender
[ 18] 0.00-261.10 sec 37.5 MBytes 1.20 Mbits/sec sender
[ 20] 0.00-261.10 sec 38.4 MBytes 1.23 Mbits/sec sender
[SUM] 0.00-261.10 sec 301 MBytes 9.67 Mbits/sec sender
Хоть широковещательный режим и не является «балансировкой» как таковой, но только он позволяет незаметно пережить «деградацию» канала интернет. Такой режим показывает максимальную стабильность, но очевидно не обеспечивает суммирование, хотя все каналы загружаются «на максимум».
Без балансировки
Прежде чем включать адаптивные механизмы, появившиеся в версии 2.5, попробуем полностью убрать балансировку, отключив первого провайдера, и посмотрим, какие варианты были эффективны.
TCP-соединение для потока от сервера к клиенту:
Резул��таты IPERF для соединения от сервера к клиенту:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-200.10 sec 33.4 MBytes 1.40 Mbits/sec sender
[ 8] 0.00-200.10 sec 39.0 MBytes 1.63 Mbits/sec sender
[ 10] 0.00-200.10 sec 37.5 MBytes 1.57 Mbits/sec sender
[ 12] 0.00-200.10 sec 34.1 MBytes 1.43 Mbits/sec sender
[ 14] 0.00-200.10 sec 35.1 MBytes 1.47 Mbits/sec sender
[ 16] 0.00-200.10 sec 46.6 MBytes 1.95 Mbits/sec sender
[ 18] 0.00-200.10 sec 36.4 MBytes 1.52 Mbits/sec sender
[ 20] 0.00-200.10 sec 38.8 MBytes 1.62 Mbits/sec sender
[SUM] 0.00-200.10 sec 301 MBytes 12.6 Mbits/sec sender
Результаты IPERF для соединения от клиента к серверу:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-540.06 sec 38.6 MBytes 600 Kbits/sec receiver
[ 8] 0.00-540.06 sec 52.4 MBytes 814 Kbits/sec receiver
[ 10] 0.00-540.06 sec 43.4 MBytes 674 Kbits/sec receiver
[ 12] 0.00-540.06 sec 50.4 MBytes 782 Kbits/sec receiver
[ 14] 0.00-540.06 sec 18.4 MBytes 285 Kbits/sec receiver
[ 16] 0.00-540.06 sec 35.0 MBytes 544 Kbits/sec receiver
[ 18] 0.00-540.06 sec 27.1 MBytes 421 Kbits/sec receiver
[ 20] 0.00-540.06 sec 33.2 MBytes 516 Kbits/sec receiver
[SUM] 0.00-540.06 sec 298 MBytes 4.64 Mbits/sec receiver
Результат показывает, что «деградировавший» канал оказывает негативное влияние на общее состояние всех ТСР-соединений. Убрав его из дата-плана, можно улучшить «здоровье» ТСР и даже увеличить общую скорость (даже в режиме broadcast).
В версии 2.4 мы решали проблему конфигурированием и тюнингом SLA для линков и, косвенно, трекингом для портов. Балансировка достигалась конфигурацией стоимости линков между парами нагруженных СРЕ. Такой механизм до сих пор дает максимальный уровень стабильности (и для версии 2.5), но добавляет «ручной» работы по оптимизации. Требуется квалификация инженеров и четкое понимание скоростных характеристик канала, предоставляемых провайдером.
Версия Kaspersky SD-WAN 2.5 принесла новый функционал динамического изменения веса канала (линка) на основе потерь, зафиксированных в этом канале.
Адаптивная балансировка по пакетам (Per-packet)
Adaptive balancing: включена
Окно конфигурации выглядит просто:
Необходимо задать начальный порог потерь, после которого начинается балансировка. Чем раньше начнем, тем эффективнее будет распределение. Максимальный уровень потерь – значение, при котором канал полностью будет исключен из дата-плана.
Запустим IPERF и посмотрим на метрики Zabbix:
До того, как механизм «адаптации» сработал, были задействованы оба канала.
По графикам видно, что потребовалось время на определение метрик (весов) для каналов, и, после процесса адаптации, были найдены рабочие «цифры». В результате скорость оптимизировалась, а количество «ошибок» TCP пришло к обычным значениям, характерным для рабочего канала.
Пример статистики динамического расчета «веса» каналов:
4 значения показывают вес для двух линков в каждом направлении. Видно, что вес кратно отличается и «деградировавший» канал почти не используется.
Результаты IPERF для соединения от сервера к клиенту:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-264.48 sec 41.8 MBytes 1.32 Mbits/sec sender
[ 8] 0.00-264.48 sec 33.4 MBytes 1.06 Mbits/sec sender
[ 10] 0.00-264.48 sec 37.2 MBytes 1.18 Mbits/sec sender
[ 12] 0.00-264.48 sec 39.4 MBytes 1.25 Mbits/sec sender
[ 14] 0.00-264.48 sec 38.9 MBytes 1.23 Mbits/sec sender
[ 16] 0.00-264.48 sec 38.8 MBytes 1.23 Mbits/sec sender
[ 18] 0.00-264.48 sec 35.8 MBytes 1.13 Mbits/sec sender
[ 20] 0.00-264.48 sec 35.8 MBytes 1.13 Mbits/sec sender
[SUM] 0.00-264.48 sec 301 MBytes 9.54 Mbits/sec sender
Результаты IPERF для соединения от клиента к серверу:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-420.15 sec 39.1 MBytes 781 Kbits/sec receiver
[ 8] 0.00-420.15 sec 39.8 MBytes 794 Kbits/sec receiver
[ 10] 0.00-420.15 sec 40.8 MBytes 814 Kbits/sec receiver
[ 12] 0.00-420.15 sec 33.8 MBytes 674 Kbits/sec receiver
[ 14] 0.00-420.15 sec 30.9 MBytes 616 Kbits/sec receiver
[ 16] 0.00-420.15 sec 35.5 MBytes 709 Kbits/sec receiver
[ 18] 0.00-420.15 sec 39.8 MBytes 794 Kbits/sec receiver
[ 20] 0.00-420.15 sec 41.5 MBytes 829 Kbits/sec receiver
[SUM] 0.00-420.15 sec 301 MBytes 6.01 Mbits/sec receiver
Метод показал хорошие результаты, каналы загружаются равномерно, согласно доступной пропускной способности, а ТСР может найти подходящие параметры.
Несмотря на то, что балансировку по пакетам не рекомендуется использовать для ТСР-соединений, данный режим может быть применен без серьезных проблем для ТСР-сессии.
Но можно лучше. Победитель далее.
Адаптивная балансировка по потокам (Per-flow)
Adaptive balancing: включена
Работает аналогично балансировке по потокам рассмотренной выше (БЕЗ адаптивного режима). В данном тесте добавим динамическое вычисление стоимости сети.
Вычисление стоимости каналов начнется при потерях более 0.01%:
Результат загрузки портов SD-WAN:
Основная нагрузка практически сразу ложится на рабочий канал. Анализ трафика ТСР:
TCP параметры подстраиваются практически сразу, и их трудно отличить от «нормальных».
Мгновенный «снимок» с распределением «весов»:
Для канала, забитого трафик��м, мы видим соотношение 3 к 24415. Цифры динамически меняются в зависимости от потерь пакетов.
Замеры IPERF показали максимальные результаты среди всех замеров разных вариантов балансировки.
Результаты измерения от сервера к клиенту:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-200.30 sec 37.2 MBytes 1.56 Mbits/sec sender
[ 8] 0.00-200.30 sec 39.5 MBytes 1.65 Mbits/sec sender
[ 10] 0.00-200.30 sec 38.8 MBytes 1.62 Mbits/sec sender
[ 12] 0.00-200.30 sec 38.5 MBytes 1.61 Mbits/sec sender
[ 14] 0.00-200.30 sec 36.4 MBytes 1.52 Mbits/sec sender
[ 16] 0.00-200.30 sec 37.2 MBytes 1.56 Mbits/sec sender
[ 18] 0.00-200.30 sec 34.5 MBytes 1.44 Mbits/sec sender
[ 20] 0.00-200.30 sec 38.9 MBytes 1.63 Mbits/sec sender
[SUM] 0.00-200.30 sec 301 MBytes 12.6 Mbits/sec sender
Результаты измерений от клиента к серверу:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-480.08 sec 42.8 MBytes 747 Kbits/sec receiver
[ 8] 0.00-480.08 sec 48.2 MBytes 843 Kbits/sec receiver
[ 10] 0.00-480.08 sec 6.25 MBytes 109 Kbits/sec receiver
[ 12] 0.00-480.08 sec 57.0 MBytes 996 Kbits/sec receiver
[ 14] 0.00-480.08 sec 10.9 MBytes 190 Kbits/sec receiver
[ 16] 0.00-480.08 sec 65.0 MBytes 1.14 Mbits/sec receiver
[ 18] 0.00-480.08 sec 6.12 MBytes 107 Kbits/sec receiver
[ 20] 0.00-480.08 sec 63.5 MBytes 1.11 Mbits/sec receiver
[SUM] 0.00-480.08 sec 300 MBytes 5.24 Mbits/sec receiver
Заметна асинхронность канала, но, тем не менее, мы достигаем высоких результатов с такой схемой. Трафик суммируется, очереди и загрузки каналов – самые ровные и честные.
Выводы и ограничения
В данной статье исследовался только TCP-трафик. Лучший вариант балансировки такого трафика – адаптивная балансировка по потокам.
Балансировка менее эффективна чем выбор одного хорошего канала. Самый стабильный вариант — это выбор одного лучшего канала по SLA. В этом случае потребуется больше конфигурации и более глубокое погружение в «линк-менеджмент», но и стабильность всей сети будет на самом высоком уровне.
Понимание механизмов балансировки трафика важно для правильного конфигурирования Kaspersky SD-WAN. Некоторые варианты конфигурации могут привести к деградации всей сети.
Прием и передача оценивались отдельно.
Существует ограничение «физических» возможностей для каждого типа СРЕ. При достижении скорости интернет-каналов соответствующей максимальной пропускной способности СРЕ уже пропадает смысл балансировки. Распределение трафика по каналам будет отличаться от представленных выше. Мы учитывали этот момент в тестировании.
Надеюсь, информация была полезной. Статья не претендует на научность, а показывает «живой» пример балансировки трафика на решении Kaspersky SD-WAN. Если вы заметите некорректность или нечестность тестов, прошу высказываться в комментариях, постараюсь исправиться. Если вы видите, что необходимо провести тесты на другом трафике, тоже прошу подать знак. Так я пойму, что этот материал для вас полезен.
