Cisco 200-301: WAN, автоматизация, виртуализация и эксплуатация сетей — Руководство по подготовке

By Laurynas Brazys · 14 August 2026 · #cisco #200-301 #certification #exam-prep #study-guide

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

Обзор

Глобальные подключения, виртуализация и автоматизация объединились, чтобы изменить подходы предприятий к построению, эксплуатации и защите сетей. Современные архитектуры сочетают транспортный уровень (underlay) (выделенные линии, Metro Ethernet, широкополосный доступ и сотовая связь) с наложенными сетями (overlay) (VPN, GRE или SD-WAN) для обеспечения предсказуемой пересылки трафика на основе политик. Виртуальная маршрутизация и пересылка (VRF) обеспечивает сегментацию, а контроллеры, такие как Cisco DNA Center и оркестраторы SD-WAN, централизуют управление на основе намерений и оптимизируют внесение изменений. Программируемые интерфейсы и инструменты, такие как REST API, Ansible и Python, позволяют выполнять повторяемые, тестируемые и проверяемые операции. Надежные эксплуатационные практики, включая контроль изменений, резервное копирование, управление образами ПО, аварийное восстановление и структурированный поиск неисправностей, связывают решение воедино и сокращают среднее время восстановления.

Подключения к WAN и инкапсуляция

Выбор транспорта для WAN — это баланс между стоимостью, производительностью, отказоустойчивостью и сложностью эксплуатации.

• Выделенные линии (T1/E1, T3/E3, OC или Ethernet private line): Выделенные каналы точка-точка с предсказуемой задержкой и строгими SLA. Плюсы: детерминированная производительность, простая маршрутизация. Минусы: высокая стоимость, более медленное развертывание.
• Metro Ethernet: Провайдерские Ethernet-сервисы (E-Line, E-LAN, E-Tree) по оптоволокну, обычно со скоростью 10/100/1000 Мбит/с и выше. Плюсы: масштабируемая пропускная способность, прозрачность QoS с классами обслуживания провайдера, более простые стыки. Минусы: топология и QoS могут различаться у разных операторов; возможны ограничения на изучение MAC-адресов при растянутом L2.
• Широкополосный доступ (DSL, кабель, FTTH): Интернет-доступ по принципу best-effort (без гарантий качества) с асимметричными или симметричными скоростями. Плюсы: недорого, быстрое развертывание, широкая доступность. Минусы: переменная задержка и джиттер; требуются наложенные сети (IPsec/GRE/SD-WAN) для сегментации и шифрования.
• VPN: Наложенные сети поверх недоверенных сетей. Site-to-site IPsec защищает трафик; DMVPN добавляет динамическое взаимодействие между филиалами (spoke-to-spoke); удаленный доступ на основе TLS масштабируется для пользователей. Плюсы: шифрование и независимость связности от транспортного уровня (underlay). Минусы: проблемы с MTU/фрагментацией, дополнительная нагрузка от шифрования, зависимость от стабильности Интернета.
• Сотовая связь (4G/LTE/5G): Основной или резервный транспорт с быстрым развертыванием. Плюсы: настоящее разнесение путей для резервирования «последней надежды», быстрый ввод в эксплуатацию. Минусы: переменная производительность, ограничения по объему трафика, проблемы с CGNAT.

Базовые инкапсуляции соединяют маршрутизаторы через эти транспортные сети:

• HDLC: По умолчанию на многих последовательных интерфейсах Cisco. Облегченное кадрирование, по умолчанию проприетарный протокол Cisco; нет аутентификации.
• PPP: Стандартизированная инкапсуляция для последовательных интерфейсов или PPPoE для Ethernet. Поддерживает сообщения keepalive протокола LCP, аутентификацию CHAP/PAP, Multilink PPP (MLPPP) и IPCP для настройки параметров IP. Компромисс: немного больше служебных данных, чем у HDLC, но добавляет совместимость и функциональность.

Пример — PPP с CHAP:

undefined

• GRE: Облегченный туннель для инкапсуляции других протоколов в IP, создающий логическую смежность. GRE не шифрует трафик; используйте его в паре с IPsec для обеспечения конфиденциальности и целостности. Следите за MTU; GRE добавляет 24 байта, IPsec — еще больше.

Пример — GRE-туннель через Интернет:

undefined

Распространенные сбои и способы защиты:

• Несовпадение инкапсуляции (PPP и HDLC) препятствует установлению соединения. Проверяйте вывод команды

undefined

, настройки инкапсуляции и состояния LCP.

• Проблемы с MTU/фрагментацией при использовании GRE/IPsec/PPPoE приводят к «черным дырам». Используйте правильные значения

undefined

и

undefined

; проверяйте с помощью PMTUD и доступности по ICMP.

• Несовпадение секретных ключей CHAP или имен хостов блокирует аутентификацию PPP. Синхронизируйте учетные данные и проверяйте с помощью команды

undefined

.

• Широкополосный доступ с CGNAT может нарушить работу IPsec, если не разрешены NAT-T и UDP 4500; проверьте доступность порта.

Виртуализация, оверлеи/андерлеи и SD-WAN

Сетевая виртуализация отделяет логические сети от физического транспорта для обеспечения сегментации, мультитенантности и гибкой пересылки трафика.

• VRF (VRF-Lite без MPLS или с MPLS в ядрах провайдеров): несколько таблиц маршрутизации на одном устройстве. Каждый VRF изолирует интерфейсы, маршруты и политики. Избегайте утечек маршрутов, используя явные политики route-target в развертываниях MPLS или статическую/пограничную фильтрацию в VRF-Lite.

Пример — простой VRF-Lite:

undefined

• Андерлей и оверлей: андерлей обеспечивает IP-связность между узлами (например, через ISP, MetroE, MPLS). Оверлеи (GRE, IPsec, VXLAN, фабрика SD-WAN) переносят трафик тенантов или сегментированный трафик. Работайте с каждым уровнем независимо, чтобы упростить поиск и устранение неисправностей — сначала тестируйте андерлей (ping между конечными точками туннеля), затем оверлей (ping через туннель).

SD-WAN дополняет оверлеи централизованным управлением и политиками:

• Компоненты: пограничные маршрутизаторы формируют зашифрованные туннели плоскости данных; контроллеры включают в себя оркестратор (для подключения устройств/обхода NAT), плоскость управления (обмен маршрутами и политики безопасности) и плоскость менеджмента (GUI/API, шаблоны, мониторинг). Сертификаты устанавливают взаимное доверие и обеспечивают автоматическую настройку (zero-touch provisioning).
• Пересылка на основе политик: маршрутизация с учетом приложений (application-aware) направляет потоки на основе метрик SLA (потери, задержка, джиттер), DSCP и бизнес-требований. Политики данных (сервисные цепочки, NAT), политики управления (анонсирование/принятие маршрутов) и политики безопасности (FW/IDS) применяются согласованно.

Обоснование проектных решений и компромиссы:

• Двойные или множественные транспортные сети (MPLS, Интернет, LTE) повышают доступность и экономическую эффективность; контроллеры постоянно проверяют пути и выбирают лучшие каналы для каждого приложения. Компромисс: повышенная сложность в проектировании политик и мониторинге.
• Централизованное управление снижает количество ошибок в конфигурации, но чувствительно к доступности контроллеров и жизненному циклу сертификатов. Размещайте резервные контроллеры на разных площадках и отслеживайте состояние управляющих соединений.
• Асимметричная маршрутизация может возникать, когда приложения направляются по-разному в каждом направлении; убедитесь, что обратный трафик учитывает устройства с отслеживанием состояния (stateful) или используйте симметричные политики.

Распространенные режимы отказа SD-WAN:

• Рассинхронизация сертификатов/времени препятствует установлению управляющих соединений. Используйте NTP и отслеживайте срок действия сертификатов.
• Проблемы с обходом NAT за строгими межсетевыми экранами. Проверьте необходимые порты UDP/TCP и механизмы отката.
• Неправильный порядок политик может случайно отбрасывать префиксы или неверно классифицировать приложения. Тестируйте на стенде и используйте счетчики совпадений/логирование для подтверждения срабатываний.

Автоматизация, Cisco DNA Center и программируемость

Сети, управляемые намерениями (Intent-based networking), кодифицируют желаемые результаты в политики и автоматизируют их применение с проверкой.

Концепции Cisco DNA Center (DNAC):

• Инвентаризация и топология: обнаруживает устройства через SNMP/CLI/API, строит топологию и хранит атрибуты аппаратного/программного обеспечения.
• Автоматизация: предоставление ресурсов на основе шаблонов, управление образами, подключение устройств (Plug and Play) и рабочие процессы программно-определяемого доступа.
• Assurance (Гарантия качества): оценки состояния клиентов, устройств и приложений на основе телеметрии; базовые показатели и обнаружение аномалий ускоряют анализ первопричин.
• Политики: преобразование намерений (сегментация, QoS, контроль доступа) в развертываемые конфигурации с проверками на соответствие.

REST API и кодирование данных:

• Методы HTTP: GET (получить), POST (создать), PUT/PATCH (заменить/изменить), DELETE (удалить). GET является идемпотентным; учитывайте идемпотентность при повторных попытках.
• Форматы данных: JSON является стандартом де-факто; YAML/TOML могут встречаться в инструментах, но REST API обычно обмениваются данными в формате JSON. Используйте UTF-8 и правильные заголовки Content-Type/Accept.
• Аутентификация: Basic-аутентификация проста, но небезопасна без TLS; предпочтительна аутентификация на основе токенов (ключи API или JWT); OAuth 2.0 обеспечивает делегированную авторизацию. Всегда используйте TLS, проверяйте сертификаты и обрабатывайте обновление токенов.
• Коды состояния: 200/201 для успеха, 202 для асинхронных операций, 400/404 для ошибок клиента, 401/403 для сбоев аутентификации/авторизации, 429 для превышения лимитов запросов, 5xx для ошибок сервера. Реализуйте механизм отсрочки (backoff) для кодов 429/5xx.

Пример — полезная нагрузка JSON для переменной в шаблоне интерфейса:

undefined

Управление конфигурациями и автоматизация инфраструктуры:

• Контроль версий: храните конфигурации, шаблоны и плейбуки в Git. Используйте ветки и pull-запросы для рецензирования и ведения аудиторского следа.
• Идемпотентность: инструменты применяют желаемое состояние без повторных изменений; это повышает предсказуемость и соответствие требованиям.
• Инвентаризация и шаблонизация: структурируйте инвентарные списки хостов/групп и параметризируйте конфигурации с помощью Jinja2. Поддерживайте «золотые» конфигурации и проверки на соответствие.
• Управление секретами: защищайте учетные данные и ключи с помощью хранилищ (vaults) или абстракций окружения; избегайте хранения их в открытом виде в репозиториях.
• CI/CD для сети: проверяйте (lint) конфигурации, симулируйте политики, запускайте юнит-тесты для шаблонов и развертывайте изменения поэтапно с предварительными и последующими проверками.

Сценарии использования Ansible и Python:

• Ansible: быстрое внесение изменений на множество устройств, обновление образов, настройка интерфейсов/VRF и проверки на соответствие с помощью сетевых модулей. Пример фрагмента плейбука:

undefined

• Python: ситуативные скрипты, интеграции с API и пользовательские проверки. Используйте библиотеку requests для вызовов REST или другие библиотеки для работы с сетевым CLI. Пример концепции:

undefined

Эксплуатация, надежность и устранение неполадок

Дисциплинированный подход к эксплуатации снижает риски и увеличивает время безотказной работы.

Управление изменениями:

• Определяйте область применения, риски, план отката, тесты для проверки и временные рамки. Требуйте экспертной оценки (peer review) и поэтапного развертывания (лаборатория → пилотный проект → поэтапное внедрение).
• Окна обслуживания и уведомления клиентов задают ожидания. Используйте подробный план работ (method of procedure) с четкими контрольными точками.

Резервное копирование и управление образами:

• Ежедневное резервное копирование running-config, startup-config и критически важных баз данных контроллеров. Проверяйте резервные копии путем периодического восстановления в лабораторной среде.
• «Золотые образы» и каталоги образов, соответствующие аппаратному обеспечению и требуемым функциям. Предварительно загружайте образы в периоды низкой нагрузки; рассмотрите возможность использования ISSU, если поддерживается, для минимизации времени простоя.
• Проверяйте контрольные суммы MD5/SHA и цифровые подписи; отслеживайте примечания к выпускам и сервисные бюллетени (field notices).

Аварийное восстановление:

• Внеполосное управление (out-of-band) и консольный доступ для неработоспособных устройств.
• Резервные контроллеры и хранение резервных копий на удаленной площадке. Документируйте и периодически отрабатывайте сценарии восстановления (runbooks).
• Для SD‑WAN и DNAC экспортируйте ключи/сертификаты и поддерживайте в актуальном состоянии процедуры повторного развертывания контроллеров.

Систематическое устранение неполадок:

• Определите проблему и ее влияние; по возможности воспроизведите ее.
• Установите базовый уровень: сравните текущие показатели CPU, памяти, счетчиков интерфейсов, записей потоков и задержки с историческими нормами. Изменения с момента последнего известного рабочего состояния являются главными «подозреваемыми».
• Изолируйте проблему по уровням OSI и по сетям (underlay vs overlay). Сначала проверьте физический/канальный уровень, затем IP-связность, затем уровень управления (маршрутизация/OMP), затем уровень данных (ACL/NAT/QoS) и, наконец, приложение.
• Сформулируйте гипотезы, проверяйте их минимальными изменениями и используйте целенаправленный сбор данных: захват пакетов, отладочную информацию (debugs) или телеметрию. Избегайте беспорядочных изменений.

Анализ первопричин (RCA):

• Задокументируйте хронологию событий, причинно-следственную цепочку и сопутствующие факторы. Различайте триггер и основную причину (например, истечение срока действия сертификата вызвало потерю управления, потому что отсутствовали пороговые значения для мониторинга).
• Внедряйте корректирующие и предупреждающие действия: мониторинг, обновление сценариев (runbooks), стандарты конфигурации и обучение.

Распространенные эксплуатационные ошибки:

• Отклонения от «золотых» конфигураций со временем; решается с помощью проверок на соответствие и автоматического исправления.
• Несогласованные пересечения политик в SD‑WAN или ACL, приводящие к непреднамеренной отбраковке трафика; решается с помощью централизованного анализа политик и проверки счетчиков срабатываний.
• Неэффективный мониторинг задержки/джиттера для критически важных приложений; решается с помощью активных проб и SLO, привязанных к системе оповещений.

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

Компания BluePeak Manufacturing заменяет дорогостоящие каналы MPLS на два интернет-канала с резервированием через LTE в 40 филиалах, одновременно внедряя сегментацию на основе VRF и централизованную автоматизацию.

1. Построить underlay-сеть и проверить связность.

• Обоснование: Для надежной overlay-сети требуется стабильная IP-связность между граничными устройствами WAN. Закажите услуги двух интернет-провайдеров для каждого филиала, подключите их к разным WAN-портам маршрутизатора и настройте LTE в качестве третьего резервного канала. Проверьте связность с помощью команд ping и traceroute между публичными IP-адресами, подтвердите корректность работы NAT и убедитесь, что ICMP не фильтруется для поддержки PMTUD.

2. Развернуть контроллеры SD‑WAN и зарегистрировать граничные устройства.

• Обоснование: Централизованное управление позволяет применять политики, основанные на намерениях (intent-driven). Разверните резервированные узлы оркестрации, управления и менеджмента; интегрируйте корпоративную PKI или используйте встроенные сертификаты. Используйте автоматическую настройку (zero-touch provisioning) для безопасного подключения граничных устройств за NAT, проверяя синхронизацию времени для предотвращения сбоев с сертификатами.

3. Определить VRF и сегментировать трафик.

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

  ip vrf PROD ip vrf GUEST interface GigabitEthernet0/1 ip vrf forwarding PROD interface GigabitEthernet0/2 ip vrf forwarding GUEST

4. Создать политики, учитывающие приложения, и пробы для контроля SLA.

• Обоснование: Направлять трафик критически важных приложений по наилучшему пути. Настройте пробы для измерения потерь/задержки/джиттера для каждого транспортного канала и определите политики: отправлять трафик ERP через интернет-канал с наименьшей задержкой с переключением на VPN, эквивалентный MPLS, при превышении пороговых значений; трафик гостевого VRF принудительно направлять только через самый дешевый широкополосный канал. Включите симметричную маршрутизацию для обратного трафика там, где используются сервисы с отслеживанием состояния (stateful).

5. Решить проблему MTU и фрагментации для overlay-сетей.

• Обоснование: Предотвратить «черные дыры», возникающие из-за служебных заголовков GRE/IPsec. Установите ip mtu и TCP MSS adjust на туннельных интерфейсах, где это необходимо, подтвердите работу PMTUD с помощью ping-запросов с установленным флагом DF и убедитесь, что межсетевые экраны провайдеров пропускают сообщения ICMP type 3 code 4.

6. Автоматизировать базовую настройку с помощью Ansible и шаблонов.

• Обоснование: Обеспечить единообразие и скорость. Храните инвентарные данные устройств и переменные в Git, создайте шаблоны Jinja2 для VRF, интерфейсов и QoS и применяйте их с помощью идемпотентных плейбуков. Выполняйте предварительную проверку наличия образов и поcле развертывания проверяйте установление соседства в протоколах маршрутизации и срабатывание политик.

7. Интегрировать Cisco DNA Center для контроля состояния и управления образами.

• Обоснование: Непрерывный мониторинг состояния и стандартизированное ПО сокращают количество инцидентов. Импортируйте устройства в инвентарную базу, включите телеметрию, установите «золотые образы» для каждой платформы, запланируйте поэтапные обновления и автоматически устраняйте отклонения от «золотых» конфигураций.

8. Обеспечить безопасность и мониторинг с помощью API.

• Обоснование: Программный доступ масштабирует эксплуатацию. Используйте аутентификацию на основе токенов для запроса состояния устройств, статуса политик и SLA. Реализуйте механизм экспоненциальной выдержки (backoff) для ответов с кодом 429 и настройте оповещения об истечении срока действия сертификатов контроллера и о сбоях на уровне управления (control-plane).

9. Выполнить управление изменениями и переключение в несколько этапов.

• Обоснование: Минимизировать риски. Запустите пилотный проект в трех филиалах, отслеживайте производительность приложений и соответствие политикам, затем внедряйте изменения поэтапно, имея планы отката на MPLS. Поддерживайте внеполосный доступ (out-of-band) во время переключения.

10. Проверить, задокументировать и провести анализ первопричин (RCA).

• Обоснование: Подтвердить успех и извлечь уроки. Сравните задержку/джиттер после переключения с базовыми показателями, проанализируйте ошибки и потери на интерфейсах и соберите метрики пользовательского опыта. При любых отклонениях сначала трассируйте underlay-сеть, затем пути в overlay-сети, корректируйте политики и документируйте результаты для улучшения шаблонов и сценариев (runbooks).

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

← Сетевая безопасность и контроль доступа · Все домены

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