Cisco IOS-XE 17.5 и SD-WAN: мигрируем филиальную сеть с MPLS и разбираем ThousandEyes на практике

Cisco IOS-XE 17.5 вышел несколько недель назад, и одна из вещей, которую мы ждали - углублённая интеграция SD-WAN с ThousandEyes. Параллельно у нас идёт живой проект: миграция сети нескольких филиалов клиента с MPLS на SD-WAN поверх интернета. Хороший момент, чтобы посмотреть что в новом релизе реально полезно, а что остаётся маркетинговым слоганом.

Контекст: зачем вообще уходить с MPLS

У клиента несколько офисов в разных городах, связанных через MPLS от одного провайдера. Схема работает годами, но цена за гарантированную полосу с SLA растёт, а бизнес-аппетиты к пропускной способности тоже не стоят на месте. Плюс появился запрос на резервирование: хочется иметь второй канал, хотя бы интернет, как fallback.

SD-WAN в этой задаче выглядит как разумный ответ: несколько каналов (MPLS + интернет), интеллектуальное переключение трафика между ними, policy-based routing на уровне приложений. Cisco SD-WAN (бывший Viptela) с управлением через vManage - один из вариантов, с которым мы работаем.

Что принёс IOS-XE 17.5 в части SD-WAN

Релиз не революционный, но несколько изменений заметны.

Application-Aware Routing получил дополнительные метрики для принятия решений о переключении трафика. Раньше AAR смотрел на latency, jitter и packet loss между vEdge-роутерами через BFD-зонды. Теперь добавились возможности опираться на данные ThousandEyes при принятии решений - то есть роутер видит не только качество тоннеля до следующего vEdge, но и реальный опыт доступа к конкретному SaaS-приложению снаружи периметра.

Policy Management в vManage стал чуть удобнее в части локализованных политик для SD-WAN edge-устройств. Конкретно - упростилась настройка per-VPN routing policies без необходимости городить сложные централизованные конструкции.

ThousandEyes интеграция - это основное, ради чего мы смотрели на 17.5 внимательнее.

ThousandEyes: что это и зачем

ThousandEyes (Cisco приобрела компанию в 2020-м) - это платформа мониторинга сети с распределёнными агентами по всему миру. Суть: агент в вашей сети или на устройстве измеряет реальное качество пути до целевого ресурса - не просто пинг, а полная трассировка с метриками на каждом хопе, HTTP-тесты с измерением времени до TTFB, BGP-мониторинг, мониторинг DNS.

Начиная с определённых версий IOS-XE, ThousandEyes Enterprise Agent можно разворачивать прямо на роутере как виртуальную машину, без отдельного железа. В 17.5 это стало стабильнее и появились дополнительные интеграции с SD-WAN policy framework.

Практический смысл такой: роутер в филиале сам измеряет что происходит с доступом к Office 365 или к корпоративному приложению в облаке - причём по каждому из своих uplink-каналов независимо. Если MPLS-канал начинает деградировать в части latency до Teams, политика может переключить этот трафик на интернет-канал раньше, чем пользователи начнут жаловаться.

Как это выглядит в нашем проекте

Сеть клиента: головной офис в Москве, три филиала, Cisco ISR-роутеры. Переводим поэтапно.

Первый филиал уже переведён на SD-WAN с двумя каналами - MPLS остался как основной, добавили интернет-канал через локального провайдера. vEdge-функциональность запущена на существующих ISR через лицензию IOS-XE SD-WAN. ThousandEyes-агент развёрнут на роутере.

Что показал ThousandEyes за первые недели:

• Реальное расхождение между характеристиками MPLS по контракту и тем, что видит агент. Провайдер обещает latency до Москвы 15ms, агент стабильно фиксирует 22-28ms в пиковые часы. Не катастрофа, но факт.
• Интернет-канал неожиданно лучше для ряда SaaS-приложений - Office 365 и Teams ходит через интернет с меньшим общим временем отклика, чем через MPLS с haipinning через Москву. Это логично: Microsoft строит свою инфраструктуру с расчётом на прямые интернет-подключения, а не на доставку через корпоративный MPLS.
• BGP-мониторинг зафиксировал несколько событий маршрутной нестабильности у MPLS-провайдера, которые не отражались в SLA-отчётах (пакеты доходили, но пути менялись, что влияло на latency). Это полезная информация для разговора с провайдером.

Настройка AAR с ThousandEyes-данными

Политика в vManage выглядит следующим образом: для трафика Office 365 определяем условия переключения не только по BFD-метрикам (потери, jitter между vEdge), но и по данным ThousandEyes HTTP-теста до конкретных Office 365 endpoints.

Конфигурация в vManage через SD-WAN policy -> Application-Aware Routing -> привязка к ThousandEyes тест-данным пока требует ручной работы в части mapping-а тестов к политикам. Интерфейс не самый интуитивный, и документация в 17.5 всё ещё имеет пробелы - часть нюансов пришлось выяснять через TAC и community.cisco.com.

Итоговая схема: Teams и SharePoint трафик переключается на интернет-канал если ThousandEyes фиксирует degradation до Microsoft-эндпоинтов через MPLS. Критичный ERP-трафик до серверов в ЦОД клиента остаётся на MPLS с fallback на интернет только при packet loss выше порога.

Что работает не так гладко

Лицензирование ThousandEyes - отдельный разговор. Агент на роутере требует собственной лицензии ThousandEyes. Для клиентов, которые не знали об этом на этапе бюджетирования SD-WAN, это сюрприз.

Производительность роутера. ThousandEyes-агент работает как виртуальная машина на платформе ISR/ASR. На роутерах с ограниченными ресурсами это ощутимо - нужно считать CPU и память заранее. На ISR 4331 с базовой конфигурацией нам пришлось ограничить количество параллельных тестов.

Корреляция данных ThousandEyes и vManage - всё ещё две разные консоли. Интеграция есть, но целостной картины в одном месте нет. Смотришь метрики в vManage, переключаешься в ThousandEyes для детализации. Для оперативного мониторинга это терпимо, для разбора инцидентов - чуть утомляет.

Промежуточный итог

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

Следующий шаг - перевод второго филиала и донастройка политик по результатам первого месяца наблюдений. Об этом, скорее всего, расскажем когда будет что рассказать.

Клиентам, которые думают о SD-WAN в рамках managed-сопровождения, стоит закладывать ThousandEyes в архитектуру с самого начала - не как опцию, а как инструмент для обоснования routing-решений и разговоров с провайдерами по факту, а не по словам.