Cisco 300-410: Политики, масштабируемость и выбор пути BGP — Руководство по подготовке

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

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

Обзор

Border Gateway Protocol (BGP) управляет политикой междоменной маршрутизации и масштабируемым распространением информации о достижимости. Проектирование устойчивых сессий, понимание поведения next-hop и обновлений, а также применение политик с полным осознанием алгоритма выбора наилучшего пути являются основополагающими. В больших сетях iBGP использует отражатели маршрутов (route reflectors) или конфедерации, в то время как продвинутые инструменты, такие как условное анонсирование, генерация маршрута по умолчанию, multipath и подавление (dampening), уточняют его поведение. В этом разделе подробно рассматриваются механика работы, компромиссы при проектировании и режимы отказа, которые необходимо предвидеть, а также предоставляется систематический подход к устранению неполадок как для отсутствующих префиксов, так и для неожиданного выбора пути.

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

• Соседство eBGP и iBGP
  • Соседи eBGP находятся в разных ASN и по умолчанию используют TTL 1, что требует одношагового соседства, если не настроено иначе.
  • Соседи iBGP находятся в одной ASN и требуют полносвязной топологии (full mesh) или альтернативного решения для масштабирования (отражатели маршрутов или конфедерации). iBGP использует TTL 255, и для стабильности сессий часто применяются интерфейсы loopback.
• Достижимость по TCP и конечный автомат BGP (FSM)
  • BGP работает поверх TCP-порта 179; формирование сессии зависит от общей достижимости на уровне IP/TCP и конечного автомата BGP (Idle → Connect/Active → OpenSent → OpenConfirm → Established).
  • Распространенные проблемы: ACL/межсетевые экраны на порту TCP/179, Control-Plane Policing (CoPP), ограничивающий скорость трафика BGP, и асимметричная маршрутизация, нарушающая работу TCP.
  • Практическая проверка:

undefined

; если сессия нестабильна, проверьте

undefined

для валидации CoPP. Во время проверки политики установите для действий conform/exceed значение transmit, чтобы избежать непреднамеренных отбросов пакетов.

• Аутентификация и усиление защиты TTL
  • Аутентификация MD5 (

undefined

) защищает от поддельных сессий; несовпадения удерживают сессию в состоянии Active.

• GTSM/TTL security (

undefined

) смягчает атаки на CPU; не используйте эту опцию вместе с ebgp-multihop для одного и того же соседа.

• Пиринг через loopback, update-source и multihop

  • Пиринг между интерфейсами loopback более устойчив к сбоям физических интерфейсов; он требует указания IP-адреса источника и увеличения TTL:

undefined

-

undefined

• Обеспечьте одноадресную достижимость до интерфейсов loopback через статические маршруты или IGP. Отсутствие рекурсивного маршрута до loopback незаметно препятствует установлению сессии.
• Обработка next-hop и next-hop-self
  • eBGP по умолчанию устанавливает в качестве next-hop IP-адрес анонсирующего соседа.

  • iBGP по умолчанию не изменяет next-hop; пограничные маршрутизаторы должны устанавливать next-hop-self для iBGP-сессий, чтобы избежать «черных дыр» из-за недостижимого стороннего next-hop.

undefined

undefined

Обработка Next-Hop и выбор наилучшего пути

Алгоритм выбора наилучшего пути BGP на платформах Cisco (в порядке убывания значимости):

1. Weight (только на Cisco, локально для маршрутизатора; предпочитается большее значение). Значения по умолчанию: 32768 для локально сгенерированных маршрутов, 0 для остальных.
2. Local Preference (внутри AS; предпочитается большее значение). Значение по умолчанию — 100; распространяется в iBGP.
3. Локально сгенерированные маршруты (network/aggregate/redistribute) предпочитаются полученным от соседей.
4. Длина AS-path (предпочитается меньшая). Добавление AS (prepending) увеличивает воспринимаемое расстояние.
5. Код Origin (IGP < EGP < Incomplete).
6. MED (предпочитается меньшее значение). Сравнивается только между путями от одной и той же соседней AS, если не включена опция bgp always-compare-med; bgp deterministic-med обеспечивает последовательное сравнение MED между пирами.
7. Предпочтение отдается eBGP перед iBGP.
8. Наименьшая метрика IGP до BGP next-hop (маршрутизация по принципу «горячей картошки», hot-potato).
9. Предпочтение самому старому маршруту для уменьшения нестабильности (если включено, с учетом dampening/multipath).
10. Правила разрешения ничьей: минимальная длина cluster-list, наименьший originator-ID, наименьший BGP router-ID соседа и, наконец, наименьший IP-адрес соседа.

Примечания по проектированию и возможные проблемы:

• Достижимость next-hop является основополагающим фактором. Путь может быть выбран как наилучший в BGP, но рекурсивный поиск в CEF может завершиться неудачей, если next-hop не разрешен.
• При анонсировании маршрутов в iBGP, полученных из eBGP, не забывайте про next-hop-self; в противном случае iBGP-маршрутизаторы могут посчитать eBGP next-hop недостижимым и отбросить трафик.
• Атрибут MED часто понимают неправильно; без always-compare-med значения MED от разных соседних AS не будут сравниваться, что приводит к значениям, которые кажутся «проигнорированными».

Инструменты политик: атрибуты, Communities и фильтрация

• Local Preference, Weight, AS-path prepending, MED
  • Предпочитайте провайдера с низкой задержкой, повышая LOCAL_PREF для его маршрутов (например, set local-preference 200). Это изменяет выбор исходящего трафика во всей AS, не затрагивая плоскость данных IP.
  • Weight действует только локально; используйте его для предпочтений на конкретном маршрутизаторе (neighbor 198.51.100.1 weight 50 или через route-map с set weight).
  • AS-path prepending (set as-path prepend 65000 65000 …) делает путь менее привлекательным для входящего в вашу AS трафика, увеличивая воспринимаемое расстояние. Применяйте выборочно; чрезмерное использование снижает доступность.
  • MED (set metric) предлагает вашему соседу точку выхода в вашу AS. Его эффект зависит от политики соседа.
• Политика на основе Communities
  • Отправка communities не происходит автоматически; включите её с помощью neighbor x send-community [both | extended].
  • Общеизвестные communities: no-export, no-advertise, internet, local-AS и no-export-subconfed (полезно при использовании конфедераций).
  • Стандартные communities — это 32-битные значения (формат AA:NN с ip bgp community new-format).
  • Расширенные (Extended) communities (64-битные) несут дополнительную семантику (например, route-targets в VPNv4).
  • Большие (Large) communities (96-битные, A:B:C) обеспечивают масштабируемость и ясность при использовании 4-байтовых ASN.
  • Пример: сопоставление community и установка атрибутов
    • ip community-list standard PREFERED permit 65000:100
    • route-map INBOUND-POLICY permit 10 match community PREFERED set local-preference 200
• Фильтрация по префиксам и AS-path
  • ip prefix-list контролирует гранулярность NLRI; as-path access-list использует регулярные выражения для ограничения путей AS. Оба применяются с помощью route-map или напрямую через neighbor … prefix-list/as-path access-group.
  • Входящая и исходящая фильтрация:
    • Входящая фильтрация определяет, что попадает в вашу таблицу BGP, и влияет на выбор лучшего пути.
    • Исходящая фильтрация контролирует то, что вы анонсируете; неправильно применённый исходящий route-map может неожиданно изменить атрибуты на локально сгенерированных маршрутах (например, добавление локальной AS ко всем анонсам приведёт к тому, что внешние соседи увидят ваш префикс на расстоянии двух, а не одного AS-хопа). Всегда ограничивайте route-map явными условиями сопоставления (match).
  • Минималистичная, целенаправленная политика уменьшает колебания (churn) и помогает избежать «чёрных дыр» (blackholing). Всегда включайте разрешающее правило в конце prefix-list, чтобы избежать непреднамеренных запретов.

Краткие, целенаправленные примеры конфигурации:

• Повышение local preference для маршрутов от провайдера ISP-A:
  • route-map SET-LP permit 10 set local-preference 200
  • neighbor 203.0.113.1 route-map SET-LP in
• AS-path prepend для определённого исходящего анонса:
  • ip prefix-list OUT-ONLY permit 192.0.2.0/24
  • route-map PREPEND permit 10 match ip address prefix-list OUT-ONLY set as-path prepend 65000 65000
  • neighbor 198.51.100.1 route-map PREPEND out

Масштабирование iBGP и расширенное поведение

• Отражатели маршрутов (Route Reflectors, RR)
  • Заменяют полносвязную топологию iBGP (full mesh) путем назначения RR, которые отражают маршруты между клиентами и не-клиентами. Петли предотвращаются с помощью атрибутов originator-ID и cluster-list.
  • Cluster ID по умолчанию равен router ID отражателя маршрутов; при наличии нескольких RR используйте уникальные Cluster ID для предотвращения постоянных петель и улучшения разнообразия путей.
  • Компромиссы: RR могут приводить к неоптимальному выбору пути (скрытие пути). Это можно смягчить правильным размещением клиентов, использованием разнообразных кластеров, add-path и настройкой параметров bestpath.
• Конфедерации
  • Разделяют большую AS на подавтономные системы (sub-AS), которые взаимодействуют по eBGP внутри, но выглядят как единая AS снаружи.
  • Плюсы: уменьшает количество связей в iBGP mesh и радиус действия политик; Минусы: сложность в эксплуатации и возможные тонкости с MED/next-hop на границах подавтономных систем.
• Условное анонсирование и маршруты по умолчанию

  • Условное анонсирование позволяет анонсировать маршрут только при отсутствии/наличии другого маршрута.

undefined

• Анонсирование маршрута по умолчанию (Default-origination):
  • neighbor 198.51.100.1 default-originate [route-map RM] анонсирует 0.0.0.0/0 независимо от его наличия в RIB (где RM контролирует условия). Альтернативно, команда network 0.0.0.0 требует наличия соответствующего маршрута в RIB.
• Multipath (многопутевая маршрутизация)
  • Распределяйте нагрузку по нескольким равноценным путям BGP с помощью maximum-paths [ebgp|ibgp] n. Используйте bgp bestpath as-path multipath-relax, чтобы разрешить eBGP multipath по путям с разными AS-path при контролируемых условиях. В MPLS L3VPN команда maximum-paths ibgp n включает ECMP между PE-маршрутизаторами.
• Рекурсия маршрутов и сбои RIB
  • BGP устанавливает путь только в том случае, если для next-hop можно выполнить рекурсивный поиск до действующей записи в таблице пересылки, и если префикс еще не занят маршрутом с меньшей административной дистанцией.
  • Распространенные причины сбоев RIB (RIB-failure):
    • Существует маршрут с лучшей AD (connected/static/IGP).
    • Next-hop не разрешен (нет маршрута IGP/статического маршрута до next-hop).
    • Присутствует более длинный, более специфичный маршрут (трафик будет соответствовать более специфичному маршруту).
  • Полезные проверки: show ip bgp <prefix>, show ip bgp rib-failure, show ip route [vrf NAME] <prefix> и проверки CEF для валидации рекурсии.
• Демпфирование (Dampening)
  • bgp dampening накладывает штрафы на флуктуирующие (нестабильные) префиксы и подавляет их до тех пор, пока они не станут стабильными. Параметры: half-life, reuse, suppress, max-suppress-time.
  • Компромиссы: может скрыть легитимное восстановление и замедлить сходимость. Применяйте точечно к нестабильным пограничным соединениям и избегайте демпфирования для маршрутов к ядру сети или критически важным для клиентов префиксам.

Систематический поиск неисправностей (отсутствующие префиксы и неверные пути):

1. Проверьте состояние сессии BGP: show ip bgp summary; если сессия нестабильна (flapping), проверьте CoPP и доступность по TCP/179.
2. Подтвердите применение политик на входе: show ip bgp neighbors x received-routes/advertised-routes; убедитесь в наличии soft-reconfiguration или возможности route refresh при необходимости.
3. Проверьте next-hop: show ip bgp <prefix> и show ip route [vrf NAME] <next-hop>; исправьте проблемы с IGP/рекурсией перед настройкой атрибутов.
4. Проверьте фильтры: prefix-lists, as-path access-lists и communities; убедитесь, что у соседа настроена команда send-community.
5. Изучите атрибуты: weight/local-pref/AS-path/origin/MED; включите deterministic-med/always-compare-med где это необходимо.
6. Проанализируйте сбои RIB и специфичность маршрутов: маршрут connected/static/IGP с меньшей AD или более специфичный маршрут будет иметь приоритет над BGP.
7. Проверьте механизмы масштабирования: на RR следите за скрытием путей и петлями с cluster-list; в конфедерациях проверьте использование no-export-subconfed.

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

Компания Acme Manufacturing использует AS 65010 с двумя провайдерами: ISP-A (низкая задержка) и ISP-B (резервный). Acme использует iBGP между тремя магистральными маршрутизаторами с двумя отражателями маршрутов и анонсирует префикс 203.0.113.0/24. После добавления исходящего route-map на пограничном маршрутизаторе к ISP-B, удаленные площадки сообщают о возросшей задержке, а некоторые пути неожиданно начинают предпочитать ISP-B.

Подход:

1. Проверка состояния сессии и политик

   • show ip bgp summary и show policy-map control-plane, чтобы убедиться в отсутствии сбоев BGP из-за CoPP. Обоснование: нестабильность на уровне управления (control plane) вызывает постоянные изменения, которые могут маскировать эффект от применения политик.

2. Проверка достижимости next-hop

   • show ip bgp 203.0.113.0/24 и show ip route <next-hop>. Обоснование: рекурсивный поиск next-hop должен успешно завершаться, прежде чем атрибуты BGP будут иметь значение.

3. Анализ исходящей политики на ISP-B

   • show run | sec router bgp; просмотрите neighbor … route-map OUT out. Обоснование: слишком общие route-map могут непреднамеренно изменять все анонсируемые префиксы, включая те, что анонсируются локально.

4. Ограничение AS-path prepending для целевых NLRI

undefined

Обоснование: Точное соответствие ограничивает prepending только для целевого префикса и позволяет избежать изменения атрибутов других анонсов. Явное permit 20 гарантирует, что маршруты, не попавшие под условие, не будут отброшены.

5. Глобальное предпочтение ISP-A для исходящего трафика

undefined

Обоснование: LOCAL_PREF влияет на выбор исходящего пути во всей AS (чем выше значение, тем лучше) и является самым чистым инструментом для предпочтения провайдера с низкой задержкой.

6. Обеспечение распространения желаемого поведения через communities

undefined

Обоснование: Маркировка с помощью community позволяет принимать решения по маршрутизации на последующих устройствах (например, установка предпочтений на RR) и требует send-community для их распространения.

7. Проверка поведения RR и предотвращение скрытия путей

   • На обоих RR убедитесь в уникальности cluster-id и правильности назначения клиентов; включите bgp additional-paths send receive select best 2, если это поддерживается. Обоснование: В среде с несколькими выходами в интернет RR могут скрыть лучший путь. Additional-paths или тщательное проектирование топологии клиентов уменьшает вероятность неоптимального выбора.

8. Проверка результатов и состояния установки маршрута

   • show ip bgp 203.0.113.0/24 для проверки атрибутов weight/local-pref/AS-path/MED; подтвердите, что eBGP-маршрут предпочитается iBGP-маршруту и проверьте метрику IGP до next-hop.
   • show ip bgp rib-failure, чтобы убедиться, что выбранный путь установлен в RIB. Обоснование: Это подтверждает, что и уровень управления (control plane), и уровень данных (data plane) отражают запланированную конфигурацию.

Эта последовательность исправляет непреднамеренные изменения AS-path (гарантируя, что внешние AS видят префикс Acme с желаемой дистанцией), устанавливает предпочтение ISP-A через LOCAL_PREF, сохраняет видимость политики с помощью communities и проверяет next-hop и установку маршрута, чтобы итоговая пересылка трафика соответствовала проекту.

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

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