SD-WAN BI.ZONE часть 6 — экстра-часть, обсуждаем элементы дизайна и возникающие проблемы при подключении мелких площадок.
Не думал, не гадал он, никак не ожидал он, такого вот конца что будет ещё одна часть. Заодно тут вскроется пара вопросов, на которые не нашлось ответа ранее. Прочтение предыдущих частей обязательно, иначе статья покажется набором слов.
Напомню, у нас всего 2 WAN на CPE, больше пока нету, архитектурное ограничение BI.ZONE. Нет VRRP, значит нельзя задействовать 2 CPE в параллель. При этом необходимо, чтобы между хабами был Full Mesh. Всеми хабами без исключения. А будет работать без Full Mesh? Да кто же знает, не документировано.
Отсюда и возникает много интересных моментов, про которые хотел поговорить. Начнём с DIA.
DIA
DIA (Direct Internet Access) заключается в следующем, на каждом CPE выход в интернет из LAN реализован сразу и не требует начальной настройки. То есть, если у нас есть WAN канал, на него автоматически вешается дефолтный маршрут. Самое прикольное, что DIA создаётся даже когда WAN каналы MPLS и не имеют выхода в интернет. Автоматическое действие, не разбирается что там за WAN канал.
Отключить DIA в явном виде, в текущей версии невозможно. Поменять приоритет маршрутов DIA тоже нельзя. Ответ вендора:
Возможность изменения приоритета маршрутов DIA, VRRP, запланированы в версии 1.6 (не ранее осени 2024)
То что сказал вендор, смело "множьте на 2". И "не ранее осени 2024" может легко стать не ранее 2025 или даже 2026 года.
Единственный вариант уйти от DIA, это распространить дефолтный маршрут с площадки в SD-WAN через BGP. Из-за редистрибуции Redistribution from BGP маршрут попадёт в Сервисные и подавит собой маршруты DIA.
Причём произойдёт это абсолютно на всех площадках, где DIA работал до этого.
Как видно, для DIA по умолчанию метрика 100 и 101, а для BGP 20, значит более приоритетна.
Позволю себе напомнить, между различными протоколами действует Административная дистанция (AD), а Metric — понятие связанное с выбором маршрута внутри конкретного протокола. И тут есть некоторая путаница, которую привносит сама циска (а BI.ZONE, как мы видим, активно пользуется):
#ip route 192.168.1.0 255.255.255.0 192.168.2.1 ? <1-255> Distance metric for this route
Таким образом, с помощью внедрённого маршрута по умолчанию реализуется централизованный выход в интернет со всех мелких площадок. Через площадку, где анонсируется дефолт по BGP. Далее на этой площадке можно поставить NGFW и реализовать единые правила выхода в интернет. Удобно и снижает техническую работу, представьте что мелких площадок 40 и на каждой нужно что-то ограничить по выходу в интернет. Можно конечно в SD-WAN написать соответствующий шаблон для встроенного FW (доступно с версии 1.4.0), только встроенный FW никогда не приблизится по возможностям и удобству к NGFW.
Теперь поговорим о текущей схеме на момент перед подключением мелких площадок.
Текущая схема
В первой части рассказывал, что у крупных/средних площадок есть 2 MPLS VPN (далее MPLS). Это не только в нашей фирме, стандартная практика. MPLS имеет гарантированные характеристики. Поэтому в первой итерации развёртывания SD-WAN, задействовали в качестве 2 WAN — 2 MPLS на крупных площадках. И делали эти CPEs хабами. Тут надо уточнить, что MPLS от одних и тех же провайдеров (ISP). Точнее всего от двух ISP, иначе хабы SD-WAN не имели бы связности между собой. А ранее данные MPLS использовались под DMVPN, а ещё ранее просто под VPN.
Далее, во второй итерации, подключили средние площадки. Там где был один MPLS и существовала техническая возможность, дотянули второй. Где не было оставили один. Сделали все данные CPEs споками.
Обмен маршрутами между площадкой и SD-WAN происходит по BGP, через CPE на этой площадке. Для всех площадок одинаково. Со стороны площадки фильтруем маршруты, отдаём только маршруты AS самой площадки. И на CPE с помощью редистрибуции запихиваем все эти маршруты в маршруты SD-WAN (Сервисные маршруты). В обратную сторону (с CPE на площадку) отдаём все маршруты из BGP global RIB. Через редистрибуцию тут ничего дополнительно не подпихиваем, хотя можем (подробнее в пятой части). На самом деле, на площадке у CPE несколько разных соседей и фильтры посложнее, но для простоты пусть будет так, как сказал.
Всё заработало, всё хорошо. Да, появлялись баги (как же без этого), они были устранены, опять же говорил о них в пятой части. Если здесь что-то будет непонятно, ту часть лучше прочитать.
MPLS VPN vs Internet
Остались мелкие площадки, на которых присутствует только услуга интернета. Они пашут сейчас на DMVPN, но понятно что и их надо подтягивать в целевую схему (SD-WAN). Тут сначала немношк поговорим почему в случае с BI.ZONE соединение через интернет, совсем плохо.
Хотя MPLS логическое соединение между точками A и B, физически оно проходит через узлы в точках A, (C, D, E, F, G..), B. На каждом узле работает шейпер/полисер, который формирует трафик. Именно за счёт этого достигается постоянство пропускных характеристик туннеля. Для интернета же, в отличие от MPLS, это единственный шейпер/полисер в точке входа/выхода трафика, всё. Поэтому надеяться здесь на какое-то постоянство не стоит. Даже если сейчас интернет соединение работает прям хорошо, никто не гарантирует, что так будет через месяц-два, полгода.
Таким образом, если хотим пользоваться дешёвыми интернет каналами, нужны встроенные в SD-WAN "улучшатели" качества соединения. Они есть, допустим, для решения SD-WAN Kaspersky. Это коррекция ошибок и зеркалирование трафика по разным каналам. Для решения BI.ZONE ничего подобного нету и не будет в видимой перспективе. Поэтому в случае ухудшения качества интернет соединения, работа по отказоустойчивости перекладывается на "надёжный" протокол TCP. При этом гарантированно всё начнёт "заикаться и кашлять". Для UDP и того хуже, особенно страдает IP-телефония.
Проблема мелких площадок
Почему бы везде не протянуть MPLS? Хорошая мысль, только где-то экономически невыгодно из-за совсем малого офиса. Где-то невыгодно из-за сильной удалённости, протяжка станет в космическую цену. А где-то технически невозможно (Крайний Север и так далее), там только CPE исключительно через LTE. Ну и другие причины. Одну проблему ранее обозначили:
В случае использования под WAN каналы интернет соединений, работа SD-WAN BI.ZONE полностью зависима от текущего состояния этих соединений.
Ничего поделать нельзя. Теперь посмотрим как же подключение мелких площадок в SD-WAN реализовать с технической стороны. Это было бы просто будь у CPE хотя бы 3 WAN канала. Добавили на все хабы ещё одно WAN подключение через интернет к имеющимся 2 MPLS и всё бы запустилось. Дальнейшие танцы исключительно специфика BI.ZONE. Думаю далее, по мере своего развития, SD-WAN как вид технического решения будет более менее стандартизован. И 4 WAN на CPE станет золотым стандартом. Моё мнение, поживём — увидим.
Техническая реализация
Как втащить в SD-WAN площадки только с интернетом в качестве WAN канала? Никак в текущей схеме. 🙂 Единственный вариант добавить ещё один специализированный HUB на одной из крупных площадок (далее Internet HUB, IHUB). Лучше два, по одному на разных площадках для отказоустойчивости. У IHUB один WAN подключён к MPLS, а второй к интернету. За счёт MPLS канала получается связность с остальными хабами. А через интернет устанавливается связность с интернет-площадками.
Рассмотрим CPE на интернет-площадке (Internet SPOKE, ISPOKE). ISPOKE является для площадки шлюзом по умолчанию, получает весь трафик с площадки. То есть все сети LAN площадки прописаны непосредственно на интерфейсах LAN ISPOKE. Тут нет BGP между площадкой и CPE. В этом главное отличие. На текущих CPEs больших/средних площадок на интерфейсах LAN прописаны линковые сети, для связи с площадкой. А маршруты самой площадки прилетают по BGP.
Так вот, на ISPOKE не будет BGP, он здесь не нужен, избыточен и технически его не реализовать (на площадке попросту нет оборудования, которое может выступить BGP соседом). Поэтому маршруты такой площадки сразу попадут в Сервисные маршруты SD-WAN. На ISPOKE они присутствуют как LOCAL, а на остальных как REMOTE. Однако эти маршруты не попадают в BGP global RIB на SD-WAN. Их там нет. А ведь, напомню, маршрутизация между SD-WAN и площадками в текущей схеме построена именно через BGP. Значит текущие площадки (MPLS площадки) не получат маршруты на новые интернетовские площадки. Вторая проблема, её решим далее.
Корпоративный трафик (трафик, для которого существуют Сервисные маршруты) с ISPOKE уходит на IHUB, затем на CPE конкретной площадки и там уже внутрь площадки. Весь остальной трафик с ISPOKE идёт в интернет. Можно либо сразу его выпускать с помощью DIA, либо централизованно как рассказал выше.
Маршрутизация
Как реализовать маршрутизацию? Много обсуждали, думали. Сначала была идея сделать IHUB чистым транзитом. Без подключения его к LAN площадки. То есть трафик с ISPOKE уходит на IHUB, далее на обычный хаб площадки назначения. В том числе и для площадки, где IHUB расположен. Не заработало, не взлетело. По причине сложной реализации прохождения трафика до DMVPN-only площадок. А так сама по себе красивая реализация.
Ещё была идея выделить интернет-площадки в отдельный проект, по сути в отдельный SD-WAN. И связать его с текущим SD-WAN и DMVPN через ядро площадок с IHUB. Реализация вроде бы простая, но когда BI.ZONE допилит ещё WAN каналы, слить два SD-WAN проекта воедино станет адской задачей. Отказались.
Итого, увидели принципиально единственный вариант по распространению трафика с IHUB:
- Цеплять IHUB к LAN сети на площадке.
Через BGP естественно, как уже сделано для существующих хабов. И тут тоже вылезло прям много-много костылей. Во-первых, куда его цеплять по BGP на площадке? К ядру, к NGFW, к BRs DMVPN или же ко всем сразу. Во-вторых, как распространить маршруты мелких площадок посредством SD-WAN на остальные площадки? В-третьих, как реализовать симметричное прохождение трафика от крупной площадки до мелкой и обратно?
Проблемы
Начинаем разбираться.
- Куда IHUB цеплять по BGP;
Избыток содей порождает слишком сложную схему, решили что соседства с BRs DMVPN вполне достаточно. Следующий вопрос:
- Как распространять маршруты мелких площадок на остальных площадках;
Сделать можно двумя путями. Первый, прописать статикой. Особенно хорошо получится, когда все префиксы с мелких площадок попадают в несколько крупных диапазонов. Эти диапазоны мы и прописываем на ядре крупной/средней площадки в сторону CPE.
Второй путь, отдать по BGP с CPEs. Но (!), маршруты мелких площадок присутствуют в Сервисных (на каждом CPE), а нужно отдать по BGP. Как их туда подпихнуть? Очевидно через редистрибуцию Сервисных маршрутов. На всех крупных/средних площадках (MPLS) придётся сделать следующее:
Вот как раз пример, зачем может потребоваться редистрибуция Сервисных маршрутов. Поскольку Сервисных маршрутов довольно много, то прилетит достаточно мусора, его хорошо бы отфильтровать.
- Кривое прохождение трафика.
И тут ещё один момент. Сначала хотели отдавать маршруты мелких площадок по BGP (указанным выше способом) только с IHUBs. Тогда получается занятная штука. Трафик площадки, где есть IHUB, ходит на мелкие площадки и обратно симметрично. А вот для остальных крупных/средних площадок (без IHUB) асимметрично. Трафик с ISPOKE мелкой площадки попадает сразу через SD-WAN на CPE площадки назначения. Почему? Потому что у него есть такой Сервисный маршрут. А вот в обратную сторону маршрут существует только через IHUB, которого находится на другой площадке. Трафик нырял в DMVPN, затем приходил на площадку с IHUB, оттуда в SD-WAN, на ISPOKE мелкой площадки и наконец внутрь её. Надеюсь не слишком сумбурно, рисовать картинку неохота, уж простите.
Список изменений
Проект активно дорабатывается, поэтому хорошо бы знать что и когда внедрялось. Список версий:
- 1.5.1 вышла в апреле 2024 г.
- 1.5.0, в личном кабинете появились мануалы по этой версии (на март 2024 г). Выпущена она не будет, останется сервисной.
- 1.4.0, 11 мая 2023 г.
- 1.3.1, 25 октября 2022 г.
- 1.3.0, 8 августа 2022 г.
Изменения прочитаете сами по ссылке, хочу обратить внимание, что между выпуском мажорных версий проходит примерно 9-10 месяцев. Основные изменения в версиях 1.4.0/1.5.1. В версии 1.4.0 внедрены шаблоны, в частности шаблоны для работы с FW.
Версия 1.5.1 несёт наибольшие изменения. Исправлены досадные баги предыдущих версий. Добавлена возможность выгружать события Syslog на внешний сервер (в SIEM в частности), развёртывание контроллера через графическую среду SCP Wizard. Значительно переработан графический интерфейс контроллера (может позже выложу изменения). Если раньше прошивка была своя под каждую железку, то теперь для всех устройств x86 единая прошивка, что конечно же ускорит дальнейшую разработку.
В первой части говорил, что все CPEs должны быть предварительно прошиты под конкретный проект. Иначе они не смогут аутентифицироваться на контроллере. В версии 1.5.1 появилась возможность самостоятельно накатывать на новую железку сертификат проекта. Для этого на контроллере теперь есть штатный инструмент. Похоже на ZTP, так же генерируется и копируется ссылка. Просто и удобно. Должно ускорить поставку новых железок от вендора.
В дальнейшем, если и появится ещё материал по SD-WAN BI.ZONE, его будет точно мало. По этой причине далее буду складывать всё в эту статью в виде апдейтов.
Приглашаю поделиться мнением в Tелеграм канал