🥇SD-WAN и DNA в помощь админу: особенности архитектур и практика

Стенд, который можно пощупать у нас в лабе, если хочется.

SD-WAN и SD-Access — два разных новых проприетарных подхода к построению сетей. В будущем они должны слиться в одну оверлейную сеть, но пока только приближаются. Логика такая: берём сеть образца 1990-х и накатываем на неё все нужные патчи и фичи, не дожидаясь, пока это ещё лет через 10 станет новым открытым стандартом.

SD-WAN — это патч SDN к распределённым корпоративным сетям. Транспорт отдельно, контроль отдельно, поэтому контроль упрощается.

Плюсы — все каналы связи используются активно включая резервный. Есть маршрутизация пакетов до приложений: что, через какой канал и с каким приоритетом. Упрощённая процедура развёртывания новых точек: вместо накатывания конфига — только указания адреса сервера Циски в большом Интернете, ЦОДе КРОК или заказчика, откуда берутся конфиги именно для вашей сети.

SD-Access (DNA) — это автоматизация управления локальной сетью: конфигурация из одной точки, визарды, удобные интерфейсы. Фактически строится другая сеть с другим транспортом на уровне протоколов поверх вашей, и на границах периметра обеспечивается совместимость со старыми сетями.

С этим тоже разберёмся ниже.

Теперь немного демонстраций на тестовых стендах в нашей лабе, как это выглядит и работает.

Начнём с SD-WAN. Основные возможности:

Упрощение деплоймента новых точек (ZTP) — предполагается, что вы каким-то образом скармливаете точке адрес сервера с настройками. Точка стучит к нему, получает конфиг, накатывает его и включается в вашу панель управления. Таким образом обеспечивается Zero-Touch Provisioning (ZTP). Чтобы развернуть оконечное устройство, сетевому инженеру не нужно выезжать на площадку. Главное – на месте правильно включить устройство и подключить к нему все кабели, далее оборудование само подключится к системе. Загрузить конфиги можно через DNS-запросы в облаке вендора с подключённого USB-накопителя, а можно открыть гиперссылку с ноутбука, подключённого к устройству по Wi-Fi или Ethernet.
Упрощение рутинного администрирования сети — конфиг из шаблонов, глобальные политики, настраиваемые централизованно хоть на пять филиалов, хоть на 5 000. Всё из единого места. Чтобы не было долгой дороги — очень удобная опция автоматического возврата к предыдущему конфигу.
Управление трафиком на уровне приложений — обеспечение качества и постоянного обновления сигнатур приложений. Политики настраиваются и накатываются централизованно (не нужно писать и апдейтить роут-мапы для каждого маршрутизатора, как раньше). Видно, кто, куда и что шлёт.
Сегментация сети. Независимые изолированные VPN поверх всей инфраструктуры — каждая со своей маршрутизацией. По умолчанию трафик между ними закрыт, можно открывать доступы только понятным видам трафика в понятных узлах сети, например, пропуская всё через большой файрволл или прокси.
Видимость истории качества работы сети — как работали приложения и каналы. Очень полезно для анализа и исправления ситуации ещё до того, как от пользователей начнут поступать жалобы на нестабильную работу приложений.
Видимость по каналам — стоят ли они своих денег, реально ли на объекте к вам приходят два разных оператора, или они по факту проходят через одну и ту же сеть и деградируют/падают одновременно.
Видимость для облачных приложений и steering-трафика через те или иные каналы на его основе (Cloud Onramp).
Одна железка содержит в себе роутер и файрволл (точнее, NGFW). Меньше железок — дешевле развернуть новый филиал.

Компоненты и архитектура решений SD-WAN

Оконечные устройства — WAN-маршрутизаторы, которые бывают аппаратными и виртуальными.

Оркестраторы — средство управления сетью. На них настраиваются параметры оконечных устройств, политики маршрутизации трафика, функционал безопасности. Получаются конфиги, которые отправляются автоматически через сеть контроля на узлы. Параллельно оркестратор слушает сеть и делает мониторинг — доступность устройств, портов, каналов связи, загрузку интерфейсов.

Средства аналитики. Делают отчёты на основании данных, собираемых с оконечных устройств: историю качества работы каналов, сетевых приложений, доступности узлов и т. п.

Контроллеры отвечают за применение политик маршрутизации трафика на сеть. Ближайшим их аналогом в традиционных сетях можно считать BGP Route Reflector. Глобальные политики, которые администратор настраивает в оркестраторе, приводят к тому, что контроллеры меняют состав своих таблиц маршрутизации и рассылают обновлённую информацию на оконечные устройства.

Что получает ИТ-служба от SD-WAN:

Резервный канал постоянно используется (не простаивает). Получается дешевле, поскольку можно позволить два менее толстых канала.
Автоматическое переключение трафика приложений между каналами.
Время администратора: можно глобально развивать сеть, а не ползать по каждой железке с конфигами.
Скорость поднятия новых филиалов. Она значительно выше.
Меньше простоев на время замены умершего оборудования.
Быстрое переконфигурирование сети под новые сервисы.

Что получает бизнес от SD-WAN:

Гарантированная работа бизнес-приложений на распределённой сети, в том числе через открытые интернет-каналы. Это про предсказуемость бизнеса.
Мгновенная поддержка новых бизнес-приложений на всей распределённой сети вне зависимости от количества филиалов. Это про скорость бизнеса.
Быстрое и безопасное подключение филиалов в любых удалённых локациях с использованием любых технологий подключения (Интернет есть везде, а выделенные линии и VPN — нет). Это про гибкость бизнеса в выборе локации.
Это может быть проект с поставкой и пусконаладкой, а может быть услугой
с ежемесячными платежами от ИТ-компании, оператора связи или облачного оператора. Кому как удобно.

Выгоды бизнеса от SD-WAN могут быть абсолютно разными, например, один заказчик нам сказал, что от топ-менеджера поступил запрос на проведение прямой линии со всеми сотрудниками многотысячной компании и возможностью доставлять контент.

Для нас это было «войсковой операцией». В тот момент мы уже решали задачу модернизации КСПД. А когда мы понимаем, что нам надо в принципе заниматься реновацией оборудования, а технологический стек ушёл вперёд, зачем нам заниматься реновацией тех же самых технологий и сервисов, если можно шагнуть дальше.

SD-WAN на месте устанавливается силами эникеев. Это важно для удалённых филиалов, где может просто не быть нормального админа. Отправляете почтой, говорите: «Кабель 1 воткните в коробку 1, кабель 2 — в коробку 2, и не перепутайте! Не перепутайте, #@$@%!». И если там не перепутают, то устройство само связывается с центральным сервером, забирает и применяет свои конфиги, и этот офис становится частью защищённой сети компании. Приятно, когда не надо ездить и легко обосновать в бюджете.

А вот схема стенда:

Немного примеров настройки:

Политика — глобальные правила управления трафиком. Редактирование политики.

Активация политики управления трафиком.

Массовая настройка основных параметров устройств (IP-адреса, пулы DHCP).

Скриншоты мониторинга перформанса приложений

Для облачных приложений.

Детально для Office365.

Для on-prem-приложений. К сожалению, на нашем стенде не удалось найти приложения с ошибками (FEC Recovery rate везде на нуле).

Дополнительно — перформанс каналов передачи данных.

Какие железки поддерживаются на SD-WAN

1. Аппаратные платформы:

Маршрутизаторы Cisco vEdge (прежнее название — Viptela vEdge), работающие под управлением ОС Viptela.
Маршрутизаторы Integrated Services Router (ISR) серий 1 000 и 4 000, работающие под управлением IOS XE SD- WAN.
Маршрутизатор Aggregation Services Router (ASR) серии 1 000, работающий под управлением IOS XE SD-WAN.

2. Виртуальные платформы:

Маршрутизатор Cloud Services Router (CSR) 1 000v, работающий под управлением IOS XE SD-WAN.
Маршрутизатор vEdge Cloud Router, работающий под управлением ОС Viptela.

Виртуальные платформы можно разворачивать на вычислительных платформах Cisco x86, например, Enterprise Network Compute System (ENCS) серии 5 000, Unified Computing System (UCS) и Cloud Services Platform (CSP) серии 5 000. Виртуальные платформы могут также работать на любом устройстве x86, использующем гипервизор, такой, как KVM или VMware ESi.

Как накатывается новое устройство

Список пролицензированных устройств для развёртывания скачивается либо со смарт-аккаунта в Cisco, либо загружается CSV-файлом. Больше скриншотов попробую достать позже, сейчас у нас нет новых устройств для развёртывания.

Последовательность шагов, через которые проходит устройство при развёртывании.

Как накатывается новое устройство/способ доставки конфига

Заводим устройства в Smart Account.

Можно загрузить CSV-файл, а можно по одному:

Заполняем параметры устройства:

Дальше в vManage синхронизируем данные со Smart Account. Устройство появляется в списке:

В выпадающем меню напротив устройства жмём Generate Bootstrap Configuration
и получаем начальный конфиг:

Этот конфиг необходимо скормить устройству. Самый простой способ — подключить к устройству флешку с сохранённым файлом с именем ciscosd-wan.cfg. При загрузке устройство будет искать этот файл.

Получив начальный конфиг, устройство сможет достучаться до оркестратора и получить оттуда полноценную конфигурацию.

Смотрим на SD-Access (DNA)

SD-Access упрощает настройку портов и прав доступа для подключения пользователей. Это делается с помощью визардов. Параметры портов задаются в привязке к группам «Администраторы», «Бухгалтерия», «Принтеры», а не к VLAN и IP-подсетям. Это минимизирует ошибки, связанные с человеческим фактором. Если, например, у компании много филиалов по России, а центральный офис при этом перегружен, то SD-Access позволяет решать больше задач именно на местах. Например, те же задачи по траблшутингу.

Для ИБ важно, что SD-Access предполагает чёткое разделение пользователей и устройств на группы и определение политик взаимодействия между ними, авторизацию при любом клиентском подключении к сети и обеспечение «прав доступа» по всей сети. Если следовать такому подходу, то администрировать становится гораздо проще.

Процесс запуска для новых офисов тоже упрощён благодаря Plug-and-Play-агентам в коммутаторах. Бегать по кроссовым с консолью, а то и вообще выезжать на объект не нужно.

Вот примеры настройки:

Общий статус.

Инциденты, которые стоит просмотреть администратору.

Автоматические рекомендации, что поменять в конфигах.

План по интеграции SD-WAN с SD-Access

Слышал, что есть такие планы у Циски — SD-WAN и SD-Access. Это должно заметно поубавить геморроя при управлении территориально распределёнными и локальными КСПД.

vManage (оркестратор SD-WAN) управляется через API с DNA Center (контроллера SD-Access).

Политики микро- и макросегментации мапятся следующим образом:

На уровне пакетов всё выглядит вот так:

Кто и что по этому поводу думает

Мы занимаемся SD-WAN с 2016 года в отдельной лаборатории, где тестируем разные варианты решений под нужды розницы, банков, транспорта и промышленности.

Очень много общаемся с реальными заказчиками.

Могу сказать, что розница уже уверенно тестирует SD-WAN, причём некоторые это делают с вендорами (чаще всего — с Cisco), но есть и те, кто пытается решить вопрос самостоятельно: пишут свою версию софта, по функционалу напоминающего SD-WAN.

Все так или иначе хотят прийти к централизованному управлению всего зоопарка оборудования. Это одна точка администрирования для нестандартных инсталляций и стандартных для разных вендоров и разных технологий. Важно минимизировать ручную работу, потому что это, во-первых, сокращает риск человеческого фактора при настройке оборудования, во-вторых, высвобождает ресурсы ИТ-службы на решение других задач. Обычно понимание необходимости приходит из-за очень долгих циклов обновления по всей стране. А, например, если розница торгует алкоголем, то ей нужна постоянная связь для продаж. Обновление или простой днём прямо сказывается на выручке.

Сейчас в рознице точно сформировано понимание, для каких задач ИТ будет использовать SD-WAN:

Быстрое развёртывание (часто нужно на LTE до прихода кабельного провайдера, часто нужно, чтобы новая точка поднималась админом в городе по ГПХ, а потом центр просто смотрел и конфигурировал).
Централизованное управление, связь для заграничных объектов.
Сокращение стоимости телекома.
Разные допсервисы (DPI-фичи дают возможность приоритетно доставлять трафик от важных приложений типа кассового).
Работа с каналами автоматически, а не руками.

И есть ещё проверка на комплаенс — много все про неё говорят, но никто не воспринимает как проблему. Поддержание того, что всё работает корректно тоже в этой парадигме нормально работает. Многие считают, что в эту сторону будет двигаться вообще весь рынок сетевых технологий.

Банки, имхо, пока тестируют SD-WAN скорее как новую технологическую фичу. Ждут окончания поддержки предыдущих поколений оборудования и только тогда будут меняться. У банков вообще своя особая атмосфера по каналам связи, поэтому текущее состояние отрасли их не очень напрягает. Проблемы скорее лежат в других плоскостях.

В отличие от российского рынка в Европе SD-WAN внедряется активно. У них дороже каналы связи, и поэтому европейские компании приносят свой стек в российские подразделения. В России же есть некая стабильность, потому что стоимость каналов (даже когда регион дороже центра в 25 раз) вполне нормально смотрится и не вызывает вопросов. Из года в год на каналы связи закладывают безоговорочно бюджет.

Вот пример из мировой практики, когда компания за счёт SD-WAN на Циске сэкономила время и деньги.

Есть такая компания — National Instruments. В определённый момент они стали понимать, что глобальная вычислительная сеть, «полученная» по результатам объединения 88 площадок по всему миру, была неэффективная. Помимо этого, компании не хватало пропускной способности и производительности ГВС. Не было баланса между непрерывным ростом компании и ограниченным ИТ-бюджетом.

SD-WAN помог сократить National Instruments расходы на MPLS на 25 % (экономия 450 тыс. долл. по итогам 2018 г.), расширив полосу пропускания на 3 075 %.

По итогам внедрения SD-WAN компания получила умную программно-определяемую сеть и централизованное управление политиками, чтобы автоматически оптимизировать трафик и производительность приложений. Вот здесь — детальный кейс.

Вот тут совершенно чумовой кейс переезда S7 в другой офис, когда сначала всё началось тяжело, но интересно — нужно было переделать 1,5 тысячи портов. А вот потом кое-что пошло не так и в итоге админы оказались теми последними перед дедлайном, на кого сыпятся все накопившиеся задержки.