Cisco 350-401: Автоматизация, программируемость и API — Руководство по подготовке

By Laurynas Brazys · 15 August 2026 · #cisco #350-401 #certification #exam-prep #study-guide

Часть Cisco CCNP Enterprise 350-401 ENCOR — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Cisco, или пройдите тесты на время на ExamRoll.io.

Обзор

Корпоративные сети переходят от конфигурации каждого устройства в отдельности к операциям на основе контроллеров, управляемым намерениями (intent-driven) и с автоматизацией по замкнутому циклу. Программируемость предоставляет доступ к состоянию и управлению сетью через API и модели данных, в то время как инструменты, такие как Python, Ansible и Git, обеспечивают повторяемые и тестируемые рабочие процессы. Цель состоит в том, чтобы декларативно выражать желаемые результаты, чтобы контроллеры преобразовывали намерения в политики и конфигурации, измеряли результаты с помощью телеметрии и средств проверки (assurance) и устраняли отклонения автоматически или с одобрения человека. Для достижения этого необходимо понимать роли контроллеров, API и протоколы (REST, NETCONF/RESTCONF с YANG), форматы данных (JSON, XML, YAML), платформы автоматизации (Cisco DNA Center) и операционные дисциплины (идемпотентность, контроль версий, тестирование, управление рисками и откат изменений).

Контроллеры, намерения и операции по замкнутому циклу

• Сети на основе контроллеров и их роли:
  • Cisco SD-WAN разделяет плоскости (planes): vManage предоставляет единую плоскость управления; vSmart управляет плоскостью контроля и распределяет политики, которые направляют передачу данных по фабрике; vBond организует подключение новых устройств (onboarding) и может действовать как STUN-сервер для прохождения NAT. Пограничные маршрутизаторы SD‑WAN используют OMP в качестве протокола плоскости управления для связи с vSmart.
  • Cisco SD‑Access создает оверлейную сеть, которая обеспечивает логическое разделение на уровнях Layer 2 и Layer 3. Узел плоскости управления фабрики (fabric control-plane node) поддерживает глобальную базу данных сопоставления конечных точек и их местоположений, в то время как пограничный узел фабрики (fabric border node) соединяет фабрику с внешними сетями. В беспроводных сетях управление радиоресурсами (Radio Resource Management) выполняется на беспроводном контроллере.
• Намерения и декларативная конфигурация:
  • Намерение (intent) описывает желаемый результат, а не способ его реализации на каждом устройстве. Декларативные системы (например, «сегментировать гостевых пользователей везде, предоставив им доступ только в Интернет») позволяют контроллерам компилировать политику в конфигурации для конкретных устройств.
  • Компромиссы: Декларативные модели упрощают операции и уменьшают расхождения в конфигурации (drift), но могут скрывать детали реализации. Операторам необходимы прозрачные инструменты для сравнения/предпросмотра (diff/preview) и отката изменений для поддержания доверия.
• Операции по замкнутому циклу:
  • Измерение: Сбор состояния с помощью потоковой телеметрии и средств проверки (assurance) контроллера.
  • Анализ: Обнаружение отклонений от намерения (например, нарушений сегментации, падения SLA).
  • Действие: Устранение отклонений через обновление политик, изменение конфигурации или инжиниринг трафика.
  • Режимы отказа: Штормы событий или «шумная» телеметрия могут вызывать ложные срабатывания; циклы исправления могут входить в колебательный режим. Защитные механизмы (ограничение частоты, гистерезис, подтверждение человеком) и надежная корреляция предотвращают перегрузку системы (thrashing).

API, модели данных и протоколы

• REST API:
  • Методы: GET (чтение), POST (создание/действие), PUT (замена), PATCH (частичное обновление), DELETE (удаление), HEAD/OPTIONS (метаданные).
  • Коды состояния: 2xx успех (200 OK, 201 Created), 3xx перенаправления, 4xx ошибки клиента (400 неверный ввод, 401 не авторизован, 403 доступ запрещен, 404 не найдено, 409 конфликт, 429 превышен лимит запросов), 5xx ошибки сервера (500, 503).
  • Аутентификация: Basic (поверх TLS), схемы с токенами/bearer-токенами и OAuth 2.0. Всегда используйте TLS; избегайте встраивания учетных данных в URI. Обрабатывайте обновление и истечение срока действия токенов.
  • Ограничение частоты запросов: Серверы могут ограничивать запросы с кодом 429 и заголовком Retry-After. Реализуйте в клиентах экспоненциальную выдержку (exponential backoff), случайную задержку (jitter) и отслеживание бюджета запросов.
• Форматы данных и валидация:
  • JSON распространен в REST; XML остается преобладающим в NETCONF; YAML используется для файлов, создаваемых человеком (инвентаризационные файлы, плейбуки, наборы переменных). При необходимости преобразуйте YAML в JSON внутри программы.
  • Валидация по схеме: Используйте JSON Schema для данных в формате JSON; XML Schema для XML; YANG для управления на основе моделей (типы, ограничения, выражения must/when). Выполняйте валидацию на стороне клиента перед отправкой, чтобы выявлять ошибки на раннем этапе.
• NETCONF, RESTCONF, YANG, RPC и хранилища данных:
  • Модели YANG определяют структуры данных и операции для конфигурации и состояния.
  • NETCONF использует XML поверх SSH, операции, такие как , , , , , . Хранилища данных (datastores) обычно включают running и candidate; candidate позволяет выполнять подготовку и применение изменений (prepare-and-commit) с атомарностью.
  • RESTCONF сопоставляет ресурсы, смоделированные в YANG, с RESTful-интерфейсом поверх HTTP(S), используя JSON или XML со стандартизированными медиатипами. Методы сопоставляются с семантикой NETCONF (PATCH/PUT для редактирования).
  • Режимы отказа и проектирование:
    • Борьба за блокировку: Координируйте использование для избежания взаимоблокировок (deadlocks); используйте узкую область действия и тайм-ауты.
    • Частичные сбои: Для транзакционных изменений предпочитайте использовать хранилище candidate + . Если доступно только хранилище running, используйте структурированные группы изменений и контрольные точки (checkpoints).
    • Расхождение моделей: Устройства могут поддерживать разные ревизии модулей YANG; согласовывайте возможности (capabilities) и тестируйте в процессе CI.
• Краткие примеры:
  • Частичное обновление через RESTCONF (обмен по HTTP):

undefined

• NETCONF с использованием Python (ncclient):

undefined

undefined

Инструментарий и рабочие процессы: Python, Ansible, Git и пайплайны

• Автоматизация Cisco DNA Center:
  • Северные (Northbound) REST API предоставляют доступ к инвентарю, шаблонам, процессам развертывания (provisioning) и данным системы Assurance. Южные (Southbound) интерфейсы соединяют контроллер с устройствами (CLI, SNMP, NETCONF/RESTCONF) для реализации намерения.
  • Процессы обнаружения могут использовать CDP, LLDP и диапазоны IP-адресов. Используйте управление доступом на основе ролей, шаблоны на основе проектов и переменные для каждого сайта. Система Assurance сопоставляет телеметрию, формируя отчеты о проблемах, оценки работоспособности и предлагаемые исправления — ключевые данные для автоматизации с замкнутым циклом.
• Основы Python для сетевой автоматизации:
  • Ядро языка: типы данных, функции, модули, виртуальные окружения и логирование.
  • Библиотеки: requests/httpx (REST), ncclient (NETCONF), jinja2 (шаблонизация), pyyaml, json, pandas (обработка и преобразование данных), rich/logging для наблюдаемости.
  • Рекомендации: валидация входных данных, повторные попытки с экспоненциальной задержкой, структурированные исключения, тайм-ауты и модульные тесты (unit tests). Отделяйте бизнес-логику от операций ввода-вывода для упрощения тестов.
• Ansible:
  • Файл inventory определяет хосты и группы; храните host_vars/group_vars в формате YAML.
  • Playbook’и объявляют желаемое состояние; модули, такие как ios_config, ios_facts, iosxe_config, restconf_config и uri, выполняют действия. Используйте роли для инкапсуляции переиспользуемой логики.
  • Идемпотентность: модули гарантируют, что повторные запуски сходятся к результату без непреднамеренных изменений. Используйте check_mode и diff для предварительного просмотра; уведомляйте обработчики (handlers) для сохранения конфигурации только при наличии изменений.
  • Пример:
    • hosts: edge connection: network_cli gather_facts: no tasks:
      • ios_config: parents: interface GigabitEthernet1 lines: - description Uplink notify: save handlers:
      • name: save ios_config: save_when: changed
  • Управление изменениями: используйте окна обслуживания, последовательную или пакетную стратегию развертывания и ограничение скорости применения изменений для каждого сайта, чтобы ограничить зону влияния сбоя. Автоматически собирайте данные проверок до и после изменений.
• Git, управление версиями, тестирование и пайплайны:
  • Храните сетевое намерение (переменные YAML, шаблоны Jinja, playbook’и), сгенерированные конфигурации и тесты в Git. Используйте ветки, пул-реквесты и ревью кода. Семантические коммиты и теги позволяют связать версии с развертываниями.
  • Тестирование: проверяйте (линтите) YAML и playbook’и, валидируйте схемы YANG/JSON, запускайте модульные тесты и сценарные тесты Ansible Molecule. Интегрируйте синтетические предварительные проверки (например, сетевой доступности) в CI.
  • Пайплайны: Dev → тестовая среда/лаборатория → канареечное развертывание в production → поэтапное развертывание. Контрольные точки (gates) включают статический анализ, пробные запуски (dry-runs) на симуляторах, согласования и автоматический откат при ухудшении показателей работоспособности.

Телеметрия, событийно-ориентированная автоматизация и управление рисками

• Потоковая передача телеметрии:
  • Модельно-ориентированная телеметрия (IOS XE, NX-OS) публикует состояние, смоделированное с помощью YANG, с заданными интервалами через gRPC/gNMI или NETCONF, используя подписки dial-in или dial-out. Преимущества включают низкую задержку и структурированные данные, что превосходит периодический сбор данных через CLI (scraping) или опрос по SNMP.
  • Пример (IOS XE, кратко): telemetry ietf subscription 100 encoding gpbid filter xpath /interfaces-state/interface receiver ip 10.0.0.50 port 57500 protocol grpc-tcp
  • Советы по проектированию: согласуйте частоту выборки с вариантом использования; обеспечьте достаточную пропускную способность шины сообщений; спроектируйте конвейеры для понижения частоты дискретизации (downsampling) и агрегации; защититесь от потери телеметрии с помощью буферизации и подтверждений.
• Событийно-ориентированная автоматизация:
  • Запускайте действия по веб-хукам, сообщениям syslog, SNMP-ловушкам (traps), событиям DNA Center или темам Kafka. Используйте корреляцию и ограничение частоты запросов (rate limiting), чтобы избежать колебаний состояния (flaps), вызванных штормом событий. Поддерживайте идемпотентные обработчики, которые можно безопасно перезапускать.
  • Замкнутый контур: контроллер обнаруживает нарушение политики, проверяет его с помощью вторичных сигналов, открывает заявку на изменение или запускает ограниченное исправление, затем повторно измеряет параметры и завершает процесс.
• Управление рисками, откат изменений и учетные данные:
  • Защитные механизмы: поэтапное развертывание, ограничения параллелизма, контроль радиуса поражения (blast radius), динамическое увеличение пауз (backoff) при ответах 429/5xx и тайм-ауты. Используйте транзакции, где это возможно (NETCONF candidate + commit), или контрольные точки конфигурации устройств и команду configure replace.
  • Откат изменений: поддерживайте эталонные конфигурации, файлы различий (diffs) и контрольные точки для каждого устройства. Предпочитайте семантику commit-confirmed, если она поддерживается; в противном случае реализуйте автоматический возврат к предыдущему состоянию с помощью таймеров и проверок доступности.
  • Защита учетных данных: применяйте RBAC, короткоживущие токены и секреты, предоставляемые по принципу JIT (just-in-time) для каждого задания. Используйте хранилища секретов (например, Ansible Vault или внешнее хранилище), никогда не встраивайте секреты в плейбуки или Git. Ротируйте учетные данные по расписанию и после кадровых изменений. Защищайте учетные данные для доступа от контроллера к устройствам и проводите аудит доступа.

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

Компания Aurelius Logistics планирует стандартизировать конфигурации кампусных и филиальных сетей, обеспечить согласованную сегментацию и внедрить систему гарантии качества с обратной связью (closed-loop assurance) с помощью Cisco DNA Center, а также обеспечить безопасное внесение изменений через Ansible и Git.

1. Сбор базовых показателей и обнаружение сети

• Обоснование: Обнаружение в DNA Center с использованием диапазонов IP-адресов, а также протоколов CDP/LLDP, позволяет составить перечень устройств и топологии, создавая авторитетный инвентарный список. Это дает возможность определять область применения намерений и наследовать переменные по площадкам. Сбор данных для системы Assurance формирует базовые показатели состояния сети до внесения изменений, которые используются для сравнения и как триггеры для отката.

2. Моделирование намерений и шаблонов в DNA Center

• Обоснование: Декларативно опишите сегментацию (например, для сотрудников, IoT, гостей) и политики QoS. Используйте параметризованные шаблоны с переменными для площадок для настройки интерфейсов, маршрутизации и ACL. Декларативный подход к политикам позволяет контроллеру компилировать конфигурации для конкретных устройств, уменьшая количество человеческих ошибок и расхождений конфигурации (drift).

3. Внедрение управления конфигурацией на основе Git

• Обоснование: Храните шаблоны, переменные для площадок (YAML) и тесты для валидации в Git. Ветки для новой функциональности (feature branches) и запросы на слияние (pull requests) обеспечивают обязательную проверку кода коллегами (peer review). Теги связывают развертывания с версиями, что позволяет выполнять точный откат. Это обеспечивает аудируемую историю изменений и поддерживает автоматический запуск конвейеров.

4. Построение CI/CD-конвейера с этапами валидации

• Обоснование: Этапы конвейера включают проверку синтаксиса (linting) YAML, валидацию данных в форматах JSON/YANG, модульное тестирование рендеринга Jinja и симуляцию вызовов API в изолированной среде (песочнице). Пробные запуски (dry run) в DNA Center и режимы check_mode/diff в Ansible проверяют изменения без их реального применения. Только после успешного прохождения всех этапов конвейер запрашивает у оператора подтверждение на продолжение.

5. Инкрементальное развертывание с помощью Ansible и API DNA Center

• Обоснование: Используйте northbound API DNA Center для применения шаблонов сначала на тестовой площадке (canary site), а затем последовательно развертывайте их по остальным площадкам с ограничением размера пакета (batch size). Для устройств, поддерживающих NETCONF/RESTCONF, модули Ansible выполняют целевые, идемпотентные обновления. Такой двойной подход позволяет использовать контроллер для задач, связанных с применением политик, и прямую автоматизацию устройств для гранулярных изменений, минимизируя при этом радиус поражения (blast radius).

6. Активация потоковой телеметрии и проверок на основе Assurance

• Обоснование: Настройте модельно-ориентированную телеметрию на пограничных устройствах для передачи данных в DNA Center Assurance и в стек наблюдаемости (observability) компании. Определите SLO (целевые показатели уровня обслуживания), например, процент успешного подключения устройств, задержку, и подписки на события, которые будут генерировать оповещения, если метрики после изменения ухудшаются. Это позволяет немедленно обнаруживать негативные последствия.

7. Включение контролируемого автоматического исправления (closed-loop remediation)

• Обоснование: Для хорошо изученных отклонений (например, падение интерфейса с известным способом решения проблемы) разрешите конвейеру запускать ограниченный плейбук для отмены последнего изменения или применения срочного исправления (hotfix). Для более масштабных исправлений требуйте подтверждения от человека. Внедрите экспоненциальную выдержку (exponential backoff) и периоды затишья (cooldown) для предотвращения колебаний (осцилляций).

8. Подготовка и тестирование путей отката

• Обоснование: Перед каждым изменением создавайте контрольные точки конфигурации устройств или используйте NETCONF candidate + commit-confirmed, если это возможно. Архивируйте конфигурации до внесения изменений и ставьте тег в репозитории Git. Если показатели состояния ухудшаются или телеметрия показывает нарушения SLA, конвейер выполняет configure replace или NETCONF discard/rollback, быстро восстанавливая предыдущее состояние.

9. Защита учетных данных и принудительное применение контроля доступа

• Обоснование: Храните учетные данные устройств/контролле

← Корпоративная безопасность и сервисы идентификации · Все домены · Обеспечение качества работы сети →

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