SD-WAN BI.ZONE часть 5 — заключительная часть, обсуждаем всё что не было рассмотрено ранее. Это BGP, Traffic Engineering, балансировка, FW и баги.
Статья будет короткая, так как чуть уже подустал от написания про SD-WAN BI.ZONE, но до логического конца довести нужно. Поэтому начнём.
Документация по SD-WAN BI.ZONE недоступна для публики, только для заказчиков. Копии этой документации появляются/исчезают на разных источниках. У меня, к сожалению, нет возможности постоянно отслеживать. Поэтому не привожу ссылки на документацию. Хотя там есть достаточно интересные вещи. Если хотите прочитать, ищите пожалуйста самостоятельно.
Во избежание путаницы, буду использовать термин LAN, как для обозначения всех сетевых устройств внутри какой-то площадки, то есть для всей площадки, так и для обозначения локальных интерфейсов CPE на данной площадке.
BGP
Здесь поговорим про BGP естественно и более подробно про маршрутизацию внутри SD-WAN. Поскольку тесно связанные вещи, тут самое место для этого рассказа.
Весь SD-WAN представляет собой одну автономную систему. Номер её, приватный конечно, назначается в общих настройках. Это настройки проекта (Project). По сути новый проект и есть новый инстанс SD-WAN.
Внутри SD-WAN маршруты BGP не используются напрямую, только передаются между CPEs. То есть на каждом CPE есть идентичная BGP global RIB. Сама BGP маршрутизация работает при этом на границе CPE-LAN, когда есть активные BGP соседи. Непосредственно маршрутизация между CPEs осуществляется за счёт Сервисных маршрутов. Что это и как завязано на BGP далее.
Ещё один пункт общих настроек, это BGP Polices. Здесь можно добавить необходимое количество политик, чтобы потом эти политики применять на CPEs.
Нажимая кнопку Add, попадаешь в BGP policy editor
После выбора матчера появятся поля для ввода соответствующих данных.
Настройки BGP для CPE
Процесс BGP запускается на CPE, если у CPE есть хоть одно соседство в состоянии enable. Заходим в настройки CPE, настроек для BGP не так много.
Добавляем нового соседа BGP - Neighbors - Add, там сначала вкладка General.
Отдельно нужно сказать про временные интервалы, Keep Alive минимальное значение 1 сек, Hold timer 3 сек. Поэтому если сосед из локальной сети отвалится, то в течение трех секунд никаких действий со стороны SD-WAN предпринято не будет. Это не фатально, но трехсекундный провал в трафике.
Далее, на вкладке Policy, если нужно для этого соседа, фильтруем отправляемые и получаемые маршруты. Политики добавляются по порядку сверху вниз кнопкой Add policy и их естественно может быть много.
Продолжаем пока не создадим всех соседей.
Это была вкладка BGP - Neighbors, рассмотрим вкладку BGP - Settings.
Redistribute to BGP передаёт маршруты из SD-WAN соседям в LAN, а Redistribute from BGP с соседей в SD-WAN, точнее в Сервисные маршруты.
Наверное понятно, что галка Redistribute from BGP должна всегда стоять, если на CPE есть активные BGP соседи. Иначе SD-WAN никогда не узнает о префиксах площадки, кроме префиксов настроенных непосредственно на LAN интерфейсах CPE. Обращаю ещё внимание, что настройки редистрибуции индивидуальны для каждого CPE. Что именно отдавать соседям в LAN возможно настроить отдельно на каждом CPE. Это важно.
BGP и Сервисные маршруты
Подробнее про галку Service route. Она запихивает BGP соседям Сервисные маршруты. Что это за маршруты? Где их посмотреть? Вкладка Overlay на CPE.
Тогда внизу страницы отобразятся Сервисные маршруты.
Сервисные маршруты — маршруты, на которых и работает передача трафика в SD-WAN
Ещё раз, поскольку важно, Сервисные маршруты существуют сами по себе, отдельно и работают внутри SD-WAN. А BGP маршруты сами по себе, тоже отдельно и работают на границе CPE-LAN, хотя и транслируются внутри SD-WAN между CPEs (BGP global RIB). Обмен между BGP и Сервисными маршрутами осуществляется за счёт редистрибуции. Должно быть примерно понятно.
Типы Сервисных маршрутов
- BGP, получены за счёт редистрибуции. Если на большинстве CPEs задействован BGP, то самый распространённый тип;
- LOCAL, получены из локальных маршрутов на этом CPE. В основном это линковая сетка между CPE и LAN;
- REMOTE, получены с других CPEs. Допустим на самом CPE маршрут в Сервисных как LOCAL, на другие CPEs он прилетит как REMOTE;
- DIA, получены из доступа в интернет на этом CPE. С DIA пока не разбирался, возможно позже. Маршруты DIA появляются автоматом на всех CPE, даже если у них физически нет выхода в интернет;
- RA, получены из маршрутов удалённого доступа на этом CPE. Если на CPE настроен удалённый доступ для сотрудников, маршруты оттуда прилетят в Сервисные. Не используем, не видел как это бывает.
Что будет, если Сервисные маршруты отправить в BGP (поставить галку)? Тогда на соседей в LAN (на площадке) всё это вывалится. При этом, Сервисные маршруты с Route type BGP и так прилетят (непосредственно через BGP), сами по себе или в составе более крупных. По сути это будет дубль уже полученных по BGP маршрутов. Не интересует. Маршруты LOCAL можно запихивать в BGP с помощью галок Connected/Static. Тоже не интересует. Получается редистрибуция конкретно Сервисных маршрутов это:
- REMOTE;
- DIA;
- RA.
В каком сценарии востребовано подпихивать Сервисные маршруты в BGP? Наверное найдётся какой-то, так сходу сложно сказать. Найду если, расскажу. На самом деле, уже нашёл такую ситуацию и рассказал о ней в шестой части.
Проверка BGP
Во-первых, можно посмотреть в настройках CPE на вкладке BGP - Neighbors состояние соседства для каждого соседа (IDLE/ACTIVE/ESTABLISHED). Во-вторых, посмотреть в настройках CPE на вкладке Diagnostics. Там много стандартных инструментов вроде пинга, арпов, трассировки и так далее. Конкретно для BGP:
- BGP global (общие сведения);
- BGP global RIB;
- BGP neighbors.
Плюсом там же есть логи CPE (доступны для скачивания).
Traffic Engineering
В первой части, когда ещё не видел настройки SD-WAN вживую, написал в предполагаемом плане развёртывания: "Параллельно пилим политику". Это как раз было про TE. Оказалось пилить тут нечего. Всё до смешного просто. Есть пункт меню в общих настройках Traffic policy, там на вкладке Global application policy можно настроить до 7 вариантов качества для WAN каналов (плюс дефолтный). Выставим для нужного количества уровней качества пороговые значения потерь, задержки и джиттера.
Затем вкладка ACLs, настраиваем правила отбора трафика. У нас изначально всё адресное пространство было разбито правильно. На три крупных области: отдельная область для VoIP и видео-трафика на всех площадках, отдельная для серверов и отдельная для пользователей.
Теперь закладка Traffic matchers. Настраиваем матчеры, сопоставляя каждый матчер с номером политики качества канала. И затем привязываем к ACL отбора трафика.
Следующее, настраиваем временные интервалы для проверки качества каналов на вкладке Monitoring templates.
Последнее тут, идём в настройки CPE на вкладку SLA, применяем матчер и темплейт временных интервалов (у нас они одинаково названы). Как видно матчер один для обоих каналов, а темплейт можно поставить свой для каждого канала (что логично). Повторяем для остальных CPEs.
Конечно же вы можете создать куда больше правил отбора, матчеров, темплейтов. Только вот смысл от этого не меняется.
Мониторинг
Настроили TE, а как и где его мониторить? В настройках CPE вкладка Overlay - Tunnels (health), тут рисуется график (пока не понял как его интерпретировать, поэтому картинки не будет). И Overlay - Peers (health), здесь понятнее, для каждого дата-туннеля возможно посмотреть его соответствие в процентах по отношению к заданному качеству.
Приоритизация хабов
Хабам необходимо Full Mesh соединение. Это обязательная часть работы SD-WAN. Споки пытаются выстроить соединение ко всем имеющимся хабам. А есть какой-то приоритет хаба для споков?
Есть. Во-первых, действительно для каждого CPE можно назначить приоритет в явном виде. Между хабами, насколько поняли, этот приоритет не используется. Между споками так же, споки в текущей архитектуре не строят между собой туннели. Зато приоритет влияет на выбор хаба, через который спок отправит трафик. Состояние соединений для любого CPE, неважно хаб он или спок, можно увидеть на вкладке Overlay - Peers (health) (картинка выше).
Допустим есть спок, он установил туннели до хабов, до которых смог достучаться. Далее при выборе туннеля работает TA. Если туннелей с нужным качеством получилось несколько, работает приоритет хаба. Чем приоритет меньше, тем хаб предпочтительней.
По умолчанию для споков приоритет всегда 0, понятно почему, а для каждого нового хаба (при его заведении) на 10 больше, чем для предыдущего, ранее созданного. Что будет если руками для двух (или более) хабов поставить одинаковый приоритет и от какого-то спока туннели к этим хабам отберутся TA для передачи трафика? Не знаю. Возможности разламывания продакшена весьма ограничены. По идее трафик от спока в таком случае должен балансироваться между хабами.
Во-вторых, это выделение части хабов и споков в регион. Логика работы региона в решении BI.ZONE заключается в следующем: хабы региона всегда приоритетнее для споков региона, чем другие хабы. Внутри региона и вне региона между хабами так же используется приоритет.
Балансировка
У нас есть 2 WAN канала (может быть и 1 на какой-то площадке, но максимум всё равно только 2). И мы можем балансировать по ним трафик, а можем не балансировать. В чём тут дело?
Если мы трафик балансируем, то таким образом расширяем суммарную пропускную способность. Но при этом портим характеристики обоих каналов (и среднюю задержку, и потери, и джиттер). Понятно что пустой канал всегда лучше, чем загруженный. При этом внутри самого SD-WAN, напомню, QoS'а у нас нет. И при значительной загрузке обоих каналов голосовой трафик может страдать.
Другой подход — не балансировать. Тогда может страдать трафик в основном канале, где идёт передача. Зато TE (при верной настройке) отберёт весь голосовой трафик и видео во второй, свободный канал.
Что выбрать? Зависит от соотношения объёмов трафика к ширине каналов. Когда соотношение низкое (трафика почти нет или широченные каналы), можно выбрать любой вариант. Соотношение среднее, но трафик с запасом пролезает в один из каналов. Тогда этот канал основным и второй вариант. Соотношение высокое, весь трафик только в один из каналов никак не помещается, тогда только первый вариант (и думать над расширением каналов).
Включение или отключение балансировки производится в настройках CPE, вкладка Overlay. Для старта балансировки нужно проскролить вниз до раздела Data Tunnels, выставить одинаковое значение в поле Priority.
При исходных настройках трафик не балансируется между всеми имеющимися WAN-каналами, а проходит через один.
Имя порта для Data Tunnels на всех CPEs одинаково, wgd5500 для WAN каналов, wgra5501 для RA.
Балансировка строится на сессиях, не на пакетах, поэтому абсолютно равномерного распределения трафика достичь невозможно. С сессиями очевидно так не получится.
Ещё здесь есть момент, балансировка хорошо работает при равном значении параметра Bandwidth в настройках для обоих WAN каналов (скрины и описание данного параметра есть в четвёртой части). Даже если каналы по ширине не самом деле неравные. Если же по Bandwidth один канал WAN значительно шире другого, то трафик будет в приоритете запихиваться в широкий канал и балансировка сломается.
Firewall
Достаточно простой, быстренько рассмотрим. В общих настройках есть группа закладок Security Orchestrator. Она содержит следующие закладки:
- VNFs;
- Catalogs;
- Analytics;
- Firewall Templates.
Все эти закладки относятся к FW. На закладке VNFs список FW для всех CPEs (когда Бизон выпустит ещё VNFs, они появятся в этом разделе). Можно поправить настройки конкретного FW либо отсюда, либо из настроек CPE, закладка тоже VNFs.
Название FW это имя CPE плюс модель CPE
Закладка Catalogs содержит следующие типы записей (на картинке):
Уже есть предустановленные сервисы. Можно добавлять свои. Остальные типы записей понятны.
На закладке Analytics список открытых соединений с возможностью стандартного поиска по IP сурса/назначения, порту. Картинку приводит не буду. Уверен, ты видел подобное много раз.
Наконец, на закладке Firewall Templates можно создать несколько шаблонов. Затем в каждый шаблон забивается свой список правил. И наконец выбранный шаблон применяется на CPE для FW. По умолчанию на CPE выбран предустановленный темплейт Default Rule Group. Конечно же не тянет на средство централизации для FW. Хотя лучше, чем ничего.
Если провалиться в настройки конкретного экземпляра FW, то там следующее:
Остальные вкладки понятны, а из вкладки Zones понятно, что наш FW — разновидность ZBF (и естественно Stateful). Посмотрим на вкладку System. Она пригодится в различных сценариях траблшутинга.
В общем и целом такой FW нужен только для каких-то совсем микро-площадок, не имеющих других средств фильтрации трафика. На обычных площадках он больше мешает, чем помогает.
Сейчас BI.ZONE усиленно пилит именно FW, чуть подзабивая на остальные фичи. Дабы оправдать слово Secure, которое они лепят везде к своему SD-WAN. Насколько у них получится.., не знаю. Что-то подобное NGFW из него вряд ли получится.
Баги
Было отловлено и исправлено огромное количество багов.
Циклическая перезагрузка CPE
Устройство работает нормально, при попытке перезагрузить уходит в циклический ребут. По логам на СРЕ видно, что при инициализации не был обнаружен MAC на интерфейсе 4 (оптический интерфейс). MAC этот аппаратный и должен присутствовать в любом случае. Поэтому на интерфейс невозможно применить конфигурацию и дальнейшая загрузка остановлена. Затем устройство автоматически ребутится. И по кругу.
Ошибка возникает периодически (где-то 1 раз на 3 перезагрузки), только на CPEs 300 серии. Сначала думали на несовместимость SFP модулей. Перепробовали все модули какие только нашли. Затем выяснили что именно баг прошивки. Почему проявляется только на устройствах 300 серии? Неизвестно. Вендор ушёл искать решение.
Workaround. Отказаться от использования оптических портов 3 и 4. Вместо них используются медные 5 и 6.
Не работают SFP
Как известно, одномодовые SFP потребляют чуть больше питания при работе, чем многомодовые. Поэтому при вставлении в CPE 4 (и более) одномодовых модулей, видимо дешевая плата питания в CPE не справляется. И не взлетает. При замене на стандартные многомодовые SNR всё шикардос.
Нельзя добавить BGP фильтр по 32 маске
Разработчики сообщили следующее:
К сожалению, использование фильтра ge 32 le 32 пока недоступно, это известный баг веб-интерфейса.
(Bug 3170). Исправление бага намечено на релиз 1.5.0, выход релиза планируется в октябре 2023.
Workaround. Использовать ge 31 le 32, при этом:
x.x.x.x/32 ge 31 le 32 - не работает x.x.x.x/31 ge 31 le 32 - работает
Не удаляются маршруты
При тестовом включении в продакшен нашли весьма серьёзный баг. При отвале CPE маршруты, которые оно получает от соседей из локальной сети по BGP, не исчезают из глобальной таблицы BGP SD-WAN. Хотя из списка сервисных пропадают практически моментально. И получается что на других площадках эти маршруты висят в таблице маршрутизации как действующие. Трафик уходит в никуда. А при перезагрузке CPE (священный ребут), эти же маршруты задваиваются. 🙂 Так что ребут не всегда лекарство. Сами протоколы BGP/BCMP работают при этом корректно.
Разработчики достаточно оперативно запилили заплату (недели за две). И всё заработало как надо.
Глюки BGP
Проявляются только в специфических условиях, при определённой конфигурации оборудования и настройках. Подробнее. Поскольку VRRP не реализован, то на LAN интерфейсах двух CPE не может быть настроена одна и та же сеть. При попытке такой настройки возникает ошибка.
Поэтому для двух CPE на площадке мы использовали разные префиксы на LAN интерфейсах. Это линковые сети для связи ядра площадки с CPEs. Напомню, что такой префикс обязательно попадёт в Сервисные маршруты. На своём CPE он будет присутствовать как LOCAL, а на другие прилетит как REMOTE. Значит два CPE обменяются маршрутной информацией о своих линковых сетях.
Далее, эти же линковые сети мы анонсировали с ядра площадки, так вышло. Получается внутри площадки на CPE линковая сеть соседнего CPE прилетает по BGP с ядра и прилетает через Сервисные маршруты. Казалось бы проблемы никакой, но именно тут глюк. У цпешек "съехали мозги", пошёл постоянный перерасчёт маршрутов. Линковая сеть соседнего CPE флапала в Сервисных маршрутах с загрузкой CPU устройства в 100%.
Workaround. Не анонсировать в такой конфигурации линковые сети с ядра.
Невозможность работы двух нод на площадке
Проблема связана с предыдущей. Если просто настроить два CPE на площадке и сделать для них анонс одних и тех же сетей по BGP, загрузка их CPU уедет на 100% и трафик через них перестанет ходить. SD-WAN некорректно понимает наличие одинаковых маршрутов, с одинаковой метрикой, в сторону площадки сразу на двух CPE. Начинается постоянный перерасчёт маршрутов.
Workaround. Выставить для этих двух CPE разный Local preference в сторону BGP соседей на площадке.
Странное поведение BGP на CPE
Если на CPE выключить BGP соседство, то со стороны LAN, на устройстве-соседе постоянно фиксируется сообщений о падении BGP сессии c CPE. В результате лог забивается такими сообщениями.
1174069: Mar 28 08:52:50: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.1.1 IPv4 Unicast topology base removed from session Peer closed the session 1174070: Mar 28 08:53:04: %BGP-5-NBR_RESET: Neighbor 192.168.1.1 active reset (Peer closed the session)
Workaround. Выключать соседство и со стороны устройства в LAN тоже. Либо прописать на соседе в LAN команду:
(config-router)#neighbor 192.168.1.1 transport connection-mode passive
Потери для UDP трафика
Наблюдались значительные потери UDP трафика (до 10-20%) при передаче по WAN каналам на части CPEs. Сразу возникла проблема с войсовыми шлюзами и голосовым трафиком. Вендор очень быстро выпустил очередной апдейт (менее недели), проблема была решена.
Некорректное отображение загрузки трафика в главной дашборде
Виден большой объем трафика при отсутствии реальной нагрузки в системе. То есть SD-WAN даже не подключен к проду, а в дашборде суммарный трафик допустим 300Mbit. Вендор ответил следующее:
Суммируется трафик in + out на всех физических интерфейсах всех СРЕ. При учете данного трафика принимаются во внимание все пакеты, включая широковещательные. В данном случае мы следовали принципу, что в общем дашборде хотим показать вообще весь возможный трафик, включая тот, что не предназначен для СРЕ.
Workaround. Использовать per-CPE Dashboard, который снимает статистику с логических интерфейсов (то есть без учета широковещательных пакетов).
Не показывается трассировка через SD-WAN
Причём через встроенный в CPEs FW такой трафик разрешён для прохождения. Внутри SD-WAN запросы пропадают, а при выходе через CPE назначения снова появляются. Считать ли это за баг? Не знаю даже. Не очень удобная шутка, когда нужно траблшутить прохождение пакетов через SD-WAN.
Нет нормального лога
То есть CPE чего-то там пишет в консоль в своём формате. Что это.., как интерпретировать.., непонятно. В версии 1.5.1 будет экспорт логов в формате Syslog. В частности в SIEM. Упростит работу, отдела Кибербезопасности в том числе.
Понижение версии контроллера не предусмотрено
То есть если успешно обновить контроллер (CSP) на новую версию, обратного хода по сути нет. Откатиться можно только когда обновление не установилось.
И процедуры штатного бэкапа CSP не существует. Бэкапиться просто созданием архива VM CSP нельзя. Почему? Потому что на всех устройствах (CSP/CPEs) присутствует версионность изменений. И если откатиться на такой архив, то версия базы данных CSP будет старее, чем на CPEs. Соответственно, после отката в случае внесения изменений на CSP, CPEs не поймут этих изменений, так как для них изменения с такой версией уже существуют и были применены.
Разработчики говорят, что разрабатывают средство штатного бэкапа. И пока предлагают пользоваться кластером CSPs для отказоустойчивости. Кластер у SD-WAN BI.ZONE состоит из 4 нод: активная, резервная, арбитр, нода сбора логов.
А когда кластера нет, в случае поломки CSP, придётся сильно-сильно шаманить ручками. При этом пользовательский трафик ходить через SD-WAN не перестанет. Как говорил уже в предыдущих частях, CSP непосредственно не участвует в решении о прохождении трафика. Он только устанавливает изменения/политики на CPEs и мониторит их. Проверили данный момент в продакшене. При обновлении CSP на новую версию 1.5.1 (сам CSP на время обновления был недоступен), пользовательский трафик нормально ходил через SD-WAN.
Понижение версии CPE довольно сложное
Если с контроллера обновить CPE на новую версию, откатить обратно можно только руками с флешки. На самом контроллере такая возможность не предусмотрена. При таком откате придётся проводить процедуру ZTP повторно.
Скорее всего было ещё что-то, хотя и этого немало. Подзабыл, сорян, и уже не вспомню.
Итоги
Подведём итоги. Продукт SD-WAN BI.ZONE очень простой. Не надо думать, что простота это только хорошо (или только плохо). Это и хорошо, и плохо. Все пять статей пытался данную мысль раскрывать в деталях как мог. Тем не менее, продукт полностью рабочий и задачу свою выполняет. А что ещё нужно? Ведь это главное.
Решение развивается. И со временем разработчики добавят все необходимые фичи. А возможно и больше. Вердикт:
SD-WAN BI.ZONE? — Надо брать!
Заключение
Очень хотел познакомиться с SD-WAN. Стремился к этому. Нашёл компанию, где SD-WAN внедрялся (не был уже развёрнут, а именно внедрялся). Поучаствовал в проекте по развёртыванию, всё сам посмотрел, всё пощупал руками. Видел все нюансы, баги и проблемы. Как они возникали, как решались. Ну что сказать, доволен как конь. 🙂 Возможно в дальнейшем повезёт посмотреть вживую SD-WAN другой фирмы. Увидим, а пока цикл статей про SD-WAN BI.ZONE завершён.
SD-WAN — технологический феномен, который неизбежно придёт на смену любым другим решениям для связи офисов.
Приглашаю поделиться мнением в Tелеграм канал