Juniper Exam Wiki - Вклад [ru]

OSPF

2017-01-04T15:27:45Z

Владислав Павкин: /* Типы Area */

==Типы пакетов==
'''Hello''' - используются для установления и поддержания соседства ospf.
Отправляются на адрес 224.0.0.5 каждые 10 сек. Содержит в себе поля: network mask, hello interval, dead interval, options, (router priority, designated router, backup designated router, neighbor).

'''Description database (DD)''' - используется только во время установления соседства. Определяет кто отвечает за синхронизацию (выбирается с большим RID). Обменивается LSA до полной синхронизации. Содержит: ospf header, sequence number, lsa header.

'''Link-state request''' - отправляется роутером, когда тот понимает, что LSBD устарела. Содержит: ospf header, link-state type, link-state ID, advertising router.

'''Link-state update''' - отправляется на адрес: 224.0.0.5 (всем) или 225.0.0.6 (для DR). Отправляется либо в ответ на link-state request, либо если меняется информация о состоянии линка. Содержит: ospf header, numbers of advertisement, link-state avertisement.

'''Link-state acknowledgment''' - ответ на link-state update. Содержит: ospf header, list of LSA headers.

==Установление соседства==
== Стадии установления соседства (OSPF Adjacency): ==

'''1. Down'''

Самое начало, ничего не происходит.

'''2. Init'''

В hello-packet в списке соседей нет router-id маршрутизатора, получившего этот пакет.

Если маршрутизатор не переходит в состояние 2-Way, а скачет - down-Init-down-init...
вероятно на маршрутизаторах не совпали параметры:
Area ID
Authentication
Network Mask
Hello Interva
Router Dead Interval
Options fields

либо до удаленного маршрутизатора не доходят ваши сообщения hello
(причиной могут быть неверно настроенные фаерволы)

'''3. 2-Way'''

В hello-packet в списке соседей появился router-id маршрутизатора, получившего этот пакет.

'''4. ExStart'''

Выборы DR и BDR маршрутизаторов производятся в момент первоначальной установки соседских отношений по следующим правилам:

* Маршрутизатор с наибольшим приоритетом выбирается DR маршрутизатором;
* Маршрутизатор со вторым по величине приоритетом назначается BDR маршрутизатором;
* Если маршрутизаторы имеют равный приоритет, то в качестве DR маршрутизатора выбирается маршрутизатор с наибольшим RID, BDR маршрутизатором выбирается маршрутизатор со вторым по величине RID;
* Маршрутизатор, с приоритетом равным нулю, не принимает участия в выборах DR и BDR маршрутизаторов;
* Если после выбора DR и BDR маршрутизаторов в сегмент сети добавляется маршрутизатор с более высоким приоритетом или большим RID, то повторные выборы не производятся;
* Повторные выборы производятся только после того как DR или BDR маршрутизаторы становится недоступными.

(Происходит обмен сообщениями DD (database descr), где заполнены только поля: router-id, neighbors, mtu.

Если маршрутизатор не переходит в следующее состояние, то вероятнее всего
причина в несовпадении mtu на физических интерфейсах маршрутизаторов.

'''5. ExChange'''

Процесс обмена LSDB с помощью сообщений DD (database descr)
(локальной базой маршрутов, их метриками, состояний линков)

'''6. Loading'''

Обмен сообщениями link-state request, link-state update. На каждом маршрутизаторе должна быть одинаковая LSDB.
(Каждый маршрутизатор восполняет недостающие знания о новых маршрутах)

'''7. Full'''

Соседство установлено, LSDB синхронизированы.
Последующие изменения в топологии передаются через сообщения link-state update,
в ответ приходят link-state acknowledgment (в кач-ве подтверждения о доставке).

==Типы Area==

===backbone===

Area 0 (к ней в обязательном порядке должны подключаться остальные area).

===stub area===

Обменивается маршрутами по ospf с ABR, не содержит с себе external routes, не принимает от ABR external routes. (не принимает LSA 4,5). Доступность внешних маршрутов достигается анонсированием 0/0 со стороны ABS в сторону stub-area.

[edit protocols ospf area 0.0.0.1]
vlad@mortlach# set stub

===stub with no summaries===

В неё не анонсируется вообще никаких LSA. Доступность маршрутов из остальных area достигается тем же анонсированием 0/0 со стороны ABS в сторону totally stub-area.

[edit protocols ospf area 0.0.0.1]
vlad@mortlach# set stub no-summaries

===not-so-stubby===

Обменивается маршрутами по ospf с ABR, содержит external routes, НО не принимает external routes от ABR. (не принимает LSA 4,5)

[edit protocols ospf area 0.0.0.1]
vlad@mortlach# set nssa

==Типы LSA==
'''Type 1 LSA (Router)''' — Описывают сам маршрутизатор и его интерфейсы. Не передаются между Area.

'''Type 2 LSA (Network)''' — Описывают сети, подключенные к маршрутизатору. Не передаются между Area.

'''Type 3 LSA (Summary)''' — Описывают сети, которые маршрутизатор получил из предыдущих типов LSA, но передаются между Area.

'''Type 4 LSA (ASBR Summary)''' — Генерируются маршрутизаторами (ASBR), в которые попадают маршруты из других протоколов, чтобы описать себя.

'''Type 5 LSA (External)''' — Описывают сети, полученные из других протоколов маршрутизации ASBR-ами. Рассылаются ими же.

'''Type 6 LSA''' — Не используется, некогда планировался под MOSPF.

'''Type 7 LSA (NSSA External)''' — Генерируются ASBR-ами в NSSA, на выходе из зоны транслируются ABR-ами в LSA Type 5.

'''Type 10 LSA (Traffic Engineering)''' — Содержат информацию, которая в последствии находится в TED и используется при работе CSPF-алгоритма.

==Типы интерфейсов==
*'''Broadcast''' - поведение аналогично тому, когда router включен в LAN сегмент. То ест дополнительно производится выбор DR, BDR среди роутеров. И если на интерфейсе висите несколько ip, то роутер сможет установить несколько соседств в каждой сети одновременно.
*'''Point to point (p2p)''' - соединение между одним source и одним destination. Возможно установление только '''одного''' соседства с такого типа интерфейса. Можно назначать на ethernet интерфейсы без IP адресов.
*'''Point to multipoint (p2mp)''' - соединение между одним source и несколькими destination. Сеть рассматривается как набор p2p линков. Т.к. нет autodiscovery механизма, от обязательно указывать соседа.
*'''Nonebroadcast multiaccess (NBMA)''' - работает как p2mp, но может взаимодействовать с другим оборудованием.
*'''Demand circuit''' - соединение на котором можно ограничить полосу или время доступа.
*'''Passive''' - передает свой адрес, но не участвует в установлении OSPF соседства и вообще не обменивается hello-сообщениями. Также в passive можно использовать инфо об интерейсе и его сетях для TE вычислений.
*'''Disable''' - не участвует в OSPF и не передает о себе инфо в LSDB
*'''Peer (для OSPFv2)''' - требуется GMPLS

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

==Другие фичи==
*Аутентификация: простая, MD5, IPSec.
*Суммирование маршрутов, прилетающих в update сообщениях от других area.
*Можно ограничить кол-во перфиксов, экспортируемых в OSPF.
*GRES возможен.
*BFD (Bidirectional Forwarding Detection) можно использовать для сокращения времени обнаружения аварии между роутерами.

BGP

2016-11-06T18:55:16Z

Владислав Павкин: /* Операторы регулярных выражений */

== Состояния соседства ==
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 категории:
# '''Well-known mandatory''' — все маршрутизаторы, работающие по протоколу BGP, должны распознавать эти атрибуты. Должны присутствовать во всех обновлениях (update).
# '''Well-known discretionary''' — все маршрутизаторы, работающие по протоколу BGP, должны распознавать эти атрибуты. Могут присутствовать в обновлениях (update), но их присутствие не обязательно.
# '''Optional transitive''' — могут не распознаваться всеми реализациями BGP. Если маршрутизатор не распознал атрибут, он помечает обновление как частичное (partial) и отправляет его дальше соседям, сохраняя не распознанный атрибут.
# '''Optional non-transitive''' — могут не распознаваться всеми реализациями BGP. Если маршрутизатор не распознал атрибут, то атрибут игнорируется и при передаче соседям отбрасывается.

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

Используется для:
* обнаружения петель
* влияние на path selection с помощью prepending (делается через export policy)

'''Обозначение:'''
* [] - local AS
* {} - AS sets - группы AS, порядок не имеет значение. Возникает при агрегировании маршрутов.
* () - confederation
* ([]) - confederation sets

Каждый сегмент атрибута 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 байта.

====Операторы регулярных выражений====
{{re|title=Список регулярных выражений для AS Path}}

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

====Next-hop resolution====
* '''Next-hop self'''
* '''Export direct into IGP:''' проанонсировать p2p сеть с EBGP peer, который прислал префикс.
* '''IGP passive interface:''' интерфейс в сторону EBGP соседа.
* '''Static routes:''' тут возникает проблема с тем, что придется на всех IBGP роутерах прописывать этот маршрут. Лучше выбрать другой способ.
* '''IGP adjacency on inter-AS links to EBGP peers:''' тоже плохой вариант. Опсано и зачем тогде вообще разные AS. Лучше выбрать другой способ.

Можно изменить с помощью policy на выходе (в сторону своей AS):
[edit policy-options policy-statement nexthop-self]
R1# show
term localpref {
then {
next-hop self;
}
}

Или же на входе (в сторону EBGP peer):
[edit policy-options policy-statement nexthop-peer]
R2# show
term localpref {
then {
next-hop peer-address;
}
}

=== Origin ===
'''✔️Well-known Mandatory'''
Атрибут '''Origin''' — указывает на то, каким образом был получен маршрут в обновлении.
{| class="wikitable"
|+Возможные значения атрибута
|-
|'''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.
* Обычно используется на бордерах.
{{note|text=Когда в сети есть 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-соседям, но анонсируются внешним соседям в конфедерации.

'''Пример использования'''
{{note|text=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'''.}}

{{note|text= 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.
{{note|text=Маршрутизаторы, которые не поддерживают атрибут 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====
{{re|title=Список операторов регулярных выражений для Community}}

=== Multi exit discriminator (MED)===
====В общем====
Атрибут '''MED''':
* Используется для информирования eBGP-соседей о том, какой путь в автономную систему более предпочтительный.
* Атрибут передается между автономными системами.
* Маршрутизаторы внутри соседней автономной системы используют этот атрибут, но, как только обновление выходит за пределы AS, атрибут MED отбрасывается.
* Чем меньше значение атрибута, тем более предпочтительна точка входа в автономную систему.
* Исходя из названия - используется только в тех случаях, когда между AS есть несколько линков.

Сравнение MED (при прочих равных) происходит если один и тот же префикс приходит от одной AS.

Если будет анонс этого префикса с более низким MED, но из другой AS, то он не будет рассматриваться как вероятный вариант для использования.

Это дефолтное поведение, которое можно изменить с помощью:
*''always-compare-med'': при этом не будет иметь значение разные AS или одна, просто активным станет маршрут с самым низким MED.
*''cisco-non-determenistic'': выбор основан на том, когда маршрут пришел. Juniper не рекомендует использовать.

====Возможные операции с MED====
Внутри policy ''metric'' - это обозначение MED атрибута.

Можно использовать как в ''from'', так и в ''then''. ''Then'': назначение метки - ''metric 50'', добавить к существующей метки - ''metric add 50'', вычесть из ''metric subtract 50''.

MED можно назначить внутри ''protocols bgp'':

[edit protocols bgp group AS-100]
type external
local-as 200
neighbor 1.1.1.1 metric-out 50 <= определенное значение
neighbor 2.2.2.2 metric-out igp <= текущаф IGP метрика
neighbor 3.3.3.3 metric-out minimum-igp <= миимальная IGP мтерика, когда-либо изученная
neighbor 4.4.4.4 metric-out igp 5 <= добавит или вычесть из IGP метрики

MED также можно назначить аналогичным образом через policy:

[edit policy-optinos policy-sttement new-metric]
term IGP
then metric igp ''offset''
term minimum-igp
then metric minimum-igp ''offset''

При использовании ''metric igp'' на префикс вешается MED, равный IGP метрики до роутера, который прислал этот префикс. При изменениях IGP metric, будет меняться и MED.

При использовании ''metric minimum-igp'' MED не будет меняться при изменениях IGP метрики.

При агрегировании маршрутов - MED становится = 0.

Если между роутерами передаются агрегированный маршрут и вложенный в него в MED, то вложенный будет передан с MED, а агрегированный - с MED = 0.

Это дефолтное поведение и альтернатив этому нет.

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

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

== Механизмы управления трафиком ==
===Входящим===
*AS path prepend
*Community (если поддерживает провайдер)
*MED (подключение к одной и той же AS)
*Анонс разных префиксов через разных ISP

===Исходящим===
*Проприетарный атрибут Cisco weight (локально на маршрутизаторе)
*Атрибут Local Preference (локально в AS)
*Балансировка трафика {{чо?}}

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

* Juniper
# Prefer highest local preference value
# Prefer shortest AS-path length
# Prefer lowest Origin value
# Prefer lowest MED value
# Prefer routes learned from an EBGP peer over an IBGP peer
# If the remaining routes were learned through IBGP, use the path with the lowest IGP cost to the IBGP peer.
# For EBGP received routes, prefer the current active route; otherwise, prefer routes from the peer with the lowest RID
# Prefer paths with the shortest cluster length
# 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.'''
# Клиент -> cluster RR
# RR -> all clients and non-clients(other RR)
# 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

Глава 2. Label Distribution Protocols (RSVP, LDP)

2016-11-02T14:41:39Z

Владислав Павкин: /* LDP runneling */

==RSVP==
'''RSVP''' - ''resource reservation protocol'' - требует больше конфигурации для работы, чем LPD, но зато имеет более полезных фич, таких как: TE, fast-failover, QoS, bandwidth reservation, LSP customization.

LSP установлена и имеет свой ''record route'': список IP адресов интерфейсов, через которых проходит RSVP LSP, включая ingress и egress.

Второй preference у RSVP: Когда внутри протокола требуется сравнение маршрутов. RSVP auto mesh - ''preference 2'' = 3. Если на сети будет построен RSVP туннель статический и auto-mesh, то предпочтительней будет статический. (preference 2: 1 < 3).
{{note| text=В LDP нет требования добавлять интерфейсы в protocols mpls, но family mpls включать нужно.}}
===Configuration===
1. Включаем family mpls на интерфейсах, смотрящих в ядро. Эта настройка позволяет отправлять и получать пакеты с метками.
[edit interfaces]
set ge-0/0/2.0 family mpls
set ge-0/0/3.0 family mpls

2. Настраиваем LSP. И добавляем нужные интерфейсы в protocols mpls. Это позволяет запустить на указанных интерфейсах mpls и появиться в TED, как возможный ресурс для использования.

[edit protocols mpls]
set label-switched-path R1-to-R5 {
to 10.200.86.3;
}
interface ge-0/0/2.0;
interface ge-0/0/3.0;

3. Добавляем в протокол RSVP нужные интерфейсы.
[edit protocols rsvp]
set interface ge-0/0/2.0
set interface ge-0/0/3.0

4. На остальных роутерах требуется включить family mpls и добавить интерфейсы в protocols rsvp.

==LDP==
'''LDP''' - ''label distribution protocol'' - намного более простой в настройке, но малофункциональный сигнальный протокол, по сравнению с RSVP.

===Соседство===
При включении LDP на роутере, он пытается установить соседство. Mulicast на '''UDP 646''' шлют hello пакеты (раз в 5 сек, dead interval = 15 сек). Другой роутер слушает hello на этом же порту, отвечает hello, т.о. устанавливается соседство.

После этого устанавливается TCP сессия. По этой сессии начинается обмен метками и пакетами по unicast.

Инициатором построения туннелей выступает egress роутер.

Роутер (A) анонсирует свой Lo соседнему роутеру (В). Этот анонс попадает в inet.3. Т.к. B - прямой сосед А, и между ними однохоповый туннель, то анонс от А придет с меткой 3.

Роутер B начинает анонсировать Lo роутера А остальным своим соседям (C,D), чтобы те начали строить туннели до роутера А. На роутерах C,D анонс от B поместится в inet.3, с ''push'' метка. А на роутере B в таблице mpls.0 - появляется запись для туннеля с ''swap''.

В итоге - full mesh на сети. На всех роутерах в inet.3 будет Lo роутера А.
{{note|text=Установление LDP LSP нельзя контролировать, они следуют кратчайшему пути по IGP.}}

'''Для исключения петель: '''

* На каждом роутере для каждого соседа создается 2 LDP database: на вход и на выход. LDP database, поступившая на вход, сравнивается с топологией IGP. В inet.3 попадает тот анонс, который пришел с того же next-hop, что указан для пришедшего Lo.
* То, что пришло и не совпало с IGP - сохраняется, но не используется. ''Liberal protection''.

'''Без настроенного link-state IGP (OSPF или ISIS) LDP работать не будет!''' Скорость перестроения - зависит от перестроения по IGP.

===Cisco===
В Cisco дефолтное поведение немного другое. Анонсируются не только Lo, а полностью таблица маршрутизации и сразу вставляется в GRT (global routing table).

Чтобы на Juniper получить такое же поведение:
# Пишем egress-policy: где указано что требуется анонсировать из таблицы маршрутизации по протоколу LDP. Policy применяется как egress policy к протоколу LDP.
# На всех остальных роутерах требуется перенести inet.3 в inet.0.

Это может понадобиться только в случае, если мы делаем редистрибьюцию внешних префиксов во внутренний протокол. '''- чего провайдер делать не должен.'''

===Configuration===

1. Включаем family mpls:
[edit interfaces]
set ge-0/0/2.0 family mpls
set ge-0/0/3.0 family mpls

2. Добавляем интерфейсы в protocols ldp
[edit protocols ldp]
set interface ge-0/0/2.0
set interface ge-0/0/3.0

3. На остальных роутерах в mpls домене делаем все тоже самое.

Можно проверить что будет происходить с меткой на каждом хопе LDP LSP:
show route protocol ldp 10.200.86.7
show ldp router
show route table inet.3 - если нет Lo нужного нам роутера, то проверяем есть ли Lo в inet.0 (IGP)

'''Обычно не стоит вопрос о том какой протокол использовать. Оба протокола друг друга просто дополняют.''' У двух протоколов разные preference, поэтому BGP будет выбирать RSVP, как более приоритетный.

==LDP tunneling==
Комбинация LDP и RSVP. Core - RSVP + TE, доступ - LDP.

* Роутер A - LDP. начинает анонсировать себя. B - '''inet.3''': LoA, pop.
* Роутер B - LDP + RSVP. анонс LoA с меткой 100. B: '''mpls.0''': LoA 100 pop -> A
* Роутер C - RSVP (с LDP-tunneling). Анонс LoA с меткой 150, UDP 646 на LoA (''берется из конфигурации туннеля''), соседство по LDP A<>C (''не hello механизм, но тоже работает’’). С: '''mpls.0''': LoA 150 swap 100 -> B.
* Роутер E - LDP + RSVP. Анонс LoA с меткой 200. E: '''mpls.0''': LoA 200 swap 150 -> C. Но C не direct connected. C доступен чере туннель => идем смотреть в inet.3. E: '''inet.3''': LoC push 1000 -> D. => E; '''mpls.0''': LoA 200 swap 150 push 1000
* Роутер F - LDP. Ingress: '''inet.3''': LoA push 200 -> E.

В обратную сторону строится точно также.
Обязательно на core роутерах (C) включить в LDP LoC, чтобы поднялся туннель C - A.
Схема работает только в пределах области.
При включенном LDP tunneling будут видны скрытые маршруты в inet.3

Глава 2. Label Distribution Protocols (RSVP, LDP)

2016-11-02T14:41:26Z

Владислав Павкин: /* Configuration */

==RSVP==
'''RSVP''' - ''resource reservation protocol'' - требует больше конфигурации для работы, чем LPD, но зато имеет более полезных фич, таких как: TE, fast-failover, QoS, bandwidth reservation, LSP customization.

LSP установлена и имеет свой ''record route'': список IP адресов интерфейсов, через которых проходит RSVP LSP, включая ingress и egress.

Второй preference у RSVP: Когда внутри протокола требуется сравнение маршрутов. RSVP auto mesh - ''preference 2'' = 3. Если на сети будет построен RSVP туннель статический и auto-mesh, то предпочтительней будет статический. (preference 2: 1 < 3).
{{note| text=В LDP нет требования добавлять интерфейсы в protocols mpls, но family mpls включать нужно.}}
===Configuration===
1. Включаем family mpls на интерфейсах, смотрящих в ядро. Эта настройка позволяет отправлять и получать пакеты с метками.
[edit interfaces]
set ge-0/0/2.0 family mpls
set ge-0/0/3.0 family mpls

2. Настраиваем LSP. И добавляем нужные интерфейсы в protocols mpls. Это позволяет запустить на указанных интерфейсах mpls и появиться в TED, как возможный ресурс для использования.

[edit protocols mpls]
set label-switched-path R1-to-R5 {
to 10.200.86.3;
}
interface ge-0/0/2.0;
interface ge-0/0/3.0;

3. Добавляем в протокол RSVP нужные интерфейсы.
[edit protocols rsvp]
set interface ge-0/0/2.0
set interface ge-0/0/3.0

4. На остальных роутерах требуется включить family mpls и добавить интерфейсы в protocols rsvp.

==LDP==
'''LDP''' - ''label distribution protocol'' - намного более простой в настройке, но малофункциональный сигнальный протокол, по сравнению с RSVP.

===Соседство===
При включении LDP на роутере, он пытается установить соседство. Mulicast на '''UDP 646''' шлют hello пакеты (раз в 5 сек, dead interval = 15 сек). Другой роутер слушает hello на этом же порту, отвечает hello, т.о. устанавливается соседство.

После этого устанавливается TCP сессия. По этой сессии начинается обмен метками и пакетами по unicast.

Инициатором построения туннелей выступает egress роутер.

Роутер (A) анонсирует свой Lo соседнему роутеру (В). Этот анонс попадает в inet.3. Т.к. B - прямой сосед А, и между ними однохоповый туннель, то анонс от А придет с меткой 3.

Роутер B начинает анонсировать Lo роутера А остальным своим соседям (C,D), чтобы те начали строить туннели до роутера А. На роутерах C,D анонс от B поместится в inet.3, с ''push'' метка. А на роутере B в таблице mpls.0 - появляется запись для туннеля с ''swap''.

В итоге - full mesh на сети. На всех роутерах в inet.3 будет Lo роутера А.
{{note|text=Установление LDP LSP нельзя контролировать, они следуют кратчайшему пути по IGP.}}

'''Для исключения петель: '''

* На каждом роутере для каждого соседа создается 2 LDP database: на вход и на выход. LDP database, поступившая на вход, сравнивается с топологией IGP. В inet.3 попадает тот анонс, который пришел с того же next-hop, что указан для пришедшего Lo.
* То, что пришло и не совпало с IGP - сохраняется, но не используется. ''Liberal protection''.

'''Без настроенного link-state IGP (OSPF или ISIS) LDP работать не будет!''' Скорость перестроения - зависит от перестроения по IGP.

===Cisco===
В Cisco дефолтное поведение немного другое. Анонсируются не только Lo, а полностью таблица маршрутизации и сразу вставляется в GRT (global routing table).

Чтобы на Juniper получить такое же поведение:
# Пишем egress-policy: где указано что требуется анонсировать из таблицы маршрутизации по протоколу LDP. Policy применяется как egress policy к протоколу LDP.
# На всех остальных роутерах требуется перенести inet.3 в inet.0.

Это может понадобиться только в случае, если мы делаем редистрибьюцию внешних префиксов во внутренний протокол. '''- чего провайдер делать не должен.'''

===Configuration===

1. Включаем family mpls:
[edit interfaces]
set ge-0/0/2.0 family mpls
set ge-0/0/3.0 family mpls

2. Добавляем интерфейсы в protocols ldp
[edit protocols ldp]
set interface ge-0/0/2.0
set interface ge-0/0/3.0

3. На остальных роутерах в mpls домене делаем все тоже самое.

Можно проверить что будет происходить с меткой на каждом хопе LDP LSP:
show route protocol ldp 10.200.86.7
show ldp router
show route table inet.3 - если нет Lo нужного нам роутера, то проверяем есть ли Lo в inet.0 (IGP)

'''Обычно не стоит вопрос о том какой протокол использовать. Оба протокола друг друга просто дополняют.''' У двух протоколов разные preference, поэтому BGP будет выбирать RSVP, как более приоритетный.

==LDP runneling==
Комбинация LDP и RSVP. Core - RSVP + TE, доступ - LDP.

* Роутер A - LDP. начинает анонсировать себя. B - '''inet.3''': LoA, pop.
* Роутер B - LDP + RSVP. анонс LoA с меткой 100. B: '''mpls.0''': LoA 100 pop -> A
* Роутер C - RSVP (с LDP-tunneling). Анонс LoA с меткой 150, UDP 646 на LoA (''берется из конфигурации туннеля''), соседство по LDP A<>C (''не hello механизм, но тоже работает’’). С: '''mpls.0''': LoA 150 swap 100 -> B.
* Роутер E - LDP + RSVP. Анонс LoA с меткой 200. E: '''mpls.0''': LoA 200 swap 150 -> C. Но C не direct connected. C доступен чере туннель => идем смотреть в inet.3. E: '''inet.3''': LoC push 1000 -> D. => E; '''mpls.0''': LoA 200 swap 150 push 1000
* Роутер F - LDP. Ingress: '''inet.3''': LoA push 200 -> E.

В обратную сторону строится точно также.
Обязательно на core роутерах (C) включить в LDP LoC, чтобы поднялся туннель C - A.
Схема работает только в пределах области.
При включенном LDP tunneling будут видны скрытые маршруты в inet.3

Глава 1. Основы MPLS и VPN

2016-11-02T13:38:21Z

Владислав Павкин: /* inet.3 */

===Причины появления и плюсы использования MPLS===
* Уменьшилось время route lookup, за счет использования меток для передачи трафика.
* Улучшилась масштабируемость сети.
* Использование traffic engineering (TE) дает дополнительную возможность управлять трафиком.
* На одном и том же оборудовании можно обеспечить работу разных технологий: Ethernet, ATM, Frame Relay, IPSec.

===Метки, LSP===
LSP - однонаправленные.

Для LSP требуется, чтобы MPLS был включен на каждом роутере, через который проходит LSP.
MPLS позволяет роутеру завести локальную DB, в которой будут метки с назначением и другими метками, обмен метками с соседними роутерами и отправка и получение пакетов, отмеченных метками.

LSP обеспечивает маршрут через сеть для пакета с меткой. В отличие от маршрутизации по dest IP, пакет с меткой маршрутизируется по сети основываясь на значении метки.

'''Заголовок MPLS''' - 32 bit (8bytes). Добавляется сразу после L2 заголовка.

Заголовок содержит: метку, CoS, Stack bit, TTL.

Метки MPLS уникальны в рамках роутера. На каждом роутере в MPLS домене, через который проходит LSP, метка обязательно будет меняться.

* 0 - Explicit null (IPv4)
* 1 - Router alter label (IP router alert)
* 2 - Explicit null (IPv6)
* 3 - Implicit null
* 4-15 - for future use

Таблица '''mps.0''' - для хранения информации о метках. Для транзитных роутеров, для принятия решений - куда передавать трафик. При включении MPLS, в ней сразу появляется информаци о 0,1,2 метках.

===Терминология===
'''LSP''' labe switched path - однонаправленный поток трафика.

'''LSR''' label switching router = роутер, использующий MPLS, который участвует в построении LSP.

Бывает нескольких типов:
* '''Ingress'''
:- Пакеты входят в LSP на ingress роутере
:- Делает push метки
:- Для отдельной LSP может быть только 1 ingress роутер
:- Upstream для остальных роутеров в рамках LSP
* '''Transit'''
:- Для LSP может быть 0 или более transit роутеров
:- Делает swap метки
:- Передает трафик следующему хопу LSP
* '''Penultimate'''
:- Предпоследний для LSP роутер
:- По дефолту делает pop метки и пакет без метки отправляет последнему egress роутеру.
* '''Egress'''
:- Пакеты выходят из LSP на egress роутере
:- Передает пакет дальше, основываясь на IP
:- Downstream для других роутеров в рамках LSP

===PHP, UHP===

'''PHP''' - ''penultimate hop popping'' - снятие метки на предпоследнем роутере. В таком случае egress роутер будет освобожден от этой функции и будет делает стандартный lookup по адресу назначения в таблице inet.0. Для реализации этой процедуры egress при установлении LSP отправляет предпоследнему роутеру метку 3.

'''UHP''' - ''ultimate hop popping'' - предпоследний роутер передает последнему пакет с меткой. Метка снимается на последнем роутере. Такое поведение требуется, например, для корректной работы CoS. Для реализации такого поведения нужно включить:

set protocols mpls explicit-null

При этом egress роутер при создании LPS будет отправлять предпоследнему роутеру метку 0.

===inet.3===
Маршруты вставляются в таблицу inet.3, в которую залезает BGP, перед тем как отрезолвить next-hop для префикса. Если удалось найти next-hop в inet.3, то BGP вставляет LSP в inet.0 в качестве физического next-hop. Если не удалось, то BGP идет в inet.0 и пытается отрезолвить там.

Если мы резолвим next-hop для Lo интерфейса удаленного маршрутизатора, что в inet.0 он будет виден как доступный через IGP протокол и трафик будет передаваться в соответствие с IGP, то есть в p2p интерфейс с соседним маршрутизатором.

Если же мы будем резолвить next-hop для префикса, находящегося за пределами IGP домена (клиентский), который будет известен по BGP (а такое будет обязательно, т.к. обычно для распространения подобных маршрутов используется next-hop self, подставляется Lo удалённого маршрутизатора), то BGP залезет в inet.3, увидит в качестве next-hop LSP до Lo удалённого маршрутизатора и подставит эту запись в inet.0!! Вот и вся магия.

То есть вся разница в том, что транзитный трафик, через роутер, участвующий в LSP, будет идти через LSP. А трафик направленный к самому роутеру (Lo интерфейсу), будут опираться на IGP.

inet.3 строится только на ingress роутерах. На транзитных - только mpls.0.

Глава 1. Основы MPLS и VPN

2016-11-02T13:38:07Z

Владислав Павкин: /* inet.3 */

===Причины появления и плюсы использования MPLS===
* Уменьшилось время route lookup, за счет использования меток для передачи трафика.
* Улучшилась масштабируемость сети.
* Использование traffic engineering (TE) дает дополнительную возможность управлять трафиком.
* На одном и том же оборудовании можно обеспечить работу разных технологий: Ethernet, ATM, Frame Relay, IPSec.

===Метки, LSP===
LSP - однонаправленные.

Для LSP требуется, чтобы MPLS был включен на каждом роутере, через который проходит LSP.
MPLS позволяет роутеру завести локальную DB, в которой будут метки с назначением и другими метками, обмен метками с соседними роутерами и отправка и получение пакетов, отмеченных метками.

LSP обеспечивает маршрут через сеть для пакета с меткой. В отличие от маршрутизации по dest IP, пакет с меткой маршрутизируется по сети основываясь на значении метки.

'''Заголовок MPLS''' - 32 bit (8bytes). Добавляется сразу после L2 заголовка.

Заголовок содержит: метку, CoS, Stack bit, TTL.

Метки MPLS уникальны в рамках роутера. На каждом роутере в MPLS домене, через который проходит LSP, метка обязательно будет меняться.

* 0 - Explicit null (IPv4)
* 1 - Router alter label (IP router alert)
* 2 - Explicit null (IPv6)
* 3 - Implicit null
* 4-15 - for future use

Таблица '''mps.0''' - для хранения информации о метках. Для транзитных роутеров, для принятия решений - куда передавать трафик. При включении MPLS, в ней сразу появляется информаци о 0,1,2 метках.

===Терминология===
'''LSP''' labe switched path - однонаправленный поток трафика.

'''LSR''' label switching router = роутер, использующий MPLS, который участвует в построении LSP.

Бывает нескольких типов:
* '''Ingress'''
:- Пакеты входят в LSP на ingress роутере
:- Делает push метки
:- Для отдельной LSP может быть только 1 ingress роутер
:- Upstream для остальных роутеров в рамках LSP
* '''Transit'''
:- Для LSP может быть 0 или более transit роутеров
:- Делает swap метки
:- Передает трафик следующему хопу LSP
* '''Penultimate'''
:- Предпоследний для LSP роутер
:- По дефолту делает pop метки и пакет без метки отправляет последнему egress роутеру.
* '''Egress'''
:- Пакеты выходят из LSP на egress роутере
:- Передает пакет дальше, основываясь на IP
:- Downstream для других роутеров в рамках LSP

===PHP, UHP===

'''PHP''' - ''penultimate hop popping'' - снятие метки на предпоследнем роутере. В таком случае egress роутер будет освобожден от этой функции и будет делает стандартный lookup по адресу назначения в таблице inet.0. Для реализации этой процедуры egress при установлении LSP отправляет предпоследнему роутеру метку 3.

'''UHP''' - ''ultimate hop popping'' - предпоследний роутер передает последнему пакет с меткой. Метка снимается на последнем роутере. Такое поведение требуется, например, для корректной работы CoS. Для реализации такого поведения нужно включить:

set protocols mpls explicit-null

При этом egress роутер при создании LPS будет отправлять предпоследнему роутеру метку 0.

===inet.3===
Маршруты вставляются в таблицу inet.3, в которую залезает BGP, перед тем как отрезолвить next-hop для префикса. Если удалось найти next-hop в inet.3, то BGP вставляет LSP в inet.0 в качестве физического next-hop. Если не удалось, то BGP идет в inet.0 и пытается отрезолвить там.

Если мы резолвим next-hop для Lo интерфейса удаленного маршрутизатора, что в inet.0 он будет виден как доступный через IGP протокол и трафик будет передаваться в соответствие с IGP, то есть в p2p интерфейс с соседним маршрутизатором.

Если же мы будем резолвить next-hop для префикса, находящегося за пределами IGP домена (клиентский), который будет известен по BGP (а такое будет обязательно, т.к. обычно для распространения подобных маршрутов используется next-hop self, подставляется Lo удалённого маршрутизатора), то BGP залезет в inet.3, увидит в качестве next-hop LSP до Lo удалённого маршрутизатора и подставит эту запись в inet.0!! Вот и вся магия.

То есть вся разница в том, что транзитный трафик, через роутер, участвующий в LSP, будет идти через LSP. А трафик направленный к самому роутеру (Lo интерфейсу), будут опираться на IGP.

LDP полностью опирается на IGP. inet.3 строится только на ingress роутерах. На транзитных - только mpls.0.

Глава 2. Label Distribution Protocols (RSVP, LDP)

2016-11-02T13:36:15Z

Владислав Павкин: /* RSVP */

Глава 2. Label Distribution Protocols (RSVP, LDP)

2016-11-02T13:35:24Z

Владислав Павкин: /* RSVP */

==RSVP==
'''RSVP''' - ''resource reservation protocol'' - требует больше конфигурации для работы, чем LPD, но зато имеет более полезных фич, таких как: TE, fast-failover, QoS, bandwidth reservation, LSP customization.

LSP установлена и имеет свой ''record route'': список IP адресов интерфейсов, через которых проходит RSVP LSP, включая ingress и egress.

Второй preference у RSVP: Когда внутри протокола требуется сравнение маршрутов. RSVP auto mesh - preference 2 = 3. Если на сети будет построен туннель статический, и auto-mesh, то предпочтительней будет статический. (preference 2: 1 < 3).
{{note| text=В LDP нет требования добавлять интерфейсы в protocols mpls, но family mpls включать нужно.}}
===Configuration===
1. Включаем family mpls на интерфейсах, смотрящих в ядро. Эта настройка позволяет отправлять и получать пакеты с метками.
[edit interfaces]
set ge-0/0/2.0 family mpls
set ge-0/0/3.0 family mpls

2. Настраиваем LSP. И добавляем нужные интерфейсы в protocols mpls. Это позволяет запустить на указанных интерфейсах mpls и появиться в TED, как возможный ресурс для использования.

[edit protocols mpls]
set label-switched-path R1-to-R5 {
to 10.200.86.3;
}
interface ge-0/0/2.0;
interface ge-0/0/3.0;

3. Добавляем в протокол RSVP нужные интерфейсы.
[edit protocols rsvp]
set interface ge-0/0/2.0
set interface ge-0/0/3.0

4. На остальных роутерах требуется включить family mpls и добавить интерфейсы в protocols rsvp.

==LDP==
'''LDP''' - ''label distribution protocol'' - намного более простой в настройке, но малофункциональный сигнальный протокол, по сравнению с RSVP.

===Соседство===
При включении LDP на роутере, он пытается установить соседство. Mulicast на '''UDP 646''' шлют hello пакеты (раз в 5 сек, dead interval = 15 сек). Другой роутер слушает hello на этом же порту, отвечает hello, т.о. устанавливается соседство.

После этого устанавливается TCP сессия. По этой сессии начинается обмен метками и пакетами по unicast.

Инициатором построения туннелей выступает egress роутер.

Роутер (A) анонсирует свой Lo соседнему роутеру (В). Этот анонс попадает в inet.3. Т.к. B - прямой сосед А, и между ними однохоповый туннель, то анонс от А придет с меткой 3.

Роутер B начинает анонсировать Lo роутера А остальным своим соседям (C,D), чтобы те начали строить туннели до роутера А. На роутерах C,D анонс от B поместится в inet.3, с ''push'' метка. А на роутере B в таблице mpls.0 - появляется запись для туннеля с ''swap''.

В итоге - full mesh на сети. На всех роутерах в inet.3 будет Lo роутера А.
{{note|text=Установление LDP LSP нельзя контролировать, они следуют кратчайшему пути по IGP.}}

'''Для исключения петель: '''

* На каждом роутере для каждого соседа создается 2 LDP database: на вход и на выход. LDP database, поступившая на вход, сравнивается с топологией IGP. В inet.3 попадает тот анонс, который пришел с того же next-hop, что указан для пришедшего Lo.
* То, что пришло и не совпало с IGP - сохраняется, но не используется. ''Liberal protection''.

'''Без настроенного link-state IGP (OSPF или ISIS) LDP работать не будет!''' Скорость перестроения - зависит от перестроения по IGP.

===Cisco===
В Cisco дефолтное поведение немного другое. Анонсируются не только Lo, а полностью таблица маршрутизации и сразу вставляется в GRT (global routing table).

Чтобы на Juniper получить такое же поведение:
# Пишем egress-policy: где указано что требуется анонсировать из таблицы маршрутизации по протоколу LDP. Policy применяется как egress policy к протоколу LDP.
# На всех остальных роутерах требуется перенести inet.3 в inet.0.

Это может понадобиться только в случае, если мы делаем редистрибьюцию внешних префиксов во внутренний протокол. '''- чего провайдер делать не должен.'''

===Configuration===

1. Включаем family mpls:
[edit interfaces]
set ge-0/0/2.0 family mpls
set ge-0/0/3.0 family mpls

2. Добавляем интерфейсы в protocols ldp
[edit protocols ldp]
set interface ge-0/0/2.0
set interface ge-0/0/3.0

3. На остальных роутерах в mpls домене делаем все тоже самое.

Можно проверить что будет происходить с меткой на каждом хопе LDP LSP:
show route protocol ldp 10.200.86.7
show ldp router
show route table inet.3 - если нет Lo нужного нам роутера, то проверяем есть ли Lo в inet.0 (IGP)

'''Обычно не стоит вопрос о том какой протокол использовать. Оба протокола друг друга просто дополняют.''' У двух протоколов разные preference, поэтому BGP будет выбирать RSVP, как более приоритетный.

Глава 2. Label Distribution Protocols (RSVP, LDP)

2016-11-02T13:32:11Z

Владислав Павкин:

==RSVP==
'''RSVP''' - ''resource reservation protocol'' - требует больше конфигурации для работы, чем LPD, но зато имеет более полезных фич, таких как: TE, fast-failover, QoS, bandwidth reservation, LSP customization.

Второй preference у RSVP: Когда внутри протокола требуется сравнение маршрутов. RSVP auto mesh - preference 2 = 3. Если на сети будет построен туннель статический, и auto-mesh, то предпочтительней будет статический. (preference 2: 1 < 3).

===Configuration===
1. Включаем family mpls на интерфейсах, смотрящих в ядро. Эта настройка позволяет отправлять и получать пакеты с метками.
[edit interfaces]
set ge-0/0/2.0 family mpls
set ge-0/0/3.0 family mpls

2. Настраиваем LSP. И добавляем нужные интерфейсы в protocols mpls. Это позволяет запустить на указанных интерфейсах mpls и появиться в TED, как возможный ресурс для использования.

[edit protocols mpls]
set label-switched-path R1-to-R5 {
to 10.200.86.3;
}
interface ge-0/0/2.0;
interface ge-0/0/3.0;

3. Добавляем в протокол RSVP нужные интерфейсы.
[edit protocols rsvp]
set interface ge-0/0/2.0
set interface ge-0/0/3.0

4. На остальных роутерах требуется включить family mpls и добавить интерфейсы в protocols rsvp.

{{note| text=В LDP нет требования добавлять интерфейсы в protocols mpls, но family mpls включать нужно.}}

LSP установлена и имеет свой ''record route'': список IP адресов интерфейсов, через которых проходит RSVP LSP, включая ingress и egress.

==LDP==
'''LDP''' - ''label distribution protocol'' - намного более простой в настройке, но малофункциональный сигнальный протокол, по сравнению с RSVP.

===Соседство===
При включении LDP на роутере, он пытается установить соседство. Mulicast на '''UDP 646''' шлют hello пакеты (раз в 5 сек, dead interval = 15 сек). Другой роутер слушает hello на этом же порту, отвечает hello, т.о. устанавливается соседство.

После этого устанавливается TCP сессия. По этой сессии начинается обмен метками и пакетами по unicast.

Инициатором построения туннелей выступает egress роутер.

Роутер (A) анонсирует свой Lo соседнему роутеру (В). Этот анонс попадает в inet.3. Т.к. B - прямой сосед А, и между ними однохоповый туннель, то анонс от А придет с меткой 3.

Роутер B начинает анонсировать Lo роутера А остальным своим соседям (C,D), чтобы те начали строить туннели до роутера А. На роутерах C,D анонс от B поместится в inet.3, с ''push'' метка. А на роутере B в таблице mpls.0 - появляется запись для туннеля с ''swap''.

В итоге - full mesh на сети. На всех роутерах в inet.3 будет Lo роутера А.
{{note|text=Установление LDP LSP нельзя контролировать, они следуют кратчайшему пути по IGP.}}

'''Для исключения петель: '''

* На каждом роутере для каждого соседа создается 2 LDP database: на вход и на выход. LDP database, поступившая на вход, сравнивается с топологией IGP. В inet.3 попадает тот анонс, который пришел с того же next-hop, что указан для пришедшего Lo.
* То, что пришло и не совпало с IGP - сохраняется, но не используется. ''Liberal protection''.

'''Без настроенного link-state IGP (OSPF или ISIS) LDP работать не будет!''' Скорость перестроения - зависит от перестроения по IGP.

===Cisco===
В Cisco дефолтное поведение немного другое. Анонсируются не только Lo, а полностью таблица маршрутизации и сразу вставляется в GRT (global routing table).

Чтобы на Juniper получить такое же поведение:
# Пишем egress-policy: где указано что требуется анонсировать из таблицы маршрутизации по протоколу LDP. Policy применяется как egress policy к протоколу LDP.
# На всех остальных роутерах требуется перенести inet.3 в inet.0.

Это может понадобиться только в случае, если мы делаем редистрибьюцию внешних префиксов во внутренний протокол. '''- чего провайдер делать не должен.'''

===Configuration===

1. Включаем family mpls:
[edit interfaces]
set ge-0/0/2.0 family mpls
set ge-0/0/3.0 family mpls

2. Добавляем интерфейсы в protocols ldp
[edit protocols ldp]
set interface ge-0/0/2.0
set interface ge-0/0/3.0

3. На остальных роутерах в mpls домене делаем все тоже самое.

Можно проверить что будет происходить с меткой на каждом хопе LDP LSP:
show route protocol ldp 10.200.86.7
show ldp router
show route table inet.3 - если нет Lo нужного нам роутера, то проверяем есть ли Lo в inet.0 (IGP)

'''Обычно не стоит вопрос о том какой протокол использовать. Оба протокола друг друга просто дополняют.''' У двух протоколов разные preference, поэтому BGP будет выбирать RSVP, как более приоритетный.

Глава 2. Label Distribution Protocols (RSVP, LDP)

2016-11-02T13:30:02Z

Владислав Павкин: /* LDP */

===RSVP===
'''RSVP''' - ''resource reservation protocol'' - требует больше конфигурации для работы, чем LPD, но зато имеет более полезных фич, таких как: TE, fast-failover, QoS, bandwidth reservation, LSP customization.

====Configuration====
1. Включаем family mpls на интерфейсах, смотрящих в ядро. Эта настройка позволяет отправлять и получать пакеты с метками.
[edit interfaces]
set ge-0/0/2.0 family mpls
set ge-0/0/3.0 family mpls

2. Настраиваем LSP. И добавляем нужные интерфейсы в protocols mpls. Это позволяет запустить на указанных интерфейсах mpls и появиться в TED, как возможный ресурс для использования.

[edit protocols mpls]
set label-switched-path R1-to-R5 {
to 10.200.86.3;
}
interface ge-0/0/2.0;
interface ge-0/0/3.0;

3. Добавляем в протокол RSVP нужные интерфейсы.
[edit protocols rsvp]
set interface ge-0/0/2.0
set interface ge-0/0/3.0

4. На остальных роутерах требуется включить family mpls и добавить интерфейсы в protocols rsvp.

{{note| text=В LDP нет требования добавлять интерфейсы в protocols mpls, но family mpls включать нужно.}}

LSP установлена и имеет свой ''record route'': список IP адресов интерфейсов, через которых проходит RSVP LSP, включая ingress и egress.

===LDP===
'''LDP''' - ''label distribution protocol'' - намного более простой в настройке, но малофункциональный сигнальный протокол, по сравнению с RSVP.

====Соседство====
При включении LDP на роутере, он пытается установить соседство. Mulicast на '''UDP 646''' шлют hello пакеты (раз в 5 сек, dead interval = 15 сек). Другой роутер слушает hello на этом же порту, отвечает hello, т.о. устанавливается соседство.

После этого устанавливается TCP сессия. По этой сессии начинается обмен метками и пакетами по unicast.

Инициатором построения туннелей выступает egress роутер.

Роутер (A) анонсирует свой Lo соседнему роутеру (В). Этот анонс попадает в inet.3. Т.к. B - прямой сосед А, и между ними однохоповый туннель, то анонс от А придет с меткой 3.

Роутер B начинает анонсировать Lo роутера А остальным своим соседям (C,D), чтобы те начали строить туннели до роутера А. На роутерах C,D анонс от B поместится в inet.3, с ''push'' метка. А на роутере B в таблице mpls.0 - появляется запись для туннеля с ''swap''.

В итоге - full mesh на сети. На всех роутерах в inet.3 будет Lo роутера А.
{{note|text=Установление LDP LSP нельзя контролировать, они следуют кратчайшему пути по IGP.}}

'''Для исключения петель: '''

* На каждом роутере для каждого соседа создается 2 LDP database: на вход и на выход. LDP database, поступившая на вход, сравнивается с топологией IGP. В inet.3 попадает тот анонс, который пришел с того же next-hop, что указан для пришедшего Lo.

* То, что пришло и не совпало с IGP - сохраняется, но не используется. ''Liberal protection''.

'''Без настроенного link-state IGP (OSPF или ISIS) LDP работать не будет!''' Скорость перестроения - зависит от перестроения по IGP.

====Cisco====

В Cisco дефолтное поведение немного другое. Анонсируются не только Lo, а полностью таблица маршрутизации и сразу вставляется в GRT (global routing table).

Чтобы на Juniper получить такое же поведение:
# Пишем egress-policy: где указано что требуется анонсировать из таблицы маршрутизации по протоколу LDP. Policy применяется как egress policy к протоколу LDP.
# На всех остальных роутерах требуется перенести inet.3 в inet.0.

Это может понадобиться только в случае, если мы делаем редистрибьюцию внешних префиксов во внутренний протокол. '''- чего провайдер делать не должен.'''

====Configuration====

1. Включаем family mpls:
[edit interfaces]
set ge-0/0/2.0 family mpls
set ge-0/0/3.0 family mpls

2. Добавляем интерфейсы в protocols ldp
[edit protocols ldp]
set interface ge-0/0/2.0
set interface ge-0/0/3.0

3. На остальных роутерах в mpls домене делаем все тоже самое.

Можно проверить что будет происходить с меткой на каждом хопе LDP LSP:
show route protocol ldp 10.200.86.7
show ldp router
show route table inet.3 - если нет Lo нужного нам роутера, то проверяем есть ли Lo в inet.0 (IGP)

'''Обычно не стоит вопрос о том какой протокол использовать. Оба протокола друг друга просто дополняют.''' У двух протоколов разные preference, поэтому BGP будет выбирать RSVP, как более приоритетный.

Второй preference у RSVP: Когда внутри протокола требуется сравнение маршрутов. RSVP auto mesh - preference 2 = 3. Если на сети будет построен туннель статический, и auto-mesh, то предпочтительней будет статический. (preference 2: 1 < 3).

Route Table and LSP Integration

2016-10-28T18:16:32Z

Владислав Павкин:

=Traffic-engineering bgp-igp=
'''Перенесет''' все маршруты из inet.3 в inet.0. Новые маршруты из inet.3 перекроют старые маршруты из inet.0, т.к. протоколы LDP и RSVP имеют лучший преференс.
Этот делается в целях обеспечения всей маршрутизации в сети по mpls-lsp (LDP и RSVP signalled). Но в этом варианте не работают VPN, основанные на MPLS,
потому, что таблица Inet3 останется пуста.

=Traffic-engineering bgp-igp-both-ribs=
'''Скопирует''' маршруты из inet.3 в inet.0. Новые маршруты из inet.3, опять же, перекроют старые маршруты из inet.0,
но старые маршруты в inet3 останутся, поэтому этот способ годится, если в сети нужны VPN-сервисы.

=Traffic-engineering mpls-forwarding=
'''Скопирует''' все маршруты из inet.3 в inet.0, но и старые маршруты в inet.0 оставит для совместимости с некоторыми политиками маршрутизации. Однако, фактически, форвардинг будет происходить по новым маршрутам.
Для индикации итого, какие маршруты в inet.0 для форвардинга трафика, а какие чисто инфомративные, есть дополнительные обозначения (#|@) в выводе show route:
> show route 10.200.86.3
inet.0: 29 destinations, 38 routes (29 active, 1 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

10.200.86.3/32 @[OSPF/10] 00:25:58, metric 3
> to 192.168.86.5 via ge-0/0/0.20
#[RSVP/7/1] 00:20:06, metric 3
> to 192.168.86.5 via ge-0/0/0.20, label-switched-path dalwhinnie-to-oban
[LDP/9] 00:02:30, metric 1
> to 192.168.86.5 via ge-0/0/0.20, Push 300288

Отказоустойчивость и оптимизация в MPLS

2016-10-28T18:16:03Z

Владислав Павкин: Добавил страницу Failover

=Fast Reroute=
На каждом промежуточном LSR создается LSP для обхода линка до следующей ноды и самой следующей ноды. Это проприетарный механизм Juniper.

Отличия от node-link-protection:
* При работе механизма frr лейбл не добавляется в стек к пакету. Вместо этого PLR производит swap на другой лейбл.
* Каждый detour защищает только свою конкретную LSP

=Secondary path=
Конфигурация:

[edit protocols mpls]  R1# show  label-switched-path R1-to-R4 {
to 10.0.0.3;
primary via-R2;
secondary via-R3 {
standby;
}
}
path via-tormore {
10.200.86.9 loose;
}  path via-blair {
192.168.10.15 strict;
192.168.10.4 strict;
192.168.10.55 strict;
} 

Primary path считается основным path. Если один из линков или роутеров на основном пути упадет, трафик пойдет по secondary. Но как только primary path станет доступным, трафик вернется обратно на primary. Чтобы избежать возвращения трафика на primary path, можно настроить два или более secondary путей, не настраивая ни одного primary.

=Loop-Free Alternates in IGPs=
Подробно не рассматривается в книге. Этот метод может сделать привлекательным использование LDP для сети, которой нужны MPLS-службы (L2VPN, L3VPN, VPLS), но нет необходимости в Traffic Engineering.
Конфигурируется добавлением опций «link-protection» или «node-link protection» в настройку интерфейса в протоколе ospf или IS-IS. Добавлением же опции «no-eligible-backup» можно предотвратить интерфейс от обслуживания бэкапного трафика.

Заглавная страница

2016-10-28T18:14:47Z

Владислав Павкин: /* Deploying MPLS */

=Сертификация Juniper=
==JNCIS-SP==

===Книга 1 (Routing, tunneling)===

====[[Глава 1-6. High Availability]]====

===Книга 2 (Switching)===

====[[Глава 2-4. Provider bridging]]====

====[[Глава 2-7. ERP (Ethernet Ring Protection)]]====

====!!!Эту главу основательно отредактировать[[Глава 2-7. LAG]]====

===Книга 3 (MPLS)===

====[[Глава 2. RSVP]]====

====[[Глава 5. MPLS Features]]====

====[[Глава 6. VPN]]====

====[[Глава 8. L3VPN Configuration]]====

====[[Глава 9. Полезности по траблшутингу L3VPN]]====

====[[Глава 10. L3VPN Scaling and Internet Access]]====

====[[Глава 11. L3VPN Advanced topics]]====

====[[Глава 12. Multicast VPNs]]====

====[[Главы 16-17. VPLS]]====

==JNCIP-SP==

===Advanced routing===

====[[OSPF]]====

====[[BGP]]====

====[[IS-IS]]====

===JCOS===

====[[Глава 2. Qos]]====

====[[Глава 3. Packet classification]]====

====[[Глава 4. Policing]]====

====[[Глава 5. Scheduling]]====

====[[Глава 6. Hierarchical scheduling]]====

====[[Глава 7. Rewrite rules]]====

====[[Глава 8. CoS-based forwarding]]====

===JMR===

====[[Глава 2. Multicast]]====

====[[Глава 3. Routing protocols]]====

====[[Глава 4. MSDP]]====

====[[Глава 5. SSM]]====

====[[Глава 6. Multicast and Policy]]====

====[[Глава 7. IPv6]]====

===JMV===

====[[Глава 1. Fundamentals]]====

====[[Глава 2. LDP]]====

===Deploying MPLS===
====[[Failover]]====
====[[Route Table and LSP Integration]]====

Route Table and LSP Integration

2016-10-28T18:12:26Z

Владислав Павкин: Новая страница: «=BGP Next-hop Installation= ==Traffic-engineering bgp-igp== '''Перенесет''' все маршруты из inet.3 в inet.0. Новые маршруты…»

=BGP Next-hop Installation=

==Traffic-engineering bgp-igp==
'''Перенесет''' все маршруты из inet.3 в inet.0. Новые маршруты из inet.3 перекроют старые маршруты из inet.0, т.к. протоколы LDP и RSVP имеют лучший преференс.
Этот делается в целях обеспечения всей маршрутизации в сети по mpls-lsp (LDP и RSVP signalled). Но в этом варианте не работают VPN, основанные на MPLS,
потому, что таблица Inet3 останется пуста.

==Traffic-engineering bgp-igp-both-ribs==
'''Скопирует''' маршруты из inet.3 в inet.0. Новые маршруты из inet.3, опять же, перекроют старые маршруты из inet.0,
но старые маршруты в inet3 останутся, поэтому этот способ годится, если в сети нужны VPN-сервисы.

==Traffic-engineering mpls-forwarding==
'''Скопирует''' все маршруты из inet.3 в inet.0, но и старые маршруты в inet.0 оставит для совместимости с некоторыми политиками маршрутизации. Однако, фактически, форвардинг будет происходить по новым маршрутам.
Для индикации итого, какие маршруты в inet.0 для форвардинга трафика, а какие чисто инфомративные, есть дополнительные обозначения (#|@) в выводе show route:
> show route 10.200.86.3
inet.0: 29 destinations, 38 routes (29 active, 1 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

10.200.86.3/32 @[OSPF/10] 00:25:58, metric 3
> to 192.168.86.5 via ge-0/0/0.20
#[RSVP/7/1] 00:20:06, metric 3
> to 192.168.86.5 via ge-0/0/0.20, label-switched-path dalwhinnie-to-oban
[LDP/9] 00:02:30, metric 1
> to 192.168.86.5 via ge-0/0/0.20, Push 300288

Заглавная страница

2016-10-28T18:08:33Z

Владислав Павкин:

Заглавная страница

2016-10-28T18:04:45Z

Владислав Павкин: /* JNCIP-SP */

BGP

2016-10-23T22:42:57Z

Владислав Павкин: /* Autonomous system path */

== Состояния соседства ==
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 категории:
# '''Well-known mandatory''' — все маршрутизаторы, работающие по протоколу BGP, должны распознавать эти атрибуты. Должны присутствовать во всех обновлениях (update).
# '''Well-known discretionary''' — все маршрутизаторы, работающие по протоколу BGP, должны распознавать эти атрибуты. Могут присутствовать в обновлениях (update), но их присутствие не обязательно.
# '''Optional transitive''' — могут не распознаваться всеми реализациями BGP. Если маршрутизатор не распознал атрибут, он помечает обновление как частичное (partial) и отправляет его дальше соседям, сохраняя не распознанный атрибут.
# '''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 байта.

====Операторы регулярных выражений====
{{re|title=Список регулярный выражений для AS Path}}

=== 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''' — указывает на то, каким образом был получен маршрут в обновлении.
{| class="wikitable"
|+Возможные значения атрибута
|-
|'''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.
* Обычно используется на бордерах.
{{note|text=Когда в сети есть 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-соседям, но анонсируются внешним соседям в конфедерации.

'''Пример использования'''
{{note|text=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'''.}}

{{note|text= 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.
{{note|text=Маршрутизаторы, которые не поддерживают атрибут 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====
{{re|title=Список операторов регулярных выражений для Community}}

=== Multi exit discriminator (MED)===
Атрибут '''MED''':
* Используется для информирования eBGP-соседей о том, какой путь в автономную систему более предпочтительный.
* Атрибут передается между автономными системами.
* Маршрутизаторы внутри соседней автономной системы используют этот атрибут, но, как только обновление выходит за пределы AS, атрибут MED отбрасывается.
* Чем меньше значение атрибута, тем более предпочтительна точка входа в автономную систему.

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

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

== Механизмы управления трафиком ==
===Входящим===
*AS path prepend
*Community (если поддерживает провайдер)
*MED (подключение к одной и той же AS)
*Анонс разных префиксов через разных ISP

===Исходящим===
*Проприетарный атрибут Cisco weight (локально на маршрутизаторе)
*Атрибут Local Preference (локально в AS)
*Балансировка трафика {{чо?}}

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

* Juniper
# Prefer highest local preference value
# Prefer shortest AS-path length
# Prefer lowest Origin value
# Prefer lowest MED value
# Prefer routes learned from an EBGP peer over an IBGP peer
# If the remaining routes were learned through IBGP, use the path with the lowest IGP cost to the IBGP peer.
# For EBGP received routes, prefer the current active route; otherwise, prefer routes from the peer with the lowest RID
# Prefer paths with the shortest cluster length
# 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.'''
# Клиент -> cluster RR
# RR -> all clients and non-clients(other RR)
# 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

Шаблон:Re

2016-10-23T22:41:43Z

Владислав Павкин:

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

Шаблон:Re

2016-10-23T22:41:03Z

Владислав Павкин:

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

BGP

2016-10-23T22:40:30Z

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

== Состояния соседства ==
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 категории:
# '''Well-known mandatory''' — все маршрутизаторы, работающие по протоколу BGP, должны распознавать эти атрибуты. Должны присутствовать во всех обновлениях (update).
# '''Well-known discretionary''' — все маршрутизаторы, работающие по протоколу BGP, должны распознавать эти атрибуты. Могут присутствовать в обновлениях (update), но их присутствие не обязательно.
# '''Optional transitive''' — могут не распознаваться всеми реализациями BGP. Если маршрутизатор не распознал атрибут, он помечает обновление как частичное (partial) и отправляет его дальше соседям, сохраняя не распознанный атрибут.
# '''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 байта.

=== 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''' — указывает на то, каким образом был получен маршрут в обновлении.
{| class="wikitable"
|+Возможные значения атрибута
|-
|'''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.
* Обычно используется на бордерах.
{{note|text=Когда в сети есть 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-соседям, но анонсируются внешним соседям в конфедерации.

'''Пример использования'''
{{note|text=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'''.}}

{{note|text= 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.
{{note|text=Маршрутизаторы, которые не поддерживают атрибут 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====
{{re|title=Список операторов регулярных выражений для Community}}

=== Multi exit discriminator (MED)===
Атрибут '''MED''':
* Используется для информирования eBGP-соседей о том, какой путь в автономную систему более предпочтительный.
* Атрибут передается между автономными системами.
* Маршрутизаторы внутри соседней автономной системы используют этот атрибут, но, как только обновление выходит за пределы AS, атрибут MED отбрасывается.
* Чем меньше значение атрибута, тем более предпочтительна точка входа в автономную систему.

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

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

== Механизмы управления трафиком ==
===Входящим===
*AS path prepend
*Community (если поддерживает провайдер)
*MED (подключение к одной и той же AS)
*Анонс разных префиксов через разных ISP

===Исходящим===
*Проприетарный атрибут Cisco weight (локально на маршрутизаторе)
*Атрибут Local Preference (локально в AS)
*Балансировка трафика {{чо?}}

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

* Juniper
# Prefer highest local preference value
# Prefer shortest AS-path length
# Prefer lowest Origin value
# Prefer lowest MED value
# Prefer routes learned from an EBGP peer over an IBGP peer
# If the remaining routes were learned through IBGP, use the path with the lowest IGP cost to the IBGP peer.
# For EBGP received routes, prefer the current active route; otherwise, prefer routes from the peer with the lowest RID
# Prefer paths with the shortest cluster length
# 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.'''
# Клиент -> cluster RR
# RR -> all clients and non-clients(other RR)
# 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

Шаблон:Re

2016-10-23T22:39:53Z

Владислав Павкин: Новая страница: «{| class="wikitable" |+Операторы регулярных выражений |- |'''{m,n}''' |От m до n |- |'''{m}''' | m |- |'''{m,}''' | m или бо…»

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

BGP

2016-10-23T22:39:46Z

Владислав Павкин: /* no-export-subconfed (0xFFFFFF03) */

== Состояния соседства ==
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 категории:
# '''Well-known mandatory''' — все маршрутизаторы, работающие по протоколу BGP, должны распознавать эти атрибуты. Должны присутствовать во всех обновлениях (update).
# '''Well-known discretionary''' — все маршрутизаторы, работающие по протоколу BGP, должны распознавать эти атрибуты. Могут присутствовать в обновлениях (update), но их присутствие не обязательно.
# '''Optional transitive''' — могут не распознаваться всеми реализациями BGP. Если маршрутизатор не распознал атрибут, он помечает обновление как частичное (partial) и отправляет его дальше соседям, сохраняя не распознанный атрибут.
# '''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 байта.

=== 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''' — указывает на то, каким образом был получен маршрут в обновлении.
{| class="wikitable"
|+Возможные значения атрибута
|-
|'''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.
* Обычно используется на бордерах.
{{note|text=Когда в сети есть 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-соседям, но анонсируются внешним соседям в конфедерации.

'''Пример использования'''
{{note|text=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'''.}}

{{note|text= 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.
{{note|text=Маршрутизаторы, которые не поддерживают атрибут 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====
{{re}}

=== Multi exit discriminator (MED)===
Атрибут '''MED''':
* Используется для информирования eBGP-соседей о том, какой путь в автономную систему более предпочтительный.
* Атрибут передается между автономными системами.
* Маршрутизаторы внутри соседней автономной системы используют этот атрибут, но, как только обновление выходит за пределы AS, атрибут MED отбрасывается.
* Чем меньше значение атрибута, тем более предпочтительна точка входа в автономную систему.

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

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

== Механизмы управления трафиком ==
===Входящим===
*AS path prepend
*Community (если поддерживает провайдер)
*MED (подключение к одной и той же AS)
*Анонс разных префиксов через разных ISP

===Исходящим===
*Проприетарный атрибут Cisco weight (локально на маршрутизаторе)
*Атрибут Local Preference (локально в AS)
*Балансировка трафика {{чо?}}

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

* Juniper
# Prefer highest local preference value
# Prefer shortest AS-path length
# Prefer lowest Origin value
# Prefer lowest MED value
# Prefer routes learned from an EBGP peer over an IBGP peer
# If the remaining routes were learned through IBGP, use the path with the lowest IGP cost to the IBGP peer.
# For EBGP received routes, prefer the current active route; otherwise, prefer routes from the peer with the lowest RID
# Prefer paths with the shortest cluster length
# 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.'''
# Клиент -> cluster RR
# RR -> all clients and non-clients(other RR)
# 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

BGP

2016-10-22T18:43:53Z

Владислав Павкин: /* Route Reflection */ Раздел добавлен.

BGP

2016-10-22T18:38:14Z

Владислав Павкин:

BGP

2016-10-22T14:33:28Z

Владислав Павкин: /* Атрибуты пути (path attributes) */ Расставил свойства атрибутов для каждого атрибута, поэтому удаляю примеры свойст атрибутов.

Шаблон:Чо?

2016-10-22T14:30:57Z

Владислав Павкин:

Шаблон:Чо?

2016-10-22T14:27:59Z

Владислав Павкин:

''← Чоо? O_o''

BGP

2016-10-22T14:27:19Z

Владислав Павкин:

Шаблон:Чо?

2016-10-22T14:26:39Z

Владислав Павкин: Новая страница: «''<- Чоо? O_o''»

''<- Чоо? O_o''

BGP

2016-10-22T14:07:01Z

Владислав Павкин: /* Origin */ Добавил свойств атрибутов

BGP

2016-10-22T14:03:06Z

Владислав Павкин: /* Origin */ Поправил внешний вид

BGP

2016-10-22T13:56:25Z

Владислав Павкин: /* Next-hop */

BGP

2016-10-21T23:44:49Z

Владислав Павкин: /* no-export-subconfed (0xFFFFFF03) */

BGP

2016-10-21T23:44:40Z

Владислав Павкин: /* no-export (0xFFFFFF01) */

Шаблон:Note

2016-10-21T23:44:12Z

Владислав Павкин: Обновление шаблона Note

{|style="border-style: solid; border-width: 0 0 0 3px;"
|
<blockquote style="color: #666666;">{{{text}}}</blockquote>
|}

BGP

2016-10-21T23:40:13Z

Владислав Павкин: /* Communities */ Пример использования no-export

Шаблон:Note

2016-10-21T23:39:05Z

Владислав Павкин:

Шаблон:Note

2016-10-21T23:37:17Z

Владислав Павкин:

Заметка!
{{{text}}}

Шаблон:Note

2016-10-21T23:36:40Z

Владислав Павкин:

Заметка!
{{{1}}}

Шаблон:Note

2016-10-21T23:35:20Z

Владислав Павкин:

Заметка!

Шаблон:Note

2016-10-21T23:33:03Z

Владислав Павкин: Новая страница: «{{Заметка: 1}}»

BGP

2016-10-21T20:33:11Z

Владислав Павкин: /* Option 2: local-as */ Еще уточнение

BGP

2016-10-21T20:16:27Z

Владислав Павкин: /* Multipath */ Убрал лишний вывод

BGP

2016-10-21T20:15:06Z

Владислав Павкин: /* Option 2: local-as */

BGP

2016-10-21T20:14:03Z

Владислав Павкин:

BGP

2016-10-21T16:07:24Z

Владислав Павкин: /* Link Bandwidth Extended Community */

BGP

2016-10-21T16:06:17Z

Владислав Павкин:

Заглавная страница

2016-10-21T15:11:34Z

Владислав Павкин: