Расширенные возможности протокола BGP

Алексей БабайцевСистемный инженер[email protected]

Расширенные возможности протокола BGP

24.11.2014 © 2014 Cisco and/or its affiliates. All rights reserved.

Содержание

• Введение • Мотивация для дальнейшего развития BGP• Новая функциональность BGP

24.11.2014 © 2014 Cisco and/or its affiliates. All rights reserved. 2

BGP появился в 1989г…

• История появления BGP: Когда интернет вырос настолько, чтобы представлять собой множество автономных систем (AS) , появилась необходимость в стабильном, «non-chatty»протоколе с небольшой нагрузкой на CPU, который свяжет системы между собой.

• В июне 1989 появилась первая рекомендация на протокол - RFC 1105, A Border Gateway Protocol (BGP).

Развитие SP-сервисов и способов маршрутизации

• Мультимедиа, мобильный интернет, облачные сервисы вызывают взрывное потребление полосы пропускания

• Объем маршрутизируемых префиксов имеет почти линейный рост• Эволюция сервисов на базе протокола BGP заставляет разрабатывать новые концепции и

подходы к проектированию операторской инфраструктуры

4

Эволюция Control-planeБольшинство сервисов стремятся совместному сосуществованию с BGP

Сервисы/транспорт 200x и ранее 2014 и далееIDR (Peering) BGP BGP (IPv6)SP L3VPN BGP BGP + FRR + ScalabilitySP Multicast VPN PIM BGP Multicast VPNDDOS mitigation CLI BGP flowspecNetwork Monitoring SNMP BGP monitoring protocolSecurity Filters BGP Sec (RPKI), DDoS MitigationProximity BGP connected app APISP-L3VPN-DC BGP Inter-AS, VPN4DCBusiness & CE L2VPN LDP BGP PW Sign (VPLS)DC Interconnect L2VPN BGP MAC Sign (EVPN)MPLS transport LDP BGP+Label (Unified MPLS)Data Center OSPF/ISIS BGP + MultipathMassive Scale DMVPN NHRP / EIGRP BGP + Path DiversityCampus/Ent L3VPN BGP BGP

5

BGP-cервисы, о которых пойдет речь

BGP Fast Convergence/BGP PICAdd-PathAutomated Route-Target FilteringAIGPMulti-AS BGPAttribute Filtering & Error HandlingBGP Origin ValidationBGP Graceful ShutdownVRF-aware Conditional Advertising

VPN Distinguisher eiBGP multi-pathper-CE LabelL3VPN iBGP PE-CE BGP Management Protocol (BMP)BGP Flowspec

6

BGP-cервисы, о которых пойдет речь

BGP Fast Convergence/BGP PICAdd-PathAutomated Route-Target FilteringAIGPMulti-AS BGPAttribute Filtering & Error HandlingBGP Origin ValidationBGP Graceful ShutdownVRF-aware Conditional Advertising


7

10.1.1.0/24VPN1 Site #1

MPLS CloudTraffic Flow 10.2.2.0/24

VPN1 Site #2

PE1

PE2

PE3

PE4

CE1 CE2

Primary

Backup

RR

PIC Edge: защита от отказа линка PE-CE

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

local preference) PE4: настраивается advertise-best-external, для распространения маршрута

полученного через линк PE4-CE2 PE3: настраивается additional-paths install, для использования основного и

резервного пути 8

10.1.1.0/24VPN1 Site #1


VPN1 Site #2

PE1

PE2

PE3

PE4

CE1 CE2

Primary

Backup

RR


PE3 имеет основной и резервный путь Основной – через линк PE3-CE2 Резервный – через PE4, как best external маршрут

Что произойдет при падении линка PE3-CE2?

9

10.1.1.0/24VPN1 Site #1


VPN1 Site #2

PE1

PE2

PE3

PE4

CE1 CE2

Primary

Backup

RR


PE3 (например, с помощью BFD) определяет отказ PE3-CE2 линка В CEF производится замена метки, таким образом активным становится

резервный маршрут Трафик переключается на маршрут, проходящий через PE4 и линк PE4-CE2

10

10.1.1.0/24VPN1 Site #1

MPLS Cloud

Traffic Flow

10.2.2.0/24VPN1 Site

#2

PE1

PE2

PE3

PE4

CE1 CE2

Primary

Backup

RR

Withdraw route via PE3


PE3 производит удаление маршрута связанного с ликом PE3-CE2 (withdrawal) Соответствующие апдейты рассылаются всем PE-маршрутизаторам

11

10.1.1.0/24VPN1 Site #1

MPLS Cloud

Traffic Flow

10.2.2.0/24VPN1 Site

#2

PE1

PE2

PE3

PE4

CE1 CE2

Primary

Backup

RR

Withdraw route via PE3


Процесс BGP на PE-маршрутизаторах выбирает новый bestpath Новый bestpath теперь проходит через PE4 Трафик перенаправляется непосредственно в сторону PE4, а не через PE3

12

Вопрос: Каким образом PE узнают об альтернативных маршрутах?

По умолчанию RR всегда отражает Best-Route

RR

PE2

PE3

ZNH:PE3, P:Z

NH:PE2, P:Z

PE1

Prefix ZVia PE2

E0

E0

Prefix ZVia E0

Prefix ZVia E0

NH:PE2, P:Z

15

Использование Shadow-сессии

Простое развертывание – нет необходимости апгрейдить существующие маршрутизаторы, необходимо только организовать новую iBGP-сессию для дополнительного маршрутаРазличные iBGP-сессии «завязаны» на анонсирование собственного best path

RR1NH:PE2, P:Z

NH:PE2, P:ZPrefix ZVia PE2Via PE3NH:PE3, P:Z

NH:PE3, P:Z

PE2

PE3

ZPE1

16

BGP Add-Path

Add-Path обеспечивает распространение нескольких путей (от 2 до X)На принимающем BGP-маршрутизаторе также требуется поддержка Add-Pathфункциональности

RR1 NH:PE2, P:Z AP 1NH:PE2, P:Z

Prefix ZVia PE2Via PE3NH:PE3, P:Z AP 2

NH:PE3, P:Z

PE2

PE3

ZPE1

17

Режимы использования BGP Add-path

IETF определяет 5 вариаций Add-x-Path (см. draft-ietf-idr-add-paths-guidelines). Две из них реализованы Cisco:Add-n-path: RR выполняет процесс вычисление наилучшего маршрута для всех путей и отсылает n лучших в сторону BR/PE.

Сценарий: Primary + n BackupAdd-all-path: RR отсылает все полученные маршруты в сторону BR/PE.

Решение дает наилучшее «path visibility». Оптимально для ECMP load balancing.

Новая функциональность в XR 4.3.1: Add-all-multipath и Add-all-multipath+backup

Справочная информация

18

Конфигурирование Add-Path – IOS-XR

Настраивается в режиме global address-family активируется для всех IBGP-пиров

Работает в per-neighbour режиме router bgp 100address-family ipv4 unicastadditional-paths send!address-family vpnv4 unicastadditional-paths send!neighbor 1.1.1.1remote-as 100address-family ipv4 unicast!address-family vpnv4 unicast!!neighbor 2.2.2.2remote-as 100capability additional-paths send disableaddress-family ipv4 unicast!


19

Автоматическая фильтрация Route Target

BGP Fast Convergence/BGP PIC Add-PathAutomated Route-Target FilteringAIGPMulti-AS BGPAttribute Filtering & Error HandlingBGP Origin ValidationBGP Graceful ShutdownVRF-aware Conditional Advertising


20


Из-за роста количества VPN-сервисов увеличивается нагрузка на VPN-маршрутизаторы

Ежегодный 10%-рост VPN-таблиц Высокая потребность в фильтрации нежелательных VPN-маршрутов перед тем,

как отправлять их в сторону сервисного PE-маршрутизатора, который все равно должен будет их отбросить.

Множество подходов к фильтрации: Специальное extended community ORF Новый тип address family: RT-фильтр

21

PE-1

PE-2

PE-3

PE-4

RR-1 RR-2

VRF- Blue

VRF- Red

VRF- Red

VRF- Green

RT-Constraint:NLRI= {VRF-Blue, VRF-Red}

RT-Constraint:NLRI= {VRF-Green, VRF-Purple}

RT-Constraint:NLRI= {VRF-Purple, VRF-Blue}

RT-Constraint:NLRI= {VRF-Red, VRF-Green}

RT-Constraint:NLRI= {VRF-Blue, VRF-Red, VRF-Green}

RT-Constraint:NLRI={VRF-Green, VRF-Purple, VRF-Blue}

VRF- Green

VRF- Purple

VRF- Purple

VRF- Blue


Данный подход улучшает масштабируемость и производительность PE и RR, путем отсылки только релевантных VPN-маршрутов

router bgp as-numberaddress-family rtfilter unicastneighbor {ip-address | peer-group-name} activateneighbor {ip-address | peer-group-name} send-community extended

22

RTC для PE старого типа• Для нормального функционирования BGP Route-Target Constraint (RTC) необходимо, чтобы PE-

маршрутизаторы поддерживали новый тип AF RTC• Для PE старого типа (без поддержки RTC) применяется иной подход, который также обеспечивает

информирование соседей (например, RR) о локальных RT. Такие PE анонсируют «специальные» маршруты совместно с набором RT, а также стандартного BGP community

• Наличие такого community информирует RR о наличии RT и способствует формированию таблицы фильтрации RT как и в случае механизма RTC.

SITE 1

SITE 2BGP RTC session

BGP sessionusing

“special” routes with community

draft-ietf-idr-legacy-rtc-0323

RTC для PE старого типа

Как это работает? Используется традиционный обмен VPN-

префиксами для сигнализирования о RT membership

PE анонсирует специальные маршруты + информацию о всех RT, настроенных на PE

Дополнительно PE тегирует эти маршруты отдельным community

Наличие этого community информирует RR о том, что необходимо учитывать прикрепленные RT для формирования таблицы RT membership

!router bgp 1address-family vpnv4 unicastneighbor 10.1.1.1 accept-route-legacy-rt

!

ip vrf route-filterrd 55:1111export map SET_RT

route-map SET_RT permit 10match ip address prefix-list RT_NET1set community 65535:2 (0xFFFF0002)set extcommunity rt 255.220.0.0:12241 255.220.0.0:12242 additiveset extcommunity rt 255.220.0.0:12243 255.220.0.0:12244 additiveset extcommunity rt 255.220.0.0:12245 255.220.0.0:12246 additiveset extcommunity rt 255.220.0.0:12247 255.220.0.0:12248 additiveset extcommunity rt 255.220.0.0:12249 255.220.0.0:12250 additive

!route-map SET_RT permit 20match ip address prefix-list RT_NET2set community 65535:2 (0xFFFF0002)set extcommunity rt 255.220.0.0:12251 255.220.0.0:12252 additiveset extcommunity rt 255.220.0.0:12253 255.220.0.0:12254 additiveset extcommunity rt 255.220.0.0:12255 additive

!

ip route vrf route-filter 1.1.1.1 255.255.255.255 Null0 – (matching prefix-set RT_NET1)ip route vrf route-filter 1.1.1.2 255.255.255.255 Null0 –(matching prefix-set RT_NET2)

route-map LEG_PE permit 10 match ip address prefix-list RT_NET1 RT_NET2set community no-advertise additive

router bgp 55address-family vpnv4 unicastneighbor x.x.x.x route-map LEG_PE out

Route-reflector

Legacy-PE

AIGP



25

AIGP - Accumulated IGP Metric Attribute для BGP (draft-ietf-idr-aigp-09)

Новый BGP-атрибут, который аккумулирует информацию об IGP метриках в разных IGP-доменах (Optional, non-transitive BGP path attribute)

Обеспечивает возможность для BGP принимать решение по выбору кратчайшего маршрута между узлами в различных ASосновываясь на IGP-метриках.

Актуально для использования в “Unified MPLS” архитектуре. Помогает решать проблемы масштабирования IGP.

Позволяет обеспечивать перенос nexthop-префиксов/меток через границы AS внутри единого административного домена.

Ingress PE выбирает наилучший маршрут используя модифицированный best path selection процесс основываясь на значении AIGP метрики.

IGP 1

IGP 2

IGP 3

A1

PE1

A2

A3 A4

PE2

PE1, NH=A1AIGP= 10

PE1, NH=A3AIGP= 10+20

10 15

20 20

PE1, NH=A4AIGP= 15+20

PE1, NH=A2AIGP= 15

26

Multi-AS BGP



27

Знакомство с Multi-AS BGP

Функционирование нескольких BGP-процессов на одном маршрутизаторе Каждый процесс может использовать свой собственный номер AS Global AF не может функционировать более чем в одной AS, за исключением vpnv4 и vpnv6 VPN address-families могут быть скофигурированы в разных AS при условии, что они не имеют

пересекающихся VRF

RP

AS 1ipv4

AS 1ipv6

RP

AS 1ipv4

AS 1 VRFs a PE-CE

AS 1 VRFs b PE-CE

RP

AS 1 ipv4

AS 2 vpnv4/VRF

Scale/Fault Isolation PE-CE/VRF Scale Service Integration

28

Multi-AS BGP – примеры конфигураций

router bgp 1 instance ipv4bgp router-id 10.0.0.1address-family ipv4 unicastneighbor 10.0.101.1

remote-as 1address-family ipv4 unicast

route-policy inbound inroute-policy outbound out

!!

!!

router bgp 1 instance ipv6bgp router-id 10.0.0.2address-family ipv6 unicastneighbor 10.0.101.2

remote-as 1address-family ipv6 unicast


!!

!!

router bgp 3 instance vpn1bgp router-id 20.0.0.1address-family vpnv4 unicastneighbor 20.0.101.1

remote-as 200address-family vpnv4 unicast


!!

!vrf foo!

!router bgp 3 instance vpn2

bgp router-id 20.0.0.2address-family vpnv4 unicastneighbor 20.0.101.2

remote-as 200address-family vpnv4 unicast


!!

!vrf bar!

!


29

Фильтрация атрибутов и управление ошибками



30

Фильтрация атрибутов и управление ошибками –ОбзорФильтрация BGP атрибутов

Существуют определенные атрибуты, которые приводят к нежелательным последствиям. Например, опциональный транзитивный атрибут ATTR_SETвключающий определенную информацию может послужить причиной отказов некоторого оборудования.

Защита от неизвестных/нежелательных атрибутов:— Блокирование определенных атрибутов— Блокирование диапазона non-mandatory атрибутов

Управление ошибками (Error-handling) draft-ietf-idr-optional-transitive-04.txt Принятые меры не должны быть избыточными Аккуратное исправление серьезных и игнорирование неопасных ошибок Предотвращение сброса сессии в большинстве случаев

31

Фильтрация атрибутов и управление ошибками –Архитектура

Атрибут с ошибками

Атрибут с некорректной длинной

Неизвестные атрибуты

Нежелательные атрибуты

Malformed BGP апдейт Транзитивные атрибуты

Фильтрация

Управление ошибками

Обработка NLRI …

32

Проверка происхождения BGP-префиксов



33

Проверка происхождения BGP-префиксов

• Поддержка функциональности RPKI RTR Отдельные базы данных для хранения записей record entries from the cache

• Анонсирование результата проверки пути IBGP-пирам используя расширенное community, внутри которого передается специальный path validation state

• Данная информация добавляется с помощью модифицированного route policy

34

Атака на префиксы (Prefix hijacking)

Варианты атак:• Анонс префикса (по ошибке или злоумышленник) • Анонс more specific-префикса В любом случае осуществляется попытка воровства трафика путем изменения маршрута:• Далее все, что угодно: Capture, sniff, redirect, manipulate traffic

Источник: nanog 46 preso35

Как выглядит решение?

Источник: nanog 46 preso36

Пример конфигурацииrouter bgp 64726bgp rpki server tcp 10.1.2.3 port 30000 refresh 60bgp bestpath prefix-validate allow-invalidneighbor 10.9.9.9 remote-as 64209neighbor 10.9.9.9 route-map EXMPL in!route-map EXMPL permit 10match rpki invalidset local-preference 50route-map EXMPL permit 20match rpki not-foundset local-preference 100route-map EXMPL permit 30match rpki validset local-preference 200route-map EXMPL permit 40!


37

BGP Graceful Shutdown



38


RFC 6198 – апрель 2011Ранее:

В случае обрыва сессии BGP выболнял withdraw для всех префиксов, полученных через эту сессию

BGP не имел механизма для предупреждения о том, что префикс вскоре будет недоступен (к примеру, для проведения плановых работ)

При использовании RR все было еще плачевнее, так как RR всегда скрывал альтернативные маршруты, анонсирую только best.

BGP Graceful Shutdown обеспечивает возможность провести обслуживание маршрутизатора без перерыва сервиса

Данная функциональность позволяет маршрутизатору уведомить соседа о перенаправлении трафика по другому маршруту. Через некоторое время сессия обрывается.

Уведомление обеспечивается выставлением атрибута Local Preference или специального community

#Graceful ShutdownPlease wait…

BGP/ Prefix 10.45 / localpref : 10

12

Traffic isredirected

3

39


Может использоваться well-known community GSHUTДля отправки атрибута GSHUT соседу используется команда: neighbor shutdown gracefulЭто позволяет безопасно отключить линк в рамках запланированного временного окна

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book.pdf

neighbor {ipv4-address | ipv6-address | peer-group-name} shutdown graceful seconds {communityvalue [local-preference value] | local-preference value}

40

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book.pdf

Задание условий при анонсирование префиксов в VRF



41

MPLS

Ранее: Условное анонсирование поддерживалось для IPv4 Unicast/Multicast address-familyСейчас: Появилась поддержка для IPv4 VRF, IPv6 Unicast и IPv6 VRF

VPN-A VPN-A

PE1 – 10.0.0.1

VPN-B VPN-B

RR2 – 10.0.0.2AS1

CE-101CE-204CE-104 CE-201 192.168.50.0/24128.16.16.0/24

RD: 192.168.50.0/24 RD: 192.168.50.0/24

PE4 - 10.0.0.4

VRF RED Routing TableIf exist 192.168.50.0/24Advertise 128.16.16.0/24

Задание условий при анонсирование префиксов в VRF

Использование атрибута VPN Distinguisher


VPN Distinguisher eiBGP for Global Routing Contextper-CE LabelL3VPN iBGP PE-CE BGP Management Protocol (BMP)BGP Flowspec

43

Использование атрибута VPN Distinguisher

• Один VPN может охватывать ISP1 и ISP2• RT желательно сохранить приватными

внутри AS• eBGP использует Атрибут VPN Distinguisher

(VD) для унификации VPN, оставляя значения RT уникальными в рамках своей AS

Service Provider 1

Service Provider 2

RED Corp.Site1

RED Corp.Site2VPN

RED CorpRT = 201:100 VPN

RED CorpRT = 700:1

eBGP

VPNRED CorpVD = 600:1

ip extcommunity-list 22 permit rt 201:100!route-map rt-mapping permit 10match extcommunity 22set extcomm-list 22 deleteset extcommunity vpn-distinguisher 600:1

!route-map rt-mapping permit 20!router bgp 3000neighbor 192.168.103.1 remote-as 3000address-family vpnv4neighbor 192.168.103.1 activateneighbor 192.168.103.1 route-map rt-mapping outexit-address-family

!

ip extcommunity-list 101 permit VD:600:1!route-map rtmap2 permit 10match extcommunity 101set extcomm-list 101 deleteset extcommunity rt 700:1 additive

!route-map rtmap2 permit 20!router bgp 4000neighbor 192.168.0.50 remote-as 4000address-family vpnv4neighbor 192.168.0.50 activateneighbor 192.168.0.50 route-map rtmap2 inexit-address-family

!44

Механизм eiBGP multi-path



45

Механизм eiBGP multi-path

Ранее: Процедура выбора наилучшего пути в BGP рассматривает eBGP как более

предпочтительный, чем iBGP

Новое: Функция eiBGP multipath исключает данный критерий из процедуры BGP path selection Механизм ECMP hash load balancing будет отправлять 50% трафика через iBGP и 50%

через eBGP

Service Provider(MPLS/L3VPN) Customer

PE1

PE2

CPE1

CPE2

eBGP

eBGP

iBGP50%

50%

!router bgp 64496address-family ipv4 unicastmaximum-paths eibgp 4

!address-family ipv6 unicastmaximum-paths eibgp 4

!

Назначение метки per-CE



47

Назначение метки per-CE

Позволяет назначать сервисную VPN-метку на PE-маршрутизаторе в режиме per-CE, нежели per-prefix. Для чего?

Снижается число MPLS-меток, которые генерирует PE(пространство меток всегда ограничено – особенно критично для IBR)

Есть ряд ограничений: BGP PIC Edge требует поддержки функционала «resilient

per-CE label» (XR 5.1.0) Поддерживается только single hop eBGP Другие ограничения можно найти в release-notes

ISP (MPLS VPN)

Customer

VRF

PE

label-allocation-mode per-ce

CE

L3VPN iBGP PE-CE



49

AS# 200AS# 200

L3VPN iBGP PE-CE (RFC6368)

Использование iBGP в качестве PE-CE протоколаЗачем?

iBGP атрибуты клиента сохраняются в VPN-инфраструктуре Исключается установка номера автономной системы ISP в

AS_PATHКаким образом?

Поддержка в рамках RFC6368 PE помещает полученные iBGP атрибуты внутрь новых атрибутов

ATTR_SET и транспортирует их через инфраструктуру ISP Целостность характеристик iBGP в рамках L3 VPN Примечание: требуется использование уникального RD per PE

AS# 100

Customer VRFCustomer VRF

iBGPiBGP

Service Provider Backbone

router bgp 100 address-family ipv4 vrf blueneighbor 10.0.0.1 remote-as 200neighbor 10.0.0.1 local-as 200neighbor 10.0.0.1 internal-vpn-clientneighbor 10.0.0.1 route-reflector-client

BGP Management Protocol



51

BGP Management Protocol (BMP)BMP может быть использован для

мониторинга жизненного цикла BGPсессий

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

BMP обеспечивает доступ к Adj-RIB-In в рамках BGP сессии и формирует массив статистической информации. Статистика может быть передана на специальный узел для последующего анализа.

Конфигурация: Разрешить мониторинг per neighbour Настроить сервер BMP

Customer

Service Provider

BMP Server

BMPsession

http://tools.ietf.org/html/draft-ietf-grow-bmp-07

!router bgp 65000neighbor 30.1.1.1 bmp-activate server 1!bmp server 1activateaddress 10.1.1.1 port-number 8000description LINE SERVER1failure-retry-delay 40flapping-delay 120initial-delay 20set ip dscp 5stats-reporting-period 30update-source ethernet 0/0exit-bmp-server-mode!

52

http://tools.ietf.org/html/draft-ietf-grow-bmp-07

Flowspec: Контроль отдельных потоков трафика посредством BGP


Введение в Flowspec

• Большинство современных механизмов для борьбы с DDoS используют BGP для перенаправления и отбрасывания вредоносного трафика

• BGP (как любой другой протокол маршрутизации) обеспечивает маршрутизацию на основе адреса назначения

• Информация протокола BGP может инжектироваться в сеть специализированным сервером - Контроллером

• Почему бы не использовать для маршрутизации трафика не только информацию об адресе назначения?

Что хотелось бы получить в идеале: Фильтрация/Перенаправление/Зеркалирование с привязкой к Приложению Гибкость при «выделении» потока, быстрая адаптация к изменениям Простота конфигурирования

Пример: защита от DDoS

Customer Provider

WebsiteIP=1.1.1.1

CE InternetBGP : 1.1.1.0/24

PE

Transit1

Tra`nsit2


Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

DDoS Traffic

BGP : 1.1.1.0/24


Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

DDoS Traffic

BGP : 1.1.1.0/24


Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

DDoS Traffic

BGP : 1.1.1.0/24


Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

DDoS Traffic

DDoS TrafficBGP : 1.1.1.0/24

Решение: Remotely Triggered Black Hole

Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

DDoS Traffic

DDoS Traffic

Предполагается использовать специальное «blackhole» community выданное ISP(например, 64500:666)

BGP : 1.1.1.0/24

BGP : 1.1.1.1/32Com. : 64500:666


Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

DDoS Traffic

DDoS TrafficBGP : 1.1.1.0/24

BGP : 1.1.1.1/32Com. : 64500:666

Предполагается использовать специальное «blackhole» community выданное ISP(например, 64500:666)


Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

DDoS Traffic

DDoS Traffic

Все префиксы помеченные «blackhole» community получают новый специальный nexthop, который рекурсивно указывает на Null0

BGP : 1.1.1.0/24

BGP : 1.1.1.1/32Com. : 64500:666

1.1.1.1/32 Discard

1.1.1.1/32 Discard


Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

DDoS Traffic

BGP : 1.1.1.0/24

BGP : 1.1.1.1/32Com. : 64500:666

1.1.1.1/32 Discard

1.1.1.1/32 Discard

Все префиксы помеченные «blackhole» community получают новый специальный nexthop, который рекурсивно указывает на Null0

Все замечательно, но что, если все-таки необходимо возобновить работоспособность WWW-сервера?

DDoS атака завершена, но трафик в принципе не пересылается на веб-сервер….

RTBH удобное решение, но подходит не для всех ситуаций.


Альтернативное решение: Маршрутизация на основе политик (PBR)Идентификация DDoS-трафика осуществляется на базе условий –используются механизмы классификации (MATCH):

Адрес источника/назначения Протокол Размер пакета Т.д.

Действия с трафиком, попавшим под критерии DDoS Отбрасывание пакетов Логирование Ограничение скорости досупа Перенаправление Т.д...

Не является ли это тем решением, что мы искали?

Альтернативное решение: Маршрутизация на основе политик (PBR)Хорошее решение в случае, если:

Реализовано с помощью специализированных аппаратных средств, что не всегда возможно даже на операторском оборудовании

Есть возможность определять критерии и последующие манипуляции с трафиком с хирургической точностью

На практике: Клиент вынужден сам звонить провайдеру с объяснением ситуации и уровня ее

критичности По мнению клиента провайдер должен применить политики и фильтры на

каждом магистральном и граничном маршрутизаторе Клиенту необходимо звонить провайдеру с просьбой удалить политики

фильтрации после исчезновения атаки

В реальности все это не работает так, как хотелось бы…

BGP FlowSpec а качестве наилучшей альтернативы

Сравнение с другими решениями: Статический PBR становится динамическим решением! Есть возможность распространять правила PBR в сети Используется существующий канал для работы control plane

Каким образом? Используя существующую MP-BGP инфраструктуру

Используется новый тип NLRI (AFI=1, SAFI=133)

Механизм распространения политик идентификации Flow (RFC5575)

7. ICMP Type8. ICMP Code9. TCP Flags10. Packet length11. DSCP12. Fragment

1. Destination IP Address2. Source IP Address 3. IP Protocol4. Port 5. Destination port6. Source Port

The MP_REACH_NLRI – RFC 4760

+---------------------------------------------------------+| Address Family Identifier (2 octets) +---------------------------------------------------------+| Subsequent Address Family Identifier (1 octet) +---------------------------------------------------------+| Length of Next Hop Network Address (1 octet) +---------------------------------------------------------+| Network Address of Next Hop (variable) +---------------------------------------------------------+| Reserved (1 octet) +---------------------------------------------------------+| Network Layer Reachability Information (variable) +---------------------------------------------------------+

Манипуляции с трафиком на базе BGP Flowspec

Действие ОписаниеTraffic-Rate Возможность ограничить flow до данного

значенияTraffic-Marking Перезаписать значение DSCPRedirect VRF Перенаправить в VRF (используя route-

target)Например: “очистка” трафика

Redirect NH Перенаправление на альтернативный next-hop

Борьба с DDoS с помощью BGP FlowSpec

Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

UDP DDoS Traffic

UDP DDoSTraffic

BGP : 1.1.1.0/24

Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

UDP DDoS Traffic

UDP DDoSTraffic

BGP : 1.1.1.0/24

IP Destination: 1.1.1.1/32IP Protocol 17 (UDP)PacketSize <=28Rate-limit 10M

Клиент анонсирует адрес web-сервера с описанием Flow и требуемым по отношению к Flow действием


Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

UDP DDoS Traffic

BGP : 1.1.1.0/24



Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

UDP DDoS Traffic

BGP : 1.1.1.0/24

Legitimate TCP Traffic



Архитектура FlowSpec используемая в реальной жизниВ реальной жизни описаная архитектура почти не используется:

Сервис-провайдеры обычно не доверяют информации, приходящей от клиентов;

Требуется использовать новую комбинацию BGP AFI/SAFI при взаимодействии клиента и провайдера;

Что используется взамен? ISP используют централизованный Flowspec Контроллер Контроллер имеет связность с SP-маршрутизаторами Только FS-контроллеру разрешено распределять политики FlowSpec в сети FS-контроллер всегда является доверенным элементом с точки зрения сети Контроллер управляется со стороны сервис-провайдера

Использование FlowSpec-Контроллера

Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

UDP DDoS Traffic

BGP : 1.1.1.0/24

Flowspec

ПорталКонтроллер

Customer Provider

WebsiteIP=1.1.1.1

CE InternetPE

Transit1

Transit2

UDP DDoS Traffic

BGP : 1.1.1.0/24

Legitimate TCP Traffic

ПорталКонтроллер

Flowspec

Использование FlowSpec-Контроллера

CiscoRu Cisco CiscoRussia

Ждем ваших сообщений с хештегом#CiscoConnectRu

Пожалуйста, используйте код для оценки доклада

7615

Ваше мнение очень важно для нас!

Спасибо за внимание!

24.11.2014 © 2014 Cisco and/or its affiliates. All rights reserved.

Backup


Развитие функционала BGP в IOS XR

4.0 4.1 4.1.1 4.2 4.2.1 4.2.3 4.3.0 4.3.1

• Add Path Support• Accumulated

Interior Gateway Protocol (AIGP) Metric Attribute

• Unipath PIC for non-VPN address-families (6PE/IPv6/IPv4Unicast)

• RT-Constraint

• BGP Accept Own

• Multi-Instance/Multi-AS

• BGP 3107 PIC Update for Global Prefixes

• Prefix Origin Validation based on RPKI

• PIC for RIB and FIB

• Attribute Filtering and Error handling

• DMZ Link Bandwidth for Unequal Cost Recursive Load Balancing

• Selective VRF Download• 6PE/6vPE over L2TPv3• Next-Generation

Multicast VPN

• BGP Based DDoSMitigation

4.3.2

• PBB-EVPNfor normalized-handoff

• Virtual Route-Reflector

5.1.0

• BGP – mVPN PE-PE ingress replication

• BGP Link State distribution

• BGP static network• BGP mVPN multi-

instance• RPL IPv6 bits address

match• Resilient per-CE Label

5.2.0

• Flowspec

Развитие функционала BGP в Cisco IOS

15.2(1)S 15.2(2)S 15.2(4)S 15.3(1)S 15.3(2)S

Origin AS Validation

Gracefull ShutdowniBGP NSRmVPN BGP SAFI 129NSR without Route-Refresh

Additional PathAttribute Filtering and Error HandlingDiverse PathGraceful ShutdownIPv6 client for Single hop BFDIPv6 PIC Core and EdgeRT ConstraintIP Prefix export from a VRF into global Table

mVPNv6 Extranet Support

Local-AS for iBGP & allow-policyRT/VPN-ID Attribute Rewrite Wildcard

15.3(3)S

MVPN BGP C-Route Full SM SupportVRF aware conditionaladvertisement

15.4(1)S

VRF aware BGP translate-updateEVPN / PBB EVPN route-reflectionBMP (BGP monitoring protocol)RTC for legacy PEGSHUT enhancement

80

Развитие функционала BGP в IOS XE

3.8 3.9

Multicast VPN BGP DampeningMultiple Cluster IDsVPN Distinguisher Attribute

IPv6 NSRLocal-AS for iBGP & Allow-policyRT or VPN-ID Rewrite WildcardVRF Aware Conditional Advertisement

3.10 3.11

EVPN/PBB_EVPN route-reflectionRTC for Legacy PEGSHUTBGP Monitoring Protocol

L3VPN iBGP PE-CENSR Support for MPLS VPNv4 and VPNv6 Inter AS Option BeiBGP multipath for non VRFInterfaces (v4/v6)L3VPN per CE label allocationMVPN BGP C-Route Full SM Support

http://www.cisco.com/en/US/docs/routers/asr1000/release/notes/asr1k_rn_rel_notes.pdfhttp://www.cisco.com/en/US/docs/routers/asr1000/release/notes/asr1k_rn_rel_notes.html

81

http://www.cisco.com/en/US/docs/routers/asr1000/release/notes/asr1k_rn_rel_notes.pdf

http://www.cisco.com/en/US/docs/routers/asr1000/release/notes/asr1k_rn_rel_notes.html

Развитие функционала BGP в NX OS

5.2 6.0 6.1

Default information originate supportFlexible distance manipulation withInject mapUnsupress mapas-format command for AS-plain & AS-dotEnhancements for removal of private ASenable route target import-export in default VRFInterAS option B-liteBGP Authentication for Prefix-based neighbors

BGP AddPathBGP send community bothBGP Neighbor AF weight command

BGP med confed and AS multipath-relaxBGP next hop self for route reflector

Prefix Independent Convergence (Core)local-asAS Override (allowas-in)Disable 4-byte AS advertisementMP BGP – MPLS VPNs, 6PE, MDT

6.2

82

Technology

Расширенные возможности протокола BGP