Преамбула
Я работаю в сервисной компании, и в своей работе мы часто используем российские SD-WAN- решения. Делаем крупные и нестандартные внедрения, а также предоставляем сеть по «подписочной модели» на основе Kaspersky SD-WAN.
Ранее я уже писал статьи об объединении сетей с одинаковым адресным пространством и трудностях миграции на SD-WAN. Нынешняя, третья статья из этого цикла будет максимально техническая, описывает механизмы переключения «сбойных» каналов решением SD-WAN от Касперского версии 2.4. Я думаю, что она позволит читателю получить представление об инструментах, доступных в решении, а также раскроет важные детали архитектуры. В ней не будет информации о кластеризации и обеспечении отказоустойчивости центральных компонентов и системы в целом, только механизмы борьбы с «разрывами».
Теория
Решения SD-WAN от Касперского многослойное и «многокомпонентное», где каждый компонент имеет свою скорость переключения и отказоустойчивость, и резервирование. До того, как начнем говорить об отказоустойчивости и скорости переключения «каналов» вначале погрузимся немного в теорию. Важно определиться с терминологией и разобраться что именно мы можем настраивать на SD-WAN устройстве, как формируются «каналы данных» и правильно называются.
Решение четко выделяет несколько независимых абстракций:
Data plane (передающий уровень) — каналы передачи данных, именно ради этого уровня и работают все другие компоненты. Используется протокол UDP и порты 4800-4807.
Control plane (управляющий уровень) — программная сеть (SD‑WAN) управляется контролером. Именно контролер составляет непротиворечивую карту сети. Наличие контролера — это важный маркер для того чтобы понять, а является ли сеть «настоящим» SD‑WAN или только «оптимизатором» путей. В «традиционных» сетях (не SD‑WAN) задачей создания непротиворечивой топологии занимались такие протоколы как, RIP, EIRGP, OSPF, BGP, ISIS, STP, SSTP, MSTP и др (вариантов очень много).
В нашем случае управляющий (control) трафик «ходит» по независимому каналу и собирается в «центре» не используя канал данных. В случае сбоя или блокировки трафика этого уровня абстракции сеть SD‑WAN «монолитится» т. е. пути Data plane не могут меняться, но продолжают работать.Management plane (уровень конфигурирования) — отдельный канал для конфигурирования устройств, снятия диагностической информации и функций управления. В случае проблем с этим уровнем мы теряем возможность изменения конфигурации устройства, но СРЕ может стабильно передавать трафик в Data plane и адекватно изменять топологию сети (через Control plane)
Monitoring plane (уровень мониторинга) — отдельный канал для передачи метрик работы оборудования. Выделен отдельно для того чтобы не использовать Data plane «какого‑то клиента». Такая архитектура позволяет полностью отделить сеть передачи данных, от служебной (технической) информации.
Каждый «уровень абстракции» использует свои независимые каналы и, самое главное для темы данной статьи, — разную скорость и механизмы переключения между рабочими провайдерами и сетями.
Рисунок показывает связь, и самое главное влияние того или иного параметра конфигурации на разные слои решения SD-WAN от Касперского. Например, «Port» контролируется параметром «tracking» и в случае сбоя запускает «волну изменений на уровне «линка», уровня данных, управления и конфигурирования. А вот «линки» будут влиять только на data plane. Отдельно стоит VRRP, так как этот механизм непосредственно не влияет на другие слои и в данной статье не рассматривается.
Фактически слово «Cluster» использованное на рисунке не является корректным, реальная кластеризация не предусмотрена, т.к. фактически не нужна в большинстве случаев. Механизм позволяет перенаправить трафик на виртуальный адрес одной из СРЕ. Сами SD-WAN- устройства перестраивать туннели данных вслед за VRRP не будут. В данной статье VRRP не рассматривается.
Но сфокусируемся на скорости переключения «каналов» уровня данных (data plane).
Выше мы использовали несколько терминов, понимание значения которых помогут сделать корректную конфигурацию «туннелей»:
CPE — физическое или виртуальное устройство. Имеет какое‑то количество сетевых карт разного типа, в том числе LTE модемы. Зависит от модели «железки».
-
Port — Сетевая карта физическая или виртуальная, в том числе 802.1Q и LTE. Часть портов формируют SD‑WAN сеть и подключаются к провайдерам, MPLS или изолированным сетям, а часть портов используется для подключения конечных клиентов (локальная сеть). На практике один порт может играть обе роли, но потребуется изменить шаблон по умолчанию и правила межсетевого экранирования (это не по best practice).
Порт sdwan используется для формирования линков, выхода локальных пользователей напрямую в интернет, работы management/monitoring уровней.
Link — однонаправленный туннель между портами sdwan разных СРЕ. Линк односторонний, т. е. для соединения двух портов разных СРЕ потребуется не менее двух линков направленных на встречу двух СРЕ. При топологии Full Mesh линков становиться очень много, так как соединяются не просто все СРЕ, а именно все порты sd‑wan всех СРЕ. Установленные линки это еще не значит, что по ним будет передаваться данные, это просто рабочие туннели, готовые оперативно подключиться, если другой путь данных перестанет работать.
Segment — это собственно и есть путь данных, в общем случае набор линков с меньшей суммарно ценой (cost) и удовлетворяющих политикам качества. В идеале сегмент должен совпадать с линком, это значит, что установлен прямой туннель между двумя СРЕ. Если это невозможно (какой‑то линк не работает), сегмент использует доступные линки, проходящие через другие СРЕ. Если сегмент не прямой, а проходит через другие СРЕ, то мы видим не оптимальное использование каналов.
Всегда имеется несколько готовых запасных сегментов (8/2 в конфигурации по умолчанию) готовых подключится в случае сбоя текущего. Т.е. как только срабатывает один из триггеров, описанных в этой статье уже есть готовые кандидаты на переключение.
Следующие параметры доступны на уровне всего контролера, СРЕ и каждого сегмента:
Maximum number of paths — количество путей между двумя точками готовых к работе в случае сбоя основных.
Auto‑SPF maximum — количество путей, используемых при балансировке трафика.
Сегменты могут использоваться и параллельно в нескольких режимах:
Балансировки по потокам TCP — позволяет использовать всех провайдеров для балансировки трафика по потокам TCP.
Broadcast — копирование трафика во все рабочие сегменты. Первый доставленный пакет и будет обработан. Максимальная скорость и защита от потерь.
Балансировка по пакетам — может быть более оптимальна в редких случаях чем по потокам TCP. Для обычного, привычного «пользовательского» трафика не подходит, так как очень сильно мешает работе стандартных механизмов TCP.
Возможно задать множитель «цены» для увеличения количества путей трафика, в этом случае все пути будут балансироваться поровну (Cost variance multiplier). Возможно делать балансировку с учетом стоимости пути и отправляя в каждый путь не равное количество данных (Multi-weight balancing), а пропорционально цены сегмента.
Балансировка и множество путей вносит определенную сложность в траблшутинг, и своевременное реагирование на изменение сети. Ведь часть трафика идет по одному каналу, а, часть по-другому. Это означает что у пользователей какие-то приложения работают с разными скоростями, задержками и т.п.
Будем честны, для стабильной предсказуемой работы «без разрывов и стабильности для всех» опции балансировки лучше использовать с осторожностью, выбирая самый лучший канал по качеству. В базовой конфигурации по умолчанию, при включении SLA для линков, остается как раз только один лучший путь, без возможности балансировки. Балансировка — это то, к чему следует подойти осознанно, задав правильные скорости каналов провайдеров.
Разобравшись с терминами и зависимостями, можно приступить к описанию собственно механизмов «борьбы с разрывами» и «замерить» скорости переключения.
Механизм трекинга (tracking)
Базовый механизм, включенный по умолчанию. Полностью отключить невозможно, можно только тюнить. Каждый порт SD-WAN обязательно ведет контроль наличия связи с «каким-то» соседом (tacking) по протоколу ICMP. Через заданные промежутки времени (interval) SD-WAN интерфейс отправляет стандартные icmp-запросы на один или несколько адресов «трекинга» (IP address for tracking).
В стандартном шаблоне каждые 2 секунды (interval) на адрес 8.8.8.8 отправляется 2 эхо-запроса. Порт считается не рабочим, если на все «пинги», т.е., 2 раза (count) не будет получен ответ. На рисунке для каждого отдельного «пинга» установлен лимит ожидания 2000 мс.
Для надежности можно вести трекинг нескольких адресов:
Параметр Reliability позволяет задать количество адресов, которые обязательно должны отвечать. Число 1 фактически реализует логический элемент «ИЛИ». Поставив число 2 в это поле, мы реализуем логическое «И».
В результате конфигурации портов sdwan0, sdwan1 и sdwan2, представленной на скриншотах выше, мы видим состояние трех sdwan каналов. Все три находятся в состоянии online (рабочем состоянии):
Skipped означает, что реализовано условие ИЛИ в трекинге и ответ от 8.8.8.8 не требуется пока отвечает 158.160.135.94. Замечу, что, «несмотря на skipped», запросы ICMP отправляются на оба адреса.
В общей таблице маршрутизации на устройстве (main vrf) появляются такие записи:
Таблица маршрутизации используется слоями management и monitoring plane, а также для прямого выхода пользователей в «интернет» в обход SD-WAN (используя NAT). Для построения линков и трафика управления эти IP маршруты не используются, но важны для служебных целей.
Метрики расставляются по порядку следования интерфейсов sdwan. Первый канал sdwan0 имеет приоритет с метрикой 1, второй sdwan1 — метрику 2 и т. д. В случае «падения» порта по трекингу, метрика повышается на 20, но маршрут полностью не убирается из таблицы маршрутизации. Пример отображения таблицы маршрутизации при «упавшем» интерфейсе для «проводных» каналов:
Такое поведение позволяет держать порт sdwan в активном состоянии, но не использовать его в случае «провала» трекинга. Ведь:
трекинг может не работать даже при наличии интернет. В этом случае мы будем иметь доступное управление и мониторинг;
постоянные включения/выключение порта запускают целую сеть событий на СРЕ с перегрузкой разных сервисов. СРЕ «штормит»;
можно зайти на СРЕ по протоколу SSH.
Для LTE-модемов поведение другое. В отсутствие трекинга происходит регулярные включения и выключения модема. Такое спорное решение поможет «рестартануть» физическое подключение LTE в метах с нестабильной связью, но это особенность «железа»
Cвязь разных параметров трекинга легче понять по следующему рисунку, показывающему время обнаружения проблемы на порту при худшем сценарии:
Неработающий порт sdwan приводит к отключению всех линков на этом порту и как следствие полному исключению порта из data plane. Полностью физический порт не отключается, а продолжает работать с повышенной метрикой, таким образом management plane и другие сервисы могут даже продолжить работу.
Можно вполне безболезненно «подвинуть» Timeout до 100-500мс, но ключевым временем, влияющим на переключение является Interval и Count. Надо понимать что, поставив слишком маленькие значения увеличится риск более частого «мигания» каналов, например, при DoS атаке. Однозначно параметры будут зависеть от цели, которую мы пингуем. Адрес 8.8.8.8 задан в шаблонах по умолчанию, но, конечно, не является максимально надежным, поэтому, в каждом случае выбирается свой набор параметров для трекинга.
В любом случае «золотого» времени, подходящего на все случаи жизни – нет. Значения, заданные по умолчанию, позволяют определить «обрыв» довольно оперативно (быстрее 4с), а настроенные более оптимально даже так, что пользователи не заметят обрыва соединения при переключении (1-2с).
Механизм трекинга самый понятный и прямолинейный, но довольно «глупый», т. к. не учитывает множество факторов. Возможно,он является немного избыточным и «не интуитивно» управляемым для переключения линков при DoS атаках, но он играет важную роль для трафика выходящего напрямую в интернет. Ждем, что в следующих версиях SD-WAN он будет как-то переработан.
Далее разберем более «интеллектуальные» механизмы.
CFM (Connectivity Fault Management)
CPE отправляет контрольные пакеты Continuity Check Message (CCM) на каждом линке через определенные интервалы времени и ожидает получения ответных контрольных пакетов через встречные соединения. При отсутствии ответных контрольных пакетов устройство считает два линка недоступными и переключается на доступный сегмент не содержащий с воем пути эти линки.
Время ожидания ответных контрольных пакетов равняется интервалу времени для отправки контрольных пакетов, умноженному на 3.5. Время переключения устройства CPE на новое соединение при отсутствии ответных контрольных пакетов равняется интервалу времени для отправки контрольных пакетов, умноженному на число в диапазоне от 3.5 до 7.
Например, если в качестве интервала времени для отправки контрольных пакетов указано 300 миллисекунд, время ожидания ответных контрольных пакетов составит 1.05 секунды, а время переключения устройства CPE на новое соединение при отсутствии ответных контрольных пакетов составит от 1.05 до 2.1 секунд.
Для медленных каналов 300мс считается довольно агрессивным временем, поэтому, мы стараемся использовать время 1с. Это дает от 3 до 7 секунд гарантированное время переключения на резервный линк.
В целом механизм CFM принципиально, возможно, схож с трекингом портов, но только CFM работает более адресно и более точно. И вот почему:
CFM проверяет и блокирует не весь порт, а только пару линков между парами устройств;
определяет то, что не может определить трекинг, т.е. реальные каналы слоя передачи данных, а не «сферический вакуум=роутер» с помощью пингов.
По своему опыту скажу, что механизм необходимый, хотя и не включен по умолчанию. Позволяет быстро и надежно исключить линк до того, как сработает SLA (описание далее). Иногда, при отсутствии трафика только этот механизм и позволит понять, что между парами устройств случилась какая-то беда. Более того, при отсутствии прямого трафика в интернет от пользователей, может более качественно заместить трекинг.
SLA (Link thresholds)
Самый интеллектуальный способ исключения «плохих» линков из слоя передачи данных. По умолчанию механизм выключен. Мы можем включить мониторинг на линках на основе следующих параметров:
Error level (количество ошибок);
Utilization (загрузка канала);
Latency (задержка передачи пакетов уровня данных);
Jitter (стабильность задержки передачи пакетов уровня данных);
Packet Loss (потери пакетов уровня данных).
Error level и Utilization довольно спорные, и в больших инсталляциях мы используем их редко (читать «не используем»). Ниже расскажу, почему.
Включая SLA необходимо обязательно определить, что делать если не окажется альтернативных линков, с приемлемым качеством. «Ignore if no constrained path is found» — означает, что канал может быть использован несмотря на деградировавший SLA, если не будет другой альтернативы. Если этот флажок не установлен, несколько линков могут быть заблокированы вплоть до полной блокировки data plane на данном устройстве. Ведь если нет альтернативы, то чуда не будет.
Разберем подробнее возможные параметры конфигурации линка.
Last resort — говорит о том, что этот линк не надо использовать, пока есть альтернативы. Обычно таким флажком помечают дорогие каналы — для уверенности, что они будут потреблять «деньги» только в крайнем случае.
-
Interval for processing errors and utilization rate (sec) — время для сбора статистики до того как решение о блокировке линка будет принято. Позволяет сгладить пики нагрузки.
Enable error monitoring — в стандартной линейке устройств Kaspersky SD‑WAN параметр не применим, так как «ошибки» не доходят до этого уровня. Всегда ноль.
Critical utilization level (%) — позволяет контролировать загрузку канала. Довольно спорный параметр, так как работать он будет только если правильно задана скорость на sdwan интерфейсе. т. е. надо четко понимать, «а сколько это» 100% в Мб в секунду. Часто скорость — параметр довольно плавающий у большинства провайдеров, поэтому «правильная» его конфигурация задача не тривиальная.
-
Interval for processing latency, jitter, and packet loss (sec) — время для сбора статистики до того как решение будет принято. Позволяет сгладить пики нагрузки.
Critical latency level (ms) — задержка передачи. Считается каждый пакет с данными.
Critical jitter level (ms) — отклонение задержки на группе пакетов с данными.
Critical packet loss level (%) — потери пакетов. Не важно по какой причине — ошибки или перегрузка канала — это все в конечном итоге будет считаться как потери.
Таким образом, ключевым параметром, определяющим скорость переключения «плохого» линка является «Interval for processing». В нашем примере сбор информации о latency, jitter и packet loss происходит в течении 30 секунд. На протяжении этого времени, канал будет использоваться несмотря на «деградацию».
Но все так радужно. Все выглядит прекрасно, когда сеть работает в штатном режиме, но может выйти из-под контроля в случае нестабильных сетевых соединений. Далее расскажу про дополнительный механизм борьбы с такими ситуациями.
Dampening
Функция Dampening позволяет исключить нестабильные линки, состояние которых меняется слишком часто. Особенно актуально для борьбы с атаками типа «отказ в обслуживании», при «мигающих» провайдерах и неправильно настроенных SLA.
Классический пример, когда SLA был настроен неправильно:
SLA линка «пробит» из за большого объёма трафика.
Происходит переключение на другой линк с «хорошим SLA».
Из-за нагрузки линк с «хорошим SLA» становится линком с «плохим SLA».
Первоначальный линк «освобождается» и становится «хорошим».
Происходит обратное переключение на этот линк.
И по-кругу на п.1.
Под DoS атаками ситуация может быть похожей, так как сеть очень сильно деградирует.
Именно для борьбы с такими ситуациями необходимо включать механизм dampening или другими словами «наказания» слишком часто переключающихся линков.
Maximum suppress time (ms) — время на которое блокируется линк в случае мигания. По умолчанию 10 минут.
Penalty — балл наказания за единичное переключение.
Suppress threshold — сколько баллов считать критическими для отключения линка
Update interval (ms) — окно (интервал) на котором считаются переключения.
В результате, если за 2 минуты (120000мс) будет 3 переключения, то линк блокируется на 10 минут (600000мс). Таким образом может «поштормить» 2 минуты, но потом на 10 минут связь наладится, возможно, будет «стабильно плохая», но без лишних «прыжков». Будет время разобраться с провайдерами и найти «хорошего».
Если нет альтернатив (все линки заблокированны) будет использоваться первый линк даже с «пробитым» SLA. Т. е. полностью связь не блокируется.
По умолчанию механизм выключен. Включается на уровне каждого линка или на уровне всего контролера с его перезагрузкой. В версии 2.4 интерфейс управления большим числом линков не очень продуманный и удобный. Для комфортной работы с «тысячами» линков мы используем API интеграцию, но это, возможно, тема отдельной статьи.
Note: Механизм работает только на уровне линков, поэтому, не выключает весь порт sdwan на уровне трекинга. Эфект «наказания» на уровне трекинга достгается тюнингом параметров UP и DOWN.
Port Down
Самый простой случай, не достойный внимания. Если порт выключается, или другими словами уходит в «даун», переключение осуществляется мгновенно, разумеется если есть доступные альтернативы. С такой ситуацией справляются большинство решений, и SD-WAN не исключение.
Выводы
Таким образом решение Kaspersky SD-WAN может довольно хорошо бороться с нестабильной сетью так, что в большинстве случаев пользователи даже не замечают проблемы. Переключения происходят за секунды, и даже особо сложные случаи, с проблемами связи между разными площадками, решаются без необходимости сложного траблшутинга. Конечно, когда все работает «само», то возникают две проблемы:
легко расслабиться и упустить момент, когда сеть потеряла запас прочности и новая проблема не будет иметь обходного пути. Мониторинг частично решает задачу.
проблемы, не решенные автоматикой довольно сложно траблшутить не имея опыта работы с технологией.
Но это все решается хорошим сервисом и квалифицированными кадрами.
Отдельно отмечу уровни управления и мониторинга. Они полностью зависят от трекинга и к ним не применимы другие механизмы «переключения».
Note: Данная статья основана на версии Kaspersky SD-WAN 2.4. Механизмы постоянно совершенствуются отвечая новым «вызовам».