Универсальный Сisco ip ngn транспорт в сетях операторов...
DESCRIPTION
TRANSCRIPT
Универсальный Сisco IP NGN транспорт в сетях операторов мобильной и фиксированной связи
Андрей Вишняков Customer Solutions Architect
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Public Presentation_ID 2
Unified MPLS Архитектура
Соображения по архитектуре o Предлагается использовать MPLS как в статической, так и в динамической форме
o В перспективе MPLS расширяется до уровня доступа, требуется динамическое развертывание сервисов для упрощения управления
o Операторы начинают со статической или гибридной модели, но в будущем имеет смысл планировать динамическую
(S-PE) (S-PE) T-PE Basic L2 PE T-PE
Basic L2 PE
End-to-End Pseudo-wire Динамика или статика Динамика или
статика Динамический IP/MPLS Control Plane
Требования NGN сетей o Поддержка больших сетей
ü 2000+ маршрутизаторов, например o Распределенные произвольно Сервисы по сети
ü Сервисная граница может быть где угодно на транспортной сети
o End-to-End доступность ü v4/v6 Uni/Multicast сервисы
o Быстрое восстановление ü Чем ближе время восстановления к 0 мс, тем лучше
o Масштабируемость и производительность
Сложности построения MPLS сетей o Масштабируемость по количеству идентификаторов PE устройств, известных на сети
o Сложность достижения 50 мс сходимости за счет MPLS FRR o Необходимость использования достаточно сложных протоколов маршрутизации
o Разделение сети на домены (IGP, EGP) в то время как требуется организовывать End-to-End сервисы
Unified MPLS должен упростить развертывание сервисов
o В классических транспортных сетях сервисы должны быть сконфигурированы на каждом транзитном устройстве. Система управления должна знать топологию сети
o Нашей задачей является уменьшение количества точек администрирования. o Только интеграция MPLS зон доступа, агрегации и ядра может минимизировать количество точек администрирования
o Unified MPLS архитектура в конечном счете должна позволить создавать End-to-End сервисы только за счет конфигурации конечных PE устройств
MPLS MPLS MPLS MPLS Access Aggr. Aggr.
LER LSR. LER Aggr. Aggr. Access
Точки администрирования
Unified MPLS построение сети
Агрегация Граница Ядро
MPLS (TP) (VPWS/VPLS),OTN and DWDM IP/MPLS IP/MPLS L3 IP + Services Placement
Circuit Emulation + Ethernet
Ethernet Access MPLS-TP Access
SONET/SDH
MPLS-TP Access
IP/MPLS Access Ethernet Access
SONET/SDH
Ядро Агрегация
L3 IP + Services Placement Circuit Emulation + Ethernet
Unified MPLS Архитектура
Классическая NGN Архитектура
Flexible Service Edge IP/MPLS (L3 VPN, L2 (VPWS, VPLS/EVPN)
Технологии в рамках Unified MPLS o LDP Downstream On Demand для узлов доступа
ü Не требует поддержки больших таблиц IP маршрутизации ü Упрощает конфигурацию, нет динамической маршрутизации
o MPLS-TP как альтернатива на сетях доступа o Loop Free Alternates для 50 мс сходимости без дополнительного конфигурирования
o RFC 3107 распределение меток с помощью BGP для создания MPLS иерархии
o BGP Prefix Independence Convergence для быстрого восстановления 3107 сетей
o MPLS OAM интеграция с Ethernet OAM
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Public Presentation_ID 9
MPLS на уровне доступа
В чем сложность развертывания MPLS на доступе
Transport CPE 0000s–00000s
Access Nodes 10,00s–100,000s
Distribution Nodes 100s–1,000s
IP Edge Nodes 10–100s
Core Nodes few–10s
Aggregation Nodes 1,000s–10,000s
Здесь поведение MPLS хорошо понятно Фокус Затруднения с использованием MPLS на доступе: 1. Узлы с ограниченной MPLS функцональностью, LFIB & кол-во маршрутов 2. Размер IGP области и нагрузка на CPU при пересчете SPF 3. Однако нужно поддерживать End-to-End LSP через всю сеть
LDP Downstream on Demand
D1
PE11
PE12 IP/MPLS control plane
1.1.1.1
Default Static Route
0/0
0/0
o Узлы доступа остаются предельно простыми ü нет IGP, нет BGP, static default routes указывает на PE
LDP Downstream on Demand
o Сервис настраивается на узле доступа o Команда xconnect запускает LDP запрос на получение метки удаленного PE
D1
PE11
PE12
1.1.1.1 Конфигурация сервиса
Port P xconnect 1.1.1.1
Конфигурация сервиса
LDP DoD Request (1.1.1.1)
LDP DoD Request (1.1.1.1) IP/MPLS control plane
LDP Downstream on Demand
D1
PE11
PE12
1.1.1.1 LDP DoD Reply (L=21)
LDP DoD Reply (L=31) IP/MPLS control plane
o Локальный PE отвечает с меткой, соответствующей удаленному PE o Локальный PE содержит полную маршрутную информацию
LDP Downstream on Demand
D1
PE11
PE12
1.1.1.1
IP/MPLS control plane
o End-to-End сервис с основным и резервным путями
LDP Downstream on Demand o Упрощение конфигураций узлов доступа
ü нет IGP, нет BGP o Узлы доступа могут поддерживать LSP к любому другому узлу o На доступе известны только те MPLS метки, что требуются o Просто и масштабируемо o Переиспользование существующих технологий (надежность)
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Public Presentation_ID 16
Бесшовный MPLS
IP маршрутизация и MPLS дизайн Что необходимо обеспечить …. o PE-to-PE маршруты (и Label Switched Paths)
ü PE должны иметь /32 маршруты к другим PE ü PE расположение не имеет значение
o Единая BGP ASN
Ядро Доступ . Регион1
.
Агрегация
PE11 PE21
Регион 2 Доступ Агрегация
IP маршрутизация и MPLS дизайн Если следовать традиционному подходу … o Объявить инфраструктурные (т.е. PE) маршруты в IGP o Объявить инфраструктурные (т.е. PE) метки в LDP o Сегментировать IGP домены (т.е. ISIS L1/L2 или OSPF Areas)
Доступ . Регион 1
.
Агрегация
PE11 PE21
Ядро
ISIS Level 2 или
OSPF Area 0 ISIS Level 1
или OSPF Area Y
BGP для сервисов
End-to-End IGP & LDP для инфраструктуры Доступ Регион 2 Агрегация
ISIS Level 1 или
OSPF Area X
IP маршрутизация и MPLS дизайн Традиционный подход имеет очевидные ограничения … o Большая IGP таблица маршрутизации
ü Долгая сходимость сети
o Большой IGP домен ü Стабильность сети
o Большая LDP таблица меток
IP маршрутизация и MPLS дизайн ‘Разделяй & Контролируй’ – Наша стратегия o Разделить & Изолировать IGP домены
ü Не требуется редистрибуция IGP маршрутов между областями o Использовать BGP для инфраструктурных (т.е. PE) маршрутов
ü Также для соответствующих (т.е. PE) меток
Ядро Доступ . Регион 1
.
Агрегация
PE11 PE21
ISIS Level 2 Or
OSPF Area 0 ISIS Level 1
Or OSPF Area Y
Изолированные IGP & LDP Изолированные IGP & LDP Изолированные IGP & LDP BGP для инфраструктурных маршрутов BGP для сервисов
Доступ Регион 2 Агрегация
ISIS Level 1 Or
OSPF Area X
Доступ Агрегация Регион 2
IP маршрутизация и MPLS дизайн Разделяй & Контролируй – Конечный результат Пример - ‘PE31’ доступность o Маршрутизация – RIB/FIB Таблицы o Передача данных – поток от PE11 к PE31
Ядро Доступ . Регион 1
.
Агрегация
PE21
ISIS Level 2 или
OSPF Area 0 ISIS Level 1
или OSPF Area Y
ISIS Level 1 или
OSPF Area X
PE31 :: next-hop = P1; BGP; label = L100; BGP P11 :: Next-hop = P11; IGP label = L200; LDP
PE31 :: next-hop = P2; BGP label = L101; BGP P2:: Next-hop = P100; IGP Label = L201; LDP
PE11
P1
P11
P2
PE31 :: next-hop = P31; IGP Label = L110; LDP
IP L200 L100 IP L110
IP IP L201 L101 P100
IP маршрутизация и MPLS дизайн Разделяй & Контролируй – Что должно получиться o IGP ограничен передачей только внутренних маршрутов
ü Не нулевая OSPF или ISIS L1 области содержат только собственные маршруты
ü Ядро также содержит только маршруты своей области
o PE редистрибутирует свой loopback в IGP, а также в iBGP+Label
o PE устанавливает iBGP соседство с локальными ABR ü ABR выступают в роли Route-reflector ü ABR распространяют _только_ инфраструктурные (т.е. PE) маршруты
o ABR в роли RR изменяет BGP Next-hop на себя (nexthop-self) ü Для всех BGP распространяемых маршрутов
o PE устанавливают отдельные соседства для Сервисов (например, VPN)
Доступ Регион 2 Агрегация
IP маршрутизация и MPLS дизайн Разделяй & Контролируй 1. IGP ограничен передачей только локальных маршрутов
ü Не нулевая или L1 область содержат только внутренние маршруты
ü Ядро также содержит только локальные маршруты
Ядро Доступ . Регион 1
.
Агрегация
PE11 PE21
ISIS Level 2 или
OSPF Area 0 ISIS Level 1
или OSPF Area X
ISIS Level 1 или
OSPF Area Y
1
ABR ABR
Изолированный IGP Изолированный IGP Изолированный IGP
Доступ Регион 2 Агрегация
IP маршрутизация и MPLS дизайн Разделяй & Контролируй 1. PE редистрибутирует свой loopback в IGP протокол, а также в iBGP с
одновременным присвоением BGP маршруту MPLS метки (bgp send-label)
Ядро Доступ . Регион 1
.
Агрегация
PE11 PE21
ISIS Level 2 или
OSPF Area 0
ISIS Level 1 или
OSPF Area X ISIS Level 1
или OSPF Area Y
2
Loopback интерфейс редистрибутируются в IGP и BGP+label
ABR ABR
Доступ Регион 2 Агрегация
IP маршрутизация и MPLS дизайн Разделяй & Контролируй 1. PE устанавливает iBGP+label соседство с локальными ABR, при
этом ü ABR выступают в роли Route-Reflector ü ABR обрабатывают _только_ инфраструктурные (т.е. PE)
маршруты ü RR'ы присутствуют в ядре сети
Ядро Доступ . Регион1
.
Агрегация
PE11 PE21
ISIS Level 2 или
OSPF Area 0 ISIS Level 1
или OSPF Area X
ISIS Level 1 или
OSPF Area Y
iBGP+Label соседство
3
ABR ABR
Доступ Регион 2 Агрегация
IP маршрутизация и MPLS дизайн Разделяй & Контролируй 1. ABR в роли RR изменяет BGP Next-hop на себя (next-hop-self) ü Для каждого анонсируемого BGP маршрута
Ядро Доступ . Регион 1
.
Агрегация
PE11 PE21
ISIS Level 2 или
OSPF Area 0
ISIS Level 1 или
OSPF Area X ISIS Level 1 или
OSPF Area Y
ABR устанавливает в роли BGP NH себя
4
ABR ABR
BGP Prefix PE31: Next-hop = P1; Label=L100
BGP Prefix PE31: Next-hop = P2; Label=L101
BGP Prefix PE31: Next-hop = PE31; Label=null
P1 P2
ABR устанавливает в роли BGP NH себя
Доступ Регион 2 Агрегация
IP маршрутизация и MPLS дизайн Разделяй & Контролируй 1. PE устанавливают отдельные iBGP соседства для Сервисов ü Выделенные RR для IPv4/6, VPNv4/6, L2VPN и т.д. ü Детали по масштабируемости BGP для сервисов чуть позже …
Ядро Ядро . Region1
.
Агрегация
PE11 PE21
ISIS Level 2 или
OSPF Area 0 . .
5
ABR ABR
RR’ы RR’ы RR’ы
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Public Presentation_ID 55
Масштабируемость BGP Route Reflector
Типовой BGP Route-Reflector дизайн "Плоская" топология o RR обычно устанавливаются парой на кластер
o PE устанавливают соседство только с парой локальных RR, таким образом количество iBGP сессий на PE ограничено 2-мя
o В данной модели RR’ы могут масштабироваться по количеству BGP сессий путем разбиения сети на большее кол-во кластеров или внедрения RR иерархии
o Проверенная временем надежная модель
Регион 1 Регион 2 Регион 3 Регион 4 Регион 5
PE PE PE PE PE
RR’ы RR’ы RR’ы RR’ы RR’ы
o Количество известных префиксов одинаково для всех RR.
o Любая нестабильность (при отсутствии dampening), «дрожание» PE-CE каналов или префиксов распространяется на всю сеть
o Время сходимости пропорционально количеству префиксов и количеству BGP соседств
o При перезагрузке RR, сбросе BGP сессии, все RR должны обрабатывают BGP таблицу маршрутизации
Масштабируемый BGP Route-Reflector дизайн Несколько RR плоскостей
o RR могут быть разделены по нескольким RR плоскостям - в каждой плоскости передается часть VPN префиксов
o Все RR кластера отдельной плоскости должны быть полносвязны
o Каждый PE устанавливает соседство с парой RR в основной плоскости и парой RR во вторичной плоскости региона o Поддерживаются send и receive BGP отношения только с основной плоскостью RR и принимается часть маршрутов
o PE не посылает свои маршруты RR вторичной плоскости o Поддерживаются только receive BGP отношения с RR вторичной плоскости для получения оставшихся префиксов
o Нет BGP связности между плоскостями
RR плоскости
Плоскость#1
Плоскость#2
Регион 1 Регион 2
RR
PE
PE
PE
PE
Send/Receive ReceiveOnly Primary Peer Secondary Peer
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Public Presentation_ID 32
Быстрое восстановление сервисов
Быстрое восстановление (Fast Restoration) o Быстрое восстановление сервисов, т.е. BGP префиксов
ü BGP Prefix Independent Convergence (PIC) o Быстрое восстановление BGP next-hop, т.е.IGP префиксов
ü IP-FRR, LDP-FRR или TE-FRR o Предлагается обсудить вначале ‘IGP префиксы’ …
ü BGP PIC рассматривается в следующем разделе …
Быстрое восстановление (Fast Restoration) IGP Префиксы o TE-FRR и IP-FRR наиболее распространенные механизмы
В обоих случаях заранее устанавливаются запасные маршруты
o IP-FRR (LFA) проще чем TE-FRR Проще конфигурировать и управлять Не требуется поддержка всех устройств сети Применимость зависит от сетевой топологии
o IP-FRR (LFA), совместно с LDP LSP, обеспечивает MPLS FRR Также просто конфигурировать и управлять Не требуется поддержка всех устройств сети Применимость зависит от сетевой топологии
o Используйте IP-FRR & LDP-FRR, а TE-FRR только, когда это требуется o MPLS-TE в том числе для управления полосой пропускания, потоками данных (Traffic Engineering)
Быстрое восстановление (Fast Restoration) IGP Префиксы o IGP FC: быстрая IGP сходимость одно из основных требований к
NGN сетям o IP/LDP LFA: имеет смысл использовать как intra PoP FRR решение
ü Может применяться в случае inter PoP с MPLS-TE туннелями для поддержки произвольных топологий
o MPLS FRR: используется как inter PoP FRR решение ü Или TE-FRR, или LDP-FRR
PoP
PoP PoP
PoP
PE P
P
PoP Intra PoP Inter PoP
Быстрое восстановление (Fast Restoration) Требования
o Определение отказа узла/канала как можно быстрее ü BFD, keep-alive на Layer 2, Alarms, IGP fast hellos, Резервирование
o Транслировать сообщение об отказе — оптимизация генерации LSP/LSA пакетов
o Распространить информацию об отказе по сети o Пересчитать маршруты (запустить SPF) либо с помощью
incremental SPF или полного SPF алгоритма o Установить новые маршруты в таблицу маршрутизации/ коммутации с учетом приоритета префиксов o CRITICAL: IPTV SSM источники o HIGH: наиболее важные PE o MEDIUM: все остальные PE o LOW: оставшиеся префиксы
Необходимо
для
FRR
Необходимо для
Fast
Con
verg
ence
Быстрое восстановление (Fast Restoration) IGP настройка для FC
o OSPF Event Propagation ü timers pacing flood value ü timers pacing retransmission value ü значения по умолчанию 33 мс/66 мс
o OSPF Subsecond Hellos Configuration: ü ipospf dead-interval minimal hello-
multiplier value ü Значения в диапазоне 3–20
o OSPF LSA Generation Exponential Backoff ü timers throttle lsa all lsa-start
lsa-hold lsa-max ü timers lsa arrival timer
o OSPF SPF Exponential Backoff ü Timers throttle spfspf-start spf-
hold spf-max ü Все LSA/SPF значения в мс
o IS-IS hello interval/ Hello Multiplier ü isis hello-interval { seconds | minimal } ü isis hello-multiplier value ------- Значения в диапазоне 3–20
o IS-IS LSP-Generation Exponential Backoff ü lsp-gen-interval lsp-max lsp-start lsp-
hold
lsp-max—(сек) lsp-hold—(мс) lsp-start—(мс)
o IS-IS Event Propagation ü lsp-interval value ü Значение по умолчанию - одно LSP каждые 33 мс
o Fast LSP Flooding ü fast-flood lsp-number (устарело ip fast-
convergence)
o IS-IS SPF Exponential Backoff ü spf-interval spf-max spf-start spf-hold <spf-max>- (сек) <spf-start> - (мс) <spf-hold> - (мс)
ü prc-interval prc-max prc-start prc-hold <prc-max>- (сек) <prc-start> - (мс) <prc-hold> - (мс)
Тюнинг OSPF параметров Тюнинг IS-IS параметров
Отметим:
MinLSArrival Значение должно быть <= lsa-hold
Быстрое восстановление (Fast Restoration) IP FRR o IP FRR (Loop Free Alternates) различают двух типов
ü Per-Link LFA – защита всех маршрутов доступных через резервируемый канал
ü Per-Prefix LFA – защита каждого маршрута доступного через данный next-hop или узел
o IP FRR (LFA) применим для большинства SP топологий
ü http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-applicability-03
Быстрое восстановление (Fast Restoration) IP FRR : per-Link LFA
S F
R1
D
Primary Path Repair Path
Route D Primary Next Hop: F Backup Next Hop: R1
Per-link LFA это сосед, который может использоваться в качестве альтернативного next-hop для всего трафика, проходящего по резервируемому каналу
o IGP рассчитывает основной маршрут, а также запасной
o FIB таблица содержит в том числе запасной маршрут
o В случае отказа канала весь трафик переводится на альтернативный маршрут/ канал менее чем за 50 мс
o После того, как сойдется IGP, трафик может переключиться на лучший маршрут без потерь
o Реализуется prefix independent convergence
o Запасные маршруты локальны на каждом узле - не требуется расширения существующих протоколов
o Per-hop behavior (no Network-wide deployment requirement)
o Простота конфигурации IS-IS или OSPF per-Link или per-prefix LFA FRR
S F
R1
D
Route D NH: F, LFA: R1
Route D NH:F
R2 R3
Быстрое восстановление (Fast Restoration) IP FRR : per-Link LFA o Доступность запасного NH зависит от топологии и метрик каналов o "Треугольные" топологии обычно удобны для IP FRR – для колец можно использовать MPLS-TE туннели
o В конечном итоге все зависит от назначенных метрик
10 10
10
10
10 10
Route D NH: F LFA: no
Route D NH: S
RP/0/0/CPU0:ospf-3-2(config)#router ospf 1 RP/0/0/CPU0:ospf-3-2(config-ospf)#area 0 RP/0/0/CPU0:ospf-3-2(config-ospf-ar)#int pos 0/3/0/0 RP/0/0/CPU0:ospf-3-2(config-ospf-ar-if)#fast-reroute per-link enable
pos 0/3/0/0
Быстрое восстановление (Fast Restoration) IP FRR : per-Prefix LFA
Рассчитывается & устанавливается запасной маршрут для каждого активного IP маршрута
ü Ищется сосед, у которго основной маршрут не проходит через резервируемый next-hop
Быстрое восстановление (Fast Restoration) IP FRR : per-Prefix LFA
Произвольные топологии могут быть LFA резервированы ü MPLS-TE между A и B может зарезервировать весь трафик от/до A:
A/S, A/B, A/T, A/D1, A/D2
Быстрое восстановление (Fast Restoration) MPLS-TE FRR o MPLS-TE FRR link protection (и prefix independent): <50 мс
ü Проще всего использовать с Auto-tunnel o MPLS-TE FRR node protection (и prefix independent):
ü <100 мс (зависит от времени определения отказа узла) o MPLS-TE FRR path protection (и prefix independent):
ü Время восстановления зависит от времени передачи RSVP-TE служебного сообщения до LSP инициирующего маршрутизатора (не локальный механизм)
ü Сложнее контролировать благодаря end-end / 1:1 защите ü Применяется в специфичных сценариях
Отметим: MPLS-TE предоставляет FRR механизм совместно с • Управлением полосой пропускания каналов связи • Управление потоками данных (Traffic Engineering) • Не зависит от топологии как IP LFA
Быстрое восстановление (Fast Restoration) MPLS-TE FRR – Link Protection
Router C
Router D Router A Router B Router E
interface Tunnel0 tunnel destination Router D tunnel mpls traffic-engineering path-options explicit-path C-D
interface POS0/0 mpls traffic-eng backup-path Tunnel0
interface Tunnel0 tunnel destination Router E .. etc ... tunnel mpls traffic-eng fast-reroute
x
Быстрое восстановление (Fast Restoration) MPLS-TE FRR – Node Protection o Что произойдет при отказе D маршрутизатора?
o Защита канала здесь не поможет, т.к. запасной туннель терминируется на D маршрутизаторе, выступающим в роли NHop резервируемого интерфейса
o MPLS-TE FRR запасной туннель должен идти к next-hop ЗА резервируемым каналом (NNhop)
Router D
Router C
Router A Router B Router E
Fast ReRoute Backup Tunnel
NHop
Protected Link Router F
Fast ReRoute Backup Tunnel
NNHop
IP FRR MPLS TE FRR
Запасной маршрут На основе минимальной метрики С учетом требуемой полосы пропускания
SRLG Поддерживается Поддерживается
Link Protection Поддерживается Поддерживается
Node Protection Поддерживается Поддерживается
Path Protection Не поддерживается Поддерживается
Control Plane требования Отсутствуют для LFA RSVP-TE
Балансировка нагрузки по нескольким путям Поддерживается Не поддерживается
Сложность конфигурации Минимальная Значительная
Зависимость от топологии Да (эффективно для полносвязных и небольших кольцевых топологий с использованием MPLS-TE туннелей)
Нет
Быстрое восстановление (Fast Restoration) IP FRR (LFA) vs. MPLS TE FRR
Быстрое восстановление (Fast Restoration) Что в итоге …
o Используйте IP FRR (LFA), где это возможно ü LFA проще, локален (не требует поддержки со стороны
взаимодействующих устройств) o Используйте MPLS FRR (LDP + LFA), где это возможно o Используйте TE FRR, если это явно необходимо
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Public Presentation_ID 48
Быстрое восстановление BGP PIC (Prefix Independent Convergence)
Что такое PIC или BGP FRR? o PIC дает возможность переключиться на запасной маршрут (next-hop) за минимальное время вне зависимости от количества ассоциированных префиксов
o BGP Fast Reroute (BGP FRR)— позволяет BGP использовать альтернативный маршрут при выходе из строя основного, минимальное время переключения
o Протоколы маршрутизации (например, BGP) с поддержкой PIC или FRR используют запасные маршруты
o При отсутствии запасных маршрутов ü Сходимость определяется протоколом маршрутизации, обновляющим RIB и FIB по одному префиксу за раз - время сходимости прямо пропорционально количеству резервируемых маршрутов
o При наличии запасных маршрутов ü Альтернативные маршруты уже в RIB/FIB
ü Предсказуемое и постоянное время сходимости вне зависимости от числа маршрутов
VPN1 Сайт 1
VPN1 Сайт 2
1
3
1. PIC core – в случае изменения IGP маршрута 2. PIC edge – при отказе удаленного PE или его подключения 3. PIC edge – при отказе PE-CE канала
PIC Edge vs. PIC Core
PE3
PE1
PE2 2 CE1
CE2
BGP PIC Edge PE-CE Link Protection
o PE1 и PE2 рассчитываю запасной bgp маршрут, используя bgp best-external подход
o В случае отказа основного PE1 - CE1 канала: ü PE1 сохраняет локальную bgp сервисную метку в таблице коммутации и транслирует приходящий для CE1 трафик к PE2, используя маршрут/ метку анонсированные PE2
ü Через определенное время локальные метки будут удалены ü PE3 к этому времени должен использовать PE2 маршрут для трафика к CE1
CE2 PE1
PE2 CE1
PE3 MPLS-VPN
Normal Path Backup Path
router bgp 100 address-family ipv4 vrf V1 bgp advertise-best-external
router bgp 100 address-family ipv4 vrf V1 bgp additional-paths install
BGP PIC Edge PE-Node Protection
o PE1, PE2 и PE3 рассчитывают запасной bgp маршрут o При отказе PE1 узла:
ü IGP протокол маршрутизации на PE3 удаляет путь к PE1 ü Переход на запасной маршрут ü PE3 должен использовать BGP сервисную метку PE2 для трафика к CE1
CE2 PE1
PE2 CE1
PE3 MPLS-VPN
Normal Path Backup Path
P
Сходимость при использовании и без PIC BGP PIC Core и PIC Edge
o При изменении next-hop, отказе канала в ядре при не использовании Core PIC, время сходимости зависит от количества затронутых маршрутов
o PIC функциональность позволяет минимизировать время сходимости и сделать его предсказуемым
o Без Edge PIC время сходимости - функция от количества префиксов
o PIC функциональность позволяет минимизировать время сходимости и сделать его предсказуемым
PIC Core PIC Edge
Спасибо!
Просим Вас заполнить анкеты. Ваше мнение очень важно для нас.