BGP

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску

Состояния соседства

http://habrastorage.org/getpro/habr/post_images/442/780/549/442780549c2f45cdda10773121b2800d.png

Сообщения

  • Open - отправляется только на стадии установления соседства. Содержит параметры BGP соседа.
  • Update - передает routing info между соседями. Атрибуты и список префиксов, подходящий под данные атрибуты.
  • Keepalive - для удостоверения, что с соседством все ок.
  • Notification - в случае если не прошел keepalive или update.
  • Refresh - soft clearing BGP сессии.

Атрибуты пути (path attributes)

Атрибуты пути разделены на 4 категории:

  1. Well-known mandatory — все маршрутизаторы, работающие по протоколу BGP, должны распознавать эти атрибуты. Должны присутствовать во всех обновлениях (update).
  2. Well-known discretionary — все маршрутизаторы, работающие по протоколу BGP, должны распознавать эти атрибуты. Могут присутствовать в обновлениях (update), но их присутствие не обязательно.
  3. Optional transitive — могут не распознаваться всеми реализациями BGP. Если маршрутизатор не распознал атрибут, он помечает обновление как частичное (partial) и отправляет его дальше соседям, сохраняя не распознанный атрибут.
  4. Optional non-transitive — могут не распознаваться всеми реализациями BGP. Если маршрутизатор не распознал атрибут, то атрибут игнорируется и при передаче соседям отбрасывается.

Autonomous system path

✔️Well-known Mandatory
  • Описывает через какие автономные системы надо пройти, чтобы дойти до сети назначения.
  • Номер AS добавляется при передаче обновления из одной AS eBGP-соседу в другой AS.

Используется для:

  • обнаружения петель
  • применения политик

Каждый сегмент атрибута AS path представлен в виде поля TLV (path segment type, path segment length, path segment value):

  • path segment type — поле размером 1 байт для которого определены такие значения:
    • 1 — AS_SET: неупорядоченное множество автономных систем, через которые прошел маршрут в сообщении Update,
    • 2 — AS_SEQUENCE: упорядоченное множество автономных систем, через которые прошел маршрут в сообщении Update
  • path segment length — поле размером 1 байт. Указывает сколько автономных систем указано в поле path segment value
  • path segment value — номера автономных систем, каждая представлена полем размером 2 байта.

Операторы регулярных выражений

Список регулярный выражений для AS Path
{m,n} От m до n
{m} m
{m,} m или более
* Все
+ 1 или более
? 0 или 1
| Один из двух
^ Начало community
$ Конец community
[] Список или массив букв или цифр
( ) Группирует символы
() Ничего (null)

Next-hop

✔️Well-known Mandatory
  • IP-адрес следующей AS для достижения сети назначения.
  • Это IP-адрес eBGP-маршрутизатора, через который идет путь к сети назначения.
  • Атрибут меняется при передаче префикса в другую AS (по-умолчанию подставляется ip-адрес bgp-соседа)
  • Атрибут не меняется при передаче префикса в ту же AS

Можно изменить с помощью policy на выходе: 

[edit policy-options policy-statement nexthop-self]
R1# show 
term localpref {
    then {
        next-hop self;
    }
}

Или же на входе: 

[edit policy-options policy-statement nexthop-peer]
R2# show 
term localpref {
    then {
        next-hop peer-address;
    }
}

Origin

✔️Well-known Mandatory

Атрибут Origin — указывает на то, каким образом был получен маршрут в обновлении.

Возможные значения атрибута
0 IGP NLRI получена внутри исходной автономной системы
1 EGP NLRI выучена по протоколу Exterior Gateway Protocol (EGP)
2 Incomplete NLRI была выучена каким-то другим образом

Local preference

✔️Well-known Discretionary
  • Указывает маршрутизаторам внутри автономной системы как выйти за её пределы.
  • Выбирается та точка выхода у которой значение атрибута больше.
  • Этот атрибут передается только в пределах одной автономной системы.
  • На маршрутизаторах Cisco и Juniper по умолчанию значение атрибута — 100.
  • Работает только между IBGP.
  • Если EBGP-сосед получает обновление с выставленным значением local preference, он игнорирует этот атрибут.
  • В Junos lpf можно задать через policy и в protocol bgp. Если задан обоими способами, то будет назначен lpf из policy.
  • Обычно используется на бордерах.

Когда в сети есть 2 бордера, которые получают один и тот же маршрут извне, и бордеры навешивают одинаковый повышенный lpf через export policy, в таком случае соседи IBGP получат маршрут с измененным lpf, но трафик не сможет по-правильному пути выйти из AS. Из-за того что бордеры тоже друг от друга будут получать маршрут с повышенным lpf. Решение: правильно менять lpf через import policy.

Atomic aggregate

✔️Well-known Discretionary

Aggregator

✔️Optional Transitive

Communities

✔️Optional Transitive
  • Тегирование маршрутов
  • Существуют предопределенные значения (well-known), которые не требуется определять локально на своем оборудовании
  • По умолчанию не пересылаются соседям
  • Одному маршруту может быть присвоено несколько communities
  • Один из вариантов применения: передается соседней AS для управления входящим трафиком

Значения от 0x00000000 до 0x0000FFFF и от 0xFFFF0000 до 0xFFFFFFFF зарезервированы.

Как правило community отображаются в формате ASN:VALUE. В таком формате, доступны для использования community от 1:0 до 65534:65535. В первой части указывается номер автономной системы, а во второй значение community, которое определяет политику маршрутизации трафика.

Некоторые значения communities предопределены. RFC1997 определяет три значения таких community. Эти значения должны одинаково распознаваться и обрабатываться всеми реализациями BGP, которые распознают атрибут community.

Если маршрутизатор получает маршрут, в котором указано предопределенное значение communities, то он выполняет специфическое, предопределенное действие основанное на значении атрибута.

Предопределенные значения communities (Well-known Communities):

no-export (0xFFFFFF01)

Все маршруты которые передаются с таким значением атрибута community не должны анонсироваться за пределы AS. То есть, маршруты не анонсируются EBGP-соседям, но анонсируются внешним соседям в конфедерации.

Пример использования

AS1 подключена к AS2 двумя линками (multinoming). AS1 анонсирует 172.17.0/16 в AS2. Для оптимальной маршрутизации, AS1 хочет посылать некоторые более специфичные маршруты через один из этих линков, при этом остальному интернету вовсе не обязательно получать эти специфики. Для этой цели AS1 использует community no-export, и посылает 172.17.0/17 в один из стыков с AS2, и 172.17.128/17 во второй стык. AS2 видит эти маршруты и выбирает их как более специфичные. Кроме того, эти маршруты видят все iBGP-соседи в пределах AS2. Тем не менее, за пределы AS2 в Интернет анонсируется только 172.17.0/16.

AS customer имеет 2 ISP (AS1, AS2). AS1 - основной. Если AS customer хочет получать выход в инет только через AS1, то в сторону AS2 можно просто посылать маршруты с no-export. Но при этом важно, что при падении AS1, AS customer будет доступна только локальным пользователям AS2, но не всему интернету.

no-advertise (0xFFFFFF02)

Все маршруты которые передаются с таким значением атрибута community не должны анонсироваться другим BGP-соседям.

no-export-subconfed (0xFFFFFF03)

Все маршруты которые передаются с таким значением атрибута community не должны анонсироваться внешним BGP-соседям (ни внешним для конфедерации, ни настоящим внешним соседям). В Cisco это значение встречается и под названием local-as.

Маршрутизаторы, которые не поддерживают атрибут community, будут передавать его далее, так как это transitive атрибут.

set policy-options policy-statement community test-community members [65510:555 65610:999]     - [x and y]
set policy-options policy-statement test term 1 then community (add|set|delete) test-community

set policy-options policy-statement community all-community members  "*:*"

С communities широко используются регулярные выражения.

Примеры

100:* - all posible community values with AS 100.

11.1:666 - 1101:666, 1111:666, 1121:666, etc. 

show route community *:20
show route community-name

Список операторов регулярных выражений для Community

Список операторов регулярных выражений для Community
{m,n} От m до n
{m} m
{m,} m или более
* Все
+ 1 или более
? 0 или 1
| Один из двух
^ Начало community
$ Конец community
[] Список или массив букв или цифр
( ) Группирует символы
() Ничего (null)

Multi exit discriminator (MED)

Атрибут MED:

  • Используется для информирования eBGP-соседей о том, какой путь в автономную систему более предпочтительный.
  • Атрибут передается между автономными системами.
  • Маршрутизаторы внутри соседней автономной системы используют этот атрибут, но, как только обновление выходит за пределы AS, атрибут MED отбрасывается.
  • Чем меньше значение атрибута, тем более предпочтительна точка входа в автономную систему.
  • Исходя из названия - используется только в тех случаях, когда между AS есть несколько линков.
  • Сравнение MED (при прочих равных) происходит если один и тот же префикс пришел от одной и той же AS. Если будет анонс этого префикса с более низким MED, но из другой AS, то он не будет рассматриваться как вероятный вариант для использования.

Weight (проприетарный атрибут Cisco)

Атрибут Weight:

  • Позволяет назначить "вес" различным путям локально на маршрутизаторе.
  • Используется в тех случаях, когда у одного маршрутизатора есть несколько выходов из автономной системы (сам маршрутизатор является точкой выхода).
  • Имеет значение только локально, в пределах маршрутизатора.
  • Не передается в обновлениях.
  • Чем больше значение атрибута, тем более предпочтителен путь выхода.

Касательно всех атрибутов

Атрибуты, при выборе best, считаются лучшими с наименьшими значением. Это правило касается всех атрибутов, кроме Local Preference

Механизмы управления трафиком

Входящим

  • AS path prepend
  • Community (если поддерживает провайдер)
  • MED (подключение к одной и той же AS)
  • Анонс разных префиксов через разных ISP

Исходящим

  • Проприетарный атрибут Cisco weight (локально на маршрутизаторе)
  • Атрибут Local Preference (локально в AS)
  • Балансировка трафика ← Чоо? O_o

Выбор лучшего пути (BGP Active Route Selection)

  • Juniper
  1. Prefer highest local preference value
  2. Prefer shortest AS-path length
  3. Prefer lowest Origin value
  4. Prefer lowest MED value
  5. Prefer routes learned from an EBGP peer over an IBGP peer
  6. If the remaining routes were learned through IBGP, use the path with the lowest IGP cost to the IBGP peer.
  7. For EBGP received routes, prefer the current active route; otherwise, prefer routes from the peer with the lowest RID
  8. Prefer paths with the shortest cluster length
  9. Prefer routes from the peer with the lowest peer ID


Multipath

Link Bandwidth Extended Community

При включенном multipath можно задать желаемую балансировку между линками через extended community. Это механизм описан в draft-ietf-idr-link-bandwidth-06, и не является стандартизированным, следовательно, возможно, он не будет работать с некоторыми вендорами. В JunOS поддерживается.

Пример использования:

R1 и R2 соединены напрямую через ва сабинтерфейса, на каждом из которых висит своя /30 сеть 

|     | ge-0/0/0.10 ----- ge-0/0/0.10 R2 |    |
|  R1 |                                  | R2 |
|     | ge-0/0/0.20 ----- ge-0/0/0.20 R2 |    |

Конфиг R1: 

R1> show configuration protocols bgp 
group ebgp {
    multipath;
    neighbor 10.1.0.2 {
        description R2;
        export from-direct;
        peer-as 2222;
    }
    neighbor 10.2.0.2 {
        description R2;
        export from-direct;
        peer-as 2222;
    }
}

Конфиг R2: 

R2> show configuration interfaces lo0   
unit 0 {
    family inet {
        address 2.2.2.2/32;
    }
    family mpls;
}

> show configuration policy-options 
policy-statement bw20 {
    then {
        community add bw20;
    }
}
policy-statement bw80 {
    then {
        community add bw80;
    }
}
policy-statement from-direct {
    term redistribute-direct {
        from protocol direct;
        then accept;
    }
    term default {
        then reject;
    }
}
community bw20 members bandwidth:2222:2500000; // 2500000 байт в секунду — это 20% от 100Мегабит
community bw80 members bandwidth:2222:10000000; // 10000000 байт в секунду — это 80% от 100Мегабит

R2> show configuration protocols bgp 
group ebgp {
    neighbor 10.1.0.1 {
        description R1;
        export [ bw20 from-direct ]; // На одно из  соседств навешивается community, отображающее, что линк загружен на 20%
        peer-as 1111;
    }
    neighbor 10.2.0.1 {
        description R1;
        export [ bw80 from-direct ];// На второе соседство навешивается community, отображающее, что линк загружен на 80%
        peer-as 1111;
    }
}

Что получилось: 

R1> show route 2.2.2.2 extensive        

inet.0: 11 destinations, 19 routes (11 active, 0 holddown, 0 hidden)
2.2.2.2/32 (2 entries, 1 announced)
TSI:
KRT in-kernel 2.2.2.2/32 -> {10.2.0.2, 10.1.0.2}
       *BGP    Preference: 170/-101
               Next hop type: Router, Next hop index: 262145
               Address: 0x9404010
               Next-hop reference count: 8
               Source: 10.1.0.2
               Next hop: 10.2.0.2 via ge-0/0/0.20 balance 80%
               Next hop: 10.1.0.2 via ge-0/0/0.10 balance 20%, selected
               State: <Active Ext>
               Local AS:  1111 Peer AS:  2222
               Age: 1:20:49 
               Task: BGP_2222.10.1.0.2+179
               Announcement bits (1): 0-KRT 
               AS path: 2222 I
               Communities: bandwidth:2222:2500000
               Accepted Multipath
               Localpref: 100
               Router ID: 2.2.2.2

Modifying AS Path

Option 1: remove-private

Option 2: local-as

[edit routing-options]
R1# show 
autonomous-system 1111;

[edit protocols bgp group ebgp]
R1# show 
neighbor 10.1.0.2 {
    peer-as 2222;
    local-as 3333;
}

При такой конфигурации R1, EBGP-сосед, который ожидает, что у R1 будет AS3333 сможет установить соседство с R1, хотя, по факту R1 принадлежит AS1111. Результат: 

R1> show bgp neighbor 
Peer: 10.1.0.2+179 AS 2222     Local: 10.1.0.1+62745 AS 3333 
  Type: External    State: Established    Flags: <Sync>
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  ...
  Holdtime: 90 Preference: 170 Localpref: 110 Local AS: 3333 Local System AS: 1111
  Number of flaps: 0
  Peer ID: 2.2.2.2         Local ID: 1.1.1.1           Active Holdtime: 90
  ...

Зачем это нужно

Предположим, оператор с AS1111 купил сеть оператора с AS3333. У AS3333 были свои клиенты, подключенные по BGP, которые не готовы или не хотят изменять конфигурацию на своих роутерах. В таком случае можно временно применить опцию local-as, чтобы выступить для них от лица предыдущей AS (в примере - 3333), но внутри сети перевести инфораструктуру на AS1111.

Если добавить ключевое слово private: 

[edit protocols bgp group ebgp]
R1# show 
neighbor 10.1.0.2 {
    peer-as 2222;
    local-as 3333 private;
}

То R1 вообще не будет добавлять AS3333 при анонсе маршрутов, получаемых от 10.1.0.2 своим соседям.


Route Reflection

Описан в RFC 4456

Концепция

  • Позволяет iBGP-спикеру анонсировать другим iBGP-маршрутизаторам маршруты, полученные через iBGP
  • RR только пересылает активные маршруты клиентам (это соседи RR, которые не являются RR. Для настройки таких роутеров не требуется изменений в конфигурации соседства.)
  • RR по умолчанию не меняет IBGP атрибуты.
  • Для предотвращения петель существуют два новых атрибута:
  • Cluster List (1 или более cluster ID)
  • Originator ID - ID роутера, который первым переслал маршрут в AS.

Cluster List

Список, включающий ID всех RR, которые обрабатывали данный префикс. Если RR получит маршрут, у которого в cluster list будет ID этого RR, то он его дропнет. Участвует при выборе активного маршрута (активным становится с наименьшим cluster list). Cluster ID добавляется к cluster list, когда маршрут отправляется. Cluster ID должен быть уникальным в рамках AS.

Configuration

Если на сет несколько RR, то соседство между ними может быть как в отдельной группе от RR-clients (IBGP), так и в той же группе что и клиенты. Между RR - full-mesh. 

set protocols bgp group RR type internal
set protocols bgp group RR peer-as 65513
set protocols bgp group RR neighbor 2.2.2.2
set protocols bgp group RR neighbor 3.3.3.3

RR-clients конфигурируются в отдельной группе, где должен быть включен: "cluster x.x.x.x" 

set protocols bgp group RR-clients cluster 1.1.1.1

Со стороны клиентов конфигурация стандартная для IBGP - простое соседство с RR.

Распространение маршрутов при использовании RR.

  1. Клиент -> cluster RR
  2. RR -> all clients and non-clients(other RR)
  3. Other RR -> all cluster clients.

При этом: non-clients -> RR -> clients (only)

При использовании нескольких RR, можно для на всех использовать одинаковый cluster ID. +: в таблице будет меньше маршрутов и при такой схеме можно добиться хорошей отказоустойчивости в сети.

2 RR в кластере

Соседство между RR можно устанавливать как внутри отдельной группы для кластера, так и в отдельной группе. В обоих случаях при передаче маршрутов между RR петель не будет, т.к. cluster ID будет одинаковыми. Каждый из RR в кластере устанавливает IBGP с другими RR, не входящих в кластер. В подобных схемах все-таки тоже стараются использовать уникальные cluster ID.

Hierarchical Route Reflection

Отличие от предыдущих: в схеме появляются не только RR и client, но еще и роутеры, выполняющие обе функции в рамках разных кластеров. Clients могут устанавливать IBPG между собой. Это удобно использовать, чтобы clients могли использовать маршруты от других clients нативно, без обработки RR. Чтобы RR не флудил копиями маршрутов, на нем можно включить no-client-reflect, это отключит пересылку маршрутов, полученных внутри кластера. Внешние маршруты при этом продолжают пересылаться.

Modifying Attributes on the RR

Все атрибуты BGP изменяются через policy. Если на RR есть EBGP, то с большой вероятностью будет активна ф-ия: next-hop-self. При этом, у маршрутов, полученных от client, также next-hop будет меняться. Что приведет к не оптимальному форвардингу трафика (должен идти напрямую к original роутеру, а будет идти через RR). Чтобы менять next-hope только у external: в policy матчим по interface ли neighbor. 

set policy-option policy-statement nhs term EBGP from protocol bgp
set policy-option policy-statement nhs term EBGP from neighbor 2.2.2.2
set policy-option policy-statement nhs term EBGP the next-hop self

Confederations

Описан в RFC 3065

Принципы

Цель: разбить global AS на sub-AS.

Внутри sub-AS между роутерами: full-mesh. Если внутри sub-AS будет слишком большая сеть, то в нее можно внедрить RR.

sub-AS должна иметь уникальный номер (зачастую берут приватные AS).

Между sub-AS - EBGP = confederation BGP = CBGP.

При прохождении маршрута через CBGP линк, роутер меняет AS path, включая sub-AS. Другие атрибуты BGP не меняются.

Также в отличие от стандартного EBGP, в CBGP обычно соседство строится на loopback.

AS-path segment

  • AS Confederation Sequence

При прохождение через CBGP линк, роутер добавляет sub-AS к AS-path в "()" в последовательности, как шел маршрут по сети.

AS Confederation Sequence не используется при выборе активного пути.

Этот атрибут имеет type code 3. 

AS-path: (65000 65001 65002) 100 200
  • AS Confederation Set

При агрегировании маршрутов внутри конфедерации, AS confederation sequence становится AS confederation set.

Этот атрибут имеет type code 4. 

10.10.10.0/24 (65000 65001) 100 
10.10.20.0/24 (65000 65002) 100
10.10.0.0/16 ({65000 65001 65002}) 100

Оба атрибута используются только для предотвращения петель внутри конфедерации.

При анонсировании маршрутов из конфедерации дальше по сети по EBGP, private AS (sub-AS) стираются, поэтому все конфедерации извне видны как одна большая глобальная AS. При этом не требуется отдельно включать (remove-private). В случае с конфедерациями, все приватные AS итак сотрутся итак.

Но все роутеры внутри конфедерации обязательно должны знать номер глобальной AS.

Configuration

Включение самой конфедерации на роутере - определяется в routing-options: 

set routing-options autonomus-system 65000
set routing-options confederation 100 members [65000 65001 65002]

R1 

внутри конфедерации: 
set protocols bgp group sub-AS-65001 type internal
set protocols bgp group sub-AS-65001 local-address 192.168.1.3
set protocols bgp group sub-AS-65001 neighbor 192.168.1.1
set protocols bgp group sub-AS-65001 neighbor 192.168.1.2
set protocols bgp group sub-AS-65001 neighbor 192.168.1.4

CBGP-link 1:
set protocols bgp group sub-AS-65000 type external
set protocols bgp group sub-AS-65000 multihop
set protocols bgp group sub-AS-65000 local-address 192.168.1.3
set protocols bgp group sub-AS-65000 peer-as 65000
set protocols bgp group sub-AS-65000 neighbor 192.168.0.3

CBGP-link 2: 

set protocols bgp group sub-AS-65002 type external 
set protocols bgp group sub-AS-65002 multihop
set protocols bgp group sub-AS-65002 local-address 192.168.1.3
set protocols bgp group sub-AS-65002 peer-as 65002
set protocols bgp group sub-AS-65002 neighbor 192.168.2.4
Источник — https://juniper-exam.ru/index.php?title=BGP&oldid=136