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

BGP

2022-09-14T08:08:06Z

Наталия Бобкова: /* Возможные операции с MED */

{{#description2:BGP в Juniper. Состояния соседства BGP. Сообщения. Атрибуты BGP. Local preference. AS Path. Next-hop. Communities. Механизмы управления трафиком. Multipath. Multihop. Route Reflection. Confederations. Route damping. Blackhole. }}
BGP - протокол маршрутизации между AS. Path-vector protocol.

'''IBGP''' - соседство внутри AS. Соседство строится обычно на Lo адресах.

'''EBGP''' - соседство между разными AS. Соседство строится на p2p адресах.

Поддерживает аутентификацию: MD5. Можно настроить key-chain, с указанием когда какой ключ использовать. Аутентификация применяется на разных уровнях protocols bgp.
=Состояния соседства=
http://habrastorage.org/getpro/habr/post_images/442/780/549/442780549c2f45cdda10773121b2800d.png

Для установления соседства используется TCP:179.
*'''Idle''': all incoming connections - refused. Инициализация BGP ресурсов и подготовка к установлению TCP. Если роутер завис в состоянии Idle - проверить наличие маршрута к соседу.
*'''Connect''': процесс установления TCP сессии. Роутер слушает TCP 179. Если сессия установилась, то роутер отправляет Open message и переходит в OpenSent состояние. Если TCP не установилась, то роутер переходит в Active состояние и запускает заново ConnectRetryTimer.
*'''Active''': local router становится активным инициатором TCP-сессии. В состоянии Active - когда ответил на прилетевший TCP. Если роутер завис в Active, проверяем: связность, прохождение по tcp:179, корректность настройки BGP с двух сторон.
*'''OpenSent''': Open отправлен локальным роутером и роутер ждет ответа (Open) от соседа.
*'''OpenConfirm''': Open сообщение получено от соседа и роутер ждет Keepalive или Notification message. Если от соседа не приходит keepalive до истечения hold timer, то роутер генерирует Notification message, с инфо, что hold timer expired и переведет сессию в Idle. Если keepalive получен, то соседство переходит в Established state.
*'''Established''': BGP сессия установлена, пиры начинают обмениваться информацией, используя: Update, Keepalive, Notification сообщений.

Hold timer может быть разным у пиров. При установлении сессии будет выбран наименьший.

==Tips==
Если сессия установилась в Established, но через какое-то время перешла в Idle по Hold timer expared (скорее всего через 90sec = 3*keepalive), то первым делом проверьте MTU на канале между роутерами.

Если MTU где-то по пути зарезан/не соответствует MTU на интерфейсах bgp-пиров, можно либо решить вопрос с MTU на найденном проблемном участке, либо можно установить для сессии вручную размер mss (maximum segment size):
set protocols bgp group clients neighbor 1.1.1.1 tcp-mss 1470

Признаки подобной проблемы в логах:
Jan 1 00:18:18.553797 bgp_io_mgmt_cb:1777: NOTIFICATION sent to 1.1.1.1 (Internal AS 64777): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 1.1.1.1 (Internal AS 64777), socket buffer sndcc: 0 rcvcc: 0 TCP state: 4, snd_una: 733415251 snd_nxt: 733415251 snd_wnd: 16384 rcv_nxt: 4248562819 rcv_adv: 4248579203, hold timer 90s, hold timer remain 0s, last sent 6s, TCP port (local 52746, remote 179)
Jan 1 00:18:18.553889 BGP SEND message type 3 (Notification) length 21
Jan 1 00:18:18.553901 BGP SEND Notification code 4 (Hold Timer Expired Error) subcode 0 (unused)
Jan 1 00:18:18.554014 bgp_peer_close_and_restart: closing peer 1.1.1.1 (Internal AS 64777), state is 7 (Established) event HoldTime
Jan 1 00:18:18.554064 RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 1.1.1.1 (Internal AS 64777) changed state from Established to Idle (event HoldTime) (instance master)

=Сообщения=
Все сообщения имеют '''Header'''
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Marker |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

BGP header содержит:
:*'''marker''' - 16 октетов, установлены в "1". Обозначает, что это bgp-пакет
:*'''lenght''' - размер пакета (16bit)
:*'''type''' - тип сообщения
:** 1 - OPEN
:** 2 - UPDATE
:** 3 - NOTIFICATION
:** 4 - KEEPALIVE
:**5 - ROUTE-REFRESH [определен в RFC 2918]

'''Типы пакетов:'''
*'''Open''' (type 1) - отправляется только на стадии установления соседства. Содержит параметры BGP соседа: AS, auth-type (+ ключ, если есть аутентификация).
*'''Update''' (type 2) - передает info о добавлении или удалении маршрутов между соседями. Update содержит в себе Path, его атрибуты и вложенные префиксы, у которых эти атрибуты одинаковые. Не отправляются по таймеру, приходят, только когда изменился сам префикс, его атрибуты или BGP-сессия. В зависимости от policy, на локальном роутере, часть routing info может быть отброшена и помещена в hidden.
*'''Notification''' (type 3) - в случае если что-то пошло не так: не прошел keepalive или update, пришла не поддерживаемая опция, ... Существуют стандартизированные коды ошибок (operation code | opcode). Пакет состоит из header + opcode+subcode + data (описание ошибки - для диагностики).
*'''Keepalive''' (type 4)- для удостоверения, что с соседством все ok. Отправляется каждые 30 sec. По дефолту hold-timer = 3 * keepalive = 90sec - время, после которого соседи рушат соседство (если в это время не пролетело ни одного keepalive). Можно выставить holdtimer = 0. Если у одного соседа = 0, у другого нет, то будет согласовано ненулевое значение holdtimer для сессии.
{{note|text=keepalive message = BGP header без payload}}
*'''Refresh''' - soft clearing BGP сессии.

=BGP Operations=
BGP хранит маршруты в трех местах:
*Adjacency-RIB-IN: все полученные маршруты от пиров
*RIB-Local: маршруты локального роутера, используемые для передачи трафика. Тут хранятся только активные маршруты.
*Adjacency-RIB-OUT: маршруты, которые будут отправляться пирам. Передаваться могут только активные маршруты. ('''advertise-inactive''' исправляет данную ситуацию).

Передача маршрутов производится по правилам (чтобы избежать routing loops):
#IBGP пиры передают маршруты, полученные от EBGP другим IBGP пирам.
#EBGP пиры передают маршруты, полученные от EBGP и IBGP другим EBGP пирам
#IBGP пиры не передают маршруты, полученные от других IBGP пиров. Поэтому для того, чтобы получить всю маршрутную информацию, требуется full-mesh связность. Либо использование RR.

По умолчанию IBGP пиры не меняют next-hop для маршрутов, полученных от EBGP.

Решается:
* настройкой '''next-hop self''' в рамках export policy к remote PE/RR.
* добавить p2p интерфейс с EBGP пиром в IGP как passive.
* анонс p2p сети по IGP. Export policy для IGP протокола.
* настройки статического маршрута на каждом IBGP до удаленного EBGP пира.
* настроить IGP соседство с EBGP пиром.

=Атрибуты (BGP attributes)=
Включаются в Update сообщения и описывают BGP префиксы. Атрибуты используются для выбора активного пути.
Атрибуты, при выборе best, считаются лучшими с наименьшими значением
Это правило касается всех атрибутов, кроме Local Preference

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

==Local preference==
'''✔️Well-known Discretionary'''
* Указывает маршрутизаторам внутри автономной системы как выйти за её пределы.
* Больший приоритет выигрывает.
* Этот атрибут передается только в пределах одной автономной системы => работает только для IBGP.
* На маршрутизаторах Cisco и Juniper по умолчанию значение атрибута — 100.
* Если EBGP-сосед получает обновление с выставленным значением local preference, он игнорирует этот атрибут.
* В Junos lpf можно задать через policy и в protocol bgp. Если задан обоими способами, то будет назначен lpf из policy.
* Обычно используется на бордерах.
{{note|text=Когда в сети есть 2 бордера, которые получают один и тот же маршрут извне, и бордеры навешивают одинаковый повышенный lpf через export policy, в таком случае соседи IBGP получат маршрут с измененным lpf, но трафик не сможет по-правильному пути выйти из AS. Из-за того что бордеры тоже друг от друга будут получать маршрут с повышенным lpf. Решение: правильно менять lpf через import policy. }}

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

Используется для:
* обнаружения петель
* влияние на path selection с помощью prepending (делается через export policy)
set protocols bgp group int export longer-as-path
set policy-options policy-statement longer-as-path term 1 then as-path-prepend "1111 1111 1111"

show route advertising-protocol bgp 10.200.86.2
inet.0: 32 destinations, 32 routes (32 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.17.0.0/24 Self 100 '''1111 1111 1111 [1111] I'''

'''Обозначение:'''
* [] - 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|Список регулярных выражений для AS Path}}
. - любой знак (одна точка - один любой знак, 3 точки - три любых символа).

==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 на выходе (export к IBGP):
set policy-options policy-statement nexthop-self term localpref then next-hop self

Или же на входе (import от EBGP peer):
set policy-options policy-statement nexthop-peer term localpref then next-hop ''peer-address''

==Origin==
'''✔️Well-known Mandatory'''
Атрибут '''Origin''' — указывает на то, каким образом был получен маршрут в обновлении. Меняется с помощью policy.
{| class="wikitable"
|+Возможные значения атрибута
|-
|'''0'''
|IGP
|NLRI получена внутри исходной автономной системы
|-
|'''1'''
| EGP
| NLRI выучена по протоколу Exterior Gateway Protocol (EGP) - протокол уже давно не используется.
|-
|'''2'''
| Incomplete
| NLRI была выучена каким-то другим образом, скорей всего через redistribution.
|}

==Atomic aggregate==
'''✔️Well-known Discretionary'''

==Aggregator==
'''✔️Optional Transitive'''

==Communities==
'''✔️Optional Transitive'''
* Тегирование маршрутов
* Существуют предопределенные значения (well-known), которые не требуется определять локально на своем оборудовании
* По умолчанию не пересылаются соседям
* Одному маршруту может быть присвоено несколько communities
*Community могут быть критерием в policy для изменения других атрибутов BGP, например lpf.
* Один из вариантов применения: передается соседней 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-test'' detail

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

===Действия с community===
*add - добавляет к текущим community префикса указанное community
*delete - удаляет только указанное community
*set - заменяет существующие community на указанное

==Multi exit discriminator (MED)==

'''✔️Optional Non-transitive'''

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

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

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

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

MED назначается с помощью policy.
===Возможные операции с 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''':
* Позволяет назначить "вес" различным путям локально на маршрутизаторе.
* Используется в тех случаях, когда у одного маршрутизатора есть несколько выходов из автономной системы (сам маршрутизатор является точкой выхода).
* Имеет значение только локально, в пределах маршрутизатора.
* Не передается в обновлениях.
* Чем больше значение атрибута, тем более предпочтителен путь выхода.

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

==Исходящим==
*Проприетарный атрибут Cisco weight (локально на маршрутизаторе)
*Local Preference (локально в AS)
*Косвенно можно политикой навешивать med на префиксы от пира и в зависимости от этого будет также регулироваться исходящий трафик.

=Выбор лучшего пути (BGP Active Route Selection)=
# Проверяем, что резолвится next-hop (без это маршрут и активным то не будет :/ )
# Route Preference (Admin distance)
# БОльший local preference (''Inactive reason: '''Local Preference''''')
# Кратчайший AS-path (''Inactive reason: '''AS path''''')
# Меньший Origin value (''Inactive reason: '''Origin''''')
# Меньший MED value (''Inactive reason: '''Route Metric or MED comparison''''')
# EBGP peer предпочтительней IBGP peer (''Inactive reason: '''Interior > Exterior > Exterior via Interior''''')
# C кратчайшей IGP метрикой к Protocol next-hop (''Inactive reason: '''Not Best in its group – IGP metric''''')
# Если префикс получен по IBGP, то используем префикс от пира с наименьшим RID (''Inactive reason: '''Not Best in its group – Router ID''''')
# Если префикс получен по EBGP, то используем более старый активный префикс (считается более стабильным) (''Inactive reason: '''Not Best in its group – Active preferred''''')
# При использовании RR: кратчайший cluster list length (''Inactive reason: '''Not Best in its group – Cluster list length''''')
# Наименьший router-ID (''Inactive reason: '''Not Best in its group – Router ID''''')
# Наименьший Source IP address (''Inactive reason: '''Not Best in its group - Update source''''')

В Juniper можно посмотреть причину неактивности маршрута: ''Inactive reason'' в выводе ''sh route protocol bgp x.x.x.x extensive''

Дефолтное поведение для EBGP маршрутов может быть изменено: '''path-selection external-router-id'''. При включении этой функции для роутера выбор активного EBGP маршрута от разных роутеров будет делаться по наименьшему router-id.

*Route Preference (Admin distance) - не передается по ibgp, ebgp. Может только навешиваться через import-policy или в настройках bgp на любом уровне иерархии.

=Multipath=
Один и тот же маршрут прилетает с двух пиров одной AS или несколько копий маршрута прилетает с одного пира. Активный маршрут будет вставлен в routing table с несколькими next-hop и трафик будет балансироваться между двумя пирами (в forwarding table все же будет вставляться один next-hop). Для inactive маршрутов будет указан один next-hop. Multipath не вставит маршруты с одинаковым MED-plus-IGP cost, при разных IGP метриках до пиров. На роутере глобально должен быть включен load-balancing.

При включенном multipath, алгоритм выбора лучшего пути игнорирует router ID и peer ID.

До включения:
mortlach> show route protocol bgp terse
inet.0: 30 destinations, 34 routes (30 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 172.17.0.0/24 B 170 100 >192.168.86.21 I
B 170 100 >192.168.86.42 I
* 172.17.1.0/24 B 170 100 >192.168.86.21 I
B 170 100 >192.168.86.42 I
* 172.17.2.0/24 B 170 100 >192.168.86.21 I
B 170 100 >192.168.86.42 I
* 172.17.3.0/24 B 170 100 >192.168.86.21 I
B 170 100 >192.168.86.42 I
mortlach> show route forwarding-table destination 172.17.0.0/24
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
172.17.0.0/24 user 0 indr 262142 5
192.168.86.21 ucst 547 5 '''ge-0/0/0.90 - выбран активным, из-за меньшего router-ID (10.200.86.4 vs 10.200.86.8)'''

После:
mortlach> show route protocol bgp terse
inet.0: 30 destinations, 34 routes (30 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 172.17.0.0/24 B 170 100 192.168.86.21 I
>192.168.86.42
B 170 100 >192.168.86.42 I
* 172.17.1.0/24 B 170 100 192.168.86.21 I
>192.168.86.42
B 170 100 >192.168.86.42 I
* 172.17.2.0/24 B 170 100 192.168.86.21 I
>192.168.86.42
B 170 100 >192.168.86.42 I
* 172.17.3.0/24 B 170 100 192.168.86.21 I
>192.168.86.42
B 170 100 >192.168.86.42 I

mortlach> show route forwarding-table destination 172.17.0.0/24
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
172.17.0.0/24 user 0 indr 262143 5
192.168.86.42 ucst 588 7 '''ge-0/0/0.50''' - '''изменился, т.к. router ID уже не влияет на выбор лучшего пути'''

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

Позволяет делать балансировку пропорционально заданным в community скоростям.

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

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

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

Конфиг 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:
set interfaces lo0 unit 0 family inet address 2.2.2.2/32

set policy-options policy-statement bw20 then community add bw20
set policy-options policy-statement bw80 then community add bw80

set policy-options policy-statement from-direct term redistribute-direct from protocol direct
set policy-options policy-statement from-direct term redistribute-direct then accept
set policy-options policy-statement from-direct term default then reject

set policy-options community bw20 members bandwidth:2222:2500000; '''// 2500000 байт в секунду — это 20% от 100Мегабит'''
set policy-options 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 bw20'''
peer-as 1111;}
neighbor 10.2.0.1 {
description R1;
export [ bw80 from-direct ]; '''// На второе соседство навешивается community bw80'''
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

=Multihop=
Возможность поднять EBGP peering между роутерами, не имеющих прямого физического соединения. Сессия устанавливается на lo интерфейсах.

Важно в конфиге задать multihop. В таблице маршрутизации должен быть маршрут до пира.

При поднятии сессии на Lo интерфейсах используем:
*''set system default-address-selection'' - будет браться адрес lo автоматически
*local-address (bgp, group или neighbor) - более специфичен, поэтому если надо будет - перебьет уже настроенный default-address-selection

TTL = 1 задаем, чтобы соседство установилось точно с одним ближайшим роутером. (либо другое значение, если роутер далеко)

blair> show route 10.200.86.4
10.200.86.4/32 *[IS-IS/18] 00:00:03, metric 10
to 192.168.86.49 via ge-0/0/0.80
> to 192.168.86.17 via ge-0/0/0.100
Config
set protocols bgp group int type internal
set protocols bgp group int multihop ttl 1
set protocols bgp group int local-address 10.200.86.1
set protocols bgp group int neighbor 10.200.86.4

Т.к. между роутерами теперь 2 физических линка, то можно балансировать трафик между ними.

=Modifying AS Path=
==Option 1: remove-private==
Диапазон: 64512 - 65534

Роутер, на котором настроен remove-private перед передачей префиксов удаляет из AS path AS из указанного выше диапазона.

Можно настраивать на всех уровнях: protocols bgp, group, neighbor.

==Option 2: local-as==
set routing-options autonomous-system 1111
set protocols bgp group ebgp neighbor 10.1.0.2 peer-as 2222
set protocols bgp group ebgp neighbor 10.1.0.2 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:
set protocols bgp group ebgp neighbor 10.1.0.2 peer-as 2222
set protocols bgp group ebgp neighbor 10.1.0.2 local-as 3333 '''private'''

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

==as-override==
CE1 '''(AS 65500)''' <> PE (AS 1111) <> P (AS 1111) <> PE (AS 1111) <> CE2 '''(AS 65500)'''

Если на сети ISP есть 2 сессии с пирами из одной AS, то при передаче маршрутов, полученных от одного site этой AS второму site'у, второй site не примет такой префикс, потому что в AS path будет дважды указана его AS - это routing loop.
65500 1111 I - '''роутер с AS 65500 не примет префикс с таким AS path.'''

set protocols bgp group int neighbor 10.200.86.4 as-override
Можно конфигурировать для группы или соседа.

Роутер ISP на полученном префиксе смотрит в AS path, AS пира заменяем на свою. При передаче префикса второму site ISP делает стандартный prepend своей AS. В итоге пиру в AS 65500 прилетит префикс с таким AS path:
1111 1111 I

==loops==
Еще один способ решения ситуации, описанной в примере выше - чтобы CE2 получил маршрут своего удаленного site:

На CE2:
set routing-options autonomous-system 65500 loops 2
Тогда на CE2 прилетит префикс с AS path:
1111 65500 I
и роутер это сожрет.

=Опции настройки для пиров=
*'''passive''' - локальный роутер перестает слать open message. Чтобы сессия поднялась, open message теперь должно прийти от удаленного пира.
blair# top show | compare
set protocols bgp group int neighbor 10.200.86.4 passive

Feb 11 22:07:58.812668 BGP SEND message type 1 (Open) length 59
Feb 11 22:07:58.856999 BGP RECV message type 1 (Open) length 59
После задания passive для пира:
Feb 11 22:12:22.128876 BGP RECV message type 1 (Open) length 59
* '''allow''' - принимает open message только из указанной сети. Можно указать только для определенной группы:
set protocols bgp group int allow 10.200.86.0/24
*'''prefix-limit''': ограничивает значение полученных префиксов от пира. Можно применять на разных уровнях иерархии.
set protocols bgp group int neighbor 10.200.86.4 family inet unicast prefix-limit maximum 1500
set protocols bgp group int neighbor 10.200.86.4 family inet unicast prefix-limit teardown 100 ('''%''') idle-timeout 10 ('''min''');}}}
*'''hold-time''': меняем hold timer. По дефолту 90 sec. Можно применять на разных уровнях иерархии.
set protocols bgp hold-time 120
*'''advertise-peer-as''': позволяет EBGP маршруты передавать обратно EBGP пиру. Но тогда и у пира должен быть настроен as loops, чтобы он не отбросил префикс с лупом в AS-Path.
set protocols bgp group int advertise-peer-as

=Route Reflection=
Описан в RFC 4456

'''Концепция'''

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

==Распространение маршрутов при использовании RR==
[[Файл:RR.png|700px]]

Будем использовать следующие обозначения:
*IBGP rr-client - IBGP сосед в кластере
*IBGP NON-rr-client - IBGP сосед не в кластере
*EBGP - EBGP сосед

Распространение маршрутов происходит следующим образом:
*IBGP rr-client > IBGP rr-client + IBGP NON-rr-client
*IBGP NON-rr-client > IGBP rr-client
*IBGP NON-rr-client <> IBGP NON-rr-client - '''не передается'''

*EGBP > IBGP rr-client + NON-rr-client

Если включить '''no-client-reflect''', то это запретит анонсить префиксы между клиентами кластера. В таком случае, если требуется сохранить связность между этими клиентами - нужно настроить между ними full-mesh. Такой вариант развитий по идее может понадобиться только при иерархичном роут-рефлектинге (о нем ниже).

RR добавляет/изменяет атрибуты (без политик по дефолту):
*'''Originator ID'''
Router ID первого роутера, который заслал маршрут в AS.

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

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

Правила работы с Originator и Cluster List:
*для EBGP или любого другого протокола, отличного от IBGP, originator и сluster list не добавляются
*для IBGP client<>client / client<>non-client:
:*originator добавится только если до этого его не существовало.
:*Cluster list дополнится новым cluster ID.
:*Cluster ID будет установлен, если его не было ранее.

'''2 RR в кластере'''

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

==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 на lo0 адресах (с включенным multihop!!)

==Hierarchical Route Reflection==
[[Файл:Hierarch_RR.png|700px]]

Отличие от предыдущих: в схеме появляются не только RR и client, но еще и роутеры, выполняющие обе функции в рамках разных кластеров.
Clients могут устанавливать IBPG между собой full-mesh. Это удобно использовать, чтобы 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-hop только у 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

=Fake-group=
Данная проблема описана в KB20870 (https://kb.juniper.net/InfoCenter/index?page=content&id=KB20870).

Более подробное описание и рекомендации по предотвращению https://www.juniper.net/documentation/en_US/junos/topics/example/bgp-vpn-session-flap-prevention.html

По факту функционал RR включается/выключается только при добавлении/удалении соседу в группе с клиентами (с '''cluster''').

Если на маршрутизаторе настроены '''EBGP с клиентами''' или '''IBGP c RR''', для которых в конфигурации группы '''включены vpn-address-family''', (inet-vpn, inet6 inet-mpvn, inet-mdt, inet6-mpvn, l2vpn, iso-vpn) и на маршрутизаторе в этих группах производится добавления первого соседа или удаления последнего, Juniper рестартует BGP сессии с RR и c EBGP пирами в VPN-address-family для отсылки NLRI с новой (удалением старой) address-family.

Для предотвращения подобных ситуаций можно предпринять следующие шаги:
* на каждом RR создана fake группа (для исключения проблемы удаления последнего соседа в группе).
* на каждом PE создана fake группа (для исключения проблемы включения нового клиента с EBGP + vpn-family)

==Configuration==
Fake группа имеет следующий вид для '''RR и PE''':
group fake-vpn {
type '''external''';
description "-- Preventing mpbgp sessions flap --";
'''passive''';
family inet {
any;
family inet-vpn {
any;
family iso-vpn {
unicast;
family l2vpn {
signaling;
family evpn {
signaling;
family inet-mvpn {
signaling;
family inet-mdt {
signaling;
'''neighbor 101.101.101.101''' {
'''peer-as 101''';

=IPv6 (6PE)=
Если у нас есть настроенная ipv4 сеть и мы захотели передавать трафик и для ipv6 адресов (используя MPLS), то:

- требуется настроить family inet6 labeled-unicast explicit-null на сессии pe<>rr
set protocols bgp group ibgp-rr family inet6 labeled-unicast explicit-null
эта family навешивает на ipv6 префикс '''label 2''' (explicit-null для ipv6), что позволяет на сети в качестве транспорта использовать mpls, а на последнем роутере делать lookup в таблице inet6.0.

- на сети у нас скорей всего уже будет включен mapping ipv4 адресов в ipv6:
set system allow-v4mapped-packets
- при передаче префиксов pe->rr должен быть настроен в политике hext-hop self. При этом для ipv6 префиксов будет подставляться mapped ipv6 адрес lo0.
rr> show route receive-protocol bgp 172.30.5.5
inet.0: 56 destinations, 58 routes (55 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 192.168.31.0/24 '''172.30.5.5''' 100 64514 I
* 192.168.32.0/24 '''172.30.5.5''' 200 64514 I
inet6.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
fd17:f0f4:f691:5::31/128
* '''::ffff:172.30.5.5''' 100 64514 I
- на rr адреса '''::ffff:172.30.5.5''' не будет, поэтому полученный префикс будет в hidden, из-за неотрезовленного next-hop. Чтобы решить эту проблему прописываем статику:
rr> show configuration routing-options
rib inet6.0 static route ::ffff:172.30.5.0/124 receive;
'''receive''' в данном случае позволяет сделать маршрут активным, не прибегая к форвардингу трафика.

- после этого рефлектор спокойно рефлектит маршрут своим клиентам.

- далее, pe получит префикс, но с принятым next-hop '''::ffff:172.30.5.5''' это префикс опять же не станет активным в таблице. Тут решение static с next-hop receive - не проканает, ибо нам нужно передавать трафик к префиксу, а не просто вставить его в таблицу маршрутизации. Тут прибегнем к варианту, который маршруты ldp для desct-ipv4 замапит в dest-ipv6 из inet.3 и поместит их в inet6.3 (для резолва ipv6 префиксов):
set protocols mpls ipv6-tunneling

rigel-r7> show route protocol ldp 172.30.5.5
'''inet.3''': 25 destinations, 32 routes (8 active, 0 holddown, 22 hidden)
'''172.30.5.5/32''' *[LDP/9] 01:17:08, metric 20
to 172.30.0.41 via ge-0/0/0.240, Push 319216
> to 172.30.0.46 via ge-0/0/3.244, Push 340912

rigel-r7> show route protocol ldp ::ffff:172.30.5.5
'''inet6.3:''' 8 destinations, 10 routes (8 active, 0 holddown, 0 hidden)
'''::ffff:172.30.5.5/128''' *[LDP/9] 01:17:20, metric 20
to 172.30.0.41 via ge-0/0/0.240, Push 319216
> to 172.30.0.46 via ge-0/0/3.244, '''Push 340912'''

ну и проверяем, что и сам префикс стал активным:
rigel-r7> show route fd17:f0f4:f691:5::31/128
inet6.0: 20 destinations, 22 routes (20 active, 0 holddown, 0 hidden)
fd17:f0f4:f691:5::31/128 *[BGP/170] 00:50:51, localpref 100, from 172.30.5.41 AS path: 64514 I
to 172.30.0.41 via ge-0/0/0.240, '''Push 2''', Push 319216(top)
> to 172.30.0.46 via ge-0/0/3.244, '''Push 2, Push 340912(top)'''

Кстати, ipv6 tunneling перетаскивает как ldp, так и rsvp маршруты в inet6.3.

=Confederations=
Описан в RFC 3065

'''Принципы'''

Цель: разбить global AS на sub-AS.
*sub-AS должна иметь уникальный номер (зачастую берут приватные AS).
*Внутри sub-AS между роутерами: full-mesh IBGP. Если внутри sub-AS будет слишком большая сеть, то в нее можно внедрить RR.
*Между sub-AS - EBGP = confederation BGP = CBGP. При прохождении маршрута через CBGP линк, роутер меняет AS path, включая туда AS sub-AS - этот метод - защита от петель. Другие атрибуты BGP не меняются.

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

==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]

confederation ''<>'' - это номер public AS.

в качестве members - определяются все AS, включенные в конфедерацию.

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

=Route damping (flapping)=
При различных обстоятельствах на сети могут возникать флапы маршрутов, что приводит к загрузке CPU на роутерах.

Чтобы избежать подобного поведения есть некоторые механизмы защиты от флапов, например: '''BGP route flap damping'''.

Damping игнорируется IBGP и работает только с EBGP и CBGP (confederation BGP).

Damping уменьшает кол-во update message, путем обозначения флапающих маршрутов непригодными стать активными маршрутами.

'''Принцип работы:'''

Когда маршрут прилетает на наш роутер (на котором настроен route damping), на префикс назначается значение merit = 0.

Как только роутер распознает некую нестабильность маршрута (префикс просто перестает долетать до роутера (или линк упал)):
*назначается merit = 1000, включается счетчик decay half-life. Если на роутер снова прилетит префикс, до того, как истечет таймер, то значение merit увеличится еще на 1000 +1000. И подобное поведение будет повторяться до превышения значения merit до supress (3000) - префикс в таком случае будет признан непригодным для использования.

После того, как префикс пропал и заново прилетел на роутер по BGP, его значение merit = 2000 (при дефолтных настройках)
Merit (last update/now): 1969/1938
Default damping parameters used
Last update: 00:00:27 First update: 00:00:49
Flaps: 2

После этого при исчезновении маршрута с роутера, его не будет видно в inet.0, но инфо можно будет посмотреть в
blair> show route damping history detail

После того, как будет превышен supress threshold, инфо о маршруте можно будет посмотреть:
blair> show route damping suppressed detail

Либо в hidden, если маршрут приходит от пира.

*если префикс передается от роутера, то он передается со значением merit = 1000.
*если изменяется path attribute, то префиксу ставится значение 500.
*decay half-life - кол-во минут после которого значение merit уменьшается вдвое, при поведении маршрута более стабильно. default = 15 min.
*max-supress - максимальное кол-во минут, которое маршрут проводит в состоянии hold-down. default = 60 min.
*reuse threshold - произвольное значение, после которого маршрут снова можно использовать. default = 750.
*supress threshold- произвольное значение, после которого маршрут больше нельзя использовать. default = 3000.
==Config==
Как только включаем на роутере damping, без заданных параметров, для работы будут использоваться дефолтные значения.

Параметры задаются через policy. '''Disable''' - для определенных префиксов удаляет merit, и убирает префикс из damping процесса (могут быть например public DNS).

set policy-options damping c11 half-life 30
set policy-options damping c11 reuse 1000
set policy-options damping c11 max-suppress 500

set policy-options policy-statement c11-damping then damping c11

set protocols bgp group c11 type external
set protocols bgp group c11 damping
set protocols bgp group c11 import c11-damping

=Blackhole=
Когда на сети определено специальное community для blackhole, и клиент посылает префикс, помеченный этим community, нужно реализовать блокировку трафика на нашей сети к этом префиксу. И желательно разослать этот префикс другим пирам и апстримам с их blackhole-community.

Блокировку трафика можно организовать несколькими способами.

1. зарулить трафик на префикс, у которого next-hop = discard.
set policy-options policy-statement blackhole from protocol bgp
set policy-options policy-statement blackhole from community blackhole
set policy-options policy-statement blackhole then next-hop 192.168.0.101
set policy-options policy-statement blackhole then accept
set routing-options static route 192.168.0.101/32 discard
set routing-options static route 192.168.0.102/32 discard

здесь без accept - видимо не происходит еще один lookup и next-hop остается unusable.
Либо resolve происходит, но с next-hop discard маршрут не считается активным и остается в hidden.

Тема discard не раскрыта :)

2. зарулить на discard interface (dsc). - подробно лучше смотреть в документации Juniper.

3. сделать у префикса сразу next-hop discard.

set policy-options policy-statement blackhole from protocol bgp
set policy-options policy-statement blackhole from community blackhole
set policy-options policy-statement blackhole then '''next-hop''' discard
set policy-options policy-statement blackhole then '''accept'''
set policy-options community blackhole members "6451[0-9]:666"

без accept маршрут будет в hidden и не передастся своим ibgp соседям. (в hidden, так как next-hop unusable)

Политику применяем на клиентов и на ibgp сессии в рамках нашей aAS (+cbgp, если используем конфедерации)

Чтобы разослать префикс другим ebgp пирам добавляем еще одну строчку в политику:
set policy-options policy-statement blackhole then community add upstream-blackhole

TIPS:
*если в политике делать только then discard - это заблочит распространение префикса на сети, что не совсем решает проблему. Через нашу сеть все-равно будет идти трафик до этого dest, просто обходными путями.
*обычно клиенты шлют /32 префиксы с blackhole-community, а на import фильтрах у уважающих себя операторов есть ограничение по длине префикса (<24).

Поэтому, чтобы получить /32, добавляем в политику условие:
set policy-options policy-statement blackhole from route-filter 0.0.0.0/0 prefix-length-range /32-/32

=BFD=
Как известно, этот механизм используется в качестве обмена hello сообщениями с заданным интервалом, ниже, чем дефолтный интервал в других протоколах. Что позволяет протоколу быстрее обнаружить падение сессии.

Сильно нагружает CPU RE, поэтому с ним сильно перебарщивать не стоит.

Хосты устанавливают сессию и обмениваются hello.

Если перестали приходить hello, то BFD дает знать протоколу, что пропала связность между хостами.

*minimum-interval - минимальный интервал получения и отправления "hello" BFD. То есть это интервал с которым локальный роутер отправляет hello и интервал, с которым локальный роутер ждет ответа на свой hello. Также в конфиге можно отдельно задать transmit и receive minimum interval.
* multiplier - значение кол-ва пропущенных hello.

set protocols bgp group upstream neighbor 1.1.1.1 bfd-liveness-detection minimum-interval 500 ''[transmit+receive]''
set protocols bgp group upstream neighbor 1.1.1.1 bfd-liveness-detection multiplier 4

или
set protocols bgp group upstream neighbor 1.1.1.1 bfd-liveness-detection minimum-receive-interval 500 ''[receive]''
set protocols bgp group upstream neighbor 1.1.1.1 bfd-liveness-detection transmit-interval minimum-interval 500 ''[transmit]''

BFD + graceful restart - не рекомендуется.

BFD + Routing Engine switchover event - не рекомендуется ниже 5000мс.

BFD + NSR - не рекомендуется ниже 2500мс.

для очень больших сетей с большим кол-вом bfd сессий - не ниже 300мс

Если значения таймеров у пиров не совпадают, то BFD использует наибольшее значение (используется режим adaptive-mode).

Это поведение по умолчанию можно выключить: no-adaptation.
set protocols bgp group upstream neighbor 1.1.1.1 bfd-liveness-detection no-adaptation

'''Проверка:'''
> show bfd session extensive

=IPv6=
Есть несколько способов настраивать BGP между роутерами, работающими с ipv6.
*Прямая ipv6 сессия на ipv6 адресах:

На интерфейсах обычные p2p адреса из /126 (/30) сеточки. Это самый примитивный вариант.
group r7-ipv6 {
type external;
export export-direct;
peer-as 54591;
neighbor fc09:c0:ffee::1;}

Настраиваем сессию на ipv6 адресах в отдельной группе. Если настраивать в группе, в которой настроены также сессии на ipv4-адресах, то сессия на ipv6 поднимется, но роутеры маршрутами обмениваться не будут.

*Сессия на ipv4 адресах, передающая ipv6 префиксы. ipv6 адреса на интерфейсах ipv4-compatible, то есть вида
a-centauri-r5> show configuration interfaces ge-0/0/0.304
description --c32;
vlan-id 304;
family inet {
address 192.168.0.13/30;}
family inet6 {
'''address ::ffff:192.168.0.13/126;'''
- сессия строится на ipv4 адресах. в группе или на neighbor настроена передача family inet6 unicast.
a-centauri-r5> show configuration protocols bgp group c31-c32
type external;
family inet unicast
family inet6 unicast
export export-ipv6
peer-as 64514
neighbor 192.168.0.10
- глобально требуется также включить:
a-centauri-r5> show configuration system
allow-v4mapped-packets
*Для IPv6 eBGP в рамках VRF нужно указывать ''routing-instance <> routing-options router-id <>''. Иначе сессия не поднимется. Будет прилетать ошибка:
May 21 00:16:05.676938 BGP RECV version 4 as 54591 holdtime 90 id '''0.0.0.0''' parmlen 30
Либо использовать отдельные lo, который будет выступать в роли router-id для сессии.
*На link-local адресах

=Дополнительная информация=
*[[OSPF]]
*[[IS-IS]]
*[[L3VPN]]

MediaWiki:Bottom-notice-ns-0

2022-02-05T13:33:06Z

Наталия Бобкова:

<div style="padding: 6px 16px; background: #f5faff; color: #333333; border: solid 1px #a1c3e6; margin-top: 30px;">
© [[Участница:Наталия_Бобкова | Наталия Бобкова]] 2014—2022 
</div>

DC

2021-12-25T19:16:32Z

Наталия Бобкова: /* Принцип работы */

{{#description2:Overlay Networks. Fabric Design. IP Fabrics. VXLAN. EVPN-VXLAN. BGP Route Types for EVPN. Distributed Layer 3 Gateway. Информация для подготовки к экзаменам Juniper.}}
=Overlay Networks=
Разделяют 2 вида сетей: overlay и underlay.

Underlay - физическая IP сеть. Это база (транспорт) поверх которого уже строится overlay netw.

Примеры underlay: MPLS, IP-сеть построенная на IGP/EGP.

Также в underlay входят bare metal servers (или могу ошибаться и это не так). Подразумевается, что underlay - это прям железо-железо в голом виде.

Overlay - это наложенная сеть на underlay. Виртуальные свитчи, серверы и другие VM соединены virt logical links (VTEPs - virtual tunnel endpoints).

*''host machine'' - сервер, на котором запущен hypervisor.
*''guest machine'' - каждая VM.
Hypervisor предоставляет OS с virt платформой для guest и далее управляет работой guest OS. Несколько разных guest OS будут делать hardware ресурсы сервера.

VXLAN - overlay technology, которая строит virt туннели на основе IP/MPLS netw (VTEPs)

VM на одном хосте будут коммуницировать между собой через virt switch - L2.
VM на разных хостах будут коммуницировать между собой через VTEP - L3. То есть прибегать к инкапсуляции L2 в L3 и передаче трафика через underlay сеть.

VTEP - располагаются на hypervisor или есть брать сервера, включенные с обычные access switches, то на свитчах тоже можно создавать VTEP. VTEP - туннель между хостами
VTEP имеет 2 iface:
*switching interface - в сторону VM
*IP interface - в сторону IP сети (L3 netw)

Для инкапсуляции используется обычно VXLAN. О нем ниже.

Положительные особенности overlay network (наложенных сетей):
# Отделение сети от физического оборудования позволяет сетям дата-центров быть развернутыми за считанные секунды.
# Поддержка L2 и L3 между VM и серверами.
# В отличие от стандартной сети поддерживает до 16,4 млн "заказчиков" (вланов).

Чем приходится платить за использование overlay network:
:- virtual tunnel endpoints (VTEPs) ипользует MAC и route. В отличие от традиционной модели, где каждая VM и каждый сервер использует MAC и route. В overlay трафик от VM и сервером инкапсулируется между VTEP. mac и route каждого сервера теперь не виден для оборудования overlay сети. mac и route теперь перенесены с физического уровня на уровень hypervisor.

=Bare metal server=
Редко в каких сетях получится найти полностью виртуализированую сеть. Какая-то часть серверов все-равно останется железной (в основном из-за производительности).

Как не бросить те самые железные сервачки и сохранить с ними сетевую связность?

Один из методов: соединить VTEP с физическим access switch.

Каждый гипервизор имеет VTEP. VTEP передает инкапсулированный трафик data plane между VM. Также VTEP делает mac-learning, предоставляет новые virt netw и другие изменения конфигурации.

На железных серверах нет VTEP. Чтобы железный сервер включить в overlay netw архитектуру, нужно чтобы кто-то инкапсулировал трафик от сервера и делал mac-learning. Пусть это делает обычный access-switch от имени сервера. Сервер при этом просто думает, что посылает от себя трафик дальше в сеть.

=Fabric Design=
*'''Traditional – MC-LAG (multichassis link aggregation group)'''
[[Файл:MC-LAG.png|мини|без]]
*'''Virtual Chassis'''
[[Файл:VC 1.png|мини|слева|top-of-rack topology]]
[[Файл:VC 2.png|мини|центр|end-of-row topology]]

*'''Virtual Chassis Fabric'''
[[Файл:VC_fabric_1.png|мини|слева|top-of-rack topology]]
[[Файл:VC fabric_2.png|мини|центр|end-of-row topology]].
Большое приемущество в том, что между каждыми двумя host в фабрике есть только 2 hops. В отличие от VC, где число hops может достигать до 9.

Limitations:
:-Virtual Chassis = 10 members
:-Virtual Chassis Fabric = 20 members [2-4 spine + 16-18 leaf]

Master + backup используют один и тот же MAC + IP для GW.

Можно легко вставлять/вытаскивать членов VC. На них автоматически будет сделан upgrade софта если нужно, подъедет конфиг, новый член будет назначен linecard.

В VC для вычисления кратчайшего пути используется Dejkstra и путь выбирается один.

В VC fabric VCCP отвчечает за эту процедуру и при возникновении нескольких равнозначных путей трафик балансируется.

Virtual Chassis Fabric works really well for a top-of-rack based solution, but for end-of-row it becomes a little more problematic.
*'''Junos Fusion'''
[[Файл:JF.png|мини|без|top-of-row topology]]

*'''IP CLOS Fabrics'''
[[Файл:CLOS.png|мини|без|finely grained failure domains]]

=IP Fabrics=
Самое важное условие для IP Fabric: VTEP должны соединяться по L3.

Clos придумал распределенную топологию для L3, при которой возможно достаточно хорошее масштабирование сети. В такой сети есть разделение на уровни: ingress, middle, egress.

На основе CLOS произошла топология spine anf leaf, которую иногда называют сложенной CLOS сетью. То ест тут ingress и egress уровни сложены друг на друга (если можно так выразиться).

Spine - это L3 свитчи.

Leaf - это top-of-the-rack свитчи, который связывают сервер и VTEP.

Масштабируемость определяется двумя параметрами: "толщиной" spine, коэффициентов переподключенийleaf светчей.

Spine L3 свитчи можно собирать в кластер, а можно и нет. Причем говорится про кластре, в котором будут и SPINE и LEAF, все вместе.

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

При фабрике без VChassis емкость рассчитывается как умножение кол-во портов под серверы на кол-во LEAF, используемых на SPINE.

Пример:
При использовании такого оборудования:
SPINE = QFX5100-24Q ['''32''' x 40GbE]
LEAF = QFX5100-96S ['''96''' x 10G + 8 x 40GbE]
получаем фабрику размерностью = (32*96) x 10GbE = 3072 x 10GbE и oversubscription ratio 3:1

==Control Plane==
Для фабрик с VChassis беспокоиться о Control Plane не приходится. Она прост работает. Но если требуется более масштабируемся сеть, то придется отойти от VChassis и подумать о ControlPlane.

В фабрике каждому LEAF потребуется отправлять и получать маршрутную инфу вместе с остальными LEAF.

В той или иной степени для ControlPlane фабрики могут подойти следующие протоколы: BGP, OSPF, ISIS. Сравним их по разным параметрам:

'''Scale + Advertise Prefixes:''' Adveritse prefixes - у всех протоколов - норм, но OSFP и ISIS флудят префиксами. Чем больше префиксов в сети, тем больше флуда. Для уменьшения флуда можно и нужно в данном случае разбивать сегменты на area. Но при этом утратятся возможности CSPF. При этом BGP специально был придуман для работы с большим кол-вом префиксов. В плане масштабируемости он значительно выигрывает!

'''Traffic engineering + traffic tagging:''' иногда нужно управлять трафиком в фабриках, например, чтобы пустить его в обход какого-то SPINE. Тут понятно, что OSPF и ISIS сильно проигрывают. В отличие от них у BGP есть дофига атрибутов, которыми можно управлять трафиком.

'''Multivendor stability:''' Вроде и OSPF и ISIS неплохо себя должны вести, но кто знает, кто проверял. Гораздо чаще разные компании, использующие разное оборудование настраивают взаимодействие между собой именно посредством BGP. Так что именно BGP можно считать самым неприхотливым в работе в разными вендорами.

Ну в итоге для IP Fabric самый адекватный протокол - '''BGP'''.

==BGP Design==
*Using '''EBGP''' in an IP fabric: каждому свитчу свою AS. Каждый LEAF пирится с каждым SPINE. Тут все просто и понятно и красиво. И также с помощью LPF и AS-PATH можем спокойно рулить трафиком. Защита от петель, напомню в том, что при отправке префикса проверяется AS-path. Префикс не отправляется пиру, если в AS-path есть AS пира.
[[Файл:Ebgp-1.png|мини|слева|top-of-the-rack]]
[[Файл:Ebgp_2.png|мини|без|end-of-the-rack]].

*Using '''IBGP''' in an IP fabric: все свитчи в одной AS. Для получения полной маршрутной информации - full mesh. Ну или более разумно использовать route reflector (или conederation - реже). RR втискиваем в уровень SPINE. Делаем пару RR, для резервирования. Все нормально НО! при таком раскладе не выйдет делать балансировку (использовать multipath), т.к. RR выбирает и отдает своим пирам только лучший маршрут. Для восстановления справедливости потребуется заморочиться с AddPath на RR (draft-ietf-idr-add-paths). Плюсом IBGP считается еще защита от петель: имеется ввиду, что IBGP пиры при любом раскладе не будут флудить префиксами.
[[Файл:Ibgp_1.png|мини|слева|top-of-the-rack]]
[[Файл:Ibgp_2.png|мини|без|end-of-the-rack]].

[[Файл:IBGP-eBGP CLOS.png|750px|без]]
ECMP - equal-cost multi-path - технология, когда один поток (один source + один dest) передается между двумя равнозначными линками. Подразумевается включение обычной балансировки, то есть:
protocols {
bgp {
group CLOS {
...
multipath multiple-as;

policy-options {
policy-statement PFE-LB {
then {
load-balance per-packet;

routing-options {
forwarding-table {
export PFE-LB;

Хорошей практикой для IP Fabric также считается использование следующих фич:
protocols {
bgp {
log-updown;
graceful-restart;
group CLOS {
mtu-discovery;
bfd-liveness-detection {
minimum-interval 350;
multiplier 3;
session-mode single-hop;
Подробно на каждой из них в этой главе останавливаться не буду.

==Requirements==
Для того, чтобы построить IP Fabric с BGP, придерживайтесь следующих требований:
*Base IP prefix. Один пул адресов для служебных целей (p2p, loopback, ...). Лучше сразу прикинуть размеры фабрики и выделить достаточный пул адресов.
*P2P network. Экономно и удобно использовать /31.
*P2P addresses. Удобно, когда при построении фабрики придерживаются одного принципа назначение ip. Первый - не spine, второй - на leaf.
*Loopback. Выделить из большого пула. Лучше использовать loopback, это облегчает диагностику.
*Server facing network. Сеть для сервачков. Leaf выступает как шлюз. Все зависит от масштабов фабрики, но понятно, что будет удобно использовать, например: /24 на один leaf, в ней работают только сервера, включенные к этому leaf. В фабрике 8 leaf, соответственно можно выделить 8*/24 = /21 сеть на фабрику. Подразумевается, что server facing netw и base ip netw - разные.
*AS num. Для каждого свитча (SPINE или LEAF) отдельная AS num - для работы EBGP. Выбор использовать 32-bit/16-bit. '''16-bit''': диапазон приватных: 64512 - 65535 то есть 1023 шт, то есть максимум 1023 свитчей в фабрике. Если этого мало, то можно переходить либо в public диапазон, либо на 32-bit AS num.
*BGP export. LEAF передает свой loopback и server facing netw.
*BGP import. Разрешаем только Base IP prefix и Server facing network.
*ECMP. Включаем load balancing на SPINE и LEAF.

==Edge connect==
Речь про связность с внешним миром и фабриками в других локациях, если такие есть.

В идеальном мире каждый дата-центр с IP Fabric должен:
*на всех фабриках иметь одинаковую структуру и даже распределение AS.
*иметь 2 edge роутера с уникальными AS num.
*быть подключенным к двум разным ISP.
*быть подключенным в внутренней MPLS сети.

Одинаковые AS num внутри фабрик разных дата-центров могут немного вводить в смятение. Можно с edge роутеров просто анонсировать агрегат своей фабрики.

Для ISP подключения: edge роутер к IP Fabric передает default, к ISP передает агрегаты фабрик. Все остальное - reject. От ISP на Edge лучше получать full view.

=VXLAN=
Virtual Extensible LAN protocol (VXLAN) инкапсулирует L2 Ethernet frame в L3 UDP packets.
*Позволяет использовать бОльшее кол-во вланов.
*Пригоден для огромных сетей облаков и ДЦ с большим кол-вом клиентов.
*Можно мигрировать VM через туннелирование трафика в L3, даже если VM включены в разные L2-домены. Это позволяет использовать ресурсы сети не учитывать границы L2. Также использование VXLAN убирает необходимость создавать огромные (в том числе по географии) L2-домены.
*Использование VXLAN дает возможность отказаться от STP и использовать более надежные и развитые протоколы маршрутизации для быстрой сходимости сети. Отсутствие STP дает возможность использовать полную пропускную способность сети (нет заблокированных портов).
*Использование L3 между L2-доменами дает возможность эффективнее балансировать трафик и опять же использовать максимально возможную пропускную способность.

MX series и EX9200: поддерживают до 32 000 VXLAN, 32 000 multicast groups, 8 000 VTEP (virtual tunnel endpoint). Это позволяет использовать MX для очень больших сетей.

QFX10000 поддерживают до 4000 VXLANs, 2000 VTEPs.

QFX5100, QFX5110, QFX5200, QFX5210, EX4600 поддерживают до 4000 VXLANs, до 2000 remote VTEPs.

EX4300-48MP поддреживают до 4000 VXLANs.

Более подробно можно узнать на сайте производителя.

==Принцип работы==
VXLAN инкапсулирует Ethernet-frame (L2) в UDP-пакет (L3). Из-за такой инкапсуляции VXLAN считают overlay технологией.

Свитчи или роутеры, которые используют VXLAN называются VTEP (virtual tunnel endpoints).

VTEPs инкапсулируют и декапсулирует VXLAN-трафик на входе и выходе из VXLAN-туннеля.

В случае, когда hardware сервер включается напрямую в Juniper и сам не умеет создавать VXLAN туннели: в качестве VTEP выступают свитчи или маршрутизаторы Juniper.

В случае с VM (virtual machine), гипервизор будет участвовать в роли VTEP, сам создавать VXLAN tunnel, а Juniper будет транзитным девайсом.

[[Файл:VXLAN пакет.png|600px|центр]]
Во время инкапсуляции VTEP добавляет к фрейму поля:
:- outer MAC dst MAC (mac endpoint VTEP)
:- outer MAC src MAC (mac source VTEP)
:- outer dst IP
:- outer src IP
:- outer UDP header
:- VXLAN header: 24-битное поле VNI (VXLAN netw indentifier), уникально идентифицирующее VXLAN. Похоже на VLANID, только побольше.

Передаем frame от VM1 к Server1.
[[Файл:VTEP аппаратный и програмный.png|600px|центр]]
#VTEP3 получает Eth-frame от VM1 (с dst addr Server1).
#В Forwarding Table уже есть изученный mac-add Server1 + инфа об исх интерфейсе (VTEP)
#VTEP3 добавляет заголовок VXLAN, который содержит VNI. VTEP3 инкапсулирует Eth-frame в UDP-пакет (L3).
#VTE3 маршрутизирует пакет через underlay L3-сеть к VTEP1.
#VTEP1 делает декапсуляцию и отдает Eth-frame к Server1.

VM и сервера при этом ничего не знают про VXLAN и протоколы на L3. Для серверов всё выглядит, как-будто они сидят в одном L2-домене.

{{note|text=VXLAN добавляет 50-54 дополнительных bytes! В ответ потребуется увеличить MTU на underlay. А именно на интерфейсах, которые участвуют в VXLAN сети, а не на логическом src VTEP interface.}}

==Learning==
*''Как VTEPs будут находить друг друга?''

Есть 2 способа обнаружения:
*data plane learning [like ethernet switch = L2 learning]
*control plane learning

*''Как будет обрабатываться BUM traffic [broadcast, unknown unicast, multicast]:''
'''Multicast''' - common solution, когда каждому VNI приравнивается какая-то multicast group. На underlay сети должен быть развернут mcast. :) [для лабы достаточно просто добавить pim на iface и назначить anycast RP].

VTEP знает какой VNI (mcast group) у него => шлет igmp-join, чтобы подписаться в домен этого VNI. Когда какой-то VTEP шлет пакет с dest mcast, остальные VTEP его получают.

Когда VTEP должен отправить BUM traffic, он шлет его с dest ip = mcast address.

===Data plane Learning [L2 learning | Flooding learning]===
Когда VTEP получает пакет, он записывает в fw table:
*IP-source VTEP
*MAC VM
*VNI
Когда приходит пакет с назначением к этой VM в этом же VNI, то VTEP уже будет знать что делать.

Если dest mac - не известен, то VTEP начинает флудить, вдруг кто другой знает такой адрес. Но чтобы уменьшить флуд, каждому VNI будет соответствовать своя multicast группа. И флуд будет распространен только в рамках этой группы.

Пример: 2 VM на разных хостах.

VNI 100 = mcast group: 239.1.1.100.

#VM1 шлет arp-request к VM2 (who has 192.168.0.11?)
#VTEP1 инкапсулирует в arp-request в mcast packet и шлет пакет к mcast group 239.1.1.100.
#Все VTEP в группе 239.1.1.100 получают пакет, декапсулируют его проверяет VNI. Если совпадает, то шлет arp в VXLAN сегмент, если не совпадает, то дропает пакет. При этом локальный VTEP также добавляет инфу: IP VTEP1 <> MAC VM1 в свою локальную VXLAN table.
#VM2 получила arp и ответила на него, раскрыв свой MAC.
#VTEP2 инкапсулировала ответ и передала его к VTEP1.
#VTEP1 получила arp-response, декапсулировала и отдала его VM1. И еще записала в VXLAN table IP VTEP2 <> MAC VM2.
#Далее VM1 и VM2 общаются via unicast.

Можно для нескольких VNI назначать одну группу. VTEP все-равно при передаче пакета проверяет VNI, а флуд при этом все-равно уменьшится.

Подходит только для девайсов, находящихся в одном L2 домене - это главный минус такой системы.

Кстати, VTEP не поддерживают аутентификацию, поэтому злоумышленник запросто может вторгнуться в ваш домен. Поэтому рекомендовано все-же использовать control plane learning.

===Control plane learning [BGP-EVPN]===
Подразумевается, что switches learning делается до того, как начинается процесс передачи трафика. Работает аналогично протоколам маршрутизации.

Свитчи пирятся по BGP и делятся своими префиксами. Для обмена используется evpn family.

Некоторые свитчи будут иметь VTEPs и понятно, что по BGP проанонсятся их адреса.

В control plane learning и VTEP появляется "аутентификация". Когда адреса VTP анонсятся по BGP, они также заносятся в white list. Когда кто-то левый захочет приконнектиться - он не сможет этого сделать до тех пор, пока он не появится в white-list.

VM MAC добавляются в процесс BGP. Соответственно, когда одна VM передает другой фрейм, роутинг к нужному хосту происходит на основании BGP. {это все подробно описано в EVPN}

При использовании control plane learning - появляется и arp suppression. VM посылает ARP-req, который доходит до свитча. А свитч уже по BGP знает соответствие IP<>mac, и отдает mac удаленной VM.

Для BUM трафика советуют также использовать Multicast, как хорошо масштабируемый.

==VXLAN Routing==
Заставляем общаться разные VNI при помощи L3 gateway.

L3 gateway можно делать как на LEAF, так и на SPINE.

Могут использоваться: L2VNI, L3VNI.

'''L2VNI''': для бриджей. То есть когда трафик остается внутри одного LAN-сегмента.

'''L3VNI''': для роутинга. То есть когда трафик должен выйти за переделы LAN. L3VNI опциональны, но если хотите роутить на локальном свитче - придется воспользоваться.

VTEPs должны знать только про локальные L2VNI, которые они локально обслуживают. С другой стороны ВСЕ VTEPs должны знать обо всех L3VNI, что называется '''anycast gateway'''.

В этом случает каждый свитч - это GW в VNI [10.1.1.1]. На соседнем физическом свитче с тем же VNI настраивается такой же адрес шлюза [10.1.1.1]. И все свитчи в этом VNI будут иметь одинаковый virt mac-add для шлюза. Это приемущество по сравнению с VRRP/HSRP в том, что: не нужны какие-то таймеры или hello-massages для синхронизации между двумя свитчами.

То есть для одного VNI, все VM, которые ему принадлежат - имеют один и тот же шлюз! Все зависимости от того к какому свитчу физически включен сервер.

Это способствует быть VM - мобильной и перемещаться на другие сервачки!

L3VNI связаны с VRF. То есть один VNI = один Customer = один RD+RT.

Пример:
На одном свитче будет настроен VRF с двумя irb интерфейсами: irb.100 [10.1.100.1], irb.101 [10.1.101.1]. Каждый будет обслуживать свой L2 домен: VTEP with VLAN100, a VNI1000 и VTEP with VLAN101, a VNI1001 соответственно.

#QFX получает VXLAN пакет с outer dest ip. Декапсулирует его.
#QFX делает lookup dest mac-адреса, который = IRB VIP MAC.
#Делает L3 lookup внутри VRF для IP-dest.
#Далее делается ARP lookup для IP dest. Если есть mapping, то шлется в iface. Если нет, то выясняется куда слать by looking at the MAC table of the other VNI.
#QFX генерирует новый L2 header с dest-mac для dest server. Потом шлет инкапсулированный VXLAN к remote VTEP.

=EVPN-VXLAN=
EVPN решает две проблемы:
#MAC learning control plane for overlay networks
#the need for workload mobility. Приложениям требуется L2 для взаимодействия друг с другом. Когда речь про app в разных DC, обычным вланом не обойтись.

EVPN относится а BGP family. Он использует MP BGP для MAC learning. Благодаря этому роутеры/свитчи обрабатывают MAC как маршруты. Что позволяет использовать несколько path одновременно (без физического гашения избыточных портов).

EVPN позволяет маршрутизировать не только MAC, но и ARP (IP + MAC). В дальнейшем ARP можно будет привязать и к VLAN-tag.

По сравнению с VPLS - тут явно больше преимуществ для использования.

Немного новой терминологии для EVPN в IP Fabric:
*Ethernet Tags = VLAN-ID
*MAC-VRF = Mac-table [в EVPN можно использовать import/export policies]
*export-policy = обычная политика, которая на все изученные местные (local) mac-addr навешивает target и отправляет route к remote sites.
*import-policy = обычная политика, которая по наличию правильного target кладет route в MAC-VFR.
*RD - uniq ID, который назначается на MAC-VRF. Уникальный в пределах IP Fabric.
*RT community - навешивается на routes посредством политик. На роутерах обозначает принадлежность к той или иной routing-table.
*EVPN services = включает в себя разные vlan-mapping options.

==VLAN Services==
*'''VLAN-based service''' - один влан на весь EVPN. То есть все девайсы на всех sites работают в одном влане. Можно делать vlan-map vlan-id 1 на vlan-id 2. Когда, например на разных фабриках используются разные vlan-id. It's ok. Плюс такого метода - ограничение broadcast. Но он не сильно масштабируем.
*'''VLAN bundle service''' - в одном EVPN много разных вланов. Полезно, когда услуга одна для нескольких арендаторов. У арендаторов используются разные вланы и никак по-другому. Плюсы: удобно для конфига. Но брадакст в таком домене будет влиять на ВСЕ вланы в нем.
*'''VLAN aware service''' - тут, кажется, используются bridge-domain внутри одного EVPN instance. Каждый со своим vlan-id внутри. То есть это дает возможность использовать в ENI (EVPN instance) несколько vlan-id, но которые не будут в одном broadcast домене. При флудах будут страдать конкретные вланы.
==Data Plane==
В качестве dataplane для EVPN из близкого к теме могут быть: MPLS, VXLAN. Есть еще и другие: PBB, STT, NVGRE..

VXLAN encapsulation метод основан на VNIs, тогда ваши vlan-id 1, vlan-id 2 > vni-1, vni-2 > vxlan-1, vxlan-2 (с изученными Mac-addr) > в EVPN instance-1 с uniq RD.

===BGP Route Types for EVPN===
:-'''Ethernet Auto-Discovery (AD) Route''': когда новый свитч вступает в EVPN, он пользуется этими роутами, чтобы объявить о себе.
RD [8], _ESI [10], _ET [4], MPLS LBL [3]

Передается flag, указывающий сколько линков можно использовать для передачи.
[[Файл:EVPN routes type1.png|мини|без]]
Например, у нас один сервер включен двумя ногами в разные свитчи. Когда LEAF4 получит auto-discovery route от LEAF1 и LEAF2, то route будет вставлен в таблицу, но также, LEAF4 будет знать, что до данного сервера у него '''два''' VXLAN, которые можно использовать.

Это как раз различие в active/active links [flag set to 0] и single link [flag is set to 1].

Auto-discovery process отрабатывает намного быстрее, так как при стандартном включении в свитч при падении линка (за которым были тысячи mac-addr) таблица будет чистить эти тысячи маков гораздо дольше, чем один route, который соответствует (ассоциирован с) линку.

:-'''MAC/IP Advertisement Route''': MAC advertisement (также может передавать IP+MAC).
RD [8], ESI [10], _ET [4],
_MAC Addr Lenght [1], _MAC Addr [6],
_IP Addr Lenght [1], _IP Addr [0|4|16]
MPLS LBL1 [3]
MPLS LBL2 [0|3]

[[Файл:EVPN routes type2.png|мини|без]]

LEAF4 изучил Mac server2. Начал передавать его другим sites EVPN с соответствующим community, которое навешивается согласно export policy.

LEAF1 исходя из import policy решает принять ли маршрут. Если import policy отсутствует - это равнозначно discard.

:-'''Inclusive Multicast Ethernet Tag Route''': BUM flooding.
ET [4], IP Addr Lenght [1], Originating Router's IP Addr [4|16]

В Juniper EVPN/VXLAN свитчи поддерживают ingress replication BUM. То есть свитч получил BUM, создал unicast копии этого трафик и отправил remote sites этого EVPN.

Route информирует remote PE - как обработать BUM traffic и PMSI аттрибуты. Он определяет следует использовать PIM или PMSI и на какой dst adddr отправлять BUM traffic.

LEAF2 передает инфу, что он ждет и использует ingress replication и что LEAF1 должен использовать 4.4.4.4 как dst addr VXLAN пакетов, которые передают BUM.

:-'''Ethernet Segment Route''': ES and DF election.
_ESI [10], _IP Addr Lenght [1], _IP Addr [4|16]

Решает проблемы:
*выбор designated forwarder (DF)
*split-horizont - preventing routing loops in the routing protocol. Not to advertise route to it's origin iface.
В EVPN есть стандартные правила split-horizont:
#Локальный свитч получил BUM от сервера. Свитч перешлет BUM только серверам в том же влане и remote sites EVPN instance. Но не обратно в интерфейс сервера, откуда он пришел.
#Свитч получи BUM от remote site. Свитч отправит BUM локальным серверам. Но не будет передавать его другим remote sites.

При использовании active/active у нас могут возникнуть проблемы и петли все-таки могут возникнуть.

Как избавиться от этого?

Для одного EVPN instance выбрать одного DF для EVPN для передачи BUM traffic. Все остальные будут дропать BUM.

:-'''IP Prefix Route''': IP route advertisement
Обычно можно увидеть при DC interconnect.

LEAF1 получил трафик от Server 1. Инкапсулировал Eth в VXLAN и отправил на EDGE router DC1 (GW for LEAF1 with irb iface).

EDGE снимет Eth header, и IP пакет смаршрутизирует согласно ip routing table.

В таблице будет route type 5, который был получен от remote PE DC2. EDGE засунет IP в VXLAN к DC2.

EDGE DC2 снимет VXLAN header, смаршрутизирует ip пакет. Засунет его в Eth заголовок с dst MAC Server 2. Отправит фрейм.

===Distributed Layer 3 Gateway===
[[Файл:EVPN gateway.png|мини|без]]

На SPINE1 и SPINE2 настроен одинаковый Virtual ip gateway address 10.0.1.254 и одинаковый Virtual MAC 00:01:8d:00:01:02.

SPINE1 и SPINE2 передают в EVPN type 1 auto-discovery и type 2 Mac+ip learning.

LEAF1 получит равнозначные по стоимости маршруты к одному MAC в том же сегменте. И начнет балансить трафик между ними.

==Design==
Как это все ляжет на сеть?

Серверы включены в LEAF в своих вланах.

VLAN связаны с VXLAN VTEP на портах свитчей.

VTEP сопоставляются в соответствующие EVPN (которые делают L2 связность для VTEP).

Как говорили выше: можно сопоставлять несколько VTEP одному EVPN instance (c one-to-one mapping или many-to-one mapping).

=Controllers=
Речь про SDN контроллеры
=Дополнительная информация=
*[[EVPN]]
*[[Traffic engineering]]
*[[Глава 1. Основы MPLS и VPN]]
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]

DC

2021-12-25T19:16:15Z

Наталия Бобкова: /* Data plane Learning [L2 learning | Flooding learning] */

{{#description2:Overlay Networks. Fabric Design. IP Fabrics. VXLAN. EVPN-VXLAN. BGP Route Types for EVPN. Distributed Layer 3 Gateway. Информация для подготовки к экзаменам Juniper.}}
=Overlay Networks=
Разделяют 2 вида сетей: overlay и underlay.

Underlay - физическая IP сеть. Это база (транспорт) поверх которого уже строится overlay netw.

Примеры underlay: MPLS, IP-сеть построенная на IGP/EGP.

Также в underlay входят bare metal servers (или могу ошибаться и это не так). Подразумевается, что underlay - это прям железо-железо в голом виде.

Overlay - это наложенная сеть на underlay. Виртуальные свитчи, серверы и другие VM соединены virt logical links (VTEPs - virtual tunnel endpoints).

*''host machine'' - сервер, на котором запущен hypervisor.
*''guest machine'' - каждая VM.
Hypervisor предоставляет OS с virt платформой для guest и далее управляет работой guest OS. Несколько разных guest OS будут делать hardware ресурсы сервера.

VXLAN - overlay technology, которая строит virt туннели на основе IP/MPLS netw (VTEPs)

VM на одном хосте будут коммуницировать между собой через virt switch - L2.
VM на разных хостах будут коммуницировать между собой через VTEP - L3. То есть прибегать к инкапсуляции L2 в L3 и передаче трафика через underlay сеть.

VTEP - располагаются на hypervisor или есть брать сервера, включенные с обычные access switches, то на свитчах тоже можно создавать VTEP. VTEP - туннель между хостами
VTEP имеет 2 iface:
*switching interface - в сторону VM
*IP interface - в сторону IP сети (L3 netw)

Для инкапсуляции используется обычно VXLAN. О нем ниже.

Положительные особенности overlay network (наложенных сетей):
# Отделение сети от физического оборудования позволяет сетям дата-центров быть развернутыми за считанные секунды.
# Поддержка L2 и L3 между VM и серверами.
# В отличие от стандартной сети поддерживает до 16,4 млн "заказчиков" (вланов).

Чем приходится платить за использование overlay network:
:- virtual tunnel endpoints (VTEPs) ипользует MAC и route. В отличие от традиционной модели, где каждая VM и каждый сервер использует MAC и route. В overlay трафик от VM и сервером инкапсулируется между VTEP. mac и route каждого сервера теперь не виден для оборудования overlay сети. mac и route теперь перенесены с физического уровня на уровень hypervisor.

=Bare metal server=
Редко в каких сетях получится найти полностью виртуализированую сеть. Какая-то часть серверов все-равно останется железной (в основном из-за производительности).

Как не бросить те самые железные сервачки и сохранить с ними сетевую связность?

Один из методов: соединить VTEP с физическим access switch.

Каждый гипервизор имеет VTEP. VTEP передает инкапсулированный трафик data plane между VM. Также VTEP делает mac-learning, предоставляет новые virt netw и другие изменения конфигурации.

На железных серверах нет VTEP. Чтобы железный сервер включить в overlay netw архитектуру, нужно чтобы кто-то инкапсулировал трафик от сервера и делал mac-learning. Пусть это делает обычный access-switch от имени сервера. Сервер при этом просто думает, что посылает от себя трафик дальше в сеть.

=Fabric Design=
*'''Traditional – MC-LAG (multichassis link aggregation group)'''
[[Файл:MC-LAG.png|мини|без]]
*'''Virtual Chassis'''
[[Файл:VC 1.png|мини|слева|top-of-rack topology]]
[[Файл:VC 2.png|мини|центр|end-of-row topology]]

*'''Virtual Chassis Fabric'''
[[Файл:VC_fabric_1.png|мини|слева|top-of-rack topology]]
[[Файл:VC fabric_2.png|мини|центр|end-of-row topology]].
Большое приемущество в том, что между каждыми двумя host в фабрике есть только 2 hops. В отличие от VC, где число hops может достигать до 9.

Limitations:
:-Virtual Chassis = 10 members
:-Virtual Chassis Fabric = 20 members [2-4 spine + 16-18 leaf]

Master + backup используют один и тот же MAC + IP для GW.

Можно легко вставлять/вытаскивать членов VC. На них автоматически будет сделан upgrade софта если нужно, подъедет конфиг, новый член будет назначен linecard.

В VC для вычисления кратчайшего пути используется Dejkstra и путь выбирается один.

В VC fabric VCCP отвчечает за эту процедуру и при возникновении нескольких равнозначных путей трафик балансируется.

Virtual Chassis Fabric works really well for a top-of-rack based solution, but for end-of-row it becomes a little more problematic.
*'''Junos Fusion'''
[[Файл:JF.png|мини|без|top-of-row topology]]

*'''IP CLOS Fabrics'''
[[Файл:CLOS.png|мини|без|finely grained failure domains]]

=IP Fabrics=
Самое важное условие для IP Fabric: VTEP должны соединяться по L3.

Clos придумал распределенную топологию для L3, при которой возможно достаточно хорошее масштабирование сети. В такой сети есть разделение на уровни: ingress, middle, egress.

На основе CLOS произошла топология spine anf leaf, которую иногда называют сложенной CLOS сетью. То ест тут ingress и egress уровни сложены друг на друга (если можно так выразиться).

Spine - это L3 свитчи.

Leaf - это top-of-the-rack свитчи, который связывают сервер и VTEP.

Масштабируемость определяется двумя параметрами: "толщиной" spine, коэффициентов переподключенийleaf светчей.

Spine L3 свитчи можно собирать в кластер, а можно и нет. Причем говорится про кластре, в котором будут и SPINE и LEAF, все вместе.

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

При фабрике без VChassis емкость рассчитывается как умножение кол-во портов под серверы на кол-во LEAF, используемых на SPINE.

Пример:
При использовании такого оборудования:
SPINE = QFX5100-24Q ['''32''' x 40GbE]
LEAF = QFX5100-96S ['''96''' x 10G + 8 x 40GbE]
получаем фабрику размерностью = (32*96) x 10GbE = 3072 x 10GbE и oversubscription ratio 3:1

==Control Plane==
Для фабрик с VChassis беспокоиться о Control Plane не приходится. Она прост работает. Но если требуется более масштабируемся сеть, то придется отойти от VChassis и подумать о ControlPlane.

В фабрике каждому LEAF потребуется отправлять и получать маршрутную инфу вместе с остальными LEAF.

В той или иной степени для ControlPlane фабрики могут подойти следующие протоколы: BGP, OSPF, ISIS. Сравним их по разным параметрам:

'''Scale + Advertise Prefixes:''' Adveritse prefixes - у всех протоколов - норм, но OSFP и ISIS флудят префиксами. Чем больше префиксов в сети, тем больше флуда. Для уменьшения флуда можно и нужно в данном случае разбивать сегменты на area. Но при этом утратятся возможности CSPF. При этом BGP специально был придуман для работы с большим кол-вом префиксов. В плане масштабируемости он значительно выигрывает!

'''Traffic engineering + traffic tagging:''' иногда нужно управлять трафиком в фабриках, например, чтобы пустить его в обход какого-то SPINE. Тут понятно, что OSPF и ISIS сильно проигрывают. В отличие от них у BGP есть дофига атрибутов, которыми можно управлять трафиком.

'''Multivendor stability:''' Вроде и OSPF и ISIS неплохо себя должны вести, но кто знает, кто проверял. Гораздо чаще разные компании, использующие разное оборудование настраивают взаимодействие между собой именно посредством BGP. Так что именно BGP можно считать самым неприхотливым в работе в разными вендорами.

Ну в итоге для IP Fabric самый адекватный протокол - '''BGP'''.

==BGP Design==
*Using '''EBGP''' in an IP fabric: каждому свитчу свою AS. Каждый LEAF пирится с каждым SPINE. Тут все просто и понятно и красиво. И также с помощью LPF и AS-PATH можем спокойно рулить трафиком. Защита от петель, напомню в том, что при отправке префикса проверяется AS-path. Префикс не отправляется пиру, если в AS-path есть AS пира.
[[Файл:Ebgp-1.png|мини|слева|top-of-the-rack]]
[[Файл:Ebgp_2.png|мини|без|end-of-the-rack]].

*Using '''IBGP''' in an IP fabric: все свитчи в одной AS. Для получения полной маршрутной информации - full mesh. Ну или более разумно использовать route reflector (или conederation - реже). RR втискиваем в уровень SPINE. Делаем пару RR, для резервирования. Все нормально НО! при таком раскладе не выйдет делать балансировку (использовать multipath), т.к. RR выбирает и отдает своим пирам только лучший маршрут. Для восстановления справедливости потребуется заморочиться с AddPath на RR (draft-ietf-idr-add-paths). Плюсом IBGP считается еще защита от петель: имеется ввиду, что IBGP пиры при любом раскладе не будут флудить префиксами.
[[Файл:Ibgp_1.png|мини|слева|top-of-the-rack]]
[[Файл:Ibgp_2.png|мини|без|end-of-the-rack]].

[[Файл:IBGP-eBGP CLOS.png|750px|без]]
ECMP - equal-cost multi-path - технология, когда один поток (один source + один dest) передается между двумя равнозначными линками. Подразумевается включение обычной балансировки, то есть:
protocols {
bgp {
group CLOS {
...
multipath multiple-as;

policy-options {
policy-statement PFE-LB {
then {
load-balance per-packet;

routing-options {
forwarding-table {
export PFE-LB;

Хорошей практикой для IP Fabric также считается использование следующих фич:
protocols {
bgp {
log-updown;
graceful-restart;
group CLOS {
mtu-discovery;
bfd-liveness-detection {
minimum-interval 350;
multiplier 3;
session-mode single-hop;
Подробно на каждой из них в этой главе останавливаться не буду.

==Requirements==
Для того, чтобы построить IP Fabric с BGP, придерживайтесь следующих требований:
*Base IP prefix. Один пул адресов для служебных целей (p2p, loopback, ...). Лучше сразу прикинуть размеры фабрики и выделить достаточный пул адресов.
*P2P network. Экономно и удобно использовать /31.
*P2P addresses. Удобно, когда при построении фабрики придерживаются одного принципа назначение ip. Первый - не spine, второй - на leaf.
*Loopback. Выделить из большого пула. Лучше использовать loopback, это облегчает диагностику.
*Server facing network. Сеть для сервачков. Leaf выступает как шлюз. Все зависит от масштабов фабрики, но понятно, что будет удобно использовать, например: /24 на один leaf, в ней работают только сервера, включенные к этому leaf. В фабрике 8 leaf, соответственно можно выделить 8*/24 = /21 сеть на фабрику. Подразумевается, что server facing netw и base ip netw - разные.
*AS num. Для каждого свитча (SPINE или LEAF) отдельная AS num - для работы EBGP. Выбор использовать 32-bit/16-bit. '''16-bit''': диапазон приватных: 64512 - 65535 то есть 1023 шт, то есть максимум 1023 свитчей в фабрике. Если этого мало, то можно переходить либо в public диапазон, либо на 32-bit AS num.
*BGP export. LEAF передает свой loopback и server facing netw.
*BGP import. Разрешаем только Base IP prefix и Server facing network.
*ECMP. Включаем load balancing на SPINE и LEAF.

==Edge connect==
Речь про связность с внешним миром и фабриками в других локациях, если такие есть.

В идеальном мире каждый дата-центр с IP Fabric должен:
*на всех фабриках иметь одинаковую структуру и даже распределение AS.
*иметь 2 edge роутера с уникальными AS num.
*быть подключенным к двум разным ISP.
*быть подключенным в внутренней MPLS сети.

Одинаковые AS num внутри фабрик разных дата-центров могут немного вводить в смятение. Можно с edge роутеров просто анонсировать агрегат своей фабрики.

Для ISP подключения: edge роутер к IP Fabric передает default, к ISP передает агрегаты фабрик. Все остальное - reject. От ISP на Edge лучше получать full view.

=VXLAN=
Virtual Extensible LAN protocol (VXLAN) инкапсулирует L2 Ethernet frame в L3 UDP packets.
*Позволяет использовать бОльшее кол-во вланов.
*Пригоден для огромных сетей облаков и ДЦ с большим кол-вом клиентов.
*Можно мигрировать VM через туннелирование трафика в L3, даже если VM включены в разные L2-домены. Это позволяет использовать ресурсы сети не учитывать границы L2. Также использование VXLAN убирает необходимость создавать огромные (в том числе по географии) L2-домены.
*Использование VXLAN дает возможность отказаться от STP и использовать более надежные и развитые протоколы маршрутизации для быстрой сходимости сети. Отсутствие STP дает возможность использовать полную пропускную способность сети (нет заблокированных портов).
*Использование L3 между L2-доменами дает возможность эффективнее балансировать трафик и опять же использовать максимально возможную пропускную способность.

MX series и EX9200: поддерживают до 32 000 VXLAN, 32 000 multicast groups, 8 000 VTEP (virtual tunnel endpoint). Это позволяет использовать MX для очень больших сетей.

QFX10000 поддерживают до 4000 VXLANs, 2000 VTEPs.

QFX5100, QFX5110, QFX5200, QFX5210, EX4600 поддерживают до 4000 VXLANs, до 2000 remote VTEPs.

EX4300-48MP поддреживают до 4000 VXLANs.

Более подробно можно узнать на сайте производителя.

==Принцип работы==
VXLAN инкапсулирует Ethernet-frame (L2) в UDP-пакет (L3). Из-за такой инкапсуляции VXLAN считают overlay технологией.

Свитчи или роутеры, которые используют VXLAN называются VTEP (virtual tunnel endpoints).

VTEPs инкапсулируют и декапсулирует VXLAN-трафик на входе и выходе из VXLAN-туннеля.

В случае, когда hardware сервер включается напрямую в Juniper и сам не умеет создавать VXLAN туннели: в качестве VTEP выступают свитчи или маршрутизаторы Juniper.

В случае с VM (virtual machine), гипервизор будет участвовать в роли VTEP, сам создавать VXLAN tunnel, а Juniper будет транзитным девайсом.

[[Файл:VXLAN пакет.png|600px|центр]]
Во время инкапсуляции VTEP добавляет к фрейму поля:
:- outer MAC dst MAC (mac endpoint VTEP)
:- outer MAC src MAC (mac source VTEP)
:- outer dst IP
:- outer src IP
:- outer UDP header
:- VXLAN header: 24-битное поле VNI (VXLAN netw indentifier), уникально идентифицирующее VXLAN. Похоже на VLANID, только побольше.

Передаем frame от VM1 к Server1.
[[Файл:VTEP аппаратный и програмный.png|600px|центр]]
#VTEP3 получает Eth-frame от VM1 (с dst addr Server1).
#В Forwarding Table уже есть изученный mac-add Server1 + инфа об исх интерфейсе (VTEP)
#VTEP3 добавляет заголовок VXLAN, который содержит VNI. VTEP3 инкапсулирует Eth-frame в UDP-пакет (L3).
#VTE3 маршрутизирует пакет через underlay L3-сеть к VTEP1.
#VTEP1 делает деинкапсуляцию и отдает Eth-frame к Server1.

VM и сервера при этом ничего не знают про VXLAN и протоколы на L3. Для серверов всё выглядит, как-будто они сидят в одном L2-домене.

{{note|text=VXLAN добавляет 50-54 дополнительных bytes! В ответ потребуется увеличить MTU на underlay. А именно на интерфейсах, которые участвуют в VXLAN сети, а не на логическом src VTEP interface.}}

==Learning==
*''Как VTEPs будут находить друг друга?''

Есть 2 способа обнаружения:
*data plane learning [like ethernet switch = L2 learning]
*control plane learning

*''Как будет обрабатываться BUM traffic [broadcast, unknown unicast, multicast]:''
'''Multicast''' - common solution, когда каждому VNI приравнивается какая-то multicast group. На underlay сети должен быть развернут mcast. :) [для лабы достаточно просто добавить pim на iface и назначить anycast RP].

VTEP знает какой VNI (mcast group) у него => шлет igmp-join, чтобы подписаться в домен этого VNI. Когда какой-то VTEP шлет пакет с dest mcast, остальные VTEP его получают.

Когда VTEP должен отправить BUM traffic, он шлет его с dest ip = mcast address.

===Data plane Learning [L2 learning | Flooding learning]===
Когда VTEP получает пакет, он записывает в fw table:
*IP-source VTEP
*MAC VM
*VNI
Когда приходит пакет с назначением к этой VM в этом же VNI, то VTEP уже будет знать что делать.

Если dest mac - не известен, то VTEP начинает флудить, вдруг кто другой знает такой адрес. Но чтобы уменьшить флуд, каждому VNI будет соответствовать своя multicast группа. И флуд будет распространен только в рамках этой группы.

Пример: 2 VM на разных хостах.

VNI 100 = mcast group: 239.1.1.100.

#VM1 шлет arp-request к VM2 (who has 192.168.0.11?)
#VTEP1 инкапсулирует в arp-request в mcast packet и шлет пакет к mcast group 239.1.1.100.
#Все VTEP в группе 239.1.1.100 получают пакет, декапсулируют его проверяет VNI. Если совпадает, то шлет arp в VXLAN сегмент, если не совпадает, то дропает пакет. При этом локальный VTEP также добавляет инфу: IP VTEP1 <> MAC VM1 в свою локальную VXLAN table.
#VM2 получила arp и ответила на него, раскрыв свой MAC.
#VTEP2 инкапсулировала ответ и передала его к VTEP1.
#VTEP1 получила arp-response, декапсулировала и отдала его VM1. И еще записала в VXLAN table IP VTEP2 <> MAC VM2.
#Далее VM1 и VM2 общаются via unicast.

Можно для нескольких VNI назначать одну группу. VTEP все-равно при передаче пакета проверяет VNI, а флуд при этом все-равно уменьшится.

Подходит только для девайсов, находящихся в одном L2 домене - это главный минус такой системы.

Кстати, VTEP не поддерживают аутентификацию, поэтому злоумышленник запросто может вторгнуться в ваш домен. Поэтому рекомендовано все-же использовать control plane learning.

===Control plane learning [BGP-EVPN]===
Подразумевается, что switches learning делается до того, как начинается процесс передачи трафика. Работает аналогично протоколам маршрутизации.

Свитчи пирятся по BGP и делятся своими префиксами. Для обмена используется evpn family.

Некоторые свитчи будут иметь VTEPs и понятно, что по BGP проанонсятся их адреса.

В control plane learning и VTEP появляется "аутентификация". Когда адреса VTP анонсятся по BGP, они также заносятся в white list. Когда кто-то левый захочет приконнектиться - он не сможет этого сделать до тех пор, пока он не появится в white-list.

VM MAC добавляются в процесс BGP. Соответственно, когда одна VM передает другой фрейм, роутинг к нужному хосту происходит на основании BGP. {это все подробно описано в EVPN}

При использовании control plane learning - появляется и arp suppression. VM посылает ARP-req, который доходит до свитча. А свитч уже по BGP знает соответствие IP<>mac, и отдает mac удаленной VM.

Для BUM трафика советуют также использовать Multicast, как хорошо масштабируемый.

==VXLAN Routing==
Заставляем общаться разные VNI при помощи L3 gateway.

L3 gateway можно делать как на LEAF, так и на SPINE.

Могут использоваться: L2VNI, L3VNI.

'''L2VNI''': для бриджей. То есть когда трафик остается внутри одного LAN-сегмента.

'''L3VNI''': для роутинга. То есть когда трафик должен выйти за переделы LAN. L3VNI опциональны, но если хотите роутить на локальном свитче - придется воспользоваться.

VTEPs должны знать только про локальные L2VNI, которые они локально обслуживают. С другой стороны ВСЕ VTEPs должны знать обо всех L3VNI, что называется '''anycast gateway'''.

В этом случает каждый свитч - это GW в VNI [10.1.1.1]. На соседнем физическом свитче с тем же VNI настраивается такой же адрес шлюза [10.1.1.1]. И все свитчи в этом VNI будут иметь одинаковый virt mac-add для шлюза. Это приемущество по сравнению с VRRP/HSRP в том, что: не нужны какие-то таймеры или hello-massages для синхронизации между двумя свитчами.

То есть для одного VNI, все VM, которые ему принадлежат - имеют один и тот же шлюз! Все зависимости от того к какому свитчу физически включен сервер.

Это способствует быть VM - мобильной и перемещаться на другие сервачки!

L3VNI связаны с VRF. То есть один VNI = один Customer = один RD+RT.

Пример:
На одном свитче будет настроен VRF с двумя irb интерфейсами: irb.100 [10.1.100.1], irb.101 [10.1.101.1]. Каждый будет обслуживать свой L2 домен: VTEP with VLAN100, a VNI1000 и VTEP with VLAN101, a VNI1001 соответственно.

#QFX получает VXLAN пакет с outer dest ip. Декапсулирует его.
#QFX делает lookup dest mac-адреса, который = IRB VIP MAC.
#Делает L3 lookup внутри VRF для IP-dest.
#Далее делается ARP lookup для IP dest. Если есть mapping, то шлется в iface. Если нет, то выясняется куда слать by looking at the MAC table of the other VNI.
#QFX генерирует новый L2 header с dest-mac для dest server. Потом шлет инкапсулированный VXLAN к remote VTEP.

=EVPN-VXLAN=
EVPN решает две проблемы:
#MAC learning control plane for overlay networks
#the need for workload mobility. Приложениям требуется L2 для взаимодействия друг с другом. Когда речь про app в разных DC, обычным вланом не обойтись.

EVPN относится а BGP family. Он использует MP BGP для MAC learning. Благодаря этому роутеры/свитчи обрабатывают MAC как маршруты. Что позволяет использовать несколько path одновременно (без физического гашения избыточных портов).

EVPN позволяет маршрутизировать не только MAC, но и ARP (IP + MAC). В дальнейшем ARP можно будет привязать и к VLAN-tag.

По сравнению с VPLS - тут явно больше преимуществ для использования.

Немного новой терминологии для EVPN в IP Fabric:
*Ethernet Tags = VLAN-ID
*MAC-VRF = Mac-table [в EVPN можно использовать import/export policies]
*export-policy = обычная политика, которая на все изученные местные (local) mac-addr навешивает target и отправляет route к remote sites.
*import-policy = обычная политика, которая по наличию правильного target кладет route в MAC-VFR.
*RD - uniq ID, который назначается на MAC-VRF. Уникальный в пределах IP Fabric.
*RT community - навешивается на routes посредством политик. На роутерах обозначает принадлежность к той или иной routing-table.
*EVPN services = включает в себя разные vlan-mapping options.

==VLAN Services==
*'''VLAN-based service''' - один влан на весь EVPN. То есть все девайсы на всех sites работают в одном влане. Можно делать vlan-map vlan-id 1 на vlan-id 2. Когда, например на разных фабриках используются разные vlan-id. It's ok. Плюс такого метода - ограничение broadcast. Но он не сильно масштабируем.
*'''VLAN bundle service''' - в одном EVPN много разных вланов. Полезно, когда услуга одна для нескольких арендаторов. У арендаторов используются разные вланы и никак по-другому. Плюсы: удобно для конфига. Но брадакст в таком домене будет влиять на ВСЕ вланы в нем.
*'''VLAN aware service''' - тут, кажется, используются bridge-domain внутри одного EVPN instance. Каждый со своим vlan-id внутри. То есть это дает возможность использовать в ENI (EVPN instance) несколько vlan-id, но которые не будут в одном broadcast домене. При флудах будут страдать конкретные вланы.
==Data Plane==
В качестве dataplane для EVPN из близкого к теме могут быть: MPLS, VXLAN. Есть еще и другие: PBB, STT, NVGRE..

VXLAN encapsulation метод основан на VNIs, тогда ваши vlan-id 1, vlan-id 2 > vni-1, vni-2 > vxlan-1, vxlan-2 (с изученными Mac-addr) > в EVPN instance-1 с uniq RD.

===BGP Route Types for EVPN===
:-'''Ethernet Auto-Discovery (AD) Route''': когда новый свитч вступает в EVPN, он пользуется этими роутами, чтобы объявить о себе.
RD [8], _ESI [10], _ET [4], MPLS LBL [3]

Передается flag, указывающий сколько линков можно использовать для передачи.
[[Файл:EVPN routes type1.png|мини|без]]
Например, у нас один сервер включен двумя ногами в разные свитчи. Когда LEAF4 получит auto-discovery route от LEAF1 и LEAF2, то route будет вставлен в таблицу, но также, LEAF4 будет знать, что до данного сервера у него '''два''' VXLAN, которые можно использовать.

Это как раз различие в active/active links [flag set to 0] и single link [flag is set to 1].

Auto-discovery process отрабатывает намного быстрее, так как при стандартном включении в свитч при падении линка (за которым были тысячи mac-addr) таблица будет чистить эти тысячи маков гораздо дольше, чем один route, который соответствует (ассоциирован с) линку.

:-'''MAC/IP Advertisement Route''': MAC advertisement (также может передавать IP+MAC).
RD [8], ESI [10], _ET [4],
_MAC Addr Lenght [1], _MAC Addr [6],
_IP Addr Lenght [1], _IP Addr [0|4|16]
MPLS LBL1 [3]
MPLS LBL2 [0|3]

[[Файл:EVPN routes type2.png|мини|без]]

LEAF4 изучил Mac server2. Начал передавать его другим sites EVPN с соответствующим community, которое навешивается согласно export policy.

LEAF1 исходя из import policy решает принять ли маршрут. Если import policy отсутствует - это равнозначно discard.

:-'''Inclusive Multicast Ethernet Tag Route''': BUM flooding.
ET [4], IP Addr Lenght [1], Originating Router's IP Addr [4|16]

В Juniper EVPN/VXLAN свитчи поддерживают ingress replication BUM. То есть свитч получил BUM, создал unicast копии этого трафик и отправил remote sites этого EVPN.

Route информирует remote PE - как обработать BUM traffic и PMSI аттрибуты. Он определяет следует использовать PIM или PMSI и на какой dst adddr отправлять BUM traffic.

LEAF2 передает инфу, что он ждет и использует ingress replication и что LEAF1 должен использовать 4.4.4.4 как dst addr VXLAN пакетов, которые передают BUM.

:-'''Ethernet Segment Route''': ES and DF election.
_ESI [10], _IP Addr Lenght [1], _IP Addr [4|16]

Решает проблемы:
*выбор designated forwarder (DF)
*split-horizont - preventing routing loops in the routing protocol. Not to advertise route to it's origin iface.
В EVPN есть стандартные правила split-horizont:
#Локальный свитч получил BUM от сервера. Свитч перешлет BUM только серверам в том же влане и remote sites EVPN instance. Но не обратно в интерфейс сервера, откуда он пришел.
#Свитч получи BUM от remote site. Свитч отправит BUM локальным серверам. Но не будет передавать его другим remote sites.

При использовании active/active у нас могут возникнуть проблемы и петли все-таки могут возникнуть.

Как избавиться от этого?

Для одного EVPN instance выбрать одного DF для EVPN для передачи BUM traffic. Все остальные будут дропать BUM.

:-'''IP Prefix Route''': IP route advertisement
Обычно можно увидеть при DC interconnect.

LEAF1 получил трафик от Server 1. Инкапсулировал Eth в VXLAN и отправил на EDGE router DC1 (GW for LEAF1 with irb iface).

EDGE снимет Eth header, и IP пакет смаршрутизирует согласно ip routing table.

В таблице будет route type 5, который был получен от remote PE DC2. EDGE засунет IP в VXLAN к DC2.

EDGE DC2 снимет VXLAN header, смаршрутизирует ip пакет. Засунет его в Eth заголовок с dst MAC Server 2. Отправит фрейм.

===Distributed Layer 3 Gateway===
[[Файл:EVPN gateway.png|мини|без]]

На SPINE1 и SPINE2 настроен одинаковый Virtual ip gateway address 10.0.1.254 и одинаковый Virtual MAC 00:01:8d:00:01:02.

SPINE1 и SPINE2 передают в EVPN type 1 auto-discovery и type 2 Mac+ip learning.

LEAF1 получит равнозначные по стоимости маршруты к одному MAC в том же сегменте. И начнет балансить трафик между ними.

==Design==
Как это все ляжет на сеть?

Серверы включены в LEAF в своих вланах.

VLAN связаны с VXLAN VTEP на портах свитчей.

VTEP сопоставляются в соответствующие EVPN (которые делают L2 связность для VTEP).

Как говорили выше: можно сопоставлять несколько VTEP одному EVPN instance (c one-to-one mapping или many-to-one mapping).

=Controllers=
Речь про SDN контроллеры
=Дополнительная информация=
*[[EVPN]]
*[[Traffic engineering]]
*[[Глава 1. Основы MPLS и VPN]]
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]

DC

2021-12-25T19:13:21Z

Наталия Бобкова: /* VXLAN Routing */

{{#description2:Overlay Networks. Fabric Design. IP Fabrics. VXLAN. EVPN-VXLAN. BGP Route Types for EVPN. Distributed Layer 3 Gateway. Информация для подготовки к экзаменам Juniper.}}
=Overlay Networks=
Разделяют 2 вида сетей: overlay и underlay.

Underlay - физическая IP сеть. Это база (транспорт) поверх которого уже строится overlay netw.

Примеры underlay: MPLS, IP-сеть построенная на IGP/EGP.

Также в underlay входят bare metal servers (или могу ошибаться и это не так). Подразумевается, что underlay - это прям железо-железо в голом виде.

Overlay - это наложенная сеть на underlay. Виртуальные свитчи, серверы и другие VM соединены virt logical links (VTEPs - virtual tunnel endpoints).

*''host machine'' - сервер, на котором запущен hypervisor.
*''guest machine'' - каждая VM.
Hypervisor предоставляет OS с virt платформой для guest и далее управляет работой guest OS. Несколько разных guest OS будут делать hardware ресурсы сервера.

VXLAN - overlay technology, которая строит virt туннели на основе IP/MPLS netw (VTEPs)

VM на одном хосте будут коммуницировать между собой через virt switch - L2.
VM на разных хостах будут коммуницировать между собой через VTEP - L3. То есть прибегать к инкапсуляции L2 в L3 и передаче трафика через underlay сеть.

VTEP - располагаются на hypervisor или есть брать сервера, включенные с обычные access switches, то на свитчах тоже можно создавать VTEP. VTEP - туннель между хостами
VTEP имеет 2 iface:
*switching interface - в сторону VM
*IP interface - в сторону IP сети (L3 netw)

Для инкапсуляции используется обычно VXLAN. О нем ниже.

Положительные особенности overlay network (наложенных сетей):
# Отделение сети от физического оборудования позволяет сетям дата-центров быть развернутыми за считанные секунды.
# Поддержка L2 и L3 между VM и серверами.
# В отличие от стандартной сети поддерживает до 16,4 млн "заказчиков" (вланов).

Чем приходится платить за использование overlay network:
:- virtual tunnel endpoints (VTEPs) ипользует MAC и route. В отличие от традиционной модели, где каждая VM и каждый сервер использует MAC и route. В overlay трафик от VM и сервером инкапсулируется между VTEP. mac и route каждого сервера теперь не виден для оборудования overlay сети. mac и route теперь перенесены с физического уровня на уровень hypervisor.

=Bare metal server=
Редко в каких сетях получится найти полностью виртуализированую сеть. Какая-то часть серверов все-равно останется железной (в основном из-за производительности).

Как не бросить те самые железные сервачки и сохранить с ними сетевую связность?

Один из методов: соединить VTEP с физическим access switch.

Каждый гипервизор имеет VTEP. VTEP передает инкапсулированный трафик data plane между VM. Также VTEP делает mac-learning, предоставляет новые virt netw и другие изменения конфигурации.

На железных серверах нет VTEP. Чтобы железный сервер включить в overlay netw архитектуру, нужно чтобы кто-то инкапсулировал трафик от сервера и делал mac-learning. Пусть это делает обычный access-switch от имени сервера. Сервер при этом просто думает, что посылает от себя трафик дальше в сеть.

=Fabric Design=
*'''Traditional – MC-LAG (multichassis link aggregation group)'''
[[Файл:MC-LAG.png|мини|без]]
*'''Virtual Chassis'''
[[Файл:VC 1.png|мини|слева|top-of-rack topology]]
[[Файл:VC 2.png|мини|центр|end-of-row topology]]

*'''Virtual Chassis Fabric'''
[[Файл:VC_fabric_1.png|мини|слева|top-of-rack topology]]
[[Файл:VC fabric_2.png|мини|центр|end-of-row topology]].
Большое приемущество в том, что между каждыми двумя host в фабрике есть только 2 hops. В отличие от VC, где число hops может достигать до 9.

Limitations:
:-Virtual Chassis = 10 members
:-Virtual Chassis Fabric = 20 members [2-4 spine + 16-18 leaf]

Master + backup используют один и тот же MAC + IP для GW.

Можно легко вставлять/вытаскивать членов VC. На них автоматически будет сделан upgrade софта если нужно, подъедет конфиг, новый член будет назначен linecard.

В VC для вычисления кратчайшего пути используется Dejkstra и путь выбирается один.

В VC fabric VCCP отвчечает за эту процедуру и при возникновении нескольких равнозначных путей трафик балансируется.

Virtual Chassis Fabric works really well for a top-of-rack based solution, but for end-of-row it becomes a little more problematic.
*'''Junos Fusion'''
[[Файл:JF.png|мини|без|top-of-row topology]]

*'''IP CLOS Fabrics'''
[[Файл:CLOS.png|мини|без|finely grained failure domains]]

=IP Fabrics=
Самое важное условие для IP Fabric: VTEP должны соединяться по L3.

Clos придумал распределенную топологию для L3, при которой возможно достаточно хорошее масштабирование сети. В такой сети есть разделение на уровни: ingress, middle, egress.

На основе CLOS произошла топология spine anf leaf, которую иногда называют сложенной CLOS сетью. То ест тут ingress и egress уровни сложены друг на друга (если можно так выразиться).

Spine - это L3 свитчи.

Leaf - это top-of-the-rack свитчи, который связывают сервер и VTEP.

Масштабируемость определяется двумя параметрами: "толщиной" spine, коэффициентов переподключенийleaf светчей.

Spine L3 свитчи можно собирать в кластер, а можно и нет. Причем говорится про кластре, в котором будут и SPINE и LEAF, все вместе.

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

При фабрике без VChassis емкость рассчитывается как умножение кол-во портов под серверы на кол-во LEAF, используемых на SPINE.

Пример:
При использовании такого оборудования:
SPINE = QFX5100-24Q ['''32''' x 40GbE]
LEAF = QFX5100-96S ['''96''' x 10G + 8 x 40GbE]
получаем фабрику размерностью = (32*96) x 10GbE = 3072 x 10GbE и oversubscription ratio 3:1

==Control Plane==
Для фабрик с VChassis беспокоиться о Control Plane не приходится. Она прост работает. Но если требуется более масштабируемся сеть, то придется отойти от VChassis и подумать о ControlPlane.

В фабрике каждому LEAF потребуется отправлять и получать маршрутную инфу вместе с остальными LEAF.

В той или иной степени для ControlPlane фабрики могут подойти следующие протоколы: BGP, OSPF, ISIS. Сравним их по разным параметрам:

'''Scale + Advertise Prefixes:''' Adveritse prefixes - у всех протоколов - норм, но OSFP и ISIS флудят префиксами. Чем больше префиксов в сети, тем больше флуда. Для уменьшения флуда можно и нужно в данном случае разбивать сегменты на area. Но при этом утратятся возможности CSPF. При этом BGP специально был придуман для работы с большим кол-вом префиксов. В плане масштабируемости он значительно выигрывает!

'''Traffic engineering + traffic tagging:''' иногда нужно управлять трафиком в фабриках, например, чтобы пустить его в обход какого-то SPINE. Тут понятно, что OSPF и ISIS сильно проигрывают. В отличие от них у BGP есть дофига атрибутов, которыми можно управлять трафиком.

'''Multivendor stability:''' Вроде и OSPF и ISIS неплохо себя должны вести, но кто знает, кто проверял. Гораздо чаще разные компании, использующие разное оборудование настраивают взаимодействие между собой именно посредством BGP. Так что именно BGP можно считать самым неприхотливым в работе в разными вендорами.

Ну в итоге для IP Fabric самый адекватный протокол - '''BGP'''.

==BGP Design==
*Using '''EBGP''' in an IP fabric: каждому свитчу свою AS. Каждый LEAF пирится с каждым SPINE. Тут все просто и понятно и красиво. И также с помощью LPF и AS-PATH можем спокойно рулить трафиком. Защита от петель, напомню в том, что при отправке префикса проверяется AS-path. Префикс не отправляется пиру, если в AS-path есть AS пира.
[[Файл:Ebgp-1.png|мини|слева|top-of-the-rack]]
[[Файл:Ebgp_2.png|мини|без|end-of-the-rack]].

*Using '''IBGP''' in an IP fabric: все свитчи в одной AS. Для получения полной маршрутной информации - full mesh. Ну или более разумно использовать route reflector (или conederation - реже). RR втискиваем в уровень SPINE. Делаем пару RR, для резервирования. Все нормально НО! при таком раскладе не выйдет делать балансировку (использовать multipath), т.к. RR выбирает и отдает своим пирам только лучший маршрут. Для восстановления справедливости потребуется заморочиться с AddPath на RR (draft-ietf-idr-add-paths). Плюсом IBGP считается еще защита от петель: имеется ввиду, что IBGP пиры при любом раскладе не будут флудить префиксами.
[[Файл:Ibgp_1.png|мини|слева|top-of-the-rack]]
[[Файл:Ibgp_2.png|мини|без|end-of-the-rack]].

[[Файл:IBGP-eBGP CLOS.png|750px|без]]
ECMP - equal-cost multi-path - технология, когда один поток (один source + один dest) передается между двумя равнозначными линками. Подразумевается включение обычной балансировки, то есть:
protocols {
bgp {
group CLOS {
...
multipath multiple-as;

policy-options {
policy-statement PFE-LB {
then {
load-balance per-packet;

routing-options {
forwarding-table {
export PFE-LB;

Хорошей практикой для IP Fabric также считается использование следующих фич:
protocols {
bgp {
log-updown;
graceful-restart;
group CLOS {
mtu-discovery;
bfd-liveness-detection {
minimum-interval 350;
multiplier 3;
session-mode single-hop;
Подробно на каждой из них в этой главе останавливаться не буду.

==Requirements==
Для того, чтобы построить IP Fabric с BGP, придерживайтесь следующих требований:
*Base IP prefix. Один пул адресов для служебных целей (p2p, loopback, ...). Лучше сразу прикинуть размеры фабрики и выделить достаточный пул адресов.
*P2P network. Экономно и удобно использовать /31.
*P2P addresses. Удобно, когда при построении фабрики придерживаются одного принципа назначение ip. Первый - не spine, второй - на leaf.
*Loopback. Выделить из большого пула. Лучше использовать loopback, это облегчает диагностику.
*Server facing network. Сеть для сервачков. Leaf выступает как шлюз. Все зависит от масштабов фабрики, но понятно, что будет удобно использовать, например: /24 на один leaf, в ней работают только сервера, включенные к этому leaf. В фабрике 8 leaf, соответственно можно выделить 8*/24 = /21 сеть на фабрику. Подразумевается, что server facing netw и base ip netw - разные.
*AS num. Для каждого свитча (SPINE или LEAF) отдельная AS num - для работы EBGP. Выбор использовать 32-bit/16-bit. '''16-bit''': диапазон приватных: 64512 - 65535 то есть 1023 шт, то есть максимум 1023 свитчей в фабрике. Если этого мало, то можно переходить либо в public диапазон, либо на 32-bit AS num.
*BGP export. LEAF передает свой loopback и server facing netw.
*BGP import. Разрешаем только Base IP prefix и Server facing network.
*ECMP. Включаем load balancing на SPINE и LEAF.

==Edge connect==
Речь про связность с внешним миром и фабриками в других локациях, если такие есть.

В идеальном мире каждый дата-центр с IP Fabric должен:
*на всех фабриках иметь одинаковую структуру и даже распределение AS.
*иметь 2 edge роутера с уникальными AS num.
*быть подключенным к двум разным ISP.
*быть подключенным в внутренней MPLS сети.

Одинаковые AS num внутри фабрик разных дата-центров могут немного вводить в смятение. Можно с edge роутеров просто анонсировать агрегат своей фабрики.

Для ISP подключения: edge роутер к IP Fabric передает default, к ISP передает агрегаты фабрик. Все остальное - reject. От ISP на Edge лучше получать full view.

=VXLAN=
Virtual Extensible LAN protocol (VXLAN) инкапсулирует L2 Ethernet frame в L3 UDP packets.
*Позволяет использовать бОльшее кол-во вланов.
*Пригоден для огромных сетей облаков и ДЦ с большим кол-вом клиентов.
*Можно мигрировать VM через туннелирование трафика в L3, даже если VM включены в разные L2-домены. Это позволяет использовать ресурсы сети не учитывать границы L2. Также использование VXLAN убирает необходимость создавать огромные (в том числе по географии) L2-домены.
*Использование VXLAN дает возможность отказаться от STP и использовать более надежные и развитые протоколы маршрутизации для быстрой сходимости сети. Отсутствие STP дает возможность использовать полную пропускную способность сети (нет заблокированных портов).
*Использование L3 между L2-доменами дает возможность эффективнее балансировать трафик и опять же использовать максимально возможную пропускную способность.

MX series и EX9200: поддерживают до 32 000 VXLAN, 32 000 multicast groups, 8 000 VTEP (virtual tunnel endpoint). Это позволяет использовать MX для очень больших сетей.

QFX10000 поддерживают до 4000 VXLANs, 2000 VTEPs.

QFX5100, QFX5110, QFX5200, QFX5210, EX4600 поддерживают до 4000 VXLANs, до 2000 remote VTEPs.

EX4300-48MP поддреживают до 4000 VXLANs.

Более подробно можно узнать на сайте производителя.

==Принцип работы==
VXLAN инкапсулирует Ethernet-frame (L2) в UDP-пакет (L3). Из-за такой инкапсуляции VXLAN считают overlay технологией.

Свитчи или роутеры, которые используют VXLAN называются VTEP (virtual tunnel endpoints).

VTEPs инкапсулируют и декапсулирует VXLAN-трафик на входе и выходе из VXLAN-туннеля.

В случае, когда hardware сервер включается напрямую в Juniper и сам не умеет создавать VXLAN туннели: в качестве VTEP выступают свитчи или маршрутизаторы Juniper.

В случае с VM (virtual machine), гипервизор будет участвовать в роли VTEP, сам создавать VXLAN tunnel, а Juniper будет транзитным девайсом.

[[Файл:VXLAN пакет.png|600px|центр]]
Во время инкапсуляции VTEP добавляет к фрейму поля:
:- outer MAC dst MAC (mac endpoint VTEP)
:- outer MAC src MAC (mac source VTEP)
:- outer dst IP
:- outer src IP
:- outer UDP header
:- VXLAN header: 24-битное поле VNI (VXLAN netw indentifier), уникально идентифицирующее VXLAN. Похоже на VLANID, только побольше.

Передаем frame от VM1 к Server1.
[[Файл:VTEP аппаратный и програмный.png|600px|центр]]
#VTEP3 получает Eth-frame от VM1 (с dst addr Server1).
#В Forwarding Table уже есть изученный mac-add Server1 + инфа об исх интерфейсе (VTEP)
#VTEP3 добавляет заголовок VXLAN, который содержит VNI. VTEP3 инкапсулирует Eth-frame в UDP-пакет (L3).
#VTE3 маршрутизирует пакет через underlay L3-сеть к VTEP1.
#VTEP1 делает деинкапсуляцию и отдает Eth-frame к Server1.

VM и сервера при этом ничего не знают про VXLAN и протоколы на L3. Для серверов всё выглядит, как-будто они сидят в одном L2-домене.

{{note|text=VXLAN добавляет 50-54 дополнительных bytes! В ответ потребуется увеличить MTU на underlay. А именно на интерфейсах, которые участвуют в VXLAN сети, а не на логическом src VTEP interface.}}

==Learning==
*''Как VTEPs будут находить друг друга?''

Есть 2 способа обнаружения:
*data plane learning [like ethernet switch = L2 learning]
*control plane learning

*''Как будет обрабатываться BUM traffic [broadcast, unknown unicast, multicast]:''
'''Multicast''' - common solution, когда каждому VNI приравнивается какая-то multicast group. На underlay сети должен быть развернут mcast. :) [для лабы достаточно просто добавить pim на iface и назначить anycast RP].

VTEP знает какой VNI (mcast group) у него => шлет igmp-join, чтобы подписаться в домен этого VNI. Когда какой-то VTEP шлет пакет с dest mcast, остальные VTEP его получают.

Когда VTEP должен отправить BUM traffic, он шлет его с dest ip = mcast address.

===Data plane Learning [L2 learning | Flooding learning]===
Когда VTEP получает пакет, он записывает в fw table:
*IP-source VTEP
*MAC VM
*VNI
Когда приходит пакет с назначением к этой VM в этом же VNI, то VTEP уже будет знать что делать.

Если dest mac - не известен, то VTEP начинает флудить, вдруг кто другой знает такой адрес. Но чтобы уменьшить флуд, каждому VNI будет соответствовать своя multicast группа. И флуд будет распространен только в рамках этой группы.

Пример: 2 VM на разных хостах.

VNI 100 = mcast group: 239.1.1.100.

#VM1 шлет arp-request к VM2 (who has 192.168.0.11?)
#VTEP1 инкапсулирует в arp-request в mcast packet и шлет пакет к mcast group 239.1.1.100.
#Все VTEP в группе 239.1.1.100 получают пакет, деинкаспулируют его проверяет VNI. Если совпадает, то шлет arp в VXLAN сегмент, если не совпадает, то дропает пакет. При этом локальный VTEP также добавляет инфу: IP VTEP1 <> MAC VM1 в свою локальную VXLAN table.
#VM2 получила arp и ответила на него, раскрыв свой MAC.
#VTEP2 инкапсулировала ответ и передала его к VTEP1.
#VTEP1 получила arp-response, деинкапсулировала и отдала его VM1. И еще записала в VXLAN table IP VTEP2 <> MAC VM2.
#Далее VM1 и VM2 общаются via unicast.

Можно для нескольких VNI назначать одну группу. VTEP все-равно при передаче пакета проверяет VNI, а флуд при этом все-равно уменьшится.

Подходит только для девайсов, находящихся в одном L2 домене - это главный минус такой системы.

Кстати, VTEP не поддерживают аутентификацию, поэтому злоумышленник запросто может вторгнуться в ваш домен. Поэтому рекомендовано все-же использовать control plane learning.

===Control plane learning [BGP-EVPN]===
Подразумевается, что switches learning делается до того, как начинается процесс передачи трафика. Работает аналогично протоколам маршрутизации.

Свитчи пирятся по BGP и делятся своими префиксами. Для обмена используется evpn family.

Некоторые свитчи будут иметь VTEPs и понятно, что по BGP проанонсятся их адреса.

В control plane learning и VTEP появляется "аутентификация". Когда адреса VTP анонсятся по BGP, они также заносятся в white list. Когда кто-то левый захочет приконнектиться - он не сможет этого сделать до тех пор, пока он не появится в white-list.

VM MAC добавляются в процесс BGP. Соответственно, когда одна VM передает другой фрейм, роутинг к нужному хосту происходит на основании BGP. {это все подробно описано в EVPN}

При использовании control plane learning - появляется и arp suppression. VM посылает ARP-req, который доходит до свитча. А свитч уже по BGP знает соответствие IP<>mac, и отдает mac удаленной VM.

Для BUM трафика советуют также использовать Multicast, как хорошо масштабируемый.

==VXLAN Routing==
Заставляем общаться разные VNI при помощи L3 gateway.

L3 gateway можно делать как на LEAF, так и на SPINE.

Могут использоваться: L2VNI, L3VNI.

'''L2VNI''': для бриджей. То есть когда трафик остается внутри одного LAN-сегмента.

'''L3VNI''': для роутинга. То есть когда трафик должен выйти за переделы LAN. L3VNI опциональны, но если хотите роутить на локальном свитче - придется воспользоваться.

VTEPs должны знать только про локальные L2VNI, которые они локально обслуживают. С другой стороны ВСЕ VTEPs должны знать обо всех L3VNI, что называется '''anycast gateway'''.

В этом случает каждый свитч - это GW в VNI [10.1.1.1]. На соседнем физическом свитче с тем же VNI настраивается такой же адрес шлюза [10.1.1.1]. И все свитчи в этом VNI будут иметь одинаковый virt mac-add для шлюза. Это приемущество по сравнению с VRRP/HSRP в том, что: не нужны какие-то таймеры или hello-massages для синхронизации между двумя свитчами.

То есть для одного VNI, все VM, которые ему принадлежат - имеют один и тот же шлюз! Все зависимости от того к какому свитчу физически включен сервер.

Это способствует быть VM - мобильной и перемещаться на другие сервачки!

L3VNI связаны с VRF. То есть один VNI = один Customer = один RD+RT.

Пример:
На одном свитче будет настроен VRF с двумя irb интерфейсами: irb.100 [10.1.100.1], irb.101 [10.1.101.1]. Каждый будет обслуживать свой L2 домен: VTEP with VLAN100, a VNI1000 и VTEP with VLAN101, a VNI1001 соответственно.

#QFX получает VXLAN пакет с outer dest ip. Декапсулирует его.
#QFX делает lookup dest mac-адреса, который = IRB VIP MAC.
#Делает L3 lookup внутри VRF для IP-dest.
#Далее делается ARP lookup для IP dest. Если есть mapping, то шлется в iface. Если нет, то выясняется куда слать by looking at the MAC table of the other VNI.
#QFX генерирует новый L2 header с dest-mac для dest server. Потом шлет инкапсулированный VXLAN к remote VTEP.

=EVPN-VXLAN=
EVPN решает две проблемы:
#MAC learning control plane for overlay networks
#the need for workload mobility. Приложениям требуется L2 для взаимодействия друг с другом. Когда речь про app в разных DC, обычным вланом не обойтись.

EVPN относится а BGP family. Он использует MP BGP для MAC learning. Благодаря этому роутеры/свитчи обрабатывают MAC как маршруты. Что позволяет использовать несколько path одновременно (без физического гашения избыточных портов).

EVPN позволяет маршрутизировать не только MAC, но и ARP (IP + MAC). В дальнейшем ARP можно будет привязать и к VLAN-tag.

По сравнению с VPLS - тут явно больше преимуществ для использования.

Немного новой терминологии для EVPN в IP Fabric:
*Ethernet Tags = VLAN-ID
*MAC-VRF = Mac-table [в EVPN можно использовать import/export policies]
*export-policy = обычная политика, которая на все изученные местные (local) mac-addr навешивает target и отправляет route к remote sites.
*import-policy = обычная политика, которая по наличию правильного target кладет route в MAC-VFR.
*RD - uniq ID, который назначается на MAC-VRF. Уникальный в пределах IP Fabric.
*RT community - навешивается на routes посредством политик. На роутерах обозначает принадлежность к той или иной routing-table.
*EVPN services = включает в себя разные vlan-mapping options.

==VLAN Services==
*'''VLAN-based service''' - один влан на весь EVPN. То есть все девайсы на всех sites работают в одном влане. Можно делать vlan-map vlan-id 1 на vlan-id 2. Когда, например на разных фабриках используются разные vlan-id. It's ok. Плюс такого метода - ограничение broadcast. Но он не сильно масштабируем.
*'''VLAN bundle service''' - в одном EVPN много разных вланов. Полезно, когда услуга одна для нескольких арендаторов. У арендаторов используются разные вланы и никак по-другому. Плюсы: удобно для конфига. Но брадакст в таком домене будет влиять на ВСЕ вланы в нем.
*'''VLAN aware service''' - тут, кажется, используются bridge-domain внутри одного EVPN instance. Каждый со своим vlan-id внутри. То есть это дает возможность использовать в ENI (EVPN instance) несколько vlan-id, но которые не будут в одном broadcast домене. При флудах будут страдать конкретные вланы.
==Data Plane==
В качестве dataplane для EVPN из близкого к теме могут быть: MPLS, VXLAN. Есть еще и другие: PBB, STT, NVGRE..

VXLAN encapsulation метод основан на VNIs, тогда ваши vlan-id 1, vlan-id 2 > vni-1, vni-2 > vxlan-1, vxlan-2 (с изученными Mac-addr) > в EVPN instance-1 с uniq RD.

===BGP Route Types for EVPN===
:-'''Ethernet Auto-Discovery (AD) Route''': когда новый свитч вступает в EVPN, он пользуется этими роутами, чтобы объявить о себе.
RD [8], _ESI [10], _ET [4], MPLS LBL [3]

Передается flag, указывающий сколько линков можно использовать для передачи.
[[Файл:EVPN routes type1.png|мини|без]]
Например, у нас один сервер включен двумя ногами в разные свитчи. Когда LEAF4 получит auto-discovery route от LEAF1 и LEAF2, то route будет вставлен в таблицу, но также, LEAF4 будет знать, что до данного сервера у него '''два''' VXLAN, которые можно использовать.

Это как раз различие в active/active links [flag set to 0] и single link [flag is set to 1].

Auto-discovery process отрабатывает намного быстрее, так как при стандартном включении в свитч при падении линка (за которым были тысячи mac-addr) таблица будет чистить эти тысячи маков гораздо дольше, чем один route, который соответствует (ассоциирован с) линку.

:-'''MAC/IP Advertisement Route''': MAC advertisement (также может передавать IP+MAC).
RD [8], ESI [10], _ET [4],
_MAC Addr Lenght [1], _MAC Addr [6],
_IP Addr Lenght [1], _IP Addr [0|4|16]
MPLS LBL1 [3]
MPLS LBL2 [0|3]

[[Файл:EVPN routes type2.png|мини|без]]

LEAF4 изучил Mac server2. Начал передавать его другим sites EVPN с соответствующим community, которое навешивается согласно export policy.

LEAF1 исходя из import policy решает принять ли маршрут. Если import policy отсутствует - это равнозначно discard.

:-'''Inclusive Multicast Ethernet Tag Route''': BUM flooding.
ET [4], IP Addr Lenght [1], Originating Router's IP Addr [4|16]

В Juniper EVPN/VXLAN свитчи поддерживают ingress replication BUM. То есть свитч получил BUM, создал unicast копии этого трафик и отправил remote sites этого EVPN.

Route информирует remote PE - как обработать BUM traffic и PMSI аттрибуты. Он определяет следует использовать PIM или PMSI и на какой dst adddr отправлять BUM traffic.

LEAF2 передает инфу, что он ждет и использует ingress replication и что LEAF1 должен использовать 4.4.4.4 как dst addr VXLAN пакетов, которые передают BUM.

:-'''Ethernet Segment Route''': ES and DF election.
_ESI [10], _IP Addr Lenght [1], _IP Addr [4|16]

Решает проблемы:
*выбор designated forwarder (DF)
*split-horizont - preventing routing loops in the routing protocol. Not to advertise route to it's origin iface.
В EVPN есть стандартные правила split-horizont:
#Локальный свитч получил BUM от сервера. Свитч перешлет BUM только серверам в том же влане и remote sites EVPN instance. Но не обратно в интерфейс сервера, откуда он пришел.
#Свитч получи BUM от remote site. Свитч отправит BUM локальным серверам. Но не будет передавать его другим remote sites.

При использовании active/active у нас могут возникнуть проблемы и петли все-таки могут возникнуть.

Как избавиться от этого?

Для одного EVPN instance выбрать одного DF для EVPN для передачи BUM traffic. Все остальные будут дропать BUM.

:-'''IP Prefix Route''': IP route advertisement
Обычно можно увидеть при DC interconnect.

LEAF1 получил трафик от Server 1. Инкапсулировал Eth в VXLAN и отправил на EDGE router DC1 (GW for LEAF1 with irb iface).

EDGE снимет Eth header, и IP пакет смаршрутизирует согласно ip routing table.

В таблице будет route type 5, который был получен от remote PE DC2. EDGE засунет IP в VXLAN к DC2.

EDGE DC2 снимет VXLAN header, смаршрутизирует ip пакет. Засунет его в Eth заголовок с dst MAC Server 2. Отправит фрейм.

===Distributed Layer 3 Gateway===
[[Файл:EVPN gateway.png|мини|без]]

На SPINE1 и SPINE2 настроен одинаковый Virtual ip gateway address 10.0.1.254 и одинаковый Virtual MAC 00:01:8d:00:01:02.

SPINE1 и SPINE2 передают в EVPN type 1 auto-discovery и type 2 Mac+ip learning.

LEAF1 получит равнозначные по стоимости маршруты к одному MAC в том же сегменте. И начнет балансить трафик между ними.

==Design==
Как это все ляжет на сеть?

Серверы включены в LEAF в своих вланах.

VLAN связаны с VXLAN VTEP на портах свитчей.

VTEP сопоставляются в соответствующие EVPN (которые делают L2 связность для VTEP).

Как говорили выше: можно сопоставлять несколько VTEP одному EVPN instance (c one-to-one mapping или many-to-one mapping).

=Controllers=
Речь про SDN контроллеры
=Дополнительная информация=
*[[EVPN]]
*[[Traffic engineering]]
*[[Глава 1. Основы MPLS и VPN]]
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]

DC

2021-12-25T19:13:05Z

Наталия Бобкова: /* VXLAN Routing */

{{#description2:Overlay Networks. Fabric Design. IP Fabrics. VXLAN. EVPN-VXLAN. BGP Route Types for EVPN. Distributed Layer 3 Gateway. Информация для подготовки к экзаменам Juniper.}}
=Overlay Networks=
Разделяют 2 вида сетей: overlay и underlay.

Underlay - физическая IP сеть. Это база (транспорт) поверх которого уже строится overlay netw.

Примеры underlay: MPLS, IP-сеть построенная на IGP/EGP.

Также в underlay входят bare metal servers (или могу ошибаться и это не так). Подразумевается, что underlay - это прям железо-железо в голом виде.

Overlay - это наложенная сеть на underlay. Виртуальные свитчи, серверы и другие VM соединены virt logical links (VTEPs - virtual tunnel endpoints).

*''host machine'' - сервер, на котором запущен hypervisor.
*''guest machine'' - каждая VM.
Hypervisor предоставляет OS с virt платформой для guest и далее управляет работой guest OS. Несколько разных guest OS будут делать hardware ресурсы сервера.

VXLAN - overlay technology, которая строит virt туннели на основе IP/MPLS netw (VTEPs)

VM на одном хосте будут коммуницировать между собой через virt switch - L2.
VM на разных хостах будут коммуницировать между собой через VTEP - L3. То есть прибегать к инкапсуляции L2 в L3 и передаче трафика через underlay сеть.

VTEP - располагаются на hypervisor или есть брать сервера, включенные с обычные access switches, то на свитчах тоже можно создавать VTEP. VTEP - туннель между хостами
VTEP имеет 2 iface:
*switching interface - в сторону VM
*IP interface - в сторону IP сети (L3 netw)

Для инкапсуляции используется обычно VXLAN. О нем ниже.

Положительные особенности overlay network (наложенных сетей):
# Отделение сети от физического оборудования позволяет сетям дата-центров быть развернутыми за считанные секунды.
# Поддержка L2 и L3 между VM и серверами.
# В отличие от стандартной сети поддерживает до 16,4 млн "заказчиков" (вланов).

Чем приходится платить за использование overlay network:
:- virtual tunnel endpoints (VTEPs) ипользует MAC и route. В отличие от традиционной модели, где каждая VM и каждый сервер использует MAC и route. В overlay трафик от VM и сервером инкапсулируется между VTEP. mac и route каждого сервера теперь не виден для оборудования overlay сети. mac и route теперь перенесены с физического уровня на уровень hypervisor.

=Bare metal server=
Редко в каких сетях получится найти полностью виртуализированую сеть. Какая-то часть серверов все-равно останется железной (в основном из-за производительности).

Как не бросить те самые железные сервачки и сохранить с ними сетевую связность?

Один из методов: соединить VTEP с физическим access switch.

Каждый гипервизор имеет VTEP. VTEP передает инкапсулированный трафик data plane между VM. Также VTEP делает mac-learning, предоставляет новые virt netw и другие изменения конфигурации.

На железных серверах нет VTEP. Чтобы железный сервер включить в overlay netw архитектуру, нужно чтобы кто-то инкапсулировал трафик от сервера и делал mac-learning. Пусть это делает обычный access-switch от имени сервера. Сервер при этом просто думает, что посылает от себя трафик дальше в сеть.

=Fabric Design=
*'''Traditional – MC-LAG (multichassis link aggregation group)'''
[[Файл:MC-LAG.png|мини|без]]
*'''Virtual Chassis'''
[[Файл:VC 1.png|мини|слева|top-of-rack topology]]
[[Файл:VC 2.png|мини|центр|end-of-row topology]]

*'''Virtual Chassis Fabric'''
[[Файл:VC_fabric_1.png|мини|слева|top-of-rack topology]]
[[Файл:VC fabric_2.png|мини|центр|end-of-row topology]].
Большое приемущество в том, что между каждыми двумя host в фабрике есть только 2 hops. В отличие от VC, где число hops может достигать до 9.

Limitations:
:-Virtual Chassis = 10 members
:-Virtual Chassis Fabric = 20 members [2-4 spine + 16-18 leaf]

Master + backup используют один и тот же MAC + IP для GW.

Можно легко вставлять/вытаскивать членов VC. На них автоматически будет сделан upgrade софта если нужно, подъедет конфиг, новый член будет назначен linecard.

В VC для вычисления кратчайшего пути используется Dejkstra и путь выбирается один.

В VC fabric VCCP отвчечает за эту процедуру и при возникновении нескольких равнозначных путей трафик балансируется.

Virtual Chassis Fabric works really well for a top-of-rack based solution, but for end-of-row it becomes a little more problematic.
*'''Junos Fusion'''
[[Файл:JF.png|мини|без|top-of-row topology]]

*'''IP CLOS Fabrics'''
[[Файл:CLOS.png|мини|без|finely grained failure domains]]

=IP Fabrics=
Самое важное условие для IP Fabric: VTEP должны соединяться по L3.

Clos придумал распределенную топологию для L3, при которой возможно достаточно хорошее масштабирование сети. В такой сети есть разделение на уровни: ingress, middle, egress.

На основе CLOS произошла топология spine anf leaf, которую иногда называют сложенной CLOS сетью. То ест тут ingress и egress уровни сложены друг на друга (если можно так выразиться).

Spine - это L3 свитчи.

Leaf - это top-of-the-rack свитчи, который связывают сервер и VTEP.

Масштабируемость определяется двумя параметрами: "толщиной" spine, коэффициентов переподключенийleaf светчей.

Spine L3 свитчи можно собирать в кластер, а можно и нет. Причем говорится про кластре, в котором будут и SPINE и LEAF, все вместе.

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

При фабрике без VChassis емкость рассчитывается как умножение кол-во портов под серверы на кол-во LEAF, используемых на SPINE.

Пример:
При использовании такого оборудования:
SPINE = QFX5100-24Q ['''32''' x 40GbE]
LEAF = QFX5100-96S ['''96''' x 10G + 8 x 40GbE]
получаем фабрику размерностью = (32*96) x 10GbE = 3072 x 10GbE и oversubscription ratio 3:1

==Control Plane==
Для фабрик с VChassis беспокоиться о Control Plane не приходится. Она прост работает. Но если требуется более масштабируемся сеть, то придется отойти от VChassis и подумать о ControlPlane.

В фабрике каждому LEAF потребуется отправлять и получать маршрутную инфу вместе с остальными LEAF.

В той или иной степени для ControlPlane фабрики могут подойти следующие протоколы: BGP, OSPF, ISIS. Сравним их по разным параметрам:

'''Scale + Advertise Prefixes:''' Adveritse prefixes - у всех протоколов - норм, но OSFP и ISIS флудят префиксами. Чем больше префиксов в сети, тем больше флуда. Для уменьшения флуда можно и нужно в данном случае разбивать сегменты на area. Но при этом утратятся возможности CSPF. При этом BGP специально был придуман для работы с большим кол-вом префиксов. В плане масштабируемости он значительно выигрывает!

'''Traffic engineering + traffic tagging:''' иногда нужно управлять трафиком в фабриках, например, чтобы пустить его в обход какого-то SPINE. Тут понятно, что OSPF и ISIS сильно проигрывают. В отличие от них у BGP есть дофига атрибутов, которыми можно управлять трафиком.

'''Multivendor stability:''' Вроде и OSPF и ISIS неплохо себя должны вести, но кто знает, кто проверял. Гораздо чаще разные компании, использующие разное оборудование настраивают взаимодействие между собой именно посредством BGP. Так что именно BGP можно считать самым неприхотливым в работе в разными вендорами.

Ну в итоге для IP Fabric самый адекватный протокол - '''BGP'''.

==BGP Design==
*Using '''EBGP''' in an IP fabric: каждому свитчу свою AS. Каждый LEAF пирится с каждым SPINE. Тут все просто и понятно и красиво. И также с помощью LPF и AS-PATH можем спокойно рулить трафиком. Защита от петель, напомню в том, что при отправке префикса проверяется AS-path. Префикс не отправляется пиру, если в AS-path есть AS пира.
[[Файл:Ebgp-1.png|мини|слева|top-of-the-rack]]
[[Файл:Ebgp_2.png|мини|без|end-of-the-rack]].

*Using '''IBGP''' in an IP fabric: все свитчи в одной AS. Для получения полной маршрутной информации - full mesh. Ну или более разумно использовать route reflector (или conederation - реже). RR втискиваем в уровень SPINE. Делаем пару RR, для резервирования. Все нормально НО! при таком раскладе не выйдет делать балансировку (использовать multipath), т.к. RR выбирает и отдает своим пирам только лучший маршрут. Для восстановления справедливости потребуется заморочиться с AddPath на RR (draft-ietf-idr-add-paths). Плюсом IBGP считается еще защита от петель: имеется ввиду, что IBGP пиры при любом раскладе не будут флудить префиксами.
[[Файл:Ibgp_1.png|мини|слева|top-of-the-rack]]
[[Файл:Ibgp_2.png|мини|без|end-of-the-rack]].

[[Файл:IBGP-eBGP CLOS.png|750px|без]]
ECMP - equal-cost multi-path - технология, когда один поток (один source + один dest) передается между двумя равнозначными линками. Подразумевается включение обычной балансировки, то есть:
protocols {
bgp {
group CLOS {
...
multipath multiple-as;

policy-options {
policy-statement PFE-LB {
then {
load-balance per-packet;

routing-options {
forwarding-table {
export PFE-LB;

Хорошей практикой для IP Fabric также считается использование следующих фич:
protocols {
bgp {
log-updown;
graceful-restart;
group CLOS {
mtu-discovery;
bfd-liveness-detection {
minimum-interval 350;
multiplier 3;
session-mode single-hop;
Подробно на каждой из них в этой главе останавливаться не буду.

==Requirements==
Для того, чтобы построить IP Fabric с BGP, придерживайтесь следующих требований:
*Base IP prefix. Один пул адресов для служебных целей (p2p, loopback, ...). Лучше сразу прикинуть размеры фабрики и выделить достаточный пул адресов.
*P2P network. Экономно и удобно использовать /31.
*P2P addresses. Удобно, когда при построении фабрики придерживаются одного принципа назначение ip. Первый - не spine, второй - на leaf.
*Loopback. Выделить из большого пула. Лучше использовать loopback, это облегчает диагностику.
*Server facing network. Сеть для сервачков. Leaf выступает как шлюз. Все зависит от масштабов фабрики, но понятно, что будет удобно использовать, например: /24 на один leaf, в ней работают только сервера, включенные к этому leaf. В фабрике 8 leaf, соответственно можно выделить 8*/24 = /21 сеть на фабрику. Подразумевается, что server facing netw и base ip netw - разные.
*AS num. Для каждого свитча (SPINE или LEAF) отдельная AS num - для работы EBGP. Выбор использовать 32-bit/16-bit. '''16-bit''': диапазон приватных: 64512 - 65535 то есть 1023 шт, то есть максимум 1023 свитчей в фабрике. Если этого мало, то можно переходить либо в public диапазон, либо на 32-bit AS num.
*BGP export. LEAF передает свой loopback и server facing netw.
*BGP import. Разрешаем только Base IP prefix и Server facing network.
*ECMP. Включаем load balancing на SPINE и LEAF.

==Edge connect==
Речь про связность с внешним миром и фабриками в других локациях, если такие есть.

В идеальном мире каждый дата-центр с IP Fabric должен:
*на всех фабриках иметь одинаковую структуру и даже распределение AS.
*иметь 2 edge роутера с уникальными AS num.
*быть подключенным к двум разным ISP.
*быть подключенным в внутренней MPLS сети.

Одинаковые AS num внутри фабрик разных дата-центров могут немного вводить в смятение. Можно с edge роутеров просто анонсировать агрегат своей фабрики.

Для ISP подключения: edge роутер к IP Fabric передает default, к ISP передает агрегаты фабрик. Все остальное - reject. От ISP на Edge лучше получать full view.

=VXLAN=
Virtual Extensible LAN protocol (VXLAN) инкапсулирует L2 Ethernet frame в L3 UDP packets.
*Позволяет использовать бОльшее кол-во вланов.
*Пригоден для огромных сетей облаков и ДЦ с большим кол-вом клиентов.
*Можно мигрировать VM через туннелирование трафика в L3, даже если VM включены в разные L2-домены. Это позволяет использовать ресурсы сети не учитывать границы L2. Также использование VXLAN убирает необходимость создавать огромные (в том числе по географии) L2-домены.
*Использование VXLAN дает возможность отказаться от STP и использовать более надежные и развитые протоколы маршрутизации для быстрой сходимости сети. Отсутствие STP дает возможность использовать полную пропускную способность сети (нет заблокированных портов).
*Использование L3 между L2-доменами дает возможность эффективнее балансировать трафик и опять же использовать максимально возможную пропускную способность.

MX series и EX9200: поддерживают до 32 000 VXLAN, 32 000 multicast groups, 8 000 VTEP (virtual tunnel endpoint). Это позволяет использовать MX для очень больших сетей.

QFX10000 поддерживают до 4000 VXLANs, 2000 VTEPs.

QFX5100, QFX5110, QFX5200, QFX5210, EX4600 поддерживают до 4000 VXLANs, до 2000 remote VTEPs.

EX4300-48MP поддреживают до 4000 VXLANs.

Более подробно можно узнать на сайте производителя.

==Принцип работы==
VXLAN инкапсулирует Ethernet-frame (L2) в UDP-пакет (L3). Из-за такой инкапсуляции VXLAN считают overlay технологией.

Свитчи или роутеры, которые используют VXLAN называются VTEP (virtual tunnel endpoints).

VTEPs инкапсулируют и декапсулирует VXLAN-трафик на входе и выходе из VXLAN-туннеля.

В случае, когда hardware сервер включается напрямую в Juniper и сам не умеет создавать VXLAN туннели: в качестве VTEP выступают свитчи или маршрутизаторы Juniper.

В случае с VM (virtual machine), гипервизор будет участвовать в роли VTEP, сам создавать VXLAN tunnel, а Juniper будет транзитным девайсом.

[[Файл:VXLAN пакет.png|600px|центр]]
Во время инкапсуляции VTEP добавляет к фрейму поля:
:- outer MAC dst MAC (mac endpoint VTEP)
:- outer MAC src MAC (mac source VTEP)
:- outer dst IP
:- outer src IP
:- outer UDP header
:- VXLAN header: 24-битное поле VNI (VXLAN netw indentifier), уникально идентифицирующее VXLAN. Похоже на VLANID, только побольше.

Передаем frame от VM1 к Server1.
[[Файл:VTEP аппаратный и програмный.png|600px|центр]]
#VTEP3 получает Eth-frame от VM1 (с dst addr Server1).
#В Forwarding Table уже есть изученный mac-add Server1 + инфа об исх интерфейсе (VTEP)
#VTEP3 добавляет заголовок VXLAN, который содержит VNI. VTEP3 инкапсулирует Eth-frame в UDP-пакет (L3).
#VTE3 маршрутизирует пакет через underlay L3-сеть к VTEP1.
#VTEP1 делает деинкапсуляцию и отдает Eth-frame к Server1.

VM и сервера при этом ничего не знают про VXLAN и протоколы на L3. Для серверов всё выглядит, как-будто они сидят в одном L2-домене.

{{note|text=VXLAN добавляет 50-54 дополнительных bytes! В ответ потребуется увеличить MTU на underlay. А именно на интерфейсах, которые участвуют в VXLAN сети, а не на логическом src VTEP interface.}}

==Learning==
*''Как VTEPs будут находить друг друга?''

Есть 2 способа обнаружения:
*data plane learning [like ethernet switch = L2 learning]
*control plane learning

*''Как будет обрабатываться BUM traffic [broadcast, unknown unicast, multicast]:''
'''Multicast''' - common solution, когда каждому VNI приравнивается какая-то multicast group. На underlay сети должен быть развернут mcast. :) [для лабы достаточно просто добавить pim на iface и назначить anycast RP].

VTEP знает какой VNI (mcast group) у него => шлет igmp-join, чтобы подписаться в домен этого VNI. Когда какой-то VTEP шлет пакет с dest mcast, остальные VTEP его получают.

Когда VTEP должен отправить BUM traffic, он шлет его с dest ip = mcast address.

===Data plane Learning [L2 learning | Flooding learning]===
Когда VTEP получает пакет, он записывает в fw table:
*IP-source VTEP
*MAC VM
*VNI
Когда приходит пакет с назначением к этой VM в этом же VNI, то VTEP уже будет знать что делать.

Если dest mac - не известен, то VTEP начинает флудить, вдруг кто другой знает такой адрес. Но чтобы уменьшить флуд, каждому VNI будет соответствовать своя multicast группа. И флуд будет распространен только в рамках этой группы.

Пример: 2 VM на разных хостах.

VNI 100 = mcast group: 239.1.1.100.

#VM1 шлет arp-request к VM2 (who has 192.168.0.11?)
#VTEP1 инкапсулирует в arp-request в mcast packet и шлет пакет к mcast group 239.1.1.100.
#Все VTEP в группе 239.1.1.100 получают пакет, деинкаспулируют его проверяет VNI. Если совпадает, то шлет arp в VXLAN сегмент, если не совпадает, то дропает пакет. При этом локальный VTEP также добавляет инфу: IP VTEP1 <> MAC VM1 в свою локальную VXLAN table.
#VM2 получила arp и ответила на него, раскрыв свой MAC.
#VTEP2 инкапсулировала ответ и передала его к VTEP1.
#VTEP1 получила arp-response, деинкапсулировала и отдала его VM1. И еще записала в VXLAN table IP VTEP2 <> MAC VM2.
#Далее VM1 и VM2 общаются via unicast.

Можно для нескольких VNI назначать одну группу. VTEP все-равно при передаче пакета проверяет VNI, а флуд при этом все-равно уменьшится.

Подходит только для девайсов, находящихся в одном L2 домене - это главный минус такой системы.

Кстати, VTEP не поддерживают аутентификацию, поэтому злоумышленник запросто может вторгнуться в ваш домен. Поэтому рекомендовано все-же использовать control plane learning.

===Control plane learning [BGP-EVPN]===
Подразумевается, что switches learning делается до того, как начинается процесс передачи трафика. Работает аналогично протоколам маршрутизации.

Свитчи пирятся по BGP и делятся своими префиксами. Для обмена используется evpn family.

Некоторые свитчи будут иметь VTEPs и понятно, что по BGP проанонсятся их адреса.

В control plane learning и VTEP появляется "аутентификация". Когда адреса VTP анонсятся по BGP, они также заносятся в white list. Когда кто-то левый захочет приконнектиться - он не сможет этого сделать до тех пор, пока он не появится в white-list.

VM MAC добавляются в процесс BGP. Соответственно, когда одна VM передает другой фрейм, роутинг к нужному хосту происходит на основании BGP. {это все подробно описано в EVPN}

При использовании control plane learning - появляется и arp suppression. VM посылает ARP-req, который доходит до свитча. А свитч уже по BGP знает соответствие IP<>mac, и отдает mac удаленной VM.

Для BUM трафика советуют также использовать Multicast, как хорошо масштабируемый.

==VXLAN Routing==
Заставляем общаться разные VNI при помощи L3 gateway.

L3 gateway можно делать как на LEAF, так и на SPINE.

Могут использоваться: L2VNI, L3VNI.

'''L2VNI''': для бриджей. То есть когда трафик остается внутри одного LAN-сегмента.

'''L3VNI''': для роутинга. То есть когда трафик должен выйти за переделы LAN. L3VNI опциональны, но если хотите роутить на локальном свитче - придется воспользоваться.

VTEPs должны знать только про локальные L2VNI, которые они локально обслуживают. С другой стороны ВСЕ VTEPs должны знать обо всех L3VNI, что называется '''anycast gateway'''.

В этом случает каждый свитч - это GW в VNI [10.1.1.1]. На соседнем физическом свитче с тем же VNI настраивается такой же адрес шлюза [10.1.1.1]. И все свитчи в этом VNI будут иметь одинаковый virt mac-add для шлюза. Это приемущество по сравнению с VRRP/HSRP в том, что: не нужны какие-то таймеры или hello-massages для синхронизации между двумя свитчами.

То есть для одного VNI, все VM, которые ему принадлежат - имеют один и тот же шлюз! Все зависимости от того к какому свитчу физически включен сервер.

Это способствует быть VM - мобильной и перемещаться на другие сервачки!

L3VNI связаны с VRF. То есть один VNI = один Customer = один RD+RT.

Пример:
На одном свитче будет настроен VRF с двумя irb интерфейсами: irb.100 [10.1.100.1], irb.101 [10.1.101.1]. Каждый будет обслуживать свой L2 домен: VTEP with VLAN100, a VNI1000 и VTEP with VLAN101, a VNI1001 соответственно.

#QFX получает VXLAN пакет с outer dest ip. Декасулирует его.
#QFX делает lookup dest mac-адреса, который = IRB VIP MAC.
#Делает L3 lookup внутри VRF для IP-dest.
#Далее делается ARP lookup для IP dest. Если есть mapping, то шлется в iface. Если нет, то выясняется куда слать by looking at the MAC table of the other VNI.
#QFX генерирует новый L2 header с dest-mac для dest server. Потом шлет инкапсулированный VXLAN к remote VTEP.

=EVPN-VXLAN=
EVPN решает две проблемы:
#MAC learning control plane for overlay networks
#the need for workload mobility. Приложениям требуется L2 для взаимодействия друг с другом. Когда речь про app в разных DC, обычным вланом не обойтись.

EVPN относится а BGP family. Он использует MP BGP для MAC learning. Благодаря этому роутеры/свитчи обрабатывают MAC как маршруты. Что позволяет использовать несколько path одновременно (без физического гашения избыточных портов).

EVPN позволяет маршрутизировать не только MAC, но и ARP (IP + MAC). В дальнейшем ARP можно будет привязать и к VLAN-tag.

По сравнению с VPLS - тут явно больше преимуществ для использования.

Немного новой терминологии для EVPN в IP Fabric:
*Ethernet Tags = VLAN-ID
*MAC-VRF = Mac-table [в EVPN можно использовать import/export policies]
*export-policy = обычная политика, которая на все изученные местные (local) mac-addr навешивает target и отправляет route к remote sites.
*import-policy = обычная политика, которая по наличию правильного target кладет route в MAC-VFR.
*RD - uniq ID, который назначается на MAC-VRF. Уникальный в пределах IP Fabric.
*RT community - навешивается на routes посредством политик. На роутерах обозначает принадлежность к той или иной routing-table.
*EVPN services = включает в себя разные vlan-mapping options.

==VLAN Services==
*'''VLAN-based service''' - один влан на весь EVPN. То есть все девайсы на всех sites работают в одном влане. Можно делать vlan-map vlan-id 1 на vlan-id 2. Когда, например на разных фабриках используются разные vlan-id. It's ok. Плюс такого метода - ограничение broadcast. Но он не сильно масштабируем.
*'''VLAN bundle service''' - в одном EVPN много разных вланов. Полезно, когда услуга одна для нескольких арендаторов. У арендаторов используются разные вланы и никак по-другому. Плюсы: удобно для конфига. Но брадакст в таком домене будет влиять на ВСЕ вланы в нем.
*'''VLAN aware service''' - тут, кажется, используются bridge-domain внутри одного EVPN instance. Каждый со своим vlan-id внутри. То есть это дает возможность использовать в ENI (EVPN instance) несколько vlan-id, но которые не будут в одном broadcast домене. При флудах будут страдать конкретные вланы.
==Data Plane==
В качестве dataplane для EVPN из близкого к теме могут быть: MPLS, VXLAN. Есть еще и другие: PBB, STT, NVGRE..

VXLAN encapsulation метод основан на VNIs, тогда ваши vlan-id 1, vlan-id 2 > vni-1, vni-2 > vxlan-1, vxlan-2 (с изученными Mac-addr) > в EVPN instance-1 с uniq RD.

===BGP Route Types for EVPN===
:-'''Ethernet Auto-Discovery (AD) Route''': когда новый свитч вступает в EVPN, он пользуется этими роутами, чтобы объявить о себе.
RD [8], _ESI [10], _ET [4], MPLS LBL [3]

Передается flag, указывающий сколько линков можно использовать для передачи.
[[Файл:EVPN routes type1.png|мини|без]]
Например, у нас один сервер включен двумя ногами в разные свитчи. Когда LEAF4 получит auto-discovery route от LEAF1 и LEAF2, то route будет вставлен в таблицу, но также, LEAF4 будет знать, что до данного сервера у него '''два''' VXLAN, которые можно использовать.

Это как раз различие в active/active links [flag set to 0] и single link [flag is set to 1].

Auto-discovery process отрабатывает намного быстрее, так как при стандартном включении в свитч при падении линка (за которым были тысячи mac-addr) таблица будет чистить эти тысячи маков гораздо дольше, чем один route, который соответствует (ассоциирован с) линку.

:-'''MAC/IP Advertisement Route''': MAC advertisement (также может передавать IP+MAC).
RD [8], ESI [10], _ET [4],
_MAC Addr Lenght [1], _MAC Addr [6],
_IP Addr Lenght [1], _IP Addr [0|4|16]
MPLS LBL1 [3]
MPLS LBL2 [0|3]

[[Файл:EVPN routes type2.png|мини|без]]

LEAF4 изучил Mac server2. Начал передавать его другим sites EVPN с соответствующим community, которое навешивается согласно export policy.

LEAF1 исходя из import policy решает принять ли маршрут. Если import policy отсутствует - это равнозначно discard.

:-'''Inclusive Multicast Ethernet Tag Route''': BUM flooding.
ET [4], IP Addr Lenght [1], Originating Router's IP Addr [4|16]

В Juniper EVPN/VXLAN свитчи поддерживают ingress replication BUM. То есть свитч получил BUM, создал unicast копии этого трафик и отправил remote sites этого EVPN.

Route информирует remote PE - как обработать BUM traffic и PMSI аттрибуты. Он определяет следует использовать PIM или PMSI и на какой dst adddr отправлять BUM traffic.

LEAF2 передает инфу, что он ждет и использует ingress replication и что LEAF1 должен использовать 4.4.4.4 как dst addr VXLAN пакетов, которые передают BUM.

:-'''Ethernet Segment Route''': ES and DF election.
_ESI [10], _IP Addr Lenght [1], _IP Addr [4|16]

Решает проблемы:
*выбор designated forwarder (DF)
*split-horizont - preventing routing loops in the routing protocol. Not to advertise route to it's origin iface.
В EVPN есть стандартные правила split-horizont:
#Локальный свитч получил BUM от сервера. Свитч перешлет BUM только серверам в том же влане и remote sites EVPN instance. Но не обратно в интерфейс сервера, откуда он пришел.
#Свитч получи BUM от remote site. Свитч отправит BUM локальным серверам. Но не будет передавать его другим remote sites.

При использовании active/active у нас могут возникнуть проблемы и петли все-таки могут возникнуть.

Как избавиться от этого?

Для одного EVPN instance выбрать одного DF для EVPN для передачи BUM traffic. Все остальные будут дропать BUM.

:-'''IP Prefix Route''': IP route advertisement
Обычно можно увидеть при DC interconnect.

LEAF1 получил трафик от Server 1. Инкапсулировал Eth в VXLAN и отправил на EDGE router DC1 (GW for LEAF1 with irb iface).

EDGE снимет Eth header, и IP пакет смаршрутизирует согласно ip routing table.

В таблице будет route type 5, который был получен от remote PE DC2. EDGE засунет IP в VXLAN к DC2.

EDGE DC2 снимет VXLAN header, смаршрутизирует ip пакет. Засунет его в Eth заголовок с dst MAC Server 2. Отправит фрейм.

===Distributed Layer 3 Gateway===
[[Файл:EVPN gateway.png|мини|без]]

На SPINE1 и SPINE2 настроен одинаковый Virtual ip gateway address 10.0.1.254 и одинаковый Virtual MAC 00:01:8d:00:01:02.

SPINE1 и SPINE2 передают в EVPN type 1 auto-discovery и type 2 Mac+ip learning.

LEAF1 получит равнозначные по стоимости маршруты к одному MAC в том же сегменте. И начнет балансить трафик между ними.

==Design==
Как это все ляжет на сеть?

Серверы включены в LEAF в своих вланах.

VLAN связаны с VXLAN VTEP на портах свитчей.

VTEP сопоставляются в соответствующие EVPN (которые делают L2 связность для VTEP).

Как говорили выше: можно сопоставлять несколько VTEP одному EVPN instance (c one-to-one mapping или many-to-one mapping).

=Controllers=
Речь про SDN контроллеры
=Дополнительная информация=
*[[EVPN]]
*[[Traffic engineering]]
*[[Глава 1. Основы MPLS и VPN]]
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]

DC

2021-12-25T19:09:12Z

Наталия Бобкова: /* Принцип работы */

{{#description2:Overlay Networks. Fabric Design. IP Fabrics. VXLAN. EVPN-VXLAN. BGP Route Types for EVPN. Distributed Layer 3 Gateway. Информация для подготовки к экзаменам Juniper.}}
=Overlay Networks=
Разделяют 2 вида сетей: overlay и underlay.

Underlay - физическая IP сеть. Это база (транспорт) поверх которого уже строится overlay netw.

Примеры underlay: MPLS, IP-сеть построенная на IGP/EGP.

Также в underlay входят bare metal servers (или могу ошибаться и это не так). Подразумевается, что underlay - это прям железо-железо в голом виде.

Overlay - это наложенная сеть на underlay. Виртуальные свитчи, серверы и другие VM соединены virt logical links (VTEPs - virtual tunnel endpoints).

*''host machine'' - сервер, на котором запущен hypervisor.
*''guest machine'' - каждая VM.
Hypervisor предоставляет OS с virt платформой для guest и далее управляет работой guest OS. Несколько разных guest OS будут делать hardware ресурсы сервера.

VXLAN - overlay technology, которая строит virt туннели на основе IP/MPLS netw (VTEPs)

VM на одном хосте будут коммуницировать между собой через virt switch - L2.
VM на разных хостах будут коммуницировать между собой через VTEP - L3. То есть прибегать к инкапсуляции L2 в L3 и передаче трафика через underlay сеть.

VTEP - располагаются на hypervisor или есть брать сервера, включенные с обычные access switches, то на свитчах тоже можно создавать VTEP. VTEP - туннель между хостами
VTEP имеет 2 iface:
*switching interface - в сторону VM
*IP interface - в сторону IP сети (L3 netw)

Для инкапсуляции используется обычно VXLAN. О нем ниже.

Положительные особенности overlay network (наложенных сетей):
# Отделение сети от физического оборудования позволяет сетям дата-центров быть развернутыми за считанные секунды.
# Поддержка L2 и L3 между VM и серверами.
# В отличие от стандартной сети поддерживает до 16,4 млн "заказчиков" (вланов).

Чем приходится платить за использование overlay network:
:- virtual tunnel endpoints (VTEPs) ипользует MAC и route. В отличие от традиционной модели, где каждая VM и каждый сервер использует MAC и route. В overlay трафик от VM и сервером инкапсулируется между VTEP. mac и route каждого сервера теперь не виден для оборудования overlay сети. mac и route теперь перенесены с физического уровня на уровень hypervisor.

=Bare metal server=
Редко в каких сетях получится найти полностью виртуализированую сеть. Какая-то часть серверов все-равно останется железной (в основном из-за производительности).

Как не бросить те самые железные сервачки и сохранить с ними сетевую связность?

Один из методов: соединить VTEP с физическим access switch.

Каждый гипервизор имеет VTEP. VTEP передает инкапсулированный трафик data plane между VM. Также VTEP делает mac-learning, предоставляет новые virt netw и другие изменения конфигурации.

На железных серверах нет VTEP. Чтобы железный сервер включить в overlay netw архитектуру, нужно чтобы кто-то инкапсулировал трафик от сервера и делал mac-learning. Пусть это делает обычный access-switch от имени сервера. Сервер при этом просто думает, что посылает от себя трафик дальше в сеть.

=Fabric Design=
*'''Traditional – MC-LAG (multichassis link aggregation group)'''
[[Файл:MC-LAG.png|мини|без]]
*'''Virtual Chassis'''
[[Файл:VC 1.png|мини|слева|top-of-rack topology]]
[[Файл:VC 2.png|мини|центр|end-of-row topology]]

*'''Virtual Chassis Fabric'''
[[Файл:VC_fabric_1.png|мини|слева|top-of-rack topology]]
[[Файл:VC fabric_2.png|мини|центр|end-of-row topology]].
Большое приемущество в том, что между каждыми двумя host в фабрике есть только 2 hops. В отличие от VC, где число hops может достигать до 9.

Limitations:
:-Virtual Chassis = 10 members
:-Virtual Chassis Fabric = 20 members [2-4 spine + 16-18 leaf]

Master + backup используют один и тот же MAC + IP для GW.

Можно легко вставлять/вытаскивать членов VC. На них автоматически будет сделан upgrade софта если нужно, подъедет конфиг, новый член будет назначен linecard.

В VC для вычисления кратчайшего пути используется Dejkstra и путь выбирается один.

В VC fabric VCCP отвчечает за эту процедуру и при возникновении нескольких равнозначных путей трафик балансируется.

Virtual Chassis Fabric works really well for a top-of-rack based solution, but for end-of-row it becomes a little more problematic.
*'''Junos Fusion'''
[[Файл:JF.png|мини|без|top-of-row topology]]

*'''IP CLOS Fabrics'''
[[Файл:CLOS.png|мини|без|finely grained failure domains]]

=IP Fabrics=
Самое важное условие для IP Fabric: VTEP должны соединяться по L3.

Clos придумал распределенную топологию для L3, при которой возможно достаточно хорошее масштабирование сети. В такой сети есть разделение на уровни: ingress, middle, egress.

На основе CLOS произошла топология spine anf leaf, которую иногда называют сложенной CLOS сетью. То ест тут ingress и egress уровни сложены друг на друга (если можно так выразиться).

Spine - это L3 свитчи.

Leaf - это top-of-the-rack свитчи, который связывают сервер и VTEP.

Масштабируемость определяется двумя параметрами: "толщиной" spine, коэффициентов переподключенийleaf светчей.

Spine L3 свитчи можно собирать в кластер, а можно и нет. Причем говорится про кластре, в котором будут и SPINE и LEAF, все вместе.

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

При фабрике без VChassis емкость рассчитывается как умножение кол-во портов под серверы на кол-во LEAF, используемых на SPINE.

Пример:
При использовании такого оборудования:
SPINE = QFX5100-24Q ['''32''' x 40GbE]
LEAF = QFX5100-96S ['''96''' x 10G + 8 x 40GbE]
получаем фабрику размерностью = (32*96) x 10GbE = 3072 x 10GbE и oversubscription ratio 3:1

==Control Plane==
Для фабрик с VChassis беспокоиться о Control Plane не приходится. Она прост работает. Но если требуется более масштабируемся сеть, то придется отойти от VChassis и подумать о ControlPlane.

В фабрике каждому LEAF потребуется отправлять и получать маршрутную инфу вместе с остальными LEAF.

В той или иной степени для ControlPlane фабрики могут подойти следующие протоколы: BGP, OSPF, ISIS. Сравним их по разным параметрам:

'''Scale + Advertise Prefixes:''' Adveritse prefixes - у всех протоколов - норм, но OSFP и ISIS флудят префиксами. Чем больше префиксов в сети, тем больше флуда. Для уменьшения флуда можно и нужно в данном случае разбивать сегменты на area. Но при этом утратятся возможности CSPF. При этом BGP специально был придуман для работы с большим кол-вом префиксов. В плане масштабируемости он значительно выигрывает!

'''Traffic engineering + traffic tagging:''' иногда нужно управлять трафиком в фабриках, например, чтобы пустить его в обход какого-то SPINE. Тут понятно, что OSPF и ISIS сильно проигрывают. В отличие от них у BGP есть дофига атрибутов, которыми можно управлять трафиком.

'''Multivendor stability:''' Вроде и OSPF и ISIS неплохо себя должны вести, но кто знает, кто проверял. Гораздо чаще разные компании, использующие разное оборудование настраивают взаимодействие между собой именно посредством BGP. Так что именно BGP можно считать самым неприхотливым в работе в разными вендорами.

Ну в итоге для IP Fabric самый адекватный протокол - '''BGP'''.

==BGP Design==
*Using '''EBGP''' in an IP fabric: каждому свитчу свою AS. Каждый LEAF пирится с каждым SPINE. Тут все просто и понятно и красиво. И также с помощью LPF и AS-PATH можем спокойно рулить трафиком. Защита от петель, напомню в том, что при отправке префикса проверяется AS-path. Префикс не отправляется пиру, если в AS-path есть AS пира.
[[Файл:Ebgp-1.png|мини|слева|top-of-the-rack]]
[[Файл:Ebgp_2.png|мини|без|end-of-the-rack]].

*Using '''IBGP''' in an IP fabric: все свитчи в одной AS. Для получения полной маршрутной информации - full mesh. Ну или более разумно использовать route reflector (или conederation - реже). RR втискиваем в уровень SPINE. Делаем пару RR, для резервирования. Все нормально НО! при таком раскладе не выйдет делать балансировку (использовать multipath), т.к. RR выбирает и отдает своим пирам только лучший маршрут. Для восстановления справедливости потребуется заморочиться с AddPath на RR (draft-ietf-idr-add-paths). Плюсом IBGP считается еще защита от петель: имеется ввиду, что IBGP пиры при любом раскладе не будут флудить префиксами.
[[Файл:Ibgp_1.png|мини|слева|top-of-the-rack]]
[[Файл:Ibgp_2.png|мини|без|end-of-the-rack]].

[[Файл:IBGP-eBGP CLOS.png|750px|без]]
ECMP - equal-cost multi-path - технология, когда один поток (один source + один dest) передается между двумя равнозначными линками. Подразумевается включение обычной балансировки, то есть:
protocols {
bgp {
group CLOS {
...
multipath multiple-as;

policy-options {
policy-statement PFE-LB {
then {
load-balance per-packet;

routing-options {
forwarding-table {
export PFE-LB;

Хорошей практикой для IP Fabric также считается использование следующих фич:
protocols {
bgp {
log-updown;
graceful-restart;
group CLOS {
mtu-discovery;
bfd-liveness-detection {
minimum-interval 350;
multiplier 3;
session-mode single-hop;
Подробно на каждой из них в этой главе останавливаться не буду.

==Requirements==
Для того, чтобы построить IP Fabric с BGP, придерживайтесь следующих требований:
*Base IP prefix. Один пул адресов для служебных целей (p2p, loopback, ...). Лучше сразу прикинуть размеры фабрики и выделить достаточный пул адресов.
*P2P network. Экономно и удобно использовать /31.
*P2P addresses. Удобно, когда при построении фабрики придерживаются одного принципа назначение ip. Первый - не spine, второй - на leaf.
*Loopback. Выделить из большого пула. Лучше использовать loopback, это облегчает диагностику.
*Server facing network. Сеть для сервачков. Leaf выступает как шлюз. Все зависит от масштабов фабрики, но понятно, что будет удобно использовать, например: /24 на один leaf, в ней работают только сервера, включенные к этому leaf. В фабрике 8 leaf, соответственно можно выделить 8*/24 = /21 сеть на фабрику. Подразумевается, что server facing netw и base ip netw - разные.
*AS num. Для каждого свитча (SPINE или LEAF) отдельная AS num - для работы EBGP. Выбор использовать 32-bit/16-bit. '''16-bit''': диапазон приватных: 64512 - 65535 то есть 1023 шт, то есть максимум 1023 свитчей в фабрике. Если этого мало, то можно переходить либо в public диапазон, либо на 32-bit AS num.
*BGP export. LEAF передает свой loopback и server facing netw.
*BGP import. Разрешаем только Base IP prefix и Server facing network.
*ECMP. Включаем load balancing на SPINE и LEAF.

==Edge connect==
Речь про связность с внешним миром и фабриками в других локациях, если такие есть.

В идеальном мире каждый дата-центр с IP Fabric должен:
*на всех фабриках иметь одинаковую структуру и даже распределение AS.
*иметь 2 edge роутера с уникальными AS num.
*быть подключенным к двум разным ISP.
*быть подключенным в внутренней MPLS сети.

Одинаковые AS num внутри фабрик разных дата-центров могут немного вводить в смятение. Можно с edge роутеров просто анонсировать агрегат своей фабрики.

Для ISP подключения: edge роутер к IP Fabric передает default, к ISP передает агрегаты фабрик. Все остальное - reject. От ISP на Edge лучше получать full view.

=VXLAN=
Virtual Extensible LAN protocol (VXLAN) инкапсулирует L2 Ethernet frame в L3 UDP packets.
*Позволяет использовать бОльшее кол-во вланов.
*Пригоден для огромных сетей облаков и ДЦ с большим кол-вом клиентов.
*Можно мигрировать VM через туннелирование трафика в L3, даже если VM включены в разные L2-домены. Это позволяет использовать ресурсы сети не учитывать границы L2. Также использование VXLAN убирает необходимость создавать огромные (в том числе по географии) L2-домены.
*Использование VXLAN дает возможность отказаться от STP и использовать более надежные и развитые протоколы маршрутизации для быстрой сходимости сети. Отсутствие STP дает возможность использовать полную пропускную способность сети (нет заблокированных портов).
*Использование L3 между L2-доменами дает возможность эффективнее балансировать трафик и опять же использовать максимально возможную пропускную способность.

MX series и EX9200: поддерживают до 32 000 VXLAN, 32 000 multicast groups, 8 000 VTEP (virtual tunnel endpoint). Это позволяет использовать MX для очень больших сетей.

QFX10000 поддерживают до 4000 VXLANs, 2000 VTEPs.

QFX5100, QFX5110, QFX5200, QFX5210, EX4600 поддерживают до 4000 VXLANs, до 2000 remote VTEPs.

EX4300-48MP поддреживают до 4000 VXLANs.

Более подробно можно узнать на сайте производителя.

==Принцип работы==
VXLAN инкапсулирует Ethernet-frame (L2) в UDP-пакет (L3). Из-за такой инкапсуляции VXLAN считают overlay технологией.

Свитчи или роутеры, которые используют VXLAN называются VTEP (virtual tunnel endpoints).

VTEPs инкапсулируют и декапсулирует VXLAN-трафик на входе и выходе из VXLAN-туннеля.

В случае, когда hardware сервер включается напрямую в Juniper и сам не умеет создавать VXLAN туннели: в качестве VTEP выступают свитчи или маршрутизаторы Juniper.

В случае с VM (virtual machine), гипервизор будет участвовать в роли VTEP, сам создавать VXLAN tunnel, а Juniper будет транзитным девайсом.

[[Файл:VXLAN пакет.png|600px|центр]]
Во время инкапсуляции VTEP добавляет к фрейму поля:
:- outer MAC dst MAC (mac endpoint VTEP)
:- outer MAC src MAC (mac source VTEP)
:- outer dst IP
:- outer src IP
:- outer UDP header
:- VXLAN header: 24-битное поле VNI (VXLAN netw indentifier), уникально идентифицирующее VXLAN. Похоже на VLANID, только побольше.

Передаем frame от VM1 к Server1.
[[Файл:VTEP аппаратный и програмный.png|600px|центр]]
#VTEP3 получает Eth-frame от VM1 (с dst addr Server1).
#В Forwarding Table уже есть изученный mac-add Server1 + инфа об исх интерфейсе (VTEP)
#VTEP3 добавляет заголовок VXLAN, который содержит VNI. VTEP3 инкапсулирует Eth-frame в UDP-пакет (L3).
#VTE3 маршрутизирует пакет через underlay L3-сеть к VTEP1.
#VTEP1 делает деинкапсуляцию и отдает Eth-frame к Server1.

VM и сервера при этом ничего не знают про VXLAN и протоколы на L3. Для серверов всё выглядит, как-будто они сидят в одном L2-домене.

{{note|text=VXLAN добавляет 50-54 дополнительных bytes! В ответ потребуется увеличить MTU на underlay. А именно на интерфейсах, которые участвуют в VXLAN сети, а не на логическом src VTEP interface.}}

==Learning==
*''Как VTEPs будут находить друг друга?''

Есть 2 способа обнаружения:
*data plane learning [like ethernet switch = L2 learning]
*control plane learning

*''Как будет обрабатываться BUM traffic [broadcast, unknown unicast, multicast]:''
'''Multicast''' - common solution, когда каждому VNI приравнивается какая-то multicast group. На underlay сети должен быть развернут mcast. :) [для лабы достаточно просто добавить pim на iface и назначить anycast RP].

VTEP знает какой VNI (mcast group) у него => шлет igmp-join, чтобы подписаться в домен этого VNI. Когда какой-то VTEP шлет пакет с dest mcast, остальные VTEP его получают.

Когда VTEP должен отправить BUM traffic, он шлет его с dest ip = mcast address.

===Data plane Learning [L2 learning | Flooding learning]===
Когда VTEP получает пакет, он записывает в fw table:
*IP-source VTEP
*MAC VM
*VNI
Когда приходит пакет с назначением к этой VM в этом же VNI, то VTEP уже будет знать что делать.

Если dest mac - не известен, то VTEP начинает флудить, вдруг кто другой знает такой адрес. Но чтобы уменьшить флуд, каждому VNI будет соответствовать своя multicast группа. И флуд будет распространен только в рамках этой группы.

Пример: 2 VM на разных хостах.

VNI 100 = mcast group: 239.1.1.100.

#VM1 шлет arp-request к VM2 (who has 192.168.0.11?)
#VTEP1 инкапсулирует в arp-request в mcast packet и шлет пакет к mcast group 239.1.1.100.
#Все VTEP в группе 239.1.1.100 получают пакет, деинкаспулируют его проверяет VNI. Если совпадает, то шлет arp в VXLAN сегмент, если не совпадает, то дропает пакет. При этом локальный VTEP также добавляет инфу: IP VTEP1 <> MAC VM1 в свою локальную VXLAN table.
#VM2 получила arp и ответила на него, раскрыв свой MAC.
#VTEP2 инкапсулировала ответ и передала его к VTEP1.
#VTEP1 получила arp-response, деинкапсулировала и отдала его VM1. И еще записала в VXLAN table IP VTEP2 <> MAC VM2.
#Далее VM1 и VM2 общаются via unicast.

Можно для нескольких VNI назначать одну группу. VTEP все-равно при передаче пакета проверяет VNI, а флуд при этом все-равно уменьшится.

Подходит только для девайсов, находящихся в одном L2 домене - это главный минус такой системы.

Кстати, VTEP не поддерживают аутентификацию, поэтому злоумышленник запросто может вторгнуться в ваш домен. Поэтому рекомендовано все-же использовать control plane learning.

===Control plane learning [BGP-EVPN]===
Подразумевается, что switches learning делается до того, как начинается процесс передачи трафика. Работает аналогично протоколам маршрутизации.

Свитчи пирятся по BGP и делятся своими префиксами. Для обмена используется evpn family.

Некоторые свитчи будут иметь VTEPs и понятно, что по BGP проанонсятся их адреса.

В control plane learning и VTEP появляется "аутентификация". Когда адреса VTP анонсятся по BGP, они также заносятся в white list. Когда кто-то левый захочет приконнектиться - он не сможет этого сделать до тех пор, пока он не появится в white-list.

VM MAC добавляются в процесс BGP. Соответственно, когда одна VM передает другой фрейм, роутинг к нужному хосту происходит на основании BGP. {это все подробно описано в EVPN}

При использовании control plane learning - появляется и arp suppression. VM посылает ARP-req, который доходит до свитча. А свитч уже по BGP знает соответствие IP<>mac, и отдает mac удаленной VM.

Для BUM трафика советуют также использовать Multicast, как хорошо масштабируемый.

==VXLAN Routing==
Заставляем общаться разные VNI при помощи L3 gateway.

L3 gateway можно делать как на LEAF, так и на SPINE.

Могут использоваться: L2VNI, L3VNI.

'''L2VNI''': для бриджей. То есть когда трафик остается внутри одного LAN-сегмента.

'''L3VNI''': для роутинга. То есть когда трафик должен выйти за переделы LAN. L3VNI опциональны, но если хотите роутить на локальном свитче - придется воспользоваться.

VTEPs должны знать только про локальные L2VNI, которые они локально обслуживают. С другой стороны ВСЕ VTEPs должны знать обо всех L3VNI, что называется '''anycast gateway'''.

В этом случает каждый свитч - это GW в VNI [10.1.1.1]. На соседнем физическом свитче с тем же VNI настраивается такой же адрес шлюза [10.1.1.1]. И все свитчи в этом VNI будут иметь одинаковый virt mac-add для шлюза. Это приемущество по сравнению с VRRP/HSRP в том, что: не нужны какие-то таймеры или hello-massages для синхронизации между двумя свитчами.

То есть для одного VNI, все VM, которые ему принадлежат - имеют один и тот же шлюз! Все зависимости от того к какому свитчу физически включен сервер.

Это способствует быть VM - мобильной и перемещаться на другие сервачки!

L3VNI связаны с VRF. То есть один VNI = один Customer = один RD+RT.

Пример:
На одном свитче будет настроен VRF с двумя irb интерфейсами: irb.100 [10.1.100.1], irb.101 [10.1.101.1]. Каждый будет обслуживать свой L2 домен: VTEP with VLAN100, a VNI1000 и VTEP with VLAN101, a VNI1001 соответственно.

#QFX получает VXLAN пакет с outer dest ip. Деинкасулирует его.
#QFX делает lookup dest mac-адреса, который = IRB VIP MAC.
#Делает L3 lookup внутри VRF для IP-dest.
#Далее делается ARP lookup для IP dest. Если есть mapping, то шлется в iface. Если нет, то выясняется куда слать by looking at the MAC table of the other VNI.
#QFX генерирует новый L2 header с dest-mac для dest server. Потом шлет инкапсулированный VXLAN к remote VTEP.

=EVPN-VXLAN=
EVPN решает две проблемы:
#MAC learning control plane for overlay networks
#the need for workload mobility. Приложениям требуется L2 для взаимодействия друг с другом. Когда речь про app в разных DC, обычным вланом не обойтись.

EVPN относится а BGP family. Он использует MP BGP для MAC learning. Благодаря этому роутеры/свитчи обрабатывают MAC как маршруты. Что позволяет использовать несколько path одновременно (без физического гашения избыточных портов).

EVPN позволяет маршрутизировать не только MAC, но и ARP (IP + MAC). В дальнейшем ARP можно будет привязать и к VLAN-tag.

По сравнению с VPLS - тут явно больше преимуществ для использования.

Немного новой терминологии для EVPN в IP Fabric:
*Ethernet Tags = VLAN-ID
*MAC-VRF = Mac-table [в EVPN можно использовать import/export policies]
*export-policy = обычная политика, которая на все изученные местные (local) mac-addr навешивает target и отправляет route к remote sites.
*import-policy = обычная политика, которая по наличию правильного target кладет route в MAC-VFR.
*RD - uniq ID, который назначается на MAC-VRF. Уникальный в пределах IP Fabric.
*RT community - навешивается на routes посредством политик. На роутерах обозначает принадлежность к той или иной routing-table.
*EVPN services = включает в себя разные vlan-mapping options.

==VLAN Services==
*'''VLAN-based service''' - один влан на весь EVPN. То есть все девайсы на всех sites работают в одном влане. Можно делать vlan-map vlan-id 1 на vlan-id 2. Когда, например на разных фабриках используются разные vlan-id. It's ok. Плюс такого метода - ограничение broadcast. Но он не сильно масштабируем.
*'''VLAN bundle service''' - в одном EVPN много разных вланов. Полезно, когда услуга одна для нескольких арендаторов. У арендаторов используются разные вланы и никак по-другому. Плюсы: удобно для конфига. Но брадакст в таком домене будет влиять на ВСЕ вланы в нем.
*'''VLAN aware service''' - тут, кажется, используются bridge-domain внутри одного EVPN instance. Каждый со своим vlan-id внутри. То есть это дает возможность использовать в ENI (EVPN instance) несколько vlan-id, но которые не будут в одном broadcast домене. При флудах будут страдать конкретные вланы.
==Data Plane==
В качестве dataplane для EVPN из близкого к теме могут быть: MPLS, VXLAN. Есть еще и другие: PBB, STT, NVGRE..

VXLAN encapsulation метод основан на VNIs, тогда ваши vlan-id 1, vlan-id 2 > vni-1, vni-2 > vxlan-1, vxlan-2 (с изученными Mac-addr) > в EVPN instance-1 с uniq RD.

===BGP Route Types for EVPN===
:-'''Ethernet Auto-Discovery (AD) Route''': когда новый свитч вступает в EVPN, он пользуется этими роутами, чтобы объявить о себе.
RD [8], _ESI [10], _ET [4], MPLS LBL [3]

Передается flag, указывающий сколько линков можно использовать для передачи.
[[Файл:EVPN routes type1.png|мини|без]]
Например, у нас один сервер включен двумя ногами в разные свитчи. Когда LEAF4 получит auto-discovery route от LEAF1 и LEAF2, то route будет вставлен в таблицу, но также, LEAF4 будет знать, что до данного сервера у него '''два''' VXLAN, которые можно использовать.

Это как раз различие в active/active links [flag set to 0] и single link [flag is set to 1].

Auto-discovery process отрабатывает намного быстрее, так как при стандартном включении в свитч при падении линка (за которым были тысячи mac-addr) таблица будет чистить эти тысячи маков гораздо дольше, чем один route, который соответствует (ассоциирован с) линку.

:-'''MAC/IP Advertisement Route''': MAC advertisement (также может передавать IP+MAC).
RD [8], ESI [10], _ET [4],
_MAC Addr Lenght [1], _MAC Addr [6],
_IP Addr Lenght [1], _IP Addr [0|4|16]
MPLS LBL1 [3]
MPLS LBL2 [0|3]

[[Файл:EVPN routes type2.png|мини|без]]

LEAF4 изучил Mac server2. Начал передавать его другим sites EVPN с соответствующим community, которое навешивается согласно export policy.

LEAF1 исходя из import policy решает принять ли маршрут. Если import policy отсутствует - это равнозначно discard.

:-'''Inclusive Multicast Ethernet Tag Route''': BUM flooding.
ET [4], IP Addr Lenght [1], Originating Router's IP Addr [4|16]

В Juniper EVPN/VXLAN свитчи поддерживают ingress replication BUM. То есть свитч получил BUM, создал unicast копии этого трафик и отправил remote sites этого EVPN.

Route информирует remote PE - как обработать BUM traffic и PMSI аттрибуты. Он определяет следует использовать PIM или PMSI и на какой dst adddr отправлять BUM traffic.

LEAF2 передает инфу, что он ждет и использует ingress replication и что LEAF1 должен использовать 4.4.4.4 как dst addr VXLAN пакетов, которые передают BUM.

:-'''Ethernet Segment Route''': ES and DF election.
_ESI [10], _IP Addr Lenght [1], _IP Addr [4|16]

Решает проблемы:
*выбор designated forwarder (DF)
*split-horizont - preventing routing loops in the routing protocol. Not to advertise route to it's origin iface.
В EVPN есть стандартные правила split-horizont:
#Локальный свитч получил BUM от сервера. Свитч перешлет BUM только серверам в том же влане и remote sites EVPN instance. Но не обратно в интерфейс сервера, откуда он пришел.
#Свитч получи BUM от remote site. Свитч отправит BUM локальным серверам. Но не будет передавать его другим remote sites.

При использовании active/active у нас могут возникнуть проблемы и петли все-таки могут возникнуть.

Как избавиться от этого?

Для одного EVPN instance выбрать одного DF для EVPN для передачи BUM traffic. Все остальные будут дропать BUM.

:-'''IP Prefix Route''': IP route advertisement
Обычно можно увидеть при DC interconnect.

LEAF1 получил трафик от Server 1. Инкапсулировал Eth в VXLAN и отправил на EDGE router DC1 (GW for LEAF1 with irb iface).

EDGE снимет Eth header, и IP пакет смаршрутизирует согласно ip routing table.

В таблице будет route type 5, который был получен от remote PE DC2. EDGE засунет IP в VXLAN к DC2.

EDGE DC2 снимет VXLAN header, смаршрутизирует ip пакет. Засунет его в Eth заголовок с dst MAC Server 2. Отправит фрейм.

===Distributed Layer 3 Gateway===
[[Файл:EVPN gateway.png|мини|без]]

На SPINE1 и SPINE2 настроен одинаковый Virtual ip gateway address 10.0.1.254 и одинаковый Virtual MAC 00:01:8d:00:01:02.

SPINE1 и SPINE2 передают в EVPN type 1 auto-discovery и type 2 Mac+ip learning.

LEAF1 получит равнозначные по стоимости маршруты к одному MAC в том же сегменте. И начнет балансить трафик между ними.

==Design==
Как это все ляжет на сеть?

Серверы включены в LEAF в своих вланах.

VLAN связаны с VXLAN VTEP на портах свитчей.

VTEP сопоставляются в соответствующие EVPN (которые делают L2 связность для VTEP).

Как говорили выше: можно сопоставлять несколько VTEP одному EVPN instance (c one-to-one mapping или many-to-one mapping).

=Controllers=
Речь про SDN контроллеры
=Дополнительная информация=
*[[EVPN]]
*[[Traffic engineering]]
*[[Глава 1. Основы MPLS и VPN]]
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]

Файл:VXLAN пакет.png

2021-12-25T19:05:34Z

Наталия Бобкова:

DC

2021-12-25T18:54:53Z

Наталия Бобкова: /* VXLAN */

{{#description2:Overlay Networks. Fabric Design. IP Fabrics. VXLAN. EVPN-VXLAN. BGP Route Types for EVPN. Distributed Layer 3 Gateway. Информация для подготовки к экзаменам Juniper.}}
=Overlay Networks=
Разделяют 2 вида сетей: overlay и underlay.

Underlay - физическая IP сеть. Это база (транспорт) поверх которого уже строится overlay netw.

Примеры underlay: MPLS, IP-сеть построенная на IGP/EGP.

Также в underlay входят bare metal servers (или могу ошибаться и это не так). Подразумевается, что underlay - это прям железо-железо в голом виде.

Overlay - это наложенная сеть на underlay. Виртуальные свитчи, серверы и другие VM соединены virt logical links (VTEPs - virtual tunnel endpoints).

*''host machine'' - сервер, на котором запущен hypervisor.
*''guest machine'' - каждая VM.
Hypervisor предоставляет OS с virt платформой для guest и далее управляет работой guest OS. Несколько разных guest OS будут делать hardware ресурсы сервера.

VXLAN - overlay technology, которая строит virt туннели на основе IP/MPLS netw (VTEPs)

VM на одном хосте будут коммуницировать между собой через virt switch - L2.
VM на разных хостах будут коммуницировать между собой через VTEP - L3. То есть прибегать к инкапсуляции L2 в L3 и передаче трафика через underlay сеть.

VTEP - располагаются на hypervisor или есть брать сервера, включенные с обычные access switches, то на свитчах тоже можно создавать VTEP. VTEP - туннель между хостами
VTEP имеет 2 iface:
*switching interface - в сторону VM
*IP interface - в сторону IP сети (L3 netw)

Для инкапсуляции используется обычно VXLAN. О нем ниже.

Положительные особенности overlay network (наложенных сетей):
# Отделение сети от физического оборудования позволяет сетям дата-центров быть развернутыми за считанные секунды.
# Поддержка L2 и L3 между VM и серверами.
# В отличие от стандартной сети поддерживает до 16,4 млн "заказчиков" (вланов).

Чем приходится платить за использование overlay network:
:- virtual tunnel endpoints (VTEPs) ипользует MAC и route. В отличие от традиционной модели, где каждая VM и каждый сервер использует MAC и route. В overlay трафик от VM и сервером инкапсулируется между VTEP. mac и route каждого сервера теперь не виден для оборудования overlay сети. mac и route теперь перенесены с физического уровня на уровень hypervisor.

=Bare metal server=
Редко в каких сетях получится найти полностью виртуализированую сеть. Какая-то часть серверов все-равно останется железной (в основном из-за производительности).

Как не бросить те самые железные сервачки и сохранить с ними сетевую связность?

Один из методов: соединить VTEP с физическим access switch.

Каждый гипервизор имеет VTEP. VTEP передает инкапсулированный трафик data plane между VM. Также VTEP делает mac-learning, предоставляет новые virt netw и другие изменения конфигурации.

На железных серверах нет VTEP. Чтобы железный сервер включить в overlay netw архитектуру, нужно чтобы кто-то инкапсулировал трафик от сервера и делал mac-learning. Пусть это делает обычный access-switch от имени сервера. Сервер при этом просто думает, что посылает от себя трафик дальше в сеть.

=Fabric Design=
*'''Traditional – MC-LAG (multichassis link aggregation group)'''
[[Файл:MC-LAG.png|мини|без]]
*'''Virtual Chassis'''
[[Файл:VC 1.png|мини|слева|top-of-rack topology]]
[[Файл:VC 2.png|мини|центр|end-of-row topology]]

*'''Virtual Chassis Fabric'''
[[Файл:VC_fabric_1.png|мини|слева|top-of-rack topology]]
[[Файл:VC fabric_2.png|мини|центр|end-of-row topology]].
Большое приемущество в том, что между каждыми двумя host в фабрике есть только 2 hops. В отличие от VC, где число hops может достигать до 9.

Limitations:
:-Virtual Chassis = 10 members
:-Virtual Chassis Fabric = 20 members [2-4 spine + 16-18 leaf]

Master + backup используют один и тот же MAC + IP для GW.

Можно легко вставлять/вытаскивать членов VC. На них автоматически будет сделан upgrade софта если нужно, подъедет конфиг, новый член будет назначен linecard.

В VC для вычисления кратчайшего пути используется Dejkstra и путь выбирается один.

В VC fabric VCCP отвчечает за эту процедуру и при возникновении нескольких равнозначных путей трафик балансируется.

Virtual Chassis Fabric works really well for a top-of-rack based solution, but for end-of-row it becomes a little more problematic.
*'''Junos Fusion'''
[[Файл:JF.png|мини|без|top-of-row topology]]

*'''IP CLOS Fabrics'''
[[Файл:CLOS.png|мини|без|finely grained failure domains]]

=IP Fabrics=
Самое важное условие для IP Fabric: VTEP должны соединяться по L3.

Clos придумал распределенную топологию для L3, при которой возможно достаточно хорошее масштабирование сети. В такой сети есть разделение на уровни: ingress, middle, egress.

На основе CLOS произошла топология spine anf leaf, которую иногда называют сложенной CLOS сетью. То ест тут ingress и egress уровни сложены друг на друга (если можно так выразиться).

Spine - это L3 свитчи.

Leaf - это top-of-the-rack свитчи, который связывают сервер и VTEP.

Масштабируемость определяется двумя параметрами: "толщиной" spine, коэффициентов переподключенийleaf светчей.

Spine L3 свитчи можно собирать в кластер, а можно и нет. Причем говорится про кластре, в котором будут и SPINE и LEAF, все вместе.

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

При фабрике без VChassis емкость рассчитывается как умножение кол-во портов под серверы на кол-во LEAF, используемых на SPINE.

Пример:
При использовании такого оборудования:
SPINE = QFX5100-24Q ['''32''' x 40GbE]
LEAF = QFX5100-96S ['''96''' x 10G + 8 x 40GbE]
получаем фабрику размерностью = (32*96) x 10GbE = 3072 x 10GbE и oversubscription ratio 3:1

==Control Plane==
Для фабрик с VChassis беспокоиться о Control Plane не приходится. Она прост работает. Но если требуется более масштабируемся сеть, то придется отойти от VChassis и подумать о ControlPlane.

В фабрике каждому LEAF потребуется отправлять и получать маршрутную инфу вместе с остальными LEAF.

В той или иной степени для ControlPlane фабрики могут подойти следующие протоколы: BGP, OSPF, ISIS. Сравним их по разным параметрам:

'''Scale + Advertise Prefixes:''' Adveritse prefixes - у всех протоколов - норм, но OSFP и ISIS флудят префиксами. Чем больше префиксов в сети, тем больше флуда. Для уменьшения флуда можно и нужно в данном случае разбивать сегменты на area. Но при этом утратятся возможности CSPF. При этом BGP специально был придуман для работы с большим кол-вом префиксов. В плане масштабируемости он значительно выигрывает!

'''Traffic engineering + traffic tagging:''' иногда нужно управлять трафиком в фабриках, например, чтобы пустить его в обход какого-то SPINE. Тут понятно, что OSPF и ISIS сильно проигрывают. В отличие от них у BGP есть дофига атрибутов, которыми можно управлять трафиком.

'''Multivendor stability:''' Вроде и OSPF и ISIS неплохо себя должны вести, но кто знает, кто проверял. Гораздо чаще разные компании, использующие разное оборудование настраивают взаимодействие между собой именно посредством BGP. Так что именно BGP можно считать самым неприхотливым в работе в разными вендорами.

Ну в итоге для IP Fabric самый адекватный протокол - '''BGP'''.

==BGP Design==
*Using '''EBGP''' in an IP fabric: каждому свитчу свою AS. Каждый LEAF пирится с каждым SPINE. Тут все просто и понятно и красиво. И также с помощью LPF и AS-PATH можем спокойно рулить трафиком. Защита от петель, напомню в том, что при отправке префикса проверяется AS-path. Префикс не отправляется пиру, если в AS-path есть AS пира.
[[Файл:Ebgp-1.png|мини|слева|top-of-the-rack]]
[[Файл:Ebgp_2.png|мини|без|end-of-the-rack]].

*Using '''IBGP''' in an IP fabric: все свитчи в одной AS. Для получения полной маршрутной информации - full mesh. Ну или более разумно использовать route reflector (или conederation - реже). RR втискиваем в уровень SPINE. Делаем пару RR, для резервирования. Все нормально НО! при таком раскладе не выйдет делать балансировку (использовать multipath), т.к. RR выбирает и отдает своим пирам только лучший маршрут. Для восстановления справедливости потребуется заморочиться с AddPath на RR (draft-ietf-idr-add-paths). Плюсом IBGP считается еще защита от петель: имеется ввиду, что IBGP пиры при любом раскладе не будут флудить префиксами.
[[Файл:Ibgp_1.png|мини|слева|top-of-the-rack]]
[[Файл:Ibgp_2.png|мини|без|end-of-the-rack]].

[[Файл:IBGP-eBGP CLOS.png|750px|без]]
ECMP - equal-cost multi-path - технология, когда один поток (один source + один dest) передается между двумя равнозначными линками. Подразумевается включение обычной балансировки, то есть:
protocols {
bgp {
group CLOS {
...
multipath multiple-as;

policy-options {
policy-statement PFE-LB {
then {
load-balance per-packet;

routing-options {
forwarding-table {
export PFE-LB;

Хорошей практикой для IP Fabric также считается использование следующих фич:
protocols {
bgp {
log-updown;
graceful-restart;
group CLOS {
mtu-discovery;
bfd-liveness-detection {
minimum-interval 350;
multiplier 3;
session-mode single-hop;
Подробно на каждой из них в этой главе останавливаться не буду.

==Requirements==
Для того, чтобы построить IP Fabric с BGP, придерживайтесь следующих требований:
*Base IP prefix. Один пул адресов для служебных целей (p2p, loopback, ...). Лучше сразу прикинуть размеры фабрики и выделить достаточный пул адресов.
*P2P network. Экономно и удобно использовать /31.
*P2P addresses. Удобно, когда при построении фабрики придерживаются одного принципа назначение ip. Первый - не spine, второй - на leaf.
*Loopback. Выделить из большого пула. Лучше использовать loopback, это облегчает диагностику.
*Server facing network. Сеть для сервачков. Leaf выступает как шлюз. Все зависит от масштабов фабрики, но понятно, что будет удобно использовать, например: /24 на один leaf, в ней работают только сервера, включенные к этому leaf. В фабрике 8 leaf, соответственно можно выделить 8*/24 = /21 сеть на фабрику. Подразумевается, что server facing netw и base ip netw - разные.
*AS num. Для каждого свитча (SPINE или LEAF) отдельная AS num - для работы EBGP. Выбор использовать 32-bit/16-bit. '''16-bit''': диапазон приватных: 64512 - 65535 то есть 1023 шт, то есть максимум 1023 свитчей в фабрике. Если этого мало, то можно переходить либо в public диапазон, либо на 32-bit AS num.
*BGP export. LEAF передает свой loopback и server facing netw.
*BGP import. Разрешаем только Base IP prefix и Server facing network.
*ECMP. Включаем load balancing на SPINE и LEAF.

==Edge connect==
Речь про связность с внешним миром и фабриками в других локациях, если такие есть.

В идеальном мире каждый дата-центр с IP Fabric должен:
*на всех фабриках иметь одинаковую структуру и даже распределение AS.
*иметь 2 edge роутера с уникальными AS num.
*быть подключенным к двум разным ISP.
*быть подключенным в внутренней MPLS сети.

Одинаковые AS num внутри фабрик разных дата-центров могут немного вводить в смятение. Можно с edge роутеров просто анонсировать агрегат своей фабрики.

Для ISP подключения: edge роутер к IP Fabric передает default, к ISP передает агрегаты фабрик. Все остальное - reject. От ISP на Edge лучше получать full view.

=VXLAN=
Virtual Extensible LAN protocol (VXLAN) инкапсулирует L2 Ethernet frame в L3 UDP packets.
*Позволяет использовать бОльшее кол-во вланов.
*Пригоден для огромных сетей облаков и ДЦ с большим кол-вом клиентов.
*Можно мигрировать VM через туннелирование трафика в L3, даже если VM включены в разные L2-домены. Это позволяет использовать ресурсы сети не учитывать границы L2. Также использование VXLAN убирает необходимость создавать огромные (в том числе по географии) L2-домены.
*Использование VXLAN дает возможность отказаться от STP и использовать более надежные и развитые протоколы маршрутизации для быстрой сходимости сети. Отсутствие STP дает возможность использовать полную пропускную способность сети (нет заблокированных портов).
*Использование L3 между L2-доменами дает возможность эффективнее балансировать трафик и опять же использовать максимально возможную пропускную способность.

MX series и EX9200: поддерживают до 32 000 VXLAN, 32 000 multicast groups, 8 000 VTEP (virtual tunnel endpoint). Это позволяет использовать MX для очень больших сетей.

QFX10000 поддерживают до 4000 VXLANs, 2000 VTEPs.

QFX5100, QFX5110, QFX5200, QFX5210, EX4600 поддерживают до 4000 VXLANs, до 2000 remote VTEPs.

EX4300-48MP поддреживают до 4000 VXLANs.

Более подробно можно узнать на сайте производителя.

==Принцип работы==
VXLAN инкапсулирует Ethernet-frame (L2) в UDP-пакет (L3). Из-за такой инкапсуляции VXLAN считают overlay технологией.

Свитчи или роутеры, которые используют VXLAN называются VTEP (virtual tunnel endpoints).

VTEPs инкапсулируют и декапсулирует VXLAN-трафик на входе и выходе из VXLAN-туннеля.

В случае, когда hardware сервер включается напрямую в Juniper и сам не умеет создавать VXLAN туннели: в качестве VTEP выступают свитчи или маршрутизаторы Juniper.

В случае с VM (virtual machine), гипервизор будет участвовать в роли VTEP, сам создавать VXLAN tunnel, а Juniper будет транзитным девайсом.

Во время инкапсуляции VTEP добавляет к фрейму поля:
:- outer MAC dst MAC (mac endpoint VTEP)
:- outer MAC src MAC (mac source VTEP)
:- outer dst IP
:- outer src IP
:- outer UDP header
:- VXLAN header: 24-битное поле VNI (VXLAN netw indentifier), уникально идентифицирующее VXLAN. Похоже на VLANID, только побольше.

| Origin Ethernet | + VXLAN Header | + OUTER IP | + OUTER MAC |

Передаем frame от VM1 к Server1.
[[Файл:VTEP аппаратный и програмный.png|700px|никакой|центр]]
#VTEP3 получает Eth-frame от VM1 (с dst addr Server1).
#В Forwarding Table уже есть изученный mac-add Server1 + инфа об исх интерфейсе (VTEP)
#VTEP3 добавляет заголовок VXLAN, который содержит VNI. VTEP3 инкапсулирует Eth-frame в UDP-пакет (L3).
#VTE3 маршрутизирует пакет через underlay L3-сеть к VTEP1.
#VTEP1 делает деинкапсуляцию и отдает Eth-frame к Server1.

VM и сервера при этом ничего не знают про VXLAN и протоколы на L3. Для серверов всё выглядит, как-будто они сидят в одном L2-домене.

{{note|text=VXLAN добавляет 50-54 дополнительных bytes! В ответ потребуется увеличить MTU на underlay. А именно на интерфейсах, которые участвуют в VXLAN сети, а не на логическом src VTEP interface.}}

==Learning==
*''Как VTEPs будут находить друг друга?''

Есть 2 способа обнаружения:
*data plane learning [like ethernet switch = L2 learning]
*control plane learning

*''Как будет обрабатываться BUM traffic [broadcast, unknown unicast, multicast]:''
'''Multicast''' - common solution, когда каждому VNI приравнивается какая-то multicast group. На underlay сети должен быть развернут mcast. :) [для лабы достаточно просто добавить pim на iface и назначить anycast RP].

VTEP знает какой VNI (mcast group) у него => шлет igmp-join, чтобы подписаться в домен этого VNI. Когда какой-то VTEP шлет пакет с dest mcast, остальные VTEP его получают.

Когда VTEP должен отправить BUM traffic, он шлет его с dest ip = mcast address.

===Data plane Learning [L2 learning | Flooding learning]===
Когда VTEP получает пакет, он записывает в fw table:
*IP-source VTEP
*MAC VM
*VNI
Когда приходит пакет с назначением к этой VM в этом же VNI, то VTEP уже будет знать что делать.

Если dest mac - не известен, то VTEP начинает флудить, вдруг кто другой знает такой адрес. Но чтобы уменьшить флуд, каждому VNI будет соответствовать своя multicast группа. И флуд будет распространен только в рамках этой группы.

Пример: 2 VM на разных хостах.

VNI 100 = mcast group: 239.1.1.100.

#VM1 шлет arp-request к VM2 (who has 192.168.0.11?)
#VTEP1 инкапсулирует в arp-request в mcast packet и шлет пакет к mcast group 239.1.1.100.
#Все VTEP в группе 239.1.1.100 получают пакет, деинкаспулируют его проверяет VNI. Если совпадает, то шлет arp в VXLAN сегмент, если не совпадает, то дропает пакет. При этом локальный VTEP также добавляет инфу: IP VTEP1 <> MAC VM1 в свою локальную VXLAN table.
#VM2 получила arp и ответила на него, раскрыв свой MAC.
#VTEP2 инкапсулировала ответ и передала его к VTEP1.
#VTEP1 получила arp-response, деинкапсулировала и отдала его VM1. И еще записала в VXLAN table IP VTEP2 <> MAC VM2.
#Далее VM1 и VM2 общаются via unicast.

Можно для нескольких VNI назначать одну группу. VTEP все-равно при передаче пакета проверяет VNI, а флуд при этом все-равно уменьшится.

Подходит только для девайсов, находящихся в одном L2 домене - это главный минус такой системы.

Кстати, VTEP не поддерживают аутентификацию, поэтому злоумышленник запросто может вторгнуться в ваш домен. Поэтому рекомендовано все-же использовать control plane learning.

===Control plane learning [BGP-EVPN]===
Подразумевается, что switches learning делается до того, как начинается процесс передачи трафика. Работает аналогично протоколам маршрутизации.

Свитчи пирятся по BGP и делятся своими префиксами. Для обмена используется evpn family.

Некоторые свитчи будут иметь VTEPs и понятно, что по BGP проанонсятся их адреса.

В control plane learning и VTEP появляется "аутентификация". Когда адреса VTP анонсятся по BGP, они также заносятся в white list. Когда кто-то левый захочет приконнектиться - он не сможет этого сделать до тех пор, пока он не появится в white-list.

VM MAC добавляются в процесс BGP. Соответственно, когда одна VM передает другой фрейм, роутинг к нужному хосту происходит на основании BGP. {это все подробно описано в EVPN}

При использовании control plane learning - появляется и arp suppression. VM посылает ARP-req, который доходит до свитча. А свитч уже по BGP знает соответствие IP<>mac, и отдает mac удаленной VM.

Для BUM трафика советуют также использовать Multicast, как хорошо масштабируемый.

==VXLAN Routing==
Заставляем общаться разные VNI при помощи L3 gateway.

L3 gateway можно делать как на LEAF, так и на SPINE.

Могут использоваться: L2VNI, L3VNI.

'''L2VNI''': для бриджей. То есть когда трафик остается внутри одного LAN-сегмента.

'''L3VNI''': для роутинга. То есть когда трафик должен выйти за переделы LAN. L3VNI опциональны, но если хотите роутить на локальном свитче - придется воспользоваться.

VTEPs должны знать только про локальные L2VNI, которые они локально обслуживают. С другой стороны ВСЕ VTEPs должны знать обо всех L3VNI, что называется '''anycast gateway'''.

В этом случает каждый свитч - это GW в VNI [10.1.1.1]. На соседнем физическом свитче с тем же VNI настраивается такой же адрес шлюза [10.1.1.1]. И все свитчи в этом VNI будут иметь одинаковый virt mac-add для шлюза. Это приемущество по сравнению с VRRP/HSRP в том, что: не нужны какие-то таймеры или hello-massages для синхронизации между двумя свитчами.

То есть для одного VNI, все VM, которые ему принадлежат - имеют один и тот же шлюз! Все зависимости от того к какому свитчу физически включен сервер.

Это способствует быть VM - мобильной и перемещаться на другие сервачки!

L3VNI связаны с VRF. То есть один VNI = один Customer = один RD+RT.

Пример:
На одном свитче будет настроен VRF с двумя irb интерфейсами: irb.100 [10.1.100.1], irb.101 [10.1.101.1]. Каждый будет обслуживать свой L2 домен: VTEP with VLAN100, a VNI1000 и VTEP with VLAN101, a VNI1001 соответственно.

#QFX получает VXLAN пакет с outer dest ip. Деинкасулирует его.
#QFX делает lookup dest mac-адреса, который = IRB VIP MAC.
#Делает L3 lookup внутри VRF для IP-dest.
#Далее делается ARP lookup для IP dest. Если есть mapping, то шлется в iface. Если нет, то выясняется куда слать by looking at the MAC table of the other VNI.
#QFX генерирует новый L2 header с dest-mac для dest server. Потом шлет инкапсулированный VXLAN к remote VTEP.

=EVPN-VXLAN=
EVPN решает две проблемы:
#MAC learning control plane for overlay networks
#the need for workload mobility. Приложениям требуется L2 для взаимодействия друг с другом. Когда речь про app в разных DC, обычным вланом не обойтись.

EVPN относится а BGP family. Он использует MP BGP для MAC learning. Благодаря этому роутеры/свитчи обрабатывают MAC как маршруты. Что позволяет использовать несколько path одновременно (без физического гашения избыточных портов).

EVPN позволяет маршрутизировать не только MAC, но и ARP (IP + MAC). В дальнейшем ARP можно будет привязать и к VLAN-tag.

По сравнению с VPLS - тут явно больше преимуществ для использования.

Немного новой терминологии для EVPN в IP Fabric:
*Ethernet Tags = VLAN-ID
*MAC-VRF = Mac-table [в EVPN можно использовать import/export policies]
*export-policy = обычная политика, которая на все изученные местные (local) mac-addr навешивает target и отправляет route к remote sites.
*import-policy = обычная политика, которая по наличию правильного target кладет route в MAC-VFR.
*RD - uniq ID, который назначается на MAC-VRF. Уникальный в пределах IP Fabric.
*RT community - навешивается на routes посредством политик. На роутерах обозначает принадлежность к той или иной routing-table.
*EVPN services = включает в себя разные vlan-mapping options.

==VLAN Services==
*'''VLAN-based service''' - один влан на весь EVPN. То есть все девайсы на всех sites работают в одном влане. Можно делать vlan-map vlan-id 1 на vlan-id 2. Когда, например на разных фабриках используются разные vlan-id. It's ok. Плюс такого метода - ограничение broadcast. Но он не сильно масштабируем.
*'''VLAN bundle service''' - в одном EVPN много разных вланов. Полезно, когда услуга одна для нескольких арендаторов. У арендаторов используются разные вланы и никак по-другому. Плюсы: удобно для конфига. Но брадакст в таком домене будет влиять на ВСЕ вланы в нем.
*'''VLAN aware service''' - тут, кажется, используются bridge-domain внутри одного EVPN instance. Каждый со своим vlan-id внутри. То есть это дает возможность использовать в ENI (EVPN instance) несколько vlan-id, но которые не будут в одном broadcast домене. При флудах будут страдать конкретные вланы.
==Data Plane==
В качестве dataplane для EVPN из близкого к теме могут быть: MPLS, VXLAN. Есть еще и другие: PBB, STT, NVGRE..

VXLAN encapsulation метод основан на VNIs, тогда ваши vlan-id 1, vlan-id 2 > vni-1, vni-2 > vxlan-1, vxlan-2 (с изученными Mac-addr) > в EVPN instance-1 с uniq RD.

===BGP Route Types for EVPN===
:-'''Ethernet Auto-Discovery (AD) Route''': когда новый свитч вступает в EVPN, он пользуется этими роутами, чтобы объявить о себе.
RD [8], _ESI [10], _ET [4], MPLS LBL [3]

Передается flag, указывающий сколько линков можно использовать для передачи.
[[Файл:EVPN routes type1.png|мини|без]]
Например, у нас один сервер включен двумя ногами в разные свитчи. Когда LEAF4 получит auto-discovery route от LEAF1 и LEAF2, то route будет вставлен в таблицу, но также, LEAF4 будет знать, что до данного сервера у него '''два''' VXLAN, которые можно использовать.

Это как раз различие в active/active links [flag set to 0] и single link [flag is set to 1].

Auto-discovery process отрабатывает намного быстрее, так как при стандартном включении в свитч при падении линка (за которым были тысячи mac-addr) таблица будет чистить эти тысячи маков гораздо дольше, чем один route, который соответствует (ассоциирован с) линку.

:-'''MAC/IP Advertisement Route''': MAC advertisement (также может передавать IP+MAC).
RD [8], ESI [10], _ET [4],
_MAC Addr Lenght [1], _MAC Addr [6],
_IP Addr Lenght [1], _IP Addr [0|4|16]
MPLS LBL1 [3]
MPLS LBL2 [0|3]

[[Файл:EVPN routes type2.png|мини|без]]

LEAF4 изучил Mac server2. Начал передавать его другим sites EVPN с соответствующим community, которое навешивается согласно export policy.

LEAF1 исходя из import policy решает принять ли маршрут. Если import policy отсутствует - это равнозначно discard.

:-'''Inclusive Multicast Ethernet Tag Route''': BUM flooding.
ET [4], IP Addr Lenght [1], Originating Router's IP Addr [4|16]

В Juniper EVPN/VXLAN свитчи поддерживают ingress replication BUM. То есть свитч получил BUM, создал unicast копии этого трафик и отправил remote sites этого EVPN.

Route информирует remote PE - как обработать BUM traffic и PMSI аттрибуты. Он определяет следует использовать PIM или PMSI и на какой dst adddr отправлять BUM traffic.

LEAF2 передает инфу, что он ждет и использует ingress replication и что LEAF1 должен использовать 4.4.4.4 как dst addr VXLAN пакетов, которые передают BUM.

:-'''Ethernet Segment Route''': ES and DF election.
_ESI [10], _IP Addr Lenght [1], _IP Addr [4|16]

Решает проблемы:
*выбор designated forwarder (DF)
*split-horizont - preventing routing loops in the routing protocol. Not to advertise route to it's origin iface.
В EVPN есть стандартные правила split-horizont:
#Локальный свитч получил BUM от сервера. Свитч перешлет BUM только серверам в том же влане и remote sites EVPN instance. Но не обратно в интерфейс сервера, откуда он пришел.
#Свитч получи BUM от remote site. Свитч отправит BUM локальным серверам. Но не будет передавать его другим remote sites.

При использовании active/active у нас могут возникнуть проблемы и петли все-таки могут возникнуть.

Как избавиться от этого?

Для одного EVPN instance выбрать одного DF для EVPN для передачи BUM traffic. Все остальные будут дропать BUM.

:-'''IP Prefix Route''': IP route advertisement
Обычно можно увидеть при DC interconnect.

LEAF1 получил трафик от Server 1. Инкапсулировал Eth в VXLAN и отправил на EDGE router DC1 (GW for LEAF1 with irb iface).

EDGE снимет Eth header, и IP пакет смаршрутизирует согласно ip routing table.

В таблице будет route type 5, который был получен от remote PE DC2. EDGE засунет IP в VXLAN к DC2.

EDGE DC2 снимет VXLAN header, смаршрутизирует ip пакет. Засунет его в Eth заголовок с dst MAC Server 2. Отправит фрейм.

===Distributed Layer 3 Gateway===
[[Файл:EVPN gateway.png|мини|без]]

На SPINE1 и SPINE2 настроен одинаковый Virtual ip gateway address 10.0.1.254 и одинаковый Virtual MAC 00:01:8d:00:01:02.

SPINE1 и SPINE2 передают в EVPN type 1 auto-discovery и type 2 Mac+ip learning.

LEAF1 получит равнозначные по стоимости маршруты к одному MAC в том же сегменте. И начнет балансить трафик между ними.

==Design==
Как это все ляжет на сеть?

Серверы включены в LEAF в своих вланах.

VLAN связаны с VXLAN VTEP на портах свитчей.

VTEP сопоставляются в соответствующие EVPN (которые делают L2 связность для VTEP).

Как говорили выше: можно сопоставлять несколько VTEP одному EVPN instance (c one-to-one mapping или many-to-one mapping).

=Controllers=
Речь про SDN контроллеры
=Дополнительная информация=
*[[EVPN]]
*[[Traffic engineering]]
*[[Глава 1. Основы MPLS и VPN]]
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]

Файл:VTEP аппаратный и програмный.png

2021-12-25T18:29:05Z

Наталия Бобкова:

EVPN

2021-12-25T18:23:45Z

Наталия Бобкова: /* Дополнительная информация */

{{#description2: Основы EVPN. Конфигурация EVPN. Траблшутинг EVPN. Multi-homing EVPN. L2 процессы внутри EVPN. L3 процессы внутри EVPN. MP-BGP EVPN Route Summary. High Availability в EVPN. Информация для подготовки к экзаменам Juniper.}}

=Основы EVPN=
Обеспечивает виртуальную многоточечную связность между разными L2 доменами через IP или MPLS сеть. Внедрить можно уже на существующей сети, потому что в ядре уже используются нужные технологии: MPLS или IP.

Отлично подходит для соединения data-centers sites.

CE, включенный в EVPN видит всю сеть как один бродкаст домен (большой свитч).

Control-plane mac-learning => all-active multihoming, traffic load balancing, MAC mobility.

Имеет хорошую возможность эффективно роутить вх и исх трафик, даже при миграции хостов в data-centers.

Имеет хорошие показатели по сходимости при link failure и node failure.

По аналогии с другими VPN, для EVPN на PE роутера создается отдельный Instance (EVIs), который логически разделяет клиентов.

CE имеют соединение с PE. PE обмениваются между собой информацией, использую MP-BGP и инкапсулированный трафик также передают между PE.

'''Особенность''': есть mac-learning, который осуществляется на control plane. Новый мак-адрес изученный PE, передается остальным удаленным PE, используя '''MP-BGP MAC route'''. Mac-learning в EVPN намного более тонко работает, чем в VPLS.

MAC-learning на control-plane позволяет примерять policy и другие опции к MAC, изученными между PE, что делает подобный mac-learning более эффективным и дает возможность обеспечивать защиту на сети.

С использованием EVPN, можно реализовать на сети много разных топологий: E-LINE, E-LAN, E-TREE.

EVPN полезно внедрять ISP, предоставляющим своим клиентам L2VPN, L3VPN, Internet access и которые дополнительно хотели бы для существующих клиентов предоставить облачные сервисы и хранение данных.

Также EVPN эффективно использовать для соединения разных data-centers (DC) site.

EVPN обладает такими функциями:
*'''Multi-homing между CE-PE''' с поддержанием active-active линков.
Дает возможность подключиться одному CE к нескольким PE, при этом трафик передается по всем активным линкам.

'''Aliasing''' дает возможность удаленным PE делать балансировку к multi-homed PE, через core, даже в том случае, когда удаленный PE изучил мак с одного из Multi-homed PE.

*В EVPN есть механизмы для '''предотвращения BUM петель'''.

В случае, когда CE не поддерживает балансировку или PE не имеет средств защиты от BUM петель, тогда можно организовать multi-homing с одним активным линком между PE и CE.

*'''Быстрое восстановление сервиса'''.
С помощью multi-homing, обеспечивается быстрое восстановление сервиса, т.к. при падении PE или линка до PE, трафик переходит на другой активный линк.

Трафик с другой стороны: удаленный PE обновляет свою forwarding table и также посылает трафик в сторону оставшихся активных PE.

*Поддержка '''миграции виртуальных машин или MAC mobility'''.
У PE есть возможность отслеживать перемещение мак-адреса виртуальной машины (VM).
При этом, когда VM переместилась, то новый PE, который изучил ее MAC, делает MAC route update. Старый PE, получив такой update, удаляет у себя информацию об этом MAC.

*'''Интеграция L3 роутинга с оптимальным forwarding'''.
Для L2 домена можно внедрить L3 routing, путем добавления IRB интерфейса для влана в EVPN instance. Хосты будут использовать этот irb как default gateway.

Irb IP и MAC анонсируются остальным удаленным PE EVPN путем ''Default Gateway Synchronization''. Это полезно с той точки зрения, что все PE будут в курсе Def GW и при переезде VM на другой PE, PE будет проксировать arp от имени изученного Def GW и маршрутизировать трафик от VM напрямую к destination.

Таким же образом, через snooping ARP и DHCP пакетов, происходит заучивание ip-адресов хостов EVPN дата-центров. Называется это ''Host MAC/IP Synchronization'''. После этого появляется возможность передавать трафик PE, ближайшему к хосту. Этот метод совместим c MAC migration.

''Asymmetric IRB Forwarding'': L2 заголовок перезаписывает ingress PE перед отправкой пакета. Это позволяет dest PE обойтись без L3 lookup, когда он производит передачу пакета.

*Уменьшение утилизации полосы пропускания для multi-destination трафика между разными частями дата-центра в разных местах.
:*PE делают Proxy ARP: изучая ip хостов и Def GW.
:*P2MP or MP2MP LSPs между сторонами дата-центров.
*Поддерживает инкапсуляцию разных данных. Например, GRE tunnels с IPSEC.

=Конфигурация EVPN=
Пример конфига разбирается на примере лабы, поднятой в книге: Day One - EVPN

[[Файл:EVPN_laba.png|1000px]]

Для поддержки trio-based FPCs, требуется включение '''enhanced-ip'''
blair# set chassis network-services enhanced-ip

==В уровне ядра==
*OSPF, на всех интерфейсах. Также включаем TE внутри OSPF.
*MPLS с RSVP-TE LSP между всеми PE (full-mesh). LSP будут использоваться как для EVPN, так и для IP VPN.
*MP-BGP для EVPN и IP VPN. Конфигурируется сессия с P-роутером, который в свою очередь также является и RR (и советуют настроить bfd-detection). Включаем необходимые family: inet-vpn, evpn.

==На уровне доступа==
*В сторону CE настраиваем отдельный логический интерфейс для каждого instance с требуемыми вланами.

*ESI - Ethernet Segment ID: требуется для multi-homing. Первый октет = Type, остальные - ID. Вид: ''00:11:11:11:11:11:11:11:11:11''.

Задаем ''all-active'', что обеспечивает балансировку между линками CE <> PE.
*LACP даже с одним линком имеет смысл: дает возможность определить действительно ли по линку ходит трафик или нет. Если LACP развалится, значит сигнальные сообщения не проходят по физическим линкам внутри LACP. Также при добавлении или исключении линка из LACP не страдает передача трафика. LACP в лабе настроен между двумя PE и свитчем на стороне CE.

set interface xe-1/0/0 gither-options 802.3.ad ae0 '''hold-time up 180000 down 0'''

*Задается одинаковый system-id для LACP на обоих РЕ (Node's System ID, encoded as a MAC address). При этом СЕ свитч думает, что LACP установлен с одним устройством.
interfaces {
ae0 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
esi {
00:22:22:22:22:22:22:22:22:22;
all-active; }
aggregated-ether-options {
lacp {
'''system-id 00:00:00:00:00:02'''; }}

==Сервисы==
*'''EVPN VLAN-based''': один влан, который принадлежит одному bridge домену.
Пример конфига:
routing-instances {
EVPN-1 {
instance-type '''evpn''';
'''vlan-id 100''';
interface ae0.100;
routing-interface '''irb.100''';
route-distinguisher 11.11.11.11:1;
vrf-target target:65000:1;
protocols {
evpn {
'''default-gateway do-not-advertise'''; }}}}

interfaces {
irb {
unit 100 {
family inet {
address 100.1.1.1/24; }
'''mac 00:00:00:01:01:01'''; }}}

Для этого EVPN используется только 1 влан = 100, в данном случае.

mac 00:00:00:01:01:01 - для irb-интерфейсов одного EVPN в разных site, используют одинаковые ip/mac. Делается для упрощения конфига, уменьшения control plane перегрузки, и минимизации времени восстановления при падении PE.

default-gateway do-not-advertise - т.к. для irb указаны одинаковые ip/mac, то можно выключить функцию анонсирования MAC/IP binding между PE.

*'''EVPN VLAN-aware''': несколько пользователей с независимыми vlan и ip.
Оба сервиса могут использовать vlan translation (настраивается на PE), что дает возможность использовать разные вланы в разных site.

Хорошей практикой считается настраивать VLAN-aware, даже когда используется всего 1 vlan. Так сказать, задел на будущее.

Пример конфига:
routing-instances {
EVPN-2 {
instance-type '''virtual-switch''';
interface ae0.200;
route-distinguisher 11.11.11.11:2;
vrf-target target:65000:2;
protocols {
evpn {
'''extended-vlan-list 200-202''';
'''default-gateway advertise'''; }}
bridge-domains {
V200 {
vlan-id 200;
routing-interface irb.200; }
V201 {
vlan-id 201;
routing-interface irb.201;}
V202 {
vlan-id 202;
routing-interface irb.202; }}}}
interfaces {
irb {
unit 200 {
family inet {
address '''200.1.1.1/24'''; }
mac '''00:00:c8:01:01:01'''; }
unit 201 {
family inet {
address '''201.1.1.1/24'''; }
mac '''00:00:c9:01:01:01'''; }
unit 202 {
family inet {
address '''202.1.1.1/24'''; }
mac '''00:00:ca:01:01:01''' }}}

extended-vlan-list 200-202 - определяет список вланов, которые будут передаваться через ядро.

Пример настройки vlan-translation на PE:
interfaces {
ae0 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
esi {
00:22:22:22:22:22:22:22:22:22;
all-active; }
aggregated-ether-options {
lacp {
system-id 00:00:00:00:00:02; }}
unit 100 {
encapsulation vlan-bridge;
vlan-id 100;
family bridge; }
unit 200 {
family bridge {
interface-mode trunk;
vlan-id-list [ 200 201 '''202''' ];
'''vlan-rewrite {'''
'''translate 222 202'''; }}}}}

*'''IP-VPN''': За маршрутизацию между VLAN отвечает irb-интерфейс, присвоенный в общий IP VPN. Также через него можно осуществлять маршрутизацию и с внешним миром.

Можно добавлять разные irb в разные IP VPN, чтобы разделить L3 трафик.

Пример конфига:
routing-instances {
IPVPN-1 {
instance-type vrf;
interface irb.100;
interface irb.200;
interface irb.201;
interface irb.202;
route-distinguisher 11.11.11.11:111;
vrf-import IpVpnDiscardEvpnSubnets;
vrf-export IpVpnAddCommunities;
vrf-table-label;

policy-options {
prefix-list PL-EVPN {
100.1.1.0/24;
200.1.1.0/24;
201.1.1.0/24;
202.1.1.0/24; }
policy-statement IpVpnAddCommunities {
term 10 {
from {
prefix-list-filter PL-EVPN orlonger; }
then {
community add COMM-EVPN;
community add COMM-IPVPN-1;
accept; }}
term 100 {
then accept;}}
policy-statement IpVpnDiscardEvpnSubnets {
term 10 {
from community COMM-EVPN;
then reject; }
term 100 {
from community COMM-IPVPN-1;
then accept; }}
community COMM-EVPN members 65000:1234;
community COMM-IPVPN-1 members target:65000:101;}

- vrf-export IpVpnAddCommunities; - добавляет community помимо ipvpn (основное) еще и evpn (дополнительно обозначает evpn subnets and hosts).

- vrf-import IpVpnDiscardEvpnSubnets; - т.к. evpn subnets and hosts уже синхронизируются путем ''Host MAC/IP Synchronization'', то передавать эту информацию через IP VPN - избыточно, поэтому маршруты с таким community будут отброшены, прилетев на PE.

==Remote PE==
В лабе, удаленный PE31 получает все маршруты от других PE в сети. При этом в RI IP-VPN на нем настроен только vrf-target target:65000:101, который соответствует COMM-IPVPN-1, таким образом, маршруты с community, соответствующие EVPN, будут просто игнорироваться для этого site.

'''Aliasing''':

Также, на данном PE31 будут получены маршруты Data-Center 1 от двух PE, участвующих в multi-homing. Чтобы PE31 мог балансировать между ними нагрузку (балансировка применяется к L2 и L3), требуется настроить BGP особым образом:
bgp {
group Internal {
type internal;
'''family inet-vpn''' {
'''any'''; }
'''multipath''';
neighbor 1.1.1.1 {
'''local-address 31.31.31.31''';
bfd-liveness-detection {
minimum-interval 200;
multiplier 3;}}}}
policy-options {
policy-statement lb {
then {
'''load-balance per-packet'''; }}}
routing-options {
router-id 31.31.31.31;
autonomous-system 65000;
'''forwarding-table''' {
'''export lb'''; }}

=Траблшутинг EVPN=

==На уровне ядра==
*OSPF adjacencies
*MP-BGP sessions to P. Families: bgp.l3vpn.0, bgp.evpn.0, IPVPN-1.inet.0, EVPN-1.evpn.0, EVPN-2.evpn.0, and__default_evpn__.evpn.0.
*BFD session: show bfd session
*LSPs to all remote PE - are up.

==На уровне доступа==
*PE-CE links: interfaces are UP, LACP is ok.

==Multi-homing==
Несколько PE соединяются с одним CE. Это важная фитча. Обеспечивает надежную работу при link-fail или node-fail. Также обеспечивает балансировку для PE <> CE линков.

Для ее корректной работы требуется настройка одинакового ESI на разных multi-homing PE. Таким образом PE узнают друг о друге.

ES route имеет Type 4 и имеет несколько других важных полей (то, что будет прилетать на удаленный PE):
*Router's IP addr = loopback addr.
*ESI: 10 октетов. ES route будет принят PE только в том случае, если ESI для двух PE будет полностью совпадать.
*ES Import RT community - полученный из ESI. Представляет из себя только 6 октетов. Поэтому для разных ESI, community может быть одинаковым. То есть судя только по community нельзя точно определить подходит ли пришедший route, но такой дополнительный метод проверки тем не менее значительно уменьшает кол-во routes, которое требуется рассмотреть в дальнейшем PE.

Для проверки и просмотра полученных ES routes:
PE11> show route table bgp.evpn.0 detail | '''find "4:/1"'''
'''4:12.12.12.12:0::111111111111111111:12.12.12.12/304''' (1 entry, 0 announced)
*BGP Preference: 170/-101
Route Distinguisher: 12.12.12.12:0
Next hop type: Indirect
Address: 0x95c606c
...
Cluster list: 1.1.1.1
Originator ID: 12.12.12.12
Communities: '''es-import-target:11-11-11-11-11-11'''

Также в таблице ''default.evpn.evpn.0'' будут хранится все ES route локального PE, в том виде, когда к ним еще не присоединилась community конкретного EVI
PE11> show route table __default_evpn__.evpn.0 | find 4:
4:11.11.11.11:0::111111111111111111:11.11.11.11/304
*[EVPN/170] 04:40:23
Indirect
4:12.12.12.12:0::111111111111111111:12.12.12.12/304
*[BGP/170] 04:40:04, localpref 100, from 1.1.1.1
AS path: I, validation-state: unverified
> to 10.11.12.12 via ae1.0, label-switched-path from-11-to-12

===Designated forwarder===
Сразу после установления Multi-homing peering между PE выбирается Designated Forwarder для ES.

Выбор производится для каждого EVI в каждом ESI.

Выборы:
#сортировка по Lo addr (от меньшего к большему, как я понимаю)
#роутерам по-порядку назначаются номера, начиная с 0. Роутер с наименьшим номеров - стал DF.
#далее производится выбор DF для каждого vlana. V mod N (V = VLAN, N = кол-во PE в multi-homing). Если в EVPN несколько вланов, то берется наименьший vid.

Передачей BUM трафика занимается '''DF PE'''. Backup PE будет отбрасывать BUM.
cse@PE11> show evpn instance EVPN-1 esi 00:11:11:11:11:11:11:11:11:11 extensive
Instance: EVPN-1
Number of ethernet segments: 2
ESI: 00:11:11:11:11:11:11:11:11:11
Status: Resolved by IFL ae0.100
Local interface: ae0.100, Status: Up/Forwarding
Number of remote PEs connected: 1
Remote PE MAC label Aliasing label Mode
12.12.12.12 300688 300688 all-active
'''Designated forwarder: 11.11.11.11'''
'''Backup forwarder: 12.12.12.12'''
Advertised MAC label: 300976
Advertised aliasing label: 300976
Advertised split horizon label: 299984

Проверка int на возможность передачи BUM трафика:
cse@'''PE11'''> show interfaces '''ae0.100''' detail | find EVPN
EVPN multi-homed status:'''Forwarding''', EVPN multi-homed ESI Split Horizon
Label: 299984
Flags: Is-Primary
cse@'''PE12'''> show interfaces '''ae0.100''' detail | find EVPN
EVPN multi-homed status: '''Blocking BUM Traffic to ESI''', EVPN multi-homed ESI Split
Horizon Label: 299888
Flags: Is-Primary

===Auto-Discovery===
Multi-homed-PE пересылают всем удаленным PE два типа маршрутов:
====Auto-discovery route for ESI====

Для более быстрого восстановления используется этот механизм auto-discovery routes, также называемый ''MAC Mass Withdraw''. В случае, когда рвется линк между PE-CE, PE сбрасывает route, содержащий пачку маков.

Передаваемые маршруты имеют следующие параметры:
*RT, соответствующий EVI
*ESI
*ESI label extended community: split horizont label + multi-homing mode (all-active/single-active).

'''Split horizont label''' - для исключения петель при получении маршрута, от нескольких CE - ''Split Horizong filtering''. Когда non-DF передает пакеты DF-router'у в этом же EVI, он первым делом добавляет split hor label к этому пакету. DF, видя метку, не передает такой пакет обратно CE.

'''Label stack'''
*Transpotr label
*Inclusive Multicast Label
*Split Horizonf Label
*BUM traffic.

====Auto-Discovery route per EVI====
В all-active multi-homing есть Aliasing (load-balancing). Большинство изученных маков будут передаваться от PE1 из multi-homing, но при этом aliasing будет обеспечивать балансировку обратного трафика и второму PE2.

Для single-active: функция тоже будет работать в качестве обеспечения ''Backup-path''.

Auto-discovery route содержит:
*RT, соответствующий EVI
*ESI
*Aliasing Label
Когда PE изучает новый MAC, то PE отправляет MAC Advertisment route, который состоит из MAC, MPLS service label, ESI (от remote PE).

remote PE сравнивает полученный ESI с ESI в обоих Auto-Discovery routes и определяет состав multi-homing PEs, которым он сможет направить обратный трафик по MAC.

Когда remote PE отправляет пакет обратно PE1, отправившего MAC Advertisement route, используется '''service label'''.

Когда remote PE отправляет пакет обратно пиру PE1 (PE2), используется '''aliasing label'''.

Для каждого EVPN можно увидеть метки от remote PE.
show evpn instance EVPN-1 extensive

===Inclusive multicast===
Type = 3

Каждый PE передает Inclusive Multicast (IM) route для разрешения передачи BUM трафика.
*RT, сопоставляемый с EVI
*Ethernet tag ID = VLAN ID
*PMSI Tunnel Attribute - обозначение multicast технологии и IM MPLS метки.
PMSI Attr - это атрибут, использующийся для NG BGP Multicast VPN: P2MP, RSVP-TE LSPs, P2MP mLDP LSPs, PIM-SM trees.

PE получил пакет от CE: PE делает копию пакета, соответствующую каждому remote PE. Навешивает на пакет метку: обычно сначала это IM метка + transport метка.

Но в случает с multi-homed non-DF, с начала добавляется Split Horizont Label.

На удаленном PE: снимается transport label, распознается IM метка и BUM трафик.

*P2MP LSPs: эффективная утилизация полосы в ядре, но могут быть проблемы с масштабируемостью, т.к. нужно выбирать точку копирования трафика.

Чтобы избежать подобных проблем: используем чистый EVPN, где точка копирования трафика уже выбрана - ingress PE.
PE11> show route table EVPN-1.evpn.0 | find '''“3\:12”'''
3:12.12.12.12:1::100::12.12.12.12/304
*[BGP/170] 1d 17:37:16, localpref 100, from 1.1.1.1
AS path: I, validation-state: unverified
> to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-12

Наличие IM от каждого remote PE можно проверить тут:
PE11> show evpn instance EVPN-1 extensive

Проверить PMSI tunnel attribute можно так:
PE11> show route table EVPN-1.evpn.0 detail
3:21.21.21.21:1::100::21.21.21.21/304 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 21.21.21.21:1
PMSI: Flags 0x0: Label 311168: '''Type INGRESS-REPLICATION 21.21.21.21'''

==L2 процессы внутри EVPN==
===MAC learning===
Когда PE изучает новый MAC на EVI access interface, он добавляет MAC в соответствующую L2 forwarding table (MAC-VRF). Затем передает MAC Advertisment route остальным PE.

MAC Adv route:
*RT
*MAC
*Ethernet tag = VLAN ID
*ESI
*IP, если известен или если сконфигурирован IRB.
*MPLS service label / MAC route label
*Default Gateway Extended Community - что сконфигурировано на IRB.
*MAC Mobility Extended Community.

Как только изучен MAC, PE передает MAC Adv route без привязки к IP. Как только появилась привязка, PE посылает новый MAC Adv route. Этот процесс - ''Host Mac/IP Synchronization.

PE также передает MAC/IP локального IRB интерфейса, используя Def Gateway Ext Community, которое сигнализирует удаленному PE, что он должен роутить трафик от имени другого PE. Этот процесс - ''Default Gateway Synchronization''.

ESI - для балансировки, при работе multi-homing PE. Multi-homed PEs анонсируют свою связь через одинаковый ESI (в Auto Discovery route). Когда remote PE получает MAC adv route, видит в нем ESI, понимает какие PE относятся к этому ESI и при необходимости послать трафик к MAC, балансирует между PE1 и PE2.

Также ESI полезно при передаче MAC между multi-homing пирами. PE1 получил MAC от пира, next-hop = local interface PE1. Локальный интерфейс PE1 будет в приоритете, по сравнению с ядром. Поэтому когда на PE1 прилетит MAC adv route от remote PE, то он будет просто отброшен.

PE11> show evpn instance EVPN-1 extensive
PE11> show evpn mac-table

Отображение MAC, ESI, IP (если есть). По сути тоже самое, что и forwarding table
PE11> show evpn database instance EVPN-1

Если для MAC есть IP, то его можно посмотреть так:
PE11> show route table EVPN-1.evpn.0 evpn-mac-address 00:50:56:8c:76:67
2:22.22.22.22:1::100::00:50:56:8c:76:67::100.1.1.10/304
*[BGP/170] 1d 01:03:50, localpref 100, from 1.1.1.1
AS path: I, validation-state: unverified
> to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-22

===L2 forwarding and aliasing===
Сама функция описана выше. Проверка:
PE11> show evpn mac-table
Routing instance : EVPN-1
Bridging domain : __EVPN-1__, VLAN : 100
MAC MAC Logical NH RTR
address flags interface Index ID
00:00:09:c1:b0:d7 DC '''1048609''' 1048609

Чтобы понять что это за PE, сначала ищем какому ESI принадлежит next-hop:
PE11> show evpn instance EVPN-1 extensive
Instance: EVPN-1
Route Distinguisher: 11.11.11.11:1
VLAN ID: 100
Number of ethernet segments: 2
ESI: 00:22:22:22:22:22:22:22:22:22
Status: Resolved by NH '''1048609'''
Number of remote PEs connected: 2
'''Remote PE MAC label Aliasing label''' Mode
'''21.21.21.21 300848 300848''' all-active
'''22.22.22.22 301040 301040''' all-active

Затем ищем метку для ESI:
PE11> show route table mpls.0 | match EVPN-1 | match esi
301184 *[EVPN/7] 2d 03:35:55, routing-instance EVPN-1, route-type Egress- MAC, ESI 00:11:11:11:11:11:11:11:11:11
'''301200 *[EVPN/7] 2d 03:35:55, routing-instance EVPN-1, route-type Egress- MAC, ESI 00:22:22:22:22:22:22:22:22:22'''

Ищем next-hop для этой метки:
PE11> show route label 301200
301200 *[EVPN/7] 2d 03:44:05, routing-instance EVPN-1, route-type Egress-
MAC, ESI 00:22:22:22:22:22:22:22:22:22
> to 10.11.1.1 via xe-1/2/0.0, '''label-switched-path from-11-to-21'''
to 10.11.1.1 via xe-1/2/0.0, '''label-switched-path from-11-to-22'''

При проверке Aliasing в лабе, выявили несколько мест, где балансируется трафик.
*CE к multi-homed PE1, PE2.
*PE балансируют при отправке к remote PE - чисто EVPN балансировка! '''Per flow.'''
*Несколько LSP могут также делать балансировку.
*LAG в разных местах.

===MAC mobility===
Переместили тачку в новый data-center. Новый PE изучил новый для себя MAC. Старый PE получил MAC Adv route и:
#Обновил свою forwarding table
#MAC Mobility Extended Community включает в себя порядковый номер, который увеличивается при каждом новом перемещении тачки. Используется для определения MAC-flapping.

==L3 процессы внутри EVPN==
===Синхронизация Default Gateway===
Функция для оптимизированного роутинга исходящего трафика от VM к любому адресу назначения и входящего трафика к VM по оптимизированному пути, при миграции VM в другую локацию.

#Конфигурируем IRB во VLAN или bridge domain.
#Добавляем IRB в IP VPN.
#Как только IRB начал выступать в качестве Def GW, PE передает MAC/IP Adv route (Def GW Ext Community) остальным PE и VM могут иметь связь с любым адресом назначения.
#Интеграция между IP VPN и EVPN требуется для Aliasing между multi-homed PE.

В лабе в примере для всех IRB.100 на всех site специально заданы одинаковые IP/MAC, для упрощения конфига. При таком варианте синхронизация осуществляется как бы статически. + в vrf задано: ''evpn default-gateway do-not-advertise''.

В обычном случае при задании разных mac/ip для irb, будем видеть следующее:
PE11> show route table EVPN-2.evpn.0 | match “200.1.1./”
2:22.22.22.22:2::200::00:00:c8:01:01:01::200.1.1.1/304
2:22.22.22.22:2::201::00:00:c9:01:01:02::201.1.1.2/304
2:22.22.22.22:2::202::00:00:ca:01:01:01::202.1.1.1/304

PE11> show bridge evpn peer-gateway-macs
Routing instance : EVPN-2
Bridging domain : V201, VLAN : 201
Installed GW MAC addresses:
00:00:c9:01:01:02

PE11> show route table EVPN-2.evpn.0 detail evpn-ethernet-tag-id 201 evpn-macaddress 00:00:c9:01:01:02
EVPN-2.evpn.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden)
2:22.22.22.22:2::'''201::00:00:c9:01:01:02::201.1.1.2'''/304 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 22.22.22.22:2
Next hop type: Indirect
Source: 1.1.1.1
Protocol next hop: 22.22.22.22
AS path: I (Originator)
Cluster list: 1.1.1.1
Originator ID: 22.22.22.22
'''Communities: target:65000:2 evpn-default-gateway'''
Import Accepted
'''Route Label: 300288''' - service label
ESI: 00:00:00:00:00:00:00:00:00:00
Localpref: 100
Router ID: 1.1.1.1
Primary Routing Table bgp.evpn.0

===Inter-VLAN Routing===
Функция ''Asymmetric IRB Forwarding'' - маршрутизация трафика между хостами разных EVPN VLANs, соединенных разными PE.

Ingress PE (Def GW) передает пакеты таким образом, который исключает необходимость делать route lookup в IP VPN VRF на egress PE. Вместо этого egress PE делает lookup в MAC-VRF по EVI dest host.

Если egress PE является multi-homed, то ingress PE может делать aliasing.

Что происходит на PE, когда он изучает новый MAC/IP:
*Появляется запись в IP VPN RVF: protocol '''EVPN''', next-hop IRB.vlan.
*Remote PE добавит полученную запись в IP VPN VRF: protocol '''BGP'''.

*PE передаст MAC/IP Adv route всем remote PE. Remote PE добавят полученный route в IP VPN VRF: protocol '''EVPN'''.

Т.о. на remote PE будет 2 записи, изученные по разным протоколам. Разница:
*BGP: VPN label + transport label (or tunnel label)
*EVPN: более сложный механизм для передачи пакета: Ingress PE перезаписывает Ethernet header (dest MAC, vlan) на значение, соответствующее хосту назначения. А soucre MAC теперь будет соответствовать local IRB MAC. Затем добавляет service или aliasing label + transport label.

BGP route - избыточные, их можно заблочить с помощью policy.

Проверяем.

В лабе: PE21: irb.200 - 200.1.1.26

Local PE:
PE21> show route 200.1.1.26
IPVPN-1.inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
200.1.1.26/32 *[EVPN/7] 00:04:52
> via irb.200

Remote PE:
PE11> show route 200.1.1.26
IPVPN-1.inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
200.1.1.26/32 *[EVPN/7] 00:49:50
> to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-21
to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-22

Layer 2 Ethernet header rewrite
PE11> show route 200.1.1.26 detail
IPVPN-1.inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
200.1.1.26/32 (1 entry, 1 announced)
*EVPN Preference: 7
Next hop type: Indirect
Next-hop reference count: 2
Next hop: 10.11.1.1 via xe-1/2/0.0, selected
'''Label-switched-path from-11-to-21'''
'''Label operation: Push 300256, Push 302448(top)'''
Load balance label: Label 300256: None; Label 302448: None;
Session Id: 0x152
Next hop type: Router, Next hop index: 696
Next hop: 10.11.1.1 via xe-1/2/0.0
'''Label-switched-path from-11-to-22'''
'''Label operation: Push 300320, Push 302464(top)'''
Label TTL action: no-prop-ttl, no-prop-ttl(top)
Load balance label: Label 300320: None; Label 302464: None;
Session Id: 0x152
Protocol next hop: 21.21.21.21
Label operation: Push 300256
Label TTL action: no-prop-ttl
Load balance label: Label 300256: None;
Composite next hop: 0x9569bac 643 INH Session ID: 0x150
Ethernet header rewrite:
'''SMAC: 00:00:c8:01:01:01, DMAC: 00:00:09:c1:b0:d4'''
'''TPID: 0x8100, TCI: 0x00c8, VLAN ID: 200, Ethertype: 0x0800'''
Indirect next hop: 0x96ae310 1048596 INH Session ID: 0x150
Protocol next hop: 22.22.22.22
Label operation: Push 300320
Label TTL action: no-prop-ttl
Load balance label: Label 300320: None;
Composite next hop: 0x9569b50 645 INH Session ID: 0x14f
Ethernet header rewrite:
'''SMAC: 00:00:c8:01:01:01, DMAC: 00:00:09:c1:b0:d4'''
'''TPID: 0x8100, TCI: 0x00c8, VLAN ID: 200, Ethertype: 0x0800'''

PE11> show evpn database instance EVPN-2 vlan-id 200
PE11> show evpn database instance EVPN-2 vlan-id 200 extensive

PE11> show evpn instance EVPN-2 extensive | find segments
Number of ethernet segments: 2
ESI: 00:22:22:22:22:22:22:22:22:22
Status: Resolved by NH 1048590
Number of remote PEs connected: 2
Remote PE MAC label Aliasing label Mode
22.22.22.22 '''300320 300320''' all-active
21.21.21.21 '''300256 300256''' all-active

Для проверки работы Aliasing, смотрим forwarding table:
PE11> show route forwarding-table destination 200.1.1.26 extensive | find IPVPN-1
Routing table: IPVPN-1.inet [Index 7]
Destination: 200.1.1.26/32
Nexthop:
Next-hop type: composite Index: 643 Reference: 2
Next-hop type: indirect Index: 1048596 Reference: 4
Nexthop:
Next-hop type: composite Index: 645 Reference: 2
Next-hop type: indirect Index: 1048597 Reference: 4

PE11> clear mpls lsp statistics
PE11> show mpls lsp statistics ingress
Ingress LSP: 4 sessions
To From State Packets Bytes LSPname
12.12.12.12 11.11.11.11 Up 2 148 from-11-to-12
21.21.21.21 11.11.11.11 Up 9942 2545152 from-11-to-21
22.22.22.22 11.11.11.11 Up 9943 2545408 from-11-to-22
31.31.31.31 11.11.11.11 Up 0 0 from-11-to-31

Для L3 балансировка также осуществляется с нескольких местах.

===Inbound Routing from IP VPN Site===
Интеграция IP VPN и EVPN положительно сказывается и на оптимизации входящего к хостам трафика, если он с источником находится не на одном site.

Egress PE, получив IP/MAC route от ingress PE, добавляет этот маршрут как изученный по BGP в VRF.table. После этого есть возможность смаршрутизировать трафик напрямую к data-center PE, ближайшему к хосту.

При миграции хоста, роутинг становился сложнее, т.к. не меняется обновление MAC/IP route и host route занимает некоторое время. Во время переезда у remote PE может сохраниться старая инфа о хосте и он пошлет туда трафик.

Учитывая этот небольшой недостаток, Mac mobility для L3 все же работает.

=MP-BGP EVPN Route Summary=
*Type 1: '''Ethernet Auto-Discovery''': per ESI, used for fast convergence (MAC Mass Withdrawal) and Split Horizont filtering. For Aliasing. Used only when multi-homing used. ESI Label Extended Community, includes multi-homing mode.
*Type 2: '''MAC Advertisement''': MAC and MAC/IP. Used for MAC learning, MAC Mobility, Aliasing, Def GW Synch., Asymmetric IRB Forwarding. Learned MAC/IP bindings generate EVPN host routes, which added to IP VPN VRF for optimizing inbound routing to host. Def GW Ext Community - for MAC/IP of RIB. MAC Mobility Ext Community - for MAC flapping.
*Type 3: '''Inclusive Multicast''': Includes IM label, used when forwarding BUM traffic between PEs.
*Type 4: '''Ethernet Segment''': For discovery of multi-homed neigh and DF election. Only used when multi-homing is configured. ES-Import Ext Community - from ESI, used by receiving PE to filter incoming advertisment.
show route table bgp.evpn.0

Route Formats:
{| class="wikitable"
|-
! Ресурс !! ссылка !! описание
|-
|1 - Ethernet Auto-Discovery per ESI||1:21.21.21.21:0::222222222222222222::FFFF:FFFF/304||
*Route Type “1”
*RD unique to advertising
*ESI
*Ethernet Tag Id – reserved“0xFFFFFFFF”
|-
|1 - Ethernet Auto-Discovery per EVI || 1:21.21.21.21:1::222222222222222222::0/304 ||
*Route Type “1”
*RD of advertising PE’s EVI
*ESI
*Ethernet Tag Id “0”
|-
|2 - MAC Advertisement||2:21.21.21.21:1::100::00:00:09:c1:b0:d7/304||
*Route Type “2”
*RD of advertising PE’s EVI
*VLAN ID
*MAC Address
|-
|2 - MAC/IP Advertisement||2:21.21.21.21:1::100::00:00:09:c1:b0:d7::100.1.1.29/304||
*Same as MAC Advertisement but includes host’s IP address
|-
|3 - Inclusive Multicast||3:21.21.21.21:1::100::21.21.21.21/304||
*Route Type “3”
*RD of advertising PE’s EVI
*VLAN ID
*Originator PE Loopback IP address
|-
|4 - Ethernet Segment||4:12.12.12.12:0::111111111111111111:12.12.12.12/304||
*Route Type “4”
*RD unique to advertising PE
*ESI
*Originator PE LoopbackIP address
|}
=High Availability=
==Падене линка ==
При падении линка (CE <> multi-homing PE), статус EVI тоже станет - down. И PE уберет все прежде переданные IP VPN и EVPN маршруты, Auto-Discovery per ESI, Auto-Discovery per EVI.
Также, если PE был DF, то эту роль подхватит backup router.

==Восстановление линка==
Если сконфигурирован hold-up timer, то ничего не изменится, пока таймер не истечет.

Когда таймер истек, LACP между PE <> CE собрался, EVIs на PE стали активными, PE передает ES, IM, Auto-Discovery routes => new DF election. Параллельно с этим PE уже начинает получать трафик от remote PEs и CE.

==Падение узла==
Отключили multi-homing PE: LSP, которые на него терминировались - упадут (Path ERr message). У remote PE упавший PE удалится из возможных вариантов маршрутов с next-hop PE - для L2 и L3. Трафик без перерыва просто будет передаваться второму multi-homing PE. Также до PE упадут все протоколы маршрутизации (OSPF, MP-BGP). Второй multi-homed PE станет DF.

==Восстановление узла==
Опять же, если настроен hold-timer на интерфейсах, то при восстановлении PE, все процессы восстановятся не сразу. Таймер лучше настроить, т.к. без него при поднятии линков трафик начнет передаваться к PE, но на PE еще не будут установлены OSPF, BGP, LSP... Трафик полетит в никуда.

Наличие LACP между CE и PE значительно уменьшает потерю пакетов.

=Дополнительная информация=
*[[DC]]
*[[L2VPN]]
*[[VPLS]]

Load-balancing

2021-07-18T11:06:45Z

Наталия Бобкова: Новая страница: «{{#description2:Load-balancing. Per-packet load-balancing. Per-flow load-balancing. Конфигурация filter-based forwarding. Multitopology. Информ...»

{{#description2:Load-balancing. Per-packet load-balancing. Per-flow load-balancing. Конфигурация filter-based forwarding. Multitopology. Информация для подготовки к экзаменам Juniper.}}
=Описание load-balancing=
Load balancing между равнозначными линками дает возможность передавать трафик к одному и тому же dest address сразу по двум ликам, распределяю нагрузку между ними.

Балансировка может быть настроена одним из методов: per-packet или per-flow.

==PER-PACKET==
Пакеты передаются в произвольном порядке (round-robin) по равнозначным (с одинаковой стоимостью) путям. При этом равнозначные линки загружаются равномерно. Но создается дополнительная нагрузка на сеть: в процессе передачи пакетов, к хосту назначения пакеты могут прийти в неверном порядке, что приводит к тому, что хост назначения должен заниматься реордерингом пакетов, либо хост источник должен будет пересылать заново потерянные пакеты. Всё это - дополнительная нагрузка на сеть.

==PER-FLOW==
Индивидуальные потоки трафика передаются по одному или второму линку. При этом уходит проблема с реордерингом пакетов >> на application level меньше зажержек. Также становится возможным эффективное внедрение QOS, т.к. на сети одинаковый пользовательский трафик будет гулять потоками.

По умолчанию поток (flow) - это трафик, имеющий один вх интерфейс, одинаковый src и dst address, а также одинаковый протокол. Можно включить дополнительные элементы 3 и 4 уровня, но это требует доп конфигурации.

Для распознавания потока по параметрам 3/4 уровней, настраиваем hash-key:
set forwarding-options hash-key family inet layer-3
set forwarding-options hash-key family inet layer-4
set forwarding-options hash-key family mpls label-1
set forwarding-options hash-key family mpls label-2
set forwarding-options hash-key family mpls payload ip
set forwarding-options hash-key family multiservice source-mac
set forwarding-options hash-key family multiservice destination-mac
set forwarding-options hash-key family multiservice payload ip layer-3

Для IP обязательно указывать l3 и l4. Иначе не будет работать ни l3, ни l4.
Для ipv6 load-balancing по дефолту делается по l3 и l4, так что дополнительной настойки не требует.
Для mpls [family mpls] и vpls [family multiservice] также можно поменять дефолтные hash-key.

'''IGP load-balancing''': выбирается один возможный путь к адресу назначения. Даже есть есть обходные пути. Когда добавляются или удаляются возможные next-hop - junos заново делает выбор пути.

'''BGP load-balancing''' = per-prefix load balancing: включается в случае, когда у маршруты получены от IBGP соседа с одинаковым next-hop. Далее роутер резолвит next-hop и в случает, если до него есть несколько путей, трафик до него пойдет по рандомно-выбранным путям. Но при этом трафик до каждого префикса будет следовать только по одному выбранному пути.

То есть если от ibgp-пира прилетело 20 префиксов, где в качестве hext-hop стоит ip ibgp-пира: рандомным образом (используя hashing алгоритм) трафик до ibgp-пира будет выбран одним из путей. То есть для 15-ти префиксов трафик до ibgp-пира пойдет одним путем, для 5ти - другим. (или 10/10, то есть из-за рандомности может возникнуть вариант распределения 20/0 - тогда ни о какой балансировке речи и не идёт). Поэтому погалаться полностью на дефолтное поведение не стоило бы.

==Конфигурация==
Настраиваем политику и применяем ее. В политике можно указать конкретные префиксы, в сторону которых будет балансироваться трафик. Либо если не будет конкретики по префиксам, то баланситься будет весь трафик.
set policy-options policy-statement load-balance then load-balance per-packet
set routing-options forwarding-table export load-balance

{{note|text = Несмотря на то, что в конфиге задаем load-balance per-packet, но всех современных роутерах это равнозначно per-flow. Балансировка будет работать per=flow! Только для роутерах в процессором Internet Processor I ASIC реально будет per-packet}}

==Мониторинг==
До применения:
> show route forwarding-table vpn mgmt destination 10.11.0.72/29
Routing table: mgmt.inet
Internet:
Enabled protocols: Bridging, All VLANs,
Destination Type RtRef Next hop Type Index NhRef Netif
10.11.0.72/29 user 0 indr 1052491 22
ulst 1051444 2
212.1.241.53 Push 35 11727 2 xe-1/0/4.10
После применения:
> show route forwarding-table vpn mgmt destination 10.11.0.72/29
Routing table: mgmt.inet
Internet:
Enabled protocols: Bridging, All VLANs,
Destination Type RtRef Next hop Type Index NhRef Netif
10.11.0.72/29 user 0 indr 1052491 22
212.1.240.179 Push 35, Push 933692(top) 12775 2 ae26.910
212.1.241.53 Push 35 11727 2 xe-1/0/4.10

Примененные изменения в load-balancing можно увидеть только в forwarding-table! В routing-table всё будет как прежде.

ulst - это список unicast ip next-hop. Пакеты, посленнаые к этому next-hop, отправляются к любому из next-hop в листе.

=Filter-based forwarding=
При этом методе балансировки на выбор пути будет влиять не только dst адрес, что делает данный тип балансировки более гибким. С помощью firewall filter пакеты классифицируются и для них определяется путь в рамках данного роутера.

Поддерживается для IPv4 и IPv6.

Можем пустить трафик от src address 10.10.0.0/24 до dst address 1.1.1.1/32 через одного ISP2, а трафик от src address 10.10.1.0/24 до dst address 1.1.1.1/32 через второго ISP2.

==Конфигурация==
[[Файл:Filter-based forwarding.png|600px|центр]]
R1:
Добавляем и применяем фильтр:
set family inet filter regions-to-cdn term match-region-1 from source-address 10.10.0.0/24
set family inet filter regions-to-cdn term match-region-1 then routing-instance ISP-1
set family inet filter regions-to-cdn term match-region-2 from source-address 10.10.1.0/24
set family inet filter regions-to-cdn term match-region-2 then routing-instance ISP-2
set family inet filter regions-to-cdn term all-accept then accept
set interfaces xe-0/0/0 unit 0 family inet filter input regions-to-cdn

Последний терм добавляем, чтобы остальной трафик, кроме src 10.10.0.0/24 и src 10.10.0.0/24 не дропался на интерфейсе, где будет применен filter regions-to-cdn.

Для каждого ISP добавляем RI:
set routing-instances ISP-1 instance-type forwarding
set routing-instances ISP-1 routing-options static route 0.0.0.0/0 next-hop 172.16.0.2
set routing-instances ISP-2 instance-type forwarding
set routing-instances ISP-2 routing-options static route 0.0.0.0/0 next-hop 172.16.0.6

Для копирования интерфейсных маршрутов, которые необходимы для next-hop resolve создаем rib-groups:
set routing-options interface-routes rib-group inet ISP-to-inet0
set routing-options rib-groups ISP-to-inet0 import-rib inet.0
set routing-options rib-groups ISP-to-inet0 import-rib ISP-1.inet.0
set routing-options rib-groups ISP-to-inet0 import-rib ISP-2.inet.0

==Проверка==
В RI кроме static route должны появиться маршруты src и p2p ISP сетей.
> show route table ISP-1.inet.0
> show route table ISP-2.inet.0
Трассировка с src netw 10.10.0.0/24 и 10.10.1.0/24 покажет разные маршруты до 1.1.1.1/32

==instance-import вместо rib-group==
Для тех, что не хочет использовать rib-groups, можно применить аналогичный по результату метод: instance-import

set policy-options policy-statement ISP-1-import from instance master = inet.0
set policy-options policy-statement ISP-1-import then accept

set routing-instances ISP-1 instance-type forwarding
set routing-instances ISP-1 routing-options static route 0.0.0.0/0 next-hop 172.16.0.2
set routing-instances ISP-1 routing-options instance-import ISP-1-import

=Multitopolgy=
Для каждого типа трафика можно создать свою тополонию сети >> свою forwarding-table. Можно использовать для inet и inet6 family. Пакеты одного forwarding-class определяем в ту или иную топологию. По умолчанию, весь трафик использует одну топологию для разных forwarding-class.

==Конфигурация==
Inet family
set routing-options topologies family inet topology voice-topology
set interfaces xe-0/0/1 unit 0 family inet filter input voice-filter
set firewall family inet filter voice-filter term af-traffic from forwarding-class assured-forwarding
set firewall family inet filter voice-filter term af-traffic then topology voice-topology
Inet6 family
set routing-options topologies family inet topology voice-topology
set interfaces xe-0/0/0 unit 0 family inet6 filter input cdn-filter
set firewall family inet6 filter cdn-filter term ef-traffic from forwarding-class ef
set firewall family inet6 filter cdn-filter term ef-traffic then topology cdn-topology

=Дополнительная информация=
*[[Static, Aggregate, Generate route]]
*[[Martians]]
*[[High Availability]]

Файл:Filter-based forwarding.png

2021-07-18T11:06:15Z

Наталия Бобкова:

BGP

2021-07-18T11:00:50Z

Наталия Бобкова: /* BFD */

{{#description2:BGP в Juniper. Состояния соседства BGP. Сообщения. Атрибуты BGP. Local preference. AS Path. Next-hop. Communities. Механизмы управления трафиком. Multipath. Multihop. Route Reflection. Confederations. Route damping. Blackhole. }}
BGP - протокол маршрутизации между AS. Path-vector protocol.

'''IBGP''' - соседство внутри AS. Соседство строится обычно на Lo адресах.

'''EBGP''' - соседство между разными AS. Соседство строится на p2p адресах.

Поддерживает аутентификацию: MD5. Можно настроить key-chain, с указанием когда какой ключ использовать. Аутентификация применяется на разных уровнях protocols bgp.
=Состояния соседства=
http://habrastorage.org/getpro/habr/post_images/442/780/549/442780549c2f45cdda10773121b2800d.png

Для установления соседства используется TCP:179.
*'''Idle''': all incoming connections - refused. Инициализация BGP ресурсов и подготовка к установлению TCP. Если роутер завис в состоянии Idle - проверить наличие маршрута к соседу.
*'''Connect''': процесс установления TCP сессии. Роутер слушает TCP 179. Если сессия установилась, то роутер отправляет Open message и переходит в OpenSent состояние. Если TCP не установилась, то роутер переходит в Active состояние и запускает заново ConnectRetryTimer.
*'''Active''': local router становится активным инициатором TCP-сессии. В состоянии Active - когда ответил на прилетевший TCP. Если роутер завис в Active, проверяем: связность, прохождение по tcp:179, корректность настройки BGP с двух сторон.
*'''OpenSent''': Open отправлен локальным роутером и роутер ждет ответа (Open) от соседа.
*'''OpenConfirm''': Open сообщение получено от соседа и роутер ждет Keepalive или Notification message. Если от соседа не приходит keepalive до истечения hold timer, то роутер генерирует Notification message, с инфо, что hold timer expired и переведет сессию в Idle. Если keepalive получен, то соседство переходит в Established state.
*'''Established''': BGP сессия установлена, пиры начинают обмениваться информацией, используя: Update, Keepalive, Notification сообщений.

Hold timer может быть разным у пиров. При установлении сессии будет выбран наименьший.

==Tips==
Если сессия установилась в Established, но через какое-то время перешла в Idle по Hold timer expared (скорее всего через 90sec = 3*keepalive), то первым делом проверьте MTU на канале между роутерами.

Если MTU где-то по пути зарезан/не соответствует MTU на интерфейсах bgp-пиров, можно либо решить вопрос с MTU на найденном проблемном участке, либо можно установить для сессии вручную размер mss (maximum segment size):
set protocols bgp group clients neighbor 1.1.1.1 tcp-mss 1470

Признаки подобной проблемы в логах:
Jan 1 00:18:18.553797 bgp_io_mgmt_cb:1777: NOTIFICATION sent to 1.1.1.1 (Internal AS 64777): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 1.1.1.1 (Internal AS 64777), socket buffer sndcc: 0 rcvcc: 0 TCP state: 4, snd_una: 733415251 snd_nxt: 733415251 snd_wnd: 16384 rcv_nxt: 4248562819 rcv_adv: 4248579203, hold timer 90s, hold timer remain 0s, last sent 6s, TCP port (local 52746, remote 179)
Jan 1 00:18:18.553889 BGP SEND message type 3 (Notification) length 21
Jan 1 00:18:18.553901 BGP SEND Notification code 4 (Hold Timer Expired Error) subcode 0 (unused)
Jan 1 00:18:18.554014 bgp_peer_close_and_restart: closing peer 1.1.1.1 (Internal AS 64777), state is 7 (Established) event HoldTime
Jan 1 00:18:18.554064 RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 1.1.1.1 (Internal AS 64777) changed state from Established to Idle (event HoldTime) (instance master)

=Сообщения=
Все сообщения имеют '''Header'''
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Marker |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

BGP header содержит:
:*'''marker''' - 16 октетов, установлены в "1". Обозначает, что это bgp-пакет
:*'''lenght''' - размер пакета (16bit)
:*'''type''' - тип сообщения
:** 1 - OPEN
:** 2 - UPDATE
:** 3 - NOTIFICATION
:** 4 - KEEPALIVE
:**5 - ROUTE-REFRESH [определен в RFC 2918]

'''Типы пакетов:'''
*'''Open''' (type 1) - отправляется только на стадии установления соседства. Содержит параметры BGP соседа: AS, auth-type (+ ключ, если есть аутентификация).
*'''Update''' (type 2) - передает info о добавлении или удалении маршрутов между соседями. Update содержит в себе Path, его атрибуты и вложенные префиксы, у которых эти атрибуты одинаковые. Не отправляются по таймеру, приходят, только когда изменился сам префикс, его атрибуты или BGP-сессия. В зависимости от policy, на локальном роутере, часть routing info может быть отброшена и помещена в hidden.
*'''Notification''' (type 3) - в случае если что-то пошло не так: не прошел keepalive или update, пришла не поддерживаемая опция, ... Существуют стандартизированные коды ошибок (operation code | opcode). Пакет состоит из header + opcode+subcode + data (описание ошибки - для диагностики).
*'''Keepalive''' (type 4)- для удостоверения, что с соседством все ok. Отправляется каждые 30 sec. По дефолту hold-timer = 3 * keepalive = 90sec - время, после которого соседи рушат соседство (если в это время не пролетело ни одного keepalive). Можно выставить holdtimer = 0. Если у одного соседа = 0, у другого нет, то будет согласовано ненулевое значение holdtimer для сессии.
{{note|text=keepalive message = BGP header без payload}}
*'''Refresh''' - soft clearing BGP сессии.

=BGP Operations=
BGP хранит маршруты в трех местах:
*Adjacency-RIB-IN: все полученные маршруты от пиров
*RIB-Local: маршруты локального роутера, используемые для передачи трафика. Тут хранятся только активные маршруты.
*Adjacency-RIB-OUT: маршруты, которые будут отправляться пирам. Передаваться могут только активные маршруты. ('''advertise-inactive''' исправляет данную ситуацию).

Передача маршрутов производится по правилам (чтобы избежать routing loops):
#IBGP пиры передают маршруты, полученные от EBGP другим IBGP пирам.
#EBGP пиры передают маршруты, полученные от EBGP и IBGP другим EBGP пирам
#IBGP пиры не передают маршруты, полученные от других IBGP пиров. Поэтому для того, чтобы получить всю маршрутную информацию, требуется full-mesh связность. Либо использование RR.

По умолчанию IBGP пиры не меняют next-hop для маршрутов, полученных от EBGP.

Решается:
* настройкой '''next-hop self''' в рамках export policy к remote PE/RR.
* добавить p2p интерфейс с EBGP пиром в IGP как passive.
* анонс p2p сети по IGP. Export policy для IGP протокола.
* настройки статического маршрута на каждом IBGP до удаленного EBGP пира.
* настроить IGP соседство с EBGP пиром.

=Атрибуты (BGP attributes)=
Включаются в Update сообщения и описывают BGP префиксы. Атрибуты используются для выбора активного пути.
Атрибуты, при выборе best, считаются лучшими с наименьшими значением
Это правило касается всех атрибутов, кроме Local Preference

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

==Local preference==
'''✔️Well-known Discretionary'''
* Указывает маршрутизаторам внутри автономной системы как выйти за её пределы.
* Больший приоритет выигрывает.
* Этот атрибут передается только в пределах одной автономной системы => работает только для IBGP.
* На маршрутизаторах Cisco и Juniper по умолчанию значение атрибута — 100.
* Если EBGP-сосед получает обновление с выставленным значением local preference, он игнорирует этот атрибут.
* В Junos lpf можно задать через policy и в protocol bgp. Если задан обоими способами, то будет назначен lpf из policy.
* Обычно используется на бордерах.
{{note|text=Когда в сети есть 2 бордера, которые получают один и тот же маршрут извне, и бордеры навешивают одинаковый повышенный lpf через export policy, в таком случае соседи IBGP получат маршрут с измененным lpf, но трафик не сможет по-правильному пути выйти из AS. Из-за того что бордеры тоже друг от друга будут получать маршрут с повышенным lpf. Решение: правильно менять lpf через import policy. }}

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

Используется для:
* обнаружения петель
* влияние на path selection с помощью prepending (делается через export policy)
set protocols bgp group int export longer-as-path
set policy-options policy-statement longer-as-path term 1 then as-path-prepend "1111 1111 1111"

show route advertising-protocol bgp 10.200.86.2
inet.0: 32 destinations, 32 routes (32 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.17.0.0/24 Self 100 '''1111 1111 1111 [1111] I'''

'''Обозначение:'''
* [] - 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|Список регулярных выражений для AS Path}}
. - любой знак (одна точка - один любой знак, 3 точки - три любых символа).

==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 на выходе (export к IBGP):
set policy-options policy-statement nexthop-self term localpref then next-hop self

Или же на входе (import от EBGP peer):
set policy-options policy-statement nexthop-peer term localpref then next-hop ''peer-address''

==Origin==
'''✔️Well-known Mandatory'''
Атрибут '''Origin''' — указывает на то, каким образом был получен маршрут в обновлении. Меняется с помощью policy.
{| class="wikitable"
|+Возможные значения атрибута
|-
|'''0'''
|IGP
|NLRI получена внутри исходной автономной системы
|-
|'''1'''
| EGP
| NLRI выучена по протоколу Exterior Gateway Protocol (EGP) - протокол уже давно не используется.
|-
|'''2'''
| Incomplete
| NLRI была выучена каким-то другим образом, скорей всего через redistribution.
|}

==Atomic aggregate==
'''✔️Well-known Discretionary'''

==Aggregator==
'''✔️Optional Transitive'''

==Communities==
'''✔️Optional Transitive'''
* Тегирование маршрутов
* Существуют предопределенные значения (well-known), которые не требуется определять локально на своем оборудовании
* По умолчанию не пересылаются соседям
* Одному маршруту может быть присвоено несколько communities
*Community могут быть критерием в policy для изменения других атрибутов BGP, например lpf.
* Один из вариантов применения: передается соседней 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-test'' detail

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

===Действия с community===
*add - добавляет к текущим community префикса указанное community
*delete - удаляет только указанное community
*set - заменяет существующие community на указанное

==Multi exit discriminator (MED)==

'''✔️Optional Non-transitive'''

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

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

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

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

MED назначается с помощью policy.
===Возможные операции с 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''':
* Позволяет назначить "вес" различным путям локально на маршрутизаторе.
* Используется в тех случаях, когда у одного маршрутизатора есть несколько выходов из автономной системы (сам маршрутизатор является точкой выхода).
* Имеет значение только локально, в пределах маршрутизатора.
* Не передается в обновлениях.
* Чем больше значение атрибута, тем более предпочтителен путь выхода.

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

==Исходящим==
*Проприетарный атрибут Cisco weight (локально на маршрутизаторе)
*Local Preference (локально в AS)
*Косвенно можно политикой навешивать med на префиксы от пира и в зависимости от этого будет также регулироваться исходящий трафик.

=Выбор лучшего пути (BGP Active Route Selection)=
# Проверяем, что резолвится next-hop (без это маршрут и активным то не будет :/ )
# Route Preference (Admin distance)
# БОльший local preference (''Inactive reason: '''Local Preference''''')
# Кратчайший AS-path (''Inactive reason: '''AS path''''')
# Меньший Origin value (''Inactive reason: '''Origin''''')
# Меньший MED value (''Inactive reason: '''Route Metric or MED comparison''''')
# EBGP peer предпочтительней IBGP peer (''Inactive reason: '''Interior > Exterior > Exterior via Interior''''')
# C кратчайшей IGP метрикой к Protocol next-hop (''Inactive reason: '''Not Best in its group – IGP metric''''')
# Если префикс получен по IBGP, то используем префикс от пира с наименьшим RID (''Inactive reason: '''Not Best in its group – Router ID''''')
# Если префикс получен по EBGP, то используем более старый активный префикс (считается более стабильным) (''Inactive reason: '''Not Best in its group – Active preferred''''')
# При использовании RR: кратчайший cluster list length (''Inactive reason: '''Not Best in its group – Cluster list length''''')
# Наименьший router-ID (''Inactive reason: '''Not Best in its group – Router ID''''')
# Наименьший Source IP address (''Inactive reason: '''Not Best in its group - Update source''''')

В Juniper можно посмотреть причину неактивности маршрута: ''Inactive reason'' в выводе ''sh route protocol bgp x.x.x.x extensive''

Дефолтное поведение для EBGP маршрутов может быть изменено: '''path-selection external-router-id'''. При включении этой функции для роутера выбор активного EBGP маршрута от разных роутеров будет делаться по наименьшему router-id.

*Route Preference (Admin distance) - не передается по ibgp, ebgp. Может только навешиваться через import-policy или в настройках bgp на любом уровне иерархии.

=Multipath=
Один и тот же маршрут прилетает с двух пиров одной AS или несколько копий маршрута прилетает с одного пира. Активный маршрут будет вставлен в routing table с несколькими next-hop и трафик будет балансироваться между двумя пирами (в forwarding table все же будет вставляться один next-hop). Для inactive маршрутов будет указан один next-hop. Multipath не вставит маршруты с одинаковым MED-plus-IGP cost, при разных IGP метриках до пиров. На роутере глобально должен быть включен load-balancing.

При включенном multipath, алгоритм выбора лучшего пути игнорирует router ID и peer ID.

До включения:
mortlach> show route protocol bgp terse
inet.0: 30 destinations, 34 routes (30 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 172.17.0.0/24 B 170 100 >192.168.86.21 I
B 170 100 >192.168.86.42 I
* 172.17.1.0/24 B 170 100 >192.168.86.21 I
B 170 100 >192.168.86.42 I
* 172.17.2.0/24 B 170 100 >192.168.86.21 I
B 170 100 >192.168.86.42 I
* 172.17.3.0/24 B 170 100 >192.168.86.21 I
B 170 100 >192.168.86.42 I
mortlach> show route forwarding-table destination 172.17.0.0/24
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
172.17.0.0/24 user 0 indr 262142 5
192.168.86.21 ucst 547 5 '''ge-0/0/0.90 - выбран активным, из-за меньшего router-ID (10.200.86.4 vs 10.200.86.8)'''

После:
mortlach> show route protocol bgp terse
inet.0: 30 destinations, 34 routes (30 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 172.17.0.0/24 B 170 100 192.168.86.21 I
>192.168.86.42
B 170 100 >192.168.86.42 I
* 172.17.1.0/24 B 170 100 192.168.86.21 I
>192.168.86.42
B 170 100 >192.168.86.42 I
* 172.17.2.0/24 B 170 100 192.168.86.21 I
>192.168.86.42
B 170 100 >192.168.86.42 I
* 172.17.3.0/24 B 170 100 192.168.86.21 I
>192.168.86.42
B 170 100 >192.168.86.42 I

mortlach> show route forwarding-table destination 172.17.0.0/24
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
172.17.0.0/24 user 0 indr 262143 5
192.168.86.42 ucst 588 7 '''ge-0/0/0.50''' - '''изменился, т.к. router ID уже не влияет на выбор лучшего пути'''

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

Позволяет делать балансировку пропорционально заданным в community скоростям.

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

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

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

Конфиг 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:
set interfaces lo0 unit 0 family inet address 2.2.2.2/32

set policy-options policy-statement bw20 then community add bw20
set policy-options policy-statement bw80 then community add bw80

set policy-options policy-statement from-direct term redistribute-direct from protocol direct
set policy-options policy-statement from-direct term redistribute-direct then accept
set policy-options policy-statement from-direct term default then reject

set policy-options community bw20 members bandwidth:2222:2500000; '''// 2500000 байт в секунду — это 20% от 100Мегабит'''
set policy-options 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 bw20'''
peer-as 1111;}
neighbor 10.2.0.1 {
description R1;
export [ bw80 from-direct ]; '''// На второе соседство навешивается community bw80'''
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

=Multihop=
Возможность поднять EBGP peering между роутерами, не имеющих прямого физического соединения. Сессия устанавливается на lo интерфейсах.

Важно в конфиге задать multihop. В таблице маршрутизации должен быть маршрут до пира.

При поднятии сессии на Lo интерфейсах используем:
*''set system default-address-selection'' - будет браться адрес lo автоматически
*local-address (bgp, group или neighbor) - более специфичен, поэтому если надо будет - перебьет уже настроенный default-address-selection

TTL = 1 задаем, чтобы соседство установилось точно с одним ближайшим роутером. (либо другое значение, если роутер далеко)

blair> show route 10.200.86.4
10.200.86.4/32 *[IS-IS/18] 00:00:03, metric 10
to 192.168.86.49 via ge-0/0/0.80
> to 192.168.86.17 via ge-0/0/0.100
Config
set protocols bgp group int type internal
set protocols bgp group int multihop ttl 1
set protocols bgp group int local-address 10.200.86.1
set protocols bgp group int neighbor 10.200.86.4

Т.к. между роутерами теперь 2 физических линка, то можно балансировать трафик между ними.

=Modifying AS Path=
==Option 1: remove-private==
Диапазон: 64512 - 65534

Роутер, на котором настроен remove-private перед передачей префиксов удаляет из AS path AS из указанного выше диапазона.

Можно настраивать на всех уровнях: protocols bgp, group, neighbor.

==Option 2: local-as==
set routing-options autonomous-system 1111
set protocols bgp group ebgp neighbor 10.1.0.2 peer-as 2222
set protocols bgp group ebgp neighbor 10.1.0.2 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:
set protocols bgp group ebgp neighbor 10.1.0.2 peer-as 2222
set protocols bgp group ebgp neighbor 10.1.0.2 local-as 3333 '''private'''

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

==as-override==
CE1 '''(AS 65500)''' <> PE (AS 1111) <> P (AS 1111) <> PE (AS 1111) <> CE2 '''(AS 65500)'''

Если на сети ISP есть 2 сессии с пирами из одной AS, то при передаче маршрутов, полученных от одного site этой AS второму site'у, второй site не примет такой префикс, потому что в AS path будет дважды указана его AS - это routing loop.
65500 1111 I - '''роутер с AS 65500 не примет префикс с таким AS path.'''

set protocols bgp group int neighbor 10.200.86.4 as-override
Можно конфигурировать для группы или соседа.

Роутер ISP на полученном префиксе смотрит в AS path, AS пира заменяем на свою. При передаче префикса второму site ISP делает стандартный prepend своей AS. В итоге пиру в AS 65500 прилетит префикс с таким AS path:
1111 1111 I

==loops==
Еще один способ решения ситуации, описанной в примере выше - чтобы CE2 получил маршрут своего удаленного site:

На CE2:
set routing-options autonomous-system 65500 loops 2
Тогда на CE2 прилетит префикс с AS path:
1111 65500 I
и роутер это сожрет.

=Опции настройки для пиров=
*'''passive''' - локальный роутер перестает слать open message. Чтобы сессия поднялась, open message теперь должно прийти от удаленного пира.
blair# top show | compare
set protocols bgp group int neighbor 10.200.86.4 passive

Feb 11 22:07:58.812668 BGP SEND message type 1 (Open) length 59
Feb 11 22:07:58.856999 BGP RECV message type 1 (Open) length 59
После задания passive для пира:
Feb 11 22:12:22.128876 BGP RECV message type 1 (Open) length 59
* '''allow''' - принимает open message только из указанной сети. Можно указать только для определенной группы:
set protocols bgp group int allow 10.200.86.0/24
*'''prefix-limit''': ограничивает значение полученных префиксов от пира. Можно применять на разных уровнях иерархии.
set protocols bgp group int neighbor 10.200.86.4 family inet unicast prefix-limit maximum 1500
set protocols bgp group int neighbor 10.200.86.4 family inet unicast prefix-limit teardown 100 ('''%''') idle-timeout 10 ('''min''');}}}
*'''hold-time''': меняем hold timer. По дефолту 90 sec. Можно применять на разных уровнях иерархии.
set protocols bgp hold-time 120
*'''advertise-peer-as''': позволяет EBGP маршруты передавать обратно EBGP пиру. Но тогда и у пира должен быть настроен as loops, чтобы он не отбросил префикс с лупом в AS-Path.
set protocols bgp group int advertise-peer-as

=Route Reflection=
Описан в RFC 4456

'''Концепция'''

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

==Распространение маршрутов при использовании RR==
[[Файл:RR.png|700px]]

Будем использовать следующие обозначения:
*IBGP rr-client - IBGP сосед в кластере
*IBGP NON-rr-client - IBGP сосед не в кластере
*EBGP - EBGP сосед

Распространение маршрутов происходит следующим образом:
*IBGP rr-client > IBGP rr-client + IBGP NON-rr-client
*IBGP NON-rr-client > IGBP rr-client
*IBGP NON-rr-client <> IBGP NON-rr-client - '''не передается'''

*EGBP > IBGP rr-client + NON-rr-client

Если включить '''no-client-reflect''', то это запретит анонсить префиксы между клиентами кластера. В таком случае, если требуется сохранить связность между этими клиентами - нужно настроить между ними full-mesh. Такой вариант развитий по идее может понадобиться только при иерархичном роут-рефлектинге (о нем ниже).

RR добавляет/изменяет атрибуты (без политик по дефолту):
*'''Originator ID'''
Router ID первого роутера, который заслал маршрут в AS.

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

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

Правила работы с Originator и Cluster List:
*для EBGP или любого другого протокола, отличного от IBGP, originator и сluster list не добавляются
*для IBGP client<>client / client<>non-client:
:*originator добавится только если до этого его не существовало.
:*Cluster list дополнится новым cluster ID.
:*Cluster ID будет установлен, если его не было ранее.

'''2 RR в кластере'''

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

==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 на lo0 адресах (с включенным multihop!!)

==Hierarchical Route Reflection==
[[Файл:Hierarch_RR.png|700px]]

Отличие от предыдущих: в схеме появляются не только RR и client, но еще и роутеры, выполняющие обе функции в рамках разных кластеров.
Clients могут устанавливать IBPG между собой full-mesh. Это удобно использовать, чтобы 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-hop только у 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

=Fake-group=
Данная проблема описана в KB20870 (https://kb.juniper.net/InfoCenter/index?page=content&id=KB20870).

Более подробное описание и рекомендации по предотвращению https://www.juniper.net/documentation/en_US/junos/topics/example/bgp-vpn-session-flap-prevention.html

По факту функционал RR включается/выключается только при добавлении/удалении соседу в группе с клиентами (с '''cluster''').

Если на маршрутизаторе настроены '''EBGP с клиентами''' или '''IBGP c RR''', для которых в конфигурации группы '''включены vpn-address-family''', (inet-vpn, inet6 inet-mpvn, inet-mdt, inet6-mpvn, l2vpn, iso-vpn) и на маршрутизаторе в этих группах производится добавления первого соседа или удаления последнего, Juniper рестартует BGP сессии с RR и c EBGP пирами в VPN-address-family для отсылки NLRI с новой (удалением старой) address-family.

Для предотвращения подобных ситуаций можно предпринять следующие шаги:
* на каждом RR создана fake группа (для исключения проблемы удаления последнего соседа в группе).
* на каждом PE создана fake группа (для исключения проблемы включения нового клиента с EBGP + vpn-family)

==Configuration==
Fake группа имеет следующий вид для '''RR и PE''':
group fake-vpn {
type '''external''';
description "-- Preventing mpbgp sessions flap --";
'''passive''';
family inet {
any;
family inet-vpn {
any;
family iso-vpn {
unicast;
family l2vpn {
signaling;
family evpn {
signaling;
family inet-mvpn {
signaling;
family inet-mdt {
signaling;
'''neighbor 101.101.101.101''' {
'''peer-as 101''';

=IPv6 (6PE)=
Если у нас есть настроенная ipv4 сеть и мы захотели передавать трафик и для ipv6 адресов (используя MPLS), то:

- требуется настроить family inet6 labeled-unicast explicit-null на сессии pe<>rr
set protocols bgp group ibgp-rr family inet6 labeled-unicast explicit-null
эта family навешивает на ipv6 префикс '''label 2''' (explicit-null для ipv6), что позволяет на сети в качестве транспорта использовать mpls, а на последнем роутере делать lookup в таблице inet6.0.

- на сети у нас скорей всего уже будет включен mapping ipv4 адресов в ipv6:
set system allow-v4mapped-packets
- при передаче префиксов pe->rr должен быть настроен в политике hext-hop self. При этом для ipv6 префиксов будет подставляться mapped ipv6 адрес lo0.
rr> show route receive-protocol bgp 172.30.5.5
inet.0: 56 destinations, 58 routes (55 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 192.168.31.0/24 '''172.30.5.5''' 100 64514 I
* 192.168.32.0/24 '''172.30.5.5''' 200 64514 I
inet6.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
fd17:f0f4:f691:5::31/128
* '''::ffff:172.30.5.5''' 100 64514 I
- на rr адреса '''::ffff:172.30.5.5''' не будет, поэтому полученный префикс будет в hidden, из-за неотрезовленного next-hop. Чтобы решить эту проблему прописываем статику:
rr> show configuration routing-options
rib inet6.0 static route ::ffff:172.30.5.0/124 receive;
'''receive''' в данном случае позволяет сделать маршрут активным, не прибегая к форвардингу трафика.

- после этого рефлектор спокойно рефлектит маршрут своим клиентам.

- далее, pe получит префикс, но с принятым next-hop '''::ffff:172.30.5.5''' это префикс опять же не станет активным в таблице. Тут решение static с next-hop receive - не проканает, ибо нам нужно передавать трафик к префиксу, а не просто вставить его в таблицу маршрутизации. Тут прибегнем к варианту, который маршруты ldp для desct-ipv4 замапит в dest-ipv6 из inet.3 и поместит их в inet6.3 (для резолва ipv6 префиксов):
set protocols mpls ipv6-tunneling

rigel-r7> show route protocol ldp 172.30.5.5
'''inet.3''': 25 destinations, 32 routes (8 active, 0 holddown, 22 hidden)
'''172.30.5.5/32''' *[LDP/9] 01:17:08, metric 20
to 172.30.0.41 via ge-0/0/0.240, Push 319216
> to 172.30.0.46 via ge-0/0/3.244, Push 340912

rigel-r7> show route protocol ldp ::ffff:172.30.5.5
'''inet6.3:''' 8 destinations, 10 routes (8 active, 0 holddown, 0 hidden)
'''::ffff:172.30.5.5/128''' *[LDP/9] 01:17:20, metric 20
to 172.30.0.41 via ge-0/0/0.240, Push 319216
> to 172.30.0.46 via ge-0/0/3.244, '''Push 340912'''

ну и проверяем, что и сам префикс стал активным:
rigel-r7> show route fd17:f0f4:f691:5::31/128
inet6.0: 20 destinations, 22 routes (20 active, 0 holddown, 0 hidden)
fd17:f0f4:f691:5::31/128 *[BGP/170] 00:50:51, localpref 100, from 172.30.5.41 AS path: 64514 I
to 172.30.0.41 via ge-0/0/0.240, '''Push 2''', Push 319216(top)
> to 172.30.0.46 via ge-0/0/3.244, '''Push 2, Push 340912(top)'''

Кстати, ipv6 tunneling перетаскивает как ldp, так и rsvp маршруты в inet6.3.

=Confederations=
Описан в RFC 3065

'''Принципы'''

Цель: разбить global AS на sub-AS.
*sub-AS должна иметь уникальный номер (зачастую берут приватные AS).
*Внутри sub-AS между роутерами: full-mesh IBGP. Если внутри sub-AS будет слишком большая сеть, то в нее можно внедрить RR.
*Между sub-AS - EBGP = confederation BGP = CBGP. При прохождении маршрута через CBGP линк, роутер меняет AS path, включая туда AS sub-AS - этот метод - защита от петель. Другие атрибуты BGP не меняются.

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

==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]

confederation ''<>'' - это номер public AS.

в качестве members - определяются все AS, включенные в конфедерацию.

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

=Route damping (flapping)=
При различных обстоятельствах на сети могут возникать флапы маршрутов, что приводит к загрузке CPU на роутерах.

Чтобы избежать подобного поведения есть некоторые механизмы защиты от флапов, например: '''BGP route flap damping'''.

Damping игнорируется IBGP и работает только с EBGP и CBGP (confederation BGP).

Damping уменьшает кол-во update message, путем обозначения флапающих маршрутов непригодными стать активными маршрутами.

'''Принцип работы:'''

Когда маршрут прилетает на наш роутер (на котором настроен route damping), на префикс назначается значение merit = 0.

Как только роутер распознает некую нестабильность маршрута (префикс просто перестает долетать до роутера (или линк упал)):
*назначается merit = 1000, включается счетчик decay half-life. Если на роутер снова прилетит префикс, до того, как истечет таймер, то значение merit увеличится еще на 1000 +1000. И подобное поведение будет повторяться до превышения значения merit до supress (3000) - префикс в таком случае будет признан непригодным для использования.

После того, как префикс пропал и заново прилетел на роутер по BGP, его значение merit = 2000 (при дефолтных настройках)
Merit (last update/now): 1969/1938
Default damping parameters used
Last update: 00:00:27 First update: 00:00:49
Flaps: 2

После этого при исчезновении маршрута с роутера, его не будет видно в inet.0, но инфо можно будет посмотреть в
blair> show route damping history detail

После того, как будет превышен supress threshold, инфо о маршруте можно будет посмотреть:
blair> show route damping suppressed detail

Либо в hidden, если маршрут приходит от пира.

*если префикс передается от роутера, то он передается со значением merit = 1000.
*если изменяется path attribute, то префиксу ставится значение 500.
*decay half-life - кол-во минут после которого значение merit уменьшается вдвое, при поведении маршрута более стабильно. default = 15 min.
*max-supress - максимальное кол-во минут, которое маршрут проводит в состоянии hold-down. default = 60 min.
*reuse threshold - произвольное значение, после которого маршрут снова можно использовать. default = 750.
*supress threshold- произвольное значение, после которого маршрут больше нельзя использовать. default = 3000.
==Config==
Как только включаем на роутере damping, без заданных параметров, для работы будут использоваться дефолтные значения.

Параметры задаются через policy. '''Disable''' - для определенных префиксов удаляет merit, и убирает префикс из damping процесса (могут быть например public DNS).

set policy-options damping c11 half-life 30
set policy-options damping c11 reuse 1000
set policy-options damping c11 max-suppress 500

set policy-options policy-statement c11-damping then damping c11

set protocols bgp group c11 type external
set protocols bgp group c11 damping
set protocols bgp group c11 import c11-damping

=Blackhole=
Когда на сети определено специальное community для blackhole, и клиент посылает префикс, помеченный этим community, нужно реализовать блокировку трафика на нашей сети к этом префиксу. И желательно разослать этот префикс другим пирам и апстримам с их blackhole-community.

Блокировку трафика можно организовать несколькими способами.

1. зарулить трафик на префикс, у которого next-hop = discard.
set policy-options policy-statement blackhole from protocol bgp
set policy-options policy-statement blackhole from community blackhole
set policy-options policy-statement blackhole then next-hop 192.168.0.101
set policy-options policy-statement blackhole then accept
set routing-options static route 192.168.0.101/32 discard
set routing-options static route 192.168.0.102/32 discard

здесь без accept - видимо не происходит еще один lookup и next-hop остается unusable.
Либо resolve происходит, но с next-hop discard маршрут не считается активным и остается в hidden.

Тема discard не раскрыта :)

2. зарулить на discard interface (dsc). - подробно лучше смотреть в документации Juniper.

3. сделать у префикса сразу next-hop discard.

set policy-options policy-statement blackhole from protocol bgp
set policy-options policy-statement blackhole from community blackhole
set policy-options policy-statement blackhole then '''next-hop''' discard
set policy-options policy-statement blackhole then '''accept'''
set policy-options community blackhole members "6451[0-9]:666"

без accept маршрут будет в hidden и не передастся своим ibgp соседям. (в hidden, так как next-hop unusable)

Политику применяем на клиентов и на ibgp сессии в рамках нашей aAS (+cbgp, если используем конфедерации)

Чтобы разослать префикс другим ebgp пирам добавляем еще одну строчку в политику:
set policy-options policy-statement blackhole then community add upstream-blackhole

TIPS:
*если в политике делать только then discard - это заблочит распространение префикса на сети, что не совсем решает проблему. Через нашу сеть все-равно будет идти трафик до этого dest, просто обходными путями.
*обычно клиенты шлют /32 префиксы с blackhole-community, а на import фильтрах у уважающих себя операторов есть ограничение по длине префикса (<24).

Поэтому, чтобы получить /32, добавляем в политику условие:
set policy-options policy-statement blackhole from route-filter 0.0.0.0/0 prefix-length-range /32-/32

=BFD=
Как известно, этот механизм используется в качестве обмена hello сообщениями с заданным интервалом, ниже, чем дефолтный интервал в других протоколах. Что позволяет протоколу быстрее обнаружить падение сессии.

Сильно нагружает CPU RE, поэтому с ним сильно перебарщивать не стоит.

Хосты устанавливают сессию и обмениваются hello.

Если перестали приходить hello, то BFD дает знать протоколу, что пропала связность между хостами.

*minimum-interval - минимальный интервал получения и отправления "hello" BFD. То есть это интервал с которым локальный роутер отправляет hello и интервал, с которым локальный роутер ждет ответа на свой hello. Также в конфиге можно отдельно задать transmit и receive minimum interval.
* multiplier - значение кол-ва пропущенных hello.

set protocols bgp group upstream neighbor 1.1.1.1 bfd-liveness-detection minimum-interval 500 ''[transmit+receive]''
set protocols bgp group upstream neighbor 1.1.1.1 bfd-liveness-detection multiplier 4

или
set protocols bgp group upstream neighbor 1.1.1.1 bfd-liveness-detection minimum-receive-interval 500 ''[receive]''
set protocols bgp group upstream neighbor 1.1.1.1 bfd-liveness-detection transmit-interval minimum-interval 500 ''[transmit]''

BFD + graceful restart - не рекомендуется.

BFD + Routing Engine switchover event - не рекомендуется ниже 5000мс.

BFD + NSR - не рекомендуется ниже 2500мс.

для очень больших сетей с большим кол-вом bfd сессий - не ниже 300мс

Если значения таймеров у пиров не совпадают, то BFD использует наибольшее значение (используется режим adaptive-mode).

Это поведение по умолчанию можно выключить: no-adaptation.
set protocols bgp group upstream neighbor 1.1.1.1 bfd-liveness-detection no-adaptation

'''Проверка:'''
> show bfd session extensive

=IPv6=
Есть несколько способов настраивать BGP между роутерами, работающими с ipv6.
*Прямая ipv6 сессия на ipv6 адресах:

На интерфейсах обычные p2p адреса из /126 (/30) сеточки. Это самый примитивный вариант.
group r7-ipv6 {
type external;
export export-direct;
peer-as 54591;
neighbor fc09:c0:ffee::1;}

Настраиваем сессию на ipv6 адресах в отдельной группе. Если настраивать в группе, в которой настроены также сессии на ipv4-адресах, то сессия на ipv6 поднимется, но роутеры маршрутами обмениваться не будут.

*Сессия на ipv4 адресах, передающая ipv6 префиксы. ipv6 адреса на интерфейсах ipv4-compatible, то есть вида
a-centauri-r5> show configuration interfaces ge-0/0/0.304
description --c32;
vlan-id 304;
family inet {
address 192.168.0.13/30;}
family inet6 {
'''address ::ffff:192.168.0.13/126;'''
- сессия строится на ipv4 адресах. в группе или на neighbor настроена передача family inet6 unicast.
a-centauri-r5> show configuration protocols bgp group c31-c32
type external;
family inet unicast
family inet6 unicast
export export-ipv6
peer-as 64514
neighbor 192.168.0.10
- глобально требуется также включить:
a-centauri-r5> show configuration system
allow-v4mapped-packets
*Для IPv6 eBGP в рамках VRF нужно указывать ''routing-instance <> routing-options router-id <>''. Иначе сессия не поднимется. Будет прилетать ошибка:
May 21 00:16:05.676938 BGP RECV version 4 as 54591 holdtime 90 id '''0.0.0.0''' parmlen 30
Либо использовать отдельные lo, который будет выступать в роли router-id для сессии.
*На link-local адресах

=Дополнительная информация=
*[[OSPF]]
*[[IS-IS]]
*[[L3VPN]]

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

2021-07-18T10:45:48Z

Наталия Бобкова: /* Routing, tunneling */

{{Главная страница}}

'''UPDATED'''

=JNCIP-SP=
==Advanced routing==
*[[OSPF]]
*[[BGP]]
*[[IS-IS]]

==JMR (Multicast routing)==
*[[Глава 2. Multicast, IGMP]]
*[[Глава 3. Routing protocols (DVMRP, PIM-DM, PIM-SM)]]
*[[MSDP | Глава 4. MSDP]]
*[[Глава 5. PIM-SSM]]
*[[Политики в мультикасте | Глава 6. Политики в мультикасте]]
*[[IPv6 в мультикасте | Глава 7. IPv6 в мультикасте]]

==JMV (MPLS and VPNs)==
*[[Глава 1. Основы MPLS и VPN]]
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]
*[[Отказоустойчивость и оптимизация в MPLS]]
*[[Traffic engineering]]
*[[L3VPN]]
*[[L2VPN]]
*[[VPLS]]
*[[MVPN]]
*[[EVPN]]
*[[Реализация MPLS в ядре сети]]

==JCOS==
*[[Глава 1. QoS]]
*[[Глава 2. Packet classification]]
*[[Глава 3. Policing]]
*[[Глава 4. Scheduling]]
*[[Глава 5. Hierarchical scheduling]]
*[[Глава 6. Rewrite rules]]
*[[Глава 7. CoS-based forwarding]]
*[[Глава 8. Packet flow]]

=JNCIS-SP, JNCIS-ENT=

==Switching==
*[[L2 switching and VLANs]]
*[[Spanning-Tree protocol (STP)]]
*[[Virtual Chassis]]
*[[Provider bridging]]
*[[ERP (Ethernet Ring Protection)]]

==Routing, tunneling==
*[[Static, Aggregate, Generate route]]
*[[Martians]]
*[[High Availability]]
*[[Load-balancing]]

==MPLS==
*[[Глава 2. RSVP]]
*[[Глава 5. MPLS Features]]
*[[Глава 6. VPN]]
*[[Глава 8. Конфигурация L3VPN]]
*[[Глава 9. Полезности по траблшутингу L3VPN]]
*[[Глава 10. L3VPN Internet Access и масштабирование]]
*[[Глава 11. L3VPN Дополнительные фичи]]
*[[Глава 12. Multicast VPNs]]

=SNMP=
*[[SNMPv3]]

=Data Center=
*[[DC]]

=Automation=
*[[Общие сведения об автоматизации в JunOS]]
*[[Основы автоматизации на SLAX]]
*[[Пример программы на SLAX]]

=Прочее=
*[[Архитектура MX]]

OSPF

2021-07-18T10:41:39Z

Наталия Бобкова:

{{#description2:Основы OSPF. Типы пакетов. Установление соседства. Типы Area. Типы LSA. Таймеры. Типы роутеров. Метрики/SPF. OSPFv3. Realm. backbone. stub area. nssa area. totally stub area. Информация для подготовки к экзаменам Juniper.}}

=Основы=
OSPF - link-state IGP протокол.

Hello пакеты для установления и поддержания соседства.

OSPF флудит LSA (IP 89 порт, '''224.0.0.5''' адрес) во все порты OSPF, кроме того, с которого прилетела LSA. С помощью LSA на каждом роутере строится топология сети и на основании этих данных затем производится рассчет кратчайшего пути.

На всех роутерах одной area поддерживается одинаковая копия LSDB.

'''Policy''' можно применять на '''export''' для summary-LSA 3 (вроде).
+ export Export policy

И только для external маршрутов на '''import'''. !!! При этом в ospf database они будут видны, но в sh route их не будет.
+ import Import policy (for external routes or setting priority)

Иерархичный дизайн сети достигается за счет использования area, которые соединяются посредством backbone area.

Dijkstra рассчитывается только в рамках одной area (на основании одной LSDB, которая едина в рамках одной area).

Summary metric для dest = сумме outgoing interface metrics.

На бродкаст сегменте выбирается DR (наиб приоритет, затем наиб router ID), который занимается флудом LSA внутри area. Для роутеров не в бродкастном сегменте, подключенных через Ethernet, включаем ''interface-type p2p'', чтобы на этом линке не проводились выборы DR и чтобы уменьшить время сходимости.

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

'''Database description (DD)''' - используется только во время установления соседства. Определяет кто отвечает за синхронизацию LSDB (выбирается роутер с бОльшим 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, либо если меняется информация о состоянии линка на локальном роутере. Передает одну или несколько LSA. Содержит: ospf header, numbers of advertisement, link-state avertisement.

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

=Установление соседства=
Соседи используют hello пакеты для установления и поддержания соседства.

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

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

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

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

*'''2-Way'''
В hello-packet в списке соседей появился RID роутера, получившего этот пакет.

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

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

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

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

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

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

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

=Таймеры=
*Hello interval - установление и поддержание соседства = 10sec для broadcast и p2p networks; 30 sec - для nonbroadcast multiple access (NBMA).
*Dead - интервал, в течение которого не приходит hello, чтобы считать соседа неоперабельным = 40 sec.
*LSA retransmission interval - когда роутер отправил LSA, он ждет 5 sec ответа от соседа, что LSA получен (LSA ACK). Если ACK не пришел - делается повторная передача LSA.
*Transit-delay - устанавливает время, необходимое для передачи link-state update на интерфейсе = 1sec. Менять дефолтное значение не советуется.
*LSA refresh - интервал обновления LSA = 50min. Если LSA не обновилась через 60min, то инфо о ней считается устаревшей и она пропадает из LSDB.
{{note|text=Когда делаешь ''clear ospf database purge'' как раз всем LSA устанавливается LSA refresh interval 60min (3600sec) и неактуальные сразу же сбрасываются.}}
Кстати, у по дефолту НЕ у Juniper LSA refresh interval = 30min.

=Роутеры=
*'''ABR (Area border router)''': OSPF роутер, имеющий линки в двух area - соединяет и распространите инфо из OSPF area в backbone.
*'''ASBR (AS boundary router)''': может находиться как внутри backbone или других area. Имеет подключения других external routing protocols и распространяет эту инфу по сети.
*'''Backbone''': хотя бы один линк внутри backbone area.
*'''Internal''': все линки внутри одной area, backbone - частный случай internal.

=Метрики/SPF=
outside the area (INTER-area routing)

*Внутренние маршруты area (intra-area) juniper preference = 10
*Внешние маршруты (inter-area) juniper external-preference = 150
{{note|text=Метрика будет сравниваться только у маршрутов одного типа. Поэтому не всегда можно гарантировать forwarding согласно метрики. Не забываем про тип маршрута!}}

external metrics - применяются к префиксам из других AS.
*TYPE 1 - учитывается external cost + cost в пути до граничного маршрутизатора.
*TYPE 2 - учитывается только external cost. Этот тип используется по дефолту.

TYPE1 приоритетнее TYPE2. Далее учитывается стоимость самой метрики - чем меньше, тем приоритетнее.

*reference-bandwidth - дефолтной расчет метрики из емкости интерфейса: cost = ref-bandwidth/bandwidth. По умолчанию ref-bandwidth = 100Mbit. Можно настроить свое значение, глобально для протокола.
set protocols ospf reference-bandwidth 10g

Если устанавливаем metric вручную на интерфейсе, то дефолтное поведение перебивается для данного интерфейса.

=Типы Area=
Ненулевые area могут иметь один и тот же номер area, но такой подход - не правильный. При этом разные area с одним area-id не будут никогда считать себя одним сегментом сети.

area-id не передаются в LSA.

Если разбирать самые стандартные area (не stub, nssа и прочее):
*area1 - area0 - area3 - ok. У всех area будет полная картина сети.
*area1 - area2 - area3 - ok, только area2 будет иметь маршруты всей сети, а area1 и area3 будут иметь только свои маршруты + маршруты area2.
*area1[1] - area0 - area1[2] - ok, НО конечно area1[1] будет видеть area1[2] как LSA3. Такой себе вариант.

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

Но если area не имеет прямого физического подключения к backbone area, то она может соединяться с ней через virtual-link.

==stub area==
Обменивается маршрутами по ospf с ABR (LSA 3), не содержит с себе external routes, не принимает от ABR external routes (не принимает LSA 4,5). Доступность внешних маршрутов достигается анонсированием 0/0 со стороны ABR в сторону stub-area. Через stub-area нельзя построить virtual-link и в ней не может размещаться ASBR. Если все же сконфигурировать ASBR внутри stub-area, то роутер разместит LSA 5 в своей локальной базе данных, но не будет пересылать ее другим роутерам даже внутри area.

Все роутеры stub area должны быть сконфигурированы, как stub.
[edit protocols ospf area 0.0.0.20]
+ stub

Чтобы появился 0/0, на ABR настраиваем:
[edit protocols ospf area 0.0.0.20 stub]
+ default-metric 10;

==stub with no summaries (totally stub)==
В неё не анонсируется вообще никаких LSA. В area не вставляются LSA 3, 4, 5. По area гуляют только LSA 1 и LSA 2 [no-summaries как раз намекает на отсутствие LSA3]. Доступность маршрутов из остальных area достигается тем же анонсированием 0/0 со стороны ABR в сторону totally stub-area. И ASBR не флудит external routes в такой area. Также virtual-link не поддерживается в такой area.

[edit protocols ospf area 0.0.0.20]
+ stub default-metric 10 no-summaries;

==not-so-stubby==
Обменивается OSPF-маршрутами с ABR (LSA3), может содержать external routes (ASBR) - НО! в этой area external = LSA7 (NSSA). Не принимает external routes от ABR. (не принимает LSA 4,5). Внешние ресурсы также через 0/0 на ABR.

Конфигурация nssa делается на каждом роутере внутри area.

[edit protocols ospf area 0.0.0.30]
+nssa

на ABR:
OSPF database, Area 0.0.0.30
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.200.86.1 10.200.86.1 0x80000002 35 0x20 0xe809 48
Router 10.200.86.3 10.200.86.3 0x80000004 36 0x20 0xbdba 72
Router 10.200.86.9 10.200.86.9 0x80000004 42 0x20 0xabe2 48
Network 192.168.86.37 10.200.86.9 0x80000001 42 0x20 0xf1d7 32
Summary *10.100.86.8 10.200.86.1 0x80000001 129 0x20 0x67ad 28
...
Summary *192.168.86.48 10.200.86.1 0x80000001 129 0x20 0x3fb6 28
'''NSSA''' 172.16.0.0 10.200.86.9
'''NSSA''' 172.16.1.0 10.200.86.9 - '''пришло от ASBR (LSA7) внутри area'''
'''NSSA''' 172.16.2.0 10.200.86.9
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
'''Extern''' *172.16.0.0 10.200.86.1
'''Extern''' *172.16.1.0 10.200.86.1 - '''сгенерировал ABR (LSA7 -> LSA5) и послал в area0
'''Extern''' *172.16.2.0 10.200.86.1

Анонс 0/0 настраивается на ABR:
[edit protocols ospf area 0.0.0.30 nssa]
+ '''default-lsa default-metric 1''';
Смотрим, что прилетело от ABR в NSSA area:
OSPF database, Area 0.0.0.30
Type ID Adv Rtr Seq Age Opt Cksum Len
NSSA 0.0.0.0 10.200.86.1 0x80000001 50 0x20 0x8681 36

Если на ABR добавляем ''no-summaries'', то 0/0 прилетит как LSA3 (а не LSA7 (NSSA)):

OSPF database, Area 0.0.0.30
Type ID Adv Rtr Seq Age Opt Cksum Len
Summary 0.0.0.0 10.200.86.1 0x80000001 3 0x20 0xae65 28
'''NSSA''' 0.0.0.0 10.200.86.1 0x80000001 '''3600''' 0x20 0x8681 36

Чтобы при настроенном ''no-summaries'' 0/0 прилетал все же как LSA 7, то добавляем в конце '''type-7''':
OSPF database, Area 0.0.0.30
Type ID Adv Rtr Seq Age Opt Cksum Len
'''Summary''' 0.0.0.0 10.200.86.1 0x80000001 '''3600''' 0x20 0xae65 28
NSSA 0.0.0.0 10.200.86.1 0x80000001 5 0x20 0x8681 36

=Типы LSA=
Все типы имеют одинаковый '''заголовок''':
*LS age - sec - время, когда LSA была впервые создана
*Option - E-bit = External LSA, P bit = NSSA external LSA.
*LS type.
*Link-state ID - разные типы LSA используют поле по-разному.
*Advertising router - роутер, который сгенерировал LSA.
*LS sec number
*LS checksum
*Length

В выводе ''sh ospf database'' ID, отмеченный '''*''' - будет означать, что этот маршрут сгенерирован самим роутером.

*'''Type 1 LSA (Router)''' — Описывает стоимость (metric) и состояние интерфейсов. Не передаются между Area. LSA1 = area scope.

*'''Type 2 LSA (Network)''' — Отправляются DR. Описывает роутеры, подключенные в бродкаст сегменте + сам себя. Не передаются между area. В выводе ''sh ospf database'': ID = DR, attached router = роутеры в бродкаст сегменте.

*'''Type 3 LSA (Summary)''' — Отправляются ABR. Описывают сети, которые маршрутизатор получил из предыдущих типов LSA, и передает между Area. LSA будет флудиться каждому роутеру внутри area. ABR, получив LSA3 не перешлет ее другому ABR, а сгенерирует на основании полученной LSA3, LSA1, 2 новую LSA3, и уже ее передаст в соседние area. LSA3 = area scope.
{{note|text=Summary не означает агрегирование! ABR передает один в один LSA1 и LSA2 в другую area без какой-либо агрегации/суммаризации по дефолту.}}

*'''Type 4 LSA (ASBR Summary)''' — Генерируются ABR, LSA содержит описание самих ASBR роутеров. В выводе ''sh ospf database'': ID = ASBR router.

*'''Type 5 LSA (External)''' — Описывают сети, полученные из других протоколов маршрутизации ASBR-ами. Рассылаются ими же. В выводе ''sh ospf database'': ID + mask = external networks.

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

*'''Type 7 LSA (NSSA External)''' — Генерируются ASBR-ами в NSSA. Передаются только внутри NSSA. Но на выходе из зоны ABR-ами транслируются в LSA Type 5. В выводе ''sh ospf database'': ID + mask = external networks.

*'''Type 9 (Graceful restart)''' - поддерживает graceful restart.

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

'''LSA flooding scopes''': LSA 1, LSA 2 - исключительно внутри area. LSA 3 - суммирует LSA 1 + LSA2 и передает эту инфу в соседнюю area. LSA 5 (external) - передаются по всему OSPF домену. LSA 4 (about ASBR) - по всему OSPF домену. LSA 7 (external in nssa) - только внутри nssa area.

Время жизни каждой LSA - 3600 sec (1 h).

Junos не поддерживает: LSA6, LSA8, LSA11

Можно вручную ограничить кол-во LSA: полезно в тех случаях, когда CE <> PE строится на OSPF.
set protocols ospf database-protection maximum-lsa 1000

macduff> show ospf database
OSPF database, Area 0.0.0.20
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.200.86.2 10.200.86.2 0x80000007 277 0x22 0xcb07 72
Router 10.200.86.4 10.200.86.4 0x8000000a 106 0x22 0x7294 72
Router *10.200.86.8 10.200.86.8 0x8000000d 105 0x22 0x5fd2 72
Network *192.168.86.14 10.200.86.8 0x80000003 2402 0x22 0xc01d 32
Summary 10.200.86.1 10.200.86.2 0x80000002 1991 0x22 0xdc09 28
Summary 10.200.86.2 10.200.86.2 0x80000004 2134 0x22 0xc41f 28
Summary 10.200.86.3 10.200.86.2 0x80000002 1705 0x22 0xd210 28
Summary 10.200.86.5 10.200.86.2 0x80000004 1420 0x22 0xba24 28
Summary 10.200.86.6 10.200.86.2 0x80000004 1277 0x22 0xa638 28
Summary 10.200.86.7 10.200.86.2 0x80000004 1134 0x22 0xb02b 28
Summary 10.200.86.9 10.200.86.2 0x80000002 848 0x22 0xa03b 28
Summary 192.168.86.4 10.200.86.2 0x80000004 991 0x22 0xec5f 28
Summary 192.168.86.8 10.200.86.2 0x80000006 2357 0x22 0xc085 28
Summary 192.168.86.24 10.200.86.2 0x80000002 1848 0x22 0x2812 28
Summary 192.168.86.28 10.200.86.2 0x80000004 705 0x22 0x62d 28
Summary 192.168.86.36 10.200.86.2 0x80000002 1563 0x22 0xb973 28
Summary 192.168.86.44 10.200.86.2 0x80000004 563 0x22 0x51d3 28
Summary 192.168.86.48 10.200.86.2 0x80000004 134 0x22 0x29f7 28
ASBRSum 10.200.86.9 10.200.86.2 0x80000001 390 0x22 0x9447 28
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 172.16.0.0 10.200.86.9 0x80000001 393 0x22 0x487b 36
Extern 172.16.1.0 10.200.86.9 0x80000001 393 0x22 0x3d85 36
Extern 172.16.2.0 10.200.86.9 0x80000001 393 0x22 0x328f 36

=Типы интерфейсов=
*'''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

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

=Другие фичи=
*Аутентификация: простая (plain-text, simple), MD5, none. и еще IPSEC.
:*simple - только один ключ. По сути просто не дает левому роутеру подключиться к твоему ospf домену, из-за использованиях хоть такого метода защиты. Но ключ не шифруется. Так что только MD5, только безопасность!
:*md5 - можно использовать несколько ключей. Менять их по времени. Каждый md5 key - с уникальным id. По id определяется какой md5 key использовать.

*Суммирование маршрутов (area-range), прилетающих в update сообщениях в backbone от других area.
Если после сети добавить
:*'''restrict''' - сети не просуммируются, а перестанут передаваться в backbone. То есть будет не передан и summary route и все вложенные в него сети.
:*'''override-metric''' - можно перезаписать значение ospf-метрики или ее тип.
:*'''exact''' - проадвертайзит только если в таблице маршрутизация будет четко такой же префикс.

Настраивается только на ABR. Здесь из area 10 будет передаваться суммированный маршрут в backbone:
[edit protocols ospf area 0.0.0.10]
+ area-range 192.168.86.0/24 [restrict|override-metric| exact];

Сразу после применения видно, что маршруты, сгенерированные ABR, и отправленные в area0 - скоро отвалятся.
OSPF database, '''Area 0.0.0.0'''
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.200.86.1 10.200.86.1 0x80000027 490 0x22 0x82a8 72
Router 10.200.86.2 10.200.86.2 0x80000016 312 0x22 0x74d9 84
Router *10.200.86.6 10.200.86.6 0x80000019 2 0x22 0xbe08 72
Network *192.168.86.10 10.200.86.6 0x8000000a 596 0x22 0xa839 32
Summary *10.200.86.5 10.200.86.6 0x80000007 2170 0x22 0x9246 28
Summary *10.200.86.7 10.200.86.6 0x80000007 2034 0x22 0x884d 28
Summary 10.200.86.9 10.200.86.1 0x80000002 1185 0x22 0x9c41 28
Summary *192.168.86.0 10.200.86.6 0x80000001 2 0x22 0x1537 28
Summary '''*192.168.86.4''' 10.200.86.6 0x80000007 '''3600''' 0x22 0xc481 28
Summary 192.168.86.24 10.200.86.1 0x8000000f 385 0x22 0xa25 28
Summary '''*192.168.86.28''' 10.200.86.6 0x80000008 '''3600''' 0x22 0xdb50 28
Summary 192.168.86.36 10.200.86.1 0x80000002 1185 0x22 0xb579 28
{{note|text=!!!Такой метод будет работать только для '''summary LSA'''. Для суммирования external LSA можно сделать area 30 NSSA area и тогда area-range сработает (пример ниже), либо на роутере area3 создавать aggregate route и делать его export в protocols ospf.}}

*Суммирование маршрутов от NSSA (LSA 7): аналогично работает и добавление '''restrict''' и '''override-metric''' и '''exact''':
[edit protocols ospf area 0.0.0.10 nssa]
+ area-range 172.16.0.0/22;

До
OSPF database, Area 0.0.0.10
NSSA *0.0.0.0 10.200.86.1 0x80000003 112 0x20 0x67f 36
NSSA 172.16.0.0 10.200.86.9 0x80000002 2485 0x28 0x88ff 36
NSSA 172.16.1.0 10.200.86.9 0x80000002 1886 0x28 0x7d0a 36
NSSA 172.16.2.0 10.200.86.9 0x80000002 1287 0x28 0x7214 36
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *172.16.0.0 10.200.86.1 0x80000004 5 0x22 0x6d5d 36
Extern *172.16.1.0 10.200.86.1 0x80000003 3600 0x22 0x2274 36
Extern *172.16.2.0 10.200.86.1 0x80000003 3600 0x22 0x177e 36

После:
OSPF database, Area 0.0.0.10
NSSA *0.0.0.0 10.200.86.1 0x80000003 201 0x20 0x67f 36
NSSA 172.16.0.0 10.200.86.9 0x80000002 2574 0x28 0x88ff 36
NSSA 172.16.1.0 10.200.86.9 0x80000002 1975 0x28 0x7d0a 36
NSSA 172.16.2.0 10.200.86.9 0x80000002 1376 0x28 0x7214 36
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *172.16.0.0 10.200.86.1 0x80000004 94 0x22 0x6d5d 36

*По дефолту в nssa будут передаваться LSA3 (summary) маршруты. Если нужно, LSA3 заменить на LSA7, то настраиваем:
set protocols ospf area 4 nssa default-lsa type-7

*Можно ограничить кол-во перфиксов, экспортируемых в OSPF.
*GRES возможен.
*BFD (Bidirectional Forwarding Detection) можно использовать для сокращения времени обнаружения аварии между роутерами.
*Можно отложить процесс перерасчета SPF при изменении LSDB (дефолт - 200ms):
set protocols ospf spf-options delay ?
<delay> Time to wait before running an SPF (50..8000 milliseconds)
*Metric - определяем желаемый интерфейс для прохождения пакета. Меньшая метика - приоритетнее.
*Overload - выставляет метрики на интерфейсах = 65535. Если после перерасчета SPF для dest не нашлось обходных путей, роутер будет передавать транзитный трафик.
set protocols ospf overload
*Topologies - можно использовать разные топологии для ipv4 unicast и ipv6 multicast. Для мультикаста и для юникаста с помощью метрик по-разному направлять трафик.
set protocols ospf topology ipv4-multicast
set protocols ospf area 0.0.0.0 interface xe-0/0/1.2056 metric 40
set protocols ospf area 0.0.0.0 interface xe-0/0/1.2056 topology ipv4-multicast metric 500

*Traffic-engineering (MPLS):
По дефолту выключен. Включаем, чтобы LSP участвовали как линки при расчёте SPF. Также в LSA теперь будут заноситься параметры traffic-engineering'a:
set protocols ospf traffic-engineering

*Traceoptions - как и для всех протоколов можно включить для диагностики
set protocols ospf traceoptions file ospf-log
set protocols ospf traceoptions file size 10m
set protocols ospf traceoptions file files 10
set protocols ospf traceoptions flag state detail
set protocols ospf traceoptions flag error detail

*Virtual-link. Как уже описывалось ранее, каждая area должна быть соединена с backbone area. Если у роутера нет физического линка до backbone, то делаем соединение через virtual-link.

В настройках всего 2 параметра: - ''transit-area'', ''neighbor-id''.

[[Файл:Ospf-virtual-link.png|600px]]

R8: set protocols ospf area 0 virtual-link transit-area 1 neighbor-id 172.30.5.7

virtual-link в SPF считается за обычный линк. Дополнительной стоимости не добавляет.

При этом, если у нас есть подобное включение: R1 (area 5) <> R2 (area 6) <> R3 (area 7). То area 5 и area 7 не будут видеть префиксы друг друга (будут видеть только area 6). А area 6 будет получать префиксы всех area.

То есть любая другая '''area не 0''' будет принимать LSDB от других area, но не передавать другим area. В отличие от Backbone. Backbone работает как RR :) А остальные как IBGP соседи. :)

=OSPFv3=
OSPF3 router-id, area-id, LSA link-state ID - взяты из OSPFv2, то есть имеют тот же формат: IPV4 = 32bit.

ROUTER ID = 172.30.5.4

AREA ID = 0.0.0.1

link state ID = 0.0.0.0, 0.0.0.1, 0.0.0.2, ...

По принципу работы не отличается от OSPFv2, но все же есть некоторый отличия:
*В OSPF3 все информаци о соседях представлена в виде router-ID (lo0.0 inet address).
*OSPF работает по линкам, а не по сетям.
*OSPF3 LSA1, LSA2 не передают никакой информации о сетях (prefix).
*Включены 2 новых типа LSA: ''link-LSA'' и ''intra-area-prefix-LSA''. Стандартные LSA 3, 4 превратились в inter-area-prefix-LSA и inter-area-router-LSA.
*OSPF3 использует link-local address для обмена сообщениями между соседями (за исключением virtual-link).
*Для аутентификации используется IPv6 authentification header.

'''Intra-area-prefix-LSA''': передает internal prefix, требуется, т.к. LSA 1, 2 передают только инфо о топологии.

'''Link-LSA''': передает link-local address и сети, прикрепленные к этому link.

==Config==
[edit]
routing-options {
router-id 10.200.86.1;}
[edit protocols]
ospf3 {
area 0.0.0.0 {
interface ge-0/0/0.80 {
interface lo0.0 {
passive; }
area 0.0.0.30 {
interface ge-0/0/0.110 }}

show ospf3 interface
show ospf3 neighbor
show ospf3 database
show route protocol ospf3
==Realm==
По дефолту OSPFv3 передает инфо только о IPv6 unicast маршрутах. Чтобы OSPFv3 мог передавать и другие family, в том числе и IPv4 unicast, IPv4 multicast, IPv6 multicast, включаем '''realm''':
set protocols ospf3 area 0.0.0.0 interface fe-0/1/0.0 - IPv6
set protocols ospf3 realm ipv4-unicast area 0.0.0.0 interface fe-0/1/0.0 - IPv4
set interfaces fe-0/1/0 unit 0 family inet6

=Дополнительная информация=
*[[IS-IS]]
*[[BGP]]
*[[L3VPN]]

IS-IS

2021-07-15T18:44:04Z

Наталия Бобкова:

{{#description2:Отличия ISIS и OSPF. ISIS Areas. NET. L2 network. L1 network. Leaking routes. Summarization. TLV. Выборы DIS в бродкаст сети. Аутентификация. Mesh-groups. Распространение маршрутов. Wide metric. Формат LSP. Hello PDU. Информация для подготовки к экзаменам Juniper.}}

=Основы=
'''[http://bradhedlund.com/notes/is-is/ Краткое содержание, в пересказе Brad Hedlund]'''

Был разработан для работы с CLNP/CLNS. Потом добавили возможность работать с IP (добавили tlv) - dual IS-IS.

CLNS (Connectionless network service).

CLNP (Connectionless network protocol).

dual IS-IS поддерживают M, MX, T series. Чистый ISIS работает только на J, SRX series.

Основные термины:
*ESs - end system = hosts.
*ISs - intermediate systems = routers.
*PDU - protocol data unit = packet.
*Level 1 (L1) - маршрутизация внутри area.
*Level 2 (L2)- маршрутизация между area и к другим AS.
*L1/L2 - совмещают 1 и 2 level на разных интерфейсах.

В L1/L2 системах роутер помечает PDU в сторону Level1 attached bit'ом, который обозначает, что роутер присоединен к L2 и что его можно использовать для достижения префиксов, находящихся за L1 area.

=Network entity title (NET)=
Network entity title (NET) - обозначения роутеров.
49.0001.1921.6803.6001.00

49.0001 - area - число 1-13 байт.

1921.6803.6001 - SYSTEM ID - обычно это просто ip loopback.

00 - selector

NET - можно назначить на любой интерфейс, на lo назначают для удобства.

SYSTEM ID должен быть уникален в рамках AREA.

=Отличия ISIS и OSPF=
В чем одинаковы:
*Поддерживают link-state database и находят кратчайший путь, используя алгоритм [https://youtu.be/0ZPuGE0aNKU Дейкстры]
*Используют hello пакеты для поддержания соседства
*Имеют функцию аутентификации
*Выбирают designated router
*Производят address summarization между area
*Используют двухуровневую иерархию

=Areas=
В ISIS линки делят сеть на area, а не роутеры, как в ospf.

По аналогии с OSPF есть backbone area: в ISIS это кучка роутеров L2. L2 роутеры могут соединять разные area.

Ротуеры, которые не имеют соединений с другими area - L1.

В area, которая не backbone и имеет связь с другой area - будет находиться роутер, имеющий линки, смотрящие в разные area, поэтому он будет называться L1/L2 роутером (как ABR в OSPF).

И еще:

; Два роутера с '''одинаковой''' AREA:
: Могут сформировать '''L1''' adjacency
: Могут сформировать '''L2''' adjacency
; Два роутера с '''разной''' AREA:
: Не могут сформировать '''L1''' Adjacency
: Сформируют '''L2''' Adjacency

=Multilevel operations=
==L2 network==
[[Файл:Isis_l2_network.jpg]]

При использовании L2 на всех роутерах будет сеть, аналогичная OSPF area 0. То есть все роутеры будут получать полные сведения о всей сети.

Тип LSP будет напрямую зависеть от Level соседства. Если установлено L1 соседство, то передаются LSP level1, если соседство L2, то и LSP будут L2.

L2 флудятся между всеми area.

==L1 network==

[[Файл:Isis_l1_network.jpg]]

Между всеми роутерами установлено соседство L1 и между собой роутеры обмениваются только LSP L1. Также все роутеры имеют одинаковую LSDB.

Выход во внешнюю сеть в подобных сетях обеспечивается засчет предоставления 0/0 маршрута Attached роутером.

Пример вывода с роутера, имеющего только L1 соседство:
talisker> show isis database
IS-IS level 1 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
talisker.00-00 0xe 0x85d1 861 L1 L2
'''macduff.00-00''' 0xc 0xfc02 859 L1 L2 '''Attached'''
macduff.02-00 0x5 0xa7cc 859 L1 L2
В таблице появляется маршрут (0/0 генерируется L1 роутером, а не анонсируется с L2):
talisker> show route protocol isis
inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[IS-IS/15] 00:08:07, metric 10
> to 192.168.86.14 via ge-0/0/0.70

Attached-bit можно отключить на L1 роутере следующим образом:
[edit protocols isis]
+ ignore-attached-bit;

==L1/L2 network==
[[Файл:Isis_l1_l2_network.jpg]]

L1/L2 сеть работает как NSSA в OSPF.

На L1/L2 роутерах происходит "суммирование" маршрутов L1 и "суммированный" маршрут флудится внутри L2 area. (по факту суммирования не происходит, просто передаются префиксы L1 в L2. Про суммирование/аггрегирование будет ниже). Почему это везде называется суммирование - не ясно.

Внутри каждой L1 area у всех L1 роутеров содержится одинаковая LSDB.

L2 маршруты не передаются в L1.

External L1 по дефолту не передаются в L2, можно разрешить с помощью policy.

L1 роутеры изолированы от изменений топологии в других area.

#L1 роутеры используют attached-bit, который генерируется L1/L2 роутером. Default route генерируется на L1 роутере в сторону L1/L2 роутера (который подсунул attached-bit).
#L1 роутеры используют кратчайший путь (по метрике) к attached роутеру.

При разделении роутеров на разные уровни повышается мастабируемость, т.к.:
#L1 изолированы от общей топологии сети, вне своей area.
#Суммирование L1 маршрутов позволяет L2 роутерам производить SPF не всей сети, а исключая L1.

=Действия внутри multilevel networks=
*L1 internal в L2 уходит без ограничений.
*L1 external в L2 уходит только через export-policy.
*L2 в L1 по умолчанию не уходит, только через export-policy.

L1 роутеры имеют только локальную маршрутную информацию, внутри своей area. Чтобы достичь назначения вне своей area, L1 роутеры используют default route.

В L1 PDU можно впихнуть и external routes (потребуется export policy). Но по умолчанию такие маршруты не будут передаваться L2.

Использование wide metrics убирает обозначение internal/external routes. Все становятся просто internal => все ext-L1 перетекают L2.

L2 PDU attached роутеров передают внутренние L1 маршруты своим L2 соседям в других area. L2-r не передает от своих L2-r соседей никаких маршрутов в сторону L1, поэтому L1 роутеры и нуждаются в default route.

Можно отключить функцию генерирования default-route на L1 роутрах:
set protocols isis ignore-attached-bit

'''БОЛЬШОЕ НО''': если у L1/L2 роутера есть соседство L2 в ДРУГОЙ area, то он будет вставлять attcahed-bit. Если такого соседства нет, то ему и не за чем добавлять attached к L1 link-state PDU.

Использование '''ignore-attached-bit'''. Когда применяется:
*Иногда админу требуется, чтобы L2 routes просочились к L1 => L1 больше не нуждается в default-route. Бывает, что появились криво сгенерированные (неподходящие) L1 LSP, L2 роутер будет их упаковывать в L2 LSP, чтобы передать своим L2 соседям. При этом сами L1 LSP, как таковые, флудиться не будут.
*Если сгенерированный def route с next-hop в сторону attached роутера не является оптимальным, то его можно просто отключить.

=Leaking routes=
Настраивается на L1/L2 роутере:
set policy-options policy-statement route-leak term L2-to-L1 from protocol isis
set policy-options policy-statement route-leak term L2-to-L1 from level 2
set policy-options policy-statement route-leak term L2-to-L1 from route-filter 192.168.16.0/20 orlonger
set policy-options policy-statement route-leak term L2-to-L1 to level 1
set policy-options policy-statement route-leak term L2-to-L1 then accept

При настройке подобного policy в 2 стороны (L2-to-L1, L1-to-L2), вполне себе может образоваться петля. Чтобы ее избежать, в LSP передается up/down bit.

На границе L2-to-L1 up/down bit = down, чтобы он точно не утек обратно/ниже из L1.
:- up = можно передавать маршрут.
:- down = уже есть утечка этого маршрута из другого level, поэтому его передача запрещена.

=ISIS соседство=
IIH = ISIS Hello packet. Используются для установления соседства.

Hold timer тоже передается в IIH.
*'''для non-DIS''': hello = 9 sec, hold = 3*9 = 27 sec.
*'''для DIS''': hello = 3sec, hold = 3*3 sec = 9 sec

Что проверяется при установление соседства:
*MTU checking = TLV 8. ISIS max mtg = 1492 bytes. Поэтому линка должен быть с mtu никак не меньше!
*The subnet checking = TLV 132. На p2p линке должны быть адреса из одной подсети.
*Protocol checking = TLV 129. CLNP ; IPv4 ; IPv6 … Тоже должны совпадать.
*Area checking = TLV 1. Area num используется только для L1 роутеров. Должна совпадать.

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

[[Файл:Isis-adjacency.png]]

*New - момент загрузки или при настройке начальной конфигурации IS-IS.
*One-Way - после Hello PDU. Роутер ждет Hello PDU пакет, содержащий свой адрес в качестве соседа.
*Initializing - Роутер получил Hello PDU со своим локальным адресом в качестве соседа.
*Up - соседство установлено, LSDB синхронизированы.
*Down - неверная area, истек таймаут или ошибка аутентификации.
*Reject - состояние маршрутизатора после сбоя проверки подлинности. IS-IS маршрутизатор будет постоянно менять свое состояние между этим и состоянием Down.

Для более быстрого распознавания потери соседа настраивается BFD. Например, для времени детектирования менее 450 мс
set groups isis protocols isis interface <ge-*> bfd-liveness-detection minimum-interval 150
set groups isis protocols isis interface <ge-*> bfd-liveness-detection multiplier 3

=Cуммирование маршрутов (Summarization)=
На L1/L2 роутерах настраивается суммирование/агрегирование маршрутов. Суммируются external L1 routes + L2 routes от других ISIS area (+ можно просуммировать internal L1 routes (хотя они итак по дефолту передаются L2)).

Пример, на роутере L1 есть локальные маршруты, их нужно агрегировать в 1 большой маршрут и переслать в сторону L2. Агрегирование и перенаправление в L2 будем делать на L1/L2 роутере.

Настраиваем policy:
set routing-options aggregate route 172.16.20.0/22
set policy-options policy-statement term on-the-L1L2 from protocol aggregate
set policy-options policy-statement term on-the-L1L2 from route-filter 172.16.20.0/22 exact
set policy-options policy-statement term on-the-L1L2 to level 2
set policy-options policy-statement term on-the-L1L2 then accept
set protocols isis level 1 export on-the-L1L2
Можно применять несколько policy. В таком случае они будут обрабатываться слева направо. Пока нужный префикс не поппадет под условие с последующим терминирующим действием (accept, reject).
set routing-options aggregate route 10.0.4.0/22
set policy-options policy-statement internal-L1-summary term local-summary from protocols aggregate
set policy-options policy-statement internal-L1-summary term local-summary from route-filter 10.0.4.0/22 exact
set policy-options policy-statement internal-L1-summary term local-summary to level 2
set policy-options policy-statement internal-L1-summary term local-summary then accept
set policy-options policy-statement internal-L1-summary term suppress-specifics from route-filter 10.0.4.0/22 longer
set policy-options policy-statement internal-L1-summary term suppress-specifics to level 2
set policy-options policy-statement internal-L1-summary term suppress-specifics then reject
set protocols isis export internal-L1-summary

=Алгоритм Дейкстры=
Shortest-path-first (SPF) рассчитывается отдельно для разных уровней, т.к. LSDB тоже заводятся для разных уровней.

Существуют:
*link-state database
*candidate database
*tree database.

LSDB - это данные на основании которых рассчитывается sortest-path-first. LSDB = router ID + neighbor ID + cost.

Движение по таблицам: lsdb -> candidate > tree.

Чтобы повысить сходимость, JunOS делает рассчет spf 3 раза, до того, как истечет hold-timer в 5 сек.
Этот тамймер установлен железно в JunOS и не конфигурируется.

Таймер гарантирует, что во время изменения топологии пакеты будут маршрутизироваться (несмотря не неправильность маршрутной информации).

Таймер spf-delay - конфигурируемый таймер, немного откладывает процесс spf. По дефолту 200 мс. Может быть от 50мс, до 1000 мс. Рекомендуется устанавливать чуть больше, чем самое высокое время прохождения пакета в сети, чтобы до роутеров успевали доходить lsp.

SPF делается в 2 шага:
#строится DB, где указаны все IS сети.
#нанесение анонсируемых префиксов на tree, и рассчет кратчайших путей до них, на каждом роутере.

'''Partial route calculation'''

Если какой-то роутер начинает аннонсить новый префикс или перестает анонсить старый, то нет смысла делать полный пересчет SPF. В таких случаях производится пересчет только ip reachability (только для конкретных префиксов). Каждый роутер сам решает какой пересчет (IS reachability или IP reachability) ему делать, на основании полученного lsp.

Маршруты приходят на роутер в виде LSP, потом производится расчет SPF и только после этого заносятся в таблицу маршрутизации. Поэтому, чтобы зафильтровать определенные маршруты с помощью policy, требуется делать это на роутере, генерирующем маршруты, с помощью export-policy. Import-policy - не работает в случае с ISIS.

=Метрики=
При расчете SPF используется cost на исходящих интерфейсах.

На одном линке разными роутерами могут быть назначены разные метрики. В этом случает ISIS ругаться не будет, но SPF будет рассчитвывать кратчайший путь в разных направлениях с разными стоимостями. Это только может усложнить админам работу, но ISIS будет работать.

Также в отличие от ospf, в isis по умолчанию используются только static metrics. Нет метрик, рассчитанных от interface bandwidth rate.

Но это дефолтное поведение можно поправить.
set protocols isis reference-bandwidth 10g

Для протоколов: direct, BGP, aggregate, generate метрика = '''10'''.

На passive интерфейсах metric = '''0'''.

Для static, OSFP и RIP маршрутов метрика = стоимости маршрута протокола.

==Wide metric==
Обычно в TLV типов 2, 128, 130 поле под метрику = 6 бит. Напомним, что эти TLV используются, чтобы передавать инфо о своих линках и external routes.
Т.е. максимальное значение метрики = '''63''' (0-63). Любое бОльшее значение метрики, настроенное на интерфейсе передается как 63.

Как я поняла, для рассчета spf это нифига не правильно и он добавляет несколько значений по 64, чтобы достичь нужного значения.

При внедрении функционала TE, появились 22 и 35 TLV, в них стали использовать 24-битные metrics (то есть значение метрики '''16,777,215''') и поле под total cost было расширено до 32 бит. При этом wide metrics не могут отличать internal маршруты от external.

По умолчанию в ISIS роутер передает и small и wide metrics. Так что значения метрик можно задавать в диапазоне: [0-16,777,215].

Можно настроить, чтобы роутер работал только с wide (рекомендуется), но стоит учесть, что тогда это автоматически уберет возможность различать internal/external routes. И в сети будут просачиваться external маршруты Level 1 в Level 2.
set protocols isis level 1 wide-metrics-only
set protocols isis level 2 wide-metrics-only

=Формат LSP=

LSP (link-state PDU ) описывает состояния соседства с другими роутерами в сети. Периодически флудится в рамках Level. Не пересекает границы уровня. Содержит TLV сегменты.

LSP флудится при изменениях в сети или по таймеру, чтобы содержать обновленную информацию.

PDU имеет поле remaining lifetime (2 байт), при создании PDU по дефолту таймер = 1200 sec = '''20 min'''.

Роутер, который получил PDU, начинает отсчет до 0. До того как таймер истечет (~ 317 sec), исходная система (роутер) пересоздает PDU и флудит его.

{| class="wikitable"
|-
| Protocol ID || Header length || Version || ID Length || PDU Type || Version || Reserved || Max area address || PDU
|}

''ID Length (6 байт), Max area address (3 байт)'' - иногда = 0х00 - это показывает, использует значения по умолчанию и что LSP совмещен с более старыми версиями протокола.

''PDU type'' - L1 (18) / L2 (20) PDU

''Version (1)'' - ранее использовалось как расширение под protocol ID, но в сейчас не используется вообще и значение = 0х01 (реально версия протокола).

''Version (2)'' - текущая версия протокола = 0х01.

'''Формат PDU headers and TLVs'''
{| class="wikitable"
|-
| PDU length || Remaining lifetime || LSP ID || Sequence number || Checksum || ATT, OL, IS Type bits || TLVs
|}

''LSP ID'' - 8 байт: 6 - router's system ID, 1 - circuit ID, 1 - LSP number. Придает уникальность внутри домена.

Circuit ID - 0x01 - for loopback или p2p interface, [0x02 - 0xff] - broadcast segment.

Sequence number = изначальный PDU имеет значение 0x01, каждый следующий фрагмент + 1.

''Attached bit (ATT)'' - ставится в L1 PDU, ISIS роутером, кот имеет соседство с L2. L1 роутер после этого передает пакеты к этому attached роутеру, если нужно выйти за пределы area.

''Overload (OL)'' - ставится, когда роутер хочет оповестить остальных, что он перегружен (скорее не хватает памяти) и не сможет надежно передать transit пакет. Сейчас крайне редко используется, так как роутеры мощные. При этом роутер будет продолжать генерировать LSP от себя, но транзитный трафик через него не должен проходить. Можно использовать, когда: 1. роутер должен быть выведен из сети на время работ. 2. роутер имеет большое кол-во bgp peers.

Можно включить или выключить overload bit на постоянной основе, а можно включить для него таймер (60-1800 сек). Таймер начинает тикать, когда ты закоммитишь конфиг + условие: должен работать rpd.

''IS type'' - определяет уровень роутера (L1 (0x01)/ L1 + L2(0x03))

=Hello PDU=
Используется для поиска, установления и поддержания соседства.

Разные hello для LAN (broadcast) и p2p сетей.

*P2P Hello для L1 и L2 имеют одинаковый формат [PDU17]
*LAN (broadcast) Hello
:*L1 (01-80-c2-00-00-14) [PDU15]
:*L2 (01-80-c2-00-00-15) [PDU16]

Передаются с интервалом 3 sec = DIS (designated IS), 9 sec = non-DIS .

Суть:
*Идентифицировать устр-во
*Описать его возможности
*Описать параметры интерфейса.

PDU filelds:
:- circuit type: L1, L2, L1/L2 router.
:- source ID: system ID of originated router.
:- hold timer: сколько ждать hello от соседа.
:- PDU length: в октетах (байтах).
:- Priority: 0-127 для DIS роутеров.
:- LAN ID: system ID или DIS + 1 октет.

=Link-state PDU=
Служат для:
*Идентификации IS соседств
*Описывает состояния своих соседств
*Описывает достижимые через него адреса.

Для построения LSDB.

Разные LSP для L1 и L2.

Отправляются в результате изменений в сети, во время формирования соседства и в ответ на sequence number PDU.

Отсылаются
#периодически
#когда упал линк к соседу
#когда появляется новый сосед
#изменилась стоимость линка.

=Sequence number PDUs=
'''Partial sequence number PDU''':
Используется для:
*Поддержания LSDB синзронизации
*Подтверждения LSPs от соседей на p2p сетях
*Запрашивает копию пропущенных LSP в broadcast сетях

Разный для L1 и L2 систем. Содержит спец информацию в заголовке для определенных LSP, кот подтверждены либо запрошены.

'''Complete sequence number PDU''':

Используется для поддержания LSDB синхронизации. Отправляется периодически всеми IS на p2p сетях, только DIS на broadcast сетях.

Разные типы для L2 и L1 систем.

Содержат инфо заголовка со всех LSP.

=TLV=
Type/Length/Value

Каждый кусочек информации в ISIS определяется как объект с атрибутами:
*Type: предопределенный код для типа информации, кот содержит объект.
*Length: размер информации
*Value: информация определенного типа

TLV это блоки для ISIS PDU, кот используются для обмена информации. Некоторые TLV могут быть использованы несколькими PDU, некоторые только конкретным PDU.

ISIS использует только известные TLV.

{| class="wikitable"
|+ Известные IS-IS типы TLV
! TLV Number !! Описание
|-
| 1 || Area address: area address, закодированный внутри ISIS NET на loopback.
|-
| 2 || IS neighbor metrics: соседи локального роутера + метрики для достижения этих соседей (0-64).
|-
| 6 || Neighbor LAN ID
|-
| 8 || Padding
|-
| 9 || LSP entries
|-
| 10 || Authentication: содержит тип аутентификации и пароль.
|-
| 22 || Extended IS reachability:
*IS соседи (system ID + wide metrics) и роутеры, которые поддерживают TE.
*sub-TLV описывают ограничения, заданные админом (определены также типы для каждого такого ограничения).
*Также эти TLV заполняют TE database.
|-
| 128 || IP internal reachability, prefix, mask, metrics: ip и mask для каждого интерфейса маршрутизатора, кот поддерживает IPv4.
|-
| 129 || Protocols supported: какие L3 протоколы поддерживает локальный роутер (IPv4, IPv6, CLNS - для SRX, J-series).
|-
| 130 || IP external information: netw+mask всех маршрутов, присланных в ISIS, используя policy.
|-
| 132 || IP interface addresses: host ip address для всех интерфейсов роутера.
|-
| 134 || TE IP router ID: router-ID локального роутера.
|-
| 135 || Extended IP reachability: ip+mask всех интерфейсов, пожжерживающих TE.
|-
| 137 || dynamic hostname resolution: ASCII hostname локального роутера.
|-
| 222 || Multiple topologies IS reachability: соседи локального роутера + роутеры, поддерживающие несколько топологий ISIS.
|-
| 229 || Multiple topologies supported: какие топологии ISIS поддерживает роутер. Каждая топология определена 12-битным полем с ID.
|-
| 232 || IPv6 interface address: IPv6 интерфейсов.
|-
| 235 || Multiple topologies (rout instances) IP reachability: ip интерфейсов, кот поддерживает несколько топологий.
|-
| 236 || IPv6 reachability: инфо о линке, где работает IPv6 протокол.
|}

=Пример LSP на роутере=
<tt>
'''vSRX2> show isis database extensive'''
IS-IS level 1 link-state database:

vSRX2.00-00 Sequence: 0x11f, Checksum: 0xb7a0, Lifetime: 1169 secs
IS neighbor: vSRX3.02 Metric: 10
Two-way fragment: vSRX3.02-00, Two-way first fragment: vSRX3.02-00
IP prefix: 2.2.2.2/32 Metric: 0 Internal Up
IP prefix: 10.0.0.0/30 Metric: 10 Internal Up
IP prefix: 10.0.0.4/30 Metric: 10 Internal Up

Header: LSP ID: vSRX2.00-00, Length: 218 bytes
Allocated length: 1492 bytes, Router ID: 2.2.2.2
Remaining lifetime: 1169 secs, Level: 1, Interface: 0
Estimated free bytes: 1187, Actual free bytes: 1274
Aging timer expires in: 1169 secs
Protocols: IP, IPv6

Packet: LSP ID: vSRX2.00-00, Length: 218 bytes, Lifetime : 1198 secs
Checksum: 0xb7a0, Sequence: 0x11f, Attributes: 0xb <L1 L2 Attached>
NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes
Packet type: 18, Packet version: 1, Max area: 0

TLVs:
Area address: 49.1111 (3)
Speaks: IP
Speaks: IPV6
IP router id: 2.2.2.2
IP address: 2.2.2.2
Hostname: vSRX2
IS neighbor: vSRX3.02, Internal, Metric: default 10
IS extended neighbor: vSRX3.02, Metric: default 10
IP address: 10.0.0.5
Local interface index: 74, Remote interface index: 0
Current reservable bandwidth:
Priority 0 : 980Mbps
Priority 1 : 980Mbps
Priority 2 : 980Mbps
Priority 3 : 980Mbps
Priority 4 : 980Mbps
Priority 5 : 980Mbps
Priority 6 : 980Mbps
Priority 7 : 980Mbps
Maximum reservable bandwidth: 1000Mbps
Maximum bandwidth: 1000Mbps
Administrative groups: 0 <none>
IP prefix: 10.0.0.0/30, Internal, Metric: default 10, Up
IP prefix: 10.0.0.4/30, Internal, Metric: default 10, Up
IP prefix: 2.2.2.2/32, Internal, Metric: default 0, Up
IP extended prefix: 10.0.0.0/30 metric 10 up
IP extended prefix: 10.0.0.4/30 metric 10 up
IP extended prefix: 2.2.2.2/32 metric 0 up
No queued transmissions
</tt>

=Designated Intermedia System (DIS)=
Не выбирается на p2p линках. Выборы производятся только между роутрерами, подключенными через один ethernet сегмент.

DIS отвечает за передачу link-state сообщений.

Как проверить, что на нашей сети не появился DIS:
show isis database
LSP ID Sequence Checksum Lifetime Attributes
sun-r1.'''00-00''' 0x81 0x7a6e 1153 L1
sirius-r2.'''00-00''' 0xd 0x292 616 L1
canopus-r3.'''00-00''' 0xa4 0x16cf 699 L1
arcturus-r4.'''00-00''' 0xc0 0xbe94 773 L1
... и т.д.

00-00 - первая пара 00 - это как раз pseudonode-id. Раз он равен 0, то DIS в данном сегменте нет. Если значение первой пары отличается (03-00, 05-00), значит выбран DIS.

==Выборы DIS в бродкаст сети / multi-access сети==
#приоритет: (0-127) для L1 и L2 назначаются разные, по умолчанию = 64. Передаются в hello PDU. Приоритет = 0 - роутер не участвует в выборах. На не бродкастных линках приоритет = 0.
#наибольший mac / SNPA.
#для L1 и L2 DIS выбирается отдельно.

set protocols isis interface ge-0/0/1.212 level 1 priority 105

ISIS сеть считается роутером, называемым pseudo-node: по факту просто создается некая сущность, типа виртуального роутрера, с которым все роутеры в бродкаст сети устанавливают соседство (в том числе и сам DIS).
*Каждый роутер анонсирует линк к pseudo-node, включая DIS.
*Каждый роутер формирует соседство с каждым роутером в бродкаст/мультиакцесс сети (в отличие от OSPF).

==Поведение DIS==
*Каждый роутер флудит свои link-state PDU каждому соседу, а не только DIS. DIS таким образом использует систему из PDU (sequence number PDU).
*DIS является представителем pseudo-node и пересылает pseudo-node всем присоединенным роутерам.
*Не существует backup DIS. при падении существующего DIS просто производятся новые выборы, и новый флуд link-state PDU.

Каждый DIS по дефолту каждые 10 сек отправляет CSNP (complete sequence number PDU) в LAN интерфейс. Также эти CSNP позволяют другим роутерам знать, когда DIS становится недоступным. Можно настроить таймер csnp (csnp-interval). Обычно для broadcast линка, где подключены только 2 роутера, этот интервал делают не очень коротким, т.к. в этом нет необходимости.

set protocols isis interface ge-0/0/0.0 csnp-interval (1-65535)

Пример Isis database с DIS на сети (вывод с canopus-r3, DIS=arcturus-r4):
IS-IS level 1 link-state database:
sun-r1.00-00 Sequence: 0x81, Checksum: 0x7a6e, Lifetime: 120 secs
IS neighbor: sirius-r2.00 Metric: 10
IS neighbor: procyon-r8.00 Metric: 10
IP prefix: 172.30.0.0/30 Metric: 10 Internal Up
IP prefix: 172.30.0.8/30 Metric: 10 Internal Up
IP prefix: 172.30.5.1/32 Metric: 0 Internal Up
sirius-r2.00-00 Sequence: 0xf, Checksum: 0x8b15, Lifetime: 808 secs
IS neighbor: sun-r1.00 Metric: 10
IS neighbor: rigel-r7.00 Metric: 10
IP prefix: 172.30.0.0/30 Metric: 10 Internal Up
IP prefix: 172.30.0.12/30 Metric: 10 Internal Up
IP prefix: 172.30.0.16/30 Metric: 10 Internal Up
IP prefix: 172.30.5.2/32 Metric: 0 Internal Up
canopus-r3.00-00 Sequence: 0xa9, Checksum: 0x8a8c, Lifetime: 1155 secs
IS neighbor: arcturus-r4.02 Metric: 10
IP prefix: 172.30.0.12/30 Metric: 10 Internal Up
IP prefix: 172.30.0.20/30 Metric: 10 Internal Up
IP prefix: 172.30.0.24/30 Metric: 10 Internal Up
IP prefix: 172.30.1.0/24 Metric: 10 Internal Up
IP prefix: 172.30.2.0/24 Metric: 10 Internal Up
IP prefix: 172.30.5.3/32 Metric: 0 Internal Up
a-centauri-r5.00-00 Sequence: 0x96, Checksum: 0x7374, Lifetime: 1161 secs
IS neighbor: arcturus-r4.03 Metric: 10
IP prefix: 172.30.0.28/30 Metric: 10 Internal Up
IP prefix: 172.30.0.32/30 Metric: 10 Internal Up
IP prefix: 172.30.5.5/32 Metric: 0 Internal Up
vegan-r6.00-00 Sequence: 0x92, Checksum: 0x7aca, Lifetime: 813 secs
IS neighbor: a-centauri-r5.00 Metric: 10
IS neighbor: rigel-r7.00 Metric: 10
IP prefix: 172.30.0.24/30 Metric: 10 Internal Up
IP prefix: 172.30.0.32/30 Metric: 10 Internal Up
IP prefix: 172.30.0.40/30 Metric: 10 Internal Up
IP prefix: 172.30.5.6/32 Metric: 0 Internal Up
rigel-r7.00-00 Sequence: 0x9, Checksum: 0x82f5, Lifetime: 275 secs
IS neighbor: sirius-r2.00 Metric: 10
IS neighbor: vegan-r6.00 Metric: 10
IS neighbor: procyon-r8.00 Metric: 10
IP prefix: 172.30.0.16/30 Metric: 10 Internal Up
IP prefix: 172.30.0.40/30 Metric: 10 Internal Up
IP prefix: 172.30.0.44/30 Metric: 10 Internal Up
IP prefix: 172.30.5.7/32 Metric: 0 Internal Up
procyon-r8.00-00 Sequence: 0x81, Checksum: 0xd174, Lifetime: 817 secs
IS neighbor: sun-r1.00 Metric: 10
IS neighbor: rigel-r7.00 Metric: 10
IP prefix: 172.30.0.8/30 Metric: 10 Internal Up
IP prefix: 172.30.0.44/30 Metric: 10 Internal Up
IP prefix: 172.30.5.8/32 Metric: 0 Internal Up
'''arcturus-r4.00-00''' Sequence: 0x4, Checksum: 0xb668, Lifetime: 1157 secs
IS neighbor: '''arcturus-r4.02''' Metric: 10
IS neighbor: '''arcturus-r4.03''' Metric: 10
IP prefix: 172.30.0.20/30 Metric: 10 Internal Up
IP prefix: 172.30.0.28/30 Metric: 10 Internal Up
IP prefix: 172.30.1.0/24 Metric: 10 Internal Up
IP prefix: 172.30.2.0/24 Metric: 10 Internal Up
IP prefix: 172.30.5.90/32 Metric: 0 Internal Up
'''arcturus-r4.02-00''' Sequence: 0x3, Checksum: 0xf44, Lifetime: 1158 secs
IS neighbor: canopus-r3.00 Metric: 0
IS neighbor: arcturus-r4.00 Metric: 0
'''arcturus-r4.03-00''' Sequence: 0x1, Checksum: 0x1495, Lifetime: 1157 secs
IS neighbor: a-centauri-r5.00 Metric: 0
IS neighbor: arcturus-r4.00 Metric: 0

= Аутентификация=
Можно настраивать в разных местах: L1, L2, на интерфейсах.

L1, L2 защищает hello PDU, LSP, порядковый номер pdu, отправленных в рамках определнного уровня.

Auth на интерфейсах шифрует только hello PDUs.

Типы:
*MD5 (включает checksumm ко всем пакетам)
*plain-text
*none

Можно выборочно отключить authen для конкретных типов PDU. Опция позволяет как не защищать конкретные PDU, так и не проверять пришедшие конкретные PDU.

no authentification-check | позволяет защищать исходящие пакеты, PDU, но при получении принимать все PDU, вне зависимости от того подходят ли они или нет.

=Mesh-groups=
Все роутеры флудят LSP всем своим соседям. В итоге один роутер может получать несколько одинаковых копий LSP.

Mesh-groups вводятся, чтобы в full-mesh сети сократить чрезмерный и избыточный флуд LSP.

Чтобы этого избежать, можно использовать mesh-groups. Члены группы не пересылают LSP внутри группы. Пересылаются только LSP, полученные извне группы.

set protocols isis interface ge-0/0/0.0 mesh-group 1
set protocols isis interface ge-0/0/1.0 mesh-group 2
set protocols isis interface ge-0/0/2.0 mesh-group blocked | икслючает флуд любых LSP от себя, но принимает LSP от соседей.

=Политики распространения маршрутов по умолчанию=
Как и OSPF, ISIS - link-state протокол. Таблица маршрутизации заполняется префиксами, прошедшими SPF алгоритм.

LSP заполняются не из inet.0, а из того, что сконфигурировано внутри <protocols isis>. В ISIS можно ограничивать internal routes и external routes с помощью export policy.

(в ospf можно фильтровать таким образом только external routes).

=Распространение маршрутов =
Чтобы в ISIS передать маршруты, полученные из других протоколов, требуется export-policy.

Также export работает и для ISIS маршрутов.

В policy как действие можно не только делать accept, но и устанавливать метрику и добавлять теги. Теги полезны для выборочной редистрибьюции. На принимающей стороне можно с помощью тегов разруливать маршруты.

Работает и import-policy на ISIS маршруты.

=Prefix limit (для external routes)=
JunOS + ISIS = это достаточно надежная система, которая позволяет стабильно работать и с большим числом префиксов, но лучше этого не допускать.

Желательно выставлять все-таки какое-то ограничение по количеству внешних маршрутов (1-4,294,967,295). При достижении лимита ISIS перестает принимать external routes + обозначает себя (через LSP) как overload. В таких случаях только ручное вмешательство спасает ситуацию.

То есть настраивается на ASBR, вероятно:
set protocols isis level 2 prefix-export-limit 2000
или
set protocols isis level 1 prefix-export-limit 2000

=Overload=
Настраиваем, если нужно вывести ненадолго роутер из эксплуатации.

timeout = (60..1800 seconds).

Если на роутере настроили overload, то при запуске протокола (rpd), overload bit = установленному интервалу.
НЕ с момента установления сосества, а именно со времени запуска протокола.

Механизм взаимодействия с другими роутерами отличается от OSPF.
*другие роутеры игнорят PDU от роутера в расчете SPF и через роутер никакой трафик не пойдет.
*если роутер является border router (L1/L2), то он перестает слать attached-bit к L1.

=Стоимость маршрутов (Junos Preference)=
*L1 internal = 15
*L2 internal = 18
*L1 external = 160
*L2 external = 165
т.к. best-practice - использовать wide-metrics, то в обычной жизни будем оперировать только internal preference. external - для старого формата метрик.

Preference можно менять внутри isis level:
set protocols isis level 1 preference 13 [internal]
set protocols isis level 1 external-preference 16 [external]

= Таймеры =
Соберем все цифры в кучу:
*hello: DIS = 3 sec, non-DIS = 9 sec
*hold (dead) = DIS = 9sec, non-DIS = 27 sec
*retransmit LSP = 5 sec (роутер ждет LSP ACK от роутера, которому отправлен LSP)
*DIS отправляет CSNP message каждые 10 sec в LAN сегмент. [Complete Sequence Number PDU]
*LSP Lifetime = 20 min (1200 sec) (maximum). Запускается обратный отсчет для чистки. Если lifetime = 0, то LSP удаляется.
*LSP refresh = ~317 sec
*ISIS database purge: R1 имеет LSP c lifetime = 0, удаляет из LSDB у себя и отправляет соседям эту LSP с lifetime = 0. Сосед получил. Сразу из LSDB не удалил, подождал 60 sec обновлений для LSP. Если обновление не пришло - удалил из LSDB.

=Использование IPv6=
Если в ISIS используются разные топологии для IPv4 и IPv6, то следует указать в конфиге, чтобы для ipv6 строилась своя топология:
set protocols isis topologies ipv6-unicast

=Конфигурация ISIS протокола=
Что обязательно:
*family iso на интерфейсах
*NET на одном из интерфейсов (обычно это lo). best practice: добавлять lo в protocols isis, даже если NET сконфигурирован не на нем. Конфиг Lo: isis работает на Lo в пассивном режиме: соседства с него не поднимает, но роутер передает о нём инфо, как о локальном линке. LSP генерируется автоматом и в L1 и в L2. (можно это действо запретить для одного из уровней).
*по умолчанию интерфейсы работают как L1/L2, если интерфейс должен быть только в L2, нужно выключить L1. И наоборот. Также можно глобально отключить работу одного из уровней <set protocols isis level 1 disable>.

Побочное:
*metric/cost: по дефолту = 10 (даже для passive), для loopback = 0. Каждый level на интерфейсе может иметь свою метрику.
set protocols isis interface ge-0/0/0.10 level 1 metric 50
set protocols isis interface ge-0/0/0.10 level 2 metric 20
*reference bandwidth: автоматический расчет cost. cost = reference bandwidth / bandwidth. При этом на всём роутере для разных линков остаётся одинаковый коэффициент. Говорят, в больших сетях помогает инженерам, вместо ручного метода.
set protocols isis reference-bandwidth
*остальные фичи, которые описаны в главе ISIS...

L1/L2 router:
set protocols isis traceoptions file isis-log size 10m files 10 world-readable
set protocols isis traceoptions flag state detail
set protocols isis traceoptions flag error detail
set protocols isis export L2-to-L1
set protocols isis export export-external
set protocols isis interface ge-0/0/0.110 level 1 disable
set protocols isis interface ge-0/0/0.130 level 2 disable
set protocols isis interface lo0.0 passive

set interfaces ge-0/0/0.110 family iso
set interfaces ge-0/0/0.130 family iso
set interfaces lo0.0 family inet address 192.168.13.4/32
set interfaces lo0.0 family iso address 49.0001.1921.6801.3004.00

L1 router:
set protocols isis traceoptions file isis-log size 10m files 10 world-readable
set protocols isis traceoptions flag state detail
set protocols isis traceoptions flag error detail
set protocols isis export export-to-L2
set protocols isis level 2 disable
set protocols isis interface ge-0/0/0.130
set protocols isis interface lo0.0 passive

set interfaces ge-0/0/0.130 family iso
set interfaces lo0 unit 0 family inet address 192.168.15.5/32
set interfaces lo0 unit 0 family iso address 49.0002.1921.6801.5005.00

=Траблшутинг соседства ISIS=
Что проверить:
*физика между роутерами
*несовпадение level
*mtu не должно быть меньше 1492
*отсутствие ip конфига на интерфейсах
*отсутствие/либо неверный конфиг ISO-NET: ошибочно включен iso на loopback

на p2p линках не обязательно использовать адреса из одной сети, линк может быть unnumberd или иметь /32 сеть.

=Мониторинг ISIS=
show isis interface | L = 3 = L1 / L2 router
show isis adjacency
show isis spf log
show isis statistics
show isis route
show isis database extensive

=Дополнительная информация=
*[[OSPF]]
*[[BGP]]

BGP

2021-07-15T18:43:29Z

Наталия Бобкова:

{{#description2:BGP в Juniper. Состояния соседства BGP. Сообщения. Атрибуты BGP. Local preference. AS Path. Next-hop. Communities. Механизмы управления трафиком. Multipath. Multihop. Route Reflection. Confederations. Route damping. Blackhole. }}
BGP - протокол маршрутизации между AS. Path-vector protocol.

'''IBGP''' - соседство внутри AS. Соседство строится обычно на Lo адресах.

'''EBGP''' - соседство между разными AS. Соседство строится на p2p адресах.

Поддерживает аутентификацию: MD5. Можно настроить key-chain, с указанием когда какой ключ использовать. Аутентификация применяется на разных уровнях protocols bgp.
=Состояния соседства=
http://habrastorage.org/getpro/habr/post_images/442/780/549/442780549c2f45cdda10773121b2800d.png

Для установления соседства используется TCP:179.
*'''Idle''': all incoming connections - refused. Инициализация BGP ресурсов и подготовка к установлению TCP. Если роутер завис в состоянии Idle - проверить наличие маршрута к соседу.
*'''Connect''': процесс установления TCP сессии. Роутер слушает TCP 179. Если сессия установилась, то роутер отправляет Open message и переходит в OpenSent состояние. Если TCP не установилась, то роутер переходит в Active состояние и запускает заново ConnectRetryTimer.
*'''Active''': local router становится активным инициатором TCP-сессии. В состоянии Active - когда ответил на прилетевший TCP. Если роутер завис в Active, проверяем: связность, прохождение по tcp:179, корректность настройки BGP с двух сторон.
*'''OpenSent''': Open отправлен локальным роутером и роутер ждет ответа (Open) от соседа.
*'''OpenConfirm''': Open сообщение получено от соседа и роутер ждет Keepalive или Notification message. Если от соседа не приходит keepalive до истечения hold timer, то роутер генерирует Notification message, с инфо, что hold timer expired и переведет сессию в Idle. Если keepalive получен, то соседство переходит в Established state.
*'''Established''': BGP сессия установлена, пиры начинают обмениваться информацией, используя: Update, Keepalive, Notification сообщений.

Hold timer может быть разным у пиров. При установлении сессии будет выбран наименьший.

==Tips==
Если сессия установилась в Established, но через какое-то время перешла в Idle по Hold timer expared (скорее всего через 90sec = 3*keepalive), то первым делом проверьте MTU на канале между роутерами.

Если MTU где-то по пути зарезан/не соответствует MTU на интерфейсах bgp-пиров, можно либо решить вопрос с MTU на найденном проблемном участке, либо можно установить для сессии вручную размер mss (maximum segment size):
set protocols bgp group clients neighbor 1.1.1.1 tcp-mss 1470

Признаки подобной проблемы в логах:
Jan 1 00:18:18.553797 bgp_io_mgmt_cb:1777: NOTIFICATION sent to 1.1.1.1 (Internal AS 64777): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 1.1.1.1 (Internal AS 64777), socket buffer sndcc: 0 rcvcc: 0 TCP state: 4, snd_una: 733415251 snd_nxt: 733415251 snd_wnd: 16384 rcv_nxt: 4248562819 rcv_adv: 4248579203, hold timer 90s, hold timer remain 0s, last sent 6s, TCP port (local 52746, remote 179)
Jan 1 00:18:18.553889 BGP SEND message type 3 (Notification) length 21
Jan 1 00:18:18.553901 BGP SEND Notification code 4 (Hold Timer Expired Error) subcode 0 (unused)
Jan 1 00:18:18.554014 bgp_peer_close_and_restart: closing peer 1.1.1.1 (Internal AS 64777), state is 7 (Established) event HoldTime
Jan 1 00:18:18.554064 RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 1.1.1.1 (Internal AS 64777) changed state from Established to Idle (event HoldTime) (instance master)

=Сообщения=
Все сообщения имеют '''Header'''
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Marker |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

BGP header содержит:
:*'''marker''' - 16 октетов, установлены в "1". Обозначает, что это bgp-пакет
:*'''lenght''' - размер пакета (16bit)
:*'''type''' - тип сообщения
:** 1 - OPEN
:** 2 - UPDATE
:** 3 - NOTIFICATION
:** 4 - KEEPALIVE
:**5 - ROUTE-REFRESH [определен в RFC 2918]

'''Типы пакетов:'''
*'''Open''' (type 1) - отправляется только на стадии установления соседства. Содержит параметры BGP соседа: AS, auth-type (+ ключ, если есть аутентификация).
*'''Update''' (type 2) - передает info о добавлении или удалении маршрутов между соседями. Update содержит в себе Path, его атрибуты и вложенные префиксы, у которых эти атрибуты одинаковые. Не отправляются по таймеру, приходят, только когда изменился сам префикс, его атрибуты или BGP-сессия. В зависимости от policy, на локальном роутере, часть routing info может быть отброшена и помещена в hidden.
*'''Notification''' (type 3) - в случае если что-то пошло не так: не прошел keepalive или update, пришла не поддерживаемая опция, ... Существуют стандартизированные коды ошибок (operation code | opcode). Пакет состоит из header + opcode+subcode + data (описание ошибки - для диагностики).
*'''Keepalive''' (type 4)- для удостоверения, что с соседством все ok. Отправляется каждые 30 sec. По дефолту hold-timer = 3 * keepalive = 90sec - время, после которого соседи рушат соседство (если в это время не пролетело ни одного keepalive). Можно выставить holdtimer = 0. Если у одного соседа = 0, у другого нет, то будет согласовано ненулевое значение holdtimer для сессии.
{{note|text=keepalive message = BGP header без payload}}
*'''Refresh''' - soft clearing BGP сессии.

=BGP Operations=
BGP хранит маршруты в трех местах:
*Adjacency-RIB-IN: все полученные маршруты от пиров
*RIB-Local: маршруты локального роутера, используемые для передачи трафика. Тут хранятся только активные маршруты.
*Adjacency-RIB-OUT: маршруты, которые будут отправляться пирам. Передаваться могут только активные маршруты. ('''advertise-inactive''' исправляет данную ситуацию).

Передача маршрутов производится по правилам (чтобы избежать routing loops):
#IBGP пиры передают маршруты, полученные от EBGP другим IBGP пирам.
#EBGP пиры передают маршруты, полученные от EBGP и IBGP другим EBGP пирам
#IBGP пиры не передают маршруты, полученные от других IBGP пиров. Поэтому для того, чтобы получить всю маршрутную информацию, требуется full-mesh связность. Либо использование RR.

По умолчанию IBGP пиры не меняют next-hop для маршрутов, полученных от EBGP.

Решается:
* настройкой '''next-hop self''' в рамках export policy к remote PE/RR.
* добавить p2p интерфейс с EBGP пиром в IGP как passive.
* анонс p2p сети по IGP. Export policy для IGP протокола.
* настройки статического маршрута на каждом IBGP до удаленного EBGP пира.
* настроить IGP соседство с EBGP пиром.

=Атрибуты (BGP attributes)=
Включаются в Update сообщения и описывают BGP префиксы. Атрибуты используются для выбора активного пути.
Атрибуты, при выборе best, считаются лучшими с наименьшими значением
Это правило касается всех атрибутов, кроме Local Preference

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

==Local preference==
'''✔️Well-known Discretionary'''
* Указывает маршрутизаторам внутри автономной системы как выйти за её пределы.
* Больший приоритет выигрывает.
* Этот атрибут передается только в пределах одной автономной системы => работает только для IBGP.
* На маршрутизаторах Cisco и Juniper по умолчанию значение атрибута — 100.
* Если EBGP-сосед получает обновление с выставленным значением local preference, он игнорирует этот атрибут.
* В Junos lpf можно задать через policy и в protocol bgp. Если задан обоими способами, то будет назначен lpf из policy.
* Обычно используется на бордерах.
{{note|text=Когда в сети есть 2 бордера, которые получают один и тот же маршрут извне, и бордеры навешивают одинаковый повышенный lpf через export policy, в таком случае соседи IBGP получат маршрут с измененным lpf, но трафик не сможет по-правильному пути выйти из AS. Из-за того что бордеры тоже друг от друга будут получать маршрут с повышенным lpf. Решение: правильно менять lpf через import policy. }}

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

Используется для:
* обнаружения петель
* влияние на path selection с помощью prepending (делается через export policy)
set protocols bgp group int export longer-as-path
set policy-options policy-statement longer-as-path term 1 then as-path-prepend "1111 1111 1111"

show route advertising-protocol bgp 10.200.86.2
inet.0: 32 destinations, 32 routes (32 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.17.0.0/24 Self 100 '''1111 1111 1111 [1111] I'''

'''Обозначение:'''
* [] - 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|Список регулярных выражений для AS Path}}
. - любой знак (одна точка - один любой знак, 3 точки - три любых символа).

==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 на выходе (export к IBGP):
set policy-options policy-statement nexthop-self term localpref then next-hop self

Или же на входе (import от EBGP peer):
set policy-options policy-statement nexthop-peer term localpref then next-hop ''peer-address''

==Origin==
'''✔️Well-known Mandatory'''
Атрибут '''Origin''' — указывает на то, каким образом был получен маршрут в обновлении. Меняется с помощью policy.
{| class="wikitable"
|+Возможные значения атрибута
|-
|'''0'''
|IGP
|NLRI получена внутри исходной автономной системы
|-
|'''1'''
| EGP
| NLRI выучена по протоколу Exterior Gateway Protocol (EGP) - протокол уже давно не используется.
|-
|'''2'''
| Incomplete
| NLRI была выучена каким-то другим образом, скорей всего через redistribution.
|}

==Atomic aggregate==
'''✔️Well-known Discretionary'''

==Aggregator==
'''✔️Optional Transitive'''

==Communities==
'''✔️Optional Transitive'''
* Тегирование маршрутов
* Существуют предопределенные значения (well-known), которые не требуется определять локально на своем оборудовании
* По умолчанию не пересылаются соседям
* Одному маршруту может быть присвоено несколько communities
*Community могут быть критерием в policy для изменения других атрибутов BGP, например lpf.
* Один из вариантов применения: передается соседней 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-test'' detail

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

===Действия с community===
*add - добавляет к текущим community префикса указанное community
*delete - удаляет только указанное community
*set - заменяет существующие community на указанное

==Multi exit discriminator (MED)==

'''✔️Optional Non-transitive'''

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

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

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

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

MED назначается с помощью policy.
===Возможные операции с 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''':
* Позволяет назначить "вес" различным путям локально на маршрутизаторе.
* Используется в тех случаях, когда у одного маршрутизатора есть несколько выходов из автономной системы (сам маршрутизатор является точкой выхода).
* Имеет значение только локально, в пределах маршрутизатора.
* Не передается в обновлениях.
* Чем больше значение атрибута, тем более предпочтителен путь выхода.

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

==Исходящим==
*Проприетарный атрибут Cisco weight (локально на маршрутизаторе)
*Local Preference (локально в AS)
*Косвенно можно политикой навешивать med на префиксы от пира и в зависимости от этого будет также регулироваться исходящий трафик.

=Выбор лучшего пути (BGP Active Route Selection)=
# Проверяем, что резолвится next-hop (без это маршрут и активным то не будет :/ )
# Route Preference (Admin distance)
# БОльший local preference (''Inactive reason: '''Local Preference''''')
# Кратчайший AS-path (''Inactive reason: '''AS path''''')
# Меньший Origin value (''Inactive reason: '''Origin''''')
# Меньший MED value (''Inactive reason: '''Route Metric or MED comparison''''')
# EBGP peer предпочтительней IBGP peer (''Inactive reason: '''Interior > Exterior > Exterior via Interior''''')
# C кратчайшей IGP метрикой к Protocol next-hop (''Inactive reason: '''Not Best in its group – IGP metric''''')
# Если префикс получен по IBGP, то используем префикс от пира с наименьшим RID (''Inactive reason: '''Not Best in its group – Router ID''''')
# Если префикс получен по EBGP, то используем более старый активный префикс (считается более стабильным) (''Inactive reason: '''Not Best in its group – Active preferred''''')
# При использовании RR: кратчайший cluster list length (''Inactive reason: '''Not Best in its group – Cluster list length''''')
# Наименьший router-ID (''Inactive reason: '''Not Best in its group – Router ID''''')
# Наименьший Source IP address (''Inactive reason: '''Not Best in its group - Update source''''')

В Juniper можно посмотреть причину неактивности маршрута: ''Inactive reason'' в выводе ''sh route protocol bgp x.x.x.x extensive''

Дефолтное поведение для EBGP маршрутов может быть изменено: '''path-selection external-router-id'''. При включении этой функции для роутера выбор активного EBGP маршрута от разных роутеров будет делаться по наименьшему router-id.

*Route Preference (Admin distance) - не передается по ibgp, ebgp. Может только навешиваться через import-policy или в настройках bgp на любом уровне иерархии.

=Multipath=
Один и тот же маршрут прилетает с двух пиров одной AS или несколько копий маршрута прилетает с одного пира. Активный маршрут будет вставлен в routing table с несколькими next-hop и трафик будет балансироваться между двумя пирами (в forwarding table все же будет вставляться один next-hop). Для inactive маршрутов будет указан один next-hop. Multipath не вставит маршруты с одинаковым MED-plus-IGP cost, при разных IGP метриках до пиров. На роутере глобально должен быть включен load-balancing.

При включенном multipath, алгоритм выбора лучшего пути игнорирует router ID и peer ID.

До включения:
mortlach> show route protocol bgp terse
inet.0: 30 destinations, 34 routes (30 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 172.17.0.0/24 B 170 100 >192.168.86.21 I
B 170 100 >192.168.86.42 I
* 172.17.1.0/24 B 170 100 >192.168.86.21 I
B 170 100 >192.168.86.42 I
* 172.17.2.0/24 B 170 100 >192.168.86.21 I
B 170 100 >192.168.86.42 I
* 172.17.3.0/24 B 170 100 >192.168.86.21 I
B 170 100 >192.168.86.42 I
mortlach> show route forwarding-table destination 172.17.0.0/24
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
172.17.0.0/24 user 0 indr 262142 5
192.168.86.21 ucst 547 5 '''ge-0/0/0.90 - выбран активным, из-за меньшего router-ID (10.200.86.4 vs 10.200.86.8)'''

После:
mortlach> show route protocol bgp terse
inet.0: 30 destinations, 34 routes (30 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 172.17.0.0/24 B 170 100 192.168.86.21 I
>192.168.86.42
B 170 100 >192.168.86.42 I
* 172.17.1.0/24 B 170 100 192.168.86.21 I
>192.168.86.42
B 170 100 >192.168.86.42 I
* 172.17.2.0/24 B 170 100 192.168.86.21 I
>192.168.86.42
B 170 100 >192.168.86.42 I
* 172.17.3.0/24 B 170 100 192.168.86.21 I
>192.168.86.42
B 170 100 >192.168.86.42 I

mortlach> show route forwarding-table destination 172.17.0.0/24
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
172.17.0.0/24 user 0 indr 262143 5
192.168.86.42 ucst 588 7 '''ge-0/0/0.50''' - '''изменился, т.к. router ID уже не влияет на выбор лучшего пути'''

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

Позволяет делать балансировку пропорционально заданным в community скоростям.

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

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

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

Конфиг 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:
set interfaces lo0 unit 0 family inet address 2.2.2.2/32

set policy-options policy-statement bw20 then community add bw20
set policy-options policy-statement bw80 then community add bw80

set policy-options policy-statement from-direct term redistribute-direct from protocol direct
set policy-options policy-statement from-direct term redistribute-direct then accept
set policy-options policy-statement from-direct term default then reject

set policy-options community bw20 members bandwidth:2222:2500000; '''// 2500000 байт в секунду — это 20% от 100Мегабит'''
set policy-options 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 bw20'''
peer-as 1111;}
neighbor 10.2.0.1 {
description R1;
export [ bw80 from-direct ]; '''// На второе соседство навешивается community bw80'''
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

=Multihop=
Возможность поднять EBGP peering между роутерами, не имеющих прямого физического соединения. Сессия устанавливается на lo интерфейсах.

Важно в конфиге задать multihop. В таблице маршрутизации должен быть маршрут до пира.

При поднятии сессии на Lo интерфейсах используем:
*''set system default-address-selection'' - будет браться адрес lo автоматически
*local-address (bgp, group или neighbor) - более специфичен, поэтому если надо будет - перебьет уже настроенный default-address-selection

TTL = 1 задаем, чтобы соседство установилось точно с одним ближайшим роутером. (либо другое значение, если роутер далеко)

blair> show route 10.200.86.4
10.200.86.4/32 *[IS-IS/18] 00:00:03, metric 10
to 192.168.86.49 via ge-0/0/0.80
> to 192.168.86.17 via ge-0/0/0.100
Config
set protocols bgp group int type internal
set protocols bgp group int multihop ttl 1
set protocols bgp group int local-address 10.200.86.1
set protocols bgp group int neighbor 10.200.86.4

Т.к. между роутерами теперь 2 физических линка, то можно балансировать трафик между ними.

=Modifying AS Path=
==Option 1: remove-private==
Диапазон: 64512 - 65534

Роутер, на котором настроен remove-private перед передачей префиксов удаляет из AS path AS из указанного выше диапазона.

Можно настраивать на всех уровнях: protocols bgp, group, neighbor.

==Option 2: local-as==
set routing-options autonomous-system 1111
set protocols bgp group ebgp neighbor 10.1.0.2 peer-as 2222
set protocols bgp group ebgp neighbor 10.1.0.2 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:
set protocols bgp group ebgp neighbor 10.1.0.2 peer-as 2222
set protocols bgp group ebgp neighbor 10.1.0.2 local-as 3333 '''private'''

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

==as-override==
CE1 '''(AS 65500)''' <> PE (AS 1111) <> P (AS 1111) <> PE (AS 1111) <> CE2 '''(AS 65500)'''

Если на сети ISP есть 2 сессии с пирами из одной AS, то при передаче маршрутов, полученных от одного site этой AS второму site'у, второй site не примет такой префикс, потому что в AS path будет дважды указана его AS - это routing loop.
65500 1111 I - '''роутер с AS 65500 не примет префикс с таким AS path.'''

set protocols bgp group int neighbor 10.200.86.4 as-override
Можно конфигурировать для группы или соседа.

Роутер ISP на полученном префиксе смотрит в AS path, AS пира заменяем на свою. При передаче префикса второму site ISP делает стандартный prepend своей AS. В итоге пиру в AS 65500 прилетит префикс с таким AS path:
1111 1111 I

==loops==
Еще один способ решения ситуации, описанной в примере выше - чтобы CE2 получил маршрут своего удаленного site:

На CE2:
set routing-options autonomous-system 65500 loops 2
Тогда на CE2 прилетит префикс с AS path:
1111 65500 I
и роутер это сожрет.

=Опции настройки для пиров=
*'''passive''' - локальный роутер перестает слать open message. Чтобы сессия поднялась, open message теперь должно прийти от удаленного пира.
blair# top show | compare
set protocols bgp group int neighbor 10.200.86.4 passive

Feb 11 22:07:58.812668 BGP SEND message type 1 (Open) length 59
Feb 11 22:07:58.856999 BGP RECV message type 1 (Open) length 59
После задания passive для пира:
Feb 11 22:12:22.128876 BGP RECV message type 1 (Open) length 59
* '''allow''' - принимает open message только из указанной сети. Можно указать только для определенной группы:
set protocols bgp group int allow 10.200.86.0/24
*'''prefix-limit''': ограничивает значение полученных префиксов от пира. Можно применять на разных уровнях иерархии.
set protocols bgp group int neighbor 10.200.86.4 family inet unicast prefix-limit maximum 1500
set protocols bgp group int neighbor 10.200.86.4 family inet unicast prefix-limit teardown 100 ('''%''') idle-timeout 10 ('''min''');}}}
*'''hold-time''': меняем hold timer. По дефолту 90 sec. Можно применять на разных уровнях иерархии.
set protocols bgp hold-time 120
*'''advertise-peer-as''': позволяет EBGP маршруты передавать обратно EBGP пиру. Но тогда и у пира должен быть настроен as loops, чтобы он не отбросил префикс с лупом в AS-Path.
set protocols bgp group int advertise-peer-as

=Route Reflection=
Описан в RFC 4456

'''Концепция'''

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

==Распространение маршрутов при использовании RR==
[[Файл:RR.png|700px]]

Будем использовать следующие обозначения:
*IBGP rr-client - IBGP сосед в кластере
*IBGP NON-rr-client - IBGP сосед не в кластере
*EBGP - EBGP сосед

Распространение маршрутов происходит следующим образом:
*IBGP rr-client > IBGP rr-client + IBGP NON-rr-client
*IBGP NON-rr-client > IGBP rr-client
*IBGP NON-rr-client <> IBGP NON-rr-client - '''не передается'''

*EGBP > IBGP rr-client + NON-rr-client

Если включить '''no-client-reflect''', то это запретит анонсить префиксы между клиентами кластера. В таком случае, если требуется сохранить связность между этими клиентами - нужно настроить между ними full-mesh. Такой вариант развитий по идее может понадобиться только при иерархичном роут-рефлектинге (о нем ниже).

RR добавляет/изменяет атрибуты (без политик по дефолту):
*'''Originator ID'''
Router ID первого роутера, который заслал маршрут в AS.

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

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

Правила работы с Originator и Cluster List:
*для EBGP или любого другого протокола, отличного от IBGP, originator и сluster list не добавляются
*для IBGP client<>client / client<>non-client:
:*originator добавится только если до этого его не существовало.
:*Cluster list дополнится новым cluster ID.
:*Cluster ID будет установлен, если его не было ранее.

'''2 RR в кластере'''

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

==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 на lo0 адресах (с включенным multihop!!)

==Hierarchical Route Reflection==
[[Файл:Hierarch_RR.png|700px]]

Отличие от предыдущих: в схеме появляются не только RR и client, но еще и роутеры, выполняющие обе функции в рамках разных кластеров.
Clients могут устанавливать IBPG между собой full-mesh. Это удобно использовать, чтобы 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-hop только у 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

=Fake-group=
Данная проблема описана в KB20870 (https://kb.juniper.net/InfoCenter/index?page=content&id=KB20870).

Более подробное описание и рекомендации по предотвращению https://www.juniper.net/documentation/en_US/junos/topics/example/bgp-vpn-session-flap-prevention.html

По факту функционал RR включается/выключается только при добавлении/удалении соседу в группе с клиентами (с '''cluster''').

Если на маршрутизаторе настроены '''EBGP с клиентами''' или '''IBGP c RR''', для которых в конфигурации группы '''включены vpn-address-family''', (inet-vpn, inet6 inet-mpvn, inet-mdt, inet6-mpvn, l2vpn, iso-vpn) и на маршрутизаторе в этих группах производится добавления первого соседа или удаления последнего, Juniper рестартует BGP сессии с RR и c EBGP пирами в VPN-address-family для отсылки NLRI с новой (удалением старой) address-family.

Для предотвращения подобных ситуаций можно предпринять следующие шаги:
* на каждом RR создана fake группа (для исключения проблемы удаления последнего соседа в группе).
* на каждом PE создана fake группа (для исключения проблемы включения нового клиента с EBGP + vpn-family)

==Configuration==
Fake группа имеет следующий вид для '''RR и PE''':
group fake-vpn {
type '''external''';
description "-- Preventing mpbgp sessions flap --";
'''passive''';
family inet {
any;
family inet-vpn {
any;
family iso-vpn {
unicast;
family l2vpn {
signaling;
family evpn {
signaling;
family inet-mvpn {
signaling;
family inet-mdt {
signaling;
'''neighbor 101.101.101.101''' {
'''peer-as 101''';

=IPv6 (6PE)=
Если у нас есть настроенная ipv4 сеть и мы захотели передавать трафик и для ipv6 адресов (используя MPLS), то:

- требуется настроить family inet6 labeled-unicast explicit-null на сессии pe<>rr
set protocols bgp group ibgp-rr family inet6 labeled-unicast explicit-null
эта family навешивает на ipv6 префикс '''label 2''' (explicit-null для ipv6), что позволяет на сети в качестве транспорта использовать mpls, а на последнем роутере делать lookup в таблице inet6.0.

- на сети у нас скорей всего уже будет включен mapping ipv4 адресов в ipv6:
set system allow-v4mapped-packets
- при передаче префиксов pe->rr должен быть настроен в политике hext-hop self. При этом для ipv6 префиксов будет подставляться mapped ipv6 адрес lo0.
rr> show route receive-protocol bgp 172.30.5.5
inet.0: 56 destinations, 58 routes (55 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 192.168.31.0/24 '''172.30.5.5''' 100 64514 I
* 192.168.32.0/24 '''172.30.5.5''' 200 64514 I
inet6.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
fd17:f0f4:f691:5::31/128
* '''::ffff:172.30.5.5''' 100 64514 I
- на rr адреса '''::ffff:172.30.5.5''' не будет, поэтому полученный префикс будет в hidden, из-за неотрезовленного next-hop. Чтобы решить эту проблему прописываем статику:
rr> show configuration routing-options
rib inet6.0 static route ::ffff:172.30.5.0/124 receive;
'''receive''' в данном случае позволяет сделать маршрут активным, не прибегая к форвардингу трафика.

- после этого рефлектор спокойно рефлектит маршрут своим клиентам.

- далее, pe получит префикс, но с принятым next-hop '''::ffff:172.30.5.5''' это префикс опять же не станет активным в таблице. Тут решение static с next-hop receive - не проканает, ибо нам нужно передавать трафик к префиксу, а не просто вставить его в таблицу маршрутизации. Тут прибегнем к варианту, который маршруты ldp для desct-ipv4 замапит в dest-ipv6 из inet.3 и поместит их в inet6.3 (для резолва ipv6 префиксов):
set protocols mpls ipv6-tunneling

rigel-r7> show route protocol ldp 172.30.5.5
'''inet.3''': 25 destinations, 32 routes (8 active, 0 holddown, 22 hidden)
'''172.30.5.5/32''' *[LDP/9] 01:17:08, metric 20
to 172.30.0.41 via ge-0/0/0.240, Push 319216
> to 172.30.0.46 via ge-0/0/3.244, Push 340912

rigel-r7> show route protocol ldp ::ffff:172.30.5.5
'''inet6.3:''' 8 destinations, 10 routes (8 active, 0 holddown, 0 hidden)
'''::ffff:172.30.5.5/128''' *[LDP/9] 01:17:20, metric 20
to 172.30.0.41 via ge-0/0/0.240, Push 319216
> to 172.30.0.46 via ge-0/0/3.244, '''Push 340912'''

ну и проверяем, что и сам префикс стал активным:
rigel-r7> show route fd17:f0f4:f691:5::31/128
inet6.0: 20 destinations, 22 routes (20 active, 0 holddown, 0 hidden)
fd17:f0f4:f691:5::31/128 *[BGP/170] 00:50:51, localpref 100, from 172.30.5.41 AS path: 64514 I
to 172.30.0.41 via ge-0/0/0.240, '''Push 2''', Push 319216(top)
> to 172.30.0.46 via ge-0/0/3.244, '''Push 2, Push 340912(top)'''

Кстати, ipv6 tunneling перетаскивает как ldp, так и rsvp маршруты в inet6.3.

=Confederations=
Описан в RFC 3065

'''Принципы'''

Цель: разбить global AS на sub-AS.
*sub-AS должна иметь уникальный номер (зачастую берут приватные AS).
*Внутри sub-AS между роутерами: full-mesh IBGP. Если внутри sub-AS будет слишком большая сеть, то в нее можно внедрить RR.
*Между sub-AS - EBGP = confederation BGP = CBGP. При прохождении маршрута через CBGP линк, роутер меняет AS path, включая туда AS sub-AS - этот метод - защита от петель. Другие атрибуты BGP не меняются.

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

==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]

confederation ''<>'' - это номер public AS.

в качестве members - определяются все AS, включенные в конфедерацию.

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

=Route damping (flapping)=
При различных обстоятельствах на сети могут возникать флапы маршрутов, что приводит к загрузке CPU на роутерах.

Чтобы избежать подобного поведения есть некоторые механизмы защиты от флапов, например: '''BGP route flap damping'''.

Damping игнорируется IBGP и работает только с EBGP и CBGP (confederation BGP).

Damping уменьшает кол-во update message, путем обозначения флапающих маршрутов непригодными стать активными маршрутами.

'''Принцип работы:'''

Когда маршрут прилетает на наш роутер (на котором настроен route damping), на префикс назначается значение merit = 0.

Как только роутер распознает некую нестабильность маршрута (префикс просто перестает долетать до роутера (или линк упал)):
*назначается merit = 1000, включается счетчик decay half-life. Если на роутер снова прилетит префикс, до того, как истечет таймер, то значение merit увеличится еще на 1000 +1000. И подобное поведение будет повторяться до превышения значения merit до supress (3000) - префикс в таком случае будет признан непригодным для использования.

После того, как префикс пропал и заново прилетел на роутер по BGP, его значение merit = 2000 (при дефолтных настройках)
Merit (last update/now): 1969/1938
Default damping parameters used
Last update: 00:00:27 First update: 00:00:49
Flaps: 2

После этого при исчезновении маршрута с роутера, его не будет видно в inet.0, но инфо можно будет посмотреть в
blair> show route damping history detail

После того, как будет превышен supress threshold, инфо о маршруте можно будет посмотреть:
blair> show route damping suppressed detail

Либо в hidden, если маршрут приходит от пира.

*если префикс передается от роутера, то он передается со значением merit = 1000.
*если изменяется path attribute, то префиксу ставится значение 500.
*decay half-life - кол-во минут после которого значение merit уменьшается вдвое, при поведении маршрута более стабильно. default = 15 min.
*max-supress - максимальное кол-во минут, которое маршрут проводит в состоянии hold-down. default = 60 min.
*reuse threshold - произвольное значение, после которого маршрут снова можно использовать. default = 750.
*supress threshold- произвольное значение, после которого маршрут больше нельзя использовать. default = 3000.
==Config==
Как только включаем на роутере damping, без заданных параметров, для работы будут использоваться дефолтные значения.

Параметры задаются через policy. '''Disable''' - для определенных префиксов удаляет merit, и убирает префикс из damping процесса (могут быть например public DNS).

set policy-options damping c11 half-life 30
set policy-options damping c11 reuse 1000
set policy-options damping c11 max-suppress 500

set policy-options policy-statement c11-damping then damping c11

set protocols bgp group c11 type external
set protocols bgp group c11 damping
set protocols bgp group c11 import c11-damping

=Blackhole=
Когда на сети определено специальное community для blackhole, и клиент посылает префикс, помеченный этим community, нужно реализовать блокировку трафика на нашей сети к этом префиксу. И желательно разослать этот префикс другим пирам и апстримам с их blackhole-community.

Блокировку трафика можно организовать несколькими способами.

1. зарулить трафик на префикс, у которого next-hop = discard.
set policy-options policy-statement blackhole from protocol bgp
set policy-options policy-statement blackhole from community blackhole
set policy-options policy-statement blackhole then next-hop 192.168.0.101
set policy-options policy-statement blackhole then accept
set routing-options static route 192.168.0.101/32 discard
set routing-options static route 192.168.0.102/32 discard

здесь без accept - видимо не происходит еще один lookup и next-hop остается unusable.
Либо resolve происходит, но с next-hop discard маршрут не считается активным и остается в hidden.

Тема discard не раскрыта :)

2. зарулить на discard interface (dsc). - подробно лучше смотреть в документации Juniper.

3. сделать у префикса сразу next-hop discard.

set policy-options policy-statement blackhole from protocol bgp
set policy-options policy-statement blackhole from community blackhole
set policy-options policy-statement blackhole then '''next-hop''' discard
set policy-options policy-statement blackhole then '''accept'''
set policy-options community blackhole members "6451[0-9]:666"

без accept маршрут будет в hidden и не передастся своим ibgp соседям. (в hidden, так как next-hop unusable)

Политику применяем на клиентов и на ibgp сессии в рамках нашей aAS (+cbgp, если используем конфедерации)

Чтобы разослать префикс другим ebgp пирам добавляем еще одну строчку в политику:
set policy-options policy-statement blackhole then community add upstream-blackhole

TIPS:
*если в политике делать только then discard - это заблочит распространение префикса на сети, что не совсем решает проблему. Через нашу сеть все-равно будет идти трафик до этого dest, просто обходными путями.
*обычно клиенты шлют /32 префиксы с blackhole-community, а на import фильтрах у уважающих себя операторов есть ограничение по длине префикса (<24).

Поэтому, чтобы получить /32, добавляем в политику условие:
set policy-options policy-statement blackhole from route-filter 0.0.0.0/0 prefix-length-range /32-/32

=BFD=
Как известно, этот механизм используется в качестве обмена hello сообщениями с заданным интервалом, ниже, чем дефолтный интервал в других протоколах. Что позволяет протоколу быстрее обнаружить падение сессии.

Сильно нагружает CPU RE, поэтому с ним сильно перебарщивать не стоит.

minimum-interval - минимальный интервал получения и отправления "hello" BFD. То есть это интервал с которым локальный роутер отправляет hello и интервал, с которым локальный роутер ждет ответа на свой hello. Также в конфиге можно отдельно задать transmit и receive minimum interval.

BFD + graceful restart - не рекомендуется.

BFD + Routing Engine switchover event - не рекомендуется ниже 5000мс.

BFD + NSR - не рекомендуется ниже 2500мс.

для очень больших сетей с большим кол-вом bfd сессий - не ниже 300мс

=IPv6=
Есть несколько способов настраивать BGP между роутерами, работающими с ipv6.
*Прямая ipv6 сессия на ipv6 адресах:

На интерфейсах обычные p2p адреса из /126 (/30) сеточки. Это самый примитивный вариант.
group r7-ipv6 {
type external;
export export-direct;
peer-as 54591;
neighbor fc09:c0:ffee::1;}

Настраиваем сессию на ipv6 адресах в отдельной группе. Если настраивать в группе, в которой настроены также сессии на ipv4-адресах, то сессия на ipv6 поднимется, но роутеры маршрутами обмениваться не будут.

*Сессия на ipv4 адресах, передающая ipv6 префиксы. ipv6 адреса на интерфейсах ipv4-compatible, то есть вида
a-centauri-r5> show configuration interfaces ge-0/0/0.304
description --c32;
vlan-id 304;
family inet {
address 192.168.0.13/30;}
family inet6 {
'''address ::ffff:192.168.0.13/126;'''
- сессия строится на ipv4 адресах. в группе или на neighbor настроена передача family inet6 unicast.
a-centauri-r5> show configuration protocols bgp group c31-c32
type external;
family inet unicast
family inet6 unicast
export export-ipv6
peer-as 64514
neighbor 192.168.0.10
- глобально требуется также включить:
a-centauri-r5> show configuration system
allow-v4mapped-packets
*Для IPv6 eBGP в рамках VRF нужно указывать ''routing-instance <> routing-options router-id <>''. Иначе сессия не поднимется. Будет прилетать ошибка:
May 21 00:16:05.676938 BGP RECV version 4 as 54591 holdtime 90 id '''0.0.0.0''' parmlen 30
Либо использовать отдельные lo, который будет выступать в роли router-id для сессии.
*На link-local адресах

=Дополнительная информация=
*[[OSPF]]
*[[IS-IS]]
*[[L3VPN]]

OSPF

2021-07-15T18:42:41Z

Наталия Бобкова:

{{#description2:Основы OSPF. Типы пакетов. Установление соседства. Типы Area. Типы LSA. Таймеры. Типы роутеров. Метрики/SPF. OSPFv3. Realm. backbone. stub area. nssa area. totally stub area. Информация для подготовки к экзаменам Juniper.}}

{{#description2:Основы OSPF. Типы пакетов. Установление соседства. Типы Area. Типы LSA. Таймеры. Типы роутеров. Метрики/SPF. OSPFv3. Realm. backbone. stub area. nssa area. totally stub area. Информация для подготовки к экзаменам Juniper.}}

=Основы=
OSPF - link-state IGP протокол.

Hello пакеты для установления и поддержания соседства.

OSPF флудит LSA (IP 89 порт, '''224.0.0.5''' адрес) во все порты OSPF, кроме того, с которого прилетела LSA. С помощью LSA на каждом роутере строится топология сети и на основании этих данных затем производится рассчет кратчайшего пути.

На всех роутерах одной area поддерживается одинаковая копия LSDB.

'''Policy''' можно применять на '''export''' для summary-LSA 3 (вроде).
+ export Export policy

И только для external маршрутов на '''import'''. !!! При этом в ospf database они будут видны, но в sh route их не будет.
+ import Import policy (for external routes or setting priority)

Иерархичный дизайн сети достигается за счет использования area, которые соединяются посредством backbone area.

Dijkstra рассчитывается только в рамках одной area (на основании одной LSDB, которая едина в рамках одной area).

Summary metric для dest = сумме outgoing interface metrics.

На бродкаст сегменте выбирается DR (наиб приоритет, затем наиб router ID), который занимается флудом LSA внутри area. Для роутеров не в бродкастном сегменте, подключенных через Ethernet, включаем ''interface-type p2p'', чтобы на этом линке не проводились выборы DR и чтобы уменьшить время сходимости.

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

'''Database description (DD)''' - используется только во время установления соседства. Определяет кто отвечает за синхронизацию LSDB (выбирается роутер с бОльшим 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, либо если меняется информация о состоянии линка на локальном роутере. Передает одну или несколько LSA. Содержит: ospf header, numbers of advertisement, link-state avertisement.

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

=Установление соседства=
Соседи используют hello пакеты для установления и поддержания соседства.

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

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

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

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

*'''2-Way'''
В hello-packet в списке соседей появился RID роутера, получившего этот пакет.

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

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

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

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

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

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

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

=Таймеры=
*Hello interval - установление и поддержание соседства = 10sec для broadcast и p2p networks; 30 sec - для nonbroadcast multiple access (NBMA).
*Dead - интервал, в течение которого не приходит hello, чтобы считать соседа неоперабельным = 40 sec.
*LSA retransmission interval - когда роутер отправил LSA, он ждет 5 sec ответа от соседа, что LSA получен (LSA ACK). Если ACK не пришел - делается повторная передача LSA.
*Transit-delay - устанавливает время, необходимое для передачи link-state update на интерфейсе = 1sec. Менять дефолтное значение не советуется.
*LSA refresh - интервал обновления LSA = 50min. Если LSA не обновилась через 60min, то инфо о ней считается устаревшей и она пропадает из LSDB.
{{note|text=Когда делаешь ''clear ospf database purge'' как раз всем LSA устанавливается LSA refresh interval 60min (3600sec) и неактуальные сразу же сбрасываются.}}
Кстати, у по дефолту НЕ у Juniper LSA refresh interval = 30min.

=Роутеры=
*'''ABR (Area border router)''': OSPF роутер, имеющий линки в двух area - соединяет и распространите инфо из OSPF area в backbone.
*'''ASBR (AS boundary router)''': может находиться как внутри backbone или других area. Имеет подключения других external routing protocols и распространяет эту инфу по сети.
*'''Backbone''': хотя бы один линк внутри backbone area.
*'''Internal''': все линки внутри одной area, backbone - частный случай internal.

=Метрики/SPF=
outside the area (INTER-area routing)

*Внутренние маршруты area (intra-area) juniper preference = 10
*Внешние маршруты (inter-area) juniper external-preference = 150
{{note|text=Метрика будет сравниваться только у маршрутов одного типа. Поэтому не всегда можно гарантировать forwarding согласно метрики. Не забываем про тип маршрута!}}

external metrics - применяются к префиксам из других AS.
*TYPE 1 - учитывается external cost + cost в пути до граничного маршрутизатора.
*TYPE 2 - учитывается только external cost. Этот тип используется по дефолту.

TYPE1 приоритетнее TYPE2. Далее учитывается стоимость самой метрики - чем меньше, тем приоритетнее.

*reference-bandwidth - дефолтной расчет метрики из емкости интерфейса: cost = ref-bandwidth/bandwidth. По умолчанию ref-bandwidth = 100Mbit. Можно настроить свое значение, глобально для протокола.
set protocols ospf reference-bandwidth 10g

Если устанавливаем metric вручную на интерфейсе, то дефолтное поведение перебивается для данного интерфейса.

=Типы Area=
Ненулевые area могут иметь один и тот же номер area, но такой подход - не правильный. При этом разные area с одним area-id не будут никогда считать себя одним сегментом сети.

area-id не передаются в LSA.

Если разбирать самые стандартные area (не stub, nssа и прочее):
*area1 - area0 - area3 - ok. У всех area будет полная картина сети.
*area1 - area2 - area3 - ok, только area2 будет иметь маршруты всей сети, а area1 и area3 будут иметь только свои маршруты + маршруты area2.
*area1[1] - area0 - area1[2] - ok, НО конечно area1[1] будет видеть area1[2] как LSA3. Такой себе вариант.

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

Но если area не имеет прямого физического подключения к backbone area, то она может соединяться с ней через virtual-link.

==stub area==
Обменивается маршрутами по ospf с ABR (LSA 3), не содержит с себе external routes, не принимает от ABR external routes (не принимает LSA 4,5). Доступность внешних маршрутов достигается анонсированием 0/0 со стороны ABR в сторону stub-area. Через stub-area нельзя построить virtual-link и в ней не может размещаться ASBR. Если все же сконфигурировать ASBR внутри stub-area, то роутер разместит LSA 5 в своей локальной базе данных, но не будет пересылать ее другим роутерам даже внутри area.

Все роутеры stub area должны быть сконфигурированы, как stub.
[edit protocols ospf area 0.0.0.20]
+ stub

Чтобы появился 0/0, на ABR настраиваем:
[edit protocols ospf area 0.0.0.20 stub]
+ default-metric 10;

==stub with no summaries (totally stub)==
В неё не анонсируется вообще никаких LSA. В area не вставляются LSA 3, 4, 5. По area гуляют только LSA 1 и LSA 2 [no-summaries как раз намекает на отсутствие LSA3]. Доступность маршрутов из остальных area достигается тем же анонсированием 0/0 со стороны ABR в сторону totally stub-area. И ASBR не флудит external routes в такой area. Также virtual-link не поддерживается в такой area.

[edit protocols ospf area 0.0.0.20]
+ stub default-metric 10 no-summaries;

==not-so-stubby==
Обменивается OSPF-маршрутами с ABR (LSA3), может содержать external routes (ASBR) - НО! в этой area external = LSA7 (NSSA). Не принимает external routes от ABR. (не принимает LSA 4,5). Внешние ресурсы также через 0/0 на ABR.

Конфигурация nssa делается на каждом роутере внутри area.

[edit protocols ospf area 0.0.0.30]
+nssa

на ABR:
OSPF database, Area 0.0.0.30
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10.200.86.1 10.200.86.1 0x80000002 35 0x20 0xe809 48
Router 10.200.86.3 10.200.86.3 0x80000004 36 0x20 0xbdba 72
Router 10.200.86.9 10.200.86.9 0x80000004 42 0x20 0xabe2 48
Network 192.168.86.37 10.200.86.9 0x80000001 42 0x20 0xf1d7 32
Summary *10.100.86.8 10.200.86.1 0x80000001 129 0x20 0x67ad 28
...
Summary *192.168.86.48 10.200.86.1 0x80000001 129 0x20 0x3fb6 28
'''NSSA''' 172.16.0.0 10.200.86.9
'''NSSA''' 172.16.1.0 10.200.86.9 - '''пришло от ASBR (LSA7) внутри area'''
'''NSSA''' 172.16.2.0 10.200.86.9
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
'''Extern''' *172.16.0.0 10.200.86.1
'''Extern''' *172.16.1.0 10.200.86.1 - '''сгенерировал ABR (LSA7 -> LSA5) и послал в area0
'''Extern''' *172.16.2.0 10.200.86.1

Анонс 0/0 настраивается на ABR:
[edit protocols ospf area 0.0.0.30 nssa]
+ '''default-lsa default-metric 1''';
Смотрим, что прилетело от ABR в NSSA area:
OSPF database, Area 0.0.0.30
Type ID Adv Rtr Seq Age Opt Cksum Len
NSSA 0.0.0.0 10.200.86.1 0x80000001 50 0x20 0x8681 36

Если на ABR добавляем ''no-summaries'', то 0/0 прилетит как LSA3 (а не LSA7 (NSSA)):

OSPF database, Area 0.0.0.30
Type ID Adv Rtr Seq Age Opt Cksum Len
Summary 0.0.0.0 10.200.86.1 0x80000001 3 0x20 0xae65 28
'''NSSA''' 0.0.0.0 10.200.86.1 0x80000001 '''3600''' 0x20 0x8681 36

Чтобы при настроенном ''no-summaries'' 0/0 прилетал все же как LSA 7, то добавляем в конце '''type-7''':
OSPF database, Area 0.0.0.30
Type ID Adv Rtr Seq Age Opt Cksum Len
'''Summary''' 0.0.0.0 10.200.86.1 0x80000001 '''3600''' 0x20 0xae65 28
NSSA 0.0.0.0 10.200.86.1 0x80000001 5 0x20 0x8681 36

=Типы LSA=
Все типы имеют одинаковый '''заголовок''':
*LS age - sec - время, когда LSA была впервые создана
*Option - E-bit = External LSA, P bit = NSSA external LSA.
*LS type.
*Link-state ID - разные типы LSA используют поле по-разному.
*Advertising router - роутер, который сгенерировал LSA.
*LS sec number
*LS checksum
*Length

В выводе ''sh ospf database'' ID, отмеченный '''*''' - будет означать, что этот маршрут сгенерирован самим роутером.

*'''Type 1 LSA (Router)''' — Описывает стоимость (metric) и состояние интерфейсов. Не передаются между Area. LSA1 = area scope.

*'''Type 2 LSA (Network)''' — Отправляются DR. Описывает роутеры, подключенные в бродкаст сегменте + сам себя. Не передаются между area. В выводе ''sh ospf database'': ID = DR, attached router = роутеры в бродкаст сегменте.

*'''Type 3 LSA (Summary)''' — Отправляются ABR. Описывают сети, которые маршрутизатор получил из предыдущих типов LSA, и передает между Area. LSA будет флудиться каждому роутеру внутри area. ABR, получив LSA3 не перешлет ее другому ABR, а сгенерирует на основании полученной LSA3, LSA1, 2 новую LSA3, и уже ее передаст в соседние area. LSA3 = area scope.
{{note|text=Summary не означает агрегирование! ABR передает один в один LSA1 и LSA2 в другую area без какой-либо агрегации/суммаризации по дефолту.}}

*'''Type 4 LSA (ASBR Summary)''' — Генерируются ABR, LSA содержит описание самих ASBR роутеров. В выводе ''sh ospf database'': ID = ASBR router.

*'''Type 5 LSA (External)''' — Описывают сети, полученные из других протоколов маршрутизации ASBR-ами. Рассылаются ими же. В выводе ''sh ospf database'': ID + mask = external networks.

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

*'''Type 7 LSA (NSSA External)''' — Генерируются ASBR-ами в NSSA. Передаются только внутри NSSA. Но на выходе из зоны ABR-ами транслируются в LSA Type 5. В выводе ''sh ospf database'': ID + mask = external networks.

*'''Type 9 (Graceful restart)''' - поддерживает graceful restart.

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

'''LSA flooding scopes''': LSA 1, LSA 2 - исключительно внутри area. LSA 3 - суммирует LSA 1 + LSA2 и передает эту инфу в соседнюю area. LSA 5 (external) - передаются по всему OSPF домену. LSA 4 (about ASBR) - по всему OSPF домену. LSA 7 (external in nssa) - только внутри nssa area.

Время жизни каждой LSA - 3600 sec (1 h).

Junos не поддерживает: LSA6, LSA8, LSA11

Можно вручную ограничить кол-во LSA: полезно в тех случаях, когда CE <> PE строится на OSPF.
set protocols ospf database-protection maximum-lsa 1000

macduff> show ospf database
OSPF database, Area 0.0.0.20
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.200.86.2 10.200.86.2 0x80000007 277 0x22 0xcb07 72
Router 10.200.86.4 10.200.86.4 0x8000000a 106 0x22 0x7294 72
Router *10.200.86.8 10.200.86.8 0x8000000d 105 0x22 0x5fd2 72
Network *192.168.86.14 10.200.86.8 0x80000003 2402 0x22 0xc01d 32
Summary 10.200.86.1 10.200.86.2 0x80000002 1991 0x22 0xdc09 28
Summary 10.200.86.2 10.200.86.2 0x80000004 2134 0x22 0xc41f 28
Summary 10.200.86.3 10.200.86.2 0x80000002 1705 0x22 0xd210 28
Summary 10.200.86.5 10.200.86.2 0x80000004 1420 0x22 0xba24 28
Summary 10.200.86.6 10.200.86.2 0x80000004 1277 0x22 0xa638 28
Summary 10.200.86.7 10.200.86.2 0x80000004 1134 0x22 0xb02b 28
Summary 10.200.86.9 10.200.86.2 0x80000002 848 0x22 0xa03b 28
Summary 192.168.86.4 10.200.86.2 0x80000004 991 0x22 0xec5f 28
Summary 192.168.86.8 10.200.86.2 0x80000006 2357 0x22 0xc085 28
Summary 192.168.86.24 10.200.86.2 0x80000002 1848 0x22 0x2812 28
Summary 192.168.86.28 10.200.86.2 0x80000004 705 0x22 0x62d 28
Summary 192.168.86.36 10.200.86.2 0x80000002 1563 0x22 0xb973 28
Summary 192.168.86.44 10.200.86.2 0x80000004 563 0x22 0x51d3 28
Summary 192.168.86.48 10.200.86.2 0x80000004 134 0x22 0x29f7 28
ASBRSum 10.200.86.9 10.200.86.2 0x80000001 390 0x22 0x9447 28
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 172.16.0.0 10.200.86.9 0x80000001 393 0x22 0x487b 36
Extern 172.16.1.0 10.200.86.9 0x80000001 393 0x22 0x3d85 36
Extern 172.16.2.0 10.200.86.9 0x80000001 393 0x22 0x328f 36

=Типы интерфейсов=
*'''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

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

=Другие фичи=
*Аутентификация: простая (plain-text, simple), MD5, none. и еще IPSEC.
:*simple - только один ключ. По сути просто не дает левому роутеру подключиться к твоему ospf домену, из-за использованиях хоть такого метода защиты. Но ключ не шифруется. Так что только MD5, только безопасность!
:*md5 - можно использовать несколько ключей. Менять их по времени. Каждый md5 key - с уникальным id. По id определяется какой md5 key использовать.

*Суммирование маршрутов (area-range), прилетающих в update сообщениях в backbone от других area.
Если после сети добавить
:*'''restrict''' - сети не просуммируются, а перестанут передаваться в backbone. То есть будет не передан и summary route и все вложенные в него сети.
:*'''override-metric''' - можно перезаписать значение ospf-метрики или ее тип.
:*'''exact''' - проадвертайзит только если в таблице маршрутизация будет четко такой же префикс.

Настраивается только на ABR. Здесь из area 10 будет передаваться суммированный маршрут в backbone:
[edit protocols ospf area 0.0.0.10]
+ area-range 192.168.86.0/24 [restrict|override-metric| exact];

Сразу после применения видно, что маршруты, сгенерированные ABR, и отправленные в area0 - скоро отвалятся.
OSPF database, '''Area 0.0.0.0'''
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.200.86.1 10.200.86.1 0x80000027 490 0x22 0x82a8 72
Router 10.200.86.2 10.200.86.2 0x80000016 312 0x22 0x74d9 84
Router *10.200.86.6 10.200.86.6 0x80000019 2 0x22 0xbe08 72
Network *192.168.86.10 10.200.86.6 0x8000000a 596 0x22 0xa839 32
Summary *10.200.86.5 10.200.86.6 0x80000007 2170 0x22 0x9246 28
Summary *10.200.86.7 10.200.86.6 0x80000007 2034 0x22 0x884d 28
Summary 10.200.86.9 10.200.86.1 0x80000002 1185 0x22 0x9c41 28
Summary *192.168.86.0 10.200.86.6 0x80000001 2 0x22 0x1537 28
Summary '''*192.168.86.4''' 10.200.86.6 0x80000007 '''3600''' 0x22 0xc481 28
Summary 192.168.86.24 10.200.86.1 0x8000000f 385 0x22 0xa25 28
Summary '''*192.168.86.28''' 10.200.86.6 0x80000008 '''3600''' 0x22 0xdb50 28
Summary 192.168.86.36 10.200.86.1 0x80000002 1185 0x22 0xb579 28
{{note|text=!!!Такой метод будет работать только для '''summary LSA'''. Для суммирования external LSA можно сделать area 30 NSSA area и тогда area-range сработает (пример ниже), либо на роутере area3 создавать aggregate route и делать его export в protocols ospf.}}

*Суммирование маршрутов от NSSA (LSA 7): аналогично работает и добавление '''restrict''' и '''override-metric''' и '''exact''':
[edit protocols ospf area 0.0.0.10 nssa]
+ area-range 172.16.0.0/22;

До
OSPF database, Area 0.0.0.10
NSSA *0.0.0.0 10.200.86.1 0x80000003 112 0x20 0x67f 36
NSSA 172.16.0.0 10.200.86.9 0x80000002 2485 0x28 0x88ff 36
NSSA 172.16.1.0 10.200.86.9 0x80000002 1886 0x28 0x7d0a 36
NSSA 172.16.2.0 10.200.86.9 0x80000002 1287 0x28 0x7214 36
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *172.16.0.0 10.200.86.1 0x80000004 5 0x22 0x6d5d 36
Extern *172.16.1.0 10.200.86.1 0x80000003 3600 0x22 0x2274 36
Extern *172.16.2.0 10.200.86.1 0x80000003 3600 0x22 0x177e 36

После:
OSPF database, Area 0.0.0.10
NSSA *0.0.0.0 10.200.86.1 0x80000003 201 0x20 0x67f 36
NSSA 172.16.0.0 10.200.86.9 0x80000002 2574 0x28 0x88ff 36
NSSA 172.16.1.0 10.200.86.9 0x80000002 1975 0x28 0x7d0a 36
NSSA 172.16.2.0 10.200.86.9 0x80000002 1376 0x28 0x7214 36
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *172.16.0.0 10.200.86.1 0x80000004 94 0x22 0x6d5d 36

*По дефолту в nssa будут передаваться LSA3 (summary) маршруты. Если нужно, LSA3 заменить на LSA7, то настраиваем:
set protocols ospf area 4 nssa default-lsa type-7

*Можно ограничить кол-во перфиксов, экспортируемых в OSPF.
*GRES возможен.
*BFD (Bidirectional Forwarding Detection) можно использовать для сокращения времени обнаружения аварии между роутерами.
*Можно отложить процесс перерасчета SPF при изменении LSDB (дефолт - 200ms):
set protocols ospf spf-options delay ?
<delay> Time to wait before running an SPF (50..8000 milliseconds)
*Metric - определяем желаемый интерфейс для прохождения пакета. Меньшая метика - приоритетнее.
*Overload - выставляет метрики на интерфейсах = 65535. Если после перерасчета SPF для dest не нашлось обходных путей, роутер будет передавать транзитный трафик.
set protocols ospf overload
*Topologies - можно использовать разные топологии для ipv4 unicast и ipv6 multicast. Для мультикаста и для юникаста с помощью метрик по-разному направлять трафик.
set protocols ospf topology ipv4-multicast
set protocols ospf area 0.0.0.0 interface xe-0/0/1.2056 metric 40
set protocols ospf area 0.0.0.0 interface xe-0/0/1.2056 topology ipv4-multicast metric 500

*Traffic-engineering (MPLS):
По дефолту выключен. Включаем, чтобы LSP участвовали как линки при расчёте SPF. Также в LSA теперь будут заноситься параметры traffic-engineering'a:
set protocols ospf traffic-engineering

*Traceoptions - как и для всех протоколов можно включить для диагностики
set protocols ospf traceoptions file ospf-log
set protocols ospf traceoptions file size 10m
set protocols ospf traceoptions file files 10
set protocols ospf traceoptions flag state detail
set protocols ospf traceoptions flag error detail

*Virtual-link. Как уже описывалось ранее, каждая area должна быть соединена с backbone area. Если у роутера нет физического линка до backbone, то делаем соединение через virtual-link.

В настройках всего 2 параметра: - ''transit-area'', ''neighbor-id''.

[[Файл:Ospf-virtual-link.png|600px]]

R8: set protocols ospf area 0 virtual-link transit-area 1 neighbor-id 172.30.5.7

virtual-link в SPF считается за обычный линк. Дополнительной стоимости не добавляет.

При этом, если у нас есть подобное включение: R1 (area 5) <> R2 (area 6) <> R3 (area 7). То area 5 и area 7 не будут видеть префиксы друг друга (будут видеть только area 6). А area 6 будет получать префиксы всех area.

То есть любая другая '''area не 0''' будет принимать LSDB от других area, но не передавать другим area. В отличие от Backbone. Backbone работает как RR :) А остальные как IBGP соседи. :)

=OSPFv3=
OSPF3 router-id, area-id, LSA link-state ID - взяты из OSPFv2, то есть имеют тот же формат: IPV4 = 32bit.

ROUTER ID = 172.30.5.4

AREA ID = 0.0.0.1

link state ID = 0.0.0.0, 0.0.0.1, 0.0.0.2, ...

По принципу работы не отличается от OSPFv2, но все же есть некоторый отличия:
*В OSPF3 все информаци о соседях представлена в виде router-ID (lo0.0 inet address).
*OSPF работает по линкам, а не по сетям.
*OSPF3 LSA1, LSA2 не передают никакой информации о сетях (prefix).
*Включены 2 новых типа LSA: ''link-LSA'' и ''intra-area-prefix-LSA''. Стандартные LSA 3, 4 превратились в inter-area-prefix-LSA и inter-area-router-LSA.
*OSPF3 использует link-local address для обмена сообщениями между соседями (за исключением virtual-link).
*Для аутентификации используется IPv6 authentification header.

'''Intra-area-prefix-LSA''': передает internal prefix, требуется, т.к. LSA 1, 2 передают только инфо о топологии.

'''Link-LSA''': передает link-local address и сети, прикрепленные к этому link.

==Config==
[edit]
routing-options {
router-id 10.200.86.1;}
[edit protocols]
ospf3 {
area 0.0.0.0 {
interface ge-0/0/0.80 {
interface lo0.0 {
passive; }
area 0.0.0.30 {
interface ge-0/0/0.110 }}

show ospf3 interface
show ospf3 neighbor
show ospf3 database
show route protocol ospf3
==Realm==
По дефолту OSPFv3 передает инфо только о IPv6 unicast маршрутах. Чтобы OSPFv3 мог передавать и другие family, в том числе и IPv4 unicast, IPv4 multicast, IPv6 multicast, включаем '''realm''':
set protocols ospf3 area 0.0.0.0 interface fe-0/1/0.0 - IPv6
set protocols ospf3 realm ipv4-unicast area 0.0.0.0 interface fe-0/1/0.0 - IPv4
set interfaces fe-0/1/0 unit 0 family inet6

=Дополнительная информация=
*[[IS-IS]]
*[[BGP]]
*[[L3VPN]]

IPv6 в мультикасте

2021-07-15T18:41:02Z

Наталия Бобкова:

{{#description2: Основы PIM IPv6. Формат. Адресация. Протокол MLD. PIM ASM IPv6. PIM SSM IPv6. Информация для подготовки к экзаменам Juniper Networks.}}

=Основы=
Используется также как и в IPv4:
*RPF check
*PIM-DM, PIM-SM для ASM
*SSM

Используется по-другому, в отличие от IPv4:
*IGMP -> MLD
*IPv6 include scoping
*не поддерживается MSDP: протокол посчитали не масштабируемым. Взамен него можно использовать внедрение инфо об RP в каждый адрес источника. Такой метод позволит работать междоменному ASM.

==Формат==

128 бит:

0-7 = 1111111 - начало, определяющее, что это мультикаст адрес.

8-11: флаги 0RPT: 0 = rezerved, R = встроенный адрес RP, P = unicast-prefix-based multicast address, T: 0 = permanent, 1 = non-permanent.

12-15: scop (ограничение): 1 = interface-local, 2 = link-local, 4 = admin-local, 5 = site-local, 8 = organization-local, E = global

16-128: группа.

==Адресация==
- все узлы: = 224.0.0.1
:*FF01:0:0:0:0:0:0:1 (interface-local)
:*FF02:0:0:0:0:0:0:1 (link-local)

-все роутеры: = 224.0.0.2
:*FF01:0:0:0:0:0:0:2 (interface-local)
:*FF02:0:0:0:0:0:0:2 (link-local)
:*FF05:0:0:0:0:0:0:2 (site-local)

-Ethernet адреса:
:*33:33 + последние 32 бита IPv6 мультикаст адреса.

=MLD=
MLD - sub-protocol of ICMPv6. Сообщения MLD передаются внутри ICMPv6, next-header значение = 58.

Source-addr = link-local IPv6.

TTL = 1 и включает IPv6 router alert header.

MLDv1 = IGMPv2
MLDv2 = IGMPv3

Типы сообщений:

- Query: general, multicast address-specific, multicast address and source-specific query (MLDv2).

- Multicast listener report.

- Multicast listener done (MLDv1) = leave message.

=ASM=
Может использовать как PIM-DM, так и PIM-SM.

В PIM-SM:

- RP discovery:
:*Static-RP
:*BSR
:*Auto-RP - не работает.

- RP redundancy:
:*Anycast-RP with PIM-Anycast
:*Anycast-RP with MSDP - не работает

- Interdomain multicast:
:*Embedded RP (внедренная RP)
:*MSDP - не работает.

'''Embedded RP'''
Идея: позволить всем роутерам использовать 1 RP, чтобы изучить источники для групп. The domain ownin the multicast address вкладывает инфо об RP в IPv6 адрес группы.

в полях IPv6:
*флаги: если R = 1, значит используется embedded RP. При этом P=T=1.
*RIID: RP interface ID.

=SSM=
- Interdomain multicast:
:*MSDP не используем
:*Embedded RP используем

- Требуется MLDv2 include option - также как и в IGMPv3 позволяет формировать получатели запрос на "канал", а не просто на группу.

- Блок адресов: FF3x::/96, x = scoping value.

=Дополнительная информация=
*[[Глава 2. Multicast, IGMP]]
*[[Глава 3. Routing protocols (DVMRP, PIM-DM, PIM-SM)]]
*[[MSDP | Глава 4. MSDP]]

Политики в мультикасте

2021-07-15T18:40:30Z

Наталия Бобкова:

{{#description2:IGMP join фильтрация. Политики на PIM соседство. Фильтрация PIM join. Фильтрация PIM register. Фильтрация BSR. Фильтрация MSDP SA сообщений. Фильтрация мультикаст трафика. Информация для подготовки к экзаменам Juniper Networks}}

Используя policy, можно
*более эффективно использовать полосу
*исключить различные проблемы в сети (не большое кол-во state в сети (S,G)), благодаря указанию конкретных групп, конкретных источников;
*можно предотвратить DoS атак.

=IGMP join=
*можно указать через policy группу (route-filter) и источник (source-address) на которые нельзя подписываться.
set policy-options policy-statement block-igmp term 1 from route-filter 235.4.5.6/32 exact
set policy-options policy-statement block-igmp term 1 from source-address 10.66.66.2 exact
set policy-options policy-statement block-igmp term 1 then reject
set protocols igmp interface ge-0/0/0.0 group-policy block-igmp

*можно ограничить кол-во подписок на интерфейсе.
set protocols igmp interface ge-0/0/0.0 group-limit 100

*каждый join считается как отдельная подписка: (*,g), (s,g) - 2 разных подписки
*каждый join на разные источники для одной и той же группы - 2 разные подписки: (s1,g), (s2,g).
*если закоммитить число групп, которое по факту меньше числа уже изученных групп, то все записи сотрутся и хостам придется переподписаться.

=Policy for PIM-SM=
==Соседство==
Фильтруем нежелательных соседей.
set policy-options policy-statement no-macduff term 1 from route-filter 192.168.86.14/32 exact
set policy-options policy-statement no-macduff term 1 then reject
set protocols pim interface ge-0/0/0.70 neighbor-policy no-macduff

show pim statistics | find "Hello drop"
Hello dropped on neighbor policy 4

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

Для указания соседей в policy лучше использовать /32 - linknet адрес, '''не lo''', потому что пакеты идут hop by hop, используя только p2p адреса.

==Join/prune==
===Фильтруем вх/исх сообщения===
Есть несколько параметров по которым можно отстроить policy: ''neighbor, interface, route-filter, source-address-filter''.
*''neighbor'': прописываем физический интерфейсный адрес, т.к. join передается от хопа к хопу.
*''interface'': вх логический интерфейс.
*''route-filter'': multicast group
*''source-address-filter'': source address (если исползуем ASM, то адрес RP).

Пример для фильтрации входящих join:
set protocols pim import no-join
set policy-options policy-statement no-join term 1 from route-filter 235.4.5.6/32 exact
set policy-options policy-statement no-join term 1 from source-address-filter 10.66.66.2/32 exact
set policy-options policy-statement no-join term 1 then reject

Для исходящих join/prune все тоже самое, только
set protocols pim export ...

Диагностика:
> show pim statistics | match "Rx Join/Prunes filtered"
Rx Joins/Prunes filtered 12

===Join suppression===
Есть отдельная функция, которая позволяет блокировать отправляемые Join сообщения в сторону upstream роутера, если он видит в сети join от других роутеров к той же сети (т.к. join отправляются на общий адрес 224.0.0.13, то все роутеры в широковещательном сегменте видят сообщения).

*''reset-tracking-bit'' - активирует подавление PIM join сообщений на каждом PIM интерфейсе роутера. При этом в пакете сбрасывается значение tracking-bit (1->0).

Когда получено несколько одинаковых PIM join на роутер, то активируется некий произвольный временной интервал (66-84 мс), и роутер не передает PIM join в сторону upstream.
*''override-interval'' - max время задержки отправки join при обнаружении такого же join.
*''propagation-delay'' - время, которое upstream роутер, получив prune, ждет join от downstream роутеров.

set protocols pim reset-tracking-bit
set protocols pim propagation-delay 100
set protocols pim override-interval 3500

==Register==
Работает только для ASM, т.к. в SSM получатели уже знают информацию об источниках.

Можно настроить register filter в двух вариантах:
#Если на RP - то фильтр на вход
#Если на DR - то фильтр на выход

Пример для source RP:
set protocols pim rp '''rp'''-register-policy
set protocols pim rp ''no-register''
set policy-options policy-statement ''no-register'' term 1 from route-filter 235.4.5.6/32 exact
set policy-options policy-statement ''no-register'' term 1 from source-address-filter 10.66.66.2/32 exact
set policy-options policy-statement ''no-register'' term 1 then reject

Пример для source DR аналогичен по конфигурации, только
set protocols pim rp '''dr'''-register-policy ''no-register''

В результате такой фильтрации source DR не будет слать к RP трафик от источника 10.66.66.2 с группой 235.4.5.6. Поэтому при использовании ASM получатели не смогут получать трафик от этого источника, а при использовании SSM получатели его все-равно получат.

Для диагностики:
show pim statistics | match "Rx register msgs filtering drop"
Rx Register msgs filtering drop 3

=BSR messages=
Обычно используется, чтобы BSR из разных доменов не распространяли информацию о своих RP.

set policy-options policy-statement block-bsr-import term 1 from interface ge-0/0/0.0
set policy-options policy-statement block-bsr-import term 1 then reject
set policy-options policy-statement block-bsr-export term 1 from interface ge-0/0/0.0
set policy-options policy-statement block-bsr-export term 1 then reject
set protocols pim rp bootstrap-import block-bsr-import
set protocols pim rp bootstrap-export block-bsr-export

show pim statistics interface ge-0/0/0.0 | match "V2 Bootstrap"

Еще один метод не распространять информацию об RP в другой домен - настроить PIMv1 на интерфейсе (т.к. BSR работает только с v2).

=MSDP SA messages=

*SA import
Для policy используются следующие критерии: neighbor, interface, route-filter (группа), source-address-filter (источник).

При применении policy проходят только явно разрешенные SA сообщения, для этого обязательно включить accept-all.
set policy-option policy-statement block-SA-imort term 1 from neighbor 192.168.1.2
set policy-option policy-statement block-SA-imort term 1 from interface ge-0/0/0.0
set policy-option policy-statement block-SA-imort term 1 from route-filter 224.7.7.7/32 exact
set policy-option policy-statement block-SA-imort term 1 from source-address-filter 10.0.107.2/32 exact
set policy-option policy-statement block-SA-imort term 1 then reject

set protocols msdp group AS65009 peer 192.168.1.2 import block-SA-import

show msdp source-active detail | mat Filtered
*SA export
Все тоже самое как и для import, только:
set protocols msdp group AS65009 peer 192.168.1.2 export block-SA-export

*SA limit
- Дефолтное ограничение - 25000. Можно ставить 1-1млн.

- Лимит можно ставить глобально, на группу, на пира. Применятся ВСЕ, а не более специфичные.

- Лимит можно ставить и для конкретной группы источников. При этом для пира стоит общее ограничение и для конкретной группы - применятся оба ограничения.

set protocols msdp active-source-limit maximum 10000 threshold 8000
set protocols msdp group AS65009 peer 192.168.100.10 source 10.1.0.0/16 active-source-limit 500
set protocols msdp group AS65009 peer 192.168.100.10 active-source-limit 10000 threshold 8000

=Multicast traffic=
Описано в RFC 2365, называется Administrative scoping (административные ограничения).

В основном используется для непрохождения трафика между доменам. Админу нужно задать огрничение для домена - с помощью пограничных интерфейсов.

В Junos 2 метода:
*Named scoping
Каждая группа должна быть именована. Один интерфейс может принадлежать нескольким группам.
set routing-options multicast scope auto-rp-deiscovery prefix 224.0.1.40/32
set routing-options multicast scope auto-rp-deiscovery interface ge-0/0/0.0
set routing-options multicast scope scoped-range prefix 239.0.0.0/8
set routing-options multicast scope scoped-range interface ge-0/0/0.0
show multicast scope

В примере показано как контролировать auto-RP трафик между доменами, чтобы не использовать RP другого домена.

*Scope policies
Более гибкий подход. Используя разные термы можно делать выборку по разным интерфейсам, тогда как в named-scope это займет кучу конфига.

Named scope и scoping policy - взаимоисключающие. При этом в named группа - 239.192/16 автоматически добавляется на интерфейсе, а при использовании scoping policy - автоматически не добавляется, нужно писать ручками.

set policy-option policy-stetment mcast-scope term 1 from interface ge-0/0/0.0
set policy-option policy-stetment mcast-scope term 1 from route-filter 239.0.0.0/8 orlonger
set policy-option policy-stetment mcast-scope term 1 from route-filter 224.0.1.40/32 exact
set policy-option policy-stetment mcast-scope term 1 from route-filter 224.0.1.39/32 exact
set policy-option policy-stetment mcast-scope term 1 then reject
set routing-options multicast scope-policy mcast-scope

Известные административные ограничения:
*site-local: 239.255/16
*organization-local: 239.192/14 - private use in network.
*unassigned: 239/10, 239.64/10, 239.128/10
*link-local: 224/24

=Дополнительная информация=
*[[Глава 2. Multicast, IGMP]]
*[[Глава 3. Routing protocols (DVMRP, PIM-DM, PIM-SM)]]
*[[MSDP | Глава 4. MSDP]]
*[[Глава 5. PIM-SSM]]

Глава 5. PIM-SSM

2021-07-15T18:39:29Z

Наталия Бобкова:

{{#description2:PIM ASM. Как работает PIM SSM. Адресное пространство PIM SSM. Использование IGMPv3 и SSM. PIM-SM + SSM. Конфигурация PIM SSM. Траблшутинг. Информация для подготовки к экзаменам Juniper Networks}}

==ASM==

*Нахождение источника - задача сети.
:*PIM-DM: флуд от источника всем получателям. Из-за этого хранится много (S,G) => проблемы с масштабируемостью.
:*PIM-SM: регистрация источника на RP. Более сложный механизм.
:*Междоменный мультикаст: MSDP.

*Поддерживает несколько типов приложений:
:*One-to-many
:*Many-to-many

*Распределение адресного пространства - адреса групп должны быть уникальными в глобальной сети.
:* Выделены блоки SDP/SAP, GLOP, Admin scoped.

==SSM==

*Нахождение источника - задача приложения у получателя.
:*Получатель уже знает о необходимом источнике.
:*Получатель подписывает на определенный канал - (S,G).
:*Приложение должно поддерживать IGMPv3.
*Для междоменного мультикаста больше не нужно использование MSDP и RP.
*Использует часть PIM-SM функционала:
:*Всегда используется (S,G) source-based tree.
*В основном использует 1 тип приложений: One-to-many
*Распределние адресного пространства:
:*Выделен блок: 232/8.
:*Один и тот же адрес группы может использоваться разными источниками на просторах всего интернета. Из-за этого усложнены DoS атаки.

==Как работает==
*Получатель знает все источники и группы, к которым он может подписаться (может быть заранее полученный список каналов на приставке).
*От получателя subscribe (S,G), используя IGMPv3 (include mode).
*DR на сегменте получателя шлет join (S,G) в сторону источника и начинает строить source-based tree.
*DR на сегменте источника как только получил join (S,G) - начинает слать трафик по shortest path tree (spt) к получателю.

==Разница в терминологии==

*'''Address identifier:''' (G) vs (S,G)
*'''Address destination:''' group vs channel
*'''Receiver protocol:''' IGMPv1,2,3 vs IGMPv3
*'''Receiver Operations:''' Join,Leave vs Subscribe/Unsubscribe
*'''Address range:''' 224/4, exclude 232/8 vs 232/8

==Адресное пространство==
SSM не работает с shared-tree. SSM не обрабатывает сообщения вида: (*,G).

Junos позволяет определить другое поведение для адресных блоков:
*Добавлять адресное пространство для использования только SSM.
set routing-options multicast ssm-groups 227.0.0.0/24
*Позволяет ASM использовать SSM блок.
set routing-options multicast asm-override-ssm

==IGMPv3 + SSM==

ASM использует 1,2,3 версии протокола. Group joins не определяют конкретный источник. 3 версия предусматривает работу именно с (S,G), что не очень то подходит по ASM, поэтому для ASM IGMPv3 работает только в режиме exclude.

SSM использует только 3 версию. При подписке должны быть определены источник и группа. Этот функционал может обеспечить IGMPv3 include mode.

В IGMPv3 включены 2 новых опции:
*include (этот режим обеспечивает определение источника для группы => используется только SSM)
*exclude (этот режим позволяет исключать определенный источник из join сообщения => поддерживается ASM)

'''IGMPv3 работа получателя'''
*получатель отправляет membership report на DA = 224.0.0.22

membership report включает в себя 3 основных типа:
*current-state record: MODE_IS_INCLUDE, MODE_IS_EXCLUDE;
*filter-mode-change (когда происходит смена режима): CHANGE_TO_INCLUDE_MODE, CHANGE_TO_EXCLUDE_MODE;
*source-list-change (когда происходит подписка/отписка): ALLOW_NEW_SOURCES, BLOCK_OLD_SOURCES;

Для SSM модели используется только 3 операции:
*подписка: ALLOW_NEW_SOURCES
*поддержание подписки: MODE_IS_INCLUDE
*отписка: BLOCK_OLD_SOURCES

'''Типы Query'''
*general query ->224.0.0.1
*group-specific query
*group-source-specific-query (include source address).

==PIM-SM + SSM==

SSM это упрощенная форма PIM-SM. Используется только часть функционала от PIM-SM.

Блок 232/8 работает только с обменом сообщений для source-based tree. Никаких сообщений для shared-tree.

*Сегмент получателя (receiver DR):
:*игнорируются любый (*,G) сообщения
:*не должен отправлять (*,G) upstream роутерам

*Сегмент источника (source DR):
:*не должен отправлять register сообщения к RP, когда получен трафик от источника.

*RP роутер:
:*игнорирует register сообщения от source DR.
:*игнорирует SA сообщения от MSDP пиров.

*Другие роутеры:
:*игнорируют все (*,G) сообщения от downstream роутеров.

Вообще, PIM-SM позволяет использовать как ASM, так и SSM. В зависимости от получаемых сообщений и сконфигурированных SSM блоков, DR роутер устанавливает либо shared tree к RP, либо source-based tree к источнику.

==Config==

На интерфейсах к сторону получателей - IGMPv3. При этом на такие интерфейсы буду приходить и запросы от IGMPv1, v2, которые будет использовать для своей работы ASM.
*На сети нужен ASM + SSM: в этом случае конфиг должен быть как для стандартной PIM-SM модели с определенным RP discovery механизмом.
*На сети нужен только SSM: в этом случае нужно просто сконфигурировать все интерфейсы в sparse mode.

Для использования адресного пространства совместно:
set routing-options multicast ssm-groups 227.0.0.0/24
set routing-options multicast asm-override-ssm

===SSM-mapping===
Если получатели не поддерживают IGMPv3, SSM maps могут переделать join из (*,G) в (S,G):

1.
set policy-options policy-statement ''ssm-mapping-policy'' term 1 from route-filter 232.7.7.7/32 exact
set policy-options policy-statement ''ssm-mapping-policy'' term 1 then accept
2.
set routing-options multicast ssm-map ''ssm-mapping-example'' policy ''ssm-mapping-policy''
set routing-options multicast ssm-map ''ssm-mapping-example'' source 192.168.100.10
3.
set protocols igmp interface ge-0/0/0.0 ssm-map ''ssm-mapping-example''

result: (*, 232.7.7.7) -> (192.168.100.10, 232.7.7.7)

Для IPv6 делается все точно по такому же алгоритму, только в конце ssm-map применяется в рамках протокола mld.

Для troubleshoting используются все те же команды.

==Troubleshooting==
show pim interfaces
show pim neighbors extensive || можно посмотреть RX Join groups!!
show pim statictics
show pim join extensive || помимо прочего, полезно: "Upstream state: Join to Source, Prune to RP"
show pim source detail
show pim rps || какие rp известны, через какой механизм, какой набор групп приходит
show pim rps extensive || помимо того, что выше - видны конкретные группы, статус, time active и много всяких подробностей
show pim bootsrap || активный BSR роутер
show multicast rpf x.x.x.x
show multicast next-hops
show multicast usage
show multicast route extensive || можно посмотреть и трафик, относящийся к группе
show route table inet.1 || таблица форвардинга - показана пара G+S
show route table inet.0 | net.2 || проверяем, что source-address есть в этой таблице и доступен
traceoptions || для диагностики не забываем включать

До того, как проверять PIM, проверяем unicast связность от роутера до источника мультикаста (по таблицам маршрутизации)
show pim neighbors
Instance: PIM.master
Interface IP V Mode Option Uptime Neighbor addr
xe-1/1/0.910 4 2 HPLGT 13w2d5h 212.1.253.189
xe-1/2/0.822 4 2 HPLG 03:08:00 192.168.152.49

B = Bidirectional Capable = bidirectional mode supported
G = Generation Identifier = gracefull restart turned on for pim
H = Hello Option Holdtime,
L = Hello Option LAN Prune Delay,
P = Hello Option DR Priority,
T = Tracking Bit = Join Suppression supported, если нет T - то у соседа настроен: ''reset-tracking-bit''

show pim neighbors detail
Interface: xe-1/2/0.822
Address: 192.168.152.49, IPv4, PIM v2, ''sg Join Count: 2'', tsg Join Count: 0
BFD: Disabled
Hello Option Holdtime: 105 seconds 102 remaining
Hello Option DR Priority: 1
Hello Option Generation ID: 1593016797
Hello Option LAN Prune Delay: delay 1000 ms override 3000 ms
Address: 192.168.152.50, IPv4, PIM v2, Mode: Sparse, sg Join Count: 0, tsg Join Count: 0
Hello Option Holdtime: 65535 seconds
Hello Option DR Priority: 1
Hello Option Generation ID: 1898464853
Hello Option LAN Prune Delay: delay 500 ms override 2000 ms
Join Suppression supported
PIM Join и PIM Prune можно посмотреть в '''pim statistics''' (как принятые так и отправленные).

> show multicast route group 235.69.101.1 extensive
Instance: master Family: INET
Group: 235.69.101.1
Source: 192.168.151.11/32
Upstream interface: xe-1/2/0.822
Downstream interface list:
xe-1/2/0.900
Number of outgoing interfaces: 1
Session description: Unknown
'''Statistics: 447 kBps, 332 pps, 7110535 packets'''
Next-hop ID: 1048579
Upstream protocol: PIM
Route state: Active
'''Forwarding state: Forwarding'''
Cache lifetime/timeout: 360 seconds
Wrong incoming interface notifications: 28
Uptime: 06:01:21

> show pim statistics interface xe-1/2/0.822
Instance: PIM.master Family: INET
PIM Interface statistics for xe-1/2/0.822
PIM Message type Received Sent Rx errors
'''V2 Hello 389 413 0'''
V2 Register 0 0 0
V2 Register Stop 0 0 0
'''V2 Join Prune 0 195 0'''

В monitor traffic interface не будут отображаться PIM Join, PIM Prune. Если требуется помониторить входящие и исходящие пакеты, то можно только замиррорить трафик.
> show route table inet.1
235.69.101.1,192.168.151.11/32*[PIM/105] 05:57:24
Multicast (IPv4) Composite
235.69.101.20,192.168.151.12/32*[PIM/105] 05:57:24
Multicast (IPv4) Composite

==Дополнительная информация==
*[[Глава 3. Routing protocols (DVMRP, PIM-DM, PIM-SM)]]
*[[Глава 2. Multicast, IGMP]]
*[[Политики в мультикасте | Глава 6. Политики в мультикасте]]

MSDP

2021-07-15T18:38:54Z

Наталия Бобкова:

{{#description2:Описание и работа протокола MSDP. Процесс установления сессии. Флудинг SA-сообщений (source-active). FPR-check для SA сообщений (Peer RPF-check). Mesh groups. Настройка. Траблшутинг. Anycast RP. Материалы для подготовки к экзаменам Juniper Networks}}
==Описание и работа протокола MSDP==
Используется только для IPv4.

Междоменный обмен мультикастом, использующий PIM-SM.

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

+: Каждый ISP сам решает где расположить RP.

+: Между доменами в качестве маршрутизации используется BGP (делаем RPF check). Если топологии unicast и multicast одинаковые - BGP в inet.0. Если разные - MP-BGP в inet.2.

MSDP распространяет информацию от RP об источниках из других доменов (т.к. их меньше в сети, чем получателей), используя Source-active message (SA).

Как это происходит:
*RP (AS1) знает об источнике
*RP (AS1) шлет инфу об источнике к RP (AS2), используя SA message.
*RP (AS2) получает (S,G) и т.о. все получатели смогут соединиться с этим новым источником из другой AS.

Обычно запускается на PIM-SM RP, но можно использовать и на non-RP роутерах.

При сконфигурированном MSDP также строятся shared tree (от RP к получателю), source tree (от RP к источнику). И также как и в PIM-SM при получении первого мультикаст пакета DR роутером, он пытается построить shortest-path tree.

MSPD устанавливает соседство, используя TCP (639 порт). Как только установилось соседство между MSDP peers => возможен обмен SA message.

В SA-message содержится: originating RP, source, group.

Когда у RP в одной AS появляется получатель и нужная группа находится в другой AS, RP как и в PIM-SM начинает слать PIM-join к источнику (в другую AS).

===Процесс установления сессии===
*Роутер с наибольшим ip становится пассивным и слушает TCP 639 от активных роутеров.

Состояния:
*'''Disable''': MSDP peer не сконфигурирован.
*'''Inactive''': MSDP peer сконфигурирован, но не слушает или не подключен.
*'''Connect''': active MSDP peer пытается установить TCP сессию.
*'''Listen''': passive MSDP peer сконфигурирован и слушает 639 порт.
*'''Established''': TCP сессия установлена.

===Флудинг SA-сообщений (source-active):===
*Исходное SA сообщение отправляется, когда источник в первый раз зарегистрировался на RP.
*Если источник все еще активен, RP будет отправлять SA сообщения каждые 60 секунд.
*SA сообщения проходят RPF-check, когда прилетают к MSDP peer.
*Если сообщение прошло RPF-check, MSDP peer хранит его в своем кэше (inet.4). Также сообщения пересылаются всем MSDP пирам, за исключением пира, от которого пришло SA.
clear msdp cache

===FPR-check для SA сообщений (Peer RPF-check)===
SA сообщения флудятся всем пирам, исключая тот, от которого пришло сообщение. SA сообщения обязательно должны пройти RPF check.

Проверяется то, чтобы originated RP и MSDP peer сидят за одним интерфейсом, и трафик передается только в сторону от originated RP.
{{note|text=Не используется для предоствращения петель! Но за счет того, что некоторые SA отвалятся - уменьшает их количество в сети.}}

''RPF check проходит, если:''

*Originating RP = MSDP peer данного маршрутизатора.
*SA сообщения получены от non-originating RP:
:* сообщение получено от MSDP peer, который является BGP next-hop для originating RP.
:* IGP next-hop MSDP peer = next-hop to originating RP.
:* MSDP peer находится в последней AS, в AS-path к originating RP.

''RPF-check не делается, если:''

* SA сообщение от MSDP peer из mesh группы.
* SA сообщение от default MSDP peer. (случай с stub доменом, где используется всего один единственный MSDP peer).

===Mesh groups===
Используют для уменьшения флуда SA сообщений => между MSDP peers внутри mesh group не распространяются SA-message, т.к. смысла в них нет. Все члены Mesh-group получат SA от originating members.

Обычно используют для intra-domain, потому что SA не проходят RPF-check, а автоматически становятся accept.

Флуд в mesh-groups:
*SA, полученные от соседей по mesh группы не передаются другим членам. Сообщения принимаются и флудятся другим MSDP peers (не из этой же mesh-group).
*SA, полученные от пиров, не состоящих в группах - подвергаются обычному RPF-check. Если проверка прошла успешно - SA флудятся всем остальным пирам (в других AS и в mesh-group).

===Конфигурация===
set protocols msdp local-address 10.200.86.2
set protocols msdp group anycast-rp mode mesh-group
set protocols msdp group anycast-rp peer 10.200.86.9
set protocols msdp group anycast-rp peer 10.200.86.3
set protocols msdp group customers mode mesh-group
set protocols msdp group customers export export-msdp-groups
set protocols msdp group customers export export-msdp-sources
set protocols msdp group customers peer 192.168.86.13 local-address 192.168.86.14
set protocols msdp group customers peer 192.168.86.37 local-address 192.168.86.38

set protocols msdp peer 192.168.2.1 default-peer || используем, чтобы убедиться, что все SA принимаются от этого пира (диагностика)

===Troubleshoting===

show msdp
show mspd peer 212.1.254.14 detail
show msdp source-active
show route table inet.4 || SA cache
show msdp statisctics

''Traceoptions''
set protocols msdp traceoptions file msdp-debug
set protocols msdp traceoptions file size 10m
set protocols msdp traceoptions file files 30
set protocols msdp traceoptions file world-readable
set protocols msdp traceoptions flag state
set protocols msdp traceoptions flag general detail
set protocols msdp traceoptions flag source-active detail

==Anycast RP==

Обеспечивает работу нескольких RP для группы, что хорошо в плане отказоустойчивости.

''Принцип:''
Несколько RP используют один общий ip (anycast). Эффект достигается засчет введения нескольких RP, использующих одинаковый IP. Источники и получатели при этом используют ближайшую по unicast RP.

Может возникнуть проблема, что получатель и источник сойдутся на разных RP. Для решения этой проблемы используем MSDP.

При этом надежность становится значительно лучше:
*failover timeout зависит только от сходимости IGP.
*распределение нагрузки на RP для группы - становится возможным.

MSDP работает только с IPv4.
Anycast-PIM поддерживает IPv4, IPv6.

===Настройка===

*Создаем уникальный ip на loopback (основной для протоколов маршрутизации) - помечаем его как primary. Также для надежности лучше его прописать как router-id.
*Создаем неуникальный ip на loopback (для anyacst-RP) - назначаем его как local RP.
*Non-RP роутеры должны "изучить" anycast-RP, используя любой discovery механизм (обычно все-таки это static RP, так как он самый простой).
*Включаем MSDP mesh peering с другими anycast-RP роутерами.
'''RP:'''
tormore# top show | compare
[edit interfaces lo0 unit 0 family inet address 10.200.86.9/32]
+ primary;
[edit interfaces lo0 unit 0 family inet]
address 10.200.86.9/32 { ... }
+ address 10.200.86.100/32;
[edit]
+ routing-options {
+ router-id 10.200.86.9;
+ }
[edit protocols pim]
+ rp {
+ local {
+ family inet {
+ address 10.200.86.100;
+ anycast-pim {
+ rp-set {
+ address 10.200.86.3;
+ local-address 172.30.5.9;
tormore# top show | compare
[edit protocols]
+ msdp {
+ group rp {
+ mode mesh-group;
+ local-address 10.200.86.9;
+ peer 10.200.86.2;

tormore> show msdp
Peer address Local address State Last up/down Peer-Group SA Count
10.200.86.2 10.200.86.9 Established 00:04:34 rp 1/1

tormore> show route receive-protocol msdp 10.200.86.2
inet.4: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
235.4.5.6,10.66.66.2/32*[MSDP/175/1] 00:00:53, from 10.200.86.2
> to 10.200.86.100 via ge-0/0/0.120
==Дополнительная информация==
*[[Глава 2. Multicast, IGMP]]
*[[Глава 3. Routing protocols (DVMRP, PIM-DM, PIM-SM)]]
*[[Политики в мультикасте | Глава 6. Политики в мультикасте]]

Глава 3. Routing protocols (DVMRP, PIM-DM, PIM-SM)

2021-07-15T18:38:08Z

Наталия Бобкова:

{{#description2: PIM Dense mode. PIM Sparse mode. SPT switchover. Static RP. Auto-RP. Bootstrap. Anycast RP. Конфигурация PIM. PIM BFD. Траблшутинг PIM. Информация для подготовки к экзаменам Juniper.}}

=DVMRP=

''Distance vector multicast routing protocol''
*Первый, нах! протокол маршрутизации для мультикаст.
*Dense-mode implementation
*Distance-vector
*Для RPF не использует Unicast таблицу.
*Можно использовать туннелирование между островками Unicast.
*Для передачи routing info использует отдельный протокол.

=PIM=

''Protocol Independent Multicast''
*Использует unicast routing table для RPF check. Использует любой IGP, BGP или оба.
*'''ASM [any-source multicast]: Sparse / Dense / Sparse-Dense/ Bidirectional''' modes.
*Version 1 (encapsulate messages into IGMP, sent to 224.0.0.2)/ 2 (encapsulate messages into protocol 103, sent to 224.0.0.13). Могут использоваться совместно даже на одном интерфейсе.
*Отдельно есть SSM [source-specific multicast]

==Dense mode==
Пригоден для использования с большим количеством получателей в сети.

===Сообщения PIM DM===
*'''Hello''': для нахождения и поддержания соседства.
*'''Join/prune''': имеют одинаковый формат сообщения. В dense mode используются prune сообщения - сообщить upstream роутеру об отказе от группы.
*'''Graft/graft-ack''': graft используется для запроса трафика у upstream роутера, которому уже пришел prune запрос.
*'''Assert''': для выбора gesignated forwarder (DF) для сегмента, где > 1 роутера.

===Соседство PIM DM===

Соседство устанавливается и поддерживается с помощью hello сообщений. В зависимости от версии шлем на нужный адрес.
*Version 1 (encapsulate messages into IGMP, sent to 224.0.0.2)
*Version 2 (encapsulate messages into protocol 103, sent to 224.0.0.13).

hello сообщения могут содержать hold-time - как долго сосед будет в состоянии up без отправки hello. В Junos если holdtimer = 0, то роутер будет использовать локальный таймер. По умолчанию = 105 сек.

===Выборы Designated router PIM DM===
'''Dense''': целесообразно использовать только в том случае, если используем IGMPv1, т.к. он не имеет встречного механизма выбора query роутера.

===Flooding===
Для доставки multicast использует SPT.
*Все роутеры получат одну копию исходного потока.
*Каждый роутер проводит RPF check. Пакеты, которые не прошли RPF check - отбрасываются.
*Пакеты прошедшие RPF check копируются и флудятся во все порты (OIL), за исключением порта, откуда трафик пришел (IIF).
*(S,G) создается на каждом роутере (даже на котором вообще нет получителей).
*Роутеры, не имеющие напрямую включенных получателей должны периодически посылать prune, чтобы быть исключенными из SPT дерева.

===Отбрасывание нежелательного трафика (Prunning)===
Prune отправляется в случае:
#Если нет получателей, подключенных к роутеру.
#Если на роутер пришел prune от downstream роутера.

Информация (S,G) хранится на роутере 3 минуты. Если появляется новый получатель или отваливается старый, роутер не мгновенно среагирует на изменения, не будет ждать таймаут 3 минуты, а сразу обновит инфо.

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

===Source-based tree===

В итоге после отправки всех prune, на сети вырисовывается shortest-path tree, по которому и ходит в дальнейшем трафик.

===Prunning on milti-access network===

При отправке роутером (R2) prune к upstrem роутеру, может пострадать другой роутер из этого же multi-access сегмента (R1).

У роутера из этого же сегмента (R1) есть 2 сек, чтобы отправить join к upstream роутеру и тем самым убить prune от R2.

При этом на R2 будет литься трафик, но сам роутер не будет его передавать другим роутрам, так как нет получателей.

===Grafting back===

SPT уже установлено, но в сети появился новый получатель.

Роутер, получивший IGMP report от получателя, генерирует Graft-message и шлет его по SPT к источнику на upstream-router. Истоник известен, т.к. на всех роутерах хранятся (S,G) записи.

Роутер, ближайший к источнику в ответ на graft сообщение генерирует graft-ack сообщение и посылает его к конечному свитчу. На этом же роутере сохранена запись (S,G), но без OIL interfaces. После получения report, список OIL интерфейсов обновляется, в сторону источника отправляется Join сообщение.

После этого получатель видит свой заветный трафик, не ожидая никаких таймаутов.

===Assert mechanism in Multiaccess networks===

В multi-access сегменте несколько роутеров могут начать посылать трафик вниз к получателям. Чтобы этого избежать, проводятся выборы DF.

Assert сообщение содержит информацию: source, group, metric preference, metric. Наименьшее значение metric pref / metric - выигрывает. если значения равны, то выигрывает наибольший ip роутера.

При этом downstream роутер как-то хитро переподписывается на группу, что получает в итоге трафик от одного роутера.

===Конфигурация PIM DM===
По дефлту при добавлении интерфейса в protocols pim, включается version 2, sparse mode.
set protocols pim assert-timeout 180
set protocols pim interface ge-0/0/0.0 mode dense priority 1 hello-interval 30

===Траблшутинг PIM DM===
show pim interfaces
show pim neighbors
show pim neighbors detail
show pim join extensive
show pim source detail
show multicast rpf ''<src addr>''
show multicast route extensive
show route table inet.1
show route table inet.1 extensive
show multicast next-hops
show pim statistics
show multicast usage

Поддерживается traceoptions.

Пинг source:
mtrace from-source group 224.7.7.7 ttl 20 source <src ip> || запускается от роутера, ближнего к получателю
Пинг получателя: тоже как-то можно продиагностировать, но придется заморочиться.
ping 224.7.7.7 ttl 10 interface ge-0/0/0.900 bypass-routing || запускается от роутера, ближнего к получателю.

==Sparse mode==
Shared tree (rendezvous point tree) = (*,G)

Source-based tree (shortest path tree (SPT)) = (S,G)

Более приспособлена к реальности: поток получают только роутеры, заинтересованные в потоке. Работа в 2х режимах: ASM/SSM. При работе ASM, требуется RP.

*'''DR''' (designated router) - занимается только отправкой register-message, join message в multi-access сети.
*'''DF''' (designated forwarder) - занимается передачей трафика в multi-access netw.

===Сообщение PIM SM===
*'''Hello''': поиск соседей, поддержание соседства, выбор DR в multi-access netw. (отправляется на dst-address 224.0.0.13, src-adderss - p2p интерфейса)
*'''Join/Prune''': подписка/отписка. (отправляется на dst-address 224.0.0.13, src-address - p2p интерфейса)
*'''Assert messages''': выборы designated router (DR).
*'''Register / register-stop''': сообщения между source и RP.
*'''Bootstrap and candidate-RP''': для работы bootstrap.

===Выбор Designated router в PIM SM===
'''Sparse''': выбор роутера проводится со стороны как получателей и так и источников.

*receiver DR: отправляет PIM join и PIM prune сообщения от получателей к RP.
*source DR: отправляет PIM register сообщения от источника к RP.

Выбор основан на DR priority field в hello сообщениях. По умолчанию = 1. Можно задавать вручную. Больший приоритет - выигрышней. Если приоритеты равны, то выигрывает с наибольшим ip.
set protocols pim interfaces xe-0/0/0.50 priority 50

Можно активировать выбор DR и на p2p линке.
set protocols pim dr-election-on-p2p

===Описание Join процесса===
'''Receiver -> RP'''

От подписчика на роутер поступает (*,G) report. Роутер не знает какой именно источник будет использоваться, поэтому он направляет пакет к upstream роутеру не в сторону источника, а в сторону RP.

Строится ''rendevous-point tree (RPT)'' или ''shared tree''.

'''Source DR -> RP'''

Источник начинает вещание группы. Далее source DR роутер инкапсулирует мультикаст трафик в PIM register сообщение и посылает его к RP.

RP получает register сообщение, деинкапсулирует его и начинает слать чистый мультикаст в интерфейс к которого пришел report на подписку к этой группе.

Если у RP есть подписчики на нужную группу, то RP шлет join (S,G) к источнику. После этого строится source-based tree. И роутер, подключенный к источнику сможет слать чистый мультикаст в направлении RP. В короткий промежуток времени RP получит 2 копии одного и того же трафика, чтобы отписаться от инкапсулированного мультикаста, RP шлет register-stop к source DR.

Если на RP приходят register от источника, но у него нет подписчиков на эту группу, то RP отправит register-stop в сторону источника.

Если между RP и источником есть роутер, то промежуточный роутер примет register-stop, начнет отбрасывать мультикаст трафик, но источник как слал его так и будет слать дальше.

Если появится новый источник, то заново повторится весь сценарий: register -> RP, (S,G) -> source, multicast -> RP, register-stop -> source.

Также на RP будет сохранена запись (S,G), т.е. если появятся получатели, то RP пошлет запрос сразу к источнику.

Также роутер между источником и RP каждые 3 минуты будет отправлять register на RP, чтобы RP знало, что источник все еще жив.

====Требования к туннелированию====

Для RP и source DR требуется туннелирование. (Не требуется только если RP=DR).

Возможности туннелирования зависят от платформы. Иногда требуется даже докупать доп оборудование (платы).

На MX сериях туннелирование включается так:
set chassis fpc X pic X tunnel-services bandwidth 1g

Проверка:
show interfaces terse | match "pe|pd"

===SPT switchover===

В ситуациях, когда есть роутеры (R6), для которых путь до источника через RP является не оптимальным, происходит перестроение дерева.

На R6 есть получатель. R6 отправляет (*,G) к RP. От RP приходит пакет (S,G). В таком случае R6 узнает об источнике.

Если R6 видит более оптимальный путь до источника, то он шлет (S,G) к источнику по этому пути (до R1 - ближайший к источнику).

Upstream роутер, получив (S,G) также ищет более короткий путь и шлет (S,G) join вверх по топологии.

Когда между R1 и R6 установлено source-based tree, мультикаст трафик может идти напрямую от R1 к R6.
Есть небольшой промежуток времени, когда R6 будет получать 2 копии мультикаст.

R6 отправляет prune сообщение (S,G) uptream роутеру в сторону RP. RP проверит, что больше нет получателей конкретной группы и отправит prune (S,G) к source DR.

В итоге трафик польется оптимальным путем.

Но на R6 (ближний к получателю) останется 2 записи о группе:
*(S,G) - где в качестве upstream state будет указан: '''Join to source, Prune from RP'''. И в incoming interface: интерфейс в сторону R1 (ближний к источнику).
*(*,G) - в качестве upstream state указан: '''Join to RP'''. Incoming interface: интерфейс в сторону RP.

'''(S,G)''' - более специфичный.

На RP при этом будет храниться информация следующего вида:
'''(S,G) Sate''': Group x.x.x.x, Source: y.y.y.y, Upstream State: '''Prune to Source'''

===RP===

В sparse обязательно должна использоваться RP.
* RP должна быть расположена оптимально, желательно поближе к источникам, чтобы не гонять большие объемы трафика от источников и максимально исключить перестроение на spt.
*Инкапсуляция и деинкапсуляция трафика от источника делается посредством использования tunnel-services. Tunnel-services не требуется, если DR = RP.
*Для одной группы - 1 RP.
*Для надежности, есть 3 механизма нахождения rp: '''static, auto-RP, bootstrap'''. Можно использовать все сразу, тогда по предпочтительности: BSR -> auto-RP -> static.
*Anycast-RP может быть использована с любым из механизмов нахождения RP (можно потом почитать здесь: http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ip-multicast/whitepaper_c11-508498.html).

====Static RP====
Прописывается вручную. Минус - никакого резервирования. В случае, когда RP - умерла, требуется ручками поправить конфигурацию.

Можно задавать приоритет. Чем меньше значение, тем приоритетнее RP среди других.

Дефолтное значение приоритета = 1.

'''Override''': при использовании нескольких механизмов поиска RP, static - менее приоритетный. Override - сделает его приоритетной остальных.

'''PE = RP:'''
set protocols pim rp local address x.x.x.x
set protocols pim rp local group-ranges 227.0.0.0/24 - RP только для этих групп (без range: все IPv4, IPv6 группы)
set protocols pim rp local override
'''PE =/= RP:'''
set protocols pim rp static address x.x.x.x

====Auto-RP====
*Используется с PIMv1 и v2.
*Нестандартное проприетарное решение (вроде от Cisco, нет RFC).
*Позволяет резервировать RP, но не делает балансировку между RP.
*Использует мультикаст для распространения инфо, связанной с RP - dense-mode.
*По PIM домену распространяет набор соответствий group-RP.
Компоненты:
*''Candidate-RP (C-RP)'': периодически отсылают инфо о себе на 224.0.1.39 (слушает только mapping agent) (announce messages).

'''Announce message''':
C-RP IP | 224.0.1.39 | group 224/4
*''Mapping agent'': слушает C-RP, выбирает RP для каждой группы (наибольший ip), анонсирует победителя RP для группы на 224.0.1.40 (Discovery message - слушают все auto-rp роутеры).

'''Discovery message/mapping message''':
Mapping agent IP | 224.0.1.40 | RP 1 - group 224/4

RP выбирается для групп.

Если RP сдохнет, то mapping agent выбирает новую RP. В общем, время падения составляет несколько минут.

'''Конфигурация'''

Обязательно на всех роутерах включить ''sparse-dense mode'' и включить 2 группы, по которым передается служебная инфо. Dense - для передачи служебной информации, Sparse - трафик.
set protocols pim interface all mode sparse-dense
set protocols pim dense-groups 224.0.1.39
set protocols pim dense-groups 224.0.1.40

'''Non-RP:'''
set protocols pim rp auto-rp discovery
''discovery'' - только получение mapping (group-RP) сообщений.

'''C-RP:'''
set protocols pim rp local address 10.200.86.3
set protocols pim rp auto-rp announce
''announce'' - '''без local address''': только слушает announce сообщения, '''с local address''': слушает и отправляет announce.

'''RP + mapping agent:'''
set protocols pim rp local address 10.200.86.3
set protocols pim rp auto-rp mapping
''mapping'' - позволяет отправку (и получение) как announce (C-RP), так и mapping (group-RP) сообщений. Если на роутере не будет настроен local address, то роутер сможет ''отправлять'' только announce.

Несколько '''Mapping Agent''', настраиваем только на них:
set protocols pim auto-rp mapping mapping-agent-election
Mapping agent с наименьшим IP (проиграл) перестает слать mapping messages в сеть, при получении mapping message от агента с бОльшим IP.
set protocols pim auto-rp mapping no-mapping-agent-election

====Bootstrap====
*Работает только с PIMv2. Для распространения информации используют сообщения PIMv2.
*backup RP обеспечивает средство защиты от падения RP и некую балансировку для одних и тех же групп между RP. Но по прежнему для 1 активной группы - используется 1 RP.
*сообщения между роутерами происходит с source Lo interface роутера. Поэтому Lo обязательно должны быть routable. Можно проверить: ''show pim bootstrap''

'''Компоненты:'''
*Candidate-RP: заявляет о себе BSR через unicast (advertisement message).
*Bootstrap router: выбирается на основании наивысшего приоритета (далее наивысшего ip), получает оповещения от C-RP. Определяет RP/group соответствие - это RP-set. Включает RP-set в bootstrap сообщения и распространяет по сети.

BSR - всего лишь роутер, который будет передавать информацию: RP-set: RP <-> группы. То есть в выводе: ''sh pim rps'' мы увидим все RP.

'''Выборы:'''
#Выбор BSR: каждый роутер предполагает, что он BSR. Генерирует BSR-сообщения другим BSR (ip+приоритет+пустой RP-set). Когда роутер получает BSR-сообщение с бОльшим приоритетом (или бОльшим ip), он перестает генерировать сообщения. Выбранный BSR-роутер продолжает генерировать сообщения, остальные лузеры-BSR просто передают эти сообщения своим соседям. Т.о. все роутеры знают об активном BSR. BSR генерирует BSR сообщение, в котором содержится ip BSR, пустой RP-set. DA = 224.0.0.13.
#C-RP передают инфо о себе BSR: свой ip, перечисляют group range.
#BSR собирает C-RP оповещения, складывает их в RP-set (RP+group range). Отправляет RP-set всем PIM роутерам.
#Каждый PIM роутер выбирает для группы действующую RP: делает hash из C-RP ip, group range, mask. Наименьший hash для группы определяет выбранную RP.
Чтобы исключить роутер из выборов (чтобы он перестал отправлять BSR сообщения), можно ему поставить приоритет = 0.

'''Конфигурация'''

BSR [C-RP]:
set protocols pim rp local 10.200.86.3
set protocols pim rp bootstrap priority 200

Non-RP: особого конфига не нужно, просто должен быть включен PIM на интерфейсах.

blair> show pim bootstrap
Instance: PIM.master
BSR Pri Local address Pri State Timeout
10.200.86.3 200 10.200.86.1 100 Candidate 110

oban> show pim rps
Instance: PIM.master
Address family INET
RP address Type Mode Holdtime Timeout Groups Group prefixes
10.200.86.1 bootstrap sparse 150 145 0 224.0.0.0/24
10.200.86.3 bootstrap sparse 150 None 1 235.0.0.0/8
10.200.86.9 bootstrap sparse 150 145 0 232.1.1.0/24
10.200.86.3 static sparse 150 None 1 235.0.0.0/8

====Anycast RP====
Для load-balancing между RP и для обеспечения резерва (redundancy) - лучший способ: использовать Anycast RP.

Может использоваться как с MSDP, так и без него. С использованием MSDP у ваших. Anycast RP будет полное и одинаковое представление об источниках. При выходе одной RP из строя - второй RP не придется изучать инфу о новых source. Лучше использовать MSDP между RP.

С MSDP:
* на lo добавляем еще один адрес [anycast - общий для нескольких PE роутеров]. Изначальный адрес lo лучше сделать primary, anycast адрес - оставить как есть.
[edit interfaces lo0 unit 0 family inet address 172.30.5.1/32]
+ primary;
+ preferred;
[edit interfaces lo0 unit 0 family inet]
address 172.30.5.1/32 { ... }
+ address '''172.30.5.254/32;'''
*nni линки и lo добавляем в protocols pim. Указываем новый адрес lo как адрес RP
set protocols pim rp local address 172.30.5.254
set protocols pim interface ge-0/0/0.208
set protocols pim interface ge-0/0/2.200
set protocols pim interface ge-0/0/3.204
set protocols pim interface lo0.0

*строим MSDP-соседство между PE, которые буду выполнять роль RP. Соседство на lo-primary адресах.
set protocols msdp peer 172.30.5.2 local-address 172.30.5.1
*'''если не хотим использовать MSDP, то можно и без него.''' Используем все предыдущие шаги и потом:

set protocols pim rp local family inet address 172.30.5.254 anycast-pim rp-set address 172.30.5.2
set protocols pim rp local family inet address 172.30.5.254 anycast-pim local-address 172.30.5.1

===Конфигурация дополнительных фич протокола PIM===
====Shortest-path tree cutover (не переключаться на shotest-path tree) ====

set protocols pim spt-threshold infinity no-spt
set policy-options policy-statement no-spt term 1 from route-filter 235.4.5.6/32 exact
set policy-options policy-statement no-spt term 1 from source-address-filter 10.66.66.2/32 exact
set policy-options policy-statement no-spt term 1 then accept
set policy-options policy-statement no-spt term 2 then reject

Делается для того, чтобы ограничить дополнительный статус (S,G), который создается при переключении на source-based tree.

Или если из-за других причин не выгодно, чтобы последний роутер перестраивался на SPT.

====Балансировка PIM join====
Если до источника есть несколько равнозначных путей, использоваться будет только 1 (т.к. пройдет RFP-check только 1, альтернативные пути будут простаивать). Имеется ввиду, что будут балансироваться как join к upstream роутеру, так и трафик в сторону downstream.

С помощью join-load-balance можно использоваться несколько интерфейсов к источнику.

Включается на не RP-роутерах.
set protocols pim join-load-balance

====BFD====
Bidirectional Forwarding Detection работает можно настроить также и для PIM.

set protocols pim interface ge-1/0/0.900 family inet bfd-liveness-detection

====Таймеры====
set protocols pim join-prune-timeout 230 || by default 210

set protocols pim reset-tracking bit || в multi-access сетях для настройки подавления join от нескольких роутеров.

set protocols pim propagation-delay 500 || время, кот определяет как долго ждать выполнения prune на upstream роутере. В теч этого времени роутер ждет любых prune override join message от других роутеров.

set protocols pim override-interval 2000 || макс время для задержки отправки join сообщений. Если в multi-access появился prune, то таймер гарантирует, что не все downstream роутеры среагируют одновременно join сообщением.

===Траблшутинг===

show pim interfaces
show pim neighbors extensive || можно посмотреть RX Join groups!!
show pim statictics || статистика различных пакетов
show multicast usage
show multicast route extensive || информация об группах, присутствующих на данном роутере
show route table inet.1. || таблица форвардинга
show multicast next-hops
show pim join extensive || помимо прочего, полезно: "Upstream state: Join to Source, Prune to RP"
show pim source detail
show multicast rpf x.x.x.x
show pim rps || какие rp известны, через какой механизм, какой набор групп приходит
show pim rps extensive || помимо того, что выше - видны конкретные группы, статус, time active и много всяких подробностей
show pim bootsrap || активный BSR роутер
traceoptions || для диагностики не забываем включать

show pim neighbors
Instance: PIM.master
Interface IP V Mode Option Uptime Neighbor addr
xe-1/1/0.910 4 2 HPLGT 13w2d5h 212.1.253.189
xe-1/2/0.822 4 2 HPLG 03:08:00 192.168.152.49

B = Bidirectional Capable = bidirectional mode supported
G = Generation Identifier = gracefull restart turned on for pim
H = Hello Option Holdtime,
L = Hello Option LAN Prune Delay,
P = Hello Option DR Priority,
T = Tracking Bit = Join Suppression supported, если нет T - то у соседа настроен: ''reset-tracking-bit''

show pim neighbors detail
Interface: xe-1/2/0.822
Address: 192.168.152.49, IPv4, PIM v2, ''sg Join Count: 2'', tsg Join Count: 0
BFD: Disabled
Hello Option Holdtime: 105 seconds 102 remaining
Hello Option DR Priority: 1
Hello Option Generation ID: 1593016797
Hello Option LAN Prune Delay: delay 1000 ms override 3000 ms
Address: 192.168.152.50, IPv4, PIM v2, Mode: Sparse, sg Join Count: 0, tsg Join Count: 0
Hello Option Holdtime: 65535 seconds
Hello Option DR Priority: 1
Hello Option Generation ID: 1898464853
Hello Option LAN Prune Delay: delay 500 ms override 2000 ms
Join Suppression supported

pim {
traceoptions {
file pim.log size 10m;
flag all;

PIM Join и PIM Prune можно посмотреть в '''pim statistics''' (как принятые так и отправленные).

> show pim statistics interface xe-1/2/0.822
Instance: PIM.master Family: INET
PIM Interface statistics for xe-1/2/0.822
PIM Message type Received Sent Rx errors
'''V2 Hello 389 413 0'''
V2 Register 0 0 0
V2 Register Stop 0 0 0
'''V2 Join Prune 0 195 0'''

В monitor traffic interface не будут отображаться PIM Join, PIM Prune. Если требуется помониторить входящие и исходящие пакеты, то можно только замиррорить трафик.

При включенном traceoptions, join также отчетливо видны (исходящие):
traceoptions {
file pim.log size 10m;
flag all;
flag join detail;
flag prune detail;

> show log pim.log | match 235.69.101.
Oct 13 13:21:50.354863 group 235.69.101.1 joins 1 prunes 0
Oct 13 13:21:50.354881 group 235.69.101.2 joins 1 prunes 0
Oct 13 13:21:50.354897 group 235.69.101.4 joins 1 prunes 0
Oct 13 13:21:50.354913 group 235.69.101.11 joins 1 prunes 0
Oct 13 13:21:50.354929 group 235.69.101.19 joins 1 prunes 0
Oct 13 13:21:50.354944 group 235.69.101.20 joins 1 prunes 0

==Bidirectional mode==
То же самое что и Sparse, только в bidirectional PIM роутеры строят shared bidirectional trees (*,G) и не производят переключение на SPT. За счет этого в процессе работы используются только (*,G).

Считается, что этот режим более масштабируемый для сети.

В отличие от PIM-SM, в данном режиме не требуется PIM Register tunneling.

т.к не происходит перестроение на SPT - может наблюдаться неоптимальный мультикаст роутинг.

=Дополнительная информация=
*[[Глава 5. PIM-SSM]]
*[[Политики в мультикасте | Глава 6. Политики в мультикасте]]
*[[MSDP | Глава 4. MSDP]]

Глава 2. Multicast, IGMP

2021-07-15T18:37:27Z

Наталия Бобкова:

{{#description2: multicast адресация. Routing tables junos. IGMP сообщения. IGMPv2. IGMPv3. Конфигурация IGMP. Траблшутинг IGMP.Информация для подготовки к экзаменам Juniper.}}

== Общее ==

Мультикаст = поток UDP на определенные адреса.

== Адресация ==

- 224/24 - local network control block [разничные протоколы маршрутизации, использующие мультикаст: OSPF, rip, igmp, ldp ...]

- 224.2.0.0/16 - SDP/SAP, адреса, использующиеся для передачи multicast session.

- 232/8 - под SSM

- 233/8 - используется под глобальную мультикаст-адресацию (GLOP) || 233.[first byte of AS].[second byte of AS].1-255 || только для 16-ти битных AS

- 234/8 - unicast-prefix-based IPv4

- 239/8 - administratively scoped block || это адреса, которые могут быть использованы в разных частях сети. Тоже самое, что и private IP.

== Multicast IP => multicast mac ==
Если не заморачиваться почему так, то правило перевода простое:

Конвертируем последние 23 бита IP в десятичную систему счисления.
*224.10.8.5: 0001010.00001000.00000101 => 0a.08.05

Прибавляем к "01-00-5e" переведенное значение.
*01-00-5e + 0a-08-05 = 01-00-5e-0a-08-05

Проблема в том, что для разных мультикаст-групп (адресов) - мак-адреса будут пересекаться, т.к. не учитываются первые биты ip-адреса.

== Multicast forwarding ==
*'''unicast forwarding''' основан на '''dest ip'''.
*'''multicast forwarding''' основан на '''source ip'''.

Предотвращение петель:
*RPF-check для источника: сравнивается с какого интерфейса фактически пришел мультикаст пакет с тем, откуда по unicast table пакет должен приходить (источник или RP). Если сходится - RPF done, не сходится - RPF fail. Префиксы, прошедшие RPF-check хранятся в inet.1.
*Multicast трафик никогда не форвардится в сторону источника.

show multicast rpf ''<group ip>''

=== Routing tables ===

'''inet.0''' - дефолтная таблица для проведения RPF-check [можно использовать inet.2, которая для этого и предназначена]. Если unicast и multicast топологии одинаковые, то inet.0 и inet.2 будут одинаковы.

'''inet.1''' - записываются результаты RPF-check, форвардинг производится на основании этой таблицы.
>show route table inet.1
inet.1: 238 destinations, 238 routes (238 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
224.0.0.0/4 *[Multicast/180] 74w2d 13:10:11
MultiResolve
224.0.0.0/24 *[Multicast/180] 74w2d 13:10:11
MultiDiscard
232.0.0.0/8 *[Multicast/180] 74w2d 13:10:11
MultiResolve
232.192.1.1,10.200.86.1/32*[PIM/105] 6w0d 08:32:53
Multicast (IPv4) Composite
232.192.1.1,10.200.86.2/32*[PIM/105] 8w3d 15:25:48
Multicast (IPv4) Composite
232.192.1.2,10.200.86.1/32*[PIM/105] 6w0d 08:32:52
Multicast (IPv4) Composite
232.192.1.2,10.200.86.2/32*[PIM/105] 8w3d 15:25:52
Multicast (IPv4) Composite
232.192.1.4,10.200.86.1/32*[PIM/105] 23:11:56
Multicast (IPv4) Composite
...

'''Detailed'''
232.192.1.1.10.200.86.1/64 (1 entry, 1 announced)
*PIM Preference: 105
Next hop type: Multicast (IPv4) Composite, Next hop index: 1048796
Address: 0xa4edf30
Next-hop reference count: 28
State: <Active Int Ext AckRequest>
Local AS: 100
Age: 6w0d 8:35:30
Validation State: unverified
Task: PIM.master
Announcement bits (1): 0-KRT
AS path: I
AS path: Recorded
'''inet.2''' - если для multicast на сети должна быть использована другая топология, то используем эту таблицу. inet.2 в таком случае будет использоваться для RPF-check.

MP-BGP и multitopology IS-IS могут напрямую заполнять маршрутной информацией inet.2.

Чтобы ISIS стал заполнять inet.2 - нужно включить
set protocols isis topologies ipv4-multicast
Все остальные протоколы для заполнения таблицы должны заниматься копированием в inet.2 маршрутов с помощью '''RIB-groups'''.

'''IMPORT-RIB''': для протокола PIM import-rib копирует маршруты из протокола в указанную таблицу. То есть указываем только одну таблицу. Указанная таблица будет использоваться для RPF.

Для остальных протоколов первая таблица <> - откуда копируются маршруты, вторая <to-inet2> - куда копируются.

set routing-options rib-groups mcast-table import-rib inet.2
set protocols pim rib-group inet mcast-table

set routing-options rib-groups import-rib to-inet2 [inet.0 inet.2]
set routing-options rib-groups import-policy static *''по желанию/необходимости''
set protocols ospf rib-groups to-inet.2
set routing-options interface-routes rib-group inet to-inet2

В обычном понимании: если задаём ''export-ribs'', то при этом указывается только одна таблица, куда будут скопированы маршруты. Но для PIM не работает export-ribs.

== Automatic Multicast Tunnel Gateway [AMT protocol]==
Возможность соединять multicast-enabled сеть и ipv4-only сеть (без мультикаст). Позволяет получать мультикаст трафик, там, где не включен мультикаст.

AMT протокол дает возможность искать и устанавливать соседство между relay-роутерами и gateway-роутерами.

Relay-роутеры - обычные мультикаст роутеры (с native-multicast), на которых аггрегируется большое кол-во AMT-туннелей.

Трафик до пользователей в multicast сети идет как multicast. Запросы трафика - multicast join.

Трафик до пользователей в ipv4-only сети получают в виде UDP unicast stream. Запросы делаю в виде UDP IGMP request.

Работает только с PIM-SSM.

Работает только с IPv4.

== IGMP ==
''Internet group management protocol''

IGMP не протокол маршрутизации. Работает между получателями и роутером, с которого отдается мультикаст в сегменте. Он просто передает информацию роутеру о заинтересованных получателях и получателях, которые хотят покинуть группу.

Для IPv6 используется точно такой же по принципу работы протокол MLD.
===Сообщения===
'''Report/Join message''': отправляет хост, когда хочет подписаться на какую-то группу. DA = group address. После того как хост подписался на группу, он должен отвечать на query message от роутера. TTL = 1, т.к. сообщение должно долететь только до ближайшего маршрутизатора.

'''General query''': роутер шлет general query на 224.0.0.1 всем хотсам (роутер при этом называется query-router (опрашивающий)). Хосты в ответ присылают группы, на которые они еще хотят быть подписаны. TTL тоже = 1.

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

Если в домене несколько query-роутеров, то в качестве активного будет выбран с наименьшим ip.

'''Leave message''':
*''IGMP2'': Хост отправляет leave message для конкретной группы на общий адрес 224.0.0.2.
*''IGMP1'': Хост просто перестает отвечать на query от роутра. Если больше нет подписчиков на группу, роутер по истечению какого-то интервала перестает слать трафик в интерфейс.

'''Group-specific query''':
*''IGMP2'': Когда роутер получил leave от хоста, он отправляет general-specific query на адрес этой группы, чтобы понять есть ли еще заинтересованные получатели.

=== Разные версии протокола ===

*'''IGMP v 1'''
:*Чтобы получить трафик от конкретной группы, хост отправляет роутеру report message.
:*Для отключения от группы хост просто перестает отвечать роутеру на query.
:*Таймаут, после которого роутер перестает вещать группу в downstream interface = 260.
(robustness count * igmp_query interval) + (1*IGMP response interval) = (2*125)+(1*10) = 260
:*Для выбора query-router нет отдельного механизма. Выбирать должен routing protocol.

*'''IGMP v 2'''
:*Чтобы подписаться, хосты шлют report-message.
:*Чтобы отписаться, хосты шлют leave-group message.
:*Чтобы проверить наличие подписчиков, роутер шлет group-specific message.
:*Таймаут, после которого роутер перестает вещать: нет ответа от хостов в течение 2 сек (дефолт).
robusness count * IGMP last member query interval = 2*1 = 2
:*Query-router - с наименьшим ip. Если падает query-router, его роль выполняет non-query router.

*'''IGMP v 3'''
Все улучшения для v 2. [активная подписка и отписка на группы].

Используется для SSM, поэтому report message (на адрес 224.0.0.22 - all IGMPv3) может содержать source information.

===L2 switches===

Свитчи обрабатывают мультикаст трафик как бродкаст, по умолчанию, т.е. шлет трафик во все порты.

IGMP-snooping позволяет выделить мультикаст трафик. С помощью IGMP сообщений, свитч может понять где получатели и слать трафик только к ним.
Делит порты на multicast-router interface (откуда приходят query, либо заданы статически), host-side interface (все остальные).

Передача трафика:

#Весь трафик направлен в multicast-router интерфейс.
#Если через IGMP-snooping свитч узнает о портах, за которыми сидят получатели, то шлет трафик туда.
#224/8 сеть бродкастом идет во все порты, кроме входящего.

Стандартное расширение IGMP позволяет только обрабатывать query от роутера и сообщения от получателей. Не генерирует IGMP сообщения.

IGMP snooping proxy ведет себя как роутер для получателей (генерирует query), работает как получатели для роутера (генерирует leave и join сообщения).

Тем самым уменьшается кол-во report-сообщений для роутера.

== Configuration ==

На интерфейсах с активным pim, автоматически включается IGMPv2.

Можно менять дефолтные значения всяких таймеров.

Можно статически подписываться на какую-то группу (полезно для тестов). При этом интерфейс просто добавляется в outgoing list.

По умолчанию на Juniper используется IGMPv2, но при необходимости можно задать на интерфейсах нужную версию.
set protocols pim interface ge-0/0/0.910
set protocols igmp interface ge-0/0/0.910 version 1
set protocols igmp interface ge-0/0/0.910 static group 239.100.1.1

== Troubleshoting ==
show igmp interfaces
show igmp groups
show igmp statistics
включение traceoptions

==Дополнительная информация==
*[[Глава 3. Routing protocols (DVMRP, PIM-DM, PIM-SM)]]
*[[Глава 5. PIM-SSM]]
*[[MSDP | Глава 4. MSDP]]

Реализация MPLS в ядре сети

2021-07-15T18:35:44Z

Наталия Бобкова:

{{#description2:Дизайн и использование MPLS на ядре сети. RSVP auto-mesh. LDP tunneling. MPLS мастрабирование. L3VPN масштабирование. BGP Considerations для L3VPN. P2MP LSP. Информация для подготовки к экзаменам Juniper.}}

=Core MPLS Designs=
==RSVP auto-mesh==
Когда на сети используется RSVP, но для конкретных функций (L3VPN, VPLS, ...) требуется full-mesh, то чтобы не прописывать все LSP руками, можно использовать '''RSVP-full-mesh'''.

Строится, когда:
* От PE пришел iBGP маршрут (inet.0, VPLS, L3VPN)
* IP PE из определенного диапазона.
[edit routing-options]
dynamic-tunnels {
tunnel-1 {
rsvp-te tunnel-1 {
label-switched-path-template {
default-template;
}
destination-networks {
10.200.86.0/26;

В книге описано, что просто туннель не поднимется (лаба на mx80), т.к. требуется маршрут до Lo PE с меткой в inet.0. '''Решение:''' Нужно временно включить LDP и set protocols mpls traffic-engineering bgp-igp-both-ribs'', ждем пока построятся RSVP LSP, потом отключаем LDP.

Но по факту в лабе завелось и без дополнительных манипуляций с LDP (лаба на vSRX). =)

В итоге, когда приходят пакеты по iBGP, то до ''protocol next-hop'' (Lo PE, который должен попадать в dest-networks) автоматически поднимается туннель.
'''bgp.l3vpn.0''': 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
''10.200.86.3:1212:12.12.12.12/32''
*[BGP/170] 12:34:36, localpref 100, from 10.200.86.3
AS path: I
> to 192.168.86.1 via ge-0/0/0.30, label-switched-path '''10.200.86.3:dt-rsvp-tunnel-1'''

'''bgp.l2vpn.0''': 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
''10.200.86.9:1515:1:1/96''
*[BGP/170] 12:16:54, localpref 100, from 10.200.86.9
AS path: I
> to 192.168.86.1 via ge-0/0/0.30, label-switched-path '''10.200.86.9:dt-rsvp-tunnel-1'''

'''inet.3''': 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.200.86.0/26 *[Tunnel/300] 12:10:07
Tunnel
''10.200.86.3/32'' *[RSVP/7/3] 00:03:04, metric 4
> to 192.168.86.1 via ge-0/0/0.30, label-switched-path '''10.200.86.3:dt-rsvp-tunnel-1'''
''10.200.86.9/32'' *[RSVP/7/3] 00:03:04, metric 5
> to 192.168.86.1 via ge-0/0/0.30, label-switched-path '''10.200.86.9:dt-rsvp-tunnel-1'''

lagavulin> show mpls lsp name '''10.200.86.3:dt-rsvp-tunnel-1''' detail
Ingress LSP: 2 sessions
10.200.86.3
From: 10.200.86.7, State: Up, ActiveRoute: 0, LSPname: 10.200.86.3:dt-rsvp-tunnel-1
ActivePath: (primary)
PathDomain: Inter-domain
LSPtype: '''Dynamic Configured'''
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 4)
192.168.86.1 S 192.168.86.41 S 192.168.86.50 S 192.168.86.25 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
192.168.86.1 192.168.86.41 192.168.86.50 192.168.86.25

*Можно добавлять разные фичи TE:
[edit protocols mpls]
label-switched-path default-template {
template;
link-protection;

*Если до одного и того же Lo PE есть динамический и статический LSP, то будет выбран статический, т.к. у него ''preference 2'' меньше:
inet.3: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)
10.200.86.3/32 *[RSVP/7/'''[[1]]'''] 00:00:26, metric 4
> to 192.168.86.1 via ge-0/0/0.30, label-switched-path lagavulin-to-oban
[RSVP/7/'''[[3]]'''] 00:02:32, metric 4
> to 192.168.86.1 via ge-0/0/0.30, label-switched-path 10.200.86.3:dt-rsvp-tunnel-1
*Если по iBGP перестают прилетать маршруты, то туннель через 15 минут умрет:
lagavulin> show dynamic-tunnels database
Table: inet.3
Destination-network: 10.200.86.0/26
Tunnel to: 10.200.86.9/32 ('''expires in 00:14:46 seconds''')
Reference count: 0
Next-hop type: rsvp-te
10.200.86.9:dt-rsvp-tunnel-1

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

===Процесс построения===

[[Файл:ldp_tunneling.png]]
* Роутер A (PE) - LDP. Egress: начинает анонсировать себя с меткой 3 в сторону B.
* Роутер B (PE) - LDP + RSVP. Анонс LoA с меткой 20 в сторону C. B: '''mpls.0''': 20 pop -> A
* Роутер C (P) - RSVP (с LDP-tunneling). Анонс LoA с меткой 30 в сторону E. С: '''mpls.0''': 30 swap 20 -> B.
* Роутер D (P) - между E<>C - RSVP LSP, где D - предпоследний роутер.
* Роутер E (P) - LDP + RSVP. Анонс LoA с меткой 40 в сторону F. E: '''mpls.0''': 40 swap 30 -> C. Но C не direct connected, а доступен через туннель => идем смотреть в inet.3. E: '''inet.3''': LoC push 100 -> D. => E: '''mpls.0''': 40 swap 30 push 100
* Роутер F (PE) - LDP. Ingress: '''inet.3''': LoA: push 40 -> E.

В обратную сторону строится точно также.

Когда туннель построен, между ingress (C) и egress (E) роутерами RSVP LSP установится LDP соседство! Устанавливается по UDP 646 на Lo P (''берется из конфигурации туннеля''), ''не hello механизм, но тоже работает’’.

Обязательно на P роутерах включить в LDP Lo, чтобы поднялся туннель C - E.

Схема работает только в пределах области.

При включенном LDP tunneling будут видны скрытые маршруты в inet.3

Можно использовать, когда не все устройства в сети поддерживают RSVP, но на ядре требуется TE. Также TE как таковой не требуется вообще на PE, нужно только на ядре, на P роутерах. Поэтому RSVP можно запустить только на ядре, а PE будут подцепляться по LDP.

При конфигурации может возникнуть проблема с переносом маршрутов из inet.3 в inet.0 (на PE роутерах). Решается как обычно: ''set protocols mpls traffic-engineering bgp-ibgp-both-ribs''. Или любым другим способом.

===Configuration===
[[Файл:ldp_tunneling_laba.png]]

'''PE (LDP + RSVP)''':
[protocols mpls]
traffic-engineering bgp-igp-both-ribs;
label-switched-path talisker-to-oban {
to 10.200.86.3;
ldp-tunneling;
[protocols ldp]
interface ge-0/0/0.70;
interface ge-0/0/0.120;
interface all;
'''С другой стороны на PE''':
[protocols mpls]
traffic-engineering bgp-igp-both-ribs;
label-switched-path oban-to-talisker {
to 10.200.86.4;
ldp-tunneling;

===Проверка===
Между крайние PE, на которых настроено туннелирование, установили соседство между собой по LDP:
talisker> show ldp neighbor
Address Interface Label space ID Hold time
10.200.86.3 lo0.0 10.200.86.3:0 42

На PE, к которому подключается CE:
macduff> show route 10.200.86.1
inet.0: 30 destinations, 40 routes (30 active, 0 holddown, 0 hidden)
10.200.86.1/32 *[LDP/9] 00:19:03, metric 1
> to 192.168.86.13 via ge-0/0/0.70, Push 300016
[OSPF/10] 00:19:03, metric 4
> to 192.168.86.13 via ge-0/0/0.70

talisker> show route label 300016 detail
mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
300016 (1 entry, 1 announced)
*LDP Preference: 9
Next hop type: Router, Next hop index: 548
Address: 0x934c3b8
Next-hop reference count: 2
Next hop: 192.168.86.33 via ge-0/0/0.120 weight 0x1, selected
Label-switched-path talisker-to-oban
Label operation: Swap 299776, Push 299968(top)
Label TTL action: prop-ttl, prop-ttl(top)
State: <Active Int NhAckRequest>
Local AS: 1111
Age: 19:37 Metric: 1
Task: LDP
Announcement bits (1): 0-KRT
AS path: I
Prefixes bound to route: 10.200.86.1/32

tormore> show route label 299968 detail
mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
299968(S=0) (1 entry, 1 announced)
*RSVP Preference: 7/1
Next hop type: Router, Next hop index: 581
Address: 0x934d258
Next-hop reference count: 2
Next hop: 192.168.86.38 via ge-0/0/0.130 weight 0x1, selected
Label-switched-path talisker-to-oban
Label operation: Pop
State: <Active Int AckRequest>
Local AS: 1111
Age: 1:09:29 Metric: 1
Task: RSVP
Announcement bits (1): 0-KRT
AS path: I

oban> show route label 299776 detail
mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
299776 (1 entry, 1 announced)
*LDP Preference: 9
Next hop type: Router, Next hop index: 544
Address: 0x934c568
Next-hop reference count: 2
Next hop: 192.168.86.26 via ge-0/0/0.110, selected
Label operation: Pop
State: <Active Int>
Local AS: 1111
Age: 26:53 Metric: 1
Task: LDP
Announcement bits (1): 0-KRT
AS path: I
Prefixes bound to route: 10.200.86.1/32
=MPLS Scaling=
==Hierarchical LSP==
Иерархичные LSP позволяют роутеру воспринимать core-to-core линки, как физические интерфейсы.
То есть протокол IGP может анонсировать метрики и TE характеристики LSP, как обычного интерфейса.

Для внедрения иерархичных LSP требуется OSPF.

===Configuration===
*LSP задаём, как te-link - это даёт возможность другим роутером увидеть данный линк внутри TED
*Конфигурируем логический интерфейс.
*Link-management
Вся конфигурация задается только на P роутерах.

lagavulin> show configuration protocols
rsvp {
interface ge-0/0/1.0;
interface ge-0/0/2.0;
peer-interface peer-talisker;
}
mpls {
label-switched-path lagavulin-to-talisker {
to 10.200.86.4;
}
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
interface ge-0/0/1.0
interface ge-0/0/2.0;
peer-interface peer-talisker;
link-management {
te-link lagavulin-to-talisker-te {
local-address 192.168.87.1;
remote-address 192.168.87.2;
te-metric 1;
label-switched-path lagavulin-to-talisker;
peer peer-talisker {
address 10.200.86.4;
te-link lagavulin-to-talisker-te;

*Для самого туннеля задаются отдельные ip: конечный и начальный (как у любого туннеля).
*Te-metric - та самая метрика, которая будет сравниваться при построении кратчайшего пути
lagavulin> show link-management
Peer name: peer-talisker, System identifier: 55629
State: Up, Control address: 10.200.86.4
Hello interval: 150, Hello dead interval: 500
TE links:
lagavulin-to-talisker-te
TE link name: lagavulin-to-talisker-te, State: Up
Local identifier: 2684274792, Remote identifier: 2684274792,
Local address: 192.168.87.1, Remote address: 192.168.87.2, Encoding: Packet,
Switching: Packet, Minimum bandwidth: 0bps, Maximum bandwidth: 0bps,
Total bandwidth: 0bps, Available bandwidth: 0bps
Name State Local ID Remote ID Bandwidth Used LSP-name
lagavulin-to-talisker Up 14956 0 0bps Yes '''dalwhinnie-to-tormore'''
В итоге видим, что ''dalwhinnie-to-tormore'' туннелируется в ''lagavulin-to-talisker''.
dalwhinnie> show mpls lsp name dalwhinnie-to-tormore detail
Ingress LSP: 1 sessions
10.200.86.9
From: 10.200.86.5, State: Up, ActiveRoute: 0, LSPname: dalwhinnie-to-tormore
ActivePath: (primary)
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 60)
192.168.86.29 S '''192.168.87.2''' S 192.168.86.33 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
192.168.86.29 192.168.87.2 192.168.86.33
Total 1 displayed, Up 1, Down 0

На роутере, где будет настроен и начинаться hierarchical LSP будет делаться дополнительный ''push'' метки, для прохождения пакета внутри hierarchical LSP.

Причём на P роутере, транзитном для hierarchal LSP, не будет никакой информации о LSP, вложенном в hierarchical LSP. В этом, наверное и заключается основное преимущество метода - '''масштабируемость'''.

==Hierarchical RSVP Domains==
Смысл: разбить путь прохождения пакета на части: PE-P, P-P, P-PE LSP.

PE имеют RSVP-TE LSP до ближайших P роутеров. Между Р роутерами - full-mesh.

При таком подходе нельзя использовать MPLS VPN сервисы, т.к. Пропадает целостность РЕ-РЕ LSP.

Но такой подход даёт возможность использовать совмещённый LDP+RSVP.

Использовать функции ТЕ в сore и различные механизмы защиты (link-protection, link-node-protection).

==RSVP Refresh reduction==
Для решения проблем с масштабируемостью в самом протоколе RSVP, были сделаны несколько дополнений:
*'''reliable messages''': внедрены 2 новых объекта MESSAGE_ID, MESSAGE_ID_ACK.
*'''boundle messages''': группировка/объединение уже существующих сообщений RSVP.
*'''summary refresh update''': объединяет несколько path или resv сообщений в один update.
[edit protocols rsvp]
Interface ge-0/0/0.120
Aggregate
=L3VPN scaling=
Кол-во VRF-таблиц может быть до 9000 в рамках одного роутера (кончено же зависит от платформы).

Кол-во маршрутов (в целом) сильно зависит от платформы, но на MX960 можно поддерживать до 1,5 млн.

==BGP Considerations==
===Route-reflection in VPN Environments===
RR должен иметь LSP до любого PE, которому он будет передавать MPLS VPN маршруты. Иначе RR не сможет сделать валидными MPLS VPN маршруты, т.к. next-hop будет unusable и RR просто не будет передавать их остальным PE (''no active'').

В качестве RR лучше делать P роутеры.

На RR не требуется конфигурация самих VRF, RR просто должны уметь работать с MPLS VPN маршрутами (family inet-vpn). ''keep all'' будет включен при включении Cluster ID.

PE роутеры буду фильтровать полученные маршруты по RT. От RR будут прилетать все маршруты из ''bgp.l3vpn.0''.

Чтобы без дополнительных действий происходило обновление маршрутов на RR, требуется использовать '''refresh''': BGP-speaker просит обновить все NLRI.
{{note|text=При использовании RR, на PE, получивших l2vpn, l3pvn маршруты, выбор активного пути (до RR) не будет опираться на стандартный BGP-алгоритм выбора best path. Для использования стандартного best path: ''l2vpn-use-bgp-rules''}}

VRR не начнет передавать получить vpn маршруты от других RR, пока на локальном RR не появятся первые клиенты.

Схема: blair - RR, lagavulin - PE1, oban - PE2.
PE1 и PE2 передают маршруты RR.
====LDP====
При использовании LDP, нужно разрешить RR участвовать в LDP, чтобы обеспечить возможность делать resolve для next-hop в таблице inet.3.

При включении LDP на RR - проблема с unusable маршрутами исчезает.
====RSVP====
При использовании RSVP требуется LSP от RR до каждого PE.

Требуется создать LSP: lagavulin (PE) <> blair (RR), blair (RR) <> oban (PE).

*И обязательно, что бы RR делал ''next-hop self'', без этого PE будет принимать VPN маршрут, но делать его ''unusable'', т.к. indirect nexp-hop будет недоступен. И трафик пойдет тогда по LSP от PE к RR, потом по LSP от RR к PE.
*Либо между PE потребуется иметь LPS (RSVP).

Либо можно заставить RR думать, что у него есть LSP до PE.

* Позволить ''bgp.l3vpn.0'' использовать другую (не inet.3) таблицу для resovle next-hop.
blair>
[edit routing-options]
resolution {
rib bgp.l3vpn.0 {
resolution-ribs inet.0;

Между PE тогда должна быть LSP.

* С помощью rib-groups скопировать маршруты из inet.0 в inet.3
blair>
[edit routing-options rib-groups inet.0-to-inet.3]
import-rib [ inet.0 inet.3 ];
[edit protocols ospf rib-group]
inet.0-to-inet.3;

Чтобы не все маршруты, а только /32 попадали в inet.3, можно сделать следующее
routing-options {
rib inet.3 {
static {
route 0.0.0.0/0 discard;
Или с помощью policy решить эту же проблему:
policy-options policy-statement Loopbacks-Only
term Loopbacks {
from {
route-filter 10.200.86.0/24 prefix-length-range /32-/32;
then accept;
term Reject-All-Else {
then reject;

routing-options
rib-groups {
inet.0-to-inet.3 {
import-rib [ inet.0 inet.3 ];
import-policy Loopbacks-Only;

===BGP Route-target Family===
По дефолту при создании L3VPN, L2VPN, РЕ роутер будет пересылать маршруты о своих VPN по всей сети. Удаленный PE будет получать все маршруты, но использовать только те, которые подходят по созданные на нем VPN.

С использованием '''route target filtering''': PE присылает RR список необходимых RT. RR применяет route filter и отправляет только соответствующие маршруты.

В family '''route-target''' (на PE) можно задавать параметры prefix-limit, external-paths, advertise-default.

При передаче маршрутов от RR, он меняет hext-hop и originator ID на свои.

Чтобы изменить такое дефолтное поведение на PE добавляем ''family route-target'':
tormore>
[edit protocols bgp group ibgp]
type internal;
local-address 10.200.86.9;
family inet-vpn {
unicast; }
family route-target;
neighbor 10.200.86.7;
neighbor 10.200.86.3;
neighbor 10.200.86.5;

'''Проверка'''
tormore> show route table bgp.rtarget.0
'''bgp.rtarget.0''': 2 destinations, 5 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both
1:1:1/96
*[BGP/170] 00:01:58, localpref 100, from 10.200.86.3
AS path: I
> to 192.168.86.38 via ge-0/0/3.0
[BGP/170] 00:01:54, localpref 100, from 10.200.86.5
AS path: I
> to 192.168.86.38 via ge-0/0/3.0, Push 100496
to 192.168.86.34 via ge-0/0/2.0, Push 655505
[BGP/170] 00:02:03, localpref 100, from 10.200.86.7
AS path: I
> to 192.168.86.34 via ge-0/0/2.0, Push 655489
'''1:2:2/96'''
*[RTarget/5] 00:02:15
'''Local'''
[BGP/170] 00:01:54, localpref 100, from 10.200.86.5 AS path: I
> to 192.168.86.38 via ge-0/0/3.0, Push 100496
to 192.168.86.34 via ge-0/0/2.0, Push 655505

'''Local''' обозначает, что локальный роутер также импортирует маршруты с 2:2 target. Таким образом РЕ видит каким удаленным РЕ какие VPN маршруты стоит отправлять.

==VPLS==
===P2MP LSP===
В случае использования P2P LSP, source PE должен расплодить несколько копий трафика и послать по разным LSP.

В случае использования P2MP: source PE отправляет трафик, копирование трафика происходит на определенном роутере, на котором происходит дальнейшее разветвление путей передачи трафика (''branch point'').

Таким образом уменьшится число копий трафика в сети. Копирование будет происходить только на ''branch points''. Понятно, что при внедрении VPLS может быть много точек, поэтому будет логично использовать P2MP.

Для VPLS внедрение P2MP делается внутри routing-instance.
=====Configuration=====
Здесь не описано, но дополнительно требуется создать p2mp LSP между PE роутерами.

Описание настройки есть здесь: http://juniper-exam.ru/index.php/%D0%93%D0%BB%D0%B0%D0%B2%D0%B0_2._Label_Distribution_Protocols_(RSVP,_LDP)#P2MP
dalwhinnie> show configuration routing-instances oak
instance-type vpls;
interface ge-1/0/0.0;
route-distinguisher 10.200.86.1:100;
'''provider-tunnel''' {
rsvp-te {
label-switched-path-template {
default-template;
vrf-target target:300:200;
protocols {
vpls {
site-range 5;
no-tunnel-services;
site oak-ce1 {
site-identifier 1;
interface ge-1/0/0.0;

''default-template'' можно заменить на свой, указав желаемые параметры для LSP.

===Filtering BUM Traffic===
Еще один способ уменьшить количество трафика Layer 2 broadcast, unknown unicast и multicast traffic - создать ''firewall family vpls filter'' и применить его [edit routing-instance oak forwarding-options family vpls].

=Дополнительная информация=
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]
*[[Отказоустойчивость и оптимизация в MPLS]]
*[[Traffic engineering]]

EVPN

2021-07-15T18:35:08Z

Наталия Бобкова:

MVPN

2021-07-15T18:34:12Z

Наталия Бобкова:

{{#description2:Next-generation MVPN. Типы NLRI для Multicast-VPN. MVPN деревья. Режимы работы MVPN. Sender/Receiver site. Draft-Rosen VPNs. Конфигурация MVPN. Траблшутинг MVPN. Информация для подготовки к экзаменам Juniper.}}

MVPN - L3VPN, в котором клиенту предоставляется возможность пускать свой мультикаст через сеть провайдера [сигнального unicast и датного multicast трафика], дополнительно к L3VPN. В подобных решениях могут быть совершенно разные топологии. Источники и получатели должны быть однозначно на сети клиента. RP можно использовать как на сети клиента, так и на сети провайдера. Для обнаружения RP могут использоваться также разные механизмы. И также можно использовать как SSM, так и ASM. И даже dense или sparse mode. И между PE<>CE могут использоваться разные протоколы static, ospf, bgp [любой вариант l3vpn]. То есть многообразие полнейшее.

В качестве транспортного протокола на сети провайдера могут выступать и GRE и MPLS.

=Next-generation MVPN=
NG-MVPN does not require PIM in the provider network.

It requires that a label be on the final hop, therefore penultimate hop popping is disabled on multicast LSPs.

Point-to-multipoint LSPs can help reduce the burden of data replication, and eliminate the need for PIM in the provider network.

В старой модели для сигнализации использовался PIM, для форвардинга - GRE-tunnels. [Multicast for Draft-Rosen VPNs]

В новой модели для сигнализации - BGP, для форвардинга - MPLS. [NG MVPN, MBGP Multicast VPN]

При использовании BGP, как сигнального протокола: ввели 7 MP-BGP NLRI (Oo).

Общие термины:
*'''Provider multicast service interface (PMSI)''' - туннель для передачи мультикаста.
*'''Inclusive-PMSI (I-PMSI)'''
:*multidirectional I-PMSI - позволяет всем PE передавать мультикаст всем остальным PE.
:*unidirectional I-PMSI - позволяет одному PE передавать мультикаст всем остальным PE.
*'''Selective-PMSI (S-PMSI)''' - PE передает мультикаст только тому PE, который отправил запрос на присоединение к forwarding-tree.

В качестве PMSI может быть использован P2MP RSVP. Плюс - для передачи можно использовать обычные методы защиты RSVP LSP.

'''Выдержка для напоминания:'''
В случае использования P2MP: source PE отправляет одну копию трафика. Копирование трафика происходит на роутере, где разветвляются пути передачи трафика (''branch point'').

==MP-BGP для Multicast-VPN==

''Сейчас тут будет описание предназначений каждого из типов NLRI. Сначала покажется сложным, но надо прочитать, чтобы хоть примерно ориентироваться. Зато потом при чтении раздела Trees все встанет на свои места.''

AFI 1/ SAFI 5

Роуты с "правильными" target community помещаются в bgp.mvpn.0 (общая) и ''instance-name''.mvpn.0 (по аналогии с l3vpn используются bgp.l3vpn.0 и ''instance-name''.inet.0)

В рамках этой family (MP-BGP MVPN family) существует еще 7 типов NLRI (далее называемых "Роутами"):

===Type 1. '''Intra'''-AS Iclusive MVPN Membership Discovery===
Отправляется всеми роутерами, участвующими в MVPN.

Если используется I-PMSI, эти роуты определяют куда автоматически строить p2mp lsp.

Эти роуты тэгируются атрибутом "PMSI Tunnel".
1 | 10.1.1.1:1 | 65412
Type | Sending PE's RD | Sending PE's AS

===Type 2. '''Inter'''-AS inclusive MVPN Membership Discovery===
Используются для поиска участников между PE-роутерами, находящимися в разных AS.
В книге на них забивается.

2 | 10.1.1.1:1 | 65412
Type | Sending PE's RD | Sending PE's AS

===Type 3. Selective MVPN Autodiscovery Route===
Отправляется PE-маршрутизатором, который, собственно, инициирует S-PMSI

3 | 10.255.170.100:1| 32 | 192.168.194.2 | 32 | 224.1.2.3 | 10.255.170.100
Type | Sending PE's RD | C-S Mask | C-S using S-PMSI | C-G Mask | C-G using S-PMSI | Sending PE's lo0

пример:
3:172.30.5.1:32767:32:172.17.17.1:32:239.0.0.1:172.30.5.1/240

===Type 4. Selective MVPN Autodiscovery Route for Leaf===
Отправляется заинтересованным в получении мультикаст-потока PE-роутером в ответ на получение Type 3.

4 (type) | <здесь идет этот самый type 3, который мы только что получили. Да, целиком. Длинный.> | <Тут наш lo0 ipaddress>
'''Немного резюмируем'''
Эти два типа (3, 4, т.е. selective MVPN autodiscovery) помогают строить S-PMSI. Эти роуты анонсируются PE источника мультикаста в ответ на роуты типов 6 и 7 (позже будут), которые, по существу, запрашивают присоединение к мультикаст-дереву (BGP-аналог PIM-JOIN'а).
Даже если PE источника узнаёт (из пришедшего роута типа 7), что удаленный PE получателя хочет получать определенный мультикаст-поток, он все равно посылает роут типа 3 как запрос к получателю на присоединение к S-PMSI. Роут типа 3 при этом тэгируется атрибутом PMSI Tunnel, позволяя PE-роутеру получателя узнавать подробности провайдерского туннеля (чтобы смочь присоединиться к нему).

Соответственно, в таблице <vrf-name>.mvpn.0 маршруты появятся только при использовании selective provider tunnel.
Пример:
4:3:172.30.5.1:32767:32:172.17.17.1:32:239.0.0.1:172.30.5.1:172.30.5.7/240

===Type 5. Source Active Autodiscovery===
Посылается PE-роутаром, который нашел у себя источник мультикаста, всем другим PE, участвующим в этом конкретном MVPN.
Отправляющий PE-роутер может узнать об источнике на своей стороне несколькими способами:
*Rsgister Messages
*MSDP
*Source Active Messages
*Directly Connected Source.
Нашел поток - объяви другим PE.

===Type 6. Shared Tree Join Route===

Когда PE получает от своего CE запрос на подключение к группе, то есть PIM join вида '''(*, G)''', он отправляет этот роут типа 6 другим PE, участвующим в данном MVPN. Ниже формат этого сообщения:

6 | 10.255.170.100:1 | 65000 | 32 | 10.12.53.12 | 32 | 224.1.2.3
Type | RD of Upstream PE | Upstream's AS | C-RP Mask | C-RP Address | C-G Mask | C-G

И, наконец...
===Type 7. Source Tree Join Route===
7 | 10.255.170.100:1 | 65000 | 32 | 10.12.53.12 | 32 | 224.1.2.3
Type | RD of Upstream PE | Upstream's AS | C-S Mask | C-S | C-G Mask | C-G

Отправляется PE-роутером (который сейчас станет получаетелем), получившим PIM-join (S, G) на vrf-интерфейсе (от клиента).
В чем разница с предыдущим типом 6? Там был (*, G) а здесь '''(S, G)'''.

То есть, в итоге что получается?
*Как только мы все настроили и закоммитили, каждый PE посылает каждому другому PE Type 1, чем заявляет свое участие в mvpn.

*Если PE находит у себя поток, то отправляет '''Type 5. Source Active Autodiscovery''' соседям - пусть знают, что есть такой источник, вещающий в такую-то группу.

*Если PE получил pim-join от CE на подключение к группе, то отправляет другим PE либо '''Type 6. Shared Tree Join Route''' если( *,G), либо '''Type 7. Source Tree Join Route''' если получил (S, G). И тогда...

*Если PE получил '''Type 6. Shared Tree Join Route''' или '''Type 7. Source Tree Join Route''', он понимает, что удаленный PE хочет от него получать трафик определенной группы. Тогда, в ответ генерируется '''Type 3. Selective MVPN Autodiscovery Route''', и идет к PE, приславшему Type [6,7]. И далее...

*Если PE, ранее отправивший Type[6-7], получает '''Type 3. Selective MVPN Autodiscovery Route''', он берет этот Type 3, и отправляет его обратно, только уже в виде Type 4 (вроде, тупо меняя поле "Type").

==Trees==
Дерево (provider-tunnel) нужно для передачи мультикаст трафика. Должно быть построено от PE, где регистрируется мультикаст от C-Source до удаленных PE, где расположены получатели мультикаста.

Разделяют 2 типа: Inclusive Trees, Selective Trees.

Можно использовать комбинацию, тогда для всего мультикаста будет использоваться Inclusive Trees, а для конкретных групп Selective Trees.

===Inclusive Trees===
Inclusive Tree - PE, при наличии у него мультикаста от источника, будет доставлять трафик от этого источника ко '''всем''' PE-получателям. Удобно, если все PE в данном vpn должны получать трафик.

Если мультикаст трафик должен доставляться лишь немногим удаленным PE, то этот способ слишком затратен по ресурсам/bandwith/etc...

Inclusive tree строится для всего мультикаст-трафика (то есть для всех групп) из данного VPN-сайта (для противопоставления есть Selective Tree, которые строятся: 1 группа = 1 tree).

====Signaling====
При включении VPN с использованием Inclusive Tree, каждый PE с каждым другим PE устанавливает Point-To-Multipoint LSP (где-то в начале книги было про то, как сделать это вручную. В данном же случае это делается автоматически, ибо работает MP-BGP с family mvpn). Причем не важно где будут источники, где получатели а где вообще ничего - все равно каждый участвующий в этом mvpn'е PE берет и устанавливает по одному p2mp lsp от себя ко всем соседям.

Получается, что если какой-либо PE не собирается быть источником, а планирует только получать трафик, то lsp, идущее от него к другим никогда не будет использоваться, но будет висеть и жрать ресурсы. Да, это так.

Есть способ на джуниперах отключить ненужное построение p2mp lsp от конкретных PE, если знаем, что PE никогда не будет вещать, а будет только получать. Но сути это не меняет.

'''Взгляд со стороны источника'''

Представим, что клиент-источник на сайте A (CE-1) использует PIM. Представим так же, что RP для данного PIM-домена настроена внутри VRF-Instance на PE, что является нормальной практикой.

Тогда CE начнет фигачить Register Message (в виде юникаста, до RP, т.е. до VRF в PE). Тогда-то и случится ситуация, что PE узнал о наличии потока из Register Message =)
А дальше повторяется алгоритм (см. выше). Т.е этот PE шлет Type 5, объявляя всем другим PE о том, что у него есть источник. Ну и т.д.

'''Взгляд со стороны получателя'''

Некий CE, собравшийся получать мультикаст-трафик, шлет обычный igmp join куда положено (например, Фред запустил VLC и подписался на IPTV-канал udp://@242.0.5.5:1234). Допустим, это Source Specific Join, т.е. "(S, G)". PE-роутер получателя конвертирует этот IGMP-join в Source Tree Join Route (Type 7) и посылает к PE-источнику. Когда PE, к которому подключен источник, получает этот Type 7 роут, он конвертирует его в обычный PIM (S, G) Join и посылает клиентскому DR (Designated Router), таким образом завершая построение мультикаст-дерева.

Аналогично работает и с Type 6, то есть когда прилетает (*, G) от CE.

На этом с сигналингом закончили, дальше начинается форвардинг.

====Forwarding====
* CE-источник посылает обычный мультикаст-пакет в сторону PE.
* PE его принимает, определяет в какую lsp совать, навешивает один mpls label (один!) и посылает в LSP. LSP до получателя имеется ввиду.
* На каком-то из P-роутеров этот пакет копируется и отправляется в два или более интерфейсов к двум или более PE (такова суть p2mp lsp). Если есть 2 получателя.
* Каждый получающий PE видит метку MPLS, снимает ее, сует пакет в нужный VRF, там уже по PIM видит в какой интерфейс направить этот пакет.

Таким образом пакет прошел по нашей сети и отправился клиенту, а клиент доставил его до Фреда. У Фреда появился первый заветный кадр видео в окне его VLC =)

====Config====
Пример настройки inclusive tree:
r1> show configuration routing-instances spoke-to-hub
provider-tunnel {
rsvp-te {
label-switched-path-template {
p2mp-mcast;
r1> show configuration protocols mpls label-switched-path p2mp-mcast
'''template;'''
'''p2mp;'''
bandwidth 30m;
hop-limit 5;
priority 5 5;
link-protection;

TE фичи навешиваются по желанию/необходимости. Для работы обязательны только: '''template, p2mp'''.

===Selective Tree===

Отдельное дерево будет построено для каждой из пар Source, Group.

'''Как работает'''

* Как только мы все настроили и закоммитили, каждый PE посылает каждому другому PE Type 1, чем заявляет свое участие в mvpn.
** Type 1 не содержит атрибута PMSI Tunnel, так что никаких p2mp lsp построено не будет до тех пор, пока кто-то не начнет просить поток.
* Допустим кто-то начал вещать. Получивший поток PE отсылает Type 5 Auto Discovery Route удаленным PE. Ну как и в прошлый раз.
* Дальше все как в прошлый раз - дальний PE получает от Фреда igmp join, конвертирует его в Type 7, посылает источническому PE.
* И теперь разница. Получив такой type 7, PE источника не начинает никуда ничего верещать. Ведь LSP-то не установлен. Теперь вступают в игру Type[3-4].
* PE источника (напомню, он сейчас имеет приходящий мультикаст поток, а так же знает, что удаленный PE выразил желание этот поток получать) посылает '''Type 3. Selective MVPN Autodiscovery Route''' ко всем PE.
* Только запросивший поток PE отвечает на это своим '''Type 4. Selective MVPN Autodiscovery Route for Leaf'''.
* Теперь PE1 строит свою p2mp lsp к тому, от которого пришел Type 4, и шлет PIM JOIN к клиентскому DR.
** Я понимаю, что рассматривается пример с одним получателем, и можно было бы построить простое p2p-lsp. А ну как кто-то еще пришлет такой же JOIN? Пусть уж лучше сразу будет построено p2mp.
* Теперь можно срать в LSP пакетами с мультикастом так же, как в прошлый раз (в случае с Inclusive Tree).
====Config====
Пример настройки:
r1> show configuration routing-instances spoke-to-hub
selective {
tunnel-limit 5;
group 239.0.0.1/32 {
source 172.31.64.0/21 {
rsvp-te {
label-switched-path-template {
selective-mcast;
threshold-rate 100000;
r1> show configuration protocols mpls label-switched-path selective-mcast
'''template;'''
'''p2mp;'''
bandwidth 60m;
hop-limit 5;
priority 5 5;
link-protection;

Если нет требования строить какой-то кастомный lsp, то можно указать дефолтный template:
set routing-instances 1 provider-tunnel selective group 239.0.0.1/32 source 172.31.64.0/21 rsvp-te label-switched-path-template '''default-template'''
При этом не в protocols mpls настраивать дополнительно ничего не нужно.

Для * вместо конкретного ip источника можно указать (для запросов (* , G)):
set routing-instances 1 provider-tunnel selective group 239.0.0.1/32 '''wildcard-source'''

Группы можно указывать диапазоном: ''group 239.0.0.0/24''

==MVPN Modes==
По дефолту MPVN работает в режиме '''SPT-only''' (shortest-path tree). В этом режиме активные источники буду изучены с помощью VPN source-active routes. source tree join '''(C-S, C-G)'''
При получении (C-S, C-G), PE сразу же такой join преобразует в Type7.

Также существует '''(RPT)-SPT mode'''. Тут используются shared tree join (С-*,С-G) запросы к RP.

Когда в режиме SPT-only от получателя прийдет (*, C-G) - PE-роутер ищет активный источник для группы. Если такой есть, то PE создает source tree customer multicast route [Type5], и отправляет его к PE с активным источником. На PE receiver приходит (*,G), которое транслируется в Type7 NLRI (S,G). К (S,G) добавляется community no-advertise и маршрут добавляется в таблицу.

Источник определяется MVPN's single-forwarder election. Этот подход позволяет определить одного передатчика для (C-S) [customer-source].
* Если активный unicast route к источнику идет через интерфейс, то этот маршрут используется как upstream mcast hop.
* Если активный unicast route к источнику находится в VPN, MVPN выбирает upstream mcast hop, основываясь на бОльшем IP в составе import community и локального master lo адреса.
Для SPT-only этого подхода достаточно. Для RTP-SPT нужно также добавить некоторые административные ограничения [приоритезацию] для исключения дублирования трафика по SPT и shared tree.

Алгоритм обработки C-join:
* на PE прилетел (C-*, C-G).
user@PE3> show pim join extensive instance vpna 224.1.1.1
Group: 224.1.1.1
Source: *
RP: 10.12.53.1
* PE генерирует Type6 и ставит его в <vrf>.mvpn.0. Type6 в качестве source ставит адрес RP.
user@PE3> show route table vpna.mvpn.0 detail | find 6:10.1.1.1

*RT и RD Type6 парсятся при lookup ip RP в <vrf>.inet.0
*Как только источник начинает вещать, ближайший к нему PE кладет маршрут Type5 в <vrf>.mvpn.0 таблицу.
*Type5, которые кладутся в <vrf>.mvpn.0, по MP-BGP передаются другим PE. (через RR или прямую IBGP)
*Удаленный PE теперь имеет Type5 и Type6 для (C-*, C-G) и теперь готов состряпать из этого Type7. RD для Type7 и Type6 будут одинковыми, если они получены от одного PE.
*Type7 устанавливается в <vrf>.mvpn.0 и передается другим PE. [в случае, если PE получает source tree C-join, то Type7 генерируется и расслылается автоматически и этому join не нужно проходить через предыдущие этапы].
*Если Type7 имеет RT, совпадающий с rt-import на Sender PE (рядом с source), то Sender PE ставит его в <vrf>.mvpn.0
*На Sender PE (рядом с source) Type7 транслируется в обычный C-join в рамках VRF. C-join в свою очередь добавляется на receiver PE в C-PIM database. И как я поняла по PIM распространяется на все PE в виде join. То есть в таблице <vrf>.mvpn.0 будут видны одни и те же маршруты, изученные по BGP и по PIM:
PE1> show route table vpna.mvpn.0 detail | find 7:10.1.1.1
7:10.1.1.1:1:65000:32:192.168.1.2:32:224.1.1.1/240 (2 entries, 2 announced)
'''*PIM Preference: 105'''
Next hop type: Multicast (IPv4)
Next-hop reference count: 30
State: <Active Int>
Age: 1d 2:19:04
Task: PIM.vpna
Announcement bits (2): 0-PIM.vpna 1-mvpn global task
AS path: I
Communities: no-advertise target:10.1.1.1:64
''' BGP Preference: 170/-101'''
Next hop type: Indirect
Next-hop reference count: 4
Source: 10.1.1.3
Protocol next hop: 10.1.1.3
Indirect next hop: 2 no-forward
State: <Secondary Int Ext>
Inactive reason: Route Preference
Local AS: 65000 Peer AS: 65000
Age: 53:27 Metric2: 1
Task: BGP_65000.10.1.1.3+179
Announcement bits (2): 0-PIM.vpna 1-mvpn global task
AS path: I
Communities: target:10.1.1.1:64
Import Accepted
Localpref: 100
Router ID: 10.1.1.3
Primary Routing Table bgp.mvpn.0
*Обычный C-Join на Sender PE обрабатывается как обычный pim join.
*finish

SPT-only mode не дает возможности использовать C-RP (customer-RP).

Небольшое пояснение: при (*,C-G) запросе, роутер должен узнать об активных источниках через Type5. Type5 может сгенерировать только MVPN PE роутер. Т.о. этот PE должен знать обо всех register messages.
Это произойдет только если:
*C-RP размещен на PE в MVPN.
*Между PE (в рамках MVPN) и C-RP настроен MSPD.

Если оба этих условия не пригодны для нашей сети, то можно работать с RPT-SPT.

'''Плюсы SPT-only:'''
- Проще работать с source-tree customer.
- Не нужно предпринимать никаких действия, чтобы не дублировался трафик при переключении с RPT на SPT.
- Проще control plane
- Проще обслуживание

'''Config'''
[edit routing-instances spoke-to-hub protocols mvpn]
+ mvpn-mode {
+ spt-only;

==Sender/Receiver site==
Каждый site mvpn можно настраивать как Sender или Receiver only. По дефолту site работает в режиме и sender и receiver.
*'''Sender-site''': не присоединяется к туннелям, анонсируемым с других PE
*'''Receiver-site''': не отправляет PMSI атрибуты.
Одновременно нельзя на одном site в конфете указать и sender и receiver.

==Config NG MVPN==
Топология в примере: L3VPN hub and spoke. + MVPN сверху, связность между site = full-mesh. Anycast RP на сети провайдера.

Приведен полный конфиг L3VPN, понятно, что protocols bgp, vrf-import, vrf-export и прочие настройки имею косвенное отношение к MVPN.

'''Config для R1:''' HUB, Anycast RP, Sender.

PE-PE MP-BGP [или PE<>RR] - добавляем inet-mvpn signaling:
[edit protocols bgp group rr]
family inet-mvpn {
signaling;
Добавляем p2mp LSP для I-PMSI и S-PMSI:
[edit protocols mpls]
label-switched-path mcast-p2mp-template {
template;
p2mp;
bandwidth 3m;
hop-limit 5;
priority 5 5;
link-protection;
label-switched-path mcast-selective-template {
template;
p2mp;
bandwidth 6m;
hop-limit 5;
priority 5 5;
link-protection;

mcast в отличие от inet трафика должен ходить не через hub, а должна быть full-mesh между всему site. Это правим route-target внутри protocol mvpn.

I-PMSI работает для всего mcast трафика, поэтому нет ограничения по group - source.

S-PMSI работает для конкретных групп, поэтому задается диапазон групп и source.

Данный mvpn-site - только с источником, поэтому ему задаем sender-site.
[edit routing-instances]
spoke {
instance-type vrf;
interface ge-0/0/0.312;
interface lo0.2;
provider-tunnel {
rsvp-te {
label-switched-path-template {
mcast-p2mp-template;
selective {
tunnel-limit 5;
group 239.0.0.1/32 {
source 172.31.64.0/21 {
rsvp-te {
label-switched-path-template {
mcast-selective-template;
threshold-rate 10000;
group 239.0.0.2/32 {
source 172.31.64.0/21 {
rsvp-te {
label-switched-path-template {
mcast-selective-template;
threshold-rate 10000;
vrf-import spoke-import;
vrf-export spoke-export;
vrf-table-label;
protocols {
bgp {
group ce {
export ce2-routes;
peer-as 64600;
as-override;
neighbor 192.168.0.46;
pim {
rp {
local {
address 172.30.5.253;
group-ranges {
239.0.0.0/24;

interface all;
mvpn {
sender-site;
mvpn-mode {
spt-only;
route-target {
import-target {
target target:54591:202;
export-target {
target target:54591:202;
В топологии в примере используется Anycast RP на сети провайдера, поэтому Lo выглядит след образом:
[edit interfaces lo0.2]
family inet {
address 172.30.5.10/32 {
primary;
preferred;
address 172.30.5.253/32;

'''Config для R7:''' SPOKE, Receiver.
PE-PE MP-BGP [или PE<>RR] - добавляем inet-mvpn signaling:
[edit protocols bgp group rr]
family inet-mvpn {
signaling;

Данный mvpn-site - только в receiver, поэтому ему задаем receiver-site.
[edit]
routing-instances {
spoke {
instance-type vrf;
interface ge-0/0/0.323;
interface lo0.1;
vrf-import spoke-import;
vrf-export spoke-export;
vrf-table-label;
protocols {
bgp {
group ce {
peer-as 64600;
as-override;
neighbor 192.168.0.90;
pim {
interface all;
mvpn {
receiver-site;
mvpn-mode {
spt-only;
route-target {
import-target {
target target:54591:202;
export-target {
target target:54591:202;

'''Виды provider-tunnels''':
> ingress-replication Ingress Replication Tunnel
> ldp-p2mp LDP point-to-multipoint LSP for flooding
> mdt Data MDT tunnels for PIM MVPN
> pim-asm PIM-SM provider tunnel
> pim-ssm PIM-SSM provider tunnel
> rsvp-te RSVP-TE point-to-multipoint LSP for flooding
> selective Selective tunnels

'''Пример использования selective-tunnels:'''
[edit routing-instances MVPN provider-tunnel]
selective {
group 224.7.7.0/24 {
wildcard-source {
rsvp-te {
label-switched-path-template {
mvpn; }}}}}
'''mvpn параметры внутри vrf''':
mvpn-join-load-balance MVPN Join Load Balancing Algorithm
traceoptions Trace options for BGP-MVPN
unicast-umh-election Upstream Multicast Hop election based on unicast route preference
receiver-site MVPN instance has sites only with multicast receivers
sender-site MVPN instance has sites only with multicast sources

Если топология для mvpn (например, full mesh) должна быть отличной от топологии для l3vpn (например, hub and spoke).
route-target Configure route-targets for MVPN routes

mvpn-mode MVPN mode of operation
> rpt-spt MVPN works in multicast RPT and SPT mode
> spt-only MVPN works in multicast SPT only mode (default mode)

==Monitoring==
show pim join instance MVPN extensive
show multicast route extensive instance MVPN
show route table MVPN.mvpn.0

На egress PE:
r7# run show mvpn neighbor inet
Instance : MVPN
MVPN Mode : SPT-ONLY
Neighbor I-P-tnl
172.30.5.1 RSVP-TE P2MP:172.30.5.1, 25759,172.30.5.1

r7# run show mvpn c-multicast inet
Instance : MVPN
MVPN Mode : SPT-ONLY
C-mcast IPv4 (S:G) Ptnl St
0.0.0.0/0:239.0.0.1/32
172.17.17.1/32:239.0.0.1/32 RSVP-TE P2MP:172.30.5.1, 25759,172.30.5.1 DS
0.0.0.0/0:239.5.5.1/32

- - - пояснение:
0.0.0.0/0:239.0.0.1/32 - Type 6 join (*,G)
0.0.0.0/0:239.5.5.1/32 - Typ6 6 join (*,G)
172.17.17.1/32:239.0.0.1/32 - Type 7 (S,G)

'''Проверка provider-tunnel'''
на ingress PE:
r7# run show rsvp session ingress
Ingress RSVP: 16 sessions
To From State Rt Style Labelin Labelout LSPname
172.30.5.7 172.30.5.1 Up 0 1 SE - 347858 '''172.30.5.7:172.30.5.1:32767:mvpn:MVPN'''

show route forwarding-table destination 224.7.7.7 extensive

=Multicast for Draft-Rosen VPNs=
Draft-rosen 6 - для ASM модели.

Draft-rosen 7 - для SSM модели.

Старый подход, где для сигнализации использовался PIM, для форвардинга - GRE-tunnels [Multipoint GRE (MP-GRE)].

MP-GRE - в отличие от обычного GRE, в качестве адреса назначения - ip multicast group [Пр.: 239.1.2.3]. А адрес источника - обычный unicast ip [зачастую просто адрес lo роутера].

Соответственно для одного VRF на всех PE должен быть определен один и тот же '''group-address'''.

Полностью построенное дерево для передачи трафика называется Multicast Distribution Tree ['''MDT'''].

Строится два MDT-дерева: 1. для сигналинга [default MDT], 2. для форвардинга [data MDT].

Через default MDT передается весь сигнальный трафик клиента. Более того, для установления Data MDT тоже используется Default MDT [до момента, пока не пришло оповещение, что построен более оптимальный туннель для передачи конкретного мультикаст потока].

Может работать как для ASM, так и для SSM модели.

При использовании '''ASM''' [draft-rosen 6] - в конфигурации ip dest для MP-GRE задаем адрес через ''vpn-group-address 232.0.0.1'' ------ Default MDT Address

При использовании '''SSM''' [draft-rosen 7] - в конфигурации ip dest для MP-GRE задаем адрес через ''provider-tunnel pim-ssm group-address 232.0.0.1''.

Комбинированный метод ASM + auto-discovery: ''provider-tunnel pim-asm instead''.
Описание для понимания: https://forums.juniper.net/t5/Junos/Please-help-confounded-by-Draft-Rosen-6-or-7/m-p/288183#M10101

==Config для ASM==
Обязательно нужно включить в конфигурацию:
*'''interface lo0.x''' - создаем новый unit, который запихиваем в
:*'''vrf interfaces'''
:*'''vrf protocols pim'''
:*IGP, BGP политики, где нужно
Внутри routing-instance:
*'''protocols pim interface''' - включить все интерфейсы, участвующие в pim.
*'''protocols pim mode sparse-dense''' - либо глобально, либо для каждого интерфейса.
*'''protocols pim group-address''' - на всех PE должен быть определен один и тот же group-address. Должен быть уникальным в рамках всей сети. [Пример: 239.1.1.1]
*'''protocols pim version 2'''- либо глобально, либо для каждого интерфейса.
*'''protocols pim rp local''' - для PE, которые выполняют роль RP. Либо можно использовать '''любой другой механизм задания RP''' (bootstrap, auto-rp,...). RP также может использоваться на стороне клиента.
*'''protocols pim rp static''' - на остальных PE, CE роутерах. (если используем не static rp, то остальные роутеры настраиваем в соответствие с методом)
*'''routing-options rib-groups''' - создание rib-groups. - опять же при необходимости.
*'''routing-instances instance-name protocols pim rib-group''' - для указания группы для RPF. [наверное] - при необходимости.

Не знаю насколько я правильно поняла, но: если используем только ''protocols pim group-address'', то этого должно быт достаточно для установления Default MDT.

Если хотим использовать комбинированный вариант ASM + auto-discovery = ''provider-tunnel pim-asm group-address 239.1.1.1'', то в конфиг нужно добавить ''protocols pim mvpn''.

Если используем SSM, то тоже конфигурируем связку: ''provider-tunnel pim-ssm group-address 239.1.1.1'', и в конфиг нужно добавить ''protocols pim mvpn''.

''protocols pim mvpn'' - служит для автоматического обнаружения других PE в рамках VRF.

Пример конфига [ASM, RP на стороне клиента, используем auto-rp]:
[edit routing-instances vrf-ospf protocols pim]
dense-groups {
224.0.1.39/32;
224.0.1.40/32;
}
vpn-group-address 239.1.1.1;
rp {
auto-rp discovery;
}
interface all {
mode sparse-dense;

==Config для MDT==
Data MDT строятся для более оптимальной передачи мультикаст трафика.

Используются '''mt-''' интерфейсы. Как для default, так и для data MDT.

Пример для ASM-модели
[edit routing-instances vrf-ospf protocols pim]
+ mdt {
+ threshold {
+ group 239.0.0.2/32 { - группа
+ source 0.0.0.0/0 { - любой источник [*]
+ rate 30000; - ограничение скорости [опционально]
+ tunnel-limit 5; - ограничение на кол-во туннелей [опционально]
+ group-range 239.0.0.0/24; - ограничение по группам [опционально]

=Дополнительная информация=
*[[Отказоустойчивость и оптимизация в MPLS]]
*[[Traffic engineering]]
*[[Реализация MPLS в ядре сети]]

VPLS

2021-07-15T18:32:52Z

Наталия Бобкова:

{{#description2: VPLS Forwarding. VPLS Signaling. Выделение меток в VPLS. Vlan в VPLS. Multihoming VPLS. Конфигурация VPLS. Траблшутинг VPLS. Информация для подготовки к экзаменам Juniper.}}
В L2VPN используются только каналы точка-точка, и нет возможности обеспечить связность точка-многоточка. Эту проблему решает - VPLS.

Для клиента сеть будет выглядеть как бродкастовый домен. ''Full-mesh'' между точками.

Для провайдера: набор каналов точка-точка.

В vpls соединениях точка-точка принято называть ''pseudo-wire''.

=Forwarding=
В обычном мире, не касаясь MPLS, когда хост посылает фрейм в свитч: свитч ''бродкастит'' и ''лернит''.

VPLS-instance работает как свитч, который тоже ''бродкастит'' и ''лернит''.

* На PE1 в VPLS прилетел фрейм, VPLS: запомнил какой mac, соотнес с портом: A -> int 1.
* PE1 флудит его во все интерфейсы. А '''pseudo-wire''', воспринимаем как интерфейс. Т.о. фрейм долетел до PE2.
* PE2 заучивает mac: A -> pseudo-wire 1 (''lsi interface'').
*Фрейм, пришедший с локального интерфейса, должен быть разослан '''всем''' PE.
{{note|text=Фрейм, пришедший с локального интерфейса флудится во все локальные интерфейсы и pseudo-wire.

Фрейм, который пришел от pseudo-wire (''lsi''), флудится только в локальные интерфейсы. Чтобы не было петли.}}

Когда прилетает фрейм с dest-mac уже известным, то он идет по уже заученному для него пути.

То есть с точки зрения форвардинга VPLS - один большой свитч!

Внутри VPLS происходит lookup по маку => должен быть включен tunnel-services.

=Signaling=
Pseudo-wire - строятся по LDP или BGP. В отличие от L2VPN, в VPLS - сигнализация по BGP имеет огромное приемущество.

==BGP==
BGP выполняет функцию signaling и auto-discovery. PE ищет какие PE законнектились в тот же VPLS и отправляет им NLRI.

Передается NLRI, аналогичный BGP L2VPN:
* label base
* label range
* site-id
* offset

То есть для работы VPLS в настройках BGP включаем тот же самый l2vpn signaling.

L2-circuit - это по сути метки (на выход, вход). В отличие от L2VPN каждому локальному интерфейсу назначать метку нет смысла, ведь внутри VPLS уже есть соответствие ''mac - interface''. Поэтому в VPLS метка должна была бы назначиться целиком на '''RI (per instance, per site)'''.

Но эта логика не правильная. =(

Learning mac-адресов! делает эту схему многоточкой!

Блок меток соответствует-выделяется '''удаленному site''', чтобы когда пакет придет на РЕ понимать с какого site он пришел. Это требуется, чтобы сделать правильный learning.

В остальном весь остальной процесс signaling аналогичен L2VPN.

Site-ID в данной схеме принципиального значения не имеет. Требуется только для PE для внутренних вычислений, поэтому можно просто выбрать и назначить site-id, или задать ''auto-site-id''.

==LDP==
Между PE требуется full-mesh.

В случае l2circuit указывали удаленный PE.

В VPLS, помимо всего прочего, потребуется добавить для всех удаленных PE remote-site-id ручками.

=Метки=
Как и у L2VPN в NLRI передается:
* label base (начальная)
* site-ID
* label range

Исходя из полученных данных PE вычисляет свою метку для связи с тем PE, кот переслал блок:
label = label base (remote) + site-ID (local) - 1 (offset) (remote)

=Инкапсуляция=
Ниже описанное касается CE-facing интерфейс.

Для обычного Ethernet с vlan должна стоять: '''vlan-vpls'''. Она подходит как для qinq, так и для 802.1q.

Можно ставить ее как на логический интерфейс, так и на физический.

Если это не единственный тип инкапсуляции на физическом интерфейсе, то лучше на нем сразу указать тип инкапсуляции: flexible-ethernet-services.

=Vlan=
В рамках vrf VPLS можно определять vlan для VPLS путем конфигурирования vlan-id | vlan-tags
*''vlan-id <vlan-id>'' - в VPLS будет работать только один указанный vlan-id
*''vlan-id none'' - у приходящего пакета будет сниматься vlan-id tag. У исходящего навешиваться тот vlan-id tag, который указан на исходящем из VPLS интерфейсе.
*''vlan-id all'' - используется с logical interface, на которых настроено двойное теггирование. При этом на выходе из VPLS outer-tag будет навешиваться (push), на входе в VPLS outer-tag будет сниматься (pop). В VPLS будут бегать маки с inner vlan-id.
*''vlan-tags inner <> outer <>'' - позволяет работать VPLS с двумя тегами.
{{note|text= Если в VPLS указывает vlan каким-то из способов, то на interface нельзя использовать input-vlan-map и output-vlan-map }}

Со стороны клиента: влан на разных site должен совпадать. Иначе связности не будет.

=+/-=
VPLS +:
*удобнее в трабшутинге
*в отличие от L2VPN не требует указания remote-site
*обеспечивает схему коммутации точка-многоточка

VPLS - :
*бродкаст домен => защита от петель между PE<>CE
:*STP на PE<>CE
:*ERP на CE
:*LAG на PE <> CE
:*Active/backup links on PE
:*Multihomed CE with two PEs.
*может передавать только ''ethernet''

=Configuration=
==BGP based VPLS==
Минимальный рабочий конфиг:

На всех роутерах:
*BGP-family:
[edit protocols bgp]
set family '''l2vpn signaling'''
*encapsulation vlan-vpls (как для LDP signalling, так и для BGP signaling):
[edit interfaces]
ge-0/0/1 {
encapsulation ''vlan-vpls|flexible-ethernet-services''
[edit interfaces ge-0/0/1 unit 804]
encapsulation '''vlan-vpls''';
vlan-id 804;

'''Lagavulin:'''
[edit routing-instances oak]
instance-type vpls;
vlan-id 804;
interface ge-0/0/0.804;
route-distinguisher 10.200.86.7:1313;
vrf-target target:1111:1313;
protocols {
vpls {
no-tunnel-services;
site ce4 {
site-identifier 1;

Дополнительные часто используемые параметры:
*'''connectivity-type permanent''' - вне зависимости от состояния интерфейсов - поднимет VPLS.
*'''mac-table-size 6000 packet-action drop''' - ограничение по макам в VPLS.
*'''site-range 8''' - ограничение по количеству site в рамках одного VPLS.
===Multihoming (BGP signaling)===
Используется для подключения одного site клиента к нескольким PE.

Только один PE будет активным и выбран в качестве designated forwarder, т.е. передавать трафик. Такой PE будет устанавливать с удаленным PE pseudo-wire.

Если что-то произойдет с активным PE, второй multihomed PE установит pseudo-wire до удаленного PE.

Удаленные PE, чтобы определить куда им все-таки нужно передавать трафик, используют процесс ''VPLS path-selection'':
#Если advertisement bit = 0, то эта NLRI отбрасывается.
#Далее выбор идет по наибольшему site-preference приоритету.
#Далее по меньшему RID.
#Далее по меньшему ip адресу BGP Peer.
Удаленный PE выбрал активный multihomed PE, назначив его designated VE (VPLS edge). И стал использовать только 1 NLRI. До такого designated VE удаленный PE и построит pseudo-wire.
{{note|text=Если требуется использовать multihoming для VPLS, то нужно учесть, что это будет работать только с BGP сигнализацией. '''Не LDP'''.}}

Настраиваем:
#Одинаковый site-id для multi homed PE.
#Разный RD для multi homed PE.
#Указать интерфейсы в VPLS.
#Включить multihoming.
#Если на сети используется схема, где один и тот же site растянут на 2 PE, оба PE имеют линки в сторону одного CE, то можно определять активный PE с помощью ''site-preference backup|primary''. Либо руками задавать site-preference. Backup-PE поднимет connections с удаленными PE только в случае отвала primary PE того же site.
#[В случае, если на одной PE несколько линков к CE]. Задаем active-interface. Если указываем ''any'', то будет выбран один из перечисленных ниже интерфейсов. Если указываем ''primary'', то активным сразу будет выбран явно заданный интерфейс. А остальные интерфейсы в порядке очереди будут использоваться при падении primary.

[edit routing-instances]
+ oak {
+ instance-type vpls;
+ vlan-id 200;
+ interface ge-0/0/0.200;
+ interface ge-0/0/1.200;
+ route-distinguisher 10.200.86.1:100;
+ vrf-target target:1111:100;
+ protocols {
+ vpls {
+ no-tunnel-services;
+ site blair
+ site-identifier 1;
+ '''multi-homing''';
+ '''site-preference primary'''';
+ '''active-interface primary''' ge-0/0/0.200;
+ interface ge-0/0/1.200;}}}}

==LDP based VPLS==
Также обязательным:
* instance-type vpls
* lo должен быть добавлен в ldp
* !!'''rt, rd - не обязательны'''!!

Есть несколько отличий:
* Вводится ''vpls-id''. Это просто идентификатор vpls. Аналогично virtual-circuit-id для l2vpn LDP signaling. То есть просто любое уникальное число.
* Вручную указываются соседи - удаленные PE.

oban> show configuration routing-instances fox
instance-type vpls;
interface ge-0/0/2.10;
vlan-id {all | vlan-id | none}
protocols {
vpls {
encapsulation-type ethernet;
no-tunnel-services;
vpls-id 9876;
neighbor 10.200.86.8; }}

Дополнительные часто используемые параметры:

*'''connectivity-type permanent''' - вне зависимости от состояния интерфейсов - поднимет VPLS.
*'''mac-table-size 6000 packet-action drop'''- ограничение по макам в VPLS.
*'''site-range 8''' - ограничение по количеству site в рамках одного VPLS.

===Multihoming (LDP signaling)===
Когда два PE, смотрят в сторону одного и того же CE, без настройки дополнительных протоколов можно настроить VPLS таким образом => один из PE настраиваем как primary, второй backup.

Настройки делаются на '''удаленных PE'''. К neighbor добавляется backup PE:
...
protocols {
vpls {
neighbor 10.200.86.8;
backup-neighbor 10.200.86.13
''revert-timer 100'' }}

На удаленном PE backup роутер будет находиться в статусе: ''BK -- Backup connection''.

А если в конфиг к backup-neighbor добавить еще и ''standby'', то на удаленных PE он будет болтаться в статусе: ''ST -- Standby connection''.
А сам backup роутер будет устанавливать сессию с удаленным PE (State = Up)

=Troubleshooting=
lagavulin> show vpls connections
Instance: oak
Local site: '''ce4 (1)'''
connection-site Type St Time last up # Up trans
'''2''' rmt '''Up''' Nov 10 03:21:50 2016 1
Remote PE: 10.200.86.3, Negotiated control-word: No
''Incoming label: '''262146''', Outgoing label: '''262145''' ''
Local interface: '''lsi.1049088''', Status: Up, Encapsulation: VPLS
Description: Intf - vpls oak local site 1 remote site 2
'''3''' rmt '''Up''' Nov 10 03:27:12 2016 1
Remote PE: 10.200.86.9, Negotiated control-word: No
''Incoming label: '''262147''', Outgoing label: '''262145''' ''
Local interface: '''lsi.1049089''', Status: Up, Encapsulation: VPLS
Description: Intf - vpls oak local site 1 remote site 3

lagavulin> show route table oak.l2vpn.0 detail
oak.l2vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
10.200.86.3:1313:2:1/96 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 10.200.86.3:1313
Source: 10.200.86.3
Protocol next hop: 10.200.86.3
Age: 15:30 Metric2: 1
Task: BGP_1111.10.200.86.3+50784
Communities: target:1111:1313 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
Label-base: 262145, range: 8
Localpref: 100
Router ID: 10.200.86.3
Primary Routing Table bgp.l2vpn.0
10.200.86.7:1313:1:1/96 (1 entry, 1 announced)
*L2VPN Preference: 170/-101
Next hop type: Indirect
Next-hop reference count: 2
Protocol next hop: 10.200.86.7
Indirect next hop: 0 -
Age: 27:51 Metric2: 1
Task: oak-l2vpn
Communities: Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
Label-base: 262145, range: 8, status-vector: 0x18
10.200.86.9:1313:3:1/96 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 10.200.86.9:1313
Source: 10.200.86.9
Protocol next hop: 10.200.86.9
Local AS: 1111 Peer AS: 1111
Age: 10:08 Metric2: 1
Task: BGP_1111.10.200.86.9+59111
Communities: target:1111:1313 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
Label-base: 262145, range: 8
Localpref: 100
Router ID: 10.200.86.9
Primary Routing Table bgp.l2vpn.0

Как посмотреть маки:
lagavulin> show route forwarding-table vpn oak
lagavulin> show vpls mac-table instance oak

=Дополнительная информация=
*[[L2VPN]]
*[[EVPN]]
*[[Реализация MPLS в ядре сети]]

L2VPN

2021-07-15T18:32:08Z

Наталия Бобкова: /* Stitching */

{{#description2: L2VPN Martini (LDP). L2VPN Kompella (BGP). L2VPN Stitching. Конфигурация L2VPN. Траблшутинг L2VPN. Информация для подготовки к экзаменам Juniper.}}

ISP предоставляет только транспорт. Маршрутизация ложится на клиента.

Обе схемы работают одинаково с точки зрения forwarding (используют одинаковую инкаспуляцию). Разница только в signaling (control plane)- BGP vs LDP.

Martini - даже нет понятия VPN, это просто объединение 2х точек.

L2VPN нуждаются в BGP route refresh, без разрыва BGP сессии. Эта функция автоматически включается для L2VPN, дополнительных настроек не требует.
==Martini (LDP)==
L2 circuit (RFC 4447)

===Signaling===
На PE2 int 1 приходит l2-пакет. Пакет нужно туннелировать. Но если просто отправить пакет, то на PE1: не понятно что делать с пакетом. Поэтому при передаче через туннель нужно добавить 2 метки. Верхняя, чтобы передать по туннелю, нижняя связана с интерфейсом.
* Каждый PE каждому интерфейсу выделяет метку (VC label).
* Приходящие пакеты будут сразу обрабатываться по mpls.0: 40 pop -> int 1, 50 pop -> int 2, 60 pop -> int 3.
* Как только сконфигурирован ''l2circuit'', интерфейсу выделена метка и записана в mpls.0.
* Cо стороны PE1 (ingress) - mpls.0: int 1 push 40 push 20 -> P (резолв LDP соседа из inet.3), int 3 push 60 push 20 -> P.

PE1 должен получить информацию о метках, которые нужно назначать. Как??

* Для передачи используется LDP сессия PE1 <> PE2, в конфигурации задано куда строить LDP туннель. Помним, что по умолчанию LDP поднимает сессии только с непосредственно подключенными соседями.
* Метки (40, 50, 60) передали от PE2 к PE1.
* PE1 должен определить какая метка какому интерфейсу соответствует. Этот параметр задаем руками. '''Virtual curcuit-ID (VCI)''' - должен быть уникальным для пары устройств, размер 4 байта. VCI передается вместе с метками.

Дополнительно передается:
* инкапсуляция, которая должна быть одинаковой с обоих концов l2curcuit
* vlan-id - одинаковый (в Cisco может быть одинаковым)
* MTU - одинаковый, задается только для сигналинга, не имеет практического значения.
Для корректной работы:
*Между PE должна быть LSP (LDP или RSVP)
*Lo интерфейсы PE должны быть добавлены в [protocols ldp]

'''BGP Autodiscovery'''
*FEC 129 BGP autodiscovery for VPWS requires the ''l2vpn-id, source-attachment-identifier'', and ''target-attachment-identifier'' statements.
*Kompella Layer 2 VPNs require the ''site-identifier'' and ''remote-site-id statements''.

===Forwarding===
Фрейм: ip(1500) + l2 header(18) + CW-control word (4) + mpls int (4) + mpls tunnel (4) - это минимальный вариант, но он уже получается большой => стоит ставить MTU с запасом ~1570 или больше.

Форвардинг строится только на метках mpls.0. Внутри сети провайдера пакет передается в 2ми метками (туннельная и интерфейсная).

Мак-адреса не изучаются. Вообще фрейм просто передается тупо и все.

Circuit - это по сути 2 метки: на вход (incoming), на выход (outgoing).

Пример (часть ненужных полей в выводе удалена):
lagavulin> show route table l2circuit.0 detail
l2circuit.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
'''10.200.86.3:CtrlWord:4:550:Local/96''' (1 entry, 1 announced)
*L2CKT Preference: 7
Next hop type: Indirect
Next hop: 192.168.86.1 via ge-0/0/0.30 weight 0x1, selected
'''Label-switched-path lagavulin-to-oban'''
'''Label operation: Push 300592'''
Protocol next hop: 10.200.86.3
Age: 41:24 Metric2: 4
Announcement bits (1): 0-LDP
AS path: I
VC Label '''299968''', MTU 9000, VLAN ID 550
10.200.86.3:CtrlWord:4:550:Remote/96 (1 entry, 1 announced)
*LDP Preference: 9
Next hop type: Discard
Age: 37:49
Announcement bits (1): 1-l2 circuit
AS path: I
VC Label '''300064''', MTU 9000, VLAN ID 550

*300064 - push VC label for that destination (метка для интерфейса)
*300592 - push MPLS label (для LSP туннеля)
*299968 - роутер будет ожидать для данного circuit пакет с этой меткой

===Configuration===
[edit interfaces ge-0/0/0]
encapsulation flexible-ethernet-services;
[edit interfaces ge-0/0/0]
unit 560 {
description l2-to-lagavulin;
encapsulation vlan-ccc;
vlan-id 560;}
[edit protocols l2circuit neighbor 10.200.86.7]
interface ge-0/0/0.560 {
virtual-circuit-id 560;
description l2-to-lagavulin;
mtu 9000;}
[edit protocols ldp]
interface Lo0.0
{{note|text=Для ссс-инкапсуляции зарезервирован диапазон 512-4094}}
Кстати, можно объединять интерфейсы между собой на одном роутере.
[edit protocols l2circuit local-switching]
interface ge-0/0/1.200
end-interface
interface ge-0/0/3.200

===Verification===
Можно смотреть только состояние l2circuit connection. =(
Если исключить всякие тупые ошибки, типа mtu mismatch, ненастроенный сигналинг с двух сторон и т.п., то в основном проблемы сводятся к проблемам с обменом метками между PE. В таком случае проверяем:
* LDP соседство
* LDP database
* Наличие Lo в inet.3 и т.д.
Если control plane поднялся:
* Можем смотреть только обмен пакетами на интерфейсе.
* Поднимать l3 интерфейсы и смотреть свзяность через l2circuit.
* Если физически нет возможности поднять l3, то можно задействовать logical-tunnel.

===psn-tunnel-endpoint===
Строит туннель до адреса, отличного от LDP соседа.

*PE1 lo = 1.1.1.1
*PE2 lo = 2.2.2.2 primary, 10.2.2.2 secondary
2.2.2.2 - LDP LSP, 10.2.2.2 - RSVP LSP.

Если хотим построить l2circuit, который пойдёт по RSVP LSP, достаточно просто в конфиге на PE указать ''psn-tunnel-endpoint'':
set protocols l2circuit neighbor 2.2.2.2 interface ge-0/0/0.10 psn-tunnel-endpoint 10.2.2.2
set protocols l2circuit neighbor 2.2.2.2 interface ge-0/0/0.10 virtual-circuit-id 10
set protocols l2circuit neighbor 2.2.2.2 interface ge-0/0/0.20 virtual-circuit-id 20

ge-0/0/0.20 - будет использовать для построения LDP LSP

ge-0/0/0.10 - будет использовать для построения RSVP LSP. лукап в inet.3 будет делаться для 10.2.2.2.

psn-tunnel-endpoint - не обязательно адрес именно на loopback.

==Kompella (BGP)==

[[Файл:Kireeti Kompella.jpg|thumb|справа|альт=Kireeti Kompella|Компелла. Собственной персоной!]]

Цель - создать полноценный VPN. В l2circuit используется LDP-full-mesh.

Для Kompella используется сигнализация на основе BGP, можно соорудить full-mesh iBGP, можно использовать RR.

* Для клиента создается '''отдельный RI'''.
* В него добавляются локальные интерфейсы клиента и указывается с каким удаленным роутером RI будет соединяться. Router-ID - не очень надежно, т.к. его можно заменить, и в таком случае придется переделывать все RI для клиента по всей сети. Поэтому привязку сделали по '''site-id''' - задаются вручную, определяют схему коммутации между роутерами (в рамках RI).
* Метка назначается каждому '''локальному интерфейсу''', который ассоциирован с site ('''per interface''').
* Роутеры между собой обмениваются выделенными метками, чтобы удаленные site знали push какой метки делать, чтобы достичь нужного site. Набор меток - новый NLRI - '''family l2vpn signaling'''.
* У каждого клиента также присутствует свой идентификатор - route-target.

LSP между PE должна быть предустановлена, можно использовать как LDP так и RSVP.

===L2vpn signaling и выделение меток===
Алгоритм выделения меток был оптимизирован, но для лучшего понимая как и зачем, рассмотрим этапы его становления. =)

Изначально, исходя из схемы, рассмотрим что требуется передавать между PE, на примере того, что передаст PE1:
*метки:
:* 102 -> site 2
:* 103 -> site 3
:* 104 -> site 4
*local site-id:
:* site-id = 1

*PE2 видит:
Я - site 2. Site 1 ассоциирован с int 1. Site 1 прислал, что для отправки пакета ему, я должен сделать push 102 => int 1: push 102 push 50 (LSP до PE1) резолвим next-hop для PE1 в inet.3))

*PE3 видит:
Я - site 3. Site 1 ассоциирован с int 1. Site 1 прислал, что для отправки пакета ему, я должен сделать push 103 => int 1: push 103 push 60.

То есть все PE получают от site 1 '''все''' метки, хотя им нужна всего одна, которая соответствует его site.

Kompella решил, что это излишняя инфа и что достаточно пересылать только метки, не указывая каким site они соответствуют. Просто метки будут располагаться ровно в том порядке, в котором они предназначены удаленным site.
101 - 1
102 - 2
103 - 3
...

В таком случае важно следить, чтобы site имели номера один за одним, блок меток тогда будет - непрерывный.

Если на сети будет так: PE1 - site 1, PE2 - site 50, то PE1 будет вынужден выделить метки [1, ..., 50], хотя требуется только 1 и 50. Те site, которые пропускаются, для них будут созданы фейковые метки 2, 3, ..., 49, но метки использоваться не будут.

PE2 получит:
102
103
104
и выберет для себя 103, что будет не правильным поведением.

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

В итоге от PE2 будет такое распределение меток:
int 1 (site 1) - 201 label
int 2 (site 3) - 203 label
int 3 (site 4) - 204 label
202 label - выделена, но не связана ни с каким интерфейсом.

И будет передан такой NLRI:
201
202
203
204
site-id 2

В Juniper выделен отдельный блок (для Kompella), начиная с 800000, в рамках 1 PE метки не повторяются, должны быть уникальными.

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

В итоге в NLRI передается:
* label base (начальная)
* site-ID
* label range

Исходя из полученных данных PE вычисляет свою метку для связи с тем PE, кот переслал блок:
label = label base (remote) + site-ID (local) - 1 (offset) (remote)

Данная метка заносится в mpls.0

Т.о. получается, что каждый PE хранит у себя одну метку, а не кучу лишних.

Когда добавляется еще один site:
site-5: создал RI, сгенерировал NLRI, NLRI проанонсировался остальным PE, через RR. PE1 получил NLRI, понял, что появился site 5, требуется построить до него туннель, посмотрел какую метку push в сторону site 5 - все нормально.

PE5 получил NLRI всех PE от RR, начинает строить до них туннели. Для site 1 - возьмет 105 метку, которой в блоке нет, это понятно по label range. Что делать?

PE1, когда был получен NLRI от PE5, должен изменить NLRI, но метка 105 возможно будет уже занята для других целей. И + уже построенные туннели должны буду заново создаться, т.к. прилетит новый NLRI.

Поэтому, PE1 не меняет текущий блок, а добавляет к нему новый блок, тогда NLRI ('''конечный вариант'''):
* label base = 110
* site-id = 1
* label-range = 3
* '''label offset = 5''' - равен начальному site-ID, которому выделена первая метка блока.

Выглядит так: 10.200.86.1:1212:1:3/96:
* 10.200.86.1:1212 - RD
* 1 - site-id
* 3 - offset
* /96 - mask

L2 extended community содержит информацию об MTU: MTU, сконфигурированное PE-CE линке на отправляющем PE. Т.к. на L2 участке нет места фрагментации, то PE, получивший NLRI с не совпадающим MTU, проигнорирует такой NLRI.

*vlan-id = [0 - 511] - обычные vlan-tagged interfaces
*vlan-id = [512 - 4094] - специальные, для ccc-encapsulation.
По факту в настройки vlan-ccc с vlan-id < 512 у меня проблем не возникало.

В случаях, когда на одном роутере подключены 2 site клиента, которые также требуется соединить между собой, можно просто внутри VRF разным интерфейсам назначаем разные site-ID. В этом случае просто для каждого site будет создан свой NLRI. Так тоже можно.

[[Файл:l2vpn_labels.png]]

===Configuration===
blair# top show | compare
[edit interfaces ge-0/0/0]
encapsulation flexible-ethernet-services;
unit 601 {
encapsulation vlan-ccc;
vlan-id 601;
}
[edit protocols bgp group internal]
family l2vpn {
signaling;

[edit routing-instances]
fox-services {
instance-type l2vpn;
interface ge-0/0/0.600;
interface ge-0/0/0.601;
route-distinguisher 10.200.86.1:1212;
vrf-target target:1111:1212;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site blair {
site-identifier 1;
interface ge-0/0/0.600 {
remote-site-id 9;
}
interface ge-0/0/0.601 {
remote-site-id 4;

tormore:
fox-services {
instance-type l2vpn;
interface ge-0/0/0.850;
route-distinguisher 10.200.86.9:1212;
vrf-target target:1111:1212;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site tormore {
site-identifier 9;
interface ge-0/0/0.850 {
remote-site-id 1;

===Verification===
blair> show l2vpn connections
Instance: fox-services
Local site: blair (1)
connection-site Type St Time last up # Up trans
4 rmt '''Up''' Nov 7 14:49:02 2016 1
Remote PE: 10.200.86.4, Negotiated control-word: Yes (Null)
Incoming label: '''800001''', Outgoing label: '''800000'''
Local interface: '''ge-0/0/0.601''', Status: Up, Encapsulation: VLAN
9 rmt '''Up''' Nov 7 17:47:21 2016 1
Remote PE: 10.200.86.9, Negotiated control-word: Yes (Null)
Incoming label: '''800002''', Outgoing label: '''800004'''
Local interface: '''ge-0/0/0.600''', Status: Up, Encapsulation: VLAN

blair> show route advertising-protocol bgp 10.200.86.9 detail
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 10.200.86.1:1212:1:3/96 (1 entry, 1 announced)
BGP group internal type Internal
Route Distinguisher: 10.200.86.1:1212
Label-base: 800000, range: 2, status-vector: 0x0
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1111] I
Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
* 10.200.86.1:1212:1:9/96 (1 entry, 1 announced)
BGP group internal type Internal
Route Distinguisher: 10.200.86.1:1212
Label-base: 800002, range: 2, status-vector: 0x0
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1111] I
Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100

blair> show route receive-protocol bgp 10.200.86.9 detail table fox-services.l2vpn.0
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 10.200.86.9:1212:9:1/96 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 10.200.86.9:1212
Label-base: 800004, range: 2, status-vector: 0x0
Nexthop: 10.200.86.9
Localpref: 100
AS path: I
Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100

blair> show route table bgp.l2vpn.0 detail
bgp.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
10.200.86.4:1212:4:1/96 (1 entry, 0 announced)
*BGP Route Distinguisher: 10.200.86.4:1212
Source: 10.200.86.4
Protocol next hop: 10.200.86.4
Age: 3:01:31 Metric2: 1
Communities: '''target:1111:1212''' Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
Import Accepted
Label-base: '''800000''', range: 2, status-vector: 0x0
Localpref: 100
Router ID: 10.200.86.4
Secondary Tables: ''fox-services.l2vpn.0''
10.200.86.9:1212:9:1/96 (1 entry, 0 announced)
*BGP Route Distinguisher: 10.200.86.9:1212
Source: 10.200.86.9
Protocol next hop: 10.200.86.9
Age: 3:12 Metric2: 1
Communities: '''target:1111:1212''' Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
Import Accepted
Label-base: '''800004''', range: 2, status-vector: 0x0
Localpref: 100
Router ID: '''10.200.86.9'''
Secondary Tables: ''fox-services.l2vpn.0''

tormore> show route receive-protocol bgp 10.200.86.1 table fox-services.l2vpn.0 detail
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 10.200.86.1:1212:1:3/96 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 10.200.86.1:1212
Label-base: 800000, range: 2, status-vector: 0x0
Nexthop: 10.200.86.1
Localpref: 100
AS path: I
Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
* 10.200.86.1:1212:1:9/96 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 10.200.86.1:1212
Label-base: 800002, range: 2, status-vector: 0x0
Nexthop: 10.200.86.1
Localpref: 100
AS path: I
Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100

'''Forwarding'''
Только метки и ничего больше! 1 метка для L2VPN, одна для передачи через LSP.

Ingress:
blair> show route table fox-services.l2vpn.0 detail
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.200.86.9:1212:9:1/96 (1 entry, 1 announced)
*BGP Route Distinguisher: 10.200.86.9:1212
Source: 10.200.86.9
Protocol next hop: 10.200.86.9
Age: 35:59 Metric2: 1
Announcement bits (1): 0-fox-services-l2vpn
Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
Import Accepted
Label-base: '''800004''', range: 2, status-vector: 0x0
Localpref: 100
Router ID: 10.200.86.9
Primary Routing Table bgp.l2vpn.0

blair> show route table fox-services.l2vpn.0
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
...
'''10.200.86.9:1212:9:1/96'''
*[BGP/170] 00:37:40, localpref 100, from 10.200.86.9
AS path: I
> to 192.168.86.25 via ge-0/0/0.110, '''label-switched-path blair-to-tormore'''

blair> show rsvp session name blair-to-tormore detail
Ingress RSVP: 2 sessions
10.200.86.9
From: 10.200.86.1, LSPstate: Up, ActiveRoute: 0
LSPname: blair-to-tormore, LSPpath: Primary
LSPtype: Static Configured
Resv style: 1 FF, Label in: -, Label out: '''301168'''

На транзитных будет swap и pop с метками для LSP.

Egress:
tormore> show route label 800004
mpls.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
'''800004''' *[L2VPN/7] 00:05:53
> via ge-0/0/0.850, Pop Offset: 4

=Stitching=
Для ститчинга VPN можно использовать ''iw-interface'' или ''lt-interface''.

В конфиге iw-interface можно задать только инкапсуляции:
ethernet-ccc Ethernet for a cross-connect
frame-relay-ccc Frame Relay DLCI for CCC
ppp-ccc Serial PPP device for a cross-connect
vlan-ccc 802.1q tagging for a cross-connect
Соответственно он работает только для ститчинга L2VPN (разных типов) между собой.

Если хочется объединить L2VPN+VPLS, или L2VPN+L3VPN, то это делается при помощи ''lt-interface''.

==L2VPN BGP (Kompella)==
[[Файл:L2VPN_stitching.png|1024px]]

Можно объединить два L2VPN, используя '''stitching''' в виде '''interworking interface''' (или иногда используют ''logical-tunnel'', кот требует физического включения на оборудовании и специальную плату):
*задаем interface iw.0 внутри [edit interfaces], encapsulation и vlan-id должны быть как и для удаленных концов VPN
[interfaces]
iw0 {
unit 0 {
encapsulation vlan-ccc;
vlan-id 10;
peer-unit 1;}
unit 1 {
encapsulation vlan-ccc;
vlan-id 10;
peer-unit 0; }}
*создаем RI, которые нужно будет скрепить между собой, добавляя в них interface iw0:
[routing-instances]
bear {
instance-type l2vpn;
interface iw0.1;
route-distinguisher 10.200.86.5:999;
vrf-target target:1111:999;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site dalw {
site-identifier 5;
interface iw0.1 {
remote-site-id 8; }}}}}
fox {
instance-type l2vpn;
interface iw0.0;
route-distinguisher 10.200.86.5:8765;
vrf-target target:1111:8765;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site dalw {
site-identifier 5;
interface iw0.0 {
remote-site-id 3; }}}}}}
*включаем l2iw protocol:
[protocols]
l2iw;
{{note|text=При выключении protocols l2iw наш ститчинг проложит работать. После выключения и перезагрузки роутера - перестанет работать. Работоспособность восстановится только после повторного включения l2iw.}}
Проверяем:
dalwhinnie> show l2vpn connections
Instance: bear
Local site: dalw (5)
connection-site Type St Time last up # Up trans
8 rmt Up Feb 9 12:52:35 2017 1
Remote PE: 10.200.86.8, Negotiated control-word: Yes (Null)
Incoming label: 800005, Outgoing label: 800006
Local interface: iw0.1, Status: Up, Encapsulation: VLAN
Instance: fox
Local site: dalw (5)
connection-site Type St Time last up # Up trans
3 rmt Up Feb 9 12:52:35 2017 1
Remote PE: 10.200.86.3, Negotiated control-word: Yes (Null)
Incoming label: 800006, Outgoing label: 800006
Local interface: iw0.0, Status: Up, Encapsulation: VLAN

==L2VPN LDP (Martini)==
iw interface и протокол l2iw - задаются аналогично, конфигурация l2circuit:
[protocols l2circuit]
neighbor 10.200.86.3 {
interface iw0.0 {
virtual-circuit-id 10;
encapsulation-type ethernet-vlan; }}
neighbor 10.200.86.8 {
interface iw0.1 {
virtual-circuit-id 10;
encapsulation-type ethernet-vlan;}}}

dalwhinnie> show l2circuit connections
Neighbor: 10.200.86.3
Interface Type St Time last up # Up trans
iw0.0(vc 10) rmt Up Feb 11 15:51:15 2017 1
Remote PE: 10.200.86.3, Negotiated control-word: Yes (Null)
Incoming label: 299872, Outgoing label: 300832
Negotiated PW status TLV: No
Local interface: iw0.0, Status: Up, Encapsulation: VLAN
Neighbor: 10.200.86.8
Interface Type St Time last up # Up trans
iw0.1(vc 10) rmt Up Feb 11 15:51:16 2017 1
Remote PE: 10.200.86.8, Negotiated control-word: Yes (Null)
Incoming label: 299888, Outgoing label: 300128
Negotiated PW status TLV: No
Local interface: iw0.1, Status: Up, Encapsulation: VLAN

==Kompella + Martini==
Опять же interface iw0 и protocols l2iw - такие же.
[protocols l2circuit]
neighbor 10.200.86.3 {
interface iw0.0 {
virtual-circuit-id 10;
encapsulation-type ethernet-vlan; }}
[routing-instances bear]
instance-type l2vpn;
interface iw0.1;
route-distinguisher 10.200.86.5:999;
vrf-target target:1111:999;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site dalw {
site-identifier 5;
interface iw0.1 {
remote-site-id 8;}}}}}

=Дополнительная информация=
*[[VPLS]]
*[[EVPN]]
*[[Реализация MPLS в ядре сети]]

L2VPN

2021-07-15T18:31:51Z

Наталия Бобкова:

{{#description2: L2VPN Martini (LDP). L2VPN Kompella (BGP). L2VPN Stitching. Конфигурация L2VPN. Траблшутинг L2VPN. Информация для подготовки к экзаменам Juniper.}}

ISP предоставляет только транспорт. Маршрутизация ложится на клиента.

Обе схемы работают одинаково с точки зрения forwarding (используют одинаковую инкаспуляцию). Разница только в signaling (control plane)- BGP vs LDP.

Martini - даже нет понятия VPN, это просто объединение 2х точек.

L2VPN нуждаются в BGP route refresh, без разрыва BGP сессии. Эта функция автоматически включается для L2VPN, дополнительных настроек не требует.
==Martini (LDP)==
L2 circuit (RFC 4447)

===Signaling===
На PE2 int 1 приходит l2-пакет. Пакет нужно туннелировать. Но если просто отправить пакет, то на PE1: не понятно что делать с пакетом. Поэтому при передаче через туннель нужно добавить 2 метки. Верхняя, чтобы передать по туннелю, нижняя связана с интерфейсом.
* Каждый PE каждому интерфейсу выделяет метку (VC label).
* Приходящие пакеты будут сразу обрабатываться по mpls.0: 40 pop -> int 1, 50 pop -> int 2, 60 pop -> int 3.
* Как только сконфигурирован ''l2circuit'', интерфейсу выделена метка и записана в mpls.0.
* Cо стороны PE1 (ingress) - mpls.0: int 1 push 40 push 20 -> P (резолв LDP соседа из inet.3), int 3 push 60 push 20 -> P.

PE1 должен получить информацию о метках, которые нужно назначать. Как??

* Для передачи используется LDP сессия PE1 <> PE2, в конфигурации задано куда строить LDP туннель. Помним, что по умолчанию LDP поднимает сессии только с непосредственно подключенными соседями.
* Метки (40, 50, 60) передали от PE2 к PE1.
* PE1 должен определить какая метка какому интерфейсу соответствует. Этот параметр задаем руками. '''Virtual curcuit-ID (VCI)''' - должен быть уникальным для пары устройств, размер 4 байта. VCI передается вместе с метками.

Дополнительно передается:
* инкапсуляция, которая должна быть одинаковой с обоих концов l2curcuit
* vlan-id - одинаковый (в Cisco может быть одинаковым)
* MTU - одинаковый, задается только для сигналинга, не имеет практического значения.
Для корректной работы:
*Между PE должна быть LSP (LDP или RSVP)
*Lo интерфейсы PE должны быть добавлены в [protocols ldp]

'''BGP Autodiscovery'''
*FEC 129 BGP autodiscovery for VPWS requires the ''l2vpn-id, source-attachment-identifier'', and ''target-attachment-identifier'' statements.
*Kompella Layer 2 VPNs require the ''site-identifier'' and ''remote-site-id statements''.

===Forwarding===
Фрейм: ip(1500) + l2 header(18) + CW-control word (4) + mpls int (4) + mpls tunnel (4) - это минимальный вариант, но он уже получается большой => стоит ставить MTU с запасом ~1570 или больше.

Форвардинг строится только на метках mpls.0. Внутри сети провайдера пакет передается в 2ми метками (туннельная и интерфейсная).

Мак-адреса не изучаются. Вообще фрейм просто передается тупо и все.

Circuit - это по сути 2 метки: на вход (incoming), на выход (outgoing).

Пример (часть ненужных полей в выводе удалена):
lagavulin> show route table l2circuit.0 detail
l2circuit.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
'''10.200.86.3:CtrlWord:4:550:Local/96''' (1 entry, 1 announced)
*L2CKT Preference: 7
Next hop type: Indirect
Next hop: 192.168.86.1 via ge-0/0/0.30 weight 0x1, selected
'''Label-switched-path lagavulin-to-oban'''
'''Label operation: Push 300592'''
Protocol next hop: 10.200.86.3
Age: 41:24 Metric2: 4
Announcement bits (1): 0-LDP
AS path: I
VC Label '''299968''', MTU 9000, VLAN ID 550
10.200.86.3:CtrlWord:4:550:Remote/96 (1 entry, 1 announced)
*LDP Preference: 9
Next hop type: Discard
Age: 37:49
Announcement bits (1): 1-l2 circuit
AS path: I
VC Label '''300064''', MTU 9000, VLAN ID 550

*300064 - push VC label for that destination (метка для интерфейса)
*300592 - push MPLS label (для LSP туннеля)
*299968 - роутер будет ожидать для данного circuit пакет с этой меткой

===Configuration===
[edit interfaces ge-0/0/0]
encapsulation flexible-ethernet-services;
[edit interfaces ge-0/0/0]
unit 560 {
description l2-to-lagavulin;
encapsulation vlan-ccc;
vlan-id 560;}
[edit protocols l2circuit neighbor 10.200.86.7]
interface ge-0/0/0.560 {
virtual-circuit-id 560;
description l2-to-lagavulin;
mtu 9000;}
[edit protocols ldp]
interface Lo0.0
{{note|text=Для ссс-инкапсуляции зарезервирован диапазон 512-4094}}
Кстати, можно объединять интерфейсы между собой на одном роутере.
[edit protocols l2circuit local-switching]
interface ge-0/0/1.200
end-interface
interface ge-0/0/3.200

===Verification===
Можно смотреть только состояние l2circuit connection. =(
Если исключить всякие тупые ошибки, типа mtu mismatch, ненастроенный сигналинг с двух сторон и т.п., то в основном проблемы сводятся к проблемам с обменом метками между PE. В таком случае проверяем:
* LDP соседство
* LDP database
* Наличие Lo в inet.3 и т.д.
Если control plane поднялся:
* Можем смотреть только обмен пакетами на интерфейсе.
* Поднимать l3 интерфейсы и смотреть свзяность через l2circuit.
* Если физически нет возможности поднять l3, то можно задействовать logical-tunnel.

===psn-tunnel-endpoint===
Строит туннель до адреса, отличного от LDP соседа.

*PE1 lo = 1.1.1.1
*PE2 lo = 2.2.2.2 primary, 10.2.2.2 secondary
2.2.2.2 - LDP LSP, 10.2.2.2 - RSVP LSP.

Если хотим построить l2circuit, который пойдёт по RSVP LSP, достаточно просто в конфиге на PE указать ''psn-tunnel-endpoint'':
set protocols l2circuit neighbor 2.2.2.2 interface ge-0/0/0.10 psn-tunnel-endpoint 10.2.2.2
set protocols l2circuit neighbor 2.2.2.2 interface ge-0/0/0.10 virtual-circuit-id 10
set protocols l2circuit neighbor 2.2.2.2 interface ge-0/0/0.20 virtual-circuit-id 20

ge-0/0/0.20 - будет использовать для построения LDP LSP

ge-0/0/0.10 - будет использовать для построения RSVP LSP. лукап в inet.3 будет делаться для 10.2.2.2.

psn-tunnel-endpoint - не обязательно адрес именно на loopback.

==Kompella (BGP)==

[[Файл:Kireeti Kompella.jpg|thumb|справа|альт=Kireeti Kompella|Компелла. Собственной персоной!]]

Цель - создать полноценный VPN. В l2circuit используется LDP-full-mesh.

Для Kompella используется сигнализация на основе BGP, можно соорудить full-mesh iBGP, можно использовать RR.

* Для клиента создается '''отдельный RI'''.
* В него добавляются локальные интерфейсы клиента и указывается с каким удаленным роутером RI будет соединяться. Router-ID - не очень надежно, т.к. его можно заменить, и в таком случае придется переделывать все RI для клиента по всей сети. Поэтому привязку сделали по '''site-id''' - задаются вручную, определяют схему коммутации между роутерами (в рамках RI).
* Метка назначается каждому '''локальному интерфейсу''', который ассоциирован с site ('''per interface''').
* Роутеры между собой обмениваются выделенными метками, чтобы удаленные site знали push какой метки делать, чтобы достичь нужного site. Набор меток - новый NLRI - '''family l2vpn signaling'''.
* У каждого клиента также присутствует свой идентификатор - route-target.

LSP между PE должна быть предустановлена, можно использовать как LDP так и RSVP.

===L2vpn signaling и выделение меток===
Алгоритм выделения меток был оптимизирован, но для лучшего понимая как и зачем, рассмотрим этапы его становления. =)

Изначально, исходя из схемы, рассмотрим что требуется передавать между PE, на примере того, что передаст PE1:
*метки:
:* 102 -> site 2
:* 103 -> site 3
:* 104 -> site 4
*local site-id:
:* site-id = 1

*PE2 видит:
Я - site 2. Site 1 ассоциирован с int 1. Site 1 прислал, что для отправки пакета ему, я должен сделать push 102 => int 1: push 102 push 50 (LSP до PE1) резолвим next-hop для PE1 в inet.3))

*PE3 видит:
Я - site 3. Site 1 ассоциирован с int 1. Site 1 прислал, что для отправки пакета ему, я должен сделать push 103 => int 1: push 103 push 60.

То есть все PE получают от site 1 '''все''' метки, хотя им нужна всего одна, которая соответствует его site.

Kompella решил, что это излишняя инфа и что достаточно пересылать только метки, не указывая каким site они соответствуют. Просто метки будут располагаться ровно в том порядке, в котором они предназначены удаленным site.
101 - 1
102 - 2
103 - 3
...

В таком случае важно следить, чтобы site имели номера один за одним, блок меток тогда будет - непрерывный.

Если на сети будет так: PE1 - site 1, PE2 - site 50, то PE1 будет вынужден выделить метки [1, ..., 50], хотя требуется только 1 и 50. Те site, которые пропускаются, для них будут созданы фейковые метки 2, 3, ..., 49, но метки использоваться не будут.

PE2 получит:
102
103
104
и выберет для себя 103, что будет не правильным поведением.

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

В итоге от PE2 будет такое распределение меток:
int 1 (site 1) - 201 label
int 2 (site 3) - 203 label
int 3 (site 4) - 204 label
202 label - выделена, но не связана ни с каким интерфейсом.

И будет передан такой NLRI:
201
202
203
204
site-id 2

В Juniper выделен отдельный блок (для Kompella), начиная с 800000, в рамках 1 PE метки не повторяются, должны быть уникальными.

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

В итоге в NLRI передается:
* label base (начальная)
* site-ID
* label range

Исходя из полученных данных PE вычисляет свою метку для связи с тем PE, кот переслал блок:
label = label base (remote) + site-ID (local) - 1 (offset) (remote)

Данная метка заносится в mpls.0

Т.о. получается, что каждый PE хранит у себя одну метку, а не кучу лишних.

Когда добавляется еще один site:
site-5: создал RI, сгенерировал NLRI, NLRI проанонсировался остальным PE, через RR. PE1 получил NLRI, понял, что появился site 5, требуется построить до него туннель, посмотрел какую метку push в сторону site 5 - все нормально.

PE5 получил NLRI всех PE от RR, начинает строить до них туннели. Для site 1 - возьмет 105 метку, которой в блоке нет, это понятно по label range. Что делать?

PE1, когда был получен NLRI от PE5, должен изменить NLRI, но метка 105 возможно будет уже занята для других целей. И + уже построенные туннели должны буду заново создаться, т.к. прилетит новый NLRI.

Поэтому, PE1 не меняет текущий блок, а добавляет к нему новый блок, тогда NLRI ('''конечный вариант'''):
* label base = 110
* site-id = 1
* label-range = 3
* '''label offset = 5''' - равен начальному site-ID, которому выделена первая метка блока.

Выглядит так: 10.200.86.1:1212:1:3/96:
* 10.200.86.1:1212 - RD
* 1 - site-id
* 3 - offset
* /96 - mask

L2 extended community содержит информацию об MTU: MTU, сконфигурированное PE-CE линке на отправляющем PE. Т.к. на L2 участке нет места фрагментации, то PE, получивший NLRI с не совпадающим MTU, проигнорирует такой NLRI.

*vlan-id = [0 - 511] - обычные vlan-tagged interfaces
*vlan-id = [512 - 4094] - специальные, для ccc-encapsulation.
По факту в настройки vlan-ccc с vlan-id < 512 у меня проблем не возникало.

В случаях, когда на одном роутере подключены 2 site клиента, которые также требуется соединить между собой, можно просто внутри VRF разным интерфейсам назначаем разные site-ID. В этом случае просто для каждого site будет создан свой NLRI. Так тоже можно.

[[Файл:l2vpn_labels.png]]

===Configuration===
blair# top show | compare
[edit interfaces ge-0/0/0]
encapsulation flexible-ethernet-services;
unit 601 {
encapsulation vlan-ccc;
vlan-id 601;
}
[edit protocols bgp group internal]
family l2vpn {
signaling;

[edit routing-instances]
fox-services {
instance-type l2vpn;
interface ge-0/0/0.600;
interface ge-0/0/0.601;
route-distinguisher 10.200.86.1:1212;
vrf-target target:1111:1212;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site blair {
site-identifier 1;
interface ge-0/0/0.600 {
remote-site-id 9;
}
interface ge-0/0/0.601 {
remote-site-id 4;

tormore:
fox-services {
instance-type l2vpn;
interface ge-0/0/0.850;
route-distinguisher 10.200.86.9:1212;
vrf-target target:1111:1212;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site tormore {
site-identifier 9;
interface ge-0/0/0.850 {
remote-site-id 1;

===Verification===
blair> show l2vpn connections
Instance: fox-services
Local site: blair (1)
connection-site Type St Time last up # Up trans
4 rmt '''Up''' Nov 7 14:49:02 2016 1
Remote PE: 10.200.86.4, Negotiated control-word: Yes (Null)
Incoming label: '''800001''', Outgoing label: '''800000'''
Local interface: '''ge-0/0/0.601''', Status: Up, Encapsulation: VLAN
9 rmt '''Up''' Nov 7 17:47:21 2016 1
Remote PE: 10.200.86.9, Negotiated control-word: Yes (Null)
Incoming label: '''800002''', Outgoing label: '''800004'''
Local interface: '''ge-0/0/0.600''', Status: Up, Encapsulation: VLAN

blair> show route advertising-protocol bgp 10.200.86.9 detail
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 10.200.86.1:1212:1:3/96 (1 entry, 1 announced)
BGP group internal type Internal
Route Distinguisher: 10.200.86.1:1212
Label-base: 800000, range: 2, status-vector: 0x0
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1111] I
Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
* 10.200.86.1:1212:1:9/96 (1 entry, 1 announced)
BGP group internal type Internal
Route Distinguisher: 10.200.86.1:1212
Label-base: 800002, range: 2, status-vector: 0x0
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1111] I
Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100

blair> show route receive-protocol bgp 10.200.86.9 detail table fox-services.l2vpn.0
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 10.200.86.9:1212:9:1/96 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 10.200.86.9:1212
Label-base: 800004, range: 2, status-vector: 0x0
Nexthop: 10.200.86.9
Localpref: 100
AS path: I
Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100

blair> show route table bgp.l2vpn.0 detail
bgp.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
10.200.86.4:1212:4:1/96 (1 entry, 0 announced)
*BGP Route Distinguisher: 10.200.86.4:1212
Source: 10.200.86.4
Protocol next hop: 10.200.86.4
Age: 3:01:31 Metric2: 1
Communities: '''target:1111:1212''' Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
Import Accepted
Label-base: '''800000''', range: 2, status-vector: 0x0
Localpref: 100
Router ID: 10.200.86.4
Secondary Tables: ''fox-services.l2vpn.0''
10.200.86.9:1212:9:1/96 (1 entry, 0 announced)
*BGP Route Distinguisher: 10.200.86.9:1212
Source: 10.200.86.9
Protocol next hop: 10.200.86.9
Age: 3:12 Metric2: 1
Communities: '''target:1111:1212''' Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
Import Accepted
Label-base: '''800004''', range: 2, status-vector: 0x0
Localpref: 100
Router ID: '''10.200.86.9'''
Secondary Tables: ''fox-services.l2vpn.0''

tormore> show route receive-protocol bgp 10.200.86.1 table fox-services.l2vpn.0 detail
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 10.200.86.1:1212:1:3/96 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 10.200.86.1:1212
Label-base: 800000, range: 2, status-vector: 0x0
Nexthop: 10.200.86.1
Localpref: 100
AS path: I
Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
* 10.200.86.1:1212:1:9/96 (1 entry, 1 announced)
Import Accepted
Route Distinguisher: 10.200.86.1:1212
Label-base: 800002, range: 2, status-vector: 0x0
Nexthop: 10.200.86.1
Localpref: 100
AS path: I
Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100

'''Forwarding'''
Только метки и ничего больше! 1 метка для L2VPN, одна для передачи через LSP.

Ingress:
blair> show route table fox-services.l2vpn.0 detail
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.200.86.9:1212:9:1/96 (1 entry, 1 announced)
*BGP Route Distinguisher: 10.200.86.9:1212
Source: 10.200.86.9
Protocol next hop: 10.200.86.9
Age: 35:59 Metric2: 1
Announcement bits (1): 0-fox-services-l2vpn
Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
Import Accepted
Label-base: '''800004''', range: 2, status-vector: 0x0
Localpref: 100
Router ID: 10.200.86.9
Primary Routing Table bgp.l2vpn.0

blair> show route table fox-services.l2vpn.0
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
...
'''10.200.86.9:1212:9:1/96'''
*[BGP/170] 00:37:40, localpref 100, from 10.200.86.9
AS path: I
> to 192.168.86.25 via ge-0/0/0.110, '''label-switched-path blair-to-tormore'''

blair> show rsvp session name blair-to-tormore detail
Ingress RSVP: 2 sessions
10.200.86.9
From: 10.200.86.1, LSPstate: Up, ActiveRoute: 0
LSPname: blair-to-tormore, LSPpath: Primary
LSPtype: Static Configured
Resv style: 1 FF, Label in: -, Label out: '''301168'''

На транзитных будет swap и pop с метками для LSP.

Egress:
tormore> show route label 800004
mpls.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
'''800004''' *[L2VPN/7] 00:05:53
> via ge-0/0/0.850, Pop Offset: 4

=Stitching=
Для ститчинга VPN можно использовать ''iw-interface'' или ''lt-interface''.

В конфиге iw-interface можно задать только инкапсуляции:
ethernet-ccc Ethernet for a cross-connect
frame-relay-ccc Frame Relay DLCI for CCC
ppp-ccc Serial PPP device for a cross-connect
vlan-ccc 802.1q tagging for a cross-connect
Соответственно он работает только для ститчинга L2VPN (разных типов) между собой.

Если хочется объединить L2VPN+VPLS, или L2VPN+L3VPN, то это делается при помощи ''lt-interface''.

==L2VPN BGP (Kompella)==
[[Файл:L2VPN_stitching.png|1024px]]

Можно объединить два L2VPN, используя '''stitching''' в виде '''interworking interface''' (или иногда используют ''logical-tunnel'', кот требует физического включения на оборудовании и специальную плату):
*задаем interface iw.0 внутри [edit interfaces], encapsulation и vlan-id должны быть как и для удаленных концов VPN
[interfaces]
iw0 {
unit 0 {
encapsulation vlan-ccc;
vlan-id 10;
peer-unit 1;}
unit 1 {
encapsulation vlan-ccc;
vlan-id 10;
peer-unit 0; }}
*создаем RI, которые нужно будет скрепить между собой, добавляя в них interface iw0:
[routing-instances]
bear {
instance-type l2vpn;
interface iw0.1;
route-distinguisher 10.200.86.5:999;
vrf-target target:1111:999;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site dalw {
site-identifier 5;
interface iw0.1 {
remote-site-id 8; }}}}}
fox {
instance-type l2vpn;
interface iw0.0;
route-distinguisher 10.200.86.5:8765;
vrf-target target:1111:8765;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site dalw {
site-identifier 5;
interface iw0.0 {
remote-site-id 3; }}}}}}
*включаем l2iw protocol:
[protocols]
l2iw;
{{note|text=При выключении protocols l2iw наш ститчинг проложит работать. После выключения и перезагрузки роутера - перестанет работать. Работоспособность восстановится только после повторного включения l2iw.}}
Проверяем:
dalwhinnie> show l2vpn connections
Instance: bear
Local site: dalw (5)
connection-site Type St Time last up # Up trans
8 rmt Up Feb 9 12:52:35 2017 1
Remote PE: 10.200.86.8, Negotiated control-word: Yes (Null)
Incoming label: 800005, Outgoing label: 800006
Local interface: iw0.1, Status: Up, Encapsulation: VLAN
Instance: fox
Local site: dalw (5)
connection-site Type St Time last up # Up trans
3 rmt Up Feb 9 12:52:35 2017 1
Remote PE: 10.200.86.3, Negotiated control-word: Yes (Null)
Incoming label: 800006, Outgoing label: 800006
Local interface: iw0.0, Status: Up, Encapsulation: VLAN

==L2VPN LDP (Martini)==
iw interface и протокол l2iw - задаются аналогично, конфигурация l2circuit:
[protocols l2circuit]
neighbor 10.200.86.3 {
interface iw0.0 {
virtual-circuit-id 10;
encapsulation-type ethernet-vlan; }}
neighbor 10.200.86.8 {
interface iw0.1 {
virtual-circuit-id 10;
encapsulation-type ethernet-vlan;}}}

dalwhinnie> show l2circuit connections
Neighbor: 10.200.86.3
Interface Type St Time last up # Up trans
iw0.0(vc 10) rmt Up Feb 11 15:51:15 2017 1
Remote PE: 10.200.86.3, Negotiated control-word: Yes (Null)
Incoming label: 299872, Outgoing label: 300832
Negotiated PW status TLV: No
Local interface: iw0.0, Status: Up, Encapsulation: VLAN
Neighbor: 10.200.86.8
Interface Type St Time last up # Up trans
iw0.1(vc 10) rmt Up Feb 11 15:51:16 2017 1
Remote PE: 10.200.86.8, Negotiated control-word: Yes (Null)
Incoming label: 299888, Outgoing label: 300128
Negotiated PW status TLV: No
Local interface: iw0.1, Status: Up, Encapsulation: VLAN

==Kompella + Martini==
Опять же interface iw0 и protocols l2iw - такие же.
[protocols l2circuit]
neighbor 10.200.86.3 {
interface iw0.0 {
virtual-circuit-id 10;
encapsulation-type ethernet-vlan; }}
[routing-instances bear]
instance-type l2vpn;
interface iw0.1;
route-distinguisher 10.200.86.5:999;
vrf-target target:1111:999;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site dalw {
site-identifier 5;
interface iw0.1 {
remote-site-id 8;}}}}}

==Дополнительная информация==
*[[VPLS]]
*[[EVPN]]
*[[Реализация MPLS в ядре сети]]

L3VPN

2021-07-15T18:30:42Z

Наталия Бобкова:

{{#description2:L3VPN Control plane. Конфигурация L3VPN. Route distinguisher. Route target. VRF-import/export. Sham-link. L3VPN IPv6. Протечка маршрутов между L3VPN. Hub-and-spoke топология. QoS в L3VPN. Доступ в интернет в L3VPN. Информация для подготовки к экзаменам Juniper.}}

=Routing (Control plane)=
VPN-IPv4 NLRI format - только control plane:
MPLS label | Type | Administrator | Assigned Number | IPv4 Prefix | Mask

*'''Mask''' : /32 = /120
*'''Route Distinguisher''': Type | Administrator | Assigned Number
*: Administrator - может быть двух типов: 2-байт (AS number), 4-byte (router ID = Lo0 address).

'''RD''' решает проблему с пересечением маршрутов между разными клиентами.

Уникальность RD:
*для L2VPN и VPLS c l2vpn-use-bgp-rules - обязательно уникальный RD.
*для L2VPN и VPLS с mesh-group - обязательно уникальный RD.
*для других типов VPN - не обязательно! НО горячо рекомендуется делать RD уникальным (для разных PE в рамках одного RI) - так будет однозначно понятно от какого PE прилетел NLRI.

automatic RD:
set routing-options route-distinguisher-id 172.30.5.3

Если внутри RI будет все же указан RD, то для построения VPN будет использован более специфический RD (тот что внутри routing-instance).

'''RT''' решает проблему распространения маршрутов, задает топологию отдельного VPN.
Имеет такую же структуру как и RD.

Определяет какому клиенту принадлежит префикс (routing-instance = routing-table конкретного клиента).

Прикрепляется к маршруту либо явно внутри VPN, либо через export policy - более гибкий метод, при котором можно создавать разные топологии.

С помощью import policy либо явно заданного RT, можно принимать либо нет маршруты с определенным RT.

'''Routing tables''':
*'''inet.0''': IGP, IBGP learned routes.
*'''inet.3''': RSVP/LDP learned Lo0 ip addresses.
*'''mpls.0''': MPLS forwarding info
*''' ''vpn-name''.inet.0''': все unicast IPv4 локального CE, статические маршруты внутри VRF, маршруты от remote PE.
*'''bgp.l3vpn.0''': все VPN-IPv4 NLRI маршруты от удаленных PE.

Не важно LDP или RSVP будет у вас на сети. Можно использовать оба, можно использовать какой-то один. Главное, чтобы были Lo PE-роутеров в net.3

Рассмотрим такую схему:
CE1 <static> PE1 <mpls> P <mpls> PE2 <static> CE2

Между CE и PE - маршрутизация (static, bgp, ospf). CE присылает свои префиксы, но ISP должен отделить эти префиксы от других и поместить с отдельную таблицу. Для этого клиент заводится в ''routing-instance'' ('''vrf''').

PE должен передать принятые префиксы от клиента другому PE на удаленный конец, и затем отдать их удаленному CE2. Используем iBGP между PE. В момент отправки префиксов с PE, нужно пометить их. Добавляем некое число - '''route-destinguisher (RD)''' - не идентифицирует клиента, просто делает префикс уникальным внутри процесса BGP. RD должен быть уникальным в пределах всей сети, поэтому зачастую используют ''IDrouter:число''. RD - часть NLRI.

Типы RD:
#AS[2 byte]:идентификатор клиента[4 byte]
#AS[4 byte]:идентификатор клиента[2 byte]
#router-ID[4 byte]:идентификатор клиента[2 byte] - можно руками не задавать, а поручить это маршрутизатору.

В inet.0 хранятся IPv4, не получится туда залить наши префиксы, т.к. они имеют совсем другую структуру.

NLRI - абстрактная структура данных. Роутеры до установления сессии должны совпадать хотя бы по 2-м ''address family''.

Включаем ''protocols bgp family inet-vpn any'' - только после этого BGP будет способен передавать новые NLRI.
По умолчанию, если в конфиге указывается какая-то конкретная family, то требуется указать '''все''' family, которые будут передаваться через MP-BGP. То есть добавляем сюда и ''family inet'' обязательно.

Под новые NLRI создается своя таблица: ''bgp.l3vpn.0''. Префиксы хранятся вместе с RD. Таблица используется только на control plane, не для форвардинга.

Для форвардинга будет использоваться отдельная таблица для VRF. В ней префиксы будут храниться в обычном IPv4 формате. Для этого нужно убрать RD и разложить префиксы по нужным VRF. То есть в сети должен существовать некий идентификатор клиента.

'''Route target (RT)''' - не часть NLRI, это атрибут, который передается внутри объекта вместе с NLRI. RT - ''extended community типа 2''. По сути будет определять какому VRF относится префикс.

С помощью RT можно для клиента обеспечить связность не только full mesh, но и более сложные топологии: 1 ко всем, 2 между собой, 3-й только с конкретным сайтом.

NLRI с RT прилетает на удаленный PE, префикс запихивается в нужный VRF, убирается RD, сохраняем префикс в виде IPv4. По настроенному протоколу PE<>CE передает префикс CE.

'''BGP''': по дефолту передает только маршруты, полученные по BGP. Но с VRF другое поведение: если конфигурируем VRF и в VRF пишет target, а не policy, то роутер берет все маршруты из этого VRF, присоединяет к ним target, и отправляет по MP-BGP.

Когда проанонсированный префикс прилетает соседу (используя vpn family), тот: смотрит на target, ищет у себя target. Если VRF с таким target нет, то BGP-update отбрасывается (даже не попадают в hidden), он не знает в какую таблицу его запихнуть. Как проверить, что все-таки update прилетает: включить ''traceoptions''. Т.е. на P роутере prefix клиента отбросится. Но до PE2 по iBGP все-равно анонс долетит, но будет скрытым (не отрезолвился next-hop, он не попал в inet.3). Если prefix все-таки не прилетает даже в hidden, то скорей всего '''проблема с RT'''.

=Forwarding=
Допустим, к CE1 подключено устройство с default route, пакет идет на CE1. CE1 по BGP передает трафик к PE1. На PE1 пакет попадает в ''vrf1.table.inet.0'', т.к. на PE1 интерфейс в сторону CE1 добавлен в VRF клиента. Forwarding next-hop: P-router (по IGP). P-router принимает пакет и не знает что с ним дальше делать. '''Схема не рабочая'''

Будем туннелировать пакеты от PE1 (не обязательно в mpls). Но рассматриваем mpls.
* LSP на PE1 в inet.3: PE2: push 20 -> P. BGP резолвит next-hop для PE2, подставляет в inet.0.
* P смотрит в mpls.0: 20 pop.
* На PE2 прилетает голый ip пакет. PE2 делает lookup в ''inet.0'', т.к. интерфейс, с которого пришел пакет - принадлежит master RI и сам пакет - просто ip. В inet.0 не будет нужного маршрута => тоже ''схема не рабочая''.

Делаем так, чтобы PE2 понял, что lookup нужно производить внутри VRF. RT и RD не проканают, т.к. они существуют только на уровне control plane, и не причастны к передаче трафика.

Какой-нибудь header можем использовать как идентификатор, что нужно смотреть в определенной таблице. Берем MPLS заголовок.
* Исходный VRF каждому пакету выделяет уникальную для себя метку. Пакет будет иметь следующий вид: '''label:RD:prefix/mask'''.
* Добавлять метку будет egress, удаленный PE2 роутер. Поэтому выделенную метку нужно проанонсировать с PE1 на PE2 по MP-BGP. Family vpn: label:prefix/mask.
* Т.к. на PE2 префикс прилетает с меткой (смотрим в таблицу bgp.l3vpn ''vpn label''), то для PE2 это означает, что с другой стороны пакеты ждут с этой меткой. Т.е. PE2 добавляет выделенную метку, затем resolve next-hop. В нашем случае произойдет следующее: push 20 (для LSP) push 50 (для VRF) -> P.
* На P делается 20 pop.
* На PE1 приходит пакет: 50:RD:prefix/mask. Пакет попадает в mpls.0, где должна быть запись: 50: pop -> vrf1. Такая запись будет создана, как только будет создан сам VRF (ему назначается определенная метка и запись инсталлируется в mpls.0).
* На PE1 далее метка снимается, RD снимается, пакет идет на второй lookup внутри таблицы vrf1. И далее пакет направляется к нужному next-hop, согласно таблицы vrf1.

На PE2 делается 2 lookup.

Такая схема будет работать только если включить '''vrf-table-label'''.

В каких случаях нам может потребоваться делать второй lookup внутри VRF: если хотим осуществлять какие-то дополнительные функции для клиентов на основании ip внутри VRF - посчитать трафик, пофильтровать, пополисить... по ip заголовку. '''vrf-table-label''' заставляет роутер назначать метку на VRF и делать второй lookup. В основном этой схемой и пользуются. При включенном '''vrf-table-label''' PE начинает передавать Direct маршруты RR (или ibgp PE)

Но на самом деле Juniper по дефолту работает так: метка назначается не на VRF, а на next-hop, с которого исходно пришли клиентские маршруты. Каждому next-hop своя метка. Т.о. на PE2 в mpls.0: 51 pop -> CE1 next-hop, 52 pop -> CE2 next-hop. Это позволяет не делать второй lookup.

Cisco по дефолту назначает метки для prefix. Но это не очень удобно, когда от клиента приходит много префиксов и тем самым занимается ASIC для хранения всех этих меток.

When using network commands like ping, traceroute, and ssh, the routing-instance switch is used to specify the routing table that should be used to forward packets for the session. By default, the router will use the inet.O table not the VRF table.

By default, an egress PE that has an Ethernet VRF interface cannot perform both a pop of the MPLS label and an ARP for packets that come from the core. Therefore, an ARP must be performed by the egress router prior to receiving packet from the core. This can be achieved simply by receiving at least one route from the connected CE (which causes an ARP to occur to determine next hop). Also, a static route can be configured within the VRF instance that points to the connected CEo This is generally sufficient. However, if it is necessary to ping the VRF interface without adding routes to the VRF table, vrf-table-label or a VT interface can be used to allow for both a pop and ARP operation by the egress router.

[[Файл:l3vpn_labels.png]]

==GRE==
Если вдруг вместо MPLS для форвардинга используется GRE, то:
*gre-туннули должны быть добавлены в inet.3 (т.к. VPN ревозвится в net.3)
*на туннельных интерфейсах должен быть включен MPLS (для лукапа меток под клиентский VPN (RI))

=Config (минимальный для VRF, PE<>CE - static)=
routing-instances {
rabbit {
instance-type vrf;
interface ge-0/0/0.10;
route-distinguisher 10.200.86.5:0001;
vrf-target target:1111:0001;
routing-options {
static {
route 11.11.11.11/32 next-hop 192.168.55.2;}}}}

bgp {
group in {
type internal;
local-address 10.200.86.5;
family inet {
any;}
family inet-vpn {
any;}
neighbor 10.200.86.3;
neighbor 10.200.86.1;}}
mpls {
label-switched-path dalw-oban {
to 10.200.86.3;

=VRF-import / VRF-export=
Если требуется передача не всех маршрутов, а специфических маршрутов, то вместо vrf-target будем использовать vrf-import/vrf-export.

- import политика может применяться несколько. '''Должен быть''' последний term: the reject. Исключение - если вся политика - это then reject.

- export политика тоже должна иметь последний term: the reject. Лучше делать then community [target] '''add'''.

Export политики на ibgp сессии между PE (или PE-RR) не влияют на передачу маршрутов в рамках vrf. Если хочется, чтобы export policy на BGP сессии также играло роль - включаем:
set protocols bgp (group|neighbor) vpn-apply-export
Сначала отработает VRF, потом BGP.

Для l2vpn в vrf-export нужно делать then community add [не set], потому что при настроенном set затрутся служебные L2-info extended community.

Пример настройки:
blair> show configuration routing-instances oak
instance-type vrf;
interface ge-0/0/0.600;
route-distinguisher 10.200.86.1:100;
'''vrf-import import-to-oak''';
'''vrf-export export-from-oak''';

blair> show configuration policy-options
policy-statement '''export-from-oak''' {
term 1 {
from {
route-filter 172.17.0.0/24 orlonger;
then {
community add ''vpn-oak'';
accept;
term defaul {
then reject;
policy-statement '''import-to-oak''' {
term 1 {
from {
community ''vpn-oak'';
route-filter 172.17.0.0/24 orlonger;
then accept;
term defaul {
then reject;
community ''vpn-oak'' members target:1111:100;

Либо можно использовать такой вариант, если нужны просто разные target на import и export:
blair# set routing-instances test vrf-target import target:1111:100
blair# set routing-instances test vrf-target export target:1111:101
==Route-origin==
По сути имеет только вид extended-community, но функционально не отличается от обычного. Обращаться с ним как с обычным!
policy-options {
community my-soo {
members origin:100:1;
==Route-target filtering==
Уменьшает кол-во служебного трафика. По сути удаленный PE->PE [или RR->PE] посылает только маршруты тех vrf, которые запрашивает локальный PE.

По дефолту на локальный PE приходят маршруты '''всех''' vrf на сети и устанавливаются в таблицы vrf только те, target которых есть на локальном роутере.

Используется таблица: bgp.rtarget.0. Предаются новые target NLRI вида: 200:200:102/96 = as:rt/mask

На локальном PE, где был создан vrf, сразу генерируется NLRI на основании vrf-import target. Остальные PE [или RR] узнают префиксы каких vrf слать этому PE.

Фильтрация включается на ibgp сессии между PE [или на ibgp c RR]. Ну понятно, что при включении новой family сессия флапает, так что осторожней!

Можно задавать дополнительные параметры:
family route-target {
advertise-default;
external-paths number;
prefix-limit number;

=CE<>PE eBGP=
В настройке особенностей нет, но возникают проблемы с AS.

У клиента одна и та же AS с двух сторон (AS 65000) => PE1 (AS 10) получает префикс с AS-path 65000 * => на PE2 сработает split horizing, и он не будет анонсировать CE2 => решаем проблему.

# На PE1 в VRF под протоколом BGP: ''advertise peer-as'' - отключает split horizont. AS path поменяется: 10 65000 *. СЕ2 принимает маршрут, но должен его отбросить, т.к. в AS-path видит свою AS => на CE2 отключаем проверку на loop: ''routing-options autonomous-system loops 2''.
# На РЕ1 в VRF под протоколом BGP '''group <*>''': ''as-override'' - отключает split horizing + ищет в AS-path соседскую AS и заменяет ее на свою. Новый AS-path: 10 10. На CE2 проблемы не возникнет. '''переустанавливает сессию'''.
# Если у клиента private AS => ''remove private''. Можно включить во всех уровнях иерархии. Удаление private AS происходит при передаче маршрута (не приеме). Удаляет левую крайнюю private AS. Если после нее идет public AS, то на этом механизм останавливается и не ищет private AS далее. В случае, если хотим передать ebgp пиру с private AS префикс, где уже указана его AS, то роутер не будет удалять private AS, а следовательно и передавать префикс пиру. То есть по факту для решения проблем с лупами AS в рамках l3vpn лучше использовать - as-override. no-peer-loop-check - позволяет удалить private AS даже в таком случае (c 15.1 ветки)
# На PE1 внутри VRF настраиваем AS CE1: ''routing-options autonomous-system <AS-CE1>'' + ''routing-instance <instance> routing-options autonomous-system independent-domain'' - исходные атрибуты BGP от CE1 сохраняются в новый атрибут: ''outer-set'', который добавится при анонсе в iBGP провайдера. На PE2 тоже настраиваем ''independent-domain'', который раскроет ''outer-set''. Т.о. при передаче префикса CE2 AS-path не будет заполнен (при iBGP AS-path пустой). Внутри VRF настраиваем ''internal BGP''. Также этот способ дает возможность сохранить ''local-preference'' от CE1.

=CE<>PE OSPF=
==Общие сведения об OSPF==
*Внутри area - LSA1 (router), LSA2(network) - описание топологии.
*Между area - LSA3 (summary) - внутренние сети.
*LSA 5 (external) - внешние маршруты.

Внутренний порядок выбора маршрутов, до попадания в routing-table:
*intra-area (LSA1, LSA2)
*inter-area (LSA3)
*external (LSA5)

Split horizont: area 0 - центральная. Все остальные area могут подключаться только через area 0. Все, что пришло из некой внешней area - не передается в area 0, т.к. оно впринцепе может прийти только из area 0.

==Sham-link==
Если все это применить к L3VPN.

Внутри VRF настраиваем OSPF, включаем в него интерфейс в сторону клиента. В core - iBGP, LSP.
#A: отправляет свой Lo 10.0.0.1 в area как LSA1.
#PE1: в RI попадает 10.0.0.1 как LSA3.
#PE1: inet.0: 10.0.0.1/32 - [OSPF] -> A.
#Все маршруты из RI передаются по iBGP.
#PE2 получит анонос сети 10.0.0.1/32 ререз BGP. vrf.inet.0: 10.0.0.1/32 - [BGP] -> LSP.
#Требуется сеть из BGP передать по OSPF. Пишем policy.
#PE2 из RI сеть будет передаваться к клиенту как LSA3.
*'''!!Проблема 1:''' при поднятии OSPF клиенту требуется одна area.
*'''!!Проблема 2:''' по факту клиенту требуется объединить 2 своих роутера в одну сеть => маршруты от СЕ1 должны приходить как LSA1.
Делаем так, чтобы из PE2 VRF к клиенту вылетела LSA1.
LSA1 содержит в себе линки, а мы при передаче от клиента к RI превратили эту информацию в маршруты, которые дальше стали анонсироваться по BGP. Из маршрутов линки обратно сделать не получится. Как исправить?
#Придумать новый NLRI, повторяющий структуру LSA1. Но ведь итак для L3VPN уже есть свой NLRI, засовывать в него еще NLRI - уже страшно. Поэтому...
#PE1 и PE2 требуется соединить с помощью sham-link. Роутеры при этом будут как бы в одной area и будут флудить между собой LSA1.

'''Задаем sham-link:'''
#Создаем отдельный unit на Lo, заносим его в RI. PE1: 1.1.1.1, PE2: 1.1.1.2
#Указываем local-end, remote-end.
#Чтобы роутеры установили соседство - нужно отправить hello в LSP (между PE) => Lo уделанного PE мы должны получить по iBGP.
PE1: inet.0: 1.1.1.2 - [BGP] -> LSP.
{{note|text=Обязательно нужно в policy (vrf-import, vrf-export) добавить адреса Lo!!, иначе ничего не заработает.}}
Все заработало, к CE2 улетел LSA1.

'''НО!''' произошло небольшое изменение: маршрут 10.0.0.1/32 прилетел на PE2 в RI, как известный по OSPF и был выбран активным.
PE2: vrf.inet.0:
*10.0.0.1/32 - [OSPF/10] -> shamlink.0
10.0.0.1/32 - [BGP/170] -> LSP

При отправке пакета с dest = 10.0.0.1/32 будет также выбран маршрут, изученный по OSPF. Но shamlink - некая абстракция и в передаче трафика не участвует.

На самом деле умный роутер делает все маршруты, доступные через shamlink - скрытыми, чтобы их нельзя было использовать. А изученные по BGP - станут активными.

'''НО!''' на удаленный PE2 обязательно должен прийти маршрут CE1, полученные по BGP (для форвардинга) и OSFP (для распространения LSA1). В итоге на удаленном PE в ''vrf.inet.0'' должны быть hidden маршруты, изученные по ospf.

- Если используем vrf-target - то все само придет, т.к. при таком варианте передаются все маршруты, находящиеся в VRF.

- Если используем policy, то нужно не забыть, что OSPF маршрут нужно отправить по BGP на удаленный PE.

''Sham-link'' годится только в случае, когда объединяются роутеры клиента в одной area и когда критично принимать именно LSA1, как было бы без вмешательства ISP.
===Configuration===
[[Файл:CE-PE OSPF laba.png]]
blair> show configuration routing-instances
beer {
instance-type vrf;
interface ge-0/0/0.510;
'''interface lo0.1''';
route-distinguisher 10.200.86.1:500;
vrf-target target:1111:500;
protocols {
ospf {
'''export beer-l3vpn;'''
'''sham-link local 1.1.1.1;'''
area 0.0.0.0 {
'''sham-link-remote 2.2.2.2;'''
interface ge-0/0/0.510 {
interface-type p2p;
}
interface lo0.1;
blair> show configuration interfaces lo0.1
family inet {
address '''1.1.1.1/32;'''
Со стороны удаленного РЕ конфиг аналочигный.

'''при использовании policy для vrf''':
policy-statement export-rabbit { - '''полиси применяется для vrf-export внутри VRF'''
term 1 {
from {
route-filter 192.168.55.0/24 orlonger;
prefix-list CE-lo;}
then {
community set rabbit;
accept;}}
term 2 {
then reject;}}
prefix-list CE-lo {
10.10.86.5/32; - '''sham-link'''
11.11.11.11/32; - '''Lo CE1'''
22.22.22.22/32; - '''Lo CE2'''
33.33.33.33/32; - '''Lo CE3'''}
community rabbit members target:1111:0001;

Также, если рассматривать топологию ospf домена клиента в целом, то наверняка между различными site, клиентские роутеры будут подключены не только через нашу сеть, но буду иметь дополнительные резервные/основные линки. Таким образом, клиент может попросить сделать линк через нашу сеть резервным/основным. Сделать это можно с помощью регулирования ospf-метрики на shamlink.

blair# set routing-instances beer protocols ospf area 0.0.0.0 '''sham-link-remote 2.2.2.2 metric 700'''

===Проверка===
'''До включения ''sham-link'' '''
blair> show ospf database instance beer
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 1.1.1.1 1.1.1.1 0x80000017 59 0x22 0x310f 60
Router *172.17.0.2 172.17.0.2 0x80000017 55 0x22 0xcffa 60
'''Summary 172.17.0.1''' 1.1.1.1 0x80000004 39 0xa2 0x4ca9 28
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
'''Extern 2.2.2.2''' 1.1.1.1 0x80000002 66 0xa2 0xa157 36
Extern 192.168.86.52 1.1.1.1 0x80000004 39 0xa2 0x7697 36

blair> show route table beer.inet.0
beer.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[Direct/0] 00:15:29
> via lo0.1
2.2.2.2/32 *[BGP/170] 00:03:09, localpref 100, from 10.200.86.7
AS path: I
> to 192.168.86.10 via ge-0/0/0.60, label-switched-path blair-to-lagavulin
172.17.0.1/32 *[BGP/170] 00:00:11, MED 1, localpref 100, from 10.200.86.7
AS path: I
> to 192.168.86.10 via ge-0/0/0.60, label-switched-path blair-to-lagavulin
172.17.0.2/32 *[OSPF/10] 00:00:21, metric 1
> to 192.168.86.58 via ge-0/0/0.510
192.168.86.52/30 *[BGP/170] 00:00:11, localpref 100, from 10.200.86.7
AS path: I
> to 192.168.86.10 via ge-0/0/0.60, label-switched-path blair-to-lagavulin
192.168.86.56/30 *[Direct/0] 01:30:08
> via ge-0/0/0.510
192.168.86.57/32 *[Local/0] 01:30:08
Local via ge-0/0/0.510
224.0.0.5/32 *[OSPF/10] 01:30:11, metric 1
MultiRecv
'''После включения ''sham-link'' '''
blair> show ospf neighbor instance beer
Address Interface State ID Pri Dead
192.168.86.58 ge-0/0/0.510 Full 172.17.0.2 128 33
2.2.2.2 shamlink.0 Full 2.2.2.2 0 3

blair> show ospf database instance beer
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *1.1.1.1 1.1.1.1 0x8000001c 6 0x22 0x3b7b 60
'''Router 2.2.2.2''' 2.2.2.2 0x80000017 7 0x22 0xdbe4 60
'''Router 172.17.0.1''' 172.17.0.1 0x8000001f 8 0x22 0x3f8a 60
Router 172.17.0.2 172.17.0.2 0x80000019 7 0x22 0xcbfc 60
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 1.1.1.1 2.2.2.2 0x80000006 7 0xa2 0xa94b 36
Extern *2.2.2.2 1.1.1.1 0x80000005 6 0xa2 0x9b5a 36

blair> show route table beer.inet.0
beer.inet.0: 8 destinations, 10 routes (8 active, 0 holddown, '''2 hidden''')
1.1.1.1/32 *[Direct/0] 00:20:59
> via lo0.1
2.2.2.2/32 *[BGP/170] 00:08:39, localpref 100, from 10.200.86.7
AS path: I
> to 192.168.86.10 via ge-0/0/0.60, label-switched-path blair-to-lagavulin
'''172.17.0.1/32''' *['''BGP'''/170] 00:03:14, MED 1, localpref 100, from 10.200.86.7
AS path: I
> to 192.168.86.10 via ge-0/0/0.60, label-switched-path blair-to-lagavulin
172.17.0.2/32 *[OSPF/10] 00:03:28, metric 1
> to 192.168.86.58 via ge-0/0/0.510
'''192.168.86.52/30''' *['''BGP'''/170] 00:03:14, localpref 100, from 10.200.86.7
AS path: I
> to 192.168.86.10 via ge-0/0/0.60, label-switched-path blair-to-lagavulin
192.168.86.56/30 *[Direct/0] 01:35:38
> via ge-0/0/0.510
192.168.86.57/32 *[Local/0] 01:35:38
Local via ge-0/0/0.510
224.0.0.5/32 *[OSPF/10] 01:35:41, metric 1
MultiRecv

blair> show route table beer.inet.0 hidden
beer.inet.0: 8 destinations, 10 routes (8 active, 0 holddown, 2 hidden)
'''172.17.0.1/32''' ['''OSPF'''] 00:00:44, metric 2
> via '''shamlink.0'''
'''192.168.86.52/30''' ['''OSPF'''] 00:00:44, metric 2
> via '''shamlink.0'''

*''' ''Если у клиента с двух сторон разные area:'' '''
т.к. соседство по OSPF должно быть внутри одной area, то shamlink не поднимется.

По факту LSA3 и LSA5 - одинаковые по структуре - маршрут, но имеют разный приоритет при выборе активного пути.

То есть в случае, когда у клиента разные area - предпринимать ничего не нужно, итак все заработает.

==Domain ID==
OSPF Domain ID используется, когда передаются маршруты между одинаковыми или разными доменами через MPLS сеть. Domain ID передается как extended community внутри MP-BGP вместе с OSPF route-type и OSPF router ID community.

Фича позволяет передавать на удаленный конец LSA1, LSA2, LSA3 как LSA3.

Также передаются LSA5, LSA7 как LSA5.

Stub и totally-stubby не поддерживают такую фичу.

*''' ''Если у клиента:'' '''
#Одинаковые Domain ID.
#Есть другой протокол, из которого сеть пришла в OSPF как external.
#Внутри сети клиента по OSPF этот маршрут будет распространятся как LSA5.
#Между PE маршрут передается по iBGP, к удаленному PE приходит как LSA3.

Как исправить:

Вводится правило трансляции типов LSA:
*Если исходно маршрут пришел как LSA1, LSA2, LSA3 - его превращаем в LSA3.
*Если маршрут пришел как LSA5 - превращаем его в LSA5.

Как удаленный PE узнает что было с другой стороны?

BGP использует следующие extended community:
*OSPF route type - тип изначального LSA.
*OSPF Domain ID - обычно закодирован как 4 byte IP address
*OSPF router-id - требуется только при использовании ''sham-link''

Генерируется автоматически. Когда iBGP передает OSPF маршрут, роутер смотрит как исходно пришел маршрут, создает для него соответствующее community, куда записывает тип LSA.

Удаленный PE смотрит тип, применяет правило трансляции.

РЕ генерирует LSA3, когда route type - internal и передает Domain ID community в соответствии в тем, какой сконфигурирован в RI.

Если Domain ID не задан с обоих концов в VRF, то это тоже является совпадением по Domain ID.

PE при передаче CE LSA также помечает из '''route tag'''. Пример: '''tag 3489662039'''. Рассчитывается автоматически, но можно и задать вручную.
CE1> show route protocol ospf
inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
1.1.1.1/32 *[OSPF/150] 18:38:53, metric 0, '''tag 3489662039'''
> to 192.168.86.53 via ge-0/0/0.500
2.2.2.2/32 *[OSPF/150] 18:36:15, metric 0, '''tag 3489662039'''
> to 192.168.86.53 via ge-0/0/0.500
===Configuration===
[edit policy-options policy-statement export-vpn-beer term 1 then]
community add vpn-beer { ... }
+ community add domain-beer;
[edit policy-options policy-statement import-vpn-beer]
+ from community domain-beer;
[edit policy-options]
+ community domain-beer members domain-id:1.1.1.1:0;
[edit routing-instances beer]
+ routing-options {
+ router-id 10.200.86.7;
+ }
[edit routing-instances beer protocols ospf]
+ domain-id 1.1.1.1;

*''' ''Если у клиента разные домены:'' '''
Правило трансляции действует, когда домен одинаковый. При передаче пакета генерируется еще одно специальное community, которое говорит, на удаленном PE: все пришедшие маршруты - LSA5.

Domain-ID одинаковые:
blair> show ospf database instance beer
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 172.17.0.2 172.17.0.2 0x80000035 103 0x22 0x4176 60
Router *192.168.86.57 192.168.86.57 0x80000004 102 0x22 0x2a53 48
'''Summary *172.17.0.1''' 192.168.86.57 0x80000003 102 0xa2 0xac55 28

При изменении Domain-ID с одной стороны - несовпадение doamin-id => маршруты прилетают как external (LSA5)
blair> show ospf database instance beer
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 172.17.0.2 172.17.0.2 0x80000038 23 0x22 0x3b79 60
Router *192.168.86.57 192.168.86.57 0x80000007 22 0x22 0x2456 48
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
'''Extern *172.17.0.1''' 192.168.86.57 0x80000001 10 0xa2 0x4984 36

*''' ''Если у клиента по краям нашего L3VPN - area1, которая в свою очередь подключается к area0 на сети клиента:'' '''
LSA3 дойдет до CE2 (area1), но ABR не отправит LSA3 в area0, т.к. это backbone area (splithorizing).
Поднимаем virtual-link.

При использовании '''IS-IS''' все проще: редистрибьюция из BGP в ISIS. В любом случае в ISIS получим внешний маршрут.
=CE<>PE IPv6=
p2p CE<>PE - ipv6 адрес.

на ядре MPLS на IPv4.

Нужно передавать ipv6 трафик.
*Для этого на PE<>CE настраиваем обычную eBGP на p2p-адресах [в рамках vrf, конечно же].
*На сессии PE<>RR (или PE<>PE) включаем ''family inet6-vpn unicast''.
*В VRF также нужно задать router-id. Делается либо через routing-options. Либо создаем новый lo.<x>, добавляем его в VRF. Он и будет router-id.
*На RR маршруты CE будут передаваться с next-hop self [должно быть настроено]. Чтобы RR смог отрезолвить next-hop, нужно каким-то способом добавить lo PE в таблицу inet6.3 адреса lo PE. (если на rr настроены протоколы динамической маршрутизации, то через них (OSPF, ISIS). Если нет таких, то можно прописать статикой с опцией receive).
*не забываем as-override на ebgp.
*Опционально: чтобы передавались direct маршруты, добавляем vrf-table-lable.

Будут использоваться таблицы:
''bgp.l3vpn-inet6.0'' - PE<>RR
''inet6.3'' - RR, PE
''<vrf-name>.inet6.0'' - PE<>CE, PE<>PE

Пример конфига:
*'''PE:'''
Interface Admin Link Proto Local Remote
lo0.2 up up inet 172.30.5.38 --> 0/0
inet6 fd17:f0f4:f691:5::26
ge-0/0/0.325 up up inet6 fc09:c0:ffee::d/126
fe80::aa08:aa01:4500:0/64

r8> show configuration routing-instances c3
instance-type vrf;
interface ge-0/0/0.325;
interface lo0.2;
route-distinguisher 172.30.5.8:300;
vrf-target target:54591:300;
vrf-table-label;
protocols {
group c3 {
type external;
peer-as 64601;
as-override;
neighbor fc09:c0:ffee::e;

r8> show configuration protocols bgp group ibgp-rr
family inet6-vpn {
unicast;

*'''RR:'''
rr> show configuration routing-instances
rib inet6.3 {
static {
route ::ffff:172.30.5.0/124 receive;

rr> show configuration protocols bgp
group ibgp-clients-1 {
family inet6-vpn {
unicast;

=Exchanging routes between VRF tables=
Если нам требуется передать маршруты из одного VRF в другой, в рамках одного маршрутизатора, можно осуществить такое двумя способами:
* включение '''auto-export''': задаем в [routing-options] в нужных VRF. При этом если внутри разных VRF указаны одинаковые vrf-target или vrf-import/export, то маршруты будут скопированы между VRF.

Либо если vrf-export одного instance будет совпадать c vrf-import другого instance.

Короче, в этом методе обмен маршрутов происходит только при совпадении targets, т.е. делается на per-table основе. Передаются ВСЕ маршруты.

Работает только на локальном роутере (не передается по MP-BGP). Правда если для route leaking править vrf-export политику (добавляя туда еще community таблицы, в которую будут передаваться маршруты) то маршрут улетит и на другие PE для этого vrf. В общем, если нужен обмен только на локальном PE через auto-export, то правь именно vrf-import политику в нужных vrf.

blair# run show route table oak.inet.0
oak.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
13.13.13.13/32 *[Static/5] 00:00:09
Discard
192.168.86.64/30 *[Direct/0] 00:00:07
> via ge-0/0/0.600
192.168.86.65/32 *[Local/0] 00:00:07
Local via ge-0/0/0.600
После включения:
blair# run show route table oak.inet.0
oak.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
13.13.13.13/32 *[Static/5] 00:01:57
Discard
15.15.15.15/32 *[Static/5] 00:00:08
Discard
192.168.86.64/30 *[Direct/0] 00:01:55
> via ge-0/0/0.600
192.168.86.65/32 *[Local/0] 00:01:55
Local via ge-0/0/0.600
192.168.86.68/30 *[Direct/0] 00:00:08
> via ge-0/0/0.610
192.168.86.69/32 *[Local/0] 00:00:08
Local via ge-0/0/0.610

* использование '''rib-groups''': per-protocol основа.
Если юзаем vrf-target - то автоматом маршруты скопируются между таблицами в рамках роутера и далее улетит по сети.

Если юзаем vrf-import | vrf-export - с выделением в политике конкретных префиксов - то только желаемые префиксы полетят далее, а все остальное скопируется только в рамках роутера.
(то есть политикой мы не навесим target для всего ненужного, а для всего нужного навесим).

Последним термом в таких политиках должен быть then reject.

При использовании в rib-group только import-rib первой определяется таблица - источник префиксов. Далее указываются таблицы, куда будут скопированы префиксы.
Следовательно, копирование маршрутов производится в одну сторону. Если нужен взаимный обмен префиксами - пишем разные rib-groups, навешиваем каждую в свой vrf.

blair# top show | compare
[edit routing-options]
+ rib-groups {
+ oak-to-spruce {
+ import-rib [ oak.inet.0 spruce.inet.0 ];
+ }
+ spruce-to-oak {
+ import-rib [ spruce.inet.0 oak.inet.0 ];
+ }
+ }
[edit routing-instances oak routing-options]
+ '''interface-routes''' {
+ rib-group inet oak-to-spruce;
+ }
[edit routing-instances spruce routing-options]
+ '''interface-routes''' {
+ rib-group inet spruce-to-oak;
+ }
При подобной настройке: будут передаваться только интерфейсные маршруты.

Если требуется копировать статические маршруты, то rib-group добавляем в:
sset routing-instances ''spoke'' routing-options static rib-group oak-to-spruce

Если требуется копировать протоколы маршрутизации, то rib-group добавляем в:
set routing-instances ''spoke'' protocols bgp family inet unicast rib-group ''c2-to-c1''
или
set routing-instances ''vrf-ospf'' protocols ospf rib-group ''c1-to-c2''
[тут речь идет только от клиентов, включенных по тому или иному протоколу, НО не про маршруты, полученные по MP-BGP от RR]

Если требуется копировать маршруты, известные по протоколам маршрутизации, то потребуется также скопировать и direct маршруты, для резолвинга.
'''NOTE:''' rib-groups applied under the [routing-options interfaces-routes] stanza copies routes in both directions.
The order of the ribs in rib-groups definition does not matter.

С помощью policy можно контролировать какими маршрутами обмениваться.
set routing-options rib-groups oak-to-spruce import-policy oak-policy

set policy-options policy-statement oak-policy term 1 from route-filter 1.1.1.1/32 exact
set policy-options policy-statement oak-policy term 1 to spruce.inet.0
set policy-options policy-statement oak-policy term 1 then accept
set policy-options policy-statement oak-policy term 2 to spruce.inet.0
set policy-options policy-statement oak-policy term 2 then reject

=Hub-and-spoke=
Hub - центральный узел, с которым соединяются остальные spoke.

'''Смысл:''' spoke-spoke связь идет не напрямую, а обязательно проходит через hub.

[[Файл:Hub-and-spoke topology.png]]

Как и для обычного L3VPN нужно решать проблему с AS path loop detection (as-override, remove-private).

Или при использовании OSPF между CE <> PE следить за правильностью Domain ID.

Могут возникнуть сложности, если в топологии будут spoke, подключенные напрямую к hub. Или к PE будет подключаться несколько spoke.

Требуется создание двух RI: hub, spoke. Hub PE будет иметь 2 линка в сторону CE (можно 2 unit на физическом линке).

2 RT, 2 RD (если в схеме используем RR).

'''Control plane''': маршруты от spoke PE передаются в spoke vrf на hub PE. Hub PE передает маршруты hub CE. Hub CE в свою очередь передает эти маршруты в hub instance hub PE. Hub PE передает маршруты к Spoke site.

=QoS=
На '''ingress''' доступны: firewall filtering, classification, rate limiting, precedence mapping.

На '''egress''' можно использовать: filtering, но дополнительно добавив ''vrf-table-label'', ''vt-interface''.

EXP bits в VRF метке выставляются на основании: firewall classification, IP precedence, ingress interface.

outer label (RSVP), может быть назначена CoS конфигурацией.

=Internet Access=
==Option 1==
PE роутеры не участвуют в роутинге интернета, т.е. PE роутеры не обмениваются маршрутами между master и vrf таблицами маршрутизации. Предоставление интернета в рамках опции 1 называется "non-VRF Internet Access".

Настраиваются политики на PE + static route [в routing-instance <name> routing-options] с next-hop table inet.0. Оттуда уже резолвиться в инет.

===Option 1.1===
[[Файл:Opt 1.1.png|700px]]

"Пусть строят как хотят". VPN-клиенты не получают интернет от провайдера VPN-услуг, а подключают в каждой локации IPS1 или ISP2 в отдельный маршрутизатор, и далее разруливают трафик как хотят. В каждой локации свой интернет.

По-умолчанию Juniper поддерживает именно эту опцию.

===Option 1.2===
[[Файл:Opt 1.2.png|700px]]

В отдельном влане (CE-PE) идет L2 по провайдерской сети до провайдерского роутера, который раздает интернет. Можно вообще отдельным кабелем воткнуться между CE и PE.
Сам PE ничего не знает про интернет и не обязан хранить маршруты в интернет, либо маршруты клиента, чтобы маршрутизировать что-либо в ту или иную сторону.
В Juniper для этого предусмотрено либо L2VPN либо CCC.

Все VPN-ы, подключенные к данному PE пойдут в интернет одинаковым путем.

==Option 2==
PE имеет частичный или полный доступ в инет. РЕ будет перемещать маршруты между VRF и main instance.
===Option 2.1===
[[Файл:Opt 2.1.png|700px]]

"Отдельный интерфейс для интернета и для VPN-трафика". В отличие от Option 1.2, здесь сам PE маршрутизирует клиента в интернет. Хотя подключается так же - через отдельный влан или даже физический интерфейс. Маршруты в интернет хранятся в VRF PE маршрутизатора. Стало быть, маршруты клиента с его белыми адресами тоже (для обратного трафика).

===Option 2.2===
[[Файл:Opt 2.2.png|700px]]

"Отдельный интерфейс для обратного (который идет от Интернета к клиенту) трафика".

Суть в том, что в VRF содержатся маршруты в интернет (0/0, или чуть больше, или вообще FullView в худшем случае), и отдаются клиенту. Дальнейший путь клиентского трафика, который не подошел к VPN-маршрутам, лукапится из главной таблицы через операцию "next-table" (т.е. 0/0 в VRF с next-table master в качестве некст-хопа. Тогда все, что не проанонсировано удаленными сайтами пойдет по дефолту).
Но все-равно нужен отдельный линк или влан между PE-CE, чтобы обратный трафик как-то попадал к клиенту.
Т.е. еще раз - трафик от клиента в интернет идет через VRF, некстхоп лукапится из master (если некстхоп - не клиентский узел на удаленном сайте), а обратно трафик идет уже минуя VRF через отделный влан/линк. Как PE различает какой трафик vpn а какой - internet: в VRF создается default route в next-table master в качестве некст-хопа. И дальше уже понятно. Да?

===Option 2.3===
[[Файл:Opt 2.3.png|700px]]

"Все через одну дырку (Single VRF for VPN and Internet Access)".

Отдельного интерфейса не требуется. Опять же, не-ВПН трафик клиента будет лукапиться в master-е и маршрутизироваться по тамошним маршрутам в интернет. А чтобы схема работала и в обратную сторону, все клиентские анонсы будут редистрибьюированы в master.

Если клиент не использует приватные адреса, то VPN и inet связность может быть достигнута с помощью одного VRF и с помощью копирования всех маршрутов из VRF в main instance (RIB-groups).

Также для корректной работы такой схемы требуется, чтобы внутри VRF было перенаправление в main instance с помощью static route -> next-table.

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

==Option 3==
[[Файл:Opt 3.png|700px]]

У клиент один из CE имеет интернет, и шлет default route удаленным CE. Удаленные CE доступаются и до ВПН-а и до интернета через один интерфейс.
Главный CE, когда получает пакеты, назначенные в Интернет, просто шлет их туда через свой НЕ-VRF интерфейс [интерфейс в inet.0]. Ну и - да, тот CE, у которого есть интернет должен к провайдеру подключиться и через VRF и через НЕ-VRF интерфейс. То, есть, через отдельный влан. Как-то так.

у Hub-PE в рамках vrf настраивается default, смотрящий в сторону ce-vpn. Дефолт анонсится остальным PE.

Если клиенту требуется NAT, то при такой схеме NAT делается на CE.

=Дополнительная информация=
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]
*[[L2VPN]]
*[[Реализация MPLS в ядре сети]]

Traffic engineering

2021-07-15T18:28:35Z

Наталия Бобкова:

{{#description2:CSPF алгоритм. LSP Metrics. Link coloring. Losse, Strict LSP hops. LSP Bandwidth. LSP Install, active. IGP shortcuts. Traffic-engineering bgp. Policy-based LSP. LSP TTL. Информация для подготовки к экзаменам Juniper.}}

=CSPF=
'''CSPF''' - способ автоматически рассчитать explicit path.
*Модифицированный shortest-path-first алгоритм.
*Интегрирует TED данные: IGP топология, доступная полоса, административные группы. Определяет оптимальный путь и порядок настройки в зависимости от ограничений юзера.
*Убирает из пути неподходящие линки, а на основании подходящих линков производит поиск кратчайшего пути.

==Без CSPF==
(просто задаем все параметры руками):
*Запрашивает резервирование ресурсов у нижестоящих роутеров и оповещение этих роутеров как и где будет установлена сессия.
*Некоторые объекты используются для определения что требуется зарезервировать:
:*Label object: резервирует MPLS label
:*Sender Tspec Object: запрашивает зарезервированную полосу
*ERO:
:*Когда ERO не задан руками, path message оправляется с пустым ERO по кратчайшему пути IGP.
:*Чтобы ERO не передавался пустым, его требуется задать руками.
*Bandwidt reservation (Сигнализируется Sender Tspec объектом):
:* Каждый роутер по пути определяет сможет ли он выделить нужную полосу. Если нет возможности, то LSP не устанавливается.
:* По умолчанию, LSR не полисит трафик, а просто выделяет требуемую полосу. Можно включить:
[protocols mpls]
'''auto-policing class all drop'''
либо
[protocols mpls label-switched-path lagavulin-to-oban]
to 10.200.86.3
bandwidth 35m
no-cspf
'''policing filter 35m'''

TE работает в рамках одной area. Чтобы не нарушать само понятие area. Но есть функции, которые дают возможность строить туннели между area (но при этом все-равно не будут работать функции защиты трафика).

==При включенном CSPF==
На ''ingress router'' с включенным CSPF будет воспроизведен следующий алгоритм:
#За актуальной топологией сети следит IGP и передает информацию в TED через расширение IGP (для ISIS - TLV tuples, для OSPF LSA Type 10)
#Топология сети хранится в TED
#Инженер задает условия для построения туннеля
#CSPF рассчитывает кратчайший путь, учитывая заданные ограничения инженера
#Роутер создает ERO
#Роутер передает ERO в RSVP, чтобы построить туннель

'''TED''' содержит в себе:
* топологию
* bandwidth
* colors
* link priority info
show ted database extensive

'''Какие ограничения может задать инженер''':
*bandiwdth
*hop count
*administrative groups (colors)
*priority
*explicit route

==CSPF алгоритм==
#Отбрасываем линки с недостаточной полосой
#Отбрасываем линки, не содержащие ''include color''
#Отбрасываем линки, содержащие ''exclude color''
#Рассчитываем кратчайший путь по IGP, но с учетом ERO, если задан
#Если в результате получилось несколько ''path'', то выбираем с наименьшим кол-вом хопов
#Если все-равно осталось несколько вариантов, то по дефолту ''path'' выбирается случайным образом. Не дефолт: ''most-fill/least-fill''.
#Роутер передает рассчитанный ERO к RSVP

=LSP Metrics=
По дефолту CSPF использует метрики кратчайшего IGP пути (или te-metric в случае с IS-IS).

Но эти значения можно переписать с помощью статических метрик.

Есть возможность задавать статические метки для LSP, аналогично как и для IGP. Можно использовать для разделения основная/резервная LSP.

Также есть возможность задать метрику и для LSP в рамках IGP протокола. Но лучше использовать метрику только в одном месте, во избежание неверного форвардинга.
[edit protocols mpls]
label-switched-path dalwhinnie-to-oban
to 10.200.86.3;
metric 20;
link-protection;

=Link coloring=
Поддерживается 32 административных группы. Admin groups хранятся в TED.

Можно ''раскрашивать'' линки в разные цвета и задавать path таким образом, чтобы он шел либо через конкретные цвета или исключая конкретные цвета.

Цвета задаются и назначаются на интерфейсы через ''admin-groups'' внутри ''protocols mpls''.

Интерфейс без настроенной admin-group - не принадлежит ни к одной из групп. '''[не используется для LSP как с include, так и с exclude параметрами]'''

Если не будет возможности построить LSP с заданными ограничениями по цветам, то LSP не построится =).
{{note|text=При построении link protection bypass, выбор пути не будет учитывать предпочтение по цветам, т.к. bypass LSP могут служить резервом для нескольких LPS. Однако, при использовании FRR, цвета будут учитываться.}}

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

Для корректной работы требуется, чтобы ''admin-groups'' были заданы на всех роутерах в MPLS домене одинаково.

При изменении admin group на интерфейсе, идущие через него LSP не будут из-за этого сразу же перестроены. Но новые LSP будут естественно строится в соответствие с этими настройками.

При изменении admin group для LSP, она сразу же перестроится.

==Configuration==
Можно настроить как на LSP, так и на path (primary или secondary)
dalwhinnie> show configuration protocols mpls
'''admin-groups {
gold 1;'''
}
label-switched-path dalwhinnie-to-oban {
to 10.200.86.3;
'''admin-group ''<include-all|include-any|exclude>'' gold;'''
}
interface ge-0/0/2.0 {
'''admin-group gold;'''

Логика при использовании нескольких цветов:
'''между строками - Logical AND'''
[edit protocols mpls label-switched-path test to 10.200.86.3]
set admin-group include-all [gold bronze] - '''Logical AND'''
set admin-group include-any [customer premium] - '''Logical OR'''
set admin-group exclude [red green] - '''Logical OR'''

=Losse, Strict LSP hops=
Параметры поля ERO (explicit route object). '''Ручной TE'''.

Для primary и secondary LSP можно задавать ''loose'' и ''strict'' хопы. Порядок имеет значение.

Также эти параметры можно задавать и для bypass LSP (внутри protocols rsvp).

'''Strict''' - роутер, чей ip мы указываем, должен быть подключен напрямую. Ищем среди direct адресов нашего роутера. Указываем ip из p2p сети с соседом (на некоторых версиях софта можно и Lo, но лучше не рисковать).

'''Loose''' - существует где-то в сети, без разницы как маршрут дойдёт до него, как пойдёт после него, важно, чтобы путь построился через него. Lo этого роутера будет доступен через IGP. В ERO до loose туннель будет построен по метрикам, после loose - тоже по метрикам. Указываем Lo желаемого роутера.

Если задаём ''path'' с помощью strict, то лучше указать полностью все хопы пути.

Если в path для хопов явно не указываем loos/strict и т.п., то по дефолту хоп будет использоваться как strict.

==Configuration==
dalwhinnie> show configuration protocols mpls
label-switched-path dalwhinnie-to-oban {
to 10.200.86.3;
link-protection;
primary via-blair;
}
path via-blair {
192.168.86.5 strict;
192.168.86.9 strict;
192.168.86.25 strict;

dalwhinnie> show configuration protocols rsvp
interface ge-0/0/2.0 {
link-protection {
path {
192.168.86.29 strict;
192.168.86.1 strict;
192.168.86.41 strict;
192.168.86.46 strict;

=LSP Bandwidth management=
По умолчанию передается физическая скорость интерфейса, но можно менять.
==Static LSP bandwidth==
Задаем для static LSP полосу в ручном режиме. При построении LSP заданная полоса будет резервироваться => если где-то на пути не будет хватать пропускной способности, то LSP не построится. Не самый удобный способ, но все же..
[edit protocols mpls]
lagavulin# show
label-switched-path lagavulin-to-oban {
to 10.200.86.3;
'''bandwidth 150m;'''
primary via-blair;

==Automatic Bandwidth Allocation==
Позволяет маршрутизатору мониторить актуальный трафик, проходящий по LSP и изменять конфигурацию этого LSP для поддержания нужного кол-ва трафика. Роутер мониторит пики загрузки за определенный период времени. По истечению данного времени LSP резервирует нужную полосу. Используется make-before-brake и SE-style.

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

[edit protocols mpls]
lagavulin# show
statistics {
file auto-bw;
interval 600;
auto-bandwidth;
}
label-switched-path lagavulin-to-oban {
to 10.200.86.3;
auto-bandwidth {
adjust-interval 7200;
adjust-threshold 20;
minimum-bandwidth 64k; - min полоса для LSP
maximum-bandwidth 150m; - max полоса для LSP
}

*adjust-interval - по окончанию интервала - процесс вычисления полосы и перестроение LSP
*adjust-threshold 20 - процентное значение отклонения от настроенной static bandwidth на LSP. Если после перерасчета полосы разница между статик bandwidth и рассчитанной >= adjust-threshold, то LSP переустанавливается.

MPLS statistics обязательно должна быть включена, чтобы работала auto-bandwidth.

Для того, чтобы вручную обновить и подогнать bandwidth:
request mpls lsp adjust-autobandwidth name lagavulin-to-oban-prime

'''Monitor-only'''

Если требуется только мониторинг используемой полосы LSP, без изменения настроек.
[edit protocols mpls]
lagavulin#
show label-switched-path lagavulin-to-oban-prime to 10.200.86.3;
bandwidth 150m;
auto-bandwidth {
adjust-interval 86400;
'''monitor-bandwidth;'''
'''Полезные команды'''
> show ted database 10.200.86.3
> show mpls lsp name lagavulin-to-oban extensive
10.200.86.3
From: 10.200.86.7, State: Up, ActiveRoute: 0, LSP name: lagavulin-to-oban ActivePath: via-blair (primary)
'''Max AvgBW util: 111.402Mbps''', Bandwidth Adjustment in 6302 second(s).
*Primary via-blair State:Up Priorities: 7 0
'''Bandwidth: 90.4322Mbps'''
> request mpls lsp adjust-autobandwidth name "lagavulin-to-oban"
> show log messages | match "bandwidth changed"
> show rsvp interface
Обычно ''adjust-interval'' выставляется достаточно большим, из-за этого в случае аварии на сети и увеличении трафика в LSP не сразу происходит подстройка ''bandwidth''. Можно исправить с помощью ''adjust-threshold-overflow-limit''. Позволяет задать лимит на число последовательных переполнений. Когда лимит исчерпан, LSP настраивает bandwidth и таймер adjust-interval обнуляется.

Когда исчерпан лимит:
# Max AvgBW util > LSP bandwidth ?
# Max AvgBW util увеличилось больше чем adjust-threshold?

'''В итоге:''' ''adjust-interval'' - позволяет более точно вручную управлять bandwidth, а ''adjust- threshold-overflow-limit'' - в автоматическом режиме.
{{note|text=''adjust-threshold-overflow-limit'' может только увеличивать полосу, но не уменьшать ее. =)}}

==Most-fill/least-fill/random==
Определяем относительную разгруженность линка.
{{note|text=available bandwidth ratio = (available bandwidth)/(reservable bandwidth)}}

Пример рассчета available bandwidth ratio для 1G линка, при зарезервированной полосе 430 Мбит:

'''(1000-430)/1000 = 57'''

57 - процент свободной полосы линка.

'''Most fill''' - предпочтительны LSP с наибольшей загрузкой (мало свободной полосы). С низким ''available bandwidth ratio''

'''Least-fill''' - предпочтительны LSP с наименьшей загрузкой (более свобдны). С высоким ''available bandwidth ratio''

'''Random''' - поведение по умолчанию.

Хорошим тоном является использование одинакового поведения для всех LSP в одном домене.

[edit protocols mpls]
lagavulin# show
label-switched-path lagavulin-to-oban {
to 10.200.86.3;
'''most-fill;'''
primary via-blair;}

=Route Table and LSP Integration=
Если PE использует next-hop self и т.о. рассылает анонсы внешних сетей, где в качестве next-hop указан его Lo, то проблемы с передачей трафика до внешних сетей через LSP не будет. Т.к. в inet.3 присутствуют туннели до всех Lo внутри нашего домена.

Но если на PE не производится процедур типа next-hop self, то другие роутеры будут посылать трафик до внешних сетей, опираясь на IGP.

==Install, active==
Насильно указываем сеть, которой принадлежит next-hop, как доступную через LSP.

Пример: CE анонсирует 5.5/16, PE принимает префикс, в качестве next-hop указан ip из p2p сети между PE<>CE - 192.168.90.12/30. Анонс разлетается по всей сети, но про 192.168.90.12/30 другие роутеры знают через IGP.

Чтобы направить трафик до 5.5/16 через LSP, включаем:
[edit protocols mpls]
label-switched-path dalwhinnie-to-oban {
to 10.200.86.3;
'''install 192.168.90.12/30;'''
Теперь трафик до 5.5/16 будет идти по LSP, но трафик до 192.168.90.12/30 все-равно пойдет по IGP, из-за того, что BGP производит только resolve next-hop внутри inet.3. То есть по сути ''Active'' дает возможность использовать LSP для форвардинга, используя inet.3.

Добавляем ''active'' чтобы запись о 192.168.90.12/30, доступная через LSP, переместилась из inet.3 в inet.0, тогда и трафик до 192.168.90.12/30 пойдет через LSP.
[edit protocols mpls]
label-switched-path dalwhinnie-to-oban {
to 10.200.86.3;
'''install 192.168.90.12/30 active;'''

==IGP shortcuts==
Благодаря настройкам выше трафик до Lo идет через LSP, но трафик где next-hop = ip p2p линка, все еще используется IGP.
[edit protocols ospf]
set traffic-engineering shotcuts

[edit protocols isis]
set traffic-engineering family inet shortcuts

Минусы:
# Нет контроля, в отличие от ''install'', ''active''.
# Требуется настройка на всех роутерах в домене.

==Traffic-engineering bgp==
Дефолтное поведение.

==Traffic-engineering bgp-igp==
'''Перенесет''' все маршруты из inet.3 в inet.0. Прилетевшие новые маршруты из inet.3 перекроют старые аналогичные маршруты из inet.0, т.к. протоколы LDP и RSVP имеют лучший preference.

Этот метод используется в целях обеспечения всей маршрутизации в сети по mpls-lsp (LDP и RSVP signalled).

Но в этом варианте не работают VPN, основанные на MPLS [Inet.3 теперь пуста]. Применяется не к отдельным LSP, а глобально.

[edit protocols mpls]
traffic-engineering ?
bgp
'''bgp-igp'''
bgp-igp-both-ribs
mspl-forwarding

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

Но в inet.3 старые маршруты останутся, поэтому этот способ годится, если в сети нужны VPN-сервисы.

[edit protocols mpls]
traffic-engineering ?
bgp
bgp-igp
'''bgp-igp-both-ribs'''
mspl-forwarding

==Traffic-engineering mpls-forwarding==
'''Скопирует''' все маршруты из inet.3 в inet.0, но и старые маршруты в inet.0 оставит для совместимости с некоторыми политиками маршрутизации (то есть эта функция убирает "затмение IGP маршрутов"). Однако, фактически, форвардинг будет происходить по новым маршрутам.
Для индикации того, какие маршруты в 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

=Advertising LSPs directly into the IGP=
Позволяет передавать информацию об LSP, как о p2p интерфейсе. Это позволяет upstream роутеру использовать LSP для рассчета кратчайшего пути.

Внутри протокола IGP задаем LSP, аналогично интерфейсам, с определенной метрикой. Не забываем, что LSP однонаправленные => требуется аналогичные LSP построить в обратном направлении.

IGP будет распространять маршрут как: LSA 1 Type / ISIS TLVs.
[edit protocols ospf]
lagavulin# show traffic-engineering; area 0.0.0.0 {
interface lo0.0;
label-switched-path lagavulin-to-oban {
metric 2; }
label-switched-path lagavulin-to-tormore {
metric 2;
} }
{{note|text=Обычно одновременно не используют IGP shotcuts и LSP advertisment into IGP.}}

=Policy-based LSP=
Назначаем конкретным префиксам next-hop конкретную LSP. Хорошо подходит для случаев, когда на сети между двумя хостами есть несколько LSP и нужно распределить трафик между ними.

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

[edit policy-options]
lagavulin# show
policy-statement to-oban-lsps {
term 1 {
from {
protocol bgp;
route-filter 172.16.0.0/24 orlonger;
route-filter 172.16.1.0/24 orlonger;
}
then {
'''install-nexthop lsp lagavulin-to-oban-1;'''
accept;
}
}
term 2 {
from {
protocol bgp;
route-filter 172.16.2.0/24 orlonger;
route-filter 172.16.3.0/24 orlonger;
}
then {
'''install-nexthop lsp lagavulin-to-oban-2;'''
accept;
}
[edit routing-options]
lagavulin# show
forwarding-table {
export to-oban-lsps;

=TTL=

==default==
*По дефолту на каждом хопе (и внутри lsp тоже) значение ttl = 1.
*При этом не ingerss роутере IP TTL копируется в MPLS TTL, при прохождении через LSP -1, IP TTL остается неизменным. На egress роутере значение TTL копируется обратно из MPLS в IP.

==no-decrement-ttl==
*Только для Juniper.
*Только на ingress роутере.
*Можно применять в разные иерархии (глобально mpls, lsp, path)
*IP TTL уменьшается только на egress роутере.
*MPLS TTL устанавливается в 255, значение MPLS TTL не перезаписывается в IP TTL.
*Работает только для RSVP.

'''До'''
P1-2> traceroute 172.21.2.1 source 10.12.0.1
traceroute to 172.21.2.1 (172.21.2.1) from 10.12.0.1, 30 hops max, 40 byte packets
1 192.168.0.37 (192.168.0.37) 20.150 ms 19.244 ms 14.906 ms
2 172.30.0.45 (172.30.0.45) 20.139 ms 19.538 ms 14.947 ms
MPLS Label=300368 CoS=0 TTL=1 S=1
3 172.30.0.17 (172.30.0.17) 29.722 ms 29.692 ms 29.925 ms
MPLS Label=300624 CoS=0 TTL=1 S=1
4 172.30.0.14 (172.30.0.14) 34.978 ms 34.501 ms 30.472 ms
5 172.21.2.1 (172.21.2.1) 40.131 ms 45.097 ms 39.280 ms

'''После'''
P1-2> traceroute 172.21.2.1 source 10.12.0.1
traceroute to 172.21.2.1 (172.21.2.1) from 10.12.0.1, 30 hops max, 40 byte packets
1 192.168.0.37 (192.168.0.37) 14.851 ms 15.075 ms 9.682 ms
2 172.30.0.14 (172.30.0.14) 35.521 ms 33.829 ms 29.991 ms
3 172.21.2.1 (172.21.2.1) 40.235 ms 29.352 ms 39.868 ms

==no-propogate-ttl==
*Мультивендорная фича.
*Должна быть сконфигурирована на egress роутере, а т.к. им может стать любой роутер => конфигурируем на всех роутерах.
*Применяется только глобально в protocol mpls иерархии.
*Если LSP уже установлен, то после применения команды, то к нему не применится команда.
*Работает и для RSVP и для LDP.
==no-vrf-propogate-ttl==
*Включаем внутри VRF.
*В документации точно не нашла где включать, но у меня заработало при включении на ingress внутри VRF. На egress при этом не была включена эта функция.
set routing-instances ce1 no-vrf-propagate-ttl

=Дополнительная информация=
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]
*[[Отказоустойчивость и оптимизация в MPLS]]
*[[Реализация MPLS в ядре сети]]

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

2021-07-15T18:27:43Z

Наталия Бобкова:

{{#description2: Link Protection. Configuration. Node-link Protection. Configuration. Fast Reroute. Configuration. Secondary path. Configuration. Loop-Free Alternates in IGPs. Priorities and Preemption. Optimization. Adaptive mode. Материалы для подготовки к экзаменам Juniper Networks}}
Без включения каких-либо функций защиты: трафик будет дропаться каждый раз, когда будет падать LSP.

Время:
*PE должен обнаружить падение линка, оправить ResvTear к ingress роутеру.
*Ingress перестает отправлять Path и Resv, чтобы удалить LSP.
*LSP удаляется из inet.3 => L2VPN, L3VPN становятся нерабочими.
*ingress пытается установить новый LSP.
*Если новый LSP удается установить, то LSP добавляется в inet.3, L2VPN, L3VPN - начинают работать.
*Трафик пошел по новому LSP.

Для того, чтобы в случае возникновения аварии не было большого простоя, были внедрены некоторые механизмы защиты.

=Link Protection=
Защищает от падения линка между роутерами, участвующими в RSVP LSP. Когда сконфигурирован link protection, каждый роутер пытается найти обходной путь до следующего в LSP роутера.

Такой обходной путь называется ''next-hop bypass LSP''. Каждый обходной путь устанавливается только после того, как будет построена LSP. Когда линк падает, то переход на альтернативный путь инициирует роутер, который зафиксировал падение линка и который является ближайшим к ingress роутеру.

Такой роутер-инициатор называют '''PLR''' - ''point of local repair''. После того, как трафик пройдет по обходному пути, он вернется на путь изначального LSP. Когда PLR переключает трафик на bypass LSP, он сигнализирует об этом ingress роутеру. Ingress пытается найти и установить другой primary path для LSP.

Есть возможность сконфигурировать bypass руками.

Что происходит с метками: в случае падения линка, на PLR производится swap метки (согласно LSP), но сверху добавляется еще одна метка (push 30880 (top)) и пакет отправляется на egress интерфейс для bypass пути. Также bypass LSP использует PHP, поэтому на предпоследнем хопе верхняя метка будет снята и дальше пакет будет следовать меткам первоначального LSP.

Плюсы:
* Быстро отрабатывает
* Масштабируемость: для резервировании большого кол-ва LSP можно обойтись несколькими обходными ''next-hop bypass LSP''.

Минусы:
* Для работы link protection требуется включение этой функции на всех роутерах, внутри протокола rsvp, которые будут участвовать в построении LSP.

==Configuration==
[edit protocols mpls]
label-switched-path dalwhinnie-to-oban {
to 10.200.86.3;
link-protection;
}
[edit protocols rsvp]
interface all {
link-protection;
}
Хорошей практикой является включение link protection внутри protocols RSVP на всех интерфейсах, внутри RSVP домена.

Смотрим что происходит с метками для обходного пути на PLR роутере.
glenlivet> show mpls lsp transit
Transit LSP: 1 session
To From State Rt Style Labelin Labelout LSPname
10.200.86.3 10.200.86.5 Up 0 1 SE '''300544''' 300624 dalwhinnie-to-oban

glenlivet> show route label '''300544''' detail
mpls.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
300544 (1 entry, 1 announced)
*RSVP Preference: 7/1
Next hop type: Router, Next hop index: 262147
Address: 0x9440488
Next-hop reference count: 2
Next hop: 192.168.86.9 via ge-0/0/0.60 weight 0x1, selected
Label-switched-path dalwhinnie-to-oban
Label operation: '''Swap 300624'''
Next hop: 192.168.86.45 via ge-0/0/0.40 weight 0x8001
'''Label-switched-path Bypass->192.168.86.9'''
'''Label operation: Swap 300624, ''Push 300320(top)'' '''
Label TTL action: prop-ttl, prop-ttl(top)
State: <Active Int>
Local AS: 1111
Age: 6:06 Metric: 1
Task: RSVP
Announcement bits (1): 0-KRT
AS path: I

На следующем роутере (в нашем случае предпоследнем на обходном пути): смотрим ту запись в таблице mpls.0, которая подписана как 300320'''(S=0)'''. Эту запись смотрим, когда количество меток в пришедшем пакете >= 2. Если количество меток = 1, то смотрим запись без обозначения '''S=0'''.

mortlach> show route label 300320 detail
mpls.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
300320 (1 entry, 1 announced)
*RSVP Preference: 7/1
Next hop type: Router, Next hop index: 585
Address: 0x934cfd0
Next-hop reference count: 3
Next hop: 192.168.86.50 via ge-0/0/0.80 weight 0x1, selected
Label-switched-path Bypass->192.168.86.9
Label operation: Pop
State: <Active Int AckRequest>
Age: 13:38 Metric: 1
Task: RSVP
Announcement bits (1): 0-KRT
AS path: I
300320(S=0) (1 entry, 1 announced)
*RSVP Preference: 7/1
Next hop type: Router, Next hop index: 587
Address: 0x934cf40
Next-hop reference count: 2
Next hop: 192.168.86.50 via ge-0/0/0.80 weight 0x1, selected
'''Label-switched-path Bypass->192.168.86.9'''
'''Label operation: ''Pop'' '''
State: <Active Int AckRequest>
Age: 13:38 Metric: 1
Task: RSVP
Announcement bits (1): 0-KRT
AS path: I

=Node-link Protection=
Node-link protection для обхода упавшего роутера, участвующего в построении LSP, использует LSP ''next-next-hop bypass LSP'', которая обеспечивает альтернативный путь к next-hop'у next-hop роутера.

Если топология сети не позволяет построить ''next-next-hop bypass LSP'', или роутер является предпоследним в LSP, тогда роутер устанавливает просто ''next-hop bypass LSP''. Если же топология сети не поддерживает и такой bypass LSP, то ничего не создается и роутер просто продолжает использовать изначальный LSP.

Одновременно роутер не будет строить ''next-next-hop bypass LSP'' и ''next-hop bypass LSP''. Только что-то одно, в зависимости от топологии и возможностей оборудования.

При обнаружении падения узла, PLR просигнализирует об этому ingress роутеру и тот в свою очередь будет пытаться найти и установить новый primary LSP.

''Next-next-hop bypass LSP'' также может обеспечить резерв для нескольких LSP.

Т.к. в случае с ''next-next-hop bypass'' строится отдельно LSP, то никаких махинаций с навешиванием дополнительных меток не происходит (как в link protection). Используются обычные операции: push, swap, pop.

==Configuration==
[edit protocols mpls]
label-switched-path dalwhinnie-to-oban {
to 10.200.86.3;
node-link-protection;
}
[edit protocols rsvp]
interface all {
link-protection; - это требуется включать на всех роутерах в RSVP домене
}
{{note|text = Ниже в выводах команд ''show'' удалены лишние строки}}

'''Ingress router:''' После построения LSP, будет установлен обходной маршрут на случай падения соседнего роутера (glenlivet):
dalwhinnie> show mpls lsp ingress name dalwhinnie-to-oban detail
10.200.86.3
From: 10.200.86.5, State: Up, ActiveRoute: 0, LSPname: dalwhinnie-to-oban
ActivePath: (primary)
'''Node/Link protection desired'''
LSPtype: Static Configured
*Primary State: Up
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
192.168.86.5 S 192.168.86.9 S 192.168.86.25 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
10.200.86.6(flag=0x29) 192.168.86.5(flag=9 Label=299952) 10.200.86.1(flag=0x21) 192.168.86.9(flag=1 Label=300000) 10.200.86.3(flag=0x20) 192.168.86.25(Label=3)

dalwhinnie> show mpls lsp bypass
Ingress LSP: 2 sessions
To From State Rt Style Labelin Labelout LSPname
10.200.86.1 10.200.86.5 Up 0 1 SE - 300720 Bypass->192.168.86.5->192.168.86.9

dalwhinnie> show mpls lsp bypass name Bypass->192.168.86.5->192.168.86.9 detail
10.200.86.1
From: 10.200.86.5, LSPstate: Up, ActiveRoute: 0
LSPname: '''Bypass->192.168.86.5->192.168.86.9'''
LSPtype: Static Configured
Time left: -, Since: Mon Oct 31 01:33:31 2016
Type: Bypass LSP
Number of data route tunnel through: 1
Number of RSVP session tunnel through: 0
Explct route: 192.168.86.29 192.168.86.1 192.168.86.41 192.168.86.50
'''Record route: <self> 192.168.86.29 192.168.86.1 192.168.86.41 192.168.86.50'''

'''На транзитном:''' аналогично построится обходной путь на случай падения соседнего роутера (blair)
glenlivet> show mpls lsp bypass name Bypass->192.168.86.9->192.168.86.25 detail
10.200.86.3
From: 10.200.86.6, LSPstate: Up, ActiveRoute: 0
LSPname: '''Bypass->192.168.86.9->192.168.86.25'''
LSPtype: Static Configured
Time left: -, Since: Mon Oct 31 01:33:22 2016
Type: Bypass LSP
Number of data route tunnel through: 1
Number of RSVP session tunnel through: 0
Explct route: 192.168.86.45 192.168.86.21 192.168.86.33 192.168.86.38
'''Record route: <self> 192.168.86.45 192.168.86.21 192.168.86.33 192.168.86.38'''

'''На предпоследнем роутере:''' в связи с особенностями топологии (предпоследний роутер), будет создан не ''next-next-hop bypass'', а ''next-hop bypass''
blair> show mpls lsp bypass
Ingress LSP: 1 sessions
To From State Rt Style Labelin Labelout LSPname
10.200.86.3 10.200.86.1 Up 0 1 SE - 299936 Bypass->192.168.86.25

blair> show mpls lsp bypass name Bypass->192.168.86.25 detail
10.200.86.3
From: 10.200.86.1, LSPstate: Up, ActiveRoute: 0
LSPname: '''Bypass->192.168.86.25'''
Time left: -, Since: Mon Oct 31 00:22:03 2016
Type: Bypass LSP
Number of data route tunnel through: 1
Number of RSVP session tunnel through: 0
Explct route: 192.168.86.17 192.168.86.33 192.168.86.38
'''Record route: <self> 192.168.86.17 192.168.86.33 192.168.86.38'''

'''Разница между link protection и node-link protection:'''
* Node-link protection обеспечивает как link protection, так и node protection - в зависимости от топологии.
* Время реагирования на аварию в сети: link protection - PLR на основании hardware узнает, что упал линк и сразу переключит трафик на альтернативный путь. Node-link protection - распознает падение роутера, когда перестают приходить hello сообщения. То есть время реакции будет значительно отличаться.

=Fast Reroute=
На каждом промежуточном LSR создается LSP (detour) для обхода линка до следующей ноды и самой следующей ноды. Это проприетарный механизм Juniper. Кол-во потерянного трафика при аварии зависит от времени обнаружения падения ноды (или линка) и времени переключения на альтернативный путь.

При падении линка между узлами, роутер, ближайший к ingress сразу перестраивается на detour, построенный от себя. Потом сообщает ingress о падении линка и ingress в свою очередь переходит на какой-нибудь secondary path (не detour).

По умолчанию fast-reroute имеет ограничение в 6 хопов для построения path в сторону egress, но это значение можно менять ('''hop-count''').

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

set protocols mpls label-switched-path to-r6 fast-reroute '''(bandwidth 60m|bandwidth-percent 19)'''
{{note|text=По умолчанию detour LSP не наследует bandwidth. Чтобы наследовало - не знаю что нужно сделать, скорей всего задать такой же как в LSP. }}

При переходе на detour, в forwarding table нужно добавить next-hop, а это дополнительная задержка для оперативного перехода на detour.

Чтобы исключить это время, можно использовать балансировку ('''load balancing policy''').

Отличия от node-link-protection:
* При работе механизма frr лейбл не добавляется в стек к пакету. Вместо этого PLR производит swap на другой лейбл.
* Каждый detour защищает только свою конкретную LSP, что делает эту технологию менее масштабируемой. Но для сглаживания этой ситуации: когда разные роутеры строят detour, то эти detour могут использовать (разделять) одни и те же линки с целью слиться обратно в изначальный LSP...
{{note|text=Если у LSP, который защищен detour LSP, есть link-coloring ограничения, то detour их тоже унаследует.
Чтобы отключить это поведение: set protocols mpls label-switched-path to-r6 fast-reroute '''no-include-all'''}}
==Configuration==
Все настраивается только на ingress роутере.
[edit protocols mpls]
label-switched-path dalwhinnie-to-oban {
to 10.200.86.3;
fast-reroute;

[policy-options policy-statement lbalancing]
then {
load-balance per-packet;
accept
[routing-options forwarding-table]
export lbalancing;

Для поверки работоспособности detour:
show rsvp session detail
...
Detour is Up
Detour Record route: <self> 192.168.86.29 192.168.86.1 192.168.86.13 192.168.86.33 192.168.86.38

На транзитном:
glenlivet> show rsvp session transit detail lsp name dalwhinnie-to-oban
...
Detour Record route: 192.168.86.6 <self> 192.168.86.45 192.168.86.42 192.168.86.13 192.168.86.33 192.168.86.38

=Secondary path=
Строим параллельно дополнительные path для LSP.

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

Все secondary - одинаковы, порядок их использования зависит от расположения в конфигурации.

Восстановление упавших линков производится по очереди как они упали, не одновременно.

''Standby'' в конфигурации позволяет строить secondary LSP параллельно (по времени) с основным LSP.

В конфиге можно задать standby как на уровне label-switched-path, так и относительно конкретного secondary.

По дефолту все атрибуты primary path будут наследоваться secondary или standby path (priority/hold/bandwidth), если явно не указано другого поведения.

Можно изменить дефолтное поведение выбора активного пути:
*'''select uniconditional''' - более приоритетный - если хотя бы у одного path а рамках одной LSP будет задан этот параметр, то все path будут наследовать именно это поведение. Этот параметр позволяет оставаться активным даже тому path, который деградирует или вообще в состоянии down.
*'''select manual''' - это стандартный механизм, если path -> down, то активным выбирается другой path.

Если в конфигурации ''mpls path'' не указано дополнительных атрибутов (loose, strict, просто next-hop, ...), то просто будет построен лучший путь.

Всегда лучше задавать некие атрибуты, чтобы secondary не повторяли primary или друг друга.

Есть параметры, которые позволяют не сразу переходить на восстановленный primary LSP:
*'''retry-timer''': время между попытками поднять упавший primary path. По умолчанию - 30 сек
*'''retry-limit''': кол-во неудачных попыток поднять упавший primary path. По умолчанию - 0. Если лимит достигли, то требуется ручками рестарануть сигналинг.
*'''revert-timer''': min время, кот primary path должен быть в состоянии up, до того как трафик перейдет на него. По дефолту - 60 сек. Если устанавливаем в 0, то не перестраивается впринцепе.

'''Минусы:'''
* Долгое реагирование, из-за того, что ingress принимает решение о переходе на secondary LSP.

==Configuration==
[edit protocols mpls]  R1# show  label-switched-path R1-to-R4 {
to 10.0.0.3;
primary via-blair;
secondary via-tormore {
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;
} 
Проверка:
dalwhinnie> show mpls lsp name dalwhinnie-to-oban detail Ingress LSP: 2 sessions
...
'''*Primary via-blair State:Up'''
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.86.5 192.168.86.9 192.168.86.25
'''Standby via-tormore State: Up'''
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 192.168.86.29 192.168.86.1 192.168.86.13 192.168.86.33 192.168.86.38

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

Добавлением же опции «no-eligible-backup» можно предотвратить интерфейс от обслуживания бэкапного трафика.

Дополнительно требуется включить per-packet load-balancing чтобы все next-hop попали с таблицу форвардинга.

[edit protocols]
ps@dalwhinnie# show ospf
area 0.0.0.0 {
interface ge-0/0/0.0 {
link-protection;
interface ge-0/0/1.0 {
node-link-protection;

[policy-options policy-statement lbalancing]
then {
load-balance per-packet;
accept
[routing-options forwarding-table]
export lbalancing;

=Priorities and Preemption=
Процесс построения LSP может регулироваться приоритетами.

Разделяют 2 приоритета: '''setup priority''', '''hold priority'''.

Setup priority должен быть сильнее (ближе к 0), чтобы LSP имела право вперед других построиться.

0 - более приоритетный, 7 - менее приоритетный

Дефолтные настройки: setup = 7, hold = 0. По сути это отсутствие вытеснения.

setup не может быть сильнее hold.

Нормальная практика указывать одинаковый setup и hold priority.

Чтобы не происходило жесткого вытеснения с потерей трафика на более слабых LSP, можно использовать '''soft preemption'''.

'''Soft-preemption:''' при (перед) вытеснением LSP, пытается переустановить эту LSP по новому пути. Если это удается сделать, то трафик переходит на новую LSP, только после этого кладется старая.

Ingress router выставляет soft-preemption flag в RRO. Если функция не поддерживается всеми роутерами на пути построения LSP, то все-равно LSP установится.

[edit protocols mpls label-switched-path to-oban]
+ priority 5 2; ''(setup hold)''

=Optimization=
Без включенной оптимизации LSP перестраиваются только во время изменения топологии.

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

Правила нормальной оптимизции:
#CSPF метрика не должна быть выше
#Если метрика одинакова, то кол-во хопов должно быть меньше.
#Новый path не вызывает вытеснения.
#Не должно происходить усугубление заторов, для этого сравнивается available bandwidth на старых и новых линках, начиная с более загруженных.
#Уменьшает затор на 10%

'''Aggressive''': оптимизация только на основании метрик IGP.

mortlach# set protocols mpls ?
optimize-aggressive Run aggressive optimization algorithm based on IGP metric only
optimize-timer Periodical path reoptimizations (0..65535 seconds)

==Adaptive mode==
Меняет стиль резервирования полосы для LSP. Если указываем в настройках на уровне label-switched-path, то для резервирования bandwidth разных LSP можно использовать один физ линк. (общий линк для разных LSP.) Помогает избежать двойного подсчета одного и того же трафика на общем линке.

Но если задать adaptive на уровне primary или secondary path, то SE reservation будет работать только для primary или secondary path. То есть все-равно резервирование будет производиться дважды.

Работает по принципу ''make-before-break''. То есть включает в себя и функции soft-preemption.

#Устанавливает новый path с SE reservation (с тем же session ID).
#Передает трафик в новый path
#Кладет старый path

[edit protocols mpls label-switched-path ''test1'']
set adaptive

Типа резервирования:
*'''Fixed filter (FF)''': каждый session/sender/LSP имеет свой идентификатор. Каждая LSP резервирует свою bandwidth на линке.
*'''Shared Explicit (SE)''': Каждый session/sender/LSP имеет свой идентификатор. Но каждая LSP делит резервирование bandwidth с другими LSP на одном линке.
=Дополнительная информация=
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]
*[[Traffic engineering]]
*[[Реализация MPLS в ядре сети]]

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

2021-07-15T18:26:37Z

Наталия Бобкова:

{{#description2: Принцип работы протокола. Настройка. RSVP auto-mesh. P2MP. LDP. Соседство. Cisco. LDP tunneling. Процесс построения. Проверка. Информация для подготовки к экзаменам Juniper.}}
=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 включать нужно.}}

== Принцип работы протокола ==
LDP - автоматом строит full mesh туннели до соседей.
RSVP - не просто строит туннели, а использует для построения TE + используются механизмы защиты трафика: FastRerote, LinkProtection...

RSVP - протокол signaling.

RSVP инкапсулируется сразу в ip.

RSVP пакет стоит из объектов. Объект имеет тип, и поле данных.

Типы сообщений:
*Path: запрос, чтобы LSP была построена: от ingress
*Resv: Резервирует ресурсы для LSP: от egress
*PathTear: удаляет path state и сообщает об этом: от LSR, где упала LSP к downstream
*ResvTear: удаляет reservation state: от LSR, где упала LSP к upstream
*PathErr: сообщение с ошибкой: к upstream
*ResvErr: сообщение с ошибкой: к downstream

Объекты path message:
*SESSION_ID
*LABEL_REQUEST
*EXPLICIT_ROUTE: strict/loose list of routers
*RECORD_ROUTE: list of addresses of all routers in path
*SESSION_ATTRIBUTE
*RSVP_HOP: interface ip of router which send path message

Для работы RSVP нужно:
#Включить протокол RSVP
#Конфигурируем туннель только на ingress.

'''Ingress -> Egress:'''
При построении туннеля на Ingress (A) создается ip-пакет pathMessage, который состоит из:
# '''dst''': ip dst (192.168.0.4), по метриками внутреннего протокола узнает где конечный роутер.
# '''session ID''' - идентификатор rsvp сессии на control plane. Все rsvp роутеры, через которые строится туннель - ассоциируют все сообщения для туннеля по session ID. Генерируется ingress роутером, состоит из router ID + какое-то число.
# '''label request''': определяет поведение транзитных маршрутизаторов, заставляет резервировать метки для туннеля.

'''Transit router 1 (B):'''
1.Видит ''label request'', выделяет (запоминает, но никуда не записывает) для туннеля метку из свободных, ассоциирует ее с ''session ID''.

'''Transit router 2 (C):'''
# Видит ''label request'', выделяет (запоминает, но никуда не записывает) для туннеля метку из свободных, ассоциирует ее с ''session ID''.

'''Egress router (D):'''
# ''dst addres'' = его loopback => он последний. Резервирует метку 3 (по дефлоту).

Формирует '''ResvPath''' - основная его суть - проанонсировать зарезервированную метку предыдущему роутеру.

'''Egress -> Ingress:'''
resvPath: session ID из PathMessage, label: (то, что он зарезервировал) 3.

'''Transit 2 (C):'''
# По session ID определяет какую метку он зарезервировал (30).
# Смотрит в label, видит 3. Понимает, что он должен передавать к egress пакет с меткой 3.
# mpls.0: 30 swap 3 = 30 pop

'''Transit 1 (B):'''
# По session ID определяет какую метку он зарезервировал (20).
# Смотрит в label, видит 30. Понимает, что он должен передавать к egress пакет с меткой 30.
# mpls.0: 20 swap 30

'''Ingress (A):'''
# inet.0: 192.168.0.4: -> BGP, push 30

Туннель - это просто метки.

'''При падении линка между роутерами:'''
Генерируются pathTear (в сторону ingress) и resvTear (в сторону egress), чтобы все транзитные роутеры освободили метки, а ingress понял, что этого туннеля больше нет.

В это время IGP пересчитал топологию, ingress router увидел next-hop для egress роутера и rsvp заново начал строить туннель.

Keepalive: Ingress роутер раз в 30 сек (по дефолту) обновляет состояние с помощью посылки pathMessage.

resvMessage должен пройти по тому же пути, что и pathMessage.
Но маршрутизация может быть не симметричной.
отличие resv и path: dst add - не loopback конечных роутеров, а адрес предыдущего роутера из ERO (также предотвращает зацикливание).

Туннель может устанавливаться с требованиями к полосе.
Задается в bandwith - передается в объекте TSpec.

Если RSVP не может установить туннель, то на проблемном участке генерируется pathErr - сообщение с кодом ошибки.
Bandwith - только для сигнализации, реально полосу не ограничивает.

Если нужно провести траблшутинг, лучше делать тут:
set protocol rsvp traceoptions file RSVP-trouble flag all detail

RSVP поддерживает mtu discovery и fragmentstion на ingress роутере.

RSVP поддерживает аутентификацию (MD5)

RSPV может использовать Gracefull restart.

RSVP может работать как point-to-multipoint => можно исключить из ядра всякие multicast протоколы.

==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.
==RSVP auto-mesh==
Когда на сети используется RSVP, но для конкретных функций (L3VPN, VPLS, ...) требуется full-mesh, то чтобы не прописывать все LSP руками, можно использовать '''RSVP-full-mesh'''.

Строится, когда:
* От PE пришел iBGP маршрут (inet.0, VPLS, L3VPN)
* IP PE из определенного диапазона.
[edit routing-options]
dynamic-tunnels {
tunnel-1 {
rsvp-te tunnel-1 {
label-switched-path-template {
default-template;
}
destination-networks {
10.200.86.0/26;

В книге описано, что просто туннель не поднимется (лаба на mx80), т.к. требуется маршрут до Lo PE с меткой в inet.0. '''Решение:''' Нужно временно включить LDP и set protocols mpls traffic-engineering bgp-igp-both-ribs'', ждем пока построятся RSVP LSP, потом отключаем LDP.

Но по факту в лабе завелось и без дополнительных манипуляций с LDP (лаба на vSRX). =)

В итоге, когда приходят пакеты по iBGP, то до ''protocol next-hop'' (Lo PE, который должен попадать в dest-networks) автоматически поднимается туннель.
'''bgp.l3vpn.0''': 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
''10.200.86.3:1212:12.12.12.12/32''
*[BGP/170] 12:34:36, localpref 100, from 10.200.86.3
AS path: I
> to 192.168.86.1 via ge-0/0/0.30, label-switched-path '''10.200.86.3:dt-rsvp-tunnel-1'''

'''bgp.l2vpn.0''': 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
''10.200.86.9:1515:1:1/96''
*[BGP/170] 12:16:54, localpref 100, from 10.200.86.9
AS path: I
> to 192.168.86.1 via ge-0/0/0.30, label-switched-path '''10.200.86.9:dt-rsvp-tunnel-1'''

'''inet.3''': 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.200.86.0/26 *[Tunnel/300] 12:10:07
Tunnel
''10.200.86.3/32'' *[RSVP/7/3] 00:03:04, metric 4
> to 192.168.86.1 via ge-0/0/0.30, label-switched-path '''10.200.86.3:dt-rsvp-tunnel-1'''
''10.200.86.9/32'' *[RSVP/7/3] 00:03:04, metric 5
> to 192.168.86.1 via ge-0/0/0.30, label-switched-path '''10.200.86.9:dt-rsvp-tunnel-1'''

lagavulin> show mpls lsp name '''10.200.86.3:dt-rsvp-tunnel-1''' detail
Ingress LSP: 2 sessions
10.200.86.3
From: 10.200.86.7, State: Up, ActiveRoute: 0, LSPname: 10.200.86.3:dt-rsvp-tunnel-1
ActivePath: (primary)
PathDomain: Inter-domain
LSPtype: '''Dynamic Configured'''
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 4)
192.168.86.1 S 192.168.86.41 S 192.168.86.50 S 192.168.86.25 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
192.168.86.1 192.168.86.41 192.168.86.50 192.168.86.25

*Можно добавлять разные фичи TE:
[edit protocols mpls]
label-switched-path default-template {
template;
link-protection;

*Если до одного и того же Lo PE есть динамический и статический LSP, то будет выбран статический, т.к. у него ''preference 2'' меньше:
inet.3: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)
10.200.86.3/32 *[RSVP/7/'''[[1]]'''] 00:00:26, metric 4
> to 192.168.86.1 via ge-0/0/0.30, label-switched-path lagavulin-to-oban
[RSVP/7/'''[[3]]'''] 00:02:32, metric 4
> to 192.168.86.1 via ge-0/0/0.30, label-switched-path 10.200.86.3:dt-rsvp-tunnel-1
*Если по iBGP перестают прилетать маршруты, то туннель через 15 минут умрет:
lagavulin> show dynamic-tunnels database
Table: inet.3
Destination-network: 10.200.86.0/26
Tunnel to: 10.200.86.9/32 ('''expires in 00:14:46 seconds''')
Reference count: 0
Next-hop type: rsvp-te
10.200.86.9:dt-rsvp-tunnel-1
==P2MP==
В случае использования '''P2P LSP''', source PE должен расплодить несколько копий трафика и послать по разным LSP.

В случае использования '''P2MP''': source PE отправляет трафик, копирование трафика происходит на определенном transit роутере, где происходит дальнейшее разветвление путей передачи трафика (branch point).

Таким образом уменьшится число копий трафика в сети. Копирование будет происходить только на branch points.

Сам туннель будет состоять также из 3 RSVP сессий.

Ingress посылает path message с session ID - одинаковый для всех leaf, label request, передаем router-ID удаленного роутера.

При построении отдельного Leaf - на всех транзитных роутерах будет выделена '''одна и та же метка'''.

Мы руками задаём от какого PE к какому строить туннель, потому что только мы знаем где расположен source.
===Config===
Задаем на ingress PE:
dalwhinnie> show configuration protocols mpls
no-cspf;
label-switched-path dalwhinnie-to-oban {
to 10.200.86.3;
p2mp p2mp1;
primary via_glenlivet;
label-switched-path dalwhinnie-to-macduff {
to 10.200.86.8;
p2mp p2mp1;
primary via_glenlivet;
label-switched-path dalwhinnie-to-talisker {
to 10.200.86.4;
p2mp p2mp1;
primary via_glenlivet;
path via_glenlivet {
10.200.86.6 loose;

dalwhinnie> show mpls lsp p2mp ingress
Ingress LSP: 1 sessions
P2MP name: p2mp1, P2MP branch count: 3
To From State Rt P ActivePath LSPname
10.200.86.3 10.200.86.5 Up 0 * via_glenlivet dalwhinnie-to-oban
10.200.86.8 10.200.86.5 Up 0 * via_glenlivet dalwhinnie-to-macduff
10.200.86.4 10.200.86.5 Up 0 * via_glenlivet dalwhinnie-to-talisker

glenlivet> show mpls lsp p2mp transit
Transit LSP: 5 sessions
P2MP name: p2mp1, P2MP branch count: 3
To From State Rt Style Labelin Labelout LSPname
10.200.86.3 10.200.86.5 Up 0 1 SE '''300144''' 300032 dalwhinnie-to-oban
10.200.86.8 10.200.86.5 Up 0 1 SE '''300144''' 300256 dalwhinnie-to-macduff
10.200.86.4 10.200.86.5 Up 0 1 SE '''300144''' 300256 dalwhinnie-to-talisker

mortlach> show mpls lsp p2mp transit
Transit LSP: 2 sessions
P2MP name: p2mp1, P2MP branch count: 2
To From State Rt Style Labelin Labelout LSPname
10.200.86.8 10.200.86.5 Up 0 1 SE '''300256''' 3 dalwhinnie-to-macduff
10.200.86.4 10.200.86.5 Up 0 1 SE '''300256''' 3 dalwhinnie-to-talisker

blair> show mpls lsp p2mp transit
Transit LSP: 1 sessions
P2MP name: p2mp1, P2MP branch count: 1
To From State Rt Style Labelin Labelout LSPname
10.200.86.3 10.200.86.5 Up 0 1 SE '''300032''' 3 dalwhinnie-to-oban

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

Типы сообщений:
*Discovery: = hello multicast 224.0.0.2 на 646 порт.
*Session: после обмена hello, роутер с бОльшим ip устанавливает TCP сессию со вторым роутером с помощью session Messages.
*Advertisement: создание, изменение и удаление меток по запросу от соседей.
*Notification: error и другая информаци о соседях.

Поддерживает MD5 аутентификацию, gracefull restart.
==Соседство==
[[Файл:ldp.png]]

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

Инициатором построения туннелей выступает egress роутер. ingress роутером будет каждый роутер на сети с настроенным LDP.

Роутер (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.}}

> show ldp neighbor
'''Для исключения петель: '''

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

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

После того, как установилось соседство - между роутерами устанавливается TCP сессия для обмена метками и пакетами по unicast.
> show ldp session
Заполняется mpls.0
Заполняется inet.3.

Если роутера имеют 2 линка между собой, то установится 2 соседства. Но сессия будет установлена одна.

На сессии можно включить authentification md5.

==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
set Lo0.0 family mpls

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

3. Если нужен не full-mesh в LDP домене, то настраиваются статические сессии. Можно с аутентификацией, можно без:
[edit protocols ldp]
set session 10.200.86.7 authentication-key ''pass''

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

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

Среди полезных настроек, которые используются практически во всех провайдерских сетях:
*''set protocols ldp track-igp-metric''- использование вместо дефолтной метрики LDP метрики IGP протокола.
*''set protocols ldp explicit-null'' - снятие метки на последнем роутер. То есть последний роутер будет слать от себя label 0. Полезно, когда на сети используется QOS.
*''set protocols isis/ospf ldp-synchronization''. Настраиваете в IGP протоколах. Работает только на p2p линках. Дает возможность IGP протоколу адвертайзить линк с максимальной метрикой, пока LDP туннель не простроится через этот линк. Таким образом линк не пропадет из топологии IGP, но и будет самым не выгодным для передачи трафика по нему.
[edit configuration protocols isis]
interface ge-0/0/0.114 {
ldp-synchronization;
point-to-point;

*''set protocols ldp deaggregate'' - по одному и тому же пути будет строиться несколько LSP.
По умолчанию в Jun при передачи нескольких префиксов в LDP, эти префиксы привязываются к одной метке и агрегируются в один FEC (equivalence forwarding class). Одна метка = одна LSP.

Deaggregate убивает это поведение и для каждого префикса будет биндиться своя метка (а значит и LSP).

дефолтное:
vlad@r5> show route protocol ldp
172.30.5.1/32 *[LDP/9] 00:01:18, metric 20
> to 172.30.0.29 via ge-0/0/0.145, Push 300032
192.168.1.0/24 *[LDP/9] 00:01:18, metric 30
> to 172.30.0.29 via ge-0/0/0.145, Push 300032

set deaggregate:
vlad@r5> show route protocol ldp
172.30.5.1/32 *[LDP/9] 00:00:14, metric 20
> to 172.30.0.29 via ge-0/0/0.145, Push 300272
192.168.1.0/24 *[LDP/9] 00:00:14, metric 30
> to 172.30.0.29 via ge-0/0/0.145, Push 300240

*по дефолту в ldp передается только адрес lo роутера. Если нужно объявить еще какие-то префиксы, то можно сделать это с помощью policy. '''Но нужно не забыть добавить в него lo ip!!'''.
[edit protocols ldp]
egress-policy export-ldp;
[edit policy-options policy-statement export-ldp]
term 1 {
from {
protocol direct;
route-filter 192.168.1.0/24 exact;
route-filter 172.30.5.1/32 exact;
then accept;

> show route protocol ldp
inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
192.168.1.0/24 *[LDP/9] 00:00:09, metric 20
> to 172.30.0.13 via ge-0/0/0.123, Push 0

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

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

==Процесс построения==

[[Файл:ldp_tunneling.png]]
* Роутер A (PE) - LDP. Egress: начинает анонсировать себя с меткой 3 в сторону B.
* Роутер B (PE) - LDP + RSVP. Анонс LoA с меткой 20 в сторону C. B: '''mpls.0''': 20 pop -> A
* Роутер C (P) - RSVP (с LDP-tunneling). Анонс LoA с меткой 30 в сторону E. С: '''mpls.0''': 30 swap 20 -> B.
* Роутер D (P) - между E<>C - RSVP LSP, где D - предпоследний роутер.
* Роутер E (P) - LDP + RSVP. Анонс LoA с меткой 40 в сторону F. E: '''mpls.0''': 40 swap 30 -> C. Но C не direct connected, а доступен через туннель => идем смотреть в inet.3. E: '''inet.3''': LoC push 100 -> D. => E: '''mpls.0''': 40 swap 30 push 100
* Роутер F (PE) - LDP. Ingress: '''inet.3''': LoA: push 40 -> E.

В обратную сторону строится точно также.

Когда туннель построен, между ingress (C) и egress (E) роутерами RSVP LSP установится LDP соседство! Устанавливается по UDP 646 на Lo P (''берется из конфигурации туннеля''), ''не hello механизм, но тоже работает’’.

Обязательно на P роутерах включить в LDP Lo, чтобы поднялся туннель C - E.

Схема работает только в пределах области.

При включенном LDP tunneling будут видны скрытые маршруты в inet.3

Можно использовать, когда не все устройства в сети поддерживают RSVP, но на ядре требуется TE. Также TE как таковой не требуется вообще на PE, нужно только на ядре, на P роутерах. Поэтому RSVP можно запустить только на ядре, а PE будут подцепляться по LDP.

При конфигурации может возникнуть проблема с переносом маршрутов из inet.3 в inet.0 (на PE роутерах). Решается как обычно: ''set protocols mpls traffic-engineering bgp-ibgp-both-ribs''. Или любым другим способом.

==Configuration==
[[Файл:ldp_tunneling_laba.png]]

'''PE (LDP + RSVP)''':
[protocols mpls]
traffic-engineering bgp-igp-both-ribs;
label-switched-path talisker-to-oban {
to 10.200.86.3;
ldp-tunneling;
[protocols ldp]
interface ge-0/0/0.70;
interface ge-0/0/0.120;
interface all;
'''С другой стороны на PE''':
[protocols mpls]
traffic-engineering bgp-igp-both-ribs;
label-switched-path oban-to-talisker {
to 10.200.86.4;
ldp-tunneling;

==Проверка==
Между крайних PE, на которых настроено туннелирование, установили соседство между собой по LDP:
talisker> show ldp neighbor
Address Interface Label space ID Hold time
10.200.86.3 lo0.0 10.200.86.3:0 42

На PE, к которому подключается CE:
macduff> show route 10.200.86.1
inet.0: 30 destinations, 40 routes (30 active, 0 holddown, 0 hidden)
10.200.86.1/32 *[LDP/9] 00:19:03, metric 1
> to 192.168.86.13 via ge-0/0/0.70, Push 300016
[OSPF/10] 00:19:03, metric 4
> to 192.168.86.13 via ge-0/0/0.70

talisker> show route label 300016 detail
mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
300016 (1 entry, 1 announced)
*LDP Preference: 9
Next hop type: Router, Next hop index: 548
Address: 0x934c3b8
Next-hop reference count: 2
Next hop: 192.168.86.33 via ge-0/0/0.120 weight 0x1, selected
Label-switched-path talisker-to-oban
Label operation: Swap 299776, Push 299968(top)
Label TTL action: prop-ttl, prop-ttl(top)
State: <Active Int NhAckRequest>
Local AS: 1111
Age: 19:37 Metric: 1
Task: LDP
Announcement bits (1): 0-KRT
AS path: I
Prefixes bound to route: 10.200.86.1/32

tormore> show route label 299968 detail
mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
299968(S=0) (1 entry, 1 announced)
*RSVP Preference: 7/1
Next hop type: Router, Next hop index: 581
Address: 0x934d258
Next-hop reference count: 2
Next hop: 192.168.86.38 via ge-0/0/0.130 weight 0x1, selected
Label-switched-path talisker-to-oban
Label operation: Pop
State: <Active Int AckRequest>
Local AS: 1111
Age: 1:09:29 Metric: 1
Task: RSVP
Announcement bits (1): 0-KRT
AS path: I

oban> show route label 299776 detail
mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
299776 (1 entry, 1 announced)
*LDP Preference: 9
Next hop type: Router, Next hop index: 544
Address: 0x934c568
Next-hop reference count: 2
Next hop: 192.168.86.26 via ge-0/0/0.110, selected
Label operation: Pop
State: <Active Int>
Local AS: 1111
Age: 26:53 Metric: 1
Task: LDP
Announcement bits (1): 0-KRT
AS path: I
Prefixes bound to route: 10.200.86.1/32

=Дополнительная информация=
*[[Глава 2. RSVP]]
*[[Глава 1. Основы MPLS и VPN]]
*[[Traffic engineering]]

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

2021-07-15T18:25:20Z

Наталия Бобкова:

{{#description2:Зачем нужен MPLS. Метки, LSP. Терминология. PHP, UHP. inet.3, MPLS routing table. Информация для подготовки к экзаменам Juniper.}}
===Причины появления и плюсы использования 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 заголовка.

Заголовок содержит: label 20 bit, CoS+Stack bit (если больше 1 метки) = 4 bit, TTL 8 bit (обычно копируется из TTL ip заголовка).

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

* 0 - Explicit null (IPv4) - снятие метки на последнем роутере
* 1 - Router alter label (IP router alert)
* 2 - Explicit null (IPv6)
* 3 - Implicit null - снятие метки на предпоследнем роутере - default behavior.
* 4-15 - for future use

Использование implicit null может немного подкосить ваш QoS дизайн, поэтому для QoS лучше использовать explicit-null:
[edit protocols mpls]
explicit-null

[edit protocols ldp]
explicit-null

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

'''Static LSP''' - labels value 1,000,000 through 1,048,575

[edit protocols mpls]
static-label-switched-path R1-to-R2 {
(ingress|egress|transit) {
next-hop 192.168.86.5
to 10.200.86.1 ''-только для ingress''
(push|pop|swap) 1000001

===Терминология===
'''LSP''' label 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 - MPLS routing table===
Маршруты вставляются в таблицу 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.

Для конкретной LSP inet.3 используется только на ingress роутерах. На транзитных будем использовать только mpls.0.

Для LSP в inet.3 будет маршрут до Lo egress роутера, который скорей всего также будет известен по какому-нибудь IGP протоколу. Но по сравнению со всеми IGP (OSPF/ISIS), у MPLS (RSVP/LDP) преферанс меньше (10/15 vs 7/9), поэтому всегда будет выбираться он - копироваться в inet.0, как forwarding next-hop.

==Дополнительная информация==
*[[Глава 2. Label Distribution Protocols (RSVP, LDP)]]
*[[Отказоустойчивость и оптимизация в MPLS]]
*[[Traffic engineering]]
*[[Реализация MPLS в ядре сети]]

Глава 8. Packet flow

2021-07-15T18:24:03Z

Наталия Бобкова:

{{#description2:Прохождение пакета по всем этапам обработки QOS. Информация для подготовки к экзаменам Juniper.}}
=Прохождение пакета по всем этапам CoS=
Пакет в CoS определяется и работает с 2мя значениями:
*Forwarding class
*Packet loss priority

Все процессы CoS производят некие манипуляции только с этими двумя параметрами.

*BA / interface class ---> FW, PLP
*Ingress Policing ---> FW, PLP
*MF ---> FW, PLP
*Forwarding policy <---> FW, PLP
*---FABRIC---
*Egress Policing ---> FW, PLP
*MF ---> FW, PLP
*Scheduler, Shaper, RED <--- FW, PLP
*Rewrite Marker <--- FW, PLP

Ingress Policing и MF используют один и тот же firewall filter => то есть сначала происходит откидывание не нужного трафика, а потом назначение FW class.

Forwarding policy - новый firewall, который на основании fw class и loss priority может отправить пакет в switch fabric, на основании информации из forwarding table для определенных fw class и PLP.

На выходе: опять можно повлиять на fw class и PLP с помощью комбинации Egress policy и MF.

После этого начинается обработка трафика: RED profile, Shaper, Scheduler.

И уже перед отправкой в "провод" можно перемаркировать заголовок пакета (IPv4, IPv6, MPLS, Ethernet) с помощью Rewrite rules. Что поможет нижестоящему оборудованию легче производить классификацию пакета.

=Прохождение пакета на уровне hardware=
*Services (PIC, DPC)
*RE (Control Plane)
*Forwadring Engine
Взаимодействуют между собой все!

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

=Дополнительная информация=
*[[Глава 1. QoS]]
*[[Глава 2. Packet classification]]
*[[Глава 6. Rewrite rules]]

Глава 7. CoS-based forwarding

2021-07-15T18:23:22Z

Наталия Бобкова:

{{#description2: Для чего CoS-based forwarding. Конфигурация CoS-based forwarding. Информация для подготовки к экзаменам Juniper.}}
==Для чего CoS-based forwarding==

CoS может быть интегрирован в policy, с помощью чего можно трафик определенного forw class направлять по определенному routing path.

Поддерживает IPv4, IPv6, MPLS.

==Конфигурация==
Этап 1. Конфигурируем '''routing-policy'''. Определяем маpшруты для использования CBF.
[edit policy-options]
policy-statement ''<cbf-policy>'' {
from {
route-filter 5.5.5.5/32 exact; }
then cos-next-hop-map ''<cbf-map>''; }

Этап 2. Конфигурируем '''CoS forw policy'''. Оперделяем next-hop для для fowr class. Можно комбинировать IP nex-hop и MPLS, тем самым обеспечивая load balancing.
[edit class-of-service]
forwarding-policy {
next-hop-map ''<cbf-map>'' {
forwarding-class assured-forwarding {
next-hop 192.168.86.49; }}
forwarding-class best-effort {
next-hop ge-0/0/0.110;
lsp-next-hop 192.168.86.10; }}}}

Этап 3. Применяем '''routing-policy''' к '''forw table'''.
[edit routing-options]
forwarding-table {
export ''<cbf-policy>''; }

==Заметочки==
*'''CBF with OSPF:''' конфигурируем в качестве nex-hop - интерфейс. Так как OSPF добавляет маршруты с next-hop = interface для p2p интерфейсов и не содержит никаких IP.
*'''IP and LSP next-hops'''. Для forw class можно конфигурировать оба, но приоритетным будет LSP.
*Если next-hop map перекрывает '''не все возможные forw class''', то трафик на попавший ни в какой forwarding-class считается unspesified и ему назначается unspesified forw class. Default forw class - class of queue 0. Если default forw class не определен в nex-hop-map, то JunOS также randomly designated the default class.
*При использовании '''L3VPN''' в качестве условий для матчинга нужно задавать атрибуты (а не route-filter), с которыми прилетел маршрут. Policy будет использовать для проверки bgp.l3vpn.0 таблицу, а не ''vrf''.inet.0.

==Дополнительная информация==
*[[Глава 1. QoS]]
*[[Глава 2. Packet classification]]
*[[Глава 8. Packet flow]]

Глава 6. Rewrite rules

2021-07-15T18:22:09Z

Наталия Бобкова:

{{#description2: Основы Rewrite rules. Default rewrite tables. Custom rewrite tables. Где использовать rewrite rules. Rewrite для комбинации разных протоколов. Информация для подготовки к экзаменам Juniper.}}
=Основы Rewrite rules=

Процесс происходит в конце всего цикла QoS. Когда понятно куда и как отправится пакет, маршрутизатор может записать в заголовок пакета - code point bits.

Способствует целостности и непрерывности QoS на всей сети.

Набор rewrite rules образует rewrite table.

Процесс rewrite:
#Считывается исходный Forw class и PLP.
#Исходя из этого находит в table соответствующий code-point.
#Записывает в заголовок пакета новый code-point.

Поддерживается для: DSCP (IPv4, IPv6), IP precedence bit, MPLS EXP bits, 802.1p CoS bits, 802.1ad DEI bits.

Rewrite rule применяется на интерфейс внутри class-of-service настроек.

*На физический интерфейс можно применить только DSCP IPv4 '''ИЛИ''' DCSP IPv6.
*На логический интерфейс можно применять и DSCP IPv4 и DSCP IPv6.

Rewrite-rule работает до egress filter. Поэтому в egress filter нужно делать политики, полагаясь на новый code-point пакета.

Дефолтное поведение QoS на Junos:
*Bits associated with DSCP traffic class are not rewritten to match the new traffic classification values.
*Bits associated with MPLS traffic class are rewritten to match the new traffic classification values.

=Default rewrite tables=

Несколько таблиц существует, но большинство не используется по умолчанию, т.к. должны быть явно заданы на unit'e.
'''НО!''' на интерфейсах, где включен MPLS, используется дефолтное MPLS exp rewrite rule.

Есть табличка со стандартными значениями (в книге).

'''Конфигурация'''
set class-of-service interfaces ge-0/0/0 unit 200 rewrite-rules dscp default
set class-of-service interfaces ge-0/0/0 unit 200 rewrite-rules exp default
set class-of-service interfaces ge-0/0/0 unit 200 rewrite-rules ieee 802.1 default

Когда пакет придет на интерфейс для дальнейшей передачи, система применит rewrite rule исходя из нужного протокола.

=Custom rewrite tables=

Если не подходят дефолтные правила, создаем свое!! Нужно задать forw class, PLP и CoS.

'''Конфигурация'''
Задаем свои code-point (если нужно)
set class-of-service code-point-aliases dscp vpn-low 001010
set class-of-service code-point-aliases dscp vpn-high 001100
set class-of-service code-point-aliases dscp vpn-priority 101110
set class-of-service code-point-aliases dscp be 000000
set class-of-service code-point-aliases dscp nc 110000
set class-of-service code-point-aliases exp be 000
set class-of-service code-point-aliases exp vpn-low 010
set class-of-service code-point-aliases exp vpn-high 011
set class-of-service code-point-aliases exp vpn-priority 101

rewrite-rules для DSCP:
set class-of-service rewrite-rules dscp dscp-rewrite forwarding-class best-effort loss-priority low code-point be
set class-of-service rewrite-rules dscp dscp-rewrite forwarding-class vpn loss-priority low code-point vpn-low
set class-of-service rewrite-rules dscp dscp-rewrite forwarding-class vpn loss-priority high code-point vpn-high
set class-of-service rewrite-rules dscp dscp-rewrite forwarding-class vpn-priority loss-priority low code-point vpn-priority
set class-of-service rewrite-rules dscp dscp-rewrite forwarding-class nc loss-priority low code-point nc
rewrite-riles для EXP:
set class-of-service rewrite-rules exp exp-rewrite forwarding-class best-effort loss-priority low code-point be
set class-of-service rewrite-rules exp exp-rewrite forwarding-class vpn loss-priority low code-point vpn-low
set class-of-service rewrite-rules exp exp-rewrite forwarding-class vpn loss-priority high code-point vpn-high
set class-of-service rewrite-rules exp exp-rewrite forwarding-class vpn-priority loss-priority low code-point vpn-priority

Применяем rewrite-rules:
set class-of-service interfaces ge-0/0/0 unit * rewrite-rules dscp dscp-rewrite
set class-of-service interfaces ge-0/0/0 unit * rewrite-rules exp exp-rewrite

=Где использовать rewrite rules=

Лучше всего использовать rewrite rules внутри сети, на интерфейсах, которые входят в QoS домен. Такая позиция сделает более эффективной и менее трудозатратной работу CoS, засчет четкой обработки BA classification на ingress для других устройств в сети.

=Rewrite для комбинации разных протоколов=
Присвоенная метка в заголовке пакета выбирается на основании протокола. Бывают такие случаи, когда пакет может иметь несколько протоколов, например:

IPv4 packet over Ethernet, using vlan. DSCP + ieee 802.1p
IPv4 packet over MPLS: DSCP + EXP.

JunOS может записывать 1 или 2 значения CoS.

Такие правила вроде уж созданы как дефолтные, например: mpls-inet-both, outer-and-inner..
{{note|text='''Опасно''': кол-во правил, присвоенных для одного логического интерфейса - зависит от платформы.}}

=Дополнительная информация=
*[[Глава 1. QoS]]
*[[Глава 2. Packet classification]]
*[[Глава 8. Packet flow]]

Глава 5. Hierarchical scheduling

2021-07-15T18:21:23Z

Наталия Бобкова:

{{#description2:Основы иерархичного scheduling. Режимы scheduler. Уровни иерархичного scheduling. Конфигурация иерархичного scheduling. Информация для подготовки к экзаменам Juniper.}}
=== Overview ===

С hierarchical sched устройство обеспечивает обработку нескольких абонентов, групп абонентов (units), разных классов у подписчика.

Выполняет те же функции, что и port-based scheduling: в каком порядке пакеты передать, сколько пакетов забуфферизировать, определить скорость, как обрабатывать разные пакеты в условиях запора.

Но есть особенности:
# H-CoS - предоставляет более тонкую обработку по нескольким уровням.
# H-CoS предоставляет возможность централизовать CoS для downstream устройств, которые не имеют функционала CoS (либо не сконфигурирован CoS на downstream device, которые CoS как таковой поддерживают).
# H-CoS поддерживают не все устройства. Поддерживают устр-ва, использующие ASICs.

'''C-VLAN''': customer-vlan, inner tag. Scheduling и shaping обычно используются для C-VLAN для установления min и max пропускной способности для клиента.

'''S-VLAN''': service-vlan, outer-tag. Scheduling и shaping обычно работают в S-vlan, для предоставления CoS нижележащим устр-вам с небольшим буффреризированием и простым scheduler.

'''Traffic control profile''': конфигурационный компонент, состоящия из scheduling и queueing свойств. Применяется к физическому интерфейсу, логическому и набору интерфейсов.

'''Interface set''': группа логических интерфейсов, определенных нами.

'''CIR''': committed interface rate: гарантированная скорость, назначенная на interface set или логический интерфейс.

'''PIR''': peak interface rate: макс скорость, сконфигурированная для порта, логического интерфейса или interface set.

'''4 уровня обработки''':

1. Port (physical interface). Каждый порт может иметь несколько interface sets. Поддерживает shaping.

2. Interface set (VLAN or logical interface group). Каждый может иметь 1 или более логических интерфейсов. Поддерживает CIR, PIR.

3. Logical interface (VLAN). Может быть до 8 очередей. Поддерживает CIR, PIR.

4. Queue. Здесь обычная обработка трафика по заданным параметрам.

Может быть до 8 очередей для 1 VLAN. Каждая очередь имеет свои свойства.

=== Scheduler modes ===

1. Per-unit (Port based) scheduler (то, что мы изучали в предыдущей главе 5):

a) port-level shaping
b) VLAN scheduling and queueing
c) full queue scheduling
'''NO interface sets!'''

2. Hierarchical scheduler:

a) port-level shaping
b) interface-set scheduling and queueing
c) VLAN scheduling and queueing
d) full queue scheduling

Включение нужного режиме делается на уровне настройки физического интерфейса:
set interfaces ge-0/0/0 ''per-unit-scheduler'' ...
or
set interfaces ge-0/0/0 ''hierarchical-scheduler'' ...

=== Hierarchical scheduling levels ===

==== Level 1 - Port ====

'''Shaping''': PIR - max rate for port. Пакеты, превышающие PIR не дропаются, а хранятся в буффере.

Config: Для установления PIR нужно сконфигурировать traffic-control-profile, затем применить его на порт.

Пример:

set class-of-service traffic-control-profile ''profile'' shaping-rate ''100m''
set class-of-service interfaces ge-0/0/0 output-traffic-control-profile ''profile''

==== Level 2 - Interface set ====

Создание Interfaces-sets: 2 варианта объединить интерфейсы в группу: собрать группу из разных вланов, определить группу двутеггированных вланов по S-vlan (outer).

set interfaces ge-0/0/0 hierarchical-scheduling
set interfaces ge-0/0/0 flexible-vlan-tagging
set interfaces ge-0/0/0 unit 100 vlan-id 100
set interfaces ge-0/0/0 unit 200 vlan-id 200
set interfaces ge-0/0/0 unit 1000 vlan-tags outer 1234 inner 1000
set interfaces ge-0/0/0 unit 1100 vlan-tags outer 1234 inner 1100

Для таких интерфейсов можем задать группы:

set interfaces interface-set ''A'' interface ge-0/0/0 unit 100
set interfaces interface-set ''A'' interface ge-0/0/0 unit 200

set interfaces interface-set ''B'' interface ge-0/0/0 vlan-tags-outer 1234

'''Особенности:'''

1. Нельзя использовать interface-range

2. В interface-set нельзя использовать одновременно logical int и S-vlan.

3. Один физ интерфейс для одного interface-set.

4. Logical int или S-vlan может принадлежать только одному interface-set.

'''Shaping''': используем CIP и PIR (гарантированная и максимальная скорости)

'''Scheduling''': CIR и PIR также используются для обозначения относительного веса данного interface-set'а, учитывая другие interface-set для данного порта.

- CIR mode: If any interface sets within port has defined CIR, bandwidth sharing among the interface sets is based on the CIR of the interface sets.

- PIR mode: If no interface sets CIR defined, bandwidth sharing among interface sets base on the PIR of the interface sets.

Когда траффик превышает PIR, интерфейс прекращает передачу пакетов.

set class-of-service traffic-control-profile '' profile '' shaping-rate 75m guaranteed-rate 50m
set class-of-service interface-set ''A'' output-traffic-control-profile ''profile''

==== Level 3 - logical interface (VLAN) ====

'''Shaping''': CIR, PIR, Scheduler map - ассоциирует влан с его очередью.

'''Scheduling''': CIR и PIR определяю относительный вес влана среди других вланов на том же порту.

- CIR mode: If any vlan within port has defined CIR, bandwidth is shared among vlans in proportion on their CIR.

- PIR mode: If noone vlan within port has defined CIR, bandwidth is shared among vlans in proportion on their PIR.

Когда траффик превышает PIR, во влане прекращается передача пакетов.

set class-of-service traffic-control-profile ''profile'' schedule-map ''sched-exmple'' shaping-rate 30m guaranteed-rate 20m
set interfaces ge-0/0/0 unit 100 output-traffic-control-profile ''profile''

'''Без указания guaranteed-rate для traffic-control-profile будет выделено значение bandwidth = 2 MTU.'''

==== Level 4 - Queue ====

'''Scheduling''': самый обычный scheduler для port-level с обычными параметрами: transm-rate, priority, delay buffer, RED drop profiles. + Можно задавать H-Cos scheduling, оно будет немногим отличаться от обычного.

Сам конфиг приводить не буду, но нужно:

#Сконфигурировать scheduler: transm-rate, priority, delay-buffer, drop-profile, drop-profile-map.
#Сконфигурировать scheduler-map.
#Применить scheduler-map к интерфейсу в рамках class-of-service конфигурации.
При этом, важный момент: для port-based scheduling, scheduler map применяется к интерфейсу.

А для H-COS scheduler map применяет на Level 3 к определенному unit.

=== Remaining traffic ===

Оставшийся трафик включает в себя units, которым не были присвоены какие-то traffic-contro-profile и набор из вланов, которые не были включены к какие-либо interface-sets.

Remaining scheduler: простой scheduler, который применяется к вланам, которым не назначили конкретных traffic-control-profiles. Короче это scheduler, который применяется к remaining traffic.

Цепочка: Port -> Interface set -> vlan -> queue.

Для тех вланов, которых входят в interface set, но которым не назначены определенные traffic-control-profile, будут использовать remaining scheduler, заданный для interface set.

Для тех вланов, которые не были включены в interface set, будут использоваться remaining scheduler, заданный для port.

'''Remaining vlans - Interface set'''

set class-of-service traffic-control-profiles ''profile-remaining'' scheduler-map ''sched-example'' shaping-rate 50m guaranteed-rate 10m
set class-of-service interface-set A output-traffic-control-profile ''profile''
set class-of-service interface-set A output-traffic-control-profile-remaining ''profile-remaining''

'''Remaining vlans - Port '''

set class-of-service traffic-control-profiles ''profile-remaining'' scheduler-map ''sched-example'' shaping-rate 50m guaranteed-rate 10m
set class-of-service interface ge-0/0/0 output-traffic-control-profile ''profile''
set class-of-service interface ge-0/0/0 output-traffic-control-profile-remaining ''profile-remaining''

=== Queue properties in Hierarchical Scheduling ===

'''Priority'''

В port-level queueing '''очереди''' "соревнуются" за пропускную способность порта.

В hierarchical queueing '''вланы''' "соревнуются" за проп способность порта. => приоритет очереди определяется утилизацией проп способности влана, которому сопоставленая данная очередь.

CIR < VLAN - приоритеты очереди остаются обычными: strict-high, high, med-high, med-low, low..

CIR > VLAN > PIR - все приоритеты (за исключением strict-high) становятся excess.

'''Работа Queueing priority''':

Алгоритм планировщика, использующего HCoS включает в себя PQ-DWRR (выбор очереди и передача пакета) и Intelligent Prioritization.

Для port-level queueing: если очередь с меньшим приоритетом уже передает пакет, то очередь с большим приоритетом должна подождать пока та очередь закончит передачу пакета до того как она распределить снова (scheduled again).

Для HCOS: приоритет отправки пакета определен для очередей с разными приоритетами. Сначала идет передача из очередей с strict-high и high приоритетами. Затем передача пакетов из medium-high и medium-low, затем low, затем excess.

'''Transmission rate'''

Полоса, которая не используется вланами называет избыточной (excess). Эта полоса может быть распределена между вланами пропорционально CIR (если не определен CIR, то смотрят по PIR) (дефолтное поведение), либо может быть разделена равными частями.

'''mode per port''': применяется ко всем interface sets.

'''mode per interface-set''': применяется ко всем вланам. Перебивает per port settings.

Чтобы маршрутизатор более точно распределил избыточную полосу между вланами, в качестве excess-bandw нужно задать max queue bandtwidth = max effeective guaranteed rate.

set class-of-service interfaces interface-set A excess-bandwidth-share equal

set class-of-service interfaces ge-0/0/0 exceed-bandwidth-share proportional 14000000

'''Buffer size'''

В отличие от port-level, где buffer size определяется определяется с помощью interface bandidth, для vlan размер определяется через traffic control profile, который задан явно в конфигурации.

- vlan bandwidth is not implicitly known: must be configured in traffic-control-profile.
- delay buffer rate - configurable parameter, provides reference for buffer size calculation.
- buffer size is calculated implicitly using CIR (if no deay buffer rate) or PIR (if no CIR).

В HCOS delay buffers не эластичны - не поддерживают динамического выделения памяти.

На практике получается так, что delay buffer вланов становится ориентиром для scheduler.

Level 1-3 поддерживают delay buffer.

Каждый уровень использует уровень ниже как ориентир для полосы пропускания.

Сумма буфферов на каждом уровне не должна превышать значения нижнего уровня.

[edit class-of-service]
traffic-control-profiles {
L1-port-prof {
shaping-rate 100m;
delay-buffer-rate 200; }
L2-interface-sets-prof {
shaping-rate 100m;
guaranteed-rate 75m;
delay-buffer-rate 100m; }
L3-unit-prof {
shaping-rate 30m;
guaranteed-rate 20m;
delay-buffer-rate 35m; }}
[edit class-of-service interfaces]
interface-set A {
output-traffic-control-profile L2-interface-sets-prof; }
[edit class-of-service interfaces]
xe-0/0/0 {
output-traffic-control-profile L1-port-prof;
unit 181 {
output-traffic-control-profile L3-unit-prof; }}

'''RED drop profiles'''
Используется только сегментная.

Задаются 2 точки и между ними рисуется прямая.
*minimum queue depth: below it drop probability = 0
*maximum queue depth: above it drop probability = 100

Задаем только 2 точки!!

[edit class-of-service]
drop-profiles {
test {
fill-level 25 drop-probability 0;
fill-level 90 drop-probability 90; } }

=== Configuration steps ===
#Configure physical interface for HCOS: add hierarchical-scheduler statement.
#Configure interface sets.
#Configure schedulers, including drop profile.
#Configure scheduler-maps: associate schedulers and forwarding classes. schedulers do nothing until they are referenced in a scheduler-map.
#Configure traffic-control profiles: associate scheduler-maps to vlans.
#Apply traffic-control-profile to ports, interface-sets and vlans.

[edit interfaces xe-0/0/0]
hierarchical-scheduler;

[edit interfaces]
interface-set A {
interface xe-0/0/0 {
unit 285;
unit 311; }}

[edit class-of-service]
drop-profiles {
aggressive {
fill-level 5 drop-probability 50;
fill-level 60 drop-probability 100; }
tolerant {
fill-level 25 drop-probability 0;
fill-level 100 drop-probability 100; }}
[edit class-of-service schedulers]
sched0 {
transmit-rate percent 20;
buffer-size percent 20;
drop-profile-map loss-priority low protocol any drop-profile tolerant; }
sched1 {
transmit-rate percent 80;
buffer-size percent 80;
drop-profile-map loss-priority high protocol any drop-profile aggressive; }

[edit class-of-service]
traffic-control-profiles {
set-A {
shaping-rate 200m;
guaranteed-rate 20m; }
PIR-200-CIR-5 {
scheduler-map schedule-0-1;
shaping-rate 200m;
guaranteed-rate 5m; }
PIR-200-CIR-25 {
scheduler-map schedule-0-1;
shaping-rate 200m;
guaranteed-rate 25m; }}

[edit class-of-service interfaces]
interface-set A {
excess-bandwidth-share proportional 6400g;
output-traffic-control-profile set-A;
output-traffic-control-profile-remaining PIR-200-CIR-25; }
ge-0/0/0 {
excess-bandwidth-share proportional 6400g;
output-traffic-control-profile-remaining PIR-200-CIR-25;
unit 246 {
output-traffic-control-profile PIR-200-CIR-5; }
unit 248 {
output-traffic-control-profile PIR-200-CIR-5; }}

===Дополнительная информация===
*[[Глава 4. Scheduling]]
*[[Глава 1. QoS]]
*[[Глава 8. Packet flow]]

Глава 4. Scheduling

2021-07-15T18:20:33Z

Наталия Бобкова:

{{#description2:Основы scheduling. Шедулер. Port-based очереди. Компоненты scheduling: Transmission rate, Queue priority, Drop profiles (RED/WRED). Scheduler map. Конфигурация Scheduler. Информация для подготовки к экзаменам Juniper.}}
=Основы scheduling=
С помощью классификатора определили трафик в разные очереди, теперь нужно как-то трафик обрабатывать. Этим процессом как раз занимается scheduler:
*Порядок передачи пакетов
*Скорость передачи пакетов
*Кол-во пакетов, которое можно забуфферизировать
*Разные способы обработки пакетов в случае заторов на сети.

Разная обработка трафика на основании loss-priority.
*Классификация или полисер назначили PLP
*PLP соответствует scheduling traffic profile
*Traffic profile соответствует drop profile
*Drop profile определяет вероятность отброса трафика

=Port-based очереди (queues)=
Каждый порт может содержать 4-8 очереди.

Одной очереди может быть назначено более одного forwarding class.

'''PQ-DWRR''': priority queue deficit round-robin: механизм для выбора очереди и последующей передачи пакета. Priority - очереди обслуживаются в порядке, сконфигурированном для очередей.

'''WRED''': Weighted random early detection: механизм для отброса пакетов. Основан на сконфигурированных параметрах: fw-class, PLP. С помощью него можно избежать и контролировать заторы.

= Компонениы Scheduling =
==Transmission rate ==
'''Transmission rate''' - кол-во пропускной способности от физического интерфейса, выделенной для этой очереди. Похоже на CIR.

Очередь может превышать tranmission rate, если есть неиспользуемая полоса (использовать большую полосу, чем выделили изначально). Тут также используется терминология in-profile, out-of-profile.

edit class-of-service schedule ''<schedule-name>'' '''transmit-rate''' (''rate | percent | remainder'') exact | rate-limit

*'''remainder''' - заполнение оставшегося буфера.
*'''exact''' - буферизирует трафик, который превысил transm rate. При наличие неиспользуемой свободной полосы не будет давать очереди её использовать.
*'''rate-limit''' - дропает трафик, который превысил transm rate.
*'''no settings''' - очередь может превысить transm rate, если есть неиспользуемая полоса.

Есть значения по умолчанию. Так как по умолчанию в джуне созданы 2 fw-class (best-effort (0) и network-control (3)), то дефолтные параметры есть только для этих очередей.

Для best-effort - 95, для netw-control - 5.

'''Unusable bandwidth'''

В случае, когда у нас сформированы 2 очереди и trasm-rate между ними делится 50/20%, в таком случае получаем неиспользуемую полосу 30%.

Эта неиспользуемая полоса будет использоваться только очередями, у которых есть превышение transm-rate.

Scheduler будет делить неиспользуемую полосу между подходящими очередями.

Чтобы исключить очередь, используем exact или rate-limit в настройке.

==Приоритет очереди==
'''Priority''' - приоритет среди других очередей. Во времена запоров приоритетом определяется в каком порядке будут обрабатываться очереди.

Значения:
*Low
*Medium-low
*Medium-high
*High
*Strict-high - traffic always in-profile. Пакеты в этой очереди всегда в первую очередь используют необходимую полосу.

Остальные очереди передают трафик в порядке убывания приоритета от high к low.

Трафик в in-profile (по transmission rate) low priority, будет обрабатывается до трафика out-profile strict priority.

То есть сначала вне зависимости обрабатывается трафик в in-profile, только потом out-profile.

Но при этом, при передаче каждого пакета в очереди, ниже strict, происходит проверка - есть ли в очереди пакеты из более высокой очереди. Если есть, то начинают передаваться они, а потом продолжает передавать прежняя очередь (если за это время не набежало пакетов из тоже приоритетной очереди).

Strict-priority - опсана! она может сожрать всю полосу и остальные очереди могут "голодать". Но High-prioroty делит полосу с Strict.

Чтобы не происходило голодания, мы можем:
#также важным очередям назначать high-priotity.
#для strict-priority задавать в transm-rate ''rate-limit''.

Разрешается задавать 1 strict-priority на 1 интерфейс.

edit class-of-service schedule ''<schedule-name>'' '''priority''' ''< high / low / medium-high / medium-low / strict-high >''

Дефолтные значения для дефолтных fw-class: '''best-effort - ''low'' ''', '''network-control - ''low'' '''.

== Delay buffers ==

- '''Delay buffers''' - кол-во данных, кот можно хранить.

larger buffer = many packet stores = large supported latency.

Buffer size - это параметр, определяющийся размер буфера интерфейса и также зависит от платформы.

edit class-of-service schedule ''<schedule-name>'' '''buffer-size''' ''<percent | temporal | remainder>''

'''percentage''': буфер "эластичный", когда очередь начинает использовать бОльшую полосу, чем ей было выделено изначально (transm-rate), буфер будет автоматически увеличиваться.

effective delay buffer (ms) = buffer size (%) * max port buffer size (ms)
effective delay buffer (s) * interf bandwidth (Mbps) / 8 = buffer size (MB) [используется для конвертации в Мбайты]

Пример:

100 ms - max buffer size
1GB ports
для очереди 0 - задаем percentage = 30%: effective delay buffer = 30 ms, buffer size = 0,03 s * 1000 Mbps /8 = 3,75 MB
для очереди 1 - задаем percentage = 45%: effective delay buffer = 45 ms, buffer size = 0,045 s * 1000 Mbps /8 = 5.625 MB

'''temporal''': для задания размера такого буфера используются мс. Буфер не эластичный, имеет строгий верхний лимит и дропает весь трафик, превышающий этот лимит. Для вычисления оптимального размера буфера используется значение transmission-rate.

buffer size (MB) = max buffer size (s) * transmit rate (Mbps) / 8
buffer size (MB) = max buffer size (s) * [interface bandw (Mbps) * transmit rate (%)] / 8

Пример:

100 ms - max buffer size
1GB ports
для очереди 2 - задаем transmission rate = 100 Mbps (10%): buffer size = 0,1 * 100 Mbps / 8 = 1,25 MB
для очереди 2 - задаем transm rate = 10% : buffer size = 0,1 * 1000 Mbps * 0.1 / 8 = 1,25 MB
для очереди 3 - задаем transmission rate = 300 Mbps (30%): buffer size = 0,1 * 300 Mbps / 8 = 3,75 MB
для очереди 3 - задаем transm rate = 30% : buffer size = 0,1 * 1000 Mbps * 0.3 / 8 = 3,75 MB

'''remainder''': использует все не занятое другими очередями пространство.

Когда мы выставляем buffer size и transm rate в процентном соотношении, хорошей практикой считается выставлять пропорциональные (равные) значения, но это не обязательно вообще.

В обоих случаях размер буффера будет увеличиваться при увеличении transm rate.

'''Default scheduler settings''': Для '''best-effort - ''95'' ''', для '''netw-control - ''5'' ''', что равно дефолтным значениям transm-rate.

== Drop profiles (RED/WRED)==
'''RED drop profiles (random early discard)''' - как отбрасывать трафик, когда возникает запор. Работает напрямую с буфферами. Отбрасывание пакетов зависит от заполненности буфера.

Определяет параметры отброшенного трафика, назначает PLP для использования (set on a packet at ingress).

При этом в RED из-за "случайно отброшенных" пакетов может возникнуть такая ситуация, когда некоторые пакеты одного потока будут отброшены, тогда source перестанет получать acknowledgement от receiver. При этом затор на уже почти перегруженном линке будет только увеличиваться.

В связи с этим более эффективно использовать WRED, он полностью не уберет проблему с "нечестным" отбросом пакетов из одного потока, но хотя бы можно исключить подобную ситуацию для трафика, нетерпимого к подобным потерям. О нем дальше.
===Параметры WRED===
#'''fullness''': наполненность буффера.
#'''drop probability''': вероятность, что пакет будет отброшен.

Для drop-profile задаём значения для этих двух параметров.
По сути получается линия на графике, где соотносятся fullness (%) к drop probability (%).

'''How it works''':
#Для каждого пакета в очереди маршрутизатор назначает любое число от 0-100.
#Числа нанесены на график отношения fullness к drop probability (по оси fullness).
#Когда случайный номер выше линии, пакет передается.
#Когда случайный номер ниже линии, пакет дропается.

Чтобы сделать более тонкую обработку трафика, рекомендуется создать несколько drop pofiles с разной "агрессивностью", и применять каждый к разному типу трафика.

Такой подход является более взшешанным (weighted RED = '''WRED''').

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

Когда мы настраиваем drop profile таким образом, что fullness < 100%, drop probability = 100%, мы таким образом уменьшаем эффективный максимальный размер буффера. То есть с помощью drop-profile мы можем влиять на "рабочий" размер буфера.

===Config options===
Помимо drop probability и fullness при конфигурации следует учитывать, что эти параметры могут задаваться:

*'''segmented''': график строится по указанным в конфигурации значениям. Особенность: так как график будет выглядить как лесенка, то на разных промежутках, при разных значениях fullness, мы будем иметь одно и то же значение drop probability.

Пример конфига:

set class-of-service drop-profiles ''segmented'' fill-level 25 drop-probability 25
set class-of-service drop-profiles ''segmented'' fill-level 50 drop-probability 50
set class-of-service drop-profiles ''segmented'' fill-level 75 drop-probability 75
set class-of-service drop-profiles ''segmented'' fill-level 95 drop-probability 100

*'''interpolated''':

Представляет собой гладкий график, постепенно возвышающийся.

Строится автоматически, состоит из 64 координат, включая координаты, которые мы задали для построения кривой.

(0,0) (100,100) - эти координаты включены по умолчанию.

Пример конфига:

set class-of-service drop-profiles ''interpolated'' interpolate fill-level [50 75] drop-probability [25 50]

===Default settings===

fill-level 0 drop-probability 0
fill-level 100 drop-probability 100

Вообще дефолтная настройка смысла не имеет, так как начинает отбрасывать пакеты только при полной загруженности буффера, что и без того происходит! )

===Apply drop profile===

Помимо того что drop profile нужно создать, для его работы его нужно прикрепить к какой-нибудь очереди.

Одной очереди может быть применено более 1 drop profile для разных типов трафика.

Также drop profile придает значение для PLP. До этого PLP было просто меткой, прикрепленной к пакету. Я так понимаю, что здесь речь о том, то прикрепленный к пакету PLP теперь имеет значение и на его основании, в том числе, будет обработан трафик.

Также drop profile может быть назначен по protocol-specific: non-TCP, TCP, all traffic.

===Drop profile map options===

'''loss-priority''': ''low'', ''medium-low'', ''medium-high'', ''high''. ''any''

'''protocol''': ''tcp'', ''non-tcp'', ''any''

'''drop profile''': desired drop-profile.

edit class-of-service schedule schedule-name drop-profile-map loss-priority ... protocol ... drop-profile ...

По сути здесь выцепляется трафик из определенного forwarding-class, с определенным PLP, опеределнного протокола и к нему применяется определенный drop-profile.

===Default scheduler settings===

edit class-of-service schedule schedule-name drop-profile-map loss-priority any protocol any drop-profile terminal

set class-of-service drop-profiles terminal fill-level 100 drop-probability 100

=Scheduler map=
Используется для группирования сложных наборов schedulers, чтобы можно было применить их к каждому FW class на интерфейсе.

При создании scheduler map мы задаем кол-во сервисов, назначенных каждому FW class и соответствующих приоритетов.

При этом к одной очереди можно применить несколько FW class (queue). Далее трафик можно будет обрабатывать особым образом, основываясь на PLP.

=Конфигурация Scheduler=

*Configure scheduler, including drop profile
:*Transmission rate
:*Queue priority
:*Delay buffers
:*Drop profile - не в рамках scheduler
:*Drop profile maps
*Configure scheduler map: schedulers придуманы, чтобы определенным образом управлять определенным трафиком. Сами по себе schedulers ничего не делают, нужна привязка. Scheduler-map как бы линк между forw-class и scheduler.
*Apply scheduler map to an interface: будет работать в outbound направлении. Для port-level queueing вешается на физический интерфейс.

Пример:

''scheduler''

set class-of-service drop-profiles relaxed interpolate fill-level [75 90 100] drop-probability [0 75 100]
set class-of-service drop-profiles aggressive interpolate fill-level [50 75 90 100] drop-probability [0 50 75 100]

set class-of-service schedulers sch-be transmit-rate percent 70
set class-of-service schedulers sch-be buffer-size percent 70
set class-of-service schedulers sch-be priority low
set class-of-service schedulers sch-be drop-profile-map loss-priority high protocol any drop-profile aggressive
set class-of-service schedulers sch-be drop-profile-map loss-priority low protocol any drop-profile relaxed

set class-of-service schedulers sch-pri transmit-rate percent 30
set class-of-service schedulers sch-pri buffer-size percent 30
set class-of-service schedulers sch-pri priority high

''scheduler map''

set class-of-service scheduler-maps ''sched-map-example'' forwarding-class best-effort-data scheduler ''sch-be''
set class-of-service scheduler-maps ''sched-map-example'' forwarding-class priority-data scheduler ''sch-pri''

''apply to an interface''

set class-of-service interfaces ge-0/0/0 scheduler-map ''sched-map-example''

=Дополнительная информация=
*[[Глава 5. Hierarchical scheduling]]
*[[Глава 1. QoS]]
*[[Глава 8. Packet flow]]

Глава 3. Policing

2021-07-15T18:19:54Z

Наталия Бобкова:

{{#description2: Основы policing. Shaping. Single-rate two-color policer. Tricolor marking policers. Two-rate tricolor marking policy. Color-blind mode. Color-aware mode. Policing с использованием firewall filter.Информация для подготовки к экзаменам Juniper.}}
==Основы policing==
*Первая ступень управления трафиком при заторах. Использует bandwidth threshold and max burst size. Может управлять трафиком (назначать PLP, forw-class), который превысил оба порога (не только шейпить).
*Применяются ограничения bandwidth для вх и исх трафика.
*Обеспечивает соблюдение SLA.
*Определяет трафик как: in-profile (трафик не превысивший threshold) и out-profile (трафик, превысивший threshold).

===Особенности===
- Для создания policer:
:-bandwidth threshold + max burst size
:-действие: reject, discard, ...
- Применяется:
:- на интерфейс.
:- в качестве действия внутри firewall filter, firewall filter вешается на интерфейс.
- Использует token-bucket алгоритм: есть некий burst, до того, как начать влиять на трафик.

=== Hard/Soft ===
'''Hard''': Все что выходит за рамки ограничения - дропается.

'''Soft''': Трафик который превышает лимит:
#не дропается, но направляется в определенный forwarding class.
#не дропается, но ему присваивается определенное значение PLP, по которому в случае заторов он будет отброшен шедулерами.

=== Параметры ===

'''CIR, CBS''': commited information rate (бит/с) / burst size (байт): зеленый - кол-во трафика < CBS - точняк пройдет (in-profile).

'''PIR, PBS/EBS''': peak information rate (бит/с), peak/exceed burst size (байт): то, что < PBS - пройдет, но в случае заторов пакеты могут быть дропнуты. То что больше - будет дропаться (out-of-profile).

== Single-rate two-color policer ==
*Один threshold по скорости ('''CIR''')
*Один burst threshold, с помощью которого создается 2 цвета, в которые может быть "окрашен" трафик. ('''CBS''')
*Трафик, превышающий CIR + CBS => '''discard / set forwarding class / set PLP / out-of-profile'''

'''Конфигурация'''
set firewall policer ''100m'' if-exceeding bandwidth-limit 100m = '''CIR'''
set firewall policer ''100m'' if-exceeding burst-size-limit 2.5m = '''CBS'''
set firewall policer ''100m'' if-exceeding then '''discard'''

== Tricolor marking policers ==
Также не только дропает трафик, а можно задавать PLP в зависимости от значений CIR, PIR, CBS, EBS.

Зеленые пакеты могут стать желтыми.
=== Single-rate tricolor marking policy===
Полисинг основан на двух burst thresholds.
*Один threshold по скорости ('''CIR''')
*Два burst size threshold ('''CBS, EBS'''). Что дает создать 3 цвета для "окраски" трафика.
*Назначение цветов:
:*< CBS - зеленый = low PLP
:*CBS < x < EBS - желтый = medium-high PLP
:*> EBS - красный - high PLP
'''Конфигурация'''
set firewall three-color-policer 100m logical-interface-policer
set firewall three-color-policer 100m action loss-priority high then discard
set firewall three-color-policer 100m single-rate committed-information-rate 90m = '''CIR'''
set firewall three-color-policer 100m single-rate committed-burst-size 10m = '''CBS'''
set firewall three-color-policer 100m single-rate excess-burst-size 100m = '''EBS'''

set firewall family inet filter 100m term 1 then three-color-policer single-rate 100m

set interfaces xe-0/0/0 unit 100 family inet filter input 100m

===Two-rate tricolor marking policy===
Полисинг основан на 2х bandwidth thresholds.
*Два thresholds по скорости ('''CIR, PIR'''). Это уже создает 3 цвета для "окраски" трафика.
*Два burst size threshold ('''CBS, PBS''').
*Markings:
:*< CIR+CBS - зеленый = low PLP
:*CIR+CBS < x < PIR+PBS - желтый = medium-low PLP
:*> PIR+PBS - красный = high PLP

'''Конфигурация'''
set firewall three-color-policer 50-60m two-rate committed-information-rate 50m
set firewall three-color-policer 50-60m two-rate committed-burst-size 1m
set firewall three-color-policer 50-60m two-rate peak-information-rate 60m
set firewall three-color-policer 50-60m two-rate peak-burst-size 1m
set firewall three-color-policer 50-60m logical-interface-policer
set firewall three-color-policer 50-60m action loss-priority high then discard

set firewall family inet filter 50-60m term 1 then three-color-policer two-rate 50-60m

set interfaces xe-0/0/0 unit 100 family inet filter input 50-60m

===Color-blind mode===
Policer не рассматривает предыдущее окрашивание пакета. Любые прежние настройки - игнорируются. PLP назначайся в соответствии с настройками policer.

===Color-aware mode===
Policer учитывает предыдущую окраску пакета.

При обработке single-rate tricolor и two-rate tricolor на выходе получается пакет с результирующей меткой PLP + учитывается текущее прохождение пакета.

PLP может увеличиваться, оставаться прежним, но не уменьшаться.

Применение:
set firewall three-color-policer 100m single-rate ''(color-aware|color-blind)''
или
set firewall three-color-policer 50-60m two-rate ''(color-aware|color-blind)''

'''По умолчанию tricolor mode включён только на М120 и МХ серии.'''

Для остальных включается руками:
[edit class-of-service]
tri-color;

== Применение полисеров==
=== Interface policers ===
*Не часть firewall filter.
*Можно применить к: protocol family, logical int, physical int.
*Можно применить на input и output.
'''Конфигурация'''
Для '''protocol family''':
set interfaces ge-0/0/0 unit 500 family inet policer input 100m
set interfaces ge-0/0/0 unit 500 family inet policer output 100m

set firewall policer 100m if-exceeding bandwidth-limit 100m
set firewall policer 100m if-exceeding burst-size-limit 250k
set firewall policer 100m then loss-priority low

В таком случае threshold по трафику на каждую '''family''' будет 100 Мбит.

Для '''Logical interface policers''': полисер применяется к family на интерфейсе, но threshold теперь применяется ко '''всем family в unit''' сразу. То есть в нашем случае в общем на ge-0/0/0.110 будет ограничение 100m.

[edit firewall policer 100m]
+ logical-interface-policer;

=== Policing с использованием firewall filter ===
*Можно применять полисеры внутри ff: тогда в ''then'' нужно указать не терминирующее действие, а назначение policer.
*Могут применяться только к ''family''
*Могут применяться на in/out

'''Конфигурация'''

''hard'':
set firewall family inet filter hard term 1 from source-address 10.200.86.3/32 except
set firewall family inet filter hard term 1 then policer hard-100m
set firewall family inet filter hard term 1 then accept
set firewall family inet filter hard term all-accept then accept

set firewall policer hard-100m if-exceeding bandwidth-limit 100m
set firewall policer hard-100m if-exceeding burst-size-limit 250k
set firewall policer hard-100m then discard

''soft'':
set firewall family inet filter soft term 1 from source-address 10.200.86.3/32 except
set firewall family inet filter soft term 1 then policer soft-100m
set firewall family inet filter soft term 1 then forwarding-class expedited-forwarding
set firewall family inet filter soft term 1 then accept
set firewall family inet filter soft term all-accept then accept

set firewall policer soft-100m if-exceeding bandwidth-limit 100m
set firewall policer soft-100m if-exceeding burst-size-limit 250k
set firewall policer soft-100m then forwarding-class best-effort

В этом случае трафику, in-profile будет назначен fw-class expedited-forwarding, а трафику попадающему в out-of-profile - best-effort (default).

'''Filter-specific policer''': применяется к ''term'', на все термы суммарно будет одно общее ограничение. Применяется для выделения разных типов трафика, но policing над ними будет делаться как над одним потоком.

set firewall policer hard '''filter-specific'''
set firewall policer hard if-exceeding bandwidth-limit 100m
set firewall policer hard if-exceeding burst-size-limit 250k
set firewall policer hard then discard

set firewall family inet filter hard-f term A from source-address 10.200.86.5/32
set firewall family inet filter hard-f term A then policer hard
set firewall family inet filter hard-f term A then accept
set firewall family inet filter hard-f term B from source-address 10.200.86.3/32
set firewall family inet filter hard-f term B then policer hard
set firewall family inet filter hard-f term B then accept
set firewall family inet filter hard-f term all-other then accept

=== Physical interface policer ===
Дает возможность создать аггрегированный полисер для одного физического интерфейса.
Может быть полезным, если хочется создать общий полисер для разных ''family'' и разных ''unit'' на одном физическом интерфейсе.

''set firewall policer int-poli physical-interface-policer''
set firewall policer int-poli if-exceeding bandwidth-limit 100m
set firewall policer int-poli if-exceeding burst-size-limit 200k
set firewall policer int-poli then forwarding-class best-effort

''set firewall family inet filter phys-int physical-interface-filter''
set firewall family inet filter phys-int term A then policer int-poli
set firewall family inet filter phys-int term A then accept

set interfaces ge-1/0/5 unit 0 family inet filter input phys-int
set interfaces ge-1/0/5 unit 0 family inet6 filter input phys-int
set interfaces ge-1/0/5 unit 2 family inet filter input phys-int
set interfaces ge-1/0/5 unit 2 family inet6 filter input phys-int

В этом случае полисер 100 Мбит будет общим для всего физического интерфейса.

=== Policiers + Firewalls ===

Можно одновременно повесить на интерфейс и policer и filter.

'''Вх. трафик''' будет обрабатываться: 1.policer => 2.filter

'''Исх. трафик''' будет обрабатываться: 1.filter => 1.policer

== Shaping ==
Помимо policing, можно лишний трафик обрезать шейпером. В Основном shaping делается на выходе (к исх трафику).

Разница:
* policing на вх и вых | shaping на вых
* policing - hard: дропает лишний трафик, soft: меняет forwarding class, который в последующем скорей всего дропнется.
* shaping - лишний трафик кладет в буфер и чуть позже его передаст. Не хорошо для сервисов, чувствительных к задержке.
* policing может влиять ну судьбу трафика за пределами роутера, назначая forw class
* shaping не влияет на судьбу трафика за пределами роутера, т.к. кроме буферизации ничего не делает.

==Дополнительная информация==
*[[Глава 1. QoS]]
*[[Глава 2. Packet classification]]
*[[Глава 7. CoS-based forwarding]]
*[[Глава 8. Packet flow]]

Глава 2. Packet classification

2021-07-15T18:18:49Z

Наталия Бобкова:

{{#description2:Основы классификации пакетов. Дефолтные классы. Packet loss priority (PLP). Типы классификации: fixed (interface based), MF (multifield), BA (behavior aggregate), mixed. Классификаторы. Информация для подготовки к экзаменам Juniper.}}
=Основы классификации пакетов=
'''Цель классификации пакетов''': исследовать трафик и ассоциировать пакеты с конкретным cos service level (c forwarding class и loss priority). И уже на основании forw class пакет обрабатывается по правилам конкретной очереди (queue).

Т.е.: определение и назначение forwarding class = помещение пакета в нужную очередь.

Ассоциирование трафика происходит по code-point меткам любого типа: DSCP (ip) / EXP (mpls) и другим.

'''Forwarding class''' - не возникает извне сети. Но при назначении FW class конкретному типу трафика на начальном узле, может быть опознан и обработай корректно на других узлах сети.

Пакеты определенного класса могут быть перекласифицированы дальше в сети.
==Дефолтные классы==
На всех роутерах есть уже предустановленные F-classes и queues для них:
* BF (Best effort) = 0 queue - default for PHB - по умолчанию пакеты в этой очереди при заторах - дропаются.
* EF (Expedited forwarding) = 1 - гарантированная полоса, low loss, low delay, low jitter - хорош для voice. Избыточный трафик принимается но при отправке его дальше часть трафика может быть дроппнута, часть переслана в неверном порядке.
* AF (assured forwarding) = 2 - концентрация в основном на packet loss - хорошо для типа трафика, чувствительного к потерям. Избыточный трафик принимается, но к нему применяется: RED drop profile. 4 drop probabilities для этого класса: low, medium-low, medium-high, and high.
* NC (network control) = 3 - low priority. Но в условиях заторов - трафик не дропается, т.к. передает служебную инфу для протоколов.

Можно создавать свои или менять для существующих классов названия, например:
blair> show class-of-service forwarding-class
Forwarding class ID Queue Policing priority
be 0 0 normal
ef 1 1 normal
voice 2 2 normal
tv-data 3 3 normal

blair# show class-of-service forwarding-classes
class be queue-num 0;
class ef queue-num 1;
class voice queue-num 2;
class tv-data queue-num 3;

MX, T, M7i/M10i с CFEB-E: до 16 классов, до 8 очередей.

Назначение очереди происходит по следующим правилам:
*Если классификатор не занес пакет в какой-то класс, то умолчанию ему назначают BE forwardong-class, queue 0.
*Конфигурация CoS по умолчанию основана на номере очереди. Имя класса пересылки, которое появляется при отображении конфигурации по умолчанию - это класс пересылки, связанный в данный момент с этой очередью.
*Конфиг, где в QoS определено больше очередей, чем поддерживает роутер - не сможет быть закоммичен.

Только для BE и NC по дефолту определены и forwarding classes и schedulers. Для EF, AF требуется их (schedulers) настраивать.

Только IP precedence classifiers работают на интерфейсах.

==Packet loss priority (PLP)==

Определяет вероятность отбрасывания при заторах. Пакет с наибольшим PLP будет отброшен первым.

PLP назначается на ingress, когда используем классификаторы. Однако, PLP также можно назначить и позднее с помощью policer.

PLP может принимать 4 значения: low, medium-low, medium-high, high. По умолчанию JunoOS использует 2: low, high.

Если смотреть на default classifier, можно менять их в конфигурации:

000 - best-effor (low)

001 - best effort (high)

010 - exp-forwarding (low)

011 - exp-forwarding (high)

...

110 - network-control (low)

111 - network-control (high)

lower-priority = high drop eligibility

=Виды классификаций=
Каждый Ingress interface должен выбрать для себя способ классификации.

== Fixed classification (interface based)==
Один forwarding class назначается на unit (vlan) и применяется ко всем входящим пакетам.

Классификация очень грубая.

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

Или если upstream узел ненадежный и нужно ''перекрасить'' весь трафик, приходящий на этот порт (обычно BE в подобных ситуациях).

При использовании такого метода нельзя сделать исключения для какого-то трафика, поэтому такой метод считается не очень "гибким" для использования.

'''Config'''
blair# show class-of-service interfaces
ge-0/0/0 {
unit 60 {
forwarding-class voice;}}

== MF (multifield) classification ==

Классификация основана на 1 или более полей в заголовке пакета: port, IP, prefix, mac.

Для выделения нужного трафика по определенным полям используется обычный '''stateless''' firewall-filter. (использует не только source/dest ip).

MF лучше применять на ingress (в самом начале попадания пакета в сеть).

Можно использовать MF для переклассификации пакетов, классифицированных ранее BA.

Config (можно писать несколько term, определяя по разным параметрам трафик и запихивая его в разные очереди)
set interfaces ge-0/0/0 unit 80 family inet filter input qos-tv-data

set firewall family inet filter qos-tv-data term 1 from source-address 239.30.30.0/24
set firewall family inet filter qos-tv-data term 1 then '''forwarding-class tv-data'''
set firewall family inet filter qos-tv-data term 1 then '''accept'''
set firewall family inet filter qos-tv-data term all-accept '''then accept'''

== BA (behavior aggregate) classification ==
BA классификация основана по уже заданному у пакета значении QoS, т.е. пакет уже был ранее классифицирован другим устройством и присвоил конкретную QoS метку. На основании этой метки пакет будет обработан устройством.

Здесь напрямую приводится соответствие: CoS <> Forwarding class + PLP => более эффективный способ по сравнению с MF (не нужно тратить ресурсы на классификацию).

Применяется к unit (vlan).

Обрабатывает все пакеты с одинаковой CoS меткой - одинаково.

Обеспечивает одинаковый приоритет трафика на всей сети.

Хорош для core device.

Может работать по: IPv4 DSCP, IPv6 DSCP, IP precedence bits, MPLS EXP bits (experimental), IEEE 802.1p CoS bits, IEEE 802.1ad drop eligible indicator (DEI).

Все логические интерфейсы по умолчанию используют ipprec-compatibility => если включить MPLS на интерфейсе - он будет использовать exp-default классификатор.

BA классификатор лучше применять внутри сети (не на входе в сеть).

set class-of-service interfaces ge-0/0/0 unit * classifiers dscp dscp-classifier
set class-of-service interfaces ge-0/0/0 unit * classifiers exp exp-classifier

set class-of-service classifiers dscp dscp-classifier forwarding-class best-effort loss-priority low code-points be
set class-of-service classifiers dscp dscp-classifier forwarding-class vpn loss-priority low code-points vpn-low
set class-of-service classifiers dscp dscp-classifier forwarding-class vpn loss-priority high code-points vpn-high
set class-of-service classifiers dscp dscp-classifier forwarding-class vpn-priority loss-priority low code-points vpn-priority
set class-of-service classifiers dscp dscp-classifier forwarding-class nc loss-priority low code-points nc
set class-of-service classifiers exp exp-classifier forwarding-class best-effort loss-priority low code-points be
set class-of-service classifiers exp exp-classifier forwarding-class vpn loss-priority low code-points vpn-low
set class-of-service classifiers exp exp-classifier forwarding-class vpn loss-priority high code-points vpn-high
set class-of-service classifiers exp exp-classifier forwarding-class vpn-priority loss-priority low code-points vpn-priority

set class-of-service code-point-aliases dscp be 000000
set class-of-service code-point-aliases dscp vpn-low 001010
set class-of-service code-point-aliases dscp vpn-high 001100
set class-of-service code-point-aliases dscp vpn-priority 101110
set class-of-service code-point-aliases dscp nc 110000
set class-of-service code-point-aliases exp be 000
set class-of-service code-point-aliases exp vpn-low 010
set class-of-service code-point-aliases exp vpn-high 011
set class-of-service code-point-aliases exp vpn-priority 101

p.s. code-points можно использовать и дефолтные, а можно прописать свои user-friendly. Посмотреть существующие: ''show class-of-service code-point-aliases''

==Mixed classification==
На интерфейс можно применить как MF, так и BA классификатор.
*Сначала производится классификация по BA, потом по MF.
*При этом если трафик подойдет под оба классификатора, то так как последним будет MF, то и трафик классифицируется по его правилам.

=Classifiers=
blair> show class-of-service interface
Logical interface: ge-0/0/0.100, Index: 72 ('''IPv4 + MPLS interface''')
Object Name Type Index
Rewrite '''exp-default''' exp (mpls-any) 33
Classifier '''exp-default''' exp 10
Classifier '''ipprec-compatibility''' ip 13
Logical interface: ge-0/0/1.0, Index: 75 ('''only IPv4 interface''')
Object Name Type Index
Classifier '''ipprec-compatibility''' ip 13

Остальные дефолтные классификаторы:
blair> show class-of-service classifier | match Classifier
Classifier: '''dscp-default''', Code point type: dscp, Index: 7
Classifier: '''dscp-ipv6-default''', Code point type: dscp-ipv6, Index: 8
Classifier: '''dscp-ipv6-compatibility''', Code point type: dscp-ipv6, Index: 9
Classifier: '''exp-default''', Code point type: exp, Index: 10
Classifier: '''ieee8021p-default''', Code point type: ieee-802.1, Index: 11
Classifier: '''ipprec-default''', Code point type: inet-precedence, Index: 12
Classifier: '''ipprec-compatibility''', Code point type: inet-precedence, Index: 13
Classifier: '''ieee8021ad-default''', Code point type: ieee-802.1ad, Index: 41

Если хотите использовать другой (или несколько других), то в ''class-of-service interfaces'' нужно их применить к интерфейсу.
blair# set class-of-service interfaces ge-0/0/0 unit 100 classifiers ?
> dscp Differentiated Services code point classifier
> dscp-ipv6 Differentiated Services code point classifier IPv6
> exp EXP classifier
> ieee-802.1 IEEE-802.1 classifier
> ieee-802.1ad IEEE-802.1ad (DEI) classifier
> inet-precedence IPv4 precedence classifier

При создании собственных классификаторов, для простоты можно использовать дефолтные классификаторы как шаблон и заменить некоторые правила на свои. (в режиме конфигурации классификатора: import <default classifier>)
[edit class-of-service]
classifiers {
dscp voice {
'''import default''';
forwarding-class assured-forwarding {
'''loss-priority high code-points 001000'''; }}}
[edit class-of-service interfaces ge-0/0/0]
unit 100 {
classifiers {
dscp voice;}}
=Дополнительная информация=
*[[Глава 1. QoS]]
*[[Глава 4. Scheduling]]
*[[Глава 6. Rewrite rules]]

Глава 1. QoS

2021-07-15T18:17:51Z

Наталия Бобкова:

{{#description2:Основы QoS. Различие IntServ и DifServ. Где можно увидеть метку QoS. Процесс работы QoS. Информация для подготовки к экзаменам Juniper.}}

=Основы QoS=
QoS [quality of service] - обработка агрегированного трафика таким образом, чтобы поток передавался с требуемыми от генератора трафика правилами.

CoS [class of service] - конфигурация определенной обработки трафика на конкретном узле.

Каждый класс ассоциирован с трафиком, который требует одинаковой обработки, пока он идет по сети.

Важно понимать, что неправильно заданное привило обработки трафика на одном из хопов может убить всю концепцию QoS на вашей сети.

'''Как описать поведение (обработку) трафика?'''

QoS поведение описывает как должен обрабатываться определенный тип трфика, пока он проходит по сети. Обычно, поведение можно описать с помощью следующих важных параметров:
*'''Loss''': кол-во потерянных пакетов от source к dest. Некоторые виды трафика терпимы к потерям, некоторые запрашивают повторную отправку потерянных пакетов, некоторые устанавливают tcp-соединение, чтобы не терять пакеты.
*'''Latency''': задержка: время передачи пакета по сети от source к dest.
*'''Jitter''': разница между задержкой последовательно передаваемых пакетов.
*'''Bandwidth''': объем передаваемой информации.

=IntServ vs DifServ=

*'''BE''': Best effort: Негарантированная доставка. Обрабатывает трафик по принципу FIFO: first in - first out. По идее такая схема будет работать хорошо, только если на сети есть запасные емкости и не бывает полок. Это обработка трафика без настроенного QoS.
*'''IntServ:''' Integrated Service: Модель обслуживания, которая гарантирует качество за счет резервирования необходимой полосы. Использует RSVP.
*'''DifServ:''' Differentiated Service: Это модель привычная - разделяет классы трафика и в зависимости от этого каждый класс обрабатывает по своему. Разница с IntServ - нет сигналинга.

При использовании DiffServ узлы обрабатывают "аггрегированный трафик" - '''BA(behavior aggregate)'''. Аггрегируется он по типу трафика.

'''DiffServ field (DS)''': IPv4 ToS field, передающий DSCP.

'''DSCP''' DiffServ Code point - определение BA разных типов трафика. Используется поле ToS => имеет 6 бит => 64 значения.

'''PHB''' Per-hop behavior - как маршрутизатор будет обрабатывать трафик в зависимости от DSCP. (AF1, AF2, AF3, AF4, ...). PHB использует DSCP.

Default PHB - Best Effort.

'''PHB group''' - набор PHB (AF: AF11, AF12...).

На '''edge node''' сваливается больше нагрузки: полисинг, классифицирование трафика, шейпинг, аккаунтинг.

На '''core node''' сваливается меньше нагрузки: BA-based classification и передача трафика в зависимости от PHB.

Основные типа DiffServ PHB:
* BF (Best effort) - default for PHB.
* EF (Expedited forwarding) - low loss, low delay, low jitter - voice.
* AF (assured forwarding) - концентрация в основном на packet loss. Содержит 4 класса: AF1, AF2, AF3, AF4. Каждый из них имеет по 3 Drop probabilities: AF11 (low), AF12 (medium), AF13 (high) .
*Class selectors Code Points: network control.

Для каждого типа PHB есть свой рекомендованный DSCP.
> show class-of-service code-point-aliases dscp

=Где можно увидеть метку QoS=
==IPv4==
'''ToS'''
Был такой байт ToS, который состоял из 3 бита - IP precedence, остальные: D, T, R, ECN. Сейчас байт ToS состоит из: первые '''6 бит - DSCP''' (3 - CS/AF, 3 - циферки, определяющие класс и приоритет)

CS: Class selector: это первые 3 бита DSCP. Используется для обратной совместимости.

'''IP precedence''': приоритет: первые 3 бита в байте ToS. Использовался для того, чтобы минимизировать дропы control трафика.

==IPv6==

'''TC''': traffic class: 1 байт.

=== Frame ===

'''PCP''': priority code point: Используются 3 бита начала 802.1p заголовка (поле с vlan) - может использовать 8 значений приоритета.

==MPLS==

'''TC''': traffic class: 3 бит - 8 значений приоритета трафика.

=Процесс работы QoS=

Code Point (BA) Classifier => Policing (rate limitimg) => Multifield Classifier => Forwarding Policy => Fabric => Policing => Multifeild Classifier => [RED | Shaper | Scheduler] => Rewriting QoS field

'''Classifiers''' на ingress роутере создает соответствие трафика и определенного forwarding class, основываясь на BA (если с пакетом уже передана QoS метка): IP precedence, DSCPs, MPLS EXP bits, or IEEE 802.1P priority values.

'''Policing''' ограничивает кол-во трафика: превышенный трафик может быть либо отброшен, либо промаркирован и далее обработан определенным образом.

'''Multifield classifier''' выделение определенного типа трафика с помощью firewall filters, назначение forwarding class и PLP.

'''CBF: CoS based forwarding''' - определенный трафик можно посылать к определенному next-hop.

'''Schedulers''': обработка очереди, ассоциированной с forwarding class. Определяет transmission rate, queue priority, delay buffers, congection management and avoidance (RED/WRED algorithm).

RED алгоритм в случае затора отбрасывает пакеты.
WRED алгоритм при принятии решения об отбросе пакет учитивает значения traffic type и loss priority.

'''Rewrite markers''': можно перезаписать QoS поля в заголовке пакета, чтобы следующий роутер мог проводить классификацию не заново, а обрабатывал бы прилетевший пакет по значению в заголовке (BA classification). IP precedence, DSCP (IPv4, IPv6), MPLS EXP, IEEE 802.1p.
{{note|text=''QoS является "однонаправленным".'' То есть для настройки QoS на каком-то линке - нужно настроить его как для вх так и для исх направления.}}
=Дополнительная информация=
*[[Глава 2. Packet classification]]
*[[Глава 7. CoS-based forwarding]]
*[[Глава 8. Packet flow]]

ERP (Ethernet Ring Protection)

2021-07-15T18:16:27Z

Наталия Бобкова:

{{#description2:Основы ERP. Падение линка. Восстановление линка. Информация для подготовки к экзаменам Juniper.}}
== ERP (Ethernet Ring Protection) ==

=== Idle state: ===
*Node A каждые 5 секунд отправляет R-APS сообщения во все интерфейсы.
(Request/State = no request, not flush = 0, RPL state block = 1).
*Остальные узлы узлы тупо передают друг другу APS сообщения то узла А.
*RPL (ring protection link) - заблокирован.

=== Случилась авария. ===
*Узел B и С через 50 мс отправляют R-APS.
(Request/State = fail, no flush = 0).
*Узлы В и С отправляют 3 сообщения R-APS подряд в первые 10 мс.
*Упавший линк - блокируют, чистят маки.
*Узел А отправляет APS
(Request/State = no request, no flush = 1, RPL state block = 0).
*Состояние Idle -> protection.
*Узел А разблокирует RPL, слушает сообщения от своих соседей.

=== Восстановился линк. ===
*Узлы В и С продолжают блокировать восстановленный линк.
(Request/State = no request, no flush = 1).
*Узел А ждет 5 минут (минимальное значение), после чего, блокирует RPL, отправляет APS сообщения во все интерфейсы
(Request/State = no request, no flush = 0, RPL state block = 1).
*Состояние protection -> idle.
*Все узлы чистят маки.

==Дополнительная информация==
*[[L2 switching and VLANs]]
*[[Spanning-Tree protocol (STP)]]
*[[Virtual Chassis]]
*[[Provider bridging]]

Provider bridging

2021-07-15T18:15:51Z

Наталия Бобкова:

{{#description2:Перемаркировка вланов. Tunnel all C-vlans. Explicit configuration of Tag operations. Network-to-Network interface. Информация для подготовки к экзаменам Juniper.}}
= Перемаркировка вланов =

Разделяют 2 типа планов:

* S-vlan (service vlan) - outer tag
* C-vlan (customer vlan) - inner tag

Режимы Bridge domain'ов:
* Independent VLAN learning mode (ILV) - трафик флудится в интерфейсы, принадлежащие одному домену.
* Shared VLAN learning mode (SLV) - трафик флудится во все интерфейсы и во все вланы, принадлежащие одному домену.

= Tunnel all C-vlans =

Cust-site-1 (trunk) - (trunk) ISP-edge1 (trunk) - (trunk) ISP-core (trunk) - (trunk) ISP-edge2 (trunk) - (trunk) Cust-site-2

(trunk) ISP-edge1
fe-0/0/2 {
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list 200-205;

ISP-edge1 (trunk):
fe-0/0/3 {
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list 100;

ISP-edge1
# show bridge-domains
vlan100 {
domain-type bridge;
vlan-id 100;

= Range of C-vlans (Part1) =

Cust-site-1 (access) - (access) ISP-edge1 (trunk) - (trunk) ISP-core (trunk) - (trunk) ISP-edge2 (access) - (access) Cust-site-2

Для каждого C-vlan создается свой logical-interf + свой bridge domain.

Для каждого клиента создается свой виртуальный роутер.

ISP-edge1
bridge-domains {
bd {
vlan-id-list 200-205;

(access) ISP-edge1
fe-0/0/2 {
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list 200-205;

ISP-edge1 (trunk):
fe-0/0/3 {
flexible-vlan-tagging;
unit 0 {
vlan-id 300;
family bridge {
interface-mode trunk;
inner-vlan-id-list 200-205;

= Range of C-vlans (Part2) =

Cust-site-1 (units) - (units) ISP-edge1 (trunk) - (trunk) ISP-core (trunk) - (trunk) ISP-edge2 (units) - (units) Cust-site-2

(units) ISP-edge1
fe-0/0/2 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 200 {
encapsulation vlan-bridge;
vlan-id 200;
}
unit 201 {
encapsulation vlan-bridge;
vlan-id 201;
}
unit 202 {
encapsulation vlan-bridge;
vlan-id 202;
...

ISP-edge1 (trunk)
fe-0/0/3 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation vlan-bridge;
vlan-tags outer 300 inner 200;

ISP-edge1
bridge-domains
bd {
vlan-id none;
interface fe-0/0/2.200;
interface fe-0/0/2.201;
interface fe-0/0/2.202;
interface fe-0/0/2.203;
interface fe-0/0/2.204;
interface fe-0/0/2.205;

Что происходит с фреймом:
#От клиента прилетает фрейм с меткой 201, с мак-адресом назначения, который находится в site2.
#Так как bridge-domain сконфигурирован с vlan-id-none, C-vlan срезается до начала mac-table-lookup.
#Если dst-mac неизвестен, то фрейм флудится во все интерфейсы данного домена, включая сабинтерфейсы fe-0/0/2. Если dst-mac известен, фрейм передается через fe-0/0/3.0 с C-vlan 200, S-vlan 300.
#На ISP-edge2 в домене также прописан vlan-id-none, поэтому S-vlan и C-vlan срезаются до mac-table-lookup.
#Если dst-mac неизвестен, то фрейм флудится во все интерфейсы данного домена, включая сабинтерфейсы fe-0/0/2. Если dst-mac известен, фрейм передается через назначенный сабинтерфейс, навешивая нужный tag.

= Explicit configuration of Tag operations =

Cust-site-1 (access) - (access) ISP-edge1 (trunk) - (trunk) ISP-core (trunk) - (trunk) ISP-edge2 (access) - (access) Cust-site-2

(access) ISP-edge1
fe-0/0/2 {
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 200 {
encapsulation vlan-bridge;
vlan-id 200;
input-vlan-map {
push;
vlan-id 300;
}
output-vlan-map pop;

ISP-edge1 (trunk)
fe-0/0/3 {
encapsulation flexible-ethernet-services;
unit 0 {
vlan-tags outer 300 inner 200;

ISP-edge1
bridge-domains {
cust1 {
interface fe-0/0/2.200;
interface fe-0/0/3.0;

= Network-to-Network interface =

Cust-site-1 - ISP1-edge1 - ISP1-core (trunk) - (trunk) ISP2-core - ISP2-edge2 - Cust-site-2

ISP1-core (trunk)
fe-0/0/6 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 1 {
family bridge {
interface-mode trunk;
vlan-id-list 200;
vlan-rewrite {
translate 300 200;

ISP1-core
# show bridge-domains
bd {
vlan-id 200;
=Дополнительная информация=
*[[L2 switching and VLANs]]
*[[Spanning-Tree protocol (STP)]]
*[[Virtual Chassis]]
*[[ERP (Ethernet Ring Protection)]]

Virtual Chassis

2021-07-15T18:15:06Z

Наталия Бобкова:

{{#description2:Компоненты virtual chassis. Master/Backup/Linecard. Обновление софта. High Availability. Управление virtual chassis. Информация для подготовки к экзаменам Juniper.}}
=Общее=
Кол-во свитчей, объединенных в одно шасси зависит от версии софта и модели.

Можно объединять разные модели в стек. Софт при этом должен быть одинаковым у всех свитчей.
==Компоненты==
===VC-port===
Для объединения в стек используются специальные порты VCP (Virtual Chassis Ports).

Некоторые модели свитчей имеют выделенные стековые порты, некоторые не имеют таковых.

Чтобы объединить в стек свитчи, не имеющие отдельных VCP, или чтобы объединить свитчи, находящиеся на большом расстоянии друг от друга, можно использовать обычные порты, настроив их как VCP.

SFP, SFP+, и XFP могут выполнять роль VCP портов.

Если требуется емкость более 40G между членами стека (стековые порты и кабели поддерживают именно такую скорость), можно сделать 2 линка между свитчами.

Оптические порты между двумя свитчами с одинаковой скоростью передачи, выступающие в роли VCP, автоматом объединяются в LAG (bundle). Порты с разной скоростью в LAG не соберутся.

Когда оптический порт настроен в роли VCP, он не может использоваться в других целях.

VCP используются как для служебного трафика между свитчами, так и для передачи трафика между свитчами.

Все 40Gb QSFP+ порты на EX4300 под дефолту используются как VCP.

Все 10Gb порты могут быть настроены и использоваться в качестве VPC.

===Master/Backup/Linecard===
При объединении в стек, свитчи играют разные роли.

====Master====
*управляет членами стека
*запускает Junos
*управляет шасси и control protocols (для chassis)
*держит единую конфигурацию для всего стека

Если включить один свитч, который поддерживает стекирование, он будет иметь роль мастера.

Если в стеке более одного свитча, то один будет мастером, один резервным (backup), остальные - линейные карты (linecard).

Если для стека используются EX4300 и EX4600, то EX4600 должна быть назначена роль мастера.

Если для стека используются EX4200, EX4500, EX4550, то любой из них может выполнять роль мастера.

====Backup====
*находится в состоянии подхватить роль мастера, если мастер перестанет работать
*синхронизирует с мастером: состояния протоколов, forwarding tables и т.д...

Если для стека используются EX4300 и EX4600, то EX4600 должна быть назначена роль backup (то есть если есть возможность EX4600 - master, второй EX4600 - backup).

В случает использования EX4200, EX4500, EX4550 - любой подходит для роли backup.

====Linecard====
*выполняет роль линейной карты, то есть как дополнительный свитч с портами
*не запускает chassis control protocols
*не может даже определить состояния интерфейсов (или ошибок), которые были настроены через master.

====Mastership-priority====
Для назначения роли члену стека используется '''mastership-priority'''. Значение [0-255].

Более высокое значение более приоритетно.

Дефолтное значение = 128.

Назначение одинакового приоритета master и backup позволяет более гладко произвести процесс переключения роли master на backup свитч. Также это позволяет на стать master свитчу, который после перерыва вернулся в работу, то есть избежать еще одного перерыва.

Свитч с mastership-priority = 0 всегда будет работать только в роли linecard.
====Master Election====
#Выбирается с наибольшим mastership-priority
#Выбирается тот свитч, который был master в последний раз
#Выбирается тот свитч, который находится в стеке большее количество времени. (считается разница в 1 мин)
#Выбирается по наименьшему mac-address

Модели свитчей никак не играют роли в выборе.

Чтобы быть точно уверенным, что нужный свитч будет выступать в роли master:
#Включаем свитч (будущий master)
#Задаем ему mastership-priority = 255
#Задаем приоритеты другим членам стека
#Включаем остальные свитчи

====Member switch/Member ID====
Каждый свитч, поддерживающий функцию стекирования назначает себе member-id. Если включить свитчи не объединяя их в стек, каждый из них будет иметь member-id = 0.

Когда свитчи объединили в стек, master назначает каждому члену свой уникальный member-id, исходя из порядка, в котором свитчи были включены, исходя из преднастроенного member-id.

Если в стеке был member, который физически отключили, его member-id более не будет использоваться мастером для присвоения member-id новому члену стека.

Member-id работает как номер fps-слота.
=Обновление софта=
В кластере все свитчи должны обязательно иметь одинаковую версию софта.

Софт можно поставить на весь кластер или на каждый свитч отдельно. Для этого используется одна и та же команда:
request system software add validate

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

Чтобы избежать длительного перерыва при обновлении, можно использовать NSSU. Он позволяет обновить отдельно каждого member'а, а при использовании дополнительных HA фид, перерыв можно сделать очень коротким (или вообще без перерыва обновить).

=High Availability=
Само по себе использование стека из EX - уже неплохое средство для HA.

1. LAG (Link Aggregation Groups): подключать CE двумя линками на разные members.

Без HA: kernel и forwarding state инфо не сохраняется инфо на обе RE. Поэтому процесс конвергенции занимает время, также как и процесс switchover может занимать до нескольких минут, до окончания процесса не передается трафик.

#GRES (Graceful routing Engine switchover): kernel и forwarding state инфо хранится на обеих RE, что обеспечивает отсутствие конвергенции и сильно сокращает перерыв в передаче графики при switchover.

#NSB (nonstop bridging): l2-протоколы, поддерживающие NSB, не падают при switchover. Инфо l2-протоколов хранится на обеих RE.

#NSR (nonstop routing): l3-протоколы, поддерживающие NSR, не падают при switchover. Инфо хранится на обеих RE.

#Graseful Protocol Restart: передача трафика не прерывается при switchover. interface и kernel инфо зарезервирована. Когда Control plane роутера падает, роутер не сразу сообщает об этом своим соседям а ждет заданный промежуток времени. Но! сосед тоже должен уметь GR.

=Управление=
Из-за наличия нескольких свитчей в стеке к кластера появляется дофига консольных и mgmt портов. К какому подключиться?

При подключении к любому, нас отредиректит к master.

Если мастер сменился, то console сессия отключится от старого master и переустановится к новому.

vme-port - виртуальный, используется для управления. По логинении на ip, настроенный на vme порту, кластер редиректнет вас на master switch.

=Конфигурация=
=Траблшутинг=
show virtual-chassis
show virtual-chassis vc-ports all-members
=Дополнительная информация=
*[[L2 switching and VLANs]]
*[[Provider bridging]]
*[[Spanning-Tree protocol (STP)]]

Spanning-Tree protocol (STP)

2021-07-15T18:14:20Z

Наталия Бобкова:

{{#description2: Основы Spanning-Tree protocol (STP). Роли портов. Состояния портов. BPDU. Модификации STP. Конфигурация STP. Мониторинг и траблшутинг STP. Информация для подготовки к экзаменам Juniper.}}
==В общем==
Ethernet легко подвержен бродкаст-штормам, когда в сети возникают петли.

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

STP как раз дает возможность использовать резервирование, но избежать петель.

Juniper поддерживает данные вариации STP: STP, RSTP(используется по дефолту), MSTP, VSTP.

''Итого зачем вообще нужен STP:''
:- Предотвращает бродкаст штормы
:- Обеспечивает резервирование дополнительными линками, без петель
:- Позволяет подключать к сети устройства, не поддерживающие STP (используя edge ports)

Корень дерева (''root tree | root bridge'') - это свитч, который выбирается алгоритмом STP на основании Bridge ID (Bridge Priority [0 - 65535] + MAC-addr свитча). Default priority = 32 768. В приоритете коммутатор с наименьшим Bridge ID. В дальнейшем он используется для рассчета наилучшего пути от bridge до root bridge.

Фреймы ходят по сети к получателю - ''leaf'' (ПК или любой другой не транзитный хост) - вдоль ветвей (''branches'').

Tree branch (ветвь) - сегмент сети или линк между бриджами.

''Designated bridges'' - свитчи, которые передают фреймы по STP-дереву.

STP создает единственный возможный путь между ''root'' и ''leaf''. Альтернативные пути переводятся в standby режим.

==Роли портов (RSTP)==
*''Root port'' - ближайший к root bridge. Это единственный порт, который получает фреймы от root bridge и пересылает их на него. Root bridge от себя отправляет BPDU с cost = 0. свитч, получивший BPDU - добавляет cost интерфейса, с которого пришел BPDU. И так далее. В случае, когда cost равнозначны с двух интерфейсов - будет выбран с наименьшим номером (ge-0/0/0, в не ge-0/0/10).
*''Designated port'' - порт, передающий трафик от root bridge к leaf. Designated bridge имеет один designated порт для каждого LAN. Root bridge передает фреймы во все designated порты. Также определяется по наименьшей cost. На root bridge все порты designated. На Leaf только один designated, иначе петля.
*''Alternate port'' - альтернатиный порт к root bridge. Он не является частью активного spanning tree, но когда root port накрывается (если падает линк или переходит в состояние отбрасывания пакетов), то alternate port сразу принимает на себя его роль. Отсутствует в обычном STP, за счет чего STP отстает по времени сходимости.
*''Backup port'' - резервный для desidnated порта. Работает аналогично alternate port.
*''Disabled port'' - порт, не принимает участия в активном spanning tree.
*''Edge port'' - порт в сторону хоста, не поддерживаюшего STP (ПК, сервер, роутеры, тупиковые хабы). Т.к. предполагается, что хосты не способны образовать петлю => edge port сразу переходит в состояние передачи фреймов. Можно назначить edge порт, а также STP может сам распознать edge порт (через отсутствие связи с конечными станциями).

В STP:
*root
*designated
*non-designated
*disabled

==Состояния портов (RSTP)==
*Discarding - отбрасывает все BPDU, все data-фреймы и не изучает mac-адреса. [в STP аналогичен по функциям: blocking, disabled, learning]
*Learning - изучает маки, и строит таблицу коммутации и пересылает BPDU
*Forwarding - порт пересылает и фильтрует фреймы > становится частью активного spanning tree. Также есть обмен BPDU.

В STP:
*blocking - ничего не шлет, но слушает BPDU
*listening - начинает отправлять BPDU, но пока не фреймы
*learning
*forwarding
*disabled - admin down. ничего не пересылает.

==BPDU (bridge protocol data units)==
BPDU фреймы - это сообщения, которыми обмениваются свитчи. В них содержится информация: bridge ID, root path costs, и port MAC addresses. Начальный обмен BPDU между коммутаторами определяет root bridge.
Также BPDU распространяют информацию о стоимости маршрутов (cost) между ветками (tree branches) - основанные либо на пропускной способности линков, либо заданные вручную. RTSP строит топологию исходя из cost. На этапе построения топологии используются Configuration BPDU.

Когда отработал STA (spanning tree algorithm), всем портам назначены роли и состояния, идентифицированы root и designated bridges, требуется механизм для поддержания данной топологии в актуальном состоянии. Используем BPDU.

Root bridge отправляет BPDU каждые '''2 сек''' (дефолтный hello time interval RSTP) на мультикаст-адрес: '''01:80:c2:00:00:00'''. Когда на порт приходит BPDU, он сравнивает данные, с полученными ранее, и на основании сравнения:
:- Если данные BPDU совпадают с существующей записью в таблице MAC-адресов, порт сбрасывает таймер max age на 0 и пересылает новый BPDU с текущей активной информацией о топологии на следующий порт в spanning tree.
:- Если топология в BPDU была изменена, обновляется таблица MAC-адресов, max age устанавливается в 0, и новый BPDU пересылается с текущей активной информацией о топологии на следующий порт в spanning tree.
:- Когда порт не получает BPDU в течение 3 * hello (3*2 = 6 сек), он реагирует одним из двух способов.
::-Если bridge является root port: происходит полное перестроение spanning tree.
::-Если bridge является любым некорневым мостом: RSTP обнаруживает, что подключенный хост не умеет отправлять BPDU, и назначает этот порт в edge port.
{{note|text=STP генерирует свои BPDUs. Сетевуха на хосте (ПК, сервер, ...) тоже генерирует свои BPDUs. Эти BPDU хостов могут быть обработаны STP свитча и привести к проблемам на сети. Поэтому лучше включать BPDU Protection на edge ports.}}

Бывают BPDU:
*configuration BPDUs
*topology change notification (TCN) BPDUs
*topology change acknowledgment (TCA) BPDUs

==Root Bridge Fails==
Когда link на root port падает, в BPDU добавляется флаг, topology change notification (TCN).

Когда этот BPDU доходит до следующего порта в VLAN, таблица MAC-адресов сбрасывается, и BPDU едет на следующий bridge. В итоге, все порты во VLAN обнулили свои таблицы MAC. После этого RSTP назначает новый root port.

Если root port или designated port падают - alternate или backup port берут на себя их роль после обмена BDPU (proposal-agreement handshake).

Если локальный порт становится root или designated, то он согласовывает быстрое изменение тем же proposal-agreement handshake с ближайшим свитчем.

Так как падение линка приводит к очистке маков на всей сети - это немного затормаживает работу сети и образует неплохой такой флуд для переобучения маков.

Включенный ''ARP (address resolution protocol)'' заставляет коммутатор активно отправлять ARP-запросы на IP-адреса в кэше ARP.
{{note|text=Включение ARP в STP наиболее полезно для избегания чрезмерного флуда в L2.}}

==Модификации STP==
===STP===
STP работает на основании "создания" bridge (switch).

Root bridge (switch) - в самом верху.

Ethernet от root switch подсоединяет другие свитчи в Local Area Network (LAN).

В STP и RSTP инстансах свитчам присваиваются extended system-id.

При изменении топологии, bridge извещает об этом root bridge, который требует от остальных почистить записи текущей топологии.

В построенном дереве только root bridge генерирует BPDU.

Дефолтные тайминги '''50 sec''' до перехода в состояние forwarding.

Нахождение порта в состояниях:
*blocking (20 sec)
*listening (15 sec)
*learning (15 sec)
*forwarding

Другие таймеры:
*Hello (2 sec)
*Max Age (20 sec)
*Forward delay timer (15 sec)

'''+''':
*Работает с 802.1D 1998 bridges
*STP обратносовместим с RSTP, можно включать STP на 802.1D 1998 bridges
*Годится для устаревших сетей, где не требуется быстрая сходимость.

'''-''':
*STP и RSTP ограничены одним инстансом для одного интерфейса. Используется set rstp interface для включения интерфейса в RSTP инстанс.
*STP медленее RSTP
*Не разделяет вланы. Создает spanning tree без учетов вланов и возможности постоения топологии для каждого влана. (в MSTP решена эта проблема)
*Не обеспечивает быструю сходимость. STP использует тайминги, RSTP использует handshake механизм.
*В IEEE 802.1D STP не используются edge ports.

'''На MX''' (c 14.1R1):
- Без включения traceoptions работает логирование состояний и ролей интерфейсов STP.
- Сбор информации что стриггерило изменения в STP (роль или статус).

'''На SRX''':
Поддерживается начиная с 15.1X49-D70 на некоторых девайсах.

'''На EX''':
По дефолту используется RSTP.
Если работаем с Junos, поддерживающем Enhanced Layer 2 Software (ELS) - можно указать чтобы STP использовался принудительно (через указание force-version в конфиге).

Основные команды:
show spanning-tree statistics message-queues
show spanning-tree stp-buffer see-all
show spanning-tree statistics bridge
show spanning-tree statistics interface
clear spanning-tree stp-buffer

====Config====
1. удаляем RSTP глобально или выключаем на конкретных интерфейсах:
delete protocols rstp
set protocols rstp interface ge-0/0/0.0 disable

2. включаем STP глобально или для конкретных интерфейсов:
set protocols stp interface all
set protocols stp interface ge-0/0/0.0

3. для более быстрого изучения маков - включаем Address Resolution Protocol (ARP) [при использовании irb | rvi]
set protocols stp interface all arp-on-stp
set protocols stp interface ge-0/0/0.0 arp-on-stp

===RSTP (Rapid STP)===
Отличие в скорости реакции на изменение топологии. При изменении топологии, свитч немедленно чистит записи о текущей топологии. Для p2p и edge-портов - быстрый переход к forwarding state.

+ появились alternate и backup роли портов. Что дает возможность заранее подготовиться к факапу, а не принимать решение во время факапа.
{{note|text=STP: сходимость до 50 сек}}
{{note|text=RSTP: сходимость 6 сек (3 * hello BPDU interval)}}

В построенной топологии (дереве) все свитчи генерируют BPDU каждые 2 sec.

В RSTP добавились port-mode:
*'''shared''' (half duplex) - p2p между свитчами, проходит обычный цикл во всеми таймингами blocking > listening > learning > forwarding.
*'''p2p''' (full duplex) - тут свитч сам запрашивает у соседа-свитча на p2p линке - давай дружить (тут вся инфа о нашем bridge), я вижу root bridge вот так. Сосед принимает решение, сравнивая полученные данные с уже имеющимися. Для обмена данными используются proposal BPDU (запрос локального bridge) и agreement BPDU (ответ соседа). Этот метод обмена данными обходит стороной дефолтные тайминг STP и является основням ускорителем RSTP.
*'''egde''' - для конечных устройств. Моментально становятся в состояние - forwarding.

По дефолту именно RSTP используется в Juniper.

'''+''':
*Быстрее в сходимости при факапах.
*Voice и video лучше использовать с rstp.
*RSTP обратносовместим с STP, причем на свитче не обязательно использовать именно RSTP.
*Поддерживается больше портов, чем в MSTP или VSTP
*Поддерживает edge ports на MX и ACX роутерах
'''-''':
*STP и RSTP ограничены одним инстансом для одного интерфейса. Используется set rstp interface для включения интерфейса в RSTP инстанс.
*Не работает с 802.1D 1998 bridges
*Не разделяет вланы. Создает spanning tree без учетов вланов и возможности постоения топологии для каждого влана. (в MSTP решена эта проблема)

====Config====
[глобально, внутри routing instance, внутри logical system]

Необходимый минимум:
*Добавляем интерфейсы [все последующие фичи применимы и к 'interface all']
set protocols rstp interface ge-0/0/0.0
или
set protocols rstp interface all

*Назначаем приоритет интерфейса для определения root port. [default priority = 128, значение должно быть кратно 16 (16,32,112 и т.п.)]
set protocols rstp interface ge-0/0/0.0 priority ''[0-240]''

*Назначаем тип интерфейса. [defaults: full-duplex = p2p mode, half-duplex = shared]
set protocols rstp interface ge-0/0/0.0 mode '''(p2p | shared)'''

*Задаем bridge-priority (switch priority). [default priority = 32 768, значение должно быть кратно 4096]
set protocols rstp bridge-priority ''[0 - 61 440]''

*Max время ожидания hello-BPDU . [defaults: 20 sec]
set protocols rstp max-age ''[6-40]''

*Интервал пересылки configuration-BPDU от root bridge. [defaults: 2 sec]
set protocols rstp hello-time ''[1-10]''

'''Опционально:'''
* Для поддержания устаревших bridge включаем чистый stp. [чтобы откатить - удаляем force-version из конфига и clear spanning-tree protocol-migration]
set protocols rstp force-version stp

* Добавление provider-bridge в rstp. [dst mac-address BPDU выставляется = 01:80:c2:00:00:08 и он не блочится RE, на которую прилетел]
set protocols rstp bpdu-destination-mac-address provider-bridge-group

* Задать extended system ID. [это ID STP|RSTP инстанса]
set protocols rstp extended-system-id ''[0 - 4095]''

* interface cost (вместо определения cost по interface speed - задаем cost вручную)
set protocols rstp interface ge-0/0/0.0 cost ''[1 - 200 000 000]''

* Настроить интерфейс как edge - не ожидает BPDU от хоста. Если прилетела BPDU, порт становится non-edge port и переводится в forwarding state. [не работает для чистого STP]
set protocols rstp interface ge-0/0/0.0 edge

* bridge port пребывает в learning и listening 15 sec, до перехода в forwarding state. Можно этот интервал изменить. [defaults: 15 sec]
set protocols rstp forward-delay ''[4-30]''
{{note|text = NSB - non stop bridging ptorotoсol синхронизирует RSTP на обоих RE, чтобы избежать перерыва сервиса при RE switchover. }}

* Включаем NSB, если на девайсе две RE [кстати, работает для STP, RSTP, MSTP]:
set chassis redundancy graceful-switchover
set system commit synchronize
set protocols layer2-control nonstop-bridging

===MSTP (Multiple STP)===
Является расширением RSTP. На одну физическую топологию накладывается несколько STP-инстансов (STI). Одна STI может состоять из одного или нескольких вланов.

В отличие от STP и RSTP, для одного влана порт будет в состоянии forwarding, для другого - blocked.

Если требуется разбалансировать нагрузку или просто часть вланов пустить по одному дереву, а остальные по-другому, то MSTP для этого подойдет лучше всего. Будет создано столько STP, сколько топологий мы хотим использовать.

Быстрая сходимость сети унаследована от RSTP.

'''MSTI''' (MST instance) - это по сути набор вланов.

'''MSTP region''' - это группка свитчей с одинаковыми MSTI. Также у свитчей одного региона должны быть одинаковыми:
*region name - задается админом - это просто зазвание
*revision level - задается админом
*mapping table

MSTP region поддерживает до 64 MSTI, каждый MSTI может содержать до 4094 vlans.

Когда мы создаем регион, MSTP автоматом создает '''internal STI (IST instance 0)''', в котором определяется Regional Root Bridge и добавляются все вланы, которые не определены в другие MSTI.

Все вланы, на свитче одного MST-региона буду по умолчанию привязаны к IST. При создании новых вланов, по дефолту тоже пойдут в IST, или в MSTI, который зададим для vlan.

IST (MST instance 0) - по умолчанию существует в каждом MSTP region.

Кроме региона, MSTP создает '''CIST: Common and Internal Spanning Tree''', которое управляет всеми MSTP регионами, а также отдельными устройствами, на которых запущен RSTP/STP [MSTP определяет их как отдельные части дерева].

CIST рассматривает MSTP регион как виртуальный bridge, несмотря на то сколько внутри региона девайсов, и позволяет коннектиться разным регионам внутри MSTP.

Благодаря CIST - в MSTP может работать с STP и RSTP.

Также есть Common Apanning Tree, который собирает IST (MSTI) и CIST вместе.

----
Ещё немного обобщив терминологию:
*IST - дерево внутри региона
*CIST - дерево между регионами
*CST - деревья внутри региона + деревья между регионами
----

О плюсах и минусах MSTP:

'''+''':
*Работает с несколькими вланами
*Поддерживает несколько инстансов для одного физ интерфейса
*Поддерживает edge ports на MX и ACX роутерах

'''-''':
*Не со всеми протоколами совместим
*Поддерживает ограниченное кол-во портов. MSTP регион поддерживает до 64 MSTIs (а в каждом инстансе 1-4094 вланов)
*MSTP больше нагружает CPU.
*Не так быстр как RSTP

====Config====
set protocols mstp interface all

Для QFX5100 и других, которые не поддерживают interface all включаем mstp для диапазона интерфейсов:

set interfaces interface-range '''all-interfaces''' member-range '''ge-0/0/0''' to '''ge-0/0/23'''
set protocols mstp interface '''all-interfaces'''

Для конкретного интерфейса:
set protocols mstp interface ge-0/0/0
set protocols mstp interface ge-0/0/0 priority ''[0-240]''
set protocols mstp interface ge-0/0/0 cost ''[1 - 200 000 000]''
set protocols mstp interface ge-0/0/0 mode ''(p2p | shared)''
set protocols mstp interface ge-0/0/0 edge
set protocols mstp interface ge-0/0/0 disable

Для протокола (аналогично RSTP):
set protocols mstp bridge-priority ''[0 - 61 440]''
set protocols mstp max-age ''[6-40]''
set protocols mstp hello-time ''[1-10]''
set protocols mstp forward-delay ''[4-30]''

MSTP-specific options:
set protocols mstp configuration-name ''region1''
set protocols mstp revision-level ''[0 - 65 535]''
set protocols mstp max-hops ''[1 - 255]'' | defaults = 19 hops 20 hops - кол-во хопов для BPDU в MSTP-регионе.
set protocols mstp msti ''[1 - 64]''
set protocols mstp msti ''[1 - 64]'' bridge-priority ''[0 - 61 440]''
set protocols mstp msti ''[1 - 64]'' vlans ''(vlan-id | vlan-id-range)''
'''msti-id''' уникальна в рамках региона. То есть в другом регионе можно использовать тот же msti-id. CIST (common instance ST) msti-id = 0.

set protocols mstp msti ''[1 - 64]'' interface ge-0/0/0.0
set protocols mstp msti ''[1 - 64]'' interface ge-0/0/0.0 priority ''[0-240]''
set protocols mstp msti ''[1 - 64]'' interface ge-0/0/0.0 cost ''[1 - 200 000 000]''
set protocols mstp msti ''[1 - 64]'' interface ge-0/0/0.0 edge

Operational commands:
show spanning-tree interface
show spanning-tree bridge

===VSTP (VLAN STP)===
Для PVST для каждого влана рассчитывается своя топология - при этом будут затрачены значительные ресурсы свитча (CPU, память) и по мере роста вланов - их будет тратиться всё больше и больше.

'''+''':
*Работает в разными вланами. Включаем VSTP внутри вланов, для которых требуется работа STP.
*VSTP и RSTP могут быть включены на свитче одновременно.
* Совместим с Cisco PVST+ и Rapid-PVST+ (но без поддержки ISL trunks)
*Можно добавить интерфейс как в global level, так и в VLAN level. Если добавить global, то VSTP будет включен во всех вланах этого интерфейса. Если будет добавлен global и VLAN level, то конфиг VLAN level будет приоритетнее и перезапишеи global level.
*Поддерживает edge ports на MX и ACX роутерах

'''-''':
*1 инстанс на один влан
*Использует ограниченное кол-во портов
*VSTP может работать максимум с 509 вланами. Однако, лучше использовать не более 190.
*Для одного влана нельзя включить и VSTP и RSTP.
*Если на свитче одновременно включаем VSTP + RSTP и на свитче более 253 вланов, то для 1-253 влана будет работаеть VSTP, для остальных RSTP.
* Не работает на SRX. Также имеет разные спецификации по кол-ву вланов для разныех моделей свитчей. Лучше смотреть на сайте juniper.

TIPS:
:- Рекомендуется включать VSTP во всех вланах.
:- При использовании: ''set protocol vstp vlan all'', '''vlan-id 1''' туда не включен, если он нужен, то добавляем отдельно: ''set protocol vstp vlan 1''
:- Максимальное кол-во вланов, используемых в VSTP - опредлеляется типов свитча и его OS.
:- Можно использовать VSTP вместе с cisco-свитчами PVST+ и Rapid-PVST+

====Config====
set protocols vstp interface all
set protocols vstp vlan all interface all
set protocols vstp vlan ''(vlan-id | vlan-id-range | vlans list)'' interface all
set protocols vstp vlan-group ''(voice-vlans)'' vlan ''(vlan-id | vlan-id-range | vlans list)'' interface all

set protocols vstp interface ge-0/0/0.0
set protocols vstp interface ge-0/0/0.0 disable
set protocols vstp vlan all interface ge-0/0/0.0
set protocols vstp vlan ''(vlan-id | vlan-id-range | vlans list)'' interface ge-0/0/0.0
set protocols vstp vlan-group ''(voice-vlans)'' vlan ''(vlan-id | vlan-id-range | vlans list)'' interface ge-0/0/0.0

Operational commands:
show spanning-tree interface
show spanning-tree bridge
show spanning-tree statistics bridge
show spanning-tree interface routing-instance ''RI-name''
show spanning-tree bridge routing-instance ''RI-name''

==Monitoring Troubleshooting ==
==Дополнительная информация==
*[[L2 switching and VLANs]]
*[[Provider bridging]]
*[[ERP (Ethernet Ring Protection)]]

L2 switching and VLANs

2021-07-15T18:13:26Z

Наталия Бобкова:

{{#description2: Основы L2. Bridging process. Зачем используем вланы. Tagging. Режимы порта. Роутинг между вланами. Информация для подготовки к экзаменам Juniper.}}
=Краткое overview=
'''Ethernet''' = shared network: sharing collision domain. '''HUB''' - тот же shared collision domain, только хосты подключены не через шину, а через хаб (тупой свитч).

'''CSMA/CD''': Хост хочет передать фрейм. Сначала он слушает: не вещает ли кто-то в домене. Начинает передавать свой фрейм, если не услышал шевелений от других. После передачи хост слушает - возникла ли коллизия. Если произошла коллизия, то хост замирает на время '''backoff delay'''. Если до начала отправки фрейма хост понимает, что кто-то тоже вещает в это время, он также замирает на '''backoff delay'''.

'''Bridge''' делит хосты на несколько collision domains. И изучает маки хостов.

'''Switch''' - каждый хост в своем порту. Каждый хост в своем collision domain. Изучает маки хостов.

Juniper switch разделяет ''Control Plane'' (routing engine [RE] = мозги, ядро свитча) и ''Forwarding Plane'' (packet forwarding engine [PFE]).

*'''Routing engine''': RPD - создает routing table и из неё forwarding table. L2-learning - создает bridging table.
*'''Packet forwarding engine''': содержит forwarding table, полученную от RE. Согласно таблице форвардит трафик.

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

Если появляется новых хост, то PFE доставляет полученный пакет RE. RE проверяет всё ли ок (firewalls, policy, mac-add limits, ...). Если ok, то обновляет bridging table и передает обновленную bridging table на PFE. Дальше пакет форвардится на egress порт или флудится во все порты (если dst mac неизвестен).

Enterprise Devices:
*SRX series - statefull firewall
*EX series - свитче, работают на ELS software
*QFX series - производительные коммутаторы, больше подходящие для DC - жирные порты, virtual chassis и т.д.

Типы портов на большинстве свитчей EX series:
*aceess [10/100/1000 Mb] RJ45 + POE - для подключение хостов
*uplink [1/10 Gb] SFP+ - для uplink или chassis cluster
*MGMT - аналог fxp на роутерах Juniper - out of band mgmt Me0
*console - RJ45 + mini-USB

=Bridging process=
Стандартные процедуры, которые происходят во время bridging:
*'''Изучение (learning).''' Изначально switch не в курсе где какие хосты включены. Как только к LAN/VLAN подключился хост и отправил пакет, свитч изучает mac-address этого хоста. Записывает с таблицу коммутации: port + mac + age (время, когда mac был изучен).
*'''Передача (Forwarding).''' Использую таблицу коммутации, свитч делает передачу фреймов между портам хостов. Если требуется передать фрейм на неизученный ранее mac-address, то запускается процесс flooding.
*'''Флуд (Flooding).''' Флуд производистя внутри LAN/VLAN. Флудится неизученный mac-address. Когда хост получит фрейм со своим адресом, он посылает в ответ ACK. Mac-addrees изучается и добавляется в таблицу коммутации.
*'''Фильтрация (Filtering).''' Трафик в рамках одного VLAN будет фильтроваться и не передаваться в другой VLAN.
*'''Устаревание (Aging).''' Каждый раз когда свитч детектит трафик от MAC, обновляется временная метка. Если трафик перестал поступать - обновляться время жизни более не будет. Когда временная метка станет больше заданного значения, запись о данном mac-address удалится из таблицы. default = 300sec.

=Зачем используем вланы=
*уменьшение кол-ва трафика и как следствие увеличение скорости передачи
*вместо сегментироавния сети посредством маршрутизации, делаем сегментирование vlan'ами
*четкая сортировка и идентефикация пакетов по доменам
*секурность - управление меньшими бродкаст-доменами
*быстрая реакция на перемещение хоста
*используя вланы, можно сгруппировать хосты, находящиеся на разных концах страны в один домен.

=Tagging=
VLAN-id диапазон: 1-4094. 0,4095 - зарезервированы под служебные нужды Junos.

Точно определить кол-во вланов, подерживаемое на железке:
set vlans ''vlan-name'' vlan-id ?

Во фрейме есть поле: TPID (tag protocol identifier).

Когда хост генерирует фрейм во влане, он заполняет поле TPID значением 0x8100, что означает - теггированный пакет.

Также во фрейме есть поле: VLAN ID, которое заполняется присвоенным уникальным 802.1Q ID.
TPID 0x8100 = tagged
TPID 0x9100 = qinq
TPID 0x88a8 = Provider Bridging and Shortest Path Bridging

По дефолту используется vlan-id 1, как нетеггированный.

Как создать и назначать влан на порт:
set vlans ''v356'' vlan-id 356
set interfaces ge-2/0/0 unit 0 family ethernet-switching vlan members ''v356''

=Interface-mode=
*'''Access.''' Принимает только untagged трафик. Дефолтное поведение чистого свитча: все порты в access default vlan (vlan-id 1 [можно при желании сменить vlan-id])

set interfaces ge-2/0/1 unit 0 family ethernet-switching interface-mode access
set interfaces ge-2/0/1 unit 0 family ethernet-switching vlan members v356

*'''Trunk.''' Принимает только tagged трафик. Можно настроить прохождение дофига vlan-id через один trunk-порт. Не пропускает untagged data-трафик. Но воспринимает untagged служебный трафик (например LACP, LLDP и прочее)

set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members [ v355 v356 ]
*'''Trunk Mode and Native VLAN.''' Принимает tagged трафик + untagged трафик того влана, который будет настроен как native. Если добавить vlan-id только как native (без добавления в vlan-members), принцип обработки будет таким:
set interfaces ge-0/0/34 native-vlan-id 391
set interfaces ge-0/0/34 unit 0 family ethernet-switching interface-mode trunk
set interfaces ge-0/0/34 unit 0 family ethernet-switching vlan members v356
{{note|text = Transmit = '''untagged 391''' (pass)
Receive = untagged 391 (pass)
Receive = tagged to 391 ('''drop''')}}

Если настроить native vlan-id + добавить этот vlan-id в trunk: когда свитч получит untagged трафик, он пометит его данным vlan-id, а также будет принимать и отправлять tagged трафик этого же vlan-id.

set interfaces ge-0/0/34 native-vlan-id 391
set interfaces ge-0/0/34 unit 0 family ethernet-switching interface-mode trunk
set interfaces ge-0/0/34 unit 0 family ethernet-switching vlan members v356
set interfaces ge-0/0/34 unit 0 family ethernet-switching vlan members v391
{{note|text = Transmit = '''tagged''' 391 (pass)
Receive = untagged 391 (pass - mapped to 391)
Receive = tagged 391 ('''pass''')}}

*'''Tagged-access mode.''' Используется для подключения серверов с виртуалками. Отсюда от access-mode взят тип подключения - host. Но по факту для если для каждой виртуалки используется свой влан, то порт должен пропускать tagged трафик. Это он и делает - это особенность от trunk-mode. Также поддерживается native vlan.

Также есть инетерсные фичи, благодаря которым равнозначеные порты, требующие одинаковых настроек можно группировать:
set interfaces interface-range Uplinks member-range ge-1/0/40 to ge-1/0/43
set interfaces interface-range Uplinks unit 0 family ethernet-switching vlan members all

=Inter-VLAN routing=
Чтобы появилась возможность коннектиться хостам из разных доменов - настраиваем Inter-VLAN routing.

По сути это просто создание l3-интерфейса внутри влана [routed VLAN interface (RVI) или IRB].

Внутри влана трафик будет бриджеваться, а между вланами - роутиться.
set interfaces irb unit 356 family inet address 10.170.19.1/24
set vlans v356 vlan-id 356 l3-interface irb.356

set interfaces ge-2/0/46 unit 0 family ethernet-switching vlan members v356
set interfaces ae0 unit 0 family ethernet-switching vlan members v356

show interfaces terse irb.356
Interface Admin Link Proto Local Remote
irb.356 up up inet 10.170.19.1/24

L3 интерфейс станет up как только vlan v356 будет назначен (trunk или access) на какой-нибудь физический интерфейс в состоянии up.

В случае с RVI будет всё тоже самое, только изменится тип интерфейса: irb.356 > vlan.356.
=Дополнительная информация=
*[[Provider bridging]]
*[[ERP (Ethernet Ring Protection)]]
*[[Spanning-Tree protocol (STP)]]

High Availability

2021-07-15T18:12:03Z

Наталия Бобкова:

{{#description2:Работы Junos без HA. Graceful restart (GR). Graceful RE switchover (GRES). Nonstop Active Routing (NSR). Bidirectional Forwarding Detection (BFD). Link Aggregation Control Protocol (LACP). Virtual Router Redundancy Protocol (VRRP). Unified in-service software upgrade (ISSU). Информация для подготовки к экзаменам Juniper.}}
= Без включенных фич High Availibility =
Когда есть 2 или более RE и падает master => PFE стартует заново и все железо и интерфейсы изучаются новым RE.

Новый RE запускает rpd, поэтому все соседствующие устройства детектят изменение топологии и заново производят вычисление кратчайших путей и активных маршрутов.

То есть без включения дополнительных фич, сходимость на сети происходит крайне медленно!

= Graceful restart (GR) =
Позволяет маршрутизатору информировать своих соседей (helper router) о предстоящей перезагрузке или перезагрузки процесса rpd.

Перезагружающийся маршрутизатор (restarting router) запрашивает у соседей определенное время на перезагрузку, после которой они заново станут соседями.

О процессе перезагрузке будет знать не вся сеть, а только непосредственные соседи (соседство по протоколам падать не будет).

Во время перерыва на control plane, трафик будет передаваться через forwarding plane.

Применимо к протоколам: OSPF, ISIS, RIP, BGP, RSVP, LDP, MSDP, PIM.

Каждому RE можно задать ip управления (interface fxp0).

Требования:

* и restarting роутер и helper роутер должны поддерживать GR (на Junos для helper роутера функция активна по умолчанию).
* роутер должен уметь передавать трафик через себя во время процесса перезагрузки (у Junos это по архитектуре есть, проблема может возникнуть только при соседстве с другими вендорами).

== Настройка ==
# show routing-options
graceful-restart { <------------------------- включается глоально
restart-duration 300; <--------------- max время, в теч которого маршрутизатор находится в GR
}

# show protocols bgp
graceful-restart {
restart-time 300;
stale-routes-time 300; <---------------- max время, в теч которого хранятся старые маршруты
}
group external {
export bgp;
neighbor 192.168.0.40 {
peer-as 200;
graceful-restart { <------------------- можно применить для более специфичного уровня иерархии
disable;

== Просмотр ==
Мониторинг только внутри протоколов:

# show protocols ospf
traceoptions {
file ospf_wtf;
flag graceful-restart;
# show log ospf_wtf
# show bgp neighbor 192.168.0.40 [Options]

= Graceful RE switchover (GRES) =
Когда включен GRES, RE синхронизируют конфигурации и обмениваются keepalive через internal link.

Если один из RE падает (не приходят keepalive 2 сек), то передача пакетов через PFE продолжается.

Graceful RE Switchover сохраняет инфо об интерфейсах, о ядре, но не инфо, содержащуюся в control plane.

Новому RE придется заново устанавливать соседства для разных протоколов и запускать rpd процесс.

Когда рухнет одна из RE, PFE разрывает связь со старым RE и устанавливает с новым, с которым обмениваются сообщениями в дальнейшем.

PFE (packet forwarding engine) не ребутается и продолжает слать трафик, основываясь на существующей forwarding table.

Чтобы сохранить работоспособность не только форвардинга, но и роутинга во время switchover, GRES должен использоваться совместно с NSR и Grasefull restart protocols extentions.

Switchover происходит в том случае, если:
*RE kernel перестает работать
*hardware failure на RE
*принудительно руками

'''Приложения, поддерживающие GRES:''' LACP, MPLS LSPs (transit only), Multicast, VPLS, DHCP relay, l2circuits, и другие...

== Настройка ==
set chassis redundancy graceful-switchover

Для синхронизации конфигов
set system commit synchronize

Только что вставленная backup RE синхронизирует свой конфиг с конфигом master RE.

Только при включенном GRES можно скопировать JunOS с master на backup RE.

== Просмотр ==
show chassis routing-engine
show system switchover || используется только на backup RE, поэтому сначала нужно перейти на backup: ''request routing-engine login backup''

==Принудительно сделать switchover==
R1> request chassis routing-engine master ?
acquire Attempt to become master Routing Engine </code>
release Request that other Routing Engine become master
switch Toggle mastership between Routing Engines

= Nonstop Active Routing (NSR) =

Используется только с кол-вом RE > 1.

Также как и graceful RE switchover, NSR хранит информацию об интерфейсах и ядре, но плюс к этому - хранит информацию о маршрутизации на backup RE =>

=> не нуждается в helper router => используется на тех сетях, где роутерами не поддерживается GR => полностью заменяет GR.

Для протоколов, которые не поддерживаются NSR, после процесса переключения на новый RE, процесс восстановления работы протоколов происходит по стандартному алгоритму.

Для работы NSR обязательно включить Graceful RE Switchover, синхронизировать конфиги.

После включения NSR, backup начинает собирать маршрутную информацию с master.

== Просмотр ==

Для переключения из master в backup

'''{master}'''
user@R1-re0> request routing-engine login other-routing-engine
--- JUNOS 10.1R1.8 built 2010-02-12 18:31:54 UTC
'''{backup}'''
user@R1-re1>

Мониторинг работы также осущ-ся для каждого протокола отдельно (для traceoptions можно задать флаг: nsr-synchronization)

= Bidirectional Forwarding Detection (BFD) =
Обнаружение падения соседства намного быстрее, чем у обычных протоколов (и статической маршуртизации) - менее секунды.

Хосты устанавливают сессию и обмениваются hello.

Если перестали приходить hello, то BFD дает знать протоколу, что пропала связность между хостами.

В настройках определяем минимальное значение для передачи и поучения hello на роутерах.
Если значения не совпадают, то BFD использует наибольшее значение (adaptive-mode).
Это поведение по умолчанию можно выключить: no-adaptation.

Значение кол-ва пропущенных hello можно менять (multiplier).

== Настройка ==

ospf {
area 0.0.0.0 {
interface fe-0/0/0.0 {
bfd-liveness-detection {
minimum-interval 300;}}

bgp {
bfd-liveness-detection {
minimum-receive-interval 300;}
group external {
export bgp;
bfd-liveness-detection {
transmit-interval {
minimum-interval 300:}}

== Просмотр ==
show bfd session

= Link Aggregation Control Protocol (LACP) =
*Автоматическое добавление и удаление отдельных линков в ae. (глобально, но не в JunOS)
*Мониторинг линка с целью проверки, что он с обоих концов включен в ae.

Когда собрана ae и включен lacp, локальная и удаленная сторона начинает обмениваться PDU, которые содержат в себе инфо о состоянии линка.
Настраивается либо active-active, либо active-passive. Одна из сторон обязательно должна отправлять PDU, то есть быть active.

==Link protection==
Link-protection: позволяет приоритезировать прохождение трафика по конкретному линку. Eggress трафик (транзитный или локально сгенерированный) будет проходить только через назначенный primary линк.

Имеет смысл при объединении от 2х линков в ae.

Если нужно задействовать большее кол-вол линков - собираем subgroups.

Мы можем добавить линки в разные subgroups, в рамках одной ae - primary и secondary. По линкам из primary subgroup будет идти трафик, пока не возникнет проблем с линком из primary subgroup. Как только, так сразу трафик перестраивается на secondary subgroup.

Трафик бегает пол инкам с высшим приоритетом. При добавлении нового линка с высшим приоритетом, или восстановления старого линка с высшим приоритетом, трафик сразу переходит на него. Чтобы избежать такого состояния, настраиваем: ''non-revertive''.

Если настраиваем link-protection, настройки у линков с обеих сторон должны быть обязательно одинаковыми!

Можно делать настройку как глобально, так и локально для конкретной ae.
===Config===
* Глобально
[edit chassis aggregated-devices ethernet]
+ lacp {
+ link-protection {
+ non-revertive;
*2 линка в ae:
[edit interfaces ge-0/0/2 gigether-options 802.3ad]
+ lacp {
+ port-priority 33333;
[edit interfaces ae0 aggregated-ether-options lacp]
+ link-protection {
+ non-revertive;
*>2 линков в ae:
[edit interfaces ae0 aggregated-ether-options]
+ link-protection-sub-group
+ subgroup-primary primary
+ subgroup-backup backup
[edit interfaces ge-0/0/2 ether-options 802.3ad]
+ link-protection-sub-group group-name
[edit interfaces ge-0/0/3 ether-options 802.3ad]
+ link-protection-sub-group group-name
[edit interfaces ge-0/0/4 ether-options 802.3ad]
+ link-protection-sub-group group-name
и включаем link-protection на каком-нибудь уровне: LAG/LACP/AE.
[edit interfaces ae0 aggregated-ether-options lacp]
+ link-protection

==Link-speed==
Когда указываем в настройках ae link-speed, все линки, входящие в ae должны соответствовать этой настройке.

Начиная с 14.2 версии, можно объединять в ae линки разных скоростей:

[edit interfaces ae33]
+ aggregated-ether-options {
+ link-speed mixed;

Минимальное кол-во линков можно задавать, но по дефолту хотя бы один линк соберется в ae.
[edit interfaces ae0 aggregated-ether-options]
+ minimum-links 4;

Если число линков указываем, то ae0 соберется, только если как минимум это число линков будет у статусе ''collecting distributing''.

= Virtual Router Redundancy Protocol (VRRP) =
Особенности роутеров:

*'''Master''' - выполняет ф-ию
*'''Backup''' - их может быть несколько

Для обмена информацией между собой (о приоритете и состоянии мастера) роутеры запихивают обновления в ip-пакеты и шлют на ip 224.0.0.18 раз в 1 сек (по умолчанию).

Можно задать другой интервал для обмена обновлений (1-255). Или с помощью fast-interval (100–999 milliseconds). TTL = 255

Мак-адрес для virtual-router: 00-00-5E-00-01-VRID [virt router ID]

Приоритет по умолчанию: 100

Выигрывает: '''больший приоритет'''

Сотосяния:
*Initialization - выборы мастера
*Master - мастер отправляет остальным не master роутерам сообщения о своем состоянии
*Backup - backup роутер мониторит состояние master роутера
*Transit - короткий момент, когда master сдох, а backup еще не стал master'ом.

== Настройка ==
> show configuration interfaces ae5.398
vlan-id 398;
family inet
address 77.94.165.185/29 {
vrrp-group 1 { <---------------------------------------------- в рамках одного маршрутизатора не должно существовать несколько групп с одинаковым ID
virtual-address 77.94.165.187;
priority 10; <----------------------------------------------- приоритет
advertise-interval 10; <----------------------------------- интервал отправки сообщений внутри группы
accept-data; <------------------------------------------- позволяет отвечать на icmp-пакеты
authentication-type md5; <------------------------------ md5, simple pass, none
authentication-key "$9$"; ## SECRET-DATA
no-preempt; <-------------------------------------------- backup не перехватывает роль master (In situations where the VIP address is not owned by any of the participating
VRRP routers within a specific VRRP group)

'''preempt/no-preempt''' - если падал vrrp интерфейс с большим приоритетом, и потом вернулся в работу - может выставить параметр не переключать master обратно на него. Либо интерфейс может себе вернуть роль мастера по истечению hold-timer. На практике сработал только когда интерфейс физически падал.

'''vrrp-inheret-from''' - создан для удобства создания интерфейсов в одинаковыми параметрами. Все настройки интерфейса, который указан в качестве vrrp-inheret-from - наследуются.

== Просмотр ==
show vrrp summary
Interface State Group VR state VR Mode Type Address
ae5.398 up 1 backup Active lcl 77.94.165.185
vip 77.94.165.187
==Track interface/route==
У vrrp есть возможность следить за состоянием маршрута или интерфейса, или за кол-вом трафика на интерфейсе. И в зависимости от состояния - уменьшать приоритет. По сути пригодно, когде vrrp сделан на PE-роутер и через этот vrrp работает клиент. В таком случае, например, при "потере" uplink линков, роутер перестал быть master, и клиент слал бы трафик на другой роутер.

> show configuration interfaces ge-0/0/4
unit 300 {
family inet {
address 172.30.1.2/24 {
vrrp-group 101 {
track {
interface ge-0/0/2.204 {
priority-cost 10;
interface ge-0/0/3.228 {
priority-cost 10;

= Unified in-service software upgrade (ISSU) =

Позволяет обновиться без перерыва на control plane и с минимальным перерывом на forwarding plane.

Обязательно должно быть 2 RE.

Должны быть включены: GRES, NSR.

На обоих RE должны быть одинаковые версии прошивки.
=Дополнительная информация=
*[[Static, Aggregate, Generate route]]
*[[OSPF]]
*[[BGP]]
*[[IS-IS]]