Конфигурация и особенности BGP: Prefix-Independent Convergence

© 2011 Cisco and/or its affiliates. All rights reserved. 1
Конфигурация и
особенности BGP:
Prefix-Independent
Convergence
Наталья Омельянюк
Инженер европейского центра технической поддержки Cisco TAC
21.05.2013
Cisco Support Community Expert Series
Webcasts in Russian:

Сегодня на семинаре эксперт Cisco Наталья Омельянюк
расскажет об особенностях BGP: Prefix-Independent Convergence и
ее конфигурации.
Наталья Омельянюк
Инженер европейского центра
технической поддержки Cisco TAC
2
Expert’s photo

Сегодняшняя презентация включает опросы аудитории
Пожалуйста, участвуйте!

4© 2011 Cisco and/or its affiliates. All rights reserved.
https://supportforums.cisco.com/docs/DOC-33272

Используйте Q&A панель, чтобы послать вопрос. Наши эксперты
ответят на них

a) Нет не знаком. Это новая для меня технология.
b) Я знаю о сушествовании этой технологии, но не
имею практического опыта
c) Я имею опыт работы с этой технологией в тестовой
среде
d) Технология BGP PIC используется в production среде
Знакомы ли Вы с технологией BGP PIC и ее
применением на устройствах Cisco?

• Вступление
• Особенности сходимости протокола BGP
• Как работает BGP PIC
• Варианты дизайна для применения BGP PIC
• Конфигурация и мониторинг
• Дополнительная информация

• Технология BGP Prefix-Independent Convergence (BGP PIC)
позволяет достигнуть времени сходимости менее секунды
как в мелких, так и в крупномасштабных операторских
сетях, спроектированных на основе протокола BGP. Мы
рассмотрим варианты применения данной технологии, а
также принципы конфигурации и мониторинга устройств
на основе операционных систем IOS и IOS XR.

• Неполадки на линии или сбой устройства в сети приводят
к потере пакетов – до тех пор, пока сходимость протокола
маршрутизации не будет достигнута.
• В процессе, в течение некоторого времени могут
существовать черные дыры или петли маршрутизации
• Время, в течение которого сервис передачи данных
недоступен – время потери связи (LoC)
• Наша задача – минимизировать данное время до величин,
незаметных для конечного пользователя.

1 Minute
TCP
Session
dies
30 secs
Routing
Proto-
cols
Tunnels
go down
5 secs1 sec
VoIP
call
500 msec
Video
50 msec
L1/L2
Transport
Conver-
gence
Signalling

Определение
(отсутствие канала или узла, получение
обновления маршрутной таблицы)
Распространение
информации
(отправка обновлений
маршрутов)
Анализ базы данных
маршрутов
Вычисление
оптимального пути
Загрузка в HW FIB
Переключение траффика
на новый путь

• IGP (OSPF/ISIS) оперируют сотнями маршрутов
(иногда тысячами, но только несколько сотен из них
действительно важны для работы сети)
• BGP предназначен для работы с сотнями тысяч
префиксов, что весьма затрудняет минимизацию LoC и
замедляет время сходимости сети.

1. Линк или узел в ядре сети недоступен
2. IGP определяет сбой и перерасчитывает путь к
РЕ1/РЕ2
3. IGP уведомляет BGP о том, что путь к next-hop
был изменен
4. PE3 определяет, какие префиксы подверглись
влиянию сбоя, расчитывает новый оптимальный
путь
5. Вносятся изменения в RIB/FIB
PE1
3/8, NH 1.1.1.1
NH <PE2>
…
PE2
1.1.1.1
3/8, NH 1.1.1.5
NH <PE1>
…
1.1.1.5
3/8, NH <PE1>
NH <PE2>
…
PE3
3/8, NH <PE1>
NH <PE2>

1. Узел на границе сети (РЕ1) недоступен
2. Соседи по IGP определяют недоступность узла, вычисляют
новые таблицы маршрутизации, удаляют маршрут(ы) к РЕ1
3. IGP уведомляет BGP о том, что путь к текущему next-hop
недоступен
4. BGP определяет подвергшиеся влиянию маршруты,
запускает алгоритм вычисления лучшего пути
5. Вносятся изменения в RIB/FIB
3/8, NH 1.1.1.1
NH <PE2>
…
3.0.0.0/81.1.1.1
3/8, NH 1.1.1.5
NH <PE1>
…
1.1.1.5
3/8, NH <PE1>
NH <PE2>
…
PE1
PE2
PE3

1. Канал связи недоступен
2. eBGP сессия прервана
3. РЕ1 определяет маршруты,
затронутые сбоем, запускает
алгоритм поиска лучшего пути
4. Отправляются withdraw
сообщения iBGP соседям
5. РЕ2/3 запускает алгоритм поиска
лучшего пути, вносит изменения
в RIB/FIB
Withdraw: 3/8, NH <PE1>
3/8, NH 1.1.1.1
NH <PE2>
…
3.0.0.0/81.1.1.1
eBGP
3/8, NH 1.1.1.5
NH <PE1>
…
1.1.1.5
3/8, NH <PE1>
NH <PE2>
…
PE1
PE2
PE3

• Два из описанных сценариев полагаются на сходимость
используемого протокола IGP, включая его способность
определения сбоев в сети. Этот процесс занимает менее
секунды.
• BGP, получив уведомление об изменении доступности
next-hop, запускает сканирование таблицы префиксов
• Сходимость BGP напрямую зависит от количества
префиксов в таблице
• Требуется иной способ для достижения предсказуемо
быстрой сходимости протокола BGP

• Control Plane Convergence
После сбоя сети, находится оптимальный маршрут; именно
он инсталлируется в data plane
• Data Plane Convergence
После достижения сходимости IGP пакеты
перенаправляются через доступный путь к пункту
назначения BGP
Несмотря на доступность, этот путь может быть не
оптимальным с точки зрения control plane
Необходимо, чтобы данный процесс был как можно
более быстрым и не зависел от количества префиксов в
таблице

• В процессе сходимости, после определения сбоя и
вычисления нового оптимального маршрута, необходимо
внести изменения в FIB
• Сколько времени может занять этот процесс?

• В соответствие каждому префиксу ставится полная информация: исходящий
интерфейс, MAC re-write, MPLS label etc.
• Любые изменения в BGP next-hop требуют внесения соответствующих изменений
по каждому префиксу, что занимает много времени
• Данный подход все еще используется как в оборудовании Cisco, так и в
оборудовании конкурентов
…
BGP Net
110.0.0.0/24
BGP Net
110.1.0.0/24
BGP Net
110.5.0.0/24
IGP Net
10.0.0.3/32
OIF
OIF
OIF
OIF

• Непрямая зависимость между IGP и BGP записями позволяет избежать обновления
BGP информации в случае, если BGP префиксы не затронуты напрямую
• Данный подход позволяет применить технологию PIC (Prefix-Independent Convergence)
…
BGP nexthop(s)
IGP nexthop(s) Output Interface
BGP Net
110.0.0.0/24
BGP Net
110.1.0.0/24
BGP Net
110.5.0.0/24
BGP pathlist
PE1
PE2 IGP pathlist
PE2 via P2
Gig1, dmac=x
IGP pathlist
PE1 via P1
PE1 via P2
Gig2, dmac=y
PE1
PE2PE3
P2
P1

• На предыдущих слайдах мы
увидели, что основной
проблемой для BGP
является обновление
информации для каждого
префикса при внесении
изменений в путь к next-hop
или при изменении самого
next-hop на альтернативный
• С возрастанием количества
маршрутов этот процесс
занимает все больше
времени

• BGP PIC Core
Применяется в случае, если IGP маршрут к BGP next-hop
изменился
Примеры: сбой линка PE-P, P-P; падение P устройства
• BGP PIC Edge
Применяется в случае, если изменился сам BGP next-hop
Примеры: сбой линка CE-PE; падение РЕ устройства

• Core Failure: сбой происходит в рамках AS, находящейся
под нашим управлением
• Сходимость IGP на PE3 ведет к изменению пути RIB к
PE1 как nex hop (но не к изменеию самого next hop!!!)
BGP Dataplane cходимость считается достигнутой после
обновления информации в FIB, включая рекурсивные ссылки
(BGP PIC Core)
BGP NHT посылает соответствующее уведомление BGP,
которое может спровоцировать BGP Control-Plane Convergence.
PE1
PE2PE3
P2
P1

• Основной функциональный компонент – иерархическая
структура FIB/CEF
• При обновлении IGP маршрута к BGP next-hop, нет
необходимости обновлять rewrite информацию для
каждого отдельно взятого префикса
• Необходимо обновить всего один Output Chain Element
(OCE), который указывает на новые параметры IGP и (при
необходимости) – исходящий интерфейс
BGP Net
110.0.0.0/24
110.0.1.0/24
110.0.2.0/24…
FIB entries
Load OCE
Adjacency OCE
Adjacency OCE

• Edge Failure: сбой происходит на или за границей
контролируемой AS
• Сходимость IGP на PE3 приводит к удалению пути в RIB к
BGP Next-Hop (PE1)
BGP Dataplane Convergence происходит на PE3 (BGP PIC
Edge); пакеты немедленно перенаправляются через PE2
BGP NHT посылает уведомление об удалении BGP next-hop,
которое провоцирует BGP Control-Plane Convergence.
PE1 does not set next-hop-self
PE1
PE2PE3
P2
P1
PE1
PE2PE3
P2
P1

• Технология BGP PIC Edge позволяет создавать
альтернативный/резервный маршрут для определенных
или всех префиксов в BGP таблице
• Этот маршрут помещается в RIB, FIB и CEF
• Таким образом, процесс сходимости в случае сбоя в сети
сводится к переключению траффика на уже загруженный в
data plane маршрут, что занимает минимальное время
• Нет необходимости в обновлении forwarding информации
для каждого отдельно взятого префикса

• Если пограничное устройство устанавливает next-hop на
свой лупбек интерфейс (next-hop-self), в случае падения
апстрим линка изменений в next-hop не происходит
Таким образом, остальные устройства ничего не знают о LoC!!!
• Однако: Next-hop меняется на самом пограничном
устройстве, таким образом РЕ1 может отреагировать в
манере PIC-Edge
Траффик перенаправляется через ядро сети к
альтернативному next-hop (РЕ2)
PE1
PE2PE3
P2
P1
PE1 does set next-hop-self

• Наличие более одного маршрута между устройством, на
котором конфигурируется BGP PIC, и сетью (сетями)
назначения
• Альтернативный/резервный маршрут имеет next-hop,
отличающийся от next-hop основного маршрута
• Наличие достаточных ресурсов памяти (при применении
BGP PIC размер CEF-таблицы удваивается)
*Данные требования применимы к BGP PIC Edge; для BGP PIC Core необходима
всего лишь поддержка технологии в рамках конфигурируемой платформы

• BGP PIC не поддерживается с MPLS VPN Inter-AS Option
B
• Поддерживаются IPv4, IPv6, VPNv4, and VPNv6 address
families; не поддерживаются Multicast or L2VPN Virtual
Routing and Forwarding (VRF) address families.
• Если 2 РЕ устройства становятся
альтернативными/резервными друг для друга, при
падении СЕ устройства возможно возникновение
маршрутной петли: траффик будет перемещаться между
РЕ устройствами до истечения таймера TTL.
• BGP PIC не работает одновременно с BGP Best External
• BGP PIC не поддерживает режим NSF/SSO

• eBGP между CE и PE
• Для СЕ РЕ1 является основным маршрутом на пути к СЕ3, РЕ2 -
альтернативным

• eBGP между CE и PE; iBGP между СЕ1 и СЕ2
• Для СЕ РЕ1 является основным маршрутом на пути к СЕ3, РЕ2 -
альтернативным

• eBGP между CE и PE; iBGP между СЕ1 и СЕ2; VPNv4 iBGP между
РЕ1/РЕ2/РЕ3/РЕ4
• MPLS в ядре (AS64500)

• eBGP между CE и PE; iBGP между СЕ1 и СЕ2
• VPNv4 между всеми РЕ устройствами

a) Нет, в нашей сети нет необходимости в такой
технологии
b) Нет, мы используем для этих целей другие
технологии
c) Да, мы протестируем данную технологию в
лабораторных условиях
d) Да, видим и будем применять
Видите ли вы необходимость в
применении BGP PIC в вашей сети?

• BGP PIC предназначена в первую очередь для улучшения
сходимости data plane; при этом используется иерархическая
организация CEF/FIB
• Почти все платформы, которые поддерживают данную
технологию, используют иерархию по умолчанию (CRS, XR12k
ASR9k, ASR1k, NX-OS)
• Кроме...

• Cisco 7600 по умолчанию использует метод организации CEF, который
позволяет минимизировать используемые ресурсы памяти, но замедляет
процесс сходимости протоколов маршрутизации
• Для изменения этого поведения используется команда
• Проверить результат ее выполнения можно с помощью следующей
команды:
cef table output-chain build favor convergence-speed
7600#sh cef table
Global information:
Output chain build favors:
platform: memory-utilization
CLI: convergence-speed
operational: convergence-speed

• Две разновидности BGP PIC Edge: Multipath и Unipath
• BGP PIC Edge Multipath используется в случае наличия equal-
cost маршрутов к альтернативным BGP next-hop
• Применяется в Active-Active схемах резервирования
• Оба маршрута одновременно активны в сontrol/data plane
• Траффик распределяется между двумя next-hop
• Конфигурируется с помощью включения опции BGP Multipath:
maximum-paths eibgp/ibgp/ebgp …

• BGP PIC Edge Unipath используется в случае наличия
основного и резервного BGP next-hop
• Применяется в Active-Backup схемах резервирования
• При этом Backup next-hop не задействован для передачи
траффика по умолчанию
• Конфигурируется с помощью включения возможности
инсталляции в FIB альтернативных маршрутов:
• Или неявно – при включении опции BGP Best External:
router bgp ...
address-family ipv4 [vrf ...]
or
address-family vpnv4
bgp additional-paths install
router bgp ...
address-family …
bgp advertise-best-external

• BGP PIC Edge Multipath: как в IOS
• BGP PIC Edge Unipath: требуется дополнительная
конфигурация
route-policy backup
set path-selection backup 1 install [multipath-protect] [advertise]
end-policy
router bgp ...
address-family ipv4 unicast
additional-paths selection route-policy backup
additional-paths receive
additional-paths send
!
address-family vpnv4 unicast
additional-paths selection route-policy backup
additional-paths receive
additional-paths send
!

• Для просмотра наличия альтернативных маршрутов в RIB,
используйте команду
PE3
PE2
PE1
PE3#sh bgp vpnv4 unicast vrf red
BGP table version is 43, local router ID is 10.0.0.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-
Filter, a additional-path
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf red)
*> 100.0.0.10/32 100.1.10.10 0 0 100 i
*bi 110.0.0.11/32 10.0.0.2 0 100 0 110 i
*>i 10.0.0.1 0 2000 0 110 I
PE3#
Backup/Repair Path
Show ip route [vrf <…>] repair-path

PE3#sh bgp vpnv4 unicast vrf red 110.0.0.11/32
BGP routing table entry for 1:3:110.0.0.11/32, version 43
Paths: (2 available, best #2, table red)
Additional-path-install
Advertised to update-groups:
1
Refresh Epoch 1
110, imported path from 1:1:110.0.0.11/32
10.0.0.2 (metric 21) from 10.0.0.6 (10.0.0.6)
Origin IGP, metric 0, localpref 100, valid, internal, backup/repair
Extended Community: RT:1:100
Originator: 10.0.0.2, Cluster list: 10.0.0.6 , recursive-via-host
mpls labels in/out nolabel/16
Refresh Epoch 1
110, imported path from 1:2:110.0.0.11/32
10.0.0.1 (metric 21) from 10.0.0.6 (10.0.0.6)
Origin IGP, metric 0, localpref 2000, valid, internal, best
Extended Community: RT:1:100
Originator: 10.0.0.1, Cluster list: 10.0.0.6 , recursive-via-host
mpls labels in/out nolabel/17
PE3#
Backup/Repair Path
PE2
Primary Path PE1
Paths flagged as recursive-
via-host by default for
vpnv4 (See later)
PIC-Edge Enabled
PE3
PE2
PE1

PE3
PE2
PE1
PE3#sh ip cef vrf red 110.0.0.11/32 internal | i list|lock|adj|buck|choic|chain
contains path extension list
path DD944670, path list DD60E02C, share 1/1, type recursive, for IPv4, flags must-be-
labelled, recursive-via-host
path DD9449F0, path list DD60E2AC, share 1/1, type attached nexthop, for IPv4
nexthop 10.1.2.2 Ethernet0/1 label 17, adjacency IP adj out of Ethernet0/1, addr
10.1.2.2 DE6DF558
path DD944A60, path list DD60E2AC, share 1/1, type attached nexthop, for IPv4
10.1.5.5 DE6DF6B8
path DD9446E0, path list DD60E02C, share 1/1, type recursive, for IPv4, flags must-be-
labelled, repair, recursive-via-host
path DD944AD0, path list DD60E2FC, share 1/1, type attached nexthop, for IPv4
10.1.5.5 DE6DF6B8
…
PE3#
BGP Path List
Primary Entry
IGP Path List
IGP Path list (to
backup next-hop)
BGP Path List
Backup (repair) Entry

PE3
PE2
PE1
RP/0/5/CPU0:C3#show bgp vrf VPN_1 10.1.0.0/22
BGP routing table entry for 10.1.0.0/22, Route Distinguisher: 100:100
…
Paths: (2 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
101
10.1.1.1 (metric 120) from 172.16.1.7 (10.1.1.1)
Received Label 66
Origin EGP, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 28702
Extended community: RT:100:1
Originator: 10.1.1.1, Cluster list: 172.16.1.7
Path #2: Received by speaker 0
101
10.2.1.1 (metric 145) from 172.16.1.7 (10.2.1.1)
Received Label 66
Origin EGP, localpref 100, valid, internal, backup, add-path, import-candidate, imported
Received Path ID 0, Local Path ID 2, version 155502
Extended community: RT:100:1
Originator: 1.2.1.1, Cluster list: 172.16.1.7
Backup/Repair Path
PE2

PE3
PE2
PE1
RP/0/5/CPU0:C3#show route vrf VPN_1 10.1.0.0/22
Routing entry for 10.1.0.0/22
Known via "bgp 100", distance 200, metric 0
Tag 101
Number of pic paths 1 , type internal
Installed Jan 25 03:21:36.026 for 1d19h
Routing Descriptor Blocks
10.1.1.1, from 172.16.1.7
Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000
Route metric is 0
10.2.1.1, from 172.16.1.7, BGP backup path
Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000
Route metric is 0
No advertising protos.
RP/0/5/CPU0:C3#
Backup/Repair Path
shows up in routing
table as well!

PE3
PE2
PE1
RP/0/5/CPU0:C3#show cef vrf VPN_1 10.1.0.0/22
10.1.0.0/22, version 4, internal 0x40040001 (ptr 0x9e1923b8) [1], 0x0 (0x0), 0x4100
(0x9ed2b0d4)
Updated Jan 25 03:21:36.793
Prefix Len 22, traffic index 0, precedence routine (0)
via 10.1.1.1, 3 dependencies, recursive [flags 0x10]
path-idx 0
next hop VRF - 'default', table - 0xe0000000
next hop 10.1.1.1 via 16393/0/21
next hop 10.10.13.1/32 PO0/0/1/0 labels imposed {16393 66}
via 10.2.1.1, 2 dependencies, recursive, backup [flags 0x110]
path-idx 1
next hop VRF - 'default', table - 0xe0000000
next hop 10.2.1.1 via 16032/0/21
next hop 10.12.16.2/32 PO0/0/0/0 labels imposed {16032 66}
RP/0/5/CPU0:C3# Backup (repair) Entry

• Поведение по умолчанию FIB предполагает рекурсию по максимальной длине
префикса
• Также в поиск включаются аггрегированные маршруты или маршруты по
умолчанию, которые могут быть валидными
• В случае, если используемый в качестве BGP next-hop префикс длиной /32
стал недоступен, нет смысла искать валидный префикс с такой же или
большей длиной
BGP Net
172.16.0.0/16
10.0.0.3
b: 10.0.0.4
10.0.0.3/32
IP Routing Table
10.0.0.3/32
10.0.0.4/32
10.0.0.0/24
...
10.0.0.4/32 10.0.0.0/24
??
0.0.0.0/0

• IOS: рекурсия для /32 префиксов через
аггрегированные/дефолтные маршруты не работает, если:
BGP PIC Edge включен
BGP next-hop является directly connected (eBGP)
Управление рекурсией с помощью команды
• IOS XR: проблема не существует для labeled path
(vpnv4/6/rfc3107 next-hops) – рекурсия всегда только через /32
префиксы
• Начиная с версии 4.2, для unlabeled path, включая VRF
префиксы: рекурсия не работает через дефолтный маршрут,
аггрегированные BGP маршруты или если длина префикса
кандидата менее сконфигурированной:
router bgp ...
address-family ...
bgp recursion host
router bgp ...
address-family ...
nexthop resolution prefix-length minimum <len>

• BGP L3VPN поддерживают
несколько режимов генерации меток
на РЕ устройствах:
• Per prefix (режим по умолчанию)
Каждому префиксу ставится в
соответствие одна уникальная метка
• Per CE
Одинаковая метка для всех префиксов,
полученных от одного СЕ
• Per VRF
Одинаковая метка для всех префиксов
в рамках одной VRF
p1
p2
CE1
CE2p3
p4
p1, L=20
p2, L=61
p3, L=22
p4, L=34
p5
p6
CE1
CE2p7
p8
p5, L=51
p6, L=51
p7, L=67
p8, L=67
p10
p11
CE1
CE2p12
p10, L=88(a)
p11, L=88(a)
p12, L=88(a)
...

• Режим по умолчанию
• Обычный label switched path до основного РЕ (РЕ1)
p1 via CE1, local label 111
backup: PE2, L=222
p1
p1
CE1
PE1
(active)
PE2
(standby)
p1 via PE1, L=111
backup: CE1, local label 222

• Режим по умолчанию
• В случае падения линка РЕ1-СЕ, РЕ1 перенаправляет
траффик через РЕ2
backup: PE2, L=222
p1
p1
CE1
PE1
(active)
PE2
(standby)
p1 via PE1, L=111

• В этом режиме требуется дополнительный IP lookup для
того, чтобы найти сеть назначения
• Это может создать временную петлю при использовании
схемы резервирования Active-Backup с применением BGP Best
External
p1 via CE1,
backup: PE2, L=30
p2 via CE1,
backup: PE2, L=30
p1
p2
p1
p2 CE1
PE1
(active)
PE2
(standby)
p1 via PE1, L=50
backup: via CE1
p2 via PE1, L=50
backup: via CE1
PE1 allocates
per-vrf label 50
PE1 allocates
per-vrf label 30

External
Проблема возникает при падении РЕ-СЕ линка до тех пор, пока не
будет достигнута сходимость BGP control plane на РЕ2
p1 via CE1
backup: PE2, L=30
p2 via CE1
backup: PE2, L=30
p1
p2
p1
p2 CE1
PE1
(active)
PE2
(standby)
p1 via PE1, L=50
backup: via CE1
p2 via PE1, L=50
backup: via CE1

External
p1 via CE1
backup: PE2, L=30
p2 via CE1
backup: PE2, L=30
p1
p2
p1
p2 CE1
PE1
(active)
PE2
(standby)
p1 via PE1, L=50
backup: via CE1
p2 via PE1, L=50
backup: via CE1

• Для применения BGP PIC Edge с таким режимом необходимо
выполнение следующих условий:
Все РЕ, к которым подключены СЕ, использовали данный режим
присвоения меток
Все префиксы должны анонсироваться через все резервные
соединения
• Пример: Какую метку (123 или 456) должен использовать РЕ1,
когда линк РЕ1-СЕ1 будет недоступен?
p1 via CE1, per-CE label=50
alternate: PE2, L=123
p2 via CE1, per-CE label=50
p1
p2
p1
p2 CE1
PE1
(per-CE label)
PE2
(per prefix label)
p1 via CE1, per-pfx label=123
p2 via CE2, per-pfx label=456
CE2

• В данном режиме устанавливается соответствие 1:1 между
метками и префиксами, и в случае необходимости своппинга
резервной метки не возникает проблем
• Также отсутствуют проблемы с aggregate lookup – как
следствие, отсутствуют временные петли
• Полная поддержка BGP PIC Edge!
backup: PE2, L=222
backup: PE2, L=444
p1
p1
p2 CE1
PE1
(active)
PE2
(standby)
p1 via PE1, L=111
p2 via PE1, L=333
p2 CE2

Per-Prefix Per-CE Per-VRF
BGP PIC Edge Fully supported Not supported
Possible transient
loop
BGP Best-External Yes Yes
Possible transient
loop
eiBGP Multipath Yes Yes No
ECMP PE-CE Yes No Yes

• Три различных метода для соединения MPLS-VPN сетей:
 Option A: отдельные (саб)интерфейсы
для каждой VPN, каждый SP
рассматривает другого как “CE”
eBGP
eBGP
eBGP
eBGP
ASBRs ASBRs
 Option B: Один интерфейс для всех VPN,
eBGP сессия для обмена vpnv4/6
маршрутами
 Option C: Один интерфейс, eBGP сессия
для обмена vpnv4/6 маршрутами между
RR
 Информация о next-hop (удаленных PE)
обменивается через eBGP или IGP+LDP
 Нет специальных условий
Существует проблема
 Нет специальных условий

• Использование уникальных
RD на PE гарантирует
разные пути через ядро,
делает апдейты от РЕ1 и
РЕ2 отличимыми друг от
друга
• Но это же не позволяет
ASBR-у в локальной AS
связать эти апдейты между
собой для обеспечения
резервирования PE
ASBR1 не знает, что можно
использовать rd2:p1 для
резервирования PE1
• Сейчас мы работаем над
решением этой проблемы
p1
PE1
PE2
rd2:p1 via PE2
ASBR1
ASBR2
rd1:p1 via PE1
ASBR1
CE1
rd1:p1 via PE1
rd2:p1 via PE2
Hmm, how can I
protect CE1
against PE1
failure?

PE1
rd1:10/8
10.0.0.0/8
PE2
1. Сбой на RR1
Траффик не затронут, так как RR1 не
задействован в передаче
2. После истечения iBGP hold-time, PE3
удаляет маршруты, полученные от RR1
 VRF остается без машрутов к 10/8
3. Альтернативные пути не
импортируются до
следующего запуска import-
scanner (до 15 секунд)
не актуально для15M/S или
SRE
PE3
rd2:10/8
rd1:10/8, NH PE1
rd2:10/8, NH PE2
rd1:10/8, NH PE1
rd2:10/8, NH PE2
> rd1:10/8, NH PE1, from RR1
rd1:10/8, NH PE1, from RR2
vrf import
RR1
RR2
RR2
RR2
По умолчанию, BGP импортирует единственный лучший путь для rd:prefix
Допущение:Использование
уникальных RDs per PE

• Импортировать более чем один оптимальный путь
или, начиная с 12.2SRE/15.0M
Необходимо учитывать дополнительные требуемые ресурсы
памяти!(~100 bytes/path)
router bgp ..
address-family ipv4 vrf …
maximum-paths [ibgp 2] import 4
vrf import
PE3
router bgp ..
address-family ipv4 vrf …
import path selection all
import path limit 4

• Быстрая сходимость протоколов маршрутизации является
ключевым фактором для предоставления современных
критичных к задержкам сервисов
• IGP как правило удовлетворяет этим требованиям
(сходимость до секунды)
В IOS может потребоваться оптимизация таймеров, IOS-XR и NX-
OS оптимизированы по умолчанию
• BGP PIC позволяетBGP достигнуть того же высокого уровня
сходимости независимо от количества префиксов
• При проектировании BGP сервисов необходимо постоянно
иметь в виду наличие альтернативных маршрутов в сети

• PIC-Core
7600
12.2(33)SRB: IPv4, non-ECMP
12.2(33)SRC: IPv4, non-ECMP + ECMP / vpnv4, non-ECMP
15.0(1)S: IPv4+vpnv4, non-ECMP and ECMP
ASR1k: XE2.5.0
NX-OS: 5.2
• PIC-Edge
7600, 7200: 12.2(33)SRE
ASR1k: XE3.2.0 (v4), 3.3.0(v6)
NX-OS: Radar

• BGP PIC Core
3.4 CRS, 3.3 12k, 3.7 ASR9k
• BGP PIC Edge
Multipath: 3.5
Unipath: 3.9
• Разработка продолжается – некоторые усовершенствования
были реализованы в 4.2
Like 3107 + Label, additional PIC triggers and many more

a) IP/MoFRR (IP и Multicast-only Fast Re-Route
b) Особенности реализации QoS на платформах
ME3600/3800
c) Ethernet OAM/CFM/ELMI
Какие темы будущих семинаров Вам
интересны? Выберите из предложенных
или предложите свои

Используйте Q&A панель, чтобы послать вопрос. Наши эксперты
ответят на них

Эксперт ответит на некоторые Ваши
вопросы. Используйте Q&A панель,
чтобы задать еще вопросы

Получить дополнительную информацию, а также задать вопросы
экспертам в рамках данной темы вы можете в течение двух
недель, на странице, доступной по ссылке
https://supportforums.cisco.com/community/russian/expert-corner
Вы можете получить видеозапись данного семинара и текст
сессии Q&A в течении ближайших 5 дней по следующей ссылке
https://supportforums.cisco.com/community/russian/expert-corner/webcast

https://supportforms.cisco.com/community/russian
http://www.facebook.com/CiscoRu
http://twitter.com/CiscoRussia
http://www.youtube.com/user/CiscoRussiaMedia
http://itunes.apple.com/us/app/cisco-technical-support/id398104252?mt=8
http://www.linkedin.com/groups/CSC-Cisco-Support-Community-3210019
Newsletter Subscription:
https://tools.cisco.com/gdrp/coiga/showsurvey.do?surveyCode=589&keyCode=146298_2&P
HYSICAL%20FULFILLMENT%20Y/N=NO&SUBSCRIPTION%20CENTER=YES

Спасибо за
Ваше время
Пожалуйста, участвуйте в опросе

Конфигурация и особенности BGP: Prefix-Independent Convergence

Recommended

Recommended

More Related Content

Similar to Конфигурация и особенности BGP: Prefix-Independent Convergence

Similar to Конфигурация и особенности BGP: Prefix-Independent Convergence (20)

More from Cisco Russia

More from Cisco Russia (20)

Конфигурация и особенности BGP: Prefix-Independent Convergence