GetNet

DMVPN — открытый стандарт, поэтому реализовать его может любой вендор. В рассматриваемом сценарии используются mGRE (multipoint GRE) и NHRP, в качестве Control Plane выбран BGP, для шифрования — IPsec.

Почему именно BGP? EIGRP отпадает практически автоматически: он реализован только у Cisco (и во FRR), и большинство вендоров смотрит на него с опаской. У OSPF, во-первых, на момент внедрения были свои нюансы на стороне Eltex, во-вторых, есть ограничения по масштабируемости, а при нескольких каналах им тяжелее управлять трафиком и расставлять приоритеты маршрутов. BGP же даёт полноценный Best Path Selection: любым атрибутом можно управлять — и жить замечательно.

Изначально в дизайне закладывается Front Door VRF, как и рекомендует Cisco. Причина проста: с одной стороны, оверлейный default нужно получать от хаба, с другой — на споках в Underlay прописывается default на провайдера, и эти два маршрута нужно развести между собой. Front Door VRF не является обязательным даже при необходимости оверлейного default, но альтернатив немного:

Если требуется, чтобы весь трафик уходил через основной хаб и основного провайдера, наиболее удачным инструментом управления оказывается AS-Path: он позволяет управлять и исходящим, и входящим трафиком через route-map на in/out с AS-Path prepend. Выстраивается иерархическая структура автономных систем, при которой падение первого туннеля переводит трафик на второй, а падение основного провайдера целиком — на соседний спок и один из его туннелей до одного из хабов.

В Eltex реализована фича, давно знакомая по Nexus, — BGP listen range. Изначально выбиралась архитектура iBGP: все споки и хабы в одной AS, потому что так удобнее конфигурировать хаб — настроил listen range на подсеть, и споки добавляются без дополнительной конфигурации.

На последних версиях прошивки Eltex поддерживается ещё и AS-range. В расширенном пространстве AS это делается без проблем, и появляется возможность реализовать сценарий eBGP: каждый спок — в своей AS, либо споки одного офиса в одной AS, споки второго офиса — в другой. Любой сценарий реализуется простым добавлением пула AS-range, если хабы построены на Eltex.

Во второй фазе при концепции iBGP хабы выступают route-реflector'ами и корректно зеркалируют маршрутную информацию.

Первая, вторая и третья фазы полностью совместимы между вендорами. Более того, совместим и Per-Tunnel QoS.
При этом третья фаза во многом была продиктована особенностями архитектуры Cisco: спецификой CEF и нехваткой TCAM — по сути, не хватало RIB. У Eltex даже самые младшие модели сегодня спокойно переваривают миллион записей, причём это заявлено в datasheet, а не получено «сверху». Отсюда практический вывод: если третья фаза уже используется — её и нужно сохранять для совместимости. Если её не было — возможно, она и не нужна.

В классическом варианте Cisco на споках в ISAKMP указывался адрес 0.0.0.0 0.0.0.0, что позволяло устанавливать соседство с любыми хабами и споками по одному ключу из конфигурационного файла.

На Eltex это работает иначе. Требуется отдельный IPsec-профиль до HUB1, отдельный — до HUB2 и отдельный — до всех остальных споков, сколько бы их ни было: сто, двести, триста. То есть настраиваются три профиля, а адреса хабов указываются вручную. Исправление обещали в конце 2025 года, но профиля в стиле Cisco в новых релизах пока не появилось.
Что касается сертификатов, на момент внедрения выбор был сделан в пользу pre-shared key.

Причина: функционала OCSP-сервера тогда не было, а CRL приходилось прошивать руками на каждую железку — ни на какой CRL-сервер устройство не ходило. Это плохо масштабируется. Если цель — максимально просто интегрировать Eltex и Cisco в DMVPN-облаке, оптимальным вариантом будет PSK. Идти в сторону сертификатов тоже можно: короткий ответ — работать будет.

Архитектура с двумя споками в одном офисе встречается нечасто: обычно провайдера действительно два, а спок один. Как разруливать резервирование ниже, на уровне офиса?

При использовании eBGP (каждый спок — в своей AS) хороший вариант — дотянуть BGP до самого уровня агрегации. Если там стек или MLAG, на нём тоже поднимается BGP: либо два port-channel, либо четыре и BGP-соседства.

Дотягивать BGP до агрегации удобно ещё и потому, что во всей сети остаётся единый протокол динамической маршрутизации. Альтернатива с OSPF выглядит хуже: при редистрибьюции OSPF в BGP и обратно на споках поднимаются два протокола маршрутизации, но главное — теряется управляемость. Например, задача «увести трафик со спока 1 на спок 2 целенаправленно» (на интерфейсе провайдера побежали ошибки или дропы, но канал не упал) в BGP решается AS-Path prepend в одном месте, и Best Path Selection перестраивает всё вплоть до агрегации. В OSPF для этого потребуется костыль в виде track-объекта, ухудшающего метрику, — довольно громоздкая конструкция.

Более современный подход — L3 to Access, когда уровень агрегации фактически «проглатывается»: стек (здесь безальтернативно именно стек, а не MLAG) ставится сразу на доступе, до него дотягивается BGP, и к нему же подключаются пользователи.

Модели здесь младше и стоят существенно дешевле: спок ESR-15R, а на стеке — 24-портовые MES, собранные в пару на случай отказа одного из устройств. Для офиса на 20–30 пользователей получается отличное решение. Лицензия на BGP для MES приобретается отдельно, но проблема невелика.

Ограничение у L3 to Access простое и банальное: у младших моделей ограниченное количество портов, особенно 10-гигабитных SFP+. Если этажей несколько, пусть даже небольших, такой дизайн не собрать — нужна агрегация, куда эти этажи будут сливаться. Если этаж один, пусть даже на 300 человек, можно собрать стек до 8 устройств и подключить его в ESR-30 парой линков: переподписка будет, но для офисной сети это не страшно. То есть выбор зависит не столько от масштаба офиса, сколько от его физической структуры. MLAG при этом — вариант «с запасом»: туда впоследствии можно добавить и серверы, и контроллеры, и что угодно ещё.

Типовой вопрос: как безболезненно смигрировать старое облако на Cisco с EIGRP на новую архитектуру с BGP и Eltex? На практике автоматизация здесь довольно простая, без ухищрений.
Конфигурация на все офисы готовится заранее по шаблонам и скриптам, а затем просто перезаливается файлами. Cisco ISR отлично загружаются из-под нового startup-config, залитого файлом. Приятная особенность ISR: даже если в конфиге написано что-то некорректное, устройство это просто проглотит и не отобразит в show run после перезагрузки. Переживать, что маршрутизатор не поднимется из-за пропущенного символа, не нужно. Таким образом всю архитектуру можно переработать и за ночь перевести разом сотню-другую офисов, наблюдая, как железки одна за другой подключаются к новому облаку.

Стоит завести шаблоны конфигурации — достаточно скрипта на три строчки, куда вбиваются параметры нового офиса: адрес провайдера, IP-адресация, адрес туннеля. Шаблон разливается, и готовая конфигурация сразу бутует ESR в офисе. Не Zero-Touch, но One-Touch Provisioning.

Для Eltex стоит посмотреть в сторону ECCM — системы управления, отчасти похожей на Cisco Prime. Там можно обновлять устройства, конфигурировать шаблонами, вести инвентаризацию и разворачивать мониторинг как некоторую альтернативу Zabbix. В целом работает неплохо.

Отдельного упоминания заслуживает система commit/confirm на Eltex ESR: сделал commit, дрогнула рука — через пару минут всё откатывается, и можно спокойно начинать заново. У Cisco в этом плане есть reload in, но перезагружать железку раз за разом обычно ничем хорошим не заканчивается.

Рекомендации по MTU и MSS связаны скорее с характеристиками каналов, чем с конкретной платформой — ESR это или ISR. Проходящий data-трафик подрезать необходимо, поскольку IPsec съедает часть полезной нагрузки. Насколько именно — зависит от используемых в IPsec протоколов и стойкости шифрования. Важно другое: MTU должен быть подрезан синхронно и одинаково на всём облаке — туннели-то динамические.
С мониторингом у Eltex ситуация хорошая: SNMP реализован подробно. Мониторить можно состояние туннелей, BGP-сессии и количество префиксов, приходящих с офисов на хаб. Если число префиксов просело — значит, где-то что-то не то. Таким образом можно двигаться в разные стороны, и с мониторингом всё будет замечательно.

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