SD-WAN BI.ZONE часть 5 — заключительная часть, обсуждаем всё что не было рассмотрено ранее. Это BGP, Traffic Engineering, балансировка, FW и баги.
Статья будет короткая, так как чуть уже подустал от написания про SD-WAN BI.ZONE, но до логического конца довести нужно. Поэтому начнём.
BGP
Весь SD-WAN представляет собой одну автономную систему. Номер её, приватный конечно, назначается в общих настройках. Ещё один пункт общих настроек, это 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.
Единственное про что тут надо сказать, галка Service route. Она запихивает в BGP сервисные маршруты. Что это за маршруты? Где их посмотреть? Вкладка Overlay на CPE.
Тогда внизу страницы отобразятся сервисные маршруты.
Маршруты с Route type BGP и так прилетят, сами по себе или в составе более крупных. Не интересует. Маршруты Local можно запихивать в BGP с помощью галок Connected/Static. Тоже не интересует. Итого, сервисные по сути дела это маршруты с Route type:
- 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), здесь понятнее, для каждого дата-туннеля возможно посмотреть его соответствие в процентах по отношению к заданному качеству.
Что ещё про трафик? Наверно интересно будет прочесть как настроить централизованный выход в интернет через Hub. И там же рядом полезная инфа про алгоритм выбора лучшего пути в разрезе SD-WAN.
Балансировка
У нас есть 2 WAN канала (может быть и 1 на какой-то площадке, но максимум всё равно только 2). И мы можем балансировать по ним трафик, а можем не балансировать. В чём тут дело?
Если мы трафик балансируем, то таким образом расширяем суммарную пропускную способность. Но при этом портим характеристики обоих каналов (и среднюю задержку, и потери, и джиттер). Понятно что пустой канал всегда лучше, чем загруженный. При этом внутри самого SD-WAN, напомню, QoS'а у нас нет. И при значительной загрузке обоих каналов голосовой трафик может страдать.
Другой подход — не балансировать. Тогда трафик в основном канале может страдать. Зато TE (при верной настройке) отберёт весь голосовой трафик и видео во второй, свободный канал.
Что выбрать? Зависит от соотношения объёмов трафика к ширине каналов. Когда соотношение низкое (трафика почти нет или широченные каналы), можно выбрать любой вариант. Соотношение среднее, но трафик с запасом пролезает в один из каналов. Тогда этот канал основным и второй вариант. Соотношение высокое, весь трафик только в один из каналов никак не помещается, тогда только первый вариант (и думать над расширением каналов).
Включение или отключение балансировки производится в настройках CPE, вкладка Overlay. Для старта балансировки нужно проскролить вниз до раздела Data Tunnels, выставить одинаковое значение в поле Priority.
При исходных настройках трафик не балансируется между всеми имеющимися WAN-каналами, а проходит через один.
Имя порта для Data Tunnels на всех CPEs одинаково, wgd5500 для WAN каналов, wgra5501 для RA (почитать подробнее здесь и здесь).
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 нужен только для каких-то совсем микро-площадок, не имеющих других средств фильтрации трафика. На обычных площадках он больше мешает, чем помогает.
Баги
Было отловлено и исправлено огромное количество багов.
Циклическая перезагрузка CPE
Устройство работает нормально, при попытке перезагрузить уходит в циклический ребут. По логам на СРЕ видно, что при инициализации не был обнаружен MAC на интерфейсе 4 (оптический интерфейс). MAC этот аппаратный и должен присутствовать в любом случае. Поэтому на интерфейс невозможно применить конфигурацию и дальнейшая загрузка остановлена. Затем устройство автоматически ребутится. И по кругу.
Ошибка возникает периодически (где-то 1 раз на 3 перезагрузки), только на CPEs 300 серии. Сначала думали на несовместимость SFP модулей. Перепробовали все модули какие только нашли. Затем выяснили что именно баг прошивки. Почему проявляется только на устройствах 300 серии? Неизвестно. Вендор ушёл искать решение.
Workaround. Отказаться от использования оптических портов 3 и 4. Вместо них используются медные 5 и 6.
Нельзя добавить 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 работают при этом корректно.
Разработчики достаточно оперативно запилили заплату (недели за две). И всё заработало как надо.
Потери для UDP трафика
Наблюдались значительные потери UDP трафика (до 10-20%) при передаче по WAN каналам на части CPEs. Сразу возникла проблема с войсовыми шлюзами и голосовым трафиком. Вендор очень быстро выпустил очередной апдейт (менее недели), проблема была решена.
Некорректное отображение загрузки трафика в главной дашборде
Виден большой объем трафика при отсутствии реальной нагрузки в системе. То есть SD-WAN даже не подключен к проду, а в дашборде суммарный трафик допустим 300Mbit. Вендор ответил следующее:
Суммируется трафик in + out на всех физических интерфейсах всех СРЕ. При учете данного трафика принимаются во внимание все пакеты, включая широковещательные. В данном случае мы следовали принципу, что в общем дашборде хотим показать вообще весь возможный трафик, включая тот, что не предназначен для СРЕ.
Workaround. Использовать per-CPE Dashboard, который снимает статистику с логических интерфейсов (то есть без учета широковещательных пакетов).
Странное поведение BGP на CPE
Если на CPE выключить BGP соседство, то со стороны LAN, на устройстве-соседе постоянно фиксируется сообщений о падении BGP сессии c CPE. В результате лог забивается такими сообщениями.
Workaround. Выключать соседство и со стороны устройства в LAN тоже.
Не показывается трассировка через SD-WAN
Причём через встроенный в CPEs FW такой трафик разрешён для прохождения. Внутри SD-WAN запросы пропадают, а при выходе через CPE назначения снова появляются. Считать ли это за баг? Не знаю даже. Не очень удобная шутка, когда нужно траблшутить прохождение пакетов через SD-WAN.
Скорее всего было ещё что-то, хотя и этого немало. Подзабыл, сорян, и уже не вспомню.
Итоги
Подведём итоги. Продукт SD-WAN BI.ZONE очень простой. Не надо думать, что простота это только хорошо (или только плохо). Это и хорошо, и плохо. Все пять статей пытался данную мысль раскрывать в деталях как мог. Тем не менее, продукт полностью рабочий и задачу свою выполняет. А что ещё нужно? Ведь это главное.
Решение развивается. И со временем разработчики добавят все необходимые фичи. А возможно и больше. Вердикт:
SD-WAN BI.ZONE? — Надо брать!
Заключение
Очень хотел познакомиться с SD-WAN. Стремился к этому. Нашёл компанию, где SD-WAN внедрялся (не был уже развёрнут, а именно внедрялся). Поучаствовал в проекте по развёртыванию, всё сам посмотрел, всё пощупал руками. Видел все нюансы, баги и проблемы. Как они возникали, как решались. Ну что сказать, доволен как конь. 🙂 Возможно в дальнейшем повезёт посмотреть вживую SD-WAN другой фирмы. Увидим, а пока цикл статей про SD-WAN BI.ZONE завершён.
SD-WAN — технологический феномен, который неизбежно придёт на смену любым другим решениям для связи офисов.
Приглашаю поделиться мнением в Tелеграм канал