Cisco 300-415: Централизованные политики и инжиниринг трафика — Руководство по подготовке

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 — это фреймворк, который позволяет программировать поведение трафика и намерения маршрутизации с контроллеров vSmart по всей фабрике. vSmart, управляющий оверлейным уровнем управления через OMP, распространяет централизованную политику управления (для маршрутов OMP и TLOC) и политики уровня данных, такие как data policy, application-aware routing (app-route) и cflowd. Эти политики формируют топологию (hub-and-spoke, ограничение mesh-сети), выбирают пути на основе производительности приложений, направляют потоки к сервисам и сегментируют трафик по VPN. Поскольку политики могут изменять как связность на уровне управления, так и пересылку на уровне данных, тщательное проектирование, предварительный просмотр и поэтапное развертывание необходимы для предотвращения сбоев.

Типы и составные блоки централизованной политики

• Централизованная политика управления (Centralized control policy)

  • Область применения: Уровень управления (OMP) между устройствами WAN Edge и vSmart.
  • Назначение: Фильтрация/изменение анонсов маршрутов OMP и TLOC, установка атрибутов (preference, tag, origin, TLOC) и построение топологий (hub-and-spoke, partial mesh).
  • Направление: Входящее (inbound, на vSmart от WAN Edge) и исходящее (outbound, с vSmart на WAN Edge).

• Централизованная политика данных (Centralized data policy)

  • Область применения: Классификация на уровне данных (L3/L4, поля, app-ID) на WAN Edge, устанавливается контроллером vSmart.
  • Назначение: Разрешение/запрет потоков, установка VPN, установка TLOC, установка DSCP/маркировки, policing, mirroring и вставка/цепочка сервисов (service insertion/chaining).
  • Направление: Оценивается на WAN Edge относительно сервисной стороны (LAN) или туннельной стороны (WAN) в зависимости от того, где она запрограммирована; обычно проектируется для применения на входе с сервисной стороны (service-side ingress) для потоков от пользователя в WAN и на туннельной стороне для обратного трафика, если требуется симметричное поведение.

• Политика маршрутизации на основе приложений (Application-aware routing, app-route)

  • Область применения: Выбор пути на уровне данных на основе приложения и SLA (потери, задержка, джиттер), измеряемых с помощью BFD.
  • Назначение: Направление трафика на предпочтительные TLOC/цвета, определение классов SLA на основе проб, установка резервных путей (fallback) и выполнение динамической инженерии трафика для каждого приложения/семейства.
  • Ключевое поведение: Постоянно оценивает производительность пути; может переключать пути при ухудшении SLA.

• Политика cflowd

  • Область применения: Телеметрия потоков (подобная IPFIX/NetFlow), генерируемая устройствами WAN Edge.
  • Назначение: Включение/выключение экспортеров для каждого VPN, определение частоты выборки (sampling rate), шаблонов и коллекторов (vManage или внешних).
  • Примечание по проектированию: Сэмплирование должно обеспечивать баланс между видимостью и накладными расходами на CPU/пропускную способность; включение для каждого VPN поддерживает сегментированную отчетность.

Списки политик — это многократно используемые объекты для сопоставления (match):

• Site list: Идентификаторы сайтов (Site ID), используемые для выбора мест применения политик и для сопоставления с сайтами-источниками/назначениями маршрутов.
• VPN list: VRF (VPN), используемые для сегментации области действия политики и создания правил для каждого сегмента.
• Prefix list: IP-префиксы для сопоставления с маршрутами OMP или трафиком данных.
• Data prefix list: Специализированный объект префиксов для классификации в политике данных.
• TLOC list: Кортежи из system IP, цвета (color) и инкапсуляции, используемые для сопоставления или установки атрибутов TLOC.
• Color list: Один или несколько цветов транспорта (например, biz-internet, mpls, public-internet) для таргетинга/привязки к каналу.
• Application list: Приложения/группы NBAR2 для классификации трафика в политиках app-route или data policy.
• SLA class: Пороговые значения задержки, потерь и джиттера, связанные с app-route для управления трафиком на основе производительности.

Структура и оценка последовательностей (sequence) в политике:

• Последовательности упорядочены, применяется правило первого совпадения (first-match wins). Каждая последовательность имеет:
  • Условия сопоставления (Match): Списки/поля (site/VPN/prefix/TLOC/color/app, порты L4, DSCP, протокол).
  • Действия (Action): Разрешить/запретить (accept/deny), установить атрибуты (TLOC, VPN, DSCP, preference, tag), вставка сервисов, policing, mirroring.
• Действие по умолчанию (Default action): Применяется, если ни одна последовательность не совпала. Обычные значения по умолчанию — accept (для control/data), чтобы избежать непреднамеренных отбрасываний пакетов; явное deny по умолчанию используется целенаправленно и требует тщательной проверки.
• Направление:
  • Направление политики управления (control policy) задается на vSmart (inbound/outbound для OMP).
  • Политики данных (data policy) и app-route работают с трафиком на WAN Edge; выберите поведение на сервисной (service-side) или туннельной (tunnel-side) стороне в зависимости от потока, на который вы хотите повлиять, и обеспечьте симметрию обратного трафика, если в пути есть stateful-сервисы.

Проектирование политик уровня управления и манипулирование маршрутами/TLOC

Политика управления — это основной инструмент для формирования топологии оверлея, поскольку она определяет, какие маршруты OMP и TLOC может отправлять или получать сайт:

• Манипулирование маршрутами OMP

  • Используйте входящую политику управления для фильтрации, тегирования или установки атрибутов для маршрутов, полученных от сайта, до того, как они попадут в RIB оверлея на vSmart.
  • Используйте исходящую политику управления для ограничения маршрутов, анонсируемых определенным сайтам (например, не анонсировать префиксы, полученные от spoke-узлов, другим spoke-узлам).
  • Распространенные действия: установка предпочтения (preference, влияет на выбор лучшего пути OMP), установка тега (tag, для последующего сопоставления), установка источника (origin), установка ограничений по сайту-источнику.

• Манипулирование TLOC

  • Выполняйте сопоставление по атрибутам TLOC (system IP, цвет, инкапсуляция), чтобы фильтровать или предпочитать определенные транспорты.
  • Действия включают изменение предпочтительных атрибутов TLOC или предпочтений, чтобы анонсы маршрутов склонялись к определенному цвету (например, предпочитать MPLS для критически важных подсетей).
  • Компромисс: чрезмерно агрессивная фильтрация TLOC может изолировать сайты в случае сбоя оставшегося транспорта. Предпочитайте тонкую настройку атрибутов полному запрету, если у вас нет резервных путей.

• Шаблоны топологии

  • Hub-and-spoke: исходящая политика управления от vSmart к spoke-узлам запрещает анонсирование маршрутов, исходящих от spoke-узлов, другим spoke-узлам; hub-узлы получают и анонсируют все маршруты.
  • Ограничение ячеистой топологии (mesh): похоже на hub-and-spoke, но разрешает обмен трафиком между определенными парами spoke-spoke (например, для региональных ячеистых сетей) с помощью исключений в последовательностях политик.
  • Сегментация: комбинируйте списки VPN с фильтрацией маршрутов, чтобы изолировать оверлеи для каждого VPN; анонсируйте только маршрут по умолчанию или избранные префиксы на ограниченные сайты.

Режимы отказа и компромиссы:

• Неправильно примененная исходящая политика управления с действием “запретить по умолчанию” (deny default) может отозвать критически важные маршруты, изолируя сайты. Всегда используйте “разрешить по умолчанию” (default accept) и добавляйте целевые запреты, если только предварительный просмотр политики явно не подтверждает полный охват.
• Масштабное изменение атрибутов OMP может вызвать колебания маршрутов (route churn); развертывайте изменения поэтапно по спискам сайтов, чтобы уменьшить нагрузку на уровень управления.
• Перезапись атрибутов TLOC может привести к асимметричной пересылке, если на обратный путь не оказывается аналогичное влияние; проверяйте оба направления.

Маршрутизация с учетом приложений, внедрение сервисов и сегментация

Маршрутизация с учетом приложений (AAR) и политика данных вместе обеспечивают детальное управление трафиком:

• AAR и управление трафиком

  • Классы SLA определяют допустимые значения потерь/задержки/джиттера; пробы BFD для каждой пары TLOC предоставляют измерения в реальном времени.
  • Политика app-route сопоставляет приложения или поля L3/L4 и выбирает предпочтительные списки цветов/TLOC; при нарушении SLA происходит переключение на резерв в соответствии с политикой.
  • Советы по проектированию:
    • Избегайте слишком строгих порогов SLA, которые вызывают флаппинг (частые переключения); используйте гистерезис с помощью множителей проб и разумных пороговых значений.
    • Для приложений, чувствительных к переупорядочиванию пакетов, предпочитайте переключение при появлении нового потока (“move on next new flow”) вместо переключений в середине потока или закрепляйте потоки с помощью консистентного хеширования, где это поддерживается.
    • Когда и AAR, и политика данных устанавливают TLOC, отдавайте приоритет AAR для выбора пути, а политику данных используйте для внедрения/маркировки сервисов; избегайте пересекающихся действий для одного и того же класса трафика.

• Создание цепочек сервисов и внедрение сервисов

  • Действие “service” в политике данных направляет трафик через локальные сервисы или сервисы в колокации (межсетевой экран, IDS/IPS, сервисные узлы SD-WAN).
  • При необходимости создавайте цепочки из нескольких сервисов; обеспечьте симметричное внедрение для сервисов с отслеживанием состояния как для прямого, так и для обратного пути.
  • Компромиссы: каждый сервисный хоп добавляет задержку и потенциальный домен отказа. Внедряйте проверки работоспособности и поведение при сбое (fail-open/fail-closed) в соответствии с требованиями безопасности.

• Сегментация трафика

  • VPN обеспечивают жесткую сегментацию; централизованная политика применяется для каждого VPN с использованием списков VPN.
  • Меж-VPN маршрутизация (утечка маршрутов) может быть реализована с помощью политики данных с действием “set VPN” для определенных потоков; строго ограничивайте ее с помощью сопоставления по префиксу/приложению и часто проводите аудит.
  • Для общих сервисов (например, DNS, сервисы идентификации) анонсируйте префиксы сервисов из сервисного VPN в VPN-потребители с помощью политики управления, а не через широкие утечки на уровне данных.

Пример фрагмента app-route, иллюстрирующий управление на основе SLA:

app-route-policy CRITICAL-APPS
  sequence 10
    match application-list BUS_APPS
    sla-class GOLD
    preferred-color mpls fallback biz-internet
  !
  sequence 20
    match application-list BEST_EFFORT
    sla-class BRONZE
    preferred-color biz-internet fallback public-internet
  !
  default-action accept
!

Операции: применение, проверка и устранение неполадок

Применение политик через vSmart:

• Определите централизованные политики в vManage и примените их к спискам сайтов и спискам VPN. vSmart компилирует политику и распространяет её на устройства WAN Edge через защищённые сессии OMP по DTLS/TLS в VPN 0.
• Тщательно определяйте область применения изменений; один экземпляр политики может затронуть сотни сайтов. Используйте списки сайтов для поэтапного развёртывания по регионам или функциональным группам.

Симуляция, предварительный просмотр и поэтапное развёртывание политик:

• Предварительный просмотр: перед активацией используйте функцию предварительного просмотра в vManage для изучения скомпилированной политики для конкретного устройства (то, что получит каждый WAN Edge). Проверьте логику соответствия/действия (match/action), действия по умолчанию и направления.
• Симуляция: используйте симуляцию политик для тестирования совпадений потоков и ожидаемых действий (например, какой TLOC будет использовать данное приложение/5-tuple). Проверьте сопоставления с классами SLA и классификацию приложений.
• Поэтапное развёртывание:
  • 1. Примените политику к списку «канареечных» сайтов (несколько сайтов).
  • 2. Отслеживайте KPI уровня управления и уровня данных (количество маршрутов OMP, BFD, срабатывания app-route).
  • 3. Постепенно расширяйте список сайтов.
• Управление версиями и откат: сохраняйте предыдущие версии политик; при обнаружении непредвиденного поведения немедленно деактивируйте новую политику или выполните откат к предыдущей версии.

Отладка непреднамеренных результатов и старшинства:

• Проверка на уровне управления

  • show omp tlocs, show omp routes: подтвердите наличие/отсутствие маршрутов и TLOC в соответствии с замыслом политики.
  • show policy received/installed: проверьте счётчики политики управления и какие последовательности (sequences) сработали.
  • Симптом: филиалы (spokes) не могут связаться друг с другом после развёртывания → проверьте запрещающие строки в исходящей политике управления для филиалов и действия по умолчанию.

• Проверка на уровне данных и AAR

  • show app-route stats/flows и show bfd sessions: проверьте состояние SLA и решения о выборе пути.
  • show sdwan policy service-path или эквивалентная команда: подтвердите счётчики вставки сервисов и порядок их цепочки.
  • show ip route vpn X и traceroute vpn X: проверьте фактический путь пересылки трафика.
  • Симптом: неожиданные изменения пути/флаппинг → ослабьте требования SLA или скорректируйте множители проб; убедитесь, что перекрывающаяся политика данных также не устанавливает TLOC.

• Старшинство и конфликты политик

  • Решения AAR обычно имеют приоритет при выборе пути; используйте политику данных в основном для вставки сервисов, маркировки и контроля доступа.
  • Перекрывающиеся критерии соответствия в разных политиках могут создавать неоднозначность. Делайте домены соответствия взаимоисключающими или вводите упорядочивание и теги для устранения неоднозначности.
  • Действие «разрешить по умолчанию» может маскировать отсутствующие последовательности; добавьте явные счётчики «только для наблюдения» (например, mirror/police low) или временное логирование для проверки совпадений перед применением запретов.

• Проверка cflowd

  • show cflowd statistics/exporters: убедитесь, что экспортёры для каждого VPN активны и сэмплирование работает как задумано.
  • Высокая загрузка ЦП после включения cflowd → увеличьте интервал сэмплирования или сузьте область до самых важных VPN/приложений.

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

Компания Northwind Traders переходит на Cisco SD-WAN и должна обеспечить топологию «звезда» (hub-and-spoke) для PCI VPN, направлять трафик Office 365 по наилучшему интернет-пути и внедрить сервис регионального межсетевого экрана для гостевого трафика, не затрагивая критически важные приложения.

Подход:

1. Создание списков для политик

   • Создайте списки сайтов: HUBS (центры обработки данных), SPOKES (филиалы).
   • Создайте списки VPN: PCI_VPN, GUEST_VPN, CORP_VPN.
   • Создайте списки приложений: O365, BEST_EFFORT.
   • Создайте списки цветов: PRIVATE (mpls), DIA (biz-internet, public-internet). Обоснование: многоразовые списки обеспечивают точное определение области применения и безопасное поэтапное развёртывание; разделение VPN поддерживает сегментацию.

2. Определение классов SLA

   • GOLD: потеря 0.5%, задержка 100 мс, джиттер 20 мс.
   • SILVER: потеря 1%, задержка 150 мс, джиттер 30 мс. Обоснование: согласуйте пороговые значения с реальной производительностью транспорта, чтобы предотвратить флаппинг путей; более строгие для O365, чем для трафика best-effort.

3. Реализация политики управления для топологии hub-and-spoke в PCI

   • На входе в vSmart: маркировать маршруты, полученные от SPOKES в PCI_VPN.
   • На выходе из vSmart: для SPOKES анонсировать маршруты от HUB и маршруты по умолчанию; запретить анонсирование маршрутов PCI, исходящих от SPOKE, другим SPOKES; для HUBS анонсировать всё. Обоснование: топология принудительно задаётся на уровне управления, гарантируя, что филиалы узнают друг о друге только через центральные узлы и сохраняя сегментацию в PCI VPN.

4. Создание политики app-route для O365 и best-effort

   • Сопоставить O365 в CORP_VPN с классом SLA GOLD; предпочтительный цвет DIA с резервным PRIVATE.
   • Сопоставить BEST_EFFORT с классом SILVER; предпочтительный PRIVATE с резервным DIA. Обоснование: O365 работает лучше всего через прямой доступ в Интернет при соблюдении SLA; при необходимости переключаться на MPLS. Трафик best-effort может предпочитать MPLS из соображений стоимости/политики, допуская использование DIA в качестве резервного варианта.

5. Внедрение регионального межсетевого экрана для гостевого трафика

   • Политика данных в GUEST_VPN: вставка сервиса в цепочку регионального межсетевого экрана в обоих направлениях: прямом (от сервисной стороны к WAN) и обратном (от туннеля к сервису).
   • Убедитесь, что состояние сервиса межсетевого экрана отслеживается; определите режим fail-open (отказоустойчивости с открытием доступа) для гостевого трафика, чтобы сохранить доступность. Обоснование: инспекция с отслеживанием состояния требует симметричного прохождения трафика; двунаправленная вставка предотвращает разрывы сессий. Допустимый уровень риска для гостевого трафика позволяет использовать fail-open в случае сбоя сервиса.

6. Применение политик через vSmart с поэтапным развёртыванием

   • Примените политику управления к HUBS и «канареечному» подмножеству SPOKES в PCI_VPN.
   • Примените политики app-route и данных сначала к ограниченному региону. Обоснование: ограничивает радиус поражения (blast radius); позволяет проверить поведение политики перед глобальным развёртыванием.

7. Проверка и мониторинг

   • Просмотрите скомпилированные политики для каждого устройства; подтвердите действия по умолчанию.
   • Используйте симуляцию для тестирования примеров потоков (O365 из филиала в CORP_VPN, гостевой веб-трафик из GUEST_VPN).
   • Отслеживайте выводы команд show omp routes/tlocs (доступность в PCI), show app-route stats (путь для O365), show policy service-path (счётчики гостевого межсетевого экрана) и BFD sessions. Обоснование: подтверждает, что результаты на уровне управления и на уровне данных соответствуют проекту, и что управление трафиком на основе SLA работает как ожидалось.

8. Расширение и усиление

   • Постепенно добавляйте оставшиеся SPOKES в область применения политики управления.
   • Ужесточите гостевую политику с помощью ограничения скорости (rate limits); скорректируйте пороговые значения SLA для O365, если происходят колебания пути. Обоснование: итеративная настройка снижает операционные риски и обеспечивает стабильность работы для пользователей.

Эта последовательность чётко разделяет управление топологией (OMP) от управления трафиком на уровне данных и сервисов, использует сегментацию для защиты PCI, применяет маршрутизацию на основе SLA для приложений для повышения производительности и обеспечивает операционную безопасность за счёт предварительного просмотра, симуляции и поэтапного применения.

← Туннели плоскости данных · Все домены · Безопасность →

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