Cisco 350-401: IP-сервисы, многоадресная передача и качество обслуживания — Руководство по подготовке

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

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

Обзор

IP-сервисы, многоадресная рассылка (multicast) и QoS составляют операционное ядро корпоративной сети. Базовые сервисы, такие как DHCP, DNS, NTP, и телеметрия управления обеспечивают работу конечных точек и операторов; NAT обеспечивает разделение адресных пространств и границ безопасности; QoS сохраняет качество обслуживания для приложений реального времени; multicast масштабирует доставку по схеме «один ко многим»; а активный мониторинг с помощью IP SLA и отслеживания объектов (object tracking) замыкает контур отказоустойчивости. В этом разделе объясняются принципы проектирования и эксплуатации каждого из них, с акцентом на режимы отказа и компромиссные решения.

Базовые IP-сервисы и телеметрия

DHCP: Централизованно предоставляйте адреса и опции, обеспечивая масштабируемость и корректность работы ретрансляторов (relay).

• Ретрансляция и обработка опций: Используйте ip helper-address на интерфейсе первого хопа для преобразования широковещательных запросов клиентов в одноадресные пакеты до DHCP-сервера. Включайте только необходимые UDP-хелперы (например, 67/68 для DHCP, 53 для DNS, 69 для TFTP, 161 для SNMP), чтобы ограничить шумовой трафик. Опция 43 предоставляет точкам доступа CAPWAP адреса WLC; Опция 82 (информация о ретрансляторе) добавляет идентификаторы канала (circuit identifiers) для применения политик и резервирования на уровне портов. Продуманно доверяйте или удаляйте Опцию 82 — коммутаторы уровня доступа обычно вставляют ее, а вышестоящие устройства не должны ее перезаписывать.
• Модели выделения адресов: Динамический пул с резервированием для MAC-адресов или ID клиентов инфраструктуры, статические привязки для критически важной инфраструктуры и короткое время аренды для пулов с высокой мобильностью или VPN. Учитывайте утилизацию подсети и используйте разделение области (split-scope) или отказоустойчивость DHCP (failover) для повышения надежности.
• Поиск и устранение неисправностей: Сначала проверьте доступность на L2 и конфигурацию VLAN, затем доступность ретранслятора и заполнение поля giaddr. В Cisco IOS используйте show ip dhcp binding, show ip dhcp server statistics и, с осторожностью, debug ip dhcp server events. Распространенные сбои включают отсутствие helper-address на SVI, блокировку Опции 82 межсетевым экраном или исчерпание пула адресов.

DNS: Развертывайте избыточные, поддерживающие anycast резолверы рядом с пользователями. Используйте записи split-horizon для внутренних сервисов. Кэшируйте данные как можно ближе к клиентам для снижения задержки. Обеспечьте безопасность с помощью валидации DNSSEC и ограничьте рекурсию только для внутренних подсетей.

NTP: Синхронизация времени защищает журналы, Kerberos и сертификаты. NTPv4 добавляет расширения безопасности и использует site-local IPv6 multicast для обнаружения в локальных сетях. Проектируйте систему как минимум с двумя вышестоящими источниками (публичными или корпоративными stratum-1/2) и распределяйте время через внутренние серверы stratum-3. Предпочитайте аутентификацию (симметричные ключи или NTS) и избегайте прямого обращения каждого узла к NTP-серверам в интернете; направляйте инфраструктуру на локальные NTP-серверы.

Плоскость управления и телеметрия:

• SNMP: Предпочитайте SNMPv3 для аутентификации/конфиденциальности; минимизируйте интервалы опроса; группируйте OID по ролям. Ограничивайте доступ к SNMP с помощью ACL и Control Plane Policing (CoPP) для защиты от перегрузки и злоупотреблений. Отправку traps/informs следует ограничивать по частоте (rate-limit).
• Syslog: Используйте надежный транспорт, где это поддерживается, и отправляйте журналы как минимум на два сборщика. Нормализуйте уровни важности (severity, 0–7) и временные метки через NTP. Внедрите парсинг для ключевых событий (колебания состояния линков, изменения маршрутов, события безопасности).
• NetFlow/IPFIX: Экспортируйте только необходимые поля; используйте сэмплирование на высокоскоростных каналах. Обеспечьте достаточную емкость сборщика и контроль конфиденциальности. Предпочитайте IPFIX для вендорно-нейтральной расширяемости.
• Model-driven telemetry: Потоковая передача данных на основе моделей YANG (gNMI/NETCONF dial-in/out) с фиксированными интервалами; это обеспечивает меньшую задержку и большую эффективность, чем массовый сбор данных по SNMP. Согласуйте сбор данных с SLI/SLO (например, отброшенные пакеты, глубина очереди, загрузка CPU, память, частота изменений маршрутов).

NAT: статический, динамический, PAT и проверка

NAT обеспечивает независимость адресного пространства, применение политик и миграцию при пересечении IP-адресов. Выбирайте простейшую конструкцию, отвечающую требованиям.

• Статический NAT: Один к одному, детерминированный. Используйте для входящих сервисов, VoIP-шлюзов и IPsec-пиров, которым требуется стабильный идентификатор. Недостаток: расходует публичные IP-адреса.
• Динамический NAT (пул): Сопоставление «многие к меньшему» с временным выбором из пула для клиентов, инициирующих только исходящие соединения. Ответный трафик должен направляться на устройство NAT; асимметрия нарушает сессии.
• PAT (перегрузка): Сопоставление «многие к одному» с использованием уникальных портов TCP/UDP на одном IP-адресе (или нескольких). Чрезвычайно эффективно, но может исчерпать порты при большом количестве одновременных соединений; распределяйте PAT между несколькими адресами на высоконагруженных пограничных устройствах.
• Hairpin NAT и двойной NAT: Требуется, когда внутренние хосты должны обращаться к внутренним сервисам по их публичному адресу или когда необходимо преобразовать и адрес источника, и адрес назначения. Тщательно проверяйте соответствие политик и маршрутов.
• Порядок операций и VRF: Убедитесь, что NAT выполняется на правильном этапе относительно ACL, ZBFW и PBR. Для архитектур с VRF применяйте правила NAT для каждого VRF и подтверждайте утечку маршрутов (route-leaking) для обратного трафика.
• Высокая доступность: Stateful NAT обязателен для бесшовного переключения; в противном случае используйте детерминированный статический NAT на обоих пирах с резервированием первого хопа (first-hop redundancy) и будьте готовы к потере сессий для потоков dynamic/PAT.
• Проверка и устранение неисправностей: show ip nat translations и statistics, проверяйте счетчики срабатываний (hit counters) в ACL, верифицируйте маршруты к/от внешней сети NAT. Используйте debug с осторожностью; захват пакетов часто безопаснее. Следите за исчерпанием портов, пересечением пулов и асимметричной маршрутизацией.

Краткий пример: ip access-list standard NAT_INSIDE permit 10.10.0.0 0.0.255.255 ip nat pool PUBLIC 198.51.100.10 198.51.100.14 netmask 255.255.255.248 ip nat inside source list NAT_INSIDE pool PUBLIC overload interface Gig0/0 ip nat inside interface Gig0/1 ip nat outside

QoS: Классификация, маркировка, очереди и управление перегрузками

Сквозной (End-to-end) QoS сохраняет производительность в условиях конкуренции за ресурсы; проектируйте границу доверия и поведение при пересылке согласованно на уровнях доступа, распределения, в WAN и центрах обработки данных.

• Классификация и маркировка: Классифицируйте на границе сети; доверяйте только способным к этому устройствам. Типичная граница доверия — это порт коммутатора доступа к IP-телефону (доверять CoS/DSCP от телефона, а не от подключенного ПК) и к устройствам инфраструктуры. Используйте NBAR или ACL для классификации при отсутствии маркировки. Перемаркировывайте несоответствующий трафик на границе.
• DSCP и CoS: DSCP EF (46) для голосового трафика, CS3 для сигнализации вызовов, AF41 для интерактивного видео, AF31/AF32 для критически важных данных, CS1 для “мусорного” трафика (scavenger). Сопоставляйте DSCP с поведением на каждом хопе (per-hop behaviors) и с L2 CoS для транков.
• Очереди и планирование: Используйте LLQ для трафика со строгим приоритетом (EF) с ограничением пропускной способности (policed bandwidth cap) для предотвращения “голодания” других очередей. Используйте CBWFQ для гарантированных классов с минимальными гарантиями пропускной способности. Проверяйте сопоставления аппаратных очередей с DSCP для каждой платформы.
• Шейпинг и полисинг: Применяйте шейпинг на исходящем трафике (egress) до согласованной скорости CIR, чтобы сгладить всплески (особенно в сторону WAN). Применяйте полисинг на входящем трафике (ingress) для принудительного соблюдения лимитов арендатора или класса; помните, что полисинг добавляет потери и потенциально может изменить порядок пакетов, если не применять его с осторожностью.
• Предотвращение перегрузок: WRED отбрасывает пакеты заблаговременно на основе средней глубины очереди и DSCP, защищая интерактивные потоки за счет эластичных объемных потоков. Не включайте WRED на очередях со строгим приоритетом. Tail-drop остается для классов, где WRED не дает преимуществ или не поддерживается аппаратно.
• SLA для голоса/видео: Односторонняя задержка ≤150 мс, джиттер ≤30 мс, потери ≤1% для голоса; интерактивное видео немного более терпимо к потерям, но так же чувствительно к вариации задержки. Рассчитывайте пропускную способность для EF на основе скоростей кодеков плюс заголовки, VAD и запас на рост; ограничивайте LLQ, чтобы защитить другие классы. Для TelePresence/интерактивного видео выделяйте AF41 с соответствующей минимальной пропускной способностью и шейпингом на низкоскоростных каналах.
• Проверка: Используйте команду show policy-map interface для подтверждения счетчиков классов, отбросов и соответствия шейпингу. Отслеживайте глубину очереди интерфейса и причины отбросов; корректируйте пропускную способность и пороговые значения на основе измеренной утилизации, а не заявленных пиковых скоростей канала.

Краткий пример LLQ: class-map match-any VOICE match dscp ef class-map match-any VIDEO match dscp af41 policy-map WAN-QOS class VOICE priority percent 10 police rate percent 10 conform-action transmit exceed-action drop class VIDEO bandwidth percent 20 random-detect dscp-based class class-default fair-queue random-detect interface Serial0/0/0 service-policy output WAN-QOS

Multicast: Пересылка, PIM, RP и проектирование в кампусной сети и WAN

Multicast эффективно масштабирует трафик “один ко многим” и требует тесной связи с одноадресной (unicast) маршрутизацией для проверок Reverse Path Forwarding (RPF).

• IGMP: Хосты присоединяются к группам и покидают их через IGMP (v2 широко распространена, v3 добавляет фильтрацию по источнику для SSM). Включайте IGMP snooping на коммутаторах; убедитесь, что в каждом VLAN существует IGMP querier для поддержания состояния групп даже без multicast-маршрутизатора в сегменте.
• Режимы PIM:
  • PIM Sparse Mode (PIM-SM): Модель “запроса” (pull model); отправляет трафик только заинтересованным получателям. RP является корнем общего дерева (*,G). По умолчанию RP необходим только для запуска новых сессий; получатели могут переключаться на дерево источника (S,G) для оптимальных путей после начала потока трафика.
  • PIM Source-Specific Multicast (SSM): RP не используется; получатели указывают (S,G) через IGMPv3. Упрощает управляющий уровень (control plane) и снижает риски, связанные с трафиком “многие ко многим”. Идеально подходит для IPTV и источников с жестким контролем.
  • PIM Bidirectional: Эффективен для сценариев “многие ко многим” с малым объемом состояний и без регистрации источников (например, данные финансового рынка), но без переключения на кратчайший путь; проектируйте соответственно.
• Стратегии выбора RP:
  • Статический RP для небольших доменов.
  • BSR/Auto-RP для динамического обнаружения.
  • Anycast-RP с MSDP для обмена информацией о регистрации источников между несколькими RP с использованием одного anycast-адреса, что повышает отказоустойчивость и локальность.
• RPF и переключение на SPT: Сбои RPF возникают из-за асимметрии unicast-маршрутов или отфильтрованных префиксов; проверяйте с помощью команд show ip rpf и show ip mroute. Пороги SPT определяют, когда переходить с общего дерева на дерево источника; устанавливайте их на основе объема трафика и симметрии путей в ядре сети.
• Проектирование в кампусной сети: Используйте PIM-SM в маршрутизируемом ядре, IGMP snooping с querier’ами на уровне доступа и Anycast-RP на согласованных узлах ядра. Предпочитайте SSM, где хосты поддерживают IGMPv3; в противном случае развертывайте SSM mapping на маршрутизаторе первого хопа.
• Проектирование в WAN: Поверх MPLS используйте провайдерский mVPN, если он доступен; в противном случае запускайте PIM в WAN VRF или инкапсулируйте трафик с помощью GRE/DMVPN и включайте PIM внутри туннелей. Обеспечьте достижимость RP между доменами и подтвердите, что провайдер принимает multicast-трафик, или планируйте оверлейные сети. Для распространения через Интернет предпочитайте SSM с GRE/IPsec, чтобы избежать зависимостей от RP в недоверенных доменах.

Краткий пример PIM/RP: ip pim rp-address 10.10.10.10 ip pim ssm range 232.0.0.0/8 interface Vlan30 ip pim sparse-mode ip igmp version 3

Активный мониторинг, автоматическое аварийное переключение и устранение неполадок

IP SLA и отслеживание (tracking) автоматизируют корректирующие действия и проверяют соблюдение SLA в реальном времени.

• IP SLA: ICMP-echo для проверки доступности, UDP jitter для качества голоса/видео, HTTP/TCP connect для доступности приложений. Для многоадресной рассылки операции UDP jitter могут тестировать доставку группе по конкретному (S,G) или (*,G).
• Отслеживание объектов и триггеры: Отслеживайте результаты IP SLA, состояния интерфейсов или маршруты. Свяжите отслеживание с HSRP/VRRP, статическими маршрутами или PBR. Используйте апплеты EEM для сложных последовательностей действий (логирование, переконфигурация, уведомление).
• Пример:

undefined

undefined

undefined

undefined

undefined

• Мониторинг доступности сервисов: Комбинируйте счетчики SNMP (отброшенные пакеты, ошибки), статистику очередей QoS, NetFlow/IPFIX для анализа использования классов и syslog для корреляции аномалий. Синхронизация времени должна быть строгой, иначе корреляция данных из нескольких источников не удастся.
• Распространенные режимы сбоев и компромиссы:
  • DHCP: Опция 82 удаляется межсетевыми экранами; пересечение разделенных областей (split-scope); нелегитимные DHCP-серверы — включите DHCP snooping.
  • DNS: Асимметричная политика или блокировка EDNS0; сбой anycast без отзыва маршрута приводит к «черным дырам» — отслеживайте состояние BGP при использовании anycast.
  • NTP: Петли пиринга и «ложные» источники времени (false tickers); неаутентифицированные сдвиги времени вызывают сбои сертификатов — применяйте аутентификацию и пороговые значения для проверки адекватности (sanity thresholds).
  • NAT: Асимметричная маршрутизация через резервированные пограничные устройства разрывает сессии; исчерпание портов PAT — масштабируйте пулы или используйте хеширование по потокам (per-flow hashing) с ECMP, осведомленным о stateful-устройствах.
  • QoS: Чрезмерное выделение ресурсов для LLQ приводит к «голоданию» других классов; неверное сопоставление DSCP на платформе ведет к попаданию трафика в непредусмотренные очереди — проверяйте специфичные для платформы карты QoS.
  • Multicast: Сбои RPF из-за фильтров маршрутов; потеря доступности RP останавливает новые подключения; IGMP snooping без запрашивающего устройства (querier) приводит к устареванию членства в группах — включите querier или обеспечьте присутствие PIM-маршрутизатора в VLAN.
  • Перегрузка плоскости управления: Чрезмерные опросы или штормы trap-сообщений дестабилизируют маршрутизацию — применяйте CoPP и ограничения скорости для телеметрии.

Практический сценарий проблемы

Компания Acme BioTech должна поддерживать многоадресные видеотренинги между площадками, VoIP и доступ в интернет через облако из двух резервированных центров обработки данных, соединенных через MPLS с резервным каналом через интернет-VPN. Пользователи сообщают о периодических замираниях видео во время тренингов и случайном ухудшении качества звонков во время аварийных переключений.

Подход:

1. Нормализовать и защитить синхронизацию времени во всей инфраструктуре.

• Настроить NTPv4 на всех сетевых устройствах для работы с локальными серверами stratum-2 с аутентификацией. Обоснование: Единое время обеспечивает корректность аналитики QoS, позволяет сопоставлять данные syslog/NetFlow и предотвращает аномалии сертификатов, которые могут нарушить работу API управления при аварийном переключении.

2. Стабилизировать работу DHCP и DNS для инфраструктурных конечных точек и телефонов.

• Обеспечить наличие ip helper-address на SVI уровня доступа, включить вставку Option 82 на уровне доступа и доверие к ней на уровне распределения, а также предоставить Option 150 для TFTP телефонов, где это необходимо. Проверить доступность DNS-резолверов из всех VLAN. Обоснование: Стабильная адресация и разрешение имен устраняют ложные перерегистрации телефонов и сбои обнаружения точек доступа/контроллеров, которые могут каскадно вызывать проблемы с QoS.

3. Внедрить QoS с четкой границей доверия (trust boundary) и шейпингом для WAN.

• Доверять маркировке от IP-телефонов и конечных точек TelePresence; перемаркировывать трафик от ПК в класс по умолчанию. Применить LLQ для EF в размере 10% с полисером, AF41 для интерактивного видео в размере 20% с WRED и настроить шейпинг исходящего трафика до уровня MPLS CIR на пограничных устройствах WAN. Обоснование: Сохраняет качество голосового и интерактивного видео трафика в условиях перегрузки и предотвращает отбрасывание пакетов полисером провайдера за счет соответствия контрактной скорости.

4. Оптимизировать многоадресную рассылку для кампуса и WAN.

• Развернуть PIM-SM в ядре с Anycast-RP в двух ЦОД с использованием MSDP, включить IGMP v3 в VLAN доступа и предпочесть SSM (232/8) для потоков тренингов, где источники известны. Обоснование: Anycast-RP обеспечивает непрерывность сессий при их запуске из разных ЦОД; SSM устраняет зависимость от RP для основных потоков тренингов и упрощает их прохождение через WAN.

5. Проверить NAT и симметричность путей на границе с интернетом.

• Использовать stateful NAT на HA-паре для исходящего PAT, детерминированный статический NAT для входящих сервисов и убедиться, что HSRP согласован с активным stateful-узлом. Обоснование: Предотвращает потерю сессий и асимметрию во время аварийного переключения, что может повлиять на медиатрафик софтфонов к облачным сервисам.

6. Развернуть IP SLA с отслеживанием объектов для автоматизации переключения на резервный интернет-канал.

• Настроить пробы IP SLA UDP jitter в сторону облачного SBC и ICMP в сторону MPLS PE; отслеживать результаты для корректировки статических маршрутов или влияния на BGP local preference. Обоснование: Измеряет реальное качество сервиса, а не просто доступность; запускает контролируемое аварийное переключение до того, как пользователи заметят ухудшение.

7. Внедрить телеметрию и защитить плоскость управления.

• Передавать счетчики глубины очереди и отброшенных пакетов через model-driven telemetry на коллекторы, включить NetFlow/IPFIX на пограничных устройствах WAN и ограничить доступ по SNMP только для IP-адресов NMS с использованием SNMPv3. Применить CoPP с явным классом для управляющего трафика. Обоснование: Обеспечивает практическую видимость состояния сети, гарантируя при этом стабильность плоскости управления под нагрузкой от мониторинга.

8. Тестировать, наблюдать и настраивать.

• Запустить плановый многоадресный тренинг с синтетическими VoIP-звонками, одновременно собирая выводы команд show policy-map interface, show ip mroute и данные об отброшенных пакетах в очередях. Скорректировать полосу пропускания для LLQ и AF41 на основе измеренной утилизации и поведения провайдера. Обоснование: Эмпирическая настройка приводит выделение ресурсов QoS в соответствие с реальными паттернами трафика и характеристиками полисинга провайдера.

Эта последовательность действий решает проблемы стабильности времени, базовых сервисов, управления очередями и скоростью, корректного поведения плоскости управления многоадресной рассылки, симметрии NAT, автоматического аварийного переключения и наблюдаемости, что в совокупности обеспечивает стабильную работу голосовой связи и видео по каналам MPLS и интернет.

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

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