Конфигурация и особенности 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 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

https://supportforums.cisco.com/docs/DOC-33272


Присылайте Ваши вопросы!

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


Вопрос №1

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.


Особенности сходимости протокола BGP


Потеря связи (Loss of Connectivity, LoC)• Неполадки на линии или сбой устройства в сети приводят

к потере пакетов – до тех пор, пока сходимость протокола маршрутизации не будет достигнута.

• В процессе, в течение некоторого времени могут существовать черные дыры или петли маршрутизации

• Время, в течение которого сервис передачи данных недоступен – время потери связи (LoC)

• Наша задача – минимизировать данное время до величин, незаметных для конечного пользователя.


Влияние 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 vs. BGP

• IGP (OSPF/ISIS) оперируют сотнями маршрутов

(иногда тысячами, но только несколько сотен из них действительно важны для работы сети)

• BGP предназначен для работы с сотнями тысяч префиксов, что весьма затрудняет минимизацию LoC и замедляет время сходимости сети.


Сходимость BGP control plane: сбой в ядре сети

1. Линк или узел в ядре сети недоступен

2. IGP определяет сбой и перерасчитывает путь к РЕ1/РЕ2

3. IGP уведомляет BGP о том, что путь к next-hop был изменен

4. PE3 определяет, какие префиксы подверглись влиянию сбоя, расчитывает новый оптимальный путь

5. Вносятся изменения в RIB/FIBPE1

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.53/8, NH <PE1> NH <PE2>…

PE33/8, NH <PE1> NH <PE2>


Сходимость BGP control plane: сбой на границе сети

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.53/8, NH <PE1> NH <PE2>…

PE1

PE2

PE3


Сходимость BGP control plane: сбой за границей сети

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.53/8, NH <PE1> NH <PE2>…

PE1

PE2

PE3


Cходимость BGP control plane: итоги

• Два из описанных сценариев полагаются на сходимость используемого протокола IGP, включая его способность определения сбоев в сети. Этот процесс занимает менее секунды.

• BGP, получив уведомление об изменении доступности next-hop, запускает сканирование таблицы префиксов

• Сходимость BGP напрямую зависит от количества префиксов в таблице

• Требуется иной способ для достижения предсказуемо быстрой сходимости протокола BGP


Сходимость: control plane vs.data plane• Control Plane Convergence

После сбоя сети, находится оптимальный маршрут; именно он инсталлируется в data plane

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

Необходимо, чтобы данный процесс был как можно более быстрым и не зависел от количества префиксов в таблице


Сходимость BGP data plane

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

• Сколько времени может занять этот процесс?


Неоптимальная организация FIB: плоская структура

• В соответствие каждому префиксу ставится полная информация: исходящий интерфейс, MAC re-write, MPLS label etc.

• Любые изменения в BGP next-hop требуют внесения соответствующих изменений по каждому префиксу, что занимает много времени

• Данный подход все еще используется как в оборудовании Cisco, так и в оборудовании конкурентов

…

BGP Net110.0.0.0/24

BGP Net110.1.0.0/24

BGP Net110.5.0.0/24

IGP Net10.0.0.3/32

OIF

OIF

OIF

OIF


Оптимальная организация FIB: иерархическая структура

• Непрямая зависимость между IGP и BGP записями позволяет избежать обновления BGP информации в случае, если BGP префиксы не затронуты напрямую

• Данный подход позволяет применить технологию PIC (Prefix-Independent Convergence)

…BGP nexthop(s)

IGP nexthop(s) Output Interface

BGP Net110.0.0.0/24

BGP Net110.1.0.0/24

BGP Net110.5.0.0/24

BGP pathlist

PE1PE2 IGP pathlist

PE2 via P2

Gig1, dmac=x

IGP pathlist

PE1 via P1PE1 via P2

Gig2, dmac=y

PE1

PE2PE3

P2

P1


Как работает BGP PIC


BGP: узкое место

• На предыдущих слайдах мы увидели, что основной проблемой для 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; падение РЕ устройства


BGP PIC Core: подробности

• 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


Как работает BGP PIC Core• Основной функциональный компонент – иерархическая

структура FIB/CEF

• При обновлении IGP маршрута к BGP next-hop, нет необходимости обновлять rewrite информацию для каждого отдельно взятого префикса

• Необходимо обновить всего один Output Chain Element (OCE), который указывает на новые параметры IGP и (при необходимости) – исходящий интерфейс

BGP Net110.0.0.0/24110.0.1.0/24

110.0.2.0/24…

FIB entries

Load OCEAdjacency OCE

Adjacency OCE


BGP PIC Edge: подробности

• 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 PIC Edge позволяет создавать альтернативный/резервный маршрут для определенных или всех префиксов в BGP таблице

• Этот маршрут помещается в RIB, FIB и CEF

• Таким образом, процесс сходимости в случае сбоя в сети сводится к переключению траффика на уже загруженный в data plane маршрут, что занимает минимальное время

• Нет необходимости в обновлении forwarding информации для каждого отдельно взятого префикса


BGP PIC Edge и Next-Hop-Self

• Если пограничное устройство устанавливает 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


Необходимые условия*• Наличие более одного маршрута между устройством, на

котором конфигурируется 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


Применение BGP PIC: Single CE, Dual PE

• eBGP между CE и PE

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


Применение BGP PIC: Dual CE, Dual PE

• eBGP между CE и PE; iBGP между СЕ1 и СЕ2

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


Применение BGP PIC: Dual CE, Dual PЕ + IP MPLS

• eBGP между CE и PE; iBGP между СЕ1 и СЕ2; VPNv4 iBGP между РЕ1/РЕ2/РЕ3/РЕ4

• MPLS в ядре (AS64500)


Применение BGP PIC: защита узла/канала связи в IP MPLS ядре

• eBGP между CE и PE; iBGP между СЕ1 и СЕ2

• VPNv4 между всеми РЕ устройствами


Вопрос №2

a) Нет, в нашей сети нет необходимости в такой технологии

b) Нет, мы используем для этих целей другие технологии

c) Да, мы протестируем данную технологию в лабораторных условиях

d) Да, видим и будем применять

Видите ли вы необходимость в применении BGP PIC в вашей сети?


Конфигурация BGP PIC


Конфигурация BGP PIC Core (1/2)

• BGP PIC предназначена в первую очередь для улучшения сходимости data plane; при этом используется иерархическая организация CEF/FIB

• Почти все платформы, которые поддерживают данную технологию, используют иерархию по умолчанию (CRS, XR12k ASR9k, ASR1k, NX-OS)

• Кроме...


Конфигурация BGP PIC Core (2/2)

• 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: IOS (1/2)• Две разновидности 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: IOS (2/2)• 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: IOS XR• BGP PIC Edge Multipath: как в IOS

• BGP PIC Edge Unipath: требуется дополнительная конфигурация

route-policy backupset 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!


Мониторинг BGP PIC: IOS

• Для просмотра наличия альтернативных маршрутов в RIB, используйте команду

PE3

PE2

PE1

PE3#sh bgp vpnv4 unicast vrf redBGP table version is 43, local router ID is 10.0.0.3Status 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-pathOrigin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight PathRoute 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 IPE3#

Backup/Repair Path

Show ip route [vrf <…>] repair-path


Мониторинг BGP PIC: IOS

PE3#sh bgp vpnv4 unicast vrf red 110.0.0.11/32BGP routing table entry for 1:3:110.0.0.11/32, version 43Paths: (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/17PE3#

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


Мониторинг BGP PIC: IOS 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 nexthop 10.1.5.5 Ethernet0/2 label 18, adjacency IP adj out of Ethernet0/2, addr 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 nexthop 10.1.5.5 Ethernet0/2 label 19, adjacency IP adj out of Ethernet0/2, addr 10.1.5.5 DE6DF6B8 …PE3#

BGP Path ListPrimary Entry

IGP Path List

IGP Path list (to backup next-hop)

BGP Path ListBackup (repair) Entry


Мониторинг BGP PIC: IOS XR 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 Not advertised to any peer 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 Not advertised to any peer 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



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!



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 и аггрегированные маршруты

• Поведение по умолчанию FIB предполагает рекурсию по максимальной длине префикса

• Также в поиск включаются аггрегированные маршруты или маршруты по умолчанию, которые могут быть валидными

• В случае, если используемый в качестве BGP next-hop префикс длиной /32 стал недоступен, нет смысла искать валидный префикс с такой же или большей длиной

BGP Net172.16.0.0/16

10.0.0.3b: 10.0.0.4

10.0.0.3/32

IP Routing Table10.0.0.3/3210.0.0.4/3210.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 label allocation на BGP PIC Edge

• BGP L3VPN поддерживают несколько режимов генерации меток на РЕ устройствах:

• Per prefix (режим по умолчанию)

Каждому префиксу ставится в соответствие одна уникальная метка

• Per CEОдинаковая метка для всех префиксов, полученных от одного СЕ

• Per VRFОдинаковая метка для всех префиксов в рамках одной VRF

p1p2

CE1

CE2p3p4

p1, L=20p2, L=61p3, L=22p4, L=34

p5p6

CE1

CE2p7p8

p5, L=51p6, L=51p7, L=67p8, L=67

p10p11

CE1

CE2p12

p10, L=88(a)p11, L=88(a)p12, L=88(a)...


BGP PIC Edge: Per prefix • Режим по умолчанию

• Обычный label switched path до основного РЕ (РЕ1)

p1 via CE1, local label 111 backup: PE2, L=222

p1

p1CE1

PE1 (active)

PE2 (standby)

p1 via PE1, L=111 backup: CE1, local label 222

111L1 IPIP

111 IP


BGP PIC Edge: Per prefix • Режим по умолчанию

• В случае падения линка РЕ1-СЕ, РЕ1 перенаправляет траффик через РЕ2

p1 via CE1, local label 111 backup: PE2, L=222

p1

p1CE1

PE1 (active)

PE2 (standby)

p1 via PE1, L=111 backup: CE1, local label 222

111L1 IP

IP

111 IP

222 IP

222L2

IP


BGP PIC Edge: Per VRF• В этом режиме требуется дополнительный IP lookup для

того, чтобы найти сеть назначения

• Это может создать временную петлю при использовании схемы резервирования Active-Backup с применением BGP Best External

p1 via CE1, backup: PE2, L=30p2 via CE1, backup: PE2, L=30

p1p2

p1p2 CE1

PE1 (active)

PE2 (standby)

p1 via PE1, L=50 backup: via CE1p2 via PE1, L=50 backup: via CE1

PE1 allocates

per-vrf label 50

PE1 allocates

per-vrf label 30





Проблема возникает при падении РЕ-СЕ линка до тех пор, пока не будет достигнута сходимость BGP control plane на РЕ2

p1 via CE1 backup: PE2, L=30p2 via CE1 backup: PE2, L=30

p1p2

p1p2 CE1

PE1 (active)

PE2 (standby)








p1p2

p1p2 CE1

PE1 (active)

PE2 (standby)








p1p2

p1p2 CE1

PE1 (active)

PE2 (standby)



BGP PIC Edge: Per СЕ• Для применения BGP PIC Edge с таким режимом необходимо

выполнение следующих условий:

Все РЕ, к которым подключены СЕ, использовали данный режим присвоения меток

Все префиксы должны анонсироваться через все резервные соединения

• Пример: Какую метку (123 или 456) должен использовать РЕ1, когда линк РЕ1-СЕ1 будет недоступен?

p1 via CE1, per-CE label=50 alternate: PE2, L=123p2 via CE1, per-CE label=50 alternate: PE2, L=456

p1

p2

p1p2 CE1

PE1(per-CE label)

PE2 (per prefix label)

p1 via CE1, per-pfx label=123 alternate: PE2, L=50p2 via CE2, per-pfx label=456 alternate: PE2, L=50

CE2


BGP PIC Edge: Per Prefix• В данном режиме устанавливается соответствие 1:1 между

метками и префиксами, и в случае необходимости своппинга резервной метки не возникает проблем

• Также отсутствуют проблемы с aggregate lookup – как следствие, отсутствуют временные петли

• Полная поддержка BGP PIC Edge!

p1 via CE1, local label 111 backup: PE2, L=222p2 via CE1, local label 333 backup: PE2, L=444

p1

p1p2 CE1

PE1 (active)

PE2 (standby)

p1 via PE1, L=111 backup: CE1, local label 222p2 via PE1, L=333 backup: CE2, local label 444

p2 CE2


BGP label allocation: резюме

Per-Prefix Per-CE Per-VRF

BGP PIC Edge Fully supported Not supportedPossible transient

loop

BGP Best-External Yes YesPossible transient

loop

eiBGP Multipath Yes Yes No

ECMP PE-CE Yes No Yes


Inter-AS MPLS VPN• Три различных метода для соединения 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

Нет специальных условий

Существует проблема

Нет специальных условий


Inter-AS Option B и BGP PIC Edge• Использование уникальных

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 PE1rd2:p1 via PE2

Hmm, how can I protect CE1 against PE1

failure?


L3VPN: RR redundancy (IOS) - проблема

PE1

rd1:10/8

10.0.0.0/8

PE2

1. Сбой на RR1 Траффик не затронут, так как RR1 не задействован в передаче

2. После истечения iBGP hold-time, PE3 удаляет маршруты, полученные от RR1 VRF остается без машрутов к 10/83. Альтернативные пути не импортируются до следующего запуска import-scanner (до 15 секунд)не актуально для15M/S или SRE

PE3

rd2:10/8

rd1:10/8, NH PE1rd2:10/8, NH PE2

rd1:10/8, NH PE1rd2:10/8, NH PE2

> rd1:10/8, NH PE1, from RR1 rd1:10/8, NH PE1, from RR2> rd2:10/8, NH PE2, from RR1 rd2:10/8, NH PE2, from RR2

vrf import> rd3:10/8, NH PE1, from RR1> rd3:10/8, NH PE2, from RR1

RR1

RR2

RR2RR2

По умолчанию, BGP импортирует единственный лучший путь для rd:prefix

Допущение:Использование уникальных RDs per PE


L3VPN: RR redundancy (IOS) - решение• Импортировать более чем один оптимальный путь

или, начиная с 12.2SRE/15.0M

Необходимо учитывать дополнительные требуемые ресурсы памяти!(~100 bytes/path)

router bgp .. address-family ipv4 vrf … maximum-paths [ibgp 2] import 4

> rd1:10/8, NH PE1, from RR1 rd1:10/8, NH PE1, from RR2> rd2:10/8, NH PE2, from RR1 rd2:10/8, NH PE2, from RR2

vrf import> rd3:10/8, NH PE1, from RR1 rd3:10/8, NH PE1, from RR2> rd3:10/8, NH PE2, from RR1 rd3:10/8, NH PE2, from RR2

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 сервисов необходимо постоянно иметь в виду наличие альтернативных маршрутов в сети


Реализация BGP PIC – IOS (7600, ASR1K) и NX-OS

• 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 – IOS XR• 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


Вопрос №3

a) IP/MoFRR (IP и Multicast-only Fast Re-Route

b) Особенности реализации QoS на платформах ME3600/3800

c) Ethernet OAM/CFM/ELMI

Какие темы будущих семинаров Вам интересны? Выберите из предложенных или предложите свои


Присылайте Ваши вопросы!

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


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


Сессия «Спросить Эксперта»Получить дополнительную информацию, а также задать вопросы экспертам в рамках данной темы вы можете в течение двух недель, на странице, доступной по ссылке

https://supportforums.cisco.com/community/russian/expert-corner

Вы можете получить видеозапись данного семинара и текст сессии Q&A в течении ближайших 5 дней по следующей ссылке

https://supportforums.cisco.com/community/russian/expert-corner/webcast






Приглашаем Вас активно участвовать в Cisco Support Community и социальных сетях

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&PHYSICAL%20FULFILLMENT%20Y/N=NO&SUBSCRIPTION%20CENTER=YES

https://supportforms.cisco.com/

https://supportforms.cisco.com/

Спасибо за Ваше время

Пожалуйста, участвуйте в опросе

Thank you.

Date post:	10-Jun-2015
Category:	Technology
Upload:	cisco-russia
View:	1,192 times
Download:	6 times

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

Technology