Cisco 300-410: MPLS, VRF и сервисы VPN уровня 3 — Руководство по подготовке
Часть Cisco CCNP Enterprise 300-410 ENARSI — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Cisco, или пройдите тесты на время на ExamRoll.io.
Обзор
VPN-сети уровня 3 на базе Multiprotocol Label Switching (MPLS) разделяют маршрутизацию клиентов на виртуальные экземпляры маршрутизации и пересылки (VRF), используя при этом общее ядро провайдера для транспорта. Пограничные маршрутизаторы провайдера (PE) добавляют и удаляют стеки меток, чтобы маршрутизаторы ядра провайдера (P) осуществляли пересылку исключительно на основе меток, сохраняя масштабируемость и изоляцию. MP-BGP распространяет VPN-маршруты (VPNv4/VPNv6) с использованием Route Distinguishers (RD) для обеспечения уникальности и Route Targets (RT) для управления политиками импорта/экспорта. Правильное проектирование требует четкого разделения ролей клиента и провайдера, тщательного распределения меток и явных политик для утечки маршрутов (route leaking) и общих сервисов. Эксплуатация требует предсказуемых состояний на уровне управления (IGP, LDP/RSVP, MP-BGP) и детерминированного поведения на уровне данных (стекирование меток, PHP), а также строгой проверки и изоляции сбоев на границах CE–PE–ядро.
Пересылка MPLS и распределение меток
Формат и стек меток
- Промежуточный заголовок MPLS (shim header) содержит 20-битную метку, 3-битное поле Traffic Class (TC/EXP), 1-битный флаг Bottom of Stack (S) и 8-битное поле TTL.
- Пакеты несут стек меток: внешняя «транспортная» метка для LSP между PE-маршрутизаторами и внутренняя «VPN»-метка, идентифицирующая исходящий VRF на PE (или сервис).
- Penultimate Hop Popping (PHP) удаляет верхнюю метку на предпоследнем P-маршрутизаторе для снижения нагрузки на исходящий PE; можно использовать явную нулевую метку (explicit-null), чтобы сохранить верхнюю метку для поддержания семантики QoS/TTL до самого исходящего узла.
Основы LDP
- Маршрутизаторы P и PE обычно используют протокол внутреннего шлюза (IGP) для установления достижимости и протокол распределения меток (LDP) для сопоставления классов эквивалентной пересылки (FEC) с метками.
- LDP обнаруживает соседей с помощью hello-сообщений по UDP/646 и формирует сессии обмена метками по TCP/646, обеспечивая надежную сигнализацию меток. Targeted LDP (tLDP) может устанавливать сессии с несоседними маршрутизаторами (offlink sessions) для определенных FEC.
- Стили назначения/распространения меток:
- Независимое или упорядоченное управление (Independent vs ordered control): маршрутизатор может назначать метки для FEC, как только узнает о маршруте (независимое), или только после получения метки от своего следующего перехода (упорядоченное).
- Либеральное или консервативное удержание меток (Liberal vs conservative label retention): сохранять все полученные метки или только те, что пришли от лучшего следующего перехода, что является компромиссом между использованием памяти и скоростью сходимости.
- LDP router ID по умолчанию равен наибольшему адресу loopback-интерфейса, если он есть (иначе — наибольшему адресу активного интерфейса). Стабилизируйте его (и транспорт) во избежание разрыва сессий; рассмотрите возможность синхронизации LDP-IGP для предотвращения «черных дыр» (blackholing) во время сходимости.
Область действия уровня управления P-маршрутизатора
- Маршрутизаторы ядра (P) не содержат VPN-маршрутов; они работают только на уровне подложки (underlay) с IGP и сигнализацией меток (LDP или RSVP-TE). RSVP-TE может использоваться вместо LDP или вместе с ним для инжиниринга трафика.
Путь на уровне данных
- Входящий PE добавляет (push) VPN- и транспортную метки; P-маршрутизаторы меняют (swap) только внешнюю метку; предпоследний P-маршрутизатор снимает (pop) транспортную метку (если не используется explicit-null); исходящий PE снимает VPN-метку, выбирает VRF и пересылает пакет на основе обычного IP-поиска.
Практические команды для конфигурации (IOS/IOS XE)
- На интерфейсах, смотрящих в ядро: mpls ip
- Глобально: mpls label protocol ldp
- Проверка: show mpls ldp neighbor, show mpls ldp bindings, show mpls forwarding-table
Архитектура L3VPN: роли, VRF, RD, RT и MP-BGP
Роли и разграничения
- CE (Customer Edge): пограничное устройство клиента. Использует протокол для связи с PE (статический маршрут, eBGP, OSPF, EIGRP) и хранит маршруты клиента; не имеет информации об MPLS.
- PE (Provider Edge): пограничный маршрутизатор провайдера. Хранит VRF для каждого клиента, участвует в MP-BGP (VPNv4/VPNv6), а также добавляет/удаляет метки.
- P (Provider Core): ядро провайдера. Только коммутация по меткам; не хранит состояния VRF.
- Customer: клиент. Административный владелец CE и политик маршрутизации своего тенанта.
VRF и пересечение адресных пространств
- Каждый клиент (тенант) получает свой VRF (отдельные таблицы RIB/FIB). Допускается пересечение адресных пространств IPv4/IPv6 между клиентами.
- Route Distinguishers (RD) делают маршруты внутри VRF глобально уникальными, добавляя префикс «RD:» к префиксу сети для формирования NLRI VPNv4/VPNv6; RD не является механизмом безопасности и не управляет политиками.
- Route Targets (RT) — это расширенные BGP-атрибуты (extended communities), используемые для маркировки маршрутов при экспорте и выбора маршрутов для импорта в VRF. Политика на основе RT является основным средством контроля импорта/экспорта.
Семейства адресов MP-BGP
- VPNv4: AFI 1, SAFI 128. Атрибут MP_REACH_NLRI несет информацию о next-hop и VPN-метку для каждого маршрута. Маршруты VPNv4 распространяются только между PE-узлами (и отражателями маршрутов).
- VPNv6 (6VPE): AFI 2, SAFI 128. Позволяет создавать IPv6 VPN поверх ядра MPLS на базе IPv4. Next-hop в BGP может оставаться IPv4; PE назначает VPN-метки для каждого IPv6-маршрута.
- Включите передачу extended communities в BGP-сессиях между PE, чтобы передавались RT.
Упрощенный шаблон конфигурации (PE)
- Определение VRF и подключения CE:
- ip vrf CUST-A rd 65000:10 route-target export 65000:10 route-target import 65000:10
- interface GigabitEthernet0/0 ip vrf forwarding CUST-A ip address 10.0.0.1 255.255.255.252
- MP-BGP для VPNv4:
- router bgp 65000 neighbor 192.0.2.2 remote-as 65000 neighbor 192.0.2.2 update-source Loopback0 address-family vpnv4 neighbor 192.0.2.2 activate neighbor 192.0.2.2 send-community extended maximum-paths ibgp 2
- Семейства адресов для каждого VRF:
- address-family ipv4 vrf CUST-A redistribute connected
- address-family ipv6 vrf CUST-A redistribute connected
- Для 6VPE:
- address-family vpnv6 neighbor 192.0.2.2 activate neighbor 192.0.2.2 send-community extended
- Определение VRF и подключения CE:
Проверка
- show ip route vrf CUST-A
- show bgp vpnv4 vrf CUST-A
- show bgp vpnv6 vrf CUST-A
- show bgp vpnv4 all summary
Политики, утечка маршрутов, общие сервисы и сегментация
Политика импорта/экспорта RT
- Экспорт: помечает маршруты из VRF одним или несколькими RT. Импорт: VRF импортирует любой маршрут, чей RT совпадает с его списком импорта.
- Детальный контроль достигается с помощью route-maps для каждого VRF (карты экспорта/импорта), которые сопоставляют префиксы и устанавливают/изменяют RT. Это ограничивает непреднамеренное распространение маршрутов.
Методы утечки маршрутов
- Утечка на основе RT (рекомендуется): определите VRF для общих сервисов (Shared-Services VRF), экспортируйте префиксы сервисов с RT SVC и импортируйте RT SVC в выбранные VRF арендаторов. Используйте карты экспорта (export maps) на арендаторах, чтобы ограничить, какие маршруты арендаторов экспортируются обратно к сервисам.
- Локальная утечка между VRF (VRF-to-VRF): на некоторых платформах статические маршруты могут указывать на интерфейсы в других VRF, или BGP может устанавливать пиринговые отношения между VRF на одном и том же PE. Используйте с осторожностью; это обходит политику RT и может усложнить аудит.
- Компромиссы в области безопасности:
- Слишком разрешающие правила импорта приводят к связности «каждый с каждым» (any-to-any) и потенциальному горизонтальному перемещению.
- Симметричная утечка без фильтров может создавать петли обратной связи или раскрывать префиксы управления/инфраструктуры.
- Предпочитайте модель общих сервисов «звезда» (hub-and-spoke) с явными списками разрешений (route-maps) и взаимодействием с межсетевыми экранами.
Концепции сегментированной маршрутизации и миграция
- Сегментация в корпоративной сети начинается с VRF-Lite внутри кампусов и центров обработки данных. MPLS L3VPN расширяет эти сегменты через WAN без использования NAT, сохраняя возможность использования пересекающихся IP-адресов.
- Подход к миграции:
- Сопоставьте каждый локальный сегмент VRF-Lite с парой RT провайдера.
- Используйте маршрутизацию CE–PE (предпочтительно eBGP) для детерминированного обмена маршрутами для каждого сегмента.
- Внедрите VRF для общих сервисов (Shared-Services VRF) для DNS/AD/выхода в Интернет и импортируйте его выборочно.
- Транспортные сети (underlays), готовые к будущему:
- LSP на основе LDP или RSVP-TE широко распространены. Segment Routing MPLS (SR-MPLS) может заменить LDP/RSVP в транспортной сети (underlay), сохраняя сервисную модель L3VPN идентичной; только транспортная метка поступает от SR, а не от LDP/RSVP.
Операции: Уровень управления (Control Plane), Уровень данных (Data Plane), Верификация и Изоляция неисправностей
Сквозной путь прохождения пакета
- CE анонсирует префикс входящему PE в VRF X.
- Входящий PE устанавливает его в RIB/CEF для VRF X, помечает его экспортными RT, создает NLRI VPNv4/v6 (RD:префикс) и выделяет VPN-метку.
- MP-BGP анонсирует маршрут удаленным PE (или через route reflectors), передавая next-hop (loopback входящего PE) и VPN-метку.
- IGP и LDP/RSVP устанавливают транспортный LSP в направлении next-hop исходящего PE.
- Уровень данных (Data plane): входящий PE добавляет (push) VPN-метку (внутреннюю) и транспортную метку (внешнюю); P-маршрутизаторы меняют (swap) внешние метки; предпоследний P-маршрутизатор удаляет (pop) внешнюю метку (PHP); исходящий PE использует внутреннюю метку для выбора VRF и пересылает пакет на исходящий CE.
Распространенные режимы сбоев и компромиссы
- Недоступность в опорной сети (underlay) или падение LDP: MP-BGP может оставаться активным, но без транспортного LSP входящий PE не может добавить действительную внешнюю метку; пакеты отбрасываются. Используйте синхронизацию LDP-IGP для предотвращения «черных дыр» (blackholing).
- Отсутствие VPN-метки: маршрут VPNv4 присутствует, но нет метки (или метка 3 с непредвиденной семантикой), что нарушает пересылку. Убедитесь, что исходящий PE выделяет метки для каждого VRF; проверьте политики, которые могут подавлять анонс меток.
- Несоответствие RT: маршруты присутствуют в отправляющем VRF, но не импортируются получателем. Проверьте RT и убедитесь, что происходит обмен расширенными community (send-community extended).
- MTU/фрагментация: стеки меток добавляют накладные расходы. Убедитесь, что интерфейсы ядра и PE поддерживают достаточный MPLS MTU во избежание потерь; при необходимости скорректируйте MSS.
- QoS и PHP: сопоставление EXP-to-QoS может быть потеряно на исходящем узле, если верхняя метка удаляется. Используйте explicit-null для сохранения прозрачности QoS на последнем хопе.
- Выбор пути iBGP в VPNv4: без
maximum-paths ibgp Nможет использоваться только один путь, даже при наличии ECMP в ядре; включите multipath для балансировки нагрузки.
Процесс верификации
- Граница CE–PE:
undefined
,
undefined
или
undefined
- MP-BGP:
undefined
;
undefined
- Метки:
undefined
;
undefined
;
undefined
- Уровень данных:
undefined
;
undefined
или до loopback исходящего PE; проверка маркировки EXP/TC, если используется QoS
Работоспособность: рассмотрите использование BFD на соседствах CE–PE и PE–PE для защиты сессий маршрутизации.
Изоляция неисправностей между CE, PE и ядром провайдера
- Проверьте, что соседство CE–PE установлено и маршруты VRF существуют на входящем PE.
- Убедитесь, что маршрут экспортируется в VPNv4 с ожидаемым RT и VPN-меткой, присутствующей на исходящем PE.
- Убедитесь, что существует транспортный LSP от входящего до исходящего PE (соседства LDP/RSVP и метка в направлении loopback исходящего PE).
- Протестируйте доступность между PE с помощью ping/traceroute с loopback-интерфейса PE в качестве источника; проверьте консистентность ECMP.
- На исходящем PE проверьте, что VPN-метка разрешается в правильный VRF и интерфейс CE.
- Если все проверки на уровне управления проходят успешно, соберите счетчики уровня данных и проверьте поведение MTU и QoS.
Практический сценарий
Компания Contoso Manufacturing планирует мигрировать с WAN на базе VRF-Lite на MPLS L3VPN от провайдера, одновременно внедряя центральный VRF для общих сервисов (Shared-Services), таких как Интернет и DNS. Арендаторы A и B используют внутреннее адресное пространство 10.10.0.0/16 и должны оставаться изолированными друг от друга, за исключением выборочного доступа к общим сервисам.
Подход
- Определение VRF и политики RT на PE-маршрутизаторах
Конфигурация:
undefined
undefined
undefined
undefined
-
undefined
undefined
undefined
undefined
-
undefined
undefined
undefined
undefined
- Обоснование: RD обеспечивают уникальность пересекающихся маршрутов 10.10.0.0/16. RT определяют границы сегментации. Отдельный RT для Shared-Services создает контролируемый центральный узел (hub).
- Привязка интерфейсов CE к правильным VRF и настройка маршрутизации CE–PE
Пример конфигурации:
undefined
undefined
undefined
-
undefined
undefined
undefined
undefined
- Обоснование: eBGP между CE и PE обеспечивает четкие границы политик и контроль для каждого арендатора, не допуская утечки атрибутов между ними.
- Включение MP-BGP между PE и распространение RT и VPN-меток
Конфигурация:
undefined
undefined
undefined
undefined
undefined
undefined
undefined
- Обоснование: Анонсы VPNv4 переносят как RT, так и VPN-метки для каждого маршрута; включение iBGP multipath подготавливает к использованию ECMP по нескольким путям через RR/PE.
- Построение и проверка транспортных LSP в ядре сети
Конфигурация:
undefined
-
undefined
undefined
undefined
- Обоснование: LDP создает LSP между PE для внешней метки. ECMP в IGP вместе с LDP обеспечивает масштабируемость и быструю сходимость. Проверяйте с помощью
show mpls ldp neighborиshow mpls forwarding-table.
- Реализация выборочной утечки маршрутов для Shared-Services
Конфигурация (на арендаторах):
undefined
undefined
-
undefined
undefined
-
undefined
undefined
undefined
undefined
-
undefined
undefined
-
undefined
- Обоснование: Арендаторы импортируют только маршруты из Shared-Services; Shared-Services импортирует маршруты арендаторов, но экспортирует обратно только разрешенные префиксы, чтобы арендаторы не узнали маршруты друг друга через центральный узел.
- Проверка уровней управления и данных, а также MTU/QoS
Команды:
undefined
-
undefined
-
undefined
-
undefined
-
undefined
- Обоснование: Подтверждает маршрутизацию в VRF, привязки меток и сквозную доступность. Проверьте MTU на интерфейсах, чтобы учесть стек меток и сохранить маркировку QoS; включите explicit-null, если на исходящем узле требуется видимость поля EXP.
- Внедрение IPv6 VPN с использованием 6VPE
Конфигурация:
undefined
undefined
undefined
-
undefined
undefined
- Обоснование: Обеспечивает сегментацию IPv6 через то же ядро MPLS на базе IPv4 с использованием VPN-меток для каждого маршрута и той же модели политик на основе RT.
Этот поэтапный план сохраняет сегментацию, обеспечивает контролируемый общий доступ, масштабируется за счет коммутации по меткам в ядре и предоставляет четкие точки верификации для быстрой изоляции неисправностей.
← Перераспределение маршрутов и маршрутизация на основе политик · Все домены · Многоадресная маршрутизация и распределение →
Отработать эти вопросы → · Тесты на время на 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.
Сдайте экзамен →