Cisco 300-410: Качество обслуживания и защита плоскости управления — Руководство по подготовке

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

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

Обзор

Качество обслуживания (QoS) и защита плоскости управления (CoPP/CPPr) совместно обеспечивают стабильную работу критически важных для бизнеса приложений и самой сети под нагрузкой и во время атак. QoS дифференцирует трафик, приоритизирует чувствительные к задержкам потоки и управляет перегрузками на каналах с ограниченной пропускной способностью. CoPP/CPPr защищает ЦП и стек управления маршрутизатора от случайной перегрузки и вредоносных событий. Корректное проектирование зависит от последовательной сквозной маркировки, строгих границ доверия, соответствующего регулирования (policing/shaping), правильно подобранных размеров очередей, проактивного предотвращения перегрузок, аккуратной обработки туннелей/шифрования и постоянной проверки с использованием счетчиков, сопоставленных с поведением приложений.

Классификация, доверие и сквозная маркировка

Классификация и маркировка трафика определяют, как пакеты будут помещаться в очередь и потенциально отбрасываться на каждом узле.

Классификация и сопоставление
- Сопоставление по спискам доступа (access-lists), DSCP/IP precedence, CoS (802.1p), сигнатурам приложений NBAR или внутренним заголовкам туннеля (с помощью qos pre-classify).
- Сохраняйте детерминизм: по возможности сопоставляйте по полям Уровня 3/4; используйте NBAR только при необходимости из-за его влияния на ЦП на некоторых платформах.
Границы доверия
- Определите, где сеть принимает существующие маркировки. Типичный подход: не доверять конечным хостам; доверять корпоративным телефонам и аплинкам к известным доменам QoS.
- На границе сети перемаркируйте недоверенный трафик в значения DSCP, определенные политикой; доверяйте только тем устройствам, которыми вы управляете и которые аутентифицируете.
- На портах коммутатора, направленных к конечным точкам, отключайте доверие (no trust dscp/cos), если вы явно не проверяете тип устройства.
Маркировка
- DSCP (6 бит) — это основная сквозная маркировка в IP-сетях. IP precedence (3 бита) является устаревшим и сопоставляется со старшими битами DSCP.
- CoS (802.1p, 3 бита) маркирует кадры Уровня 2 в транках VLAN; последовательно сопоставляйте DSCP↔CoS на границах L2/L3.
- В ядрах MPLS 3-битное поле Traffic Class (TC, ранее EXP) переносит информацию о QoS; сопоставляйте DSCP с TC на входе и TC обратно с DSCP на выходе, чтобы сохранить семантику в ядре VPN или TE.
Последовательность маркировки
- Резервируйте EF для несущего голосового трафика (с низким джиттером), CS3/AF31/AF32 для сигнализации вызовов, AF4x для интерактивного видео, AF2x/AF1x для критически важных данных, CS0/BE для трафика с негарантированной доставкой (best effort) и CS1 для низкоприоритетного трафика (scavenger).
- Задокументируйте единую корпоративную политику QoS; убедитесь, что провайдеры WAN соблюдают и сопоставляют маркировку согласно контракту.
- Избегайте перемаркировки в середине пути, если это не перевод между доменами; в противном случае вы рискуете получить инверсию приоритетов и усложнить поиск неисправностей.

Пример (маркировка на входящем пограничном интерфейсе):

undefined

Сценарии сбоев и компромиссы:

Доверие неверному пограничному устройству ведет к злоупотреблению приоритетами; потоки с низким приоритетом могут вызвать «голодание» критически важных очередей.
Непоследовательное сопоставление DSCP↔CoS нарушает работу QoS на переходах L2/L3.
Чрезмерное использование NBAR на программных платформах может повысить нагрузку на ЦП; предпочитайте статические сопоставления.

Регулирование, организация очередей и предотвращение перегрузок

Регулирование трафика формирует его до скоростей, которые сеть может поддерживать, и применяет policing там, где требуются жесткие ограничения.

Policing в сравнении с shaping
- Policing ограничивает скорость с помощью алгоритма «дырявого ведра» (token bucket); избыточный трафик отбрасывается или опционально перемаркируется. Это сохраняет пропускную способность канала, но увеличивает потери и может вызывать механизм отсрочки TCP (TCP backoff) и повторные попытки на уровне приложений.
- Shaping буферизует и отправляет трафик с целевой скоростью (обычно соответствующей CIR оператора связи), сглаживая всплески и уменьшая количество отбрасываний на последующих узлах; это добавляет задержку и джиттер, пропорциональные глубине очереди.
Параметры всплесков
- Односкоростные двухпараметрические policer’ы используют гарантированную скорость передачи информации (CIR) с гарантированным объемом всплеска (Bc) и опционально Be (избыточный объем всплеска).
- Слишком маленький Bc относительно RTT и MTU вызывает отбрасывания на уровне фрагментации и неэффективную пропускную способность; устанавливайте размер Bc не менее 1–2 x произведения пропускной способности на задержку (bandwidth-delay product) для shaping и в несколько MTU для policing.
CBWFQ и LLQ
- Class-Based Weighted Fair Queuing (CBWFQ) гарантирует минимальную пропускную способность для классов. Настраивайте пропускную способность в кбит/с или процентах в рамках shaping.
- Low-Latency Queue (LLQ) добавляет обслуживание со строгим приоритетом для класса (priority), трафик которого ограничивается (policed) настроенной скоростью для предотвращения «голодания» других очередей. Только несущий трафик голоса/видео в реальном времени должен находиться в LLQ.
- Лимиты очереди (queue-limit) устанавливают максимальное количество пакетов в буфере для каждого класса; слишком высокий лимит увеличивает задержку, слишком низкий — количество отбрасываний. Найдите баланс с учетом требований приложений.
WRED в сравнении с tail drop
- Tail drop отбрасывает пакеты только при полном заполнении очередей; это может вызвать глобальную синхронизацию TCP и значительные колебания производительности.
- Weighted Random Early Detection (WRED) начинает вероятностные отбрасывания до полного заполнения очереди; WRED на основе DSCP позволяет классам с более высоким приоритетом использовать более глубокие очереди с меньшей вероятностью раннего отбрасывания.
- WRED полезен для потоков TCP; для преимущественно UDP-трафика (голос) он добавляет потери без активации механизма отсрочки. Не включайте WRED в LLQ.

Пример (родительский shaping с дочерними CBWFQ/LLQ и WRED):

undefined

Ключевые моменты проектирования:

Всегда применяйте shaping до скорости самого узкого места в вашей зоне ответственности; пусть решение об отбрасывании принимает ваша система очередей, а не механизм провайдера.
Определяйте размер LLQ на основе кодека и объема вызовов; включите 5–10% запаса на заголовки и вариативность VAD (Voice Activity Detection).
Включайте WRED только там, где преобладают мультиплексированные потоки TCP; настраивайте веса консервативно, чтобы предотвратить преждевременные отбрасывания.

QoS на туннелях и WAN-каналах

Туннелирование и шифрование скрывают внутренние заголовки и изменяют MTU, что влияет на классификацию и фрагментацию.

GRE/DMVPN и IPsec
- Без специальной обработки классификация видит только внешние заголовки. Используйте qos pre-classify на туннельных интерфейсах, чтобы устройство классифицировало трафик по внутреннему 5-tuple и DSCP до инкапсуляции/шифрования.
- Сохраняйте или копируйте DSCP во внешний заголовок для поддержания поведения QoS в транзитной сети.
- Настройте MTU и MSS, чтобы избежать фрагментации и сбоев PMTUD; для IPsec на некоторых платформах и у некоторых провайдеров может потребоваться фрагментация после шифрования (fragmentation after-encryption).
QoS для каждого туннеля и иерархический дизайн
- На mGRE/DMVPN применяйте иерархический QoS (шейпинг для каждого туннеля, затем LLQ/CBWFQ для каждого класса), чтобы обеспечить справедливое распределение ресурсов между spoke-узлами.
- Когда каналы провайдера ограничивают CIR с помощью строгих полисеров, настройте шейпинг на уровне CIR или немного ниже, чтобы избежать отбрасывания пакетов (tail drops) на стороне провайдера.

Пример (QoS для hub-and-spoke DMVPN на туннеле): interface Tunnel30 ip address 10.0.30.1 255.255.255.0 tunnel mode gre multipoint qos pre-classify ip mtu 1400 ip tcp adjust-mss 1360 service-policy output PM-WAN-PARENT ! crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac crypto ipsec profile DMVPN-PROFILE set transform-set TS ! ! Зависит от платформы: crypto ipsec fragmentation after-encryption

Распространенные проблемы и способы их решения:

Отсутствие qos pre-classify приводит к тому, что весь трафик после шифрования попадает в class-default, лишая ресурсов потоки реального времени.
Неправильные значения MTU/MSS вызывают «черные дыры» (blackholing) для больших сегментов и нестабильную работу приложений; проверяйте Path MTU на всем пути от отправителя до получателя.
Применение сложных политик на полной скорости (line rate) к программным туннелям может сильно нагружать CPU; по возможности используйте аппаратное ускорение (hardware offload).

Защита плоскости управления (Control-Plane Protection, CoPP/CPPr) и операционная проверка

CoPP защищает CPU маршрутизатора путем классификации и ограничения скорости управляющего трафика и трафика менеджмента в плоскости управления. CPPr добавляет более тонкую гранулярность, используя подынтерфейсы host, transit и CEF-exception.

Основы CoPP
- Применяйте политики к плоскости управления, а не к интерфейсам данных.
- Обычно поддерживаемые типы соответствия: ip dscp, ip precedence и access-group. Не используйте ключевое слово log в записях ACL, на которые ссылается CoPP.
- Отделяйте критически важные протоколы маршрутизации (BGP, OSPF, RSVP/LDP, где применимо) от трафика управления по принципу «best-effort» (HTTP) и массового управляющего трафика (экспорт NetFlow на CPU в исключительных случаях). Предоставляйте достаточные значения CIR для критически важных протоколов.
Детали CPPr
- control-plane host управляет трафиком, терминируемым на маршрутизаторе (например, SSH, SNMP, сессии маршрутизации).
- control-plane transit обрабатывает трафик исключений, перенаправленный (punted) с аппаратного уровня (например, TTL-exceeded, MTU exceeded).
- control-plane cef-exception управляет перенаправлениями (punts), связанными с CEF.
- Применяйте разные политики к каждому подынтерфейсу, чтобы избежать побочного ущерба, когда один из классов трафика ведет себя некорректно.
Пример CoPP с исключениями и правильным применением: ip access-list extended ACL-TELNET-EXEMPT deny tcp host 10.1.1.1 any eq 23 deny tcp host 172.16.1.1 any eq 23 permit ip any any ip access-list extended ACL-BGP permit tcp any any eq 179 permit tcp any eq 179 any ip access-list extended ACL-HTTP permit tcp any any eq 80 permit tcp any any eq 443 ! class-map match-any CM-BGP match access-group name ACL-BGP class-map match-any CM-HTTP match access-group name ACL-HTTP class-map match-any CM-TELNET match access-group name ACL-TELNET-EXEMPT ! policy-map PM-COPP class CM-BGP police cir 256000 conform-action transmit exceed-action transmit class CM-HTTP police cir 64000 conform-action transmit exceed-action drop class CM-TELNET police cir 100000 conform-action transmit exceed-action drop class class-default police cir 32000 conform-action transmit exceed-action drop ! ! Убедитесь, что политика применена к плоскости управления, а не к интерфейсам данных: no interface GigabitEthernet0/0 service-policy input PM-COPP control-plane service-policy input PM-COPP

Примечания:

Слишком агрессивное ограничение скорости BGP может привести к потере keepalive-сообщений, сбросу сессий и флуктуации маршрутов (route churn). Если необходимо применять police, установите достаточный CIR и рассмотрите использование exceed-action transmit, чтобы избежать отбросов во время всплесков трафика.
Исключите определенные доверенные источники управления, используя записи deny в ACL перед permit; примените ACL в качестве условия match в соответствующем классе.
Дополнения для плоскости управления
- IPv6 RA Guard блокирует нелегитимные Router Advertisements на портах L2, но не может обеспечить защиту, если RA-сообщения туннелируются; применяйте защиту на конечных точках туннеля или используйте аутентификацию, где это возможно.
- IPv6 Source Guard использует таблицу привязок (binding table) для разрешения трафика только от действительных исходных адресов; он отбрасывает трафик от неизвестных/неназначенных источников IPv6 на портах доступа, уменьшая объем трафика исключений, обрабатываемого CPU.
- Усиление защиты устройства (отключение неиспользуемых служб, использование ACL на линиях vty, ограничение SNMP communities) уменьшает уязвимость плоскости управления.
Проверка и счетчики
- Используйте команды show policy-map interface и show policy-map control-plane для проверки счетчиков пакетов, отбросов и действий police. При появлении симптомов высокой загрузки CPU (например, медленный SSH, прерывистый SNMP) в первую очередь выполните show policy-map control-plane.
- На платформах с аппаратной коммутацией сопоставьте данные со счетчиками show platform hardware qfp active statistics drop или эквивалентными счетчиками ASIC для отбросов WRED/tail drops.
- Для очередей проверьте их глубину, отбросы tail/WRED и действия police для приоритетной очереди с помощью show policy-map interface и show queueing interface.
- Ищите симптомы на уровне приложений:
  - Джиттер, потеря пакетов или прерывистый звук в голосовой связи указывают на слишком маленький размер LLQ или неверную границу доверия.
  - Медленный/разрывающийся SSH при нормальных пингах может указывать на то, что CoPP ограничивает трафик управления.
  - Прерывистый SNMP коррелирует с отбросами в классе управления или превышением лимитов для трафика исключений CEF (punts).
  - Падение пропускной способности TCP под нагрузкой с ростом отбросов WRED является ожидаемым; при использовании только tail drop ищите синхронизированные «пилообразные» потоки.

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

Компания Acme Engineering использует сеть DMVPN с одной центральной точкой (single-hub) через широкополосный интернет с IPsec+mGRE. Пользователи жалуются на прерывистый VoIP в штаб-квартиру, прерывистый опрос SNMP на маршрутизаторах филиалов и медленный или разрывающийся SSH к центральному узлу в часы пик.

Установите границы доверия и перемаркируйте трафик на границе сети

Обоснование: Только телефонам и доверенным аплинкам разрешено устанавливать EF/CS3; весь остальной трафик доступа перемаркируется в BE. Это предотвращает злоупотребление приоритетами, которое может привести к нехватке ресурсов для классов реального времени.

Внедрите иерархический QoS на туннеле DMVPN

Обоснование: Примените родительский шейпер (parent shaper) к туннелю со скоростью, соответствующей измеренной скорости провайдера (например, 20 Мбит/с), чтобы избежать ограничения скорости вышестоящим оборудованием. В рамках родительского класса используйте LLQ для голоса (EF), классы с гарантированной полосой пропускания для видео и критически важных данных, WRED для классов с преобладанием TCP и fair-queue для класса по умолчанию. Это позволяет управлять перегрузками локально, до того как оператор начнет отбрасывать пакеты.

Включите qos pre-classify и настройте MTU/MSS

Обоснование: qos pre-classify гарантирует, что политика сработает по внутренним IP/порту/DSCP до инкапсуляции в GRE/IPsec. ip mtu 1400 и ip tcp adjust-mss 1360 предотвращают фрагментацию/«черные дыры» из-за накладных расходов на инкапсуляцию. Фрагментация после шифрования (after-encryption fragmentation) настраивается с учетом поведения провайдера.

Удалите CoPP, примененный к интерфейсу, и примените его к плоскости управления

Обоснование: CoPP должен защищать CPU независимо от входящего интерфейса. Отключите все input service-policy от физических интерфейсов и примените PM-COPP к плоскости управления, чтобы централизованно управлять перенаправленным (punted) и терминируемым на устройстве трафиком.

Создайте отдельные классы CoPP с безопасными значениями CIR; исключите доверенные источники

Обоснование: Поместите BGP в отдельный класс с CIR, достаточным для keepalive-сообщений и всплесков трафика; настройте conform/exceed transmit, чтобы избежать сброса сессий. Ограничьте HTTP/HTTPS до низких скоростей, чтобы лимитировать веб-управление, направленное на CPU. Для исключений Telnet/SSH запретите (deny) доверенные IP-адреса управления в ACL, чтобы политика не ограничивала их скорость, но при этом контролировала все остальные источники.

Проверяйте и корректируйте на основе счетчиков и симптомов

Обоснование: Используйте show policy-map control-plane, чтобы убедиться, что отбросы трафика управления соответствуют наблюдаемым проблемам с SSH/SNMP; корректируйте CIR, пока отбросы не прекратятся. Используйте show policy-map interface Tunnel30, чтобы проверить утилизацию LLQ и убедиться, что при нормальном объеме звонков не происходит отбросов из-за переполнения приоритетной очереди. Отслеживайте отбросы WRED и tail drops в критически важных классах; если качество голоса остается плохим при отсутствии отбросов в LLQ, немного увеличьте процент для LLQ; если отбросы происходят, более точно рассчитайте размер LLQ и родительского шейпера в соответствии с кодеком и полосой пропускания.

Применяя правильную границу доверия, формируя трафик до узкого места, классифицируя его до инкапсуляции и защищая плоскость управления с помощью правильно настроенных политик CoPP/CPPr, Acme Engineering восстанавливает качество голоса и стабилизирует доступ для управления без ущерба для общей пропускной способности.

← Многоадресная маршрутизация и распределение · Все домены · VPN →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Сдайте экзамен →