Cisco 300-415: Архитектура фабрики Cisco SD-WAN и плоскости — Руководство по подготовке

By Laurynas Brazys · 13 August 2026 · #cisco #300-415 #certification #exam-prep #study-guide

Часть Cisco SD-WAN 300-415 ENSDWI — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Cisco, или пройдите тесты на время на ExamRoll.io.

Обзор

Cisco SD-WAN — это фабрика, управляемая намерениями, построенная из отдельных компонентов и уровней, которые разделяют функции управления, оркестрации, контроля и передачи данных. Архитектура масштабируется от нескольких филиалов до тысяч, независимо от используемой транспортной сети, сохраняя при этом детерминированное управление и безопасность. В этом разделе объясняются роли vManage, vSmart, vBond и WAN Edge; уровни и протоколы, которые их соединяют; выбор платформ; адресация и сегментация; шаблоны топологии оверлея; концепции мультитенантности и группировки; а также ключевые компромиссы в проектировании и режимы сбоев, которые необходимо учитывать.

Компоненты и уровни фабрики

• WAN Edge: Маршрутизатор уровня данных на границе филиала, кампуса, ЦОД или облака. Он формирует защищенные туннели данных, применяет политики, использует BFD для проверки работоспособности путей, обменивается маршрутами OMP с контроллерами и пересылает пользовательский трафик.
• vSmart Controller: «Мозг» уровня управления. Он строит и поддерживает топологию оверлея, распространяет информацию о маршрутах и политиках через OMP, а также оркестрирует подключение WAN Edge и распределение криптографических ключей для обеспечения безопасного пиринга IPsec между пограничными устройствами.
• vBond Orchestrator: Первая точка контакта для новых устройств. Он аутентифицирует устройство, помогает в прохождении NAT и координирует подключение каждого WAN Edge к vSmart. Он поддерживает постоянные соединения с контроллерами vSmart и обычно размещается в доступном публичном IP-пространстве для универсального подключения устройств.
• vManage: Уровень управления и оркестрации (NMS). Он обеспечивает ввод намерений, шаблоны конфигурации, управление образами, телеметрию, автоматизацию Cloud OnRamp и API. vManage не участвует в работе уровня управления пересылкой данных.

Уровни и протоколы:

• Уровень управления: vManage использует защищенные каналы (NETCONF/gRPC через TLS) для мониторинга и настройки устройств и контроллеров.
• Уровень оркестрации: vBond использует DTLS/TLS для аутентификации устройств, обмена информацией о доступности контроллеров и прохождения NAT. При наличии сертификатов контроллера и без настройки альтернативного порта vBond прослушивает UDP/TCP 12346.
• Уровень управления (Control plane): vSmart использует OMP для обмена префиксами, TLOC и политиками с устройствами WAN Edge. По умолчанию для управляющих соединений используется DTLS; также поддерживается TLS, что часто требуется при работе через строгие межсетевые экраны или для соответствия нормативным требованиям.
• Уровень данных: Устройства WAN Edge строят туннели IPsec (или GRE, где это уместно) между TLOC для зашифрованной передачи данных, с проверкой BFD для каждого туннеля для обнаружения сбоев менее чем за секунду и маршрутизации с учетом приложений.

Жизненный цикл при подключении:

1. WAN Edge связывается с vBond, проходит аутентификацию и получает списки контроллеров.
2. WAN Edge устанавливает управляющие сессии DTLS/TLS с vSmart (и с vManage для управления).
3. vSmart распространяет информацию о криптографических ключах; затем WAN Edge формирует туннели IPsec с другими WAN Edge в соответствии с политикой и топологией.

Последствия для отказоустойчивости:

• Потеря vManage влияет только на конфигурацию и видимость; пересылка данных продолжается.
• Потеря vBond влияет на подключение новых устройств; существующие устройства не затрагиваются.
• Потеря всех контроллеров vSmart изолирует уровень управления; туннели данных сохраняются, но изменения маршрутов/политик прекращаются, и устаревшее состояние уровня управления со временем может ухудшить работу.
• Переключение путей на основе BFD и наличие нескольких TLOC обеспечивают непрерывность работы уровня данных во время сбоев в транспортной сети.

Идентификация, адресация и сегментация

Идентификация и адресация ориентированы на оверлей:

• Имя организации: Строка, единая для всей фабрики, которая должна совпадать на всех устройствах и контроллерах; несоответствие препятствует установлению соседства на уровне управления.
• System IP: Уникальный 32-битный идентификатор для каждого устройства, подобный loopback-интерфейсу, используемый в кортежах TLOC и для адресации на уровне управления. Он не привязан ни к какому физическому интерфейсу.
• Site ID: Числовой идентификатор, группирующий устройства в одной локации. По умолчанию устройства с одинаковым Site ID не формируют прямые туннели данных между собой, чтобы избежать петель маршрутизации (hairpin) и циклов внутри площадки.
• Сертификаты: Устройства и контроллеры используют идентификацию на основе X.509. Аппаратные WAN Edge используют защищенный идентификатор устройства (SUDI) для автоматической настройки (zero-touch provisioning); все устройства должны быть зарегистрированы и авторизованы в vManage перед подключением к фабрике.

Ключевые VPN:

• VPN 0 (Transport): Обеспечивает подключение к транспортной сети и содержит интерфейсы TLOC в сторону MPLS, прямого доступа в Интернет (DIA), широкополосного доступа или LTE. Здесь терминируются NAT, DHCP, PPPoE, а также статические маршруты и маршруты по умолчанию. TLOC = {system IP, color, encapsulation}, где color характеризует транспорт (например, mpls, biz-internet, public-internet), а encapsulation — это IPsec или GRE.
• VPN 512 (Management): Внеполосное управление устройством и доступность контроллеров. На IOS XE SD-WAN это соответствует VRF управления; на vEdge это явно VPN 512. Контроллеры и WAN Edge устанавливают сессии управления с использованием протоколов, защищенных TLS.
• Сервисные VPN (1–511, кроме 512): Переносят пользовательские сервисы и могут использовать OSPF, EIGRP, BGP, статическую маршрутизацию или коммутацию (bridging). Политики (централизованные и локализованные) управляют потоками между VPN и внутри VPN, QoS и безопасностью.

Полезные элементы базовой конфигурации:

sdwan
 system-ip 10.255.0.11
 site-id 101
 organization-name ACME-Global

Возможные режимы сбоев, на которые стоит обратить внимание:

• Дублирующиеся System IP или Site ID создают аномалии в работе уровня управления или нежелательное подавление туннелей.
• Несоответствие имени организации препятствует установлению соседства OMP.
• Истечение срока действия или отзыв сертификата нарушает доверие между контроллером и устройством.
• Неправильно размещенный маршрут по умолчанию для управления в VPN 512 изолирует устройство от контроллеров; неправильно размещенный транспортный маршрут по умолчанию в VPN 0 изолирует TLOC.

Платформы, модели развертывания и дизайн контроллеров

Платформы WAN Edge:

• Cisco IOS XE SD-WAN: Поддерживается на платформах серий ISR 4000 и ASR 1000 (а также на семействе Catalyst 8000). Предпочитайте IOS XE SD-WAN для долгосрочного развития функционала и унифицированных сервисов в филиалах.
• vEdge: Ранние аппаратные/виртуальные платформы на базе Viptela, которые все еще поддерживаются во многих развертываниях; при планировании миграции следует учитывать различия в функционале и сроки жизненного цикла.
• Virtual WAN Edge: Работает на гипервизорах и серверах, включая Cisco UCS и Cisco ENCS 5000 Series, а также в публичных облаках (AWS, Azure, GCP). Используйте Cloud OnRamp для автоматизации развертываний IaaS; предварительные требования включают подписку на образ из маркетплейса облака (например, AWS AMI) и подготовку шаблона устройства в vManage.

Независимость от транспортной сети (underlay) и разнообразие транспортов:

• Каждый TLOC привязывается к транспорту с соответствующим цветом (color); политика может отдавать предпочтение, балансировать или исключать транспорты в зависимости от приложения, SLA или роли площадки.
• IPsec используется по умолчанию для недоверенных транспортных сетей (underlay); GRE может использоваться поверх частных сетей MPLS, где шифрование не требуется или ограничено.
• BFD обеспечивает проверку работоспособности каждого туннеля и предоставляет метрики SLA (потери, задержка, джиттер) для управления маршрутизацией с учетом приложений (application-aware routing).

Кластеризация, масштабирование, высокая доступность и размещение контроллеров:

• vManage: Развертывайте в виде кластера из трех или более узлов для обеспечения высокой доступности (HA) и отказоустойчивости; размещайте совместно с высокопроизводительным хранилищем для телеметрии и репозитория образов. Часто создавайте резервные копии.
• vSmart: Развертывайте несколько контроллеров в разных доменах отказа и географических регионах; все WAN Edge устройства устанавливают сессии управления с более чем одним vSmart. Экземпляры vSmart масштабируются горизонтально; планируйте емкость N+1 для устойчивости к потере одного контроллера.
• vBond: Развертывайте как минимум два оркестратора в публичном адресном пространстве (или со статическим NAT и согласованным маппингом портов). vBond поддерживает постоянные сессии с vSmart и временные сессии с WAN Edge во время их подключения (onboarding).
• Размещение: Контроллеры могут быть размещены в ваших дата-центрах или в публичном облаке. Обеспечьте детерминированную входящую доступность vBond из интернета и достаточную пропускную способность для исходящего трафика от WAN Edge. Если промежуточные устройства (middleboxes) требуют исключений для инспекции TLS, предпочитайте сессии управления на основе TLS, а не DTLS.

Примечания по эксплуатации:

• Транспортом плоскости управления по умолчанию является DTLS; переключайтесь на TLS при прохождении через строгие межсетевые экраны или домены соответствия, которые разрешают только шифрованное управление на основе TCP. Убедитесь, что соответствующие порты разрешены на всем пути.
• Когда WAN Edge подключается к сети, он устанавливает сессию DTLS/TLS с vSmart и IPsec-туннели с другими пограничными устройствами на основе достижимости по OMP и политик. На широкополосных каналах обеспечьте работу NAT keepalives и UDP pinholes, чтобы избежать незаметных обрывов туннелей.

Топологии оверлея, мультитенантность и компромиссы проектирования

Шаблоны топологий реализуются через централизованные политики управления (анонсы маршрутов и TLOC) и локализованные политики данных:

• Полносвязная топология (Full mesh): наименьшая задержка между всеми площадками; отличная отказоустойчивость; самая высокая нагрузка на плоскости управления и данных из-за большого количества сессий IPsec/BFD.
• Топология «звезда» (Hub-and-spoke): простое масштабирование с меньшим количеством туннелей; хаб становится узким местом по пропускной способности и отказоустойчивости без схемы с двумя хабами; более высокая задержка для трафика между оконечными узлами (spoke-to-spoke).
• Региональный хаб: балансирует задержку и масштабирование, ограничивая полносвязные топологии регионами и передавая межрегиональный трафик через хабы; требует тщательной настройки политик для предотвращения тромбонинга.
• Двойной хаб (active/active или active/standby): повышает отказоустойчивость и может распределять нагрузку; усложняет управление (ECMP, разрешение коллизий, предотвращение петель) и потребляет больше ресурсов хаба.

Мультитенантность и группировка:

• Истинная мультитенантность: сервис-провайдеры могут включить режим multi-tenant на контроллерах для размещения нескольких логических организаций с изолированными плоскостями управления, администраторами и политиками на одном кластере контроллеров.
• Сегментация по арендаторам или бизнес-подразделениям: используйте сервисные VPN для разделения трафика, утечки маршрутов (route-leaking) там, где это необходимо, и применения политик/QoS для каждой VPN.
• Группировка устройств: используйте группы устройств vManage, списки сайтов, списки VPN, списки префиксов/TLOC для целевого применения политик, обновлений и шаблонов по функциям, регионам или ролям.

Компромиссы проектирования:

• Задержка против контроля политик: полносвязная топология минимизирует задержку, но усложняет применение и наблюдение за политиками; hub-and-spoke упрощает управление, но добавляет задержку для горизонтального трафика (east–west).
• Отказоустойчивость против операционного масштаба: большее количество TLOC, транспортов и хабов повышает доступность и выбор путей, но увеличивает число сессий IPsec/BFD и нагрузку на плоскость управления. Используйте регионализацию и суммирование для контроля размеров таблиц OMP и FIB.
• Разнообразие транспортной сети (underlay) против стоимости: добавление широкополосного доступа и LTE улучшает доступность и устойчивость к деградации каналов (brownout); стоимость, поведение NAT и переменный джиттер могут усложнить соблюдение SLA. Используйте классы SLA на основе BFD и маршрутизацию с учетом приложений (app-aware routing) для ограничения чувствительного трафика.
• Богатство централизованных политик против непрозрачности при поиске неисправностей: сложные цепочки условий/действий (match/action) обеспечивают гранулярный контроль, но могут скрывать логику пересылки. Поддерживайте модульность, версионирование и хорошую документацию политик; тестируйте их в промежуточной (staging) фабрике.
• Безопасность против производительности: обязательное использование IPsec на всех транспортах усиливает конфиденциальность, но создает нагрузку на CPU и требует учета MTU/фрагментации. Предпочитайте аппаратное ускорение криптографии и последовательную настройку MSS/PMTUD.

Распространенные режимы сбоев и способы их устранения:

• Асимметричная политика, препятствующая формированию туннеля: проверяйте симметричность политик TLOC и управления; подтверждайте маршруты OMP TLOC.
• Истечение срока действия NAT-проколов (pinholes) для UDP: предпочитайте управление через TLS или настройте NAT keepalives; рассмотрите возможность использования статического NAT для контроллеров.
• Неправильное использование Site ID, приводящее к схлопыванию туннелей внутри площадки: убедитесь в уникальности Site ID для каждой физической локации; используйте политики BFD с ограничением по цвету (color-restrict) для реализации намерений внутри кампуса вместо принудительного объединения сайтов.
• Перегрузка хабов оконечными узлами (spoke-starved hubs): отслеживайте загрузку CPU/криптографии и количество сессий BFD на хабах; масштабируйте хабы горизонтально или вводите региональные хабы; используйте QoS и полисеры для защиты управляющего трафика.

Практический сценарий

Компания Apex Manufacturing расширяется в AWS, имея 600 филиалов по всему миру на двух транспортах (MPLS и DIA). Им необходимо расширить SD-WAN в AWS с минимальной задержкой до региональных приложений, поддерживать соответствие требованиям, используя TLS для управления, и обеспечить высокую доступность контроллеров.

1. Разместите два оркестратора vBond в публичном IP-пространстве и три контроллера vSmart в двух облаках.

• Обоснование: vBond должен быть доступен извне для содействия в обходе NAT; несколько экземпляров vSmart обеспечивают высокую доступность плоскости управления и географическую близость. vBond поддерживает постоянные сессии с vSmart и временные сессии с WAN Edge, ускоряя ввод в эксплуатацию и повторное подключение.

2. Переведите все управляющие соединения на TLS и разрешите TCP 12346 на корпоративных межсетевых экранах.

• Обоснование: DTLS по умолчанию может блокироваться строгими промежуточными устройствами (middleboxes). TLS обеспечивает доступность плоскости управления через TCP-прокси и домены инспекции без ущерба для шифрования или целостности.

3. Разверните vManage в виде кластера из трех узлов в центральном облачном регионе с ежедневным резервным копированием.

• Обоснование: Плоскость управления должна оставаться доступной для операций с политиками, образами и телеметрией. Кластеризация сохраняет состояние и масштабирует доступ к API/GUI; резервные копии защищают от потери операционных данных.

4. Используйте Cloud OnRamp for IaaS для создания виртуальных маршрутизаторов WAN Edge в AWS, по одному на VPC, в подсетях, подключенных к transit gateway.

• Обоснование: Cloud OnRamp автоматизирует подписку на AMI, развертывание и регистрацию сертификатов. Устройства WAN Edge терминируют TLOC SD-WAN и анонсируют маршруты VPC через OMP, интегрируя облачные рабочие нагрузки в фабрику с тем же набором политик.

5. Назначьте system IP из зарезервированного блока оверлея и уникальные site ID для каждого облачного региона (например, 9001–9010), а также установите единое имя организации (organization name) для всей фабрики.

• Обоснование: Уникальные system IP и site ID предотвращают подавление туннелей и неоднозначность в плоскости управления. Единообразие organization-name является обязательным для установления соседства OMP и доверия к сертификатам.

6. Настройте VPN 0 для двух транспортов на пограничных устройствах в AWS (публичный интернет и, при наличии, Direct Connect через приватный цвет) и включите BFD с классами SLA для маршрутизации с учетом приложений (app-aware routing).

• Обоснование: Разнообразие транспортов улучшает доступность и устойчивость к деградации каналов (brownout). BFD предоставляет метрики потерь/задержки/джиттера для направления трафика приложений на TLOC с наилучшей производительностью в соответствии с SLA.

7. Предоставляйте доступ к VPN 512 только для подсетей управления и ограничивайте маршрутизацию к контроллерам с помощью явных статических маршрутов и ACL.

• Обоснование: Минимизирует поверхность атаки на плоскость управления и предотвращает утечки маршрутов, которые могут изолировать устройства или излишне раскрыть сервисы контроллеров.

8. Внедрите топологию с региональными хабами, используя пограничные устройства AWS в качестве хабов для своих регионов, с двумя локальными (on-prem) хабами на каждом континенте для отказоустойчивости, и включите прямые интернет-пути между оконечными узлами (spoke-to-spoke) для трафика, чувствительного к задержкам.

• Обоснование: Региональные хабы локализуют потоки для снижения задержки и ограничения масштаба плоскости управления; двойные хабы обеспечивают резервирование. Контролируемые прямые туннели spoke-to-spoke сохраняют низкую задержку для приложений реального времени, не перегружая хабы.

9. Примените централизованные политики управления для суммирования маршрутов филиалов на региональных хабах, ограничения анонсов TLOC предназначенными регионами и обеспечения сегментации с помощью сервисных VPN для производственного, OT и гостевого трафика.

• Обоснование: Суммирование снижает частоту изменений маршрутов OMP и использование памяти. Ограничение анонсов TLOC предотвращает непреднамеренное формирование межрегиональных туннелей. Сегментация на основе VPN поддерживает границы соответствия требованиям с явной утечкой маршрутов (route-leaking) только там, где это необходимо.

10. Отслеживайте состояние BFD и плоскости управления; настройте оповещения о потере vSmart или vBond и заранее выделите емкость N+1.

• Обоснование: Раннее обнаружение деградации управления предотвращает широкомасштабную нестабильность. N+1 гарантирует, что фабрика выдержит отказ контроллера без потери сессий, защищая как сходимость плоскости управления, так и отказоустойчивость плоскости данных.

Все домены · Подключение контроллеров →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →