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

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

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

Обзор

IP-сервисы связывают сети воедино и обеспечивают их наблюдаемость, доступность и предсказуемость под нагрузкой. В этом разделе рассматриваются основные сервисы (DHCP, DNS, NTP), средства мониторинга и сигнализации (SNMP, syslog, NetFlow, телеметрия), трансляция адресов (NAT) и управление трафиком (QoS), а затем всё это увязывается с резервированием первого хопа и операционной проверкой. При проектировании акцент делается на детерминированном поведении, принципе наименьших привилегий и плавной деградации при сбоях.

Основные IP-сервисы: DHCP, DNS и NTP

DHCP

• Компоненты и процесс: Клиент использует процесс DORA (Discover, Offer, Request, Acknowledgment). Пулы сервера (scopes) определяют диапазоны адресов, маски, шлюзы (Option 3), DNS (Option 6), таймеры и опции производителя (например, Option 150 для TFTP для IP-телефонов).
• Ретрансляция (Relay): Когда сервер не находится в подсети клиента, интерфейс уровня 3 ретранслирует широковещательные запросы с помощью ip helper-address, отправляя их в виде одноадресного (unicast) запроса на сервер. DHCP snooping вставляет опцию 82 (Option 82, circuit-id/remote-id), чтобы сервер мог принимать решения с учётом местоположения клиента.
• Пулы и исключения: Создавайте пулы, достаточные для ожидаемого количества клиентов плюс запас на рост. Резервируйте статические адреса либо через привязку по MAC-адресу, либо исключая их из динамического распределения с помощью ip dhcp excluded-address.
• Аренда (Leases): Найдите баланс между текучестью и повторным использованием адресов; короткое время аренды ускоряет возврат адресов, но увеличивает трафик DHCP.
• Типичные режимы сбоя:
  • Отсутствует/неправильный helper-address на ретрансляторе или ACL блокируют UDP 67/68.
  • Нет подходящего пула (scope), пул исчерпан или подсети пересекаются.
  • Неверная опция шлюза по умолчанию, вызывающая проблемы с доступностью после загрузки.
  • Неправильная настройка доверия (trust) в DHCP snooping, приводящая к отбрасыванию ответов сервера.

• Полезные команды:

undefined

undefined

• Минимальный пример ретранслятора:

undefined

DNS

• Процесс разрешения имён: Stub-резолвер проверяет кэш хоста и файл hosts, затем запрашивает рекурсивный резолвер. Рекурсивный сервер итеративно опрашивает корневые, TLD и авторитативные серверы, кэширует ответы в соответствии с TTL и возвращает результат. Сбои могут быть типа NXDOMAIN (имя не существует) или SERVFAIL (проблема с разрешением).
• Рекомендации по проектированию: Используйте резервные рекурсивные резолверы; предпочитайте anycast для локальности и доступности; настраивайте TTL для баланса между гибкостью и эффективностью кэширования. Применяйте белые списки DNS для чувствительных сегментов.
• Типичные режимы сбоя:
  • Блокировка или асимметрия UDP/TCP 53, некорректная обработка EDNS или проблемы с MTU/фрагментацией.
  • Неправильно настроенные домены поиска, приводящие к неверному разрешению FQDN.
  • Устаревший/отравленный кэш; сбой проверки DNSSEC.
• Основы настройки на устройстве:

undefined

.

NTP

• Синхронизация времени обеспечивает корреляцию (логов, потоков, событий безопасности) и точное измерение задержки/джиттера. Иерархия использует уровни (stratum): 1 — напрямую подключен к эталонным часам; 16 — не синхронизирован.
• Клиенты, серверы и пиры формируют стабильное дерево времени; аутентифицируйте NTP с помощью ключей для предотвращения спуфинга.
• IP SLA и джиттер: Точная синхронизация времени (например, с помощью NTP) необходима при измерении односторонней задержки и для обеспечения корректных расчетов джиттера между узлами.
• Типичные режимы сбоя: Недоступные серверы, асимметричные пути/расхождение времени, путаница с часовыми поясами/летним временем или случайное принятие неаутентифицированных серверов.

• Полезные команды:

undefined

undefined

Средства мониторинга и контроля: SNMP, Syslog, NetFlow и телеметрия

SNMP

• Версии: v2c (на основе community-строк) против v3 (аутентификация/шифрование). Предпочитайте v3 с authPriv для обеспечения целостности и конфиденциальности.
• Опрос (Polling) против ловушек (traps/informs): Опрос для регулярного сбора метрик; отправка traps/informs при изменении состояния. Informs обеспечивают надежность за счет подтверждения доставки.
• Безопасность и масштабирование: Ограничивайте управляющие станции с помощью ACL; ограничивайте частоту отправки traps; минимизируйте использование ресурсоемких OID; избегайте стандартных community-строк public/private.

Syslog

• Уровни: 0 (emergency), 1 (alert), 2 (critical), 3 (error), 4 (warning), 5 (notice), 6 (informational), 7 (debugging).
• Включите временные метки и порядковые номера; отправляйте сообщения на резервные коллекторы; устанавливайте facility/уровень для каждой функции, чтобы избежать информационного шума.

• Пример:

undefined

NetFlow

• Собирает метаданные о сессиях (5-tuple, счетчики, временные метки). v5 имеет фиксированный формат; v9/IPFIX основаны на шаблонах и являются расширяемыми.
• Проектирование: Экспортируйте данные как минимум на два коллектора; при необходимости используйте сэмплирование для снижения нагрузки на CPU; обеспечьте синхронизацию времени (NTP) для точной аналитики.

• Классический пример:

undefined

Model-driven telemetry (Телеметрия на основе моделей)

• Потоковая передача (push-based) выбранных данных, смоделированных с помощью YANG, по эффективным транспортным протоколам (например, gRPC). Преимущества: меньшая задержка, предсказуемая нагрузка на CPU и лучшая масштабируемость по сравнению с периодическим опросом по SNMP.
• Компромиссы: Требуются коллекторы, которые понимают модели данных; необходимо обеспечивать безопасность транспорта и QoS для самого потока телеметрии.

Типичные режимы сбоя и способы их устранения

• Чрезмерное логирование или опрос, вызывающие скачки нагрузки на CPU: настройте уровни, группируйте или сэмплируйте данные.
• Расхождение времени: Настройте NTP, чтобы предотвратить нарушение порядка событий и некорректную сшивку потоков (flow stitching).
• Блокировка плоскости управления (management plane) межсетевым экраном/ACL: выделите отдельную сеть управления (OOB) или VRF и используйте политики для защиты плоскости управления (control plane policing).

NAT и трансляция адресов

Основные понятия

• Терминология:
  • Inside local: Исходный частный (private) адрес.
  • Inside global: Транслированный адрес, видимый извне.
  • Outside local/global: Адрес внешнего хоста, как он виден изнутри/снаружи.
• Типы:
  • Static NAT: Фиксированное сопоставление «один к одному»; стабильная доступность для входящих подключений.
  • Dynamic NAT: «Многие ко многим» через пул адресов; только для исходящих подключений, пока не будет выделена трансляция.
  • PAT (overload): «Многие к одному» или «многие к нескольким» с использованием портов TCP/UDP; самый распространенный тип для выхода в Интернет.

Принципы проектирования и компромиссы

• Static NAT для серверов, которым требуется входящий доступ; PAT для клиентов для экономии публичных IP-адресов.
• NAT нарушает сквозную прозрачность (end-to-end transparency); некоторые протоколы требуют ALGs (Application Layer Gateway), например FTP, SIP. Предпочтительно использовать функции application-awareness на границах сети или протоколы, устойчивые к трансляции.
• Высокая доступность (High availability): FHRP перемещает шлюз по умолчанию, но состояние NAT хранится на каждом устройстве; без stateful NAT (трансляции с сохранением состояния) отработка отказа сбрасывает потоки. Размещайте NAT на HA-брандмауэрах/маршрутизаторах, которые поддерживают репликацию состояния, или детерминированно управляйте исходящим трафиком.

Примеры конфигурации

• PAT с использованием WAN-интерфейса:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

• Static NAT для сервера:

undefined

Проверка и устранение неполадок

undefined

,

undefined

undefined

• Распространенные проблемы: Отсутствие меток inside/outside на интерфейсах, нет маршрута к пулу адресов, пересекающиеся пулы, несоответствие ACL, исчерпание портов при PAT, асимметричная маршрутизация через несколько выходов или нерешенная проблема hairpinning (возврата трафика).

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

Классификация и маркировка

• Классифицируйте трафик с помощью ACL, IP precedence/DSCP, CoS или NBAR. Маркируйте на границе сети; сохраняйте маркировку в доверенных доменах.
• DSCP и CoS:
  • DSCP EF (46) для голосового трафика (bearer); CS3/AF31–AF33 для сигнализации; AF41–AF43/CS4 для интерактивного видео.
  • Значения CoS на транках 802.1Q требуют сопоставления (mapping) со значениями DSCP на границах L3.
• Границы доверия (Trust boundaries):

  • Доверяйте только тем устройствам, которые могут нести ответственность за маркировку (например, IP-телефон Cisco). На порту доступа с телефоном используйте доверие на основе типа устройства и сохраняйте приоритеты нижестоящего трафика:

undefined

-

undefined

undefined

undefined

undefined

Организация очередей и управление перегрузками

• CBWFQ: Взвешенное планирование (weighted scheduling) на основе гарантированной полосы пропускания.
• LLQ: Добавляет очередь строгого приоритета (strict-priority) к CBWFQ для классов, чувствительных к задержкам (голос, интерактивное видео).
• PQ: Чистая строгая приоритизация; может вызвать “голодание” другого трафика, если не используется policing. LLQ предпочтительнее, так как он по своей сути ограничивает (polices) приоритетный трафик.
• WRED: Произвольное отбрасывание пакетов на ранней стадии для предотвращения глобальной синхронизации TCP; не применяйте к приоритетным очередям.

Policing (ограничение) и shaping (формирование)

• Policing: Принудительно ограничивает скорость, отбрасывая/перемаркировывая избыточный трафик; низкая задержка, но увеличивает потери и джиттер.
• Shaping: Буферизует всплески трафика, чтобы соответствовать заданной скорости; добавляет задержку, но уменьшает количество отбрасываемых пакетов на последующих устройствах.
• Применяйте shaping на более медленных исходящих каналах перед иерархическими политиками.

• Пример политики LLQ:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Целевые показатели для голоса и видео

• Голос: Односторонняя задержка <150 мс, джиттер <30 мс, потери <1%. Используйте LLQ для основного трафика (bearers), защищайте сигнальный трафик отдельно.
• Видео: Интерактивное видео требует контроля полосы пропускания и джиттера; потоковое видео (streaming) более устойчиво к потерям, но требует большой полосы пропускания. Рассмотрите возможность использования отдельных очередей и контроля доступа (admission control).

Проверка и измерение

• Используйте IP SLA для генерации синтетического трафика RTP/UDP и измерения задержки, джиттера и потерь; обеспечьте точность времени с помощью NTP.
• Используйте show policy-map interface для проверки счетчиков и отброшенных пакетов по каждому классу.

Отказоустойчивость: Влияние FHRP и операционная проверка

FHRP

• HSRP/VRRP предоставляют виртуальный шлюз по умолчанию для переживания сбоев первого хопа; GLBP добавляет балансировку нагрузки на шлюзы.
• Проектирование: Настраивайте таймеры для достижения баланса между конвергенцией и стабильностью; используйте отслеживание объектов (object tracking) для переключения при потере связи с вышестоящим провайдером/WAN, а не только при падении интерфейса.
• Влияние на сервис: Во время переключения отказ, обновление ARP и перехеширование могут вызвать кратковременную потерю связи; потоки реального времени без симметричности пути или реплицированного состояния NAT могут быть сброшены. Сохраняйте постоянство исходящего пути для приоритетного трафика.

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

• DHCP: Подтвердите наличие helper-адресов и утилизацию пула; используйте захват пакетов для анализа процесса DORA; проверьте таблицы DHCP snooping.
• DNS: Проверьте с помощью nslookup/dig; проверьте резервирование резолверов; изучите правила межсетевого экрана и поведение MTU/EDNS.
• NAT: Проверьте трансляции во время активных потоков; убедитесь в наличии маршрутов к inside local и пулу адресов; протестируйте входящий статический NAT извне.
• NTP: Убедитесь в синхронизации stratum и низком смещении (offset); требуйте аутентификацию.
• QoS: Проверьте настройки доверия (trust); проверьте счетчики service-policy под реалистичной нагрузкой; запустите тесты IP SLA для голоса; отслеживайте сбросы пакетов полисером в приоритетном трафике.
• Наблюдаемость: Убедитесь, что SNMPv3 работает и traps доставляются; временные метки syslog корректны; экспортеры NetFlow согласованы с коллекторами; потоки телеметрии стабильны.

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

В компании Acme Manufacturing наблюдаются периодические прерывания звука в IP-телефонах и спорадические сбои DHCP в филиале после добавления второго интернет-провайдера и включения PAT на новом маршрутизаторе.

1. Стабилизировать маршрутизацию и доступность шлюза с помощью FHRP

• Настроить HSRP на SVI для VLAN филиала на обоих маршрутизаторах, установить preempt и приоритеты, а также отслеживать WAN-аплинки.
• Обоснование: Виртуальный шлюз по умолчанию скрывает от конечных устройств отказ маршрутизатора; отслеживание объектов (object tracking) переключает шлюз с маршрутизатора, потерявшего достижимость вышестоящего провайдера.

2. Нормализовать поведение NAT и предотвратить асимметричный исходящий трафик

• Настроить PAT только на активном маршрутизаторе HSRP; убедиться, что резервный маршрутизатор не анонсирует маршрут по умолчанию, пока не станет активным, или реализовать PBR для привязки исходящего трафика голосового VLAN к одному маршрутизатору.
• Обоснование: Асимметричный исходящий трафик нарушает работу stateful PAT и ALG для SIP/RTP; постоянство исходящего пути сохраняет трансляции и стабильность вызовов.

3. Исправить надежность ретрансляции DHCP

• На обоих шлюзах на SVI настроить ip helper-address на центральные DHCP-серверы; проверить доверие (trust) DHCP snooping в сторону аплинка и недоверие (untrust) в сторону портов доступа; исключить диапазоны статических IP-адресов.
• Обоснование: Правильная ретрансляция гарантирует, что процесс DORA достигает серверов; snooping предотвращает появление нелегитимных серверов, разрешая при этом ответы от легитимных; исключения позволяют избежать конфликтов.

4. Настроить точное время и включить измерения

• Настроить NTP-клиенты на обоих маршрутизаторах с аутентифицированными серверами, проверить stratum, а затем настроить операции IP SLA udp-jitter в сторону менеджера вызовов в штаб-квартире.
• Обоснование: Точное время является основой для расчетов односторонней задержки и джиттера; IP SLA подтверждает, что QoS способен поддерживать голосовой трафик.

5. Внедрить политику QoS от границы сети до WAN с границами доверия

• Доверять CoS на портах доступа только при обнаружении IP-телефона Cisco; перемаркировать DSCP для голоса в EF и для сигнализации в CS3; применить LLQ с 10% для голоса, выделенной полосой для видео и fair-queue по умолчанию. Применить шейпинг до CIR провайдера перед применением политики, если физический интерфейс быстрее, чем скорость по контракту.
• Обоснование: Правильная настройка доверия не позволяет хостам завышать приоритет; LLQ гарантирует низкую задержку; шейпинг позволяет избежать отбрасывания пакетов на оборудовании провайдера.

6. Улучшить наблюдаемость и усилить безопасность плоскости управления

• Включить SNMPv3 на NMS, syslog на резервированные коллекторы с временными метками и экспортеры NetFlow v9 на системы аналитики; добавить полисинг плоскости управления для SNMP и логирования.
• Обоснование: Наблюдаемость подтверждает улучшения и выявляет регрессии; защищенное управление уменьшает поверхность атаки, сохраняя при этом телеметрию.

7. Проверить, затем симулировать сбой

• Использовать команду show policy-map interface, чтобы убедиться, что счетчики приоритетного трафика увеличиваются во время тестовых звонков; наблюдать за базовыми показателями джиттера IP SLA; выполнить traceroute и протестировать отказоустойчивость, принудительно изменив состояние HSRP.
• Обоснование: Операционная проверка под нагрузкой подтверждает правильность проектного решения; контролируемый отказ доказывает отказоустойчивость и выявляет любые пограничные случаи с NAT или конвергенцией.

← Динамическая маршрутизация и IP-связность · Все домены · Проектирование и эксплуатация беспроводных сетей LAN →

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