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

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).

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

RSVP auto-mesh

Когда на сети используется RSVP, но для конкретных функций (L3VPN, VPLS, ...) требуется full-mesh, то чтобы не прописывать все LSP руками, можно использовать RSVP-full-mesh.

Строится, когда:

• От PE пришел iBGP пакет
• 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

Configuration

1. Включаем family mpls на интерфейсах, смотрящих в ядро. Эта настройка позволяет отправлять и получать пакеты с метками.

[edit interfaces]
   set ge-0/0/2.0 family mpls
   set ge-0/0/3.0 family mpls

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

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

3. Добавляем в протокол RSVP нужные интерфейсы.

[edit protocols rsvp]
	set interface ge-0/0/2.0
	set interface ge-0/0/3.0

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

LDP

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

Соседство

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

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

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

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

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

В итоге - full mesh на сети. На всех роутерах в inet.3 будет Lo роутера А.

Установление LDP LSP нельзя контролировать, они следуют кратчайшему пути по IGP.

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

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

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

Cisco

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

Чтобы на Juniper получить такое же поведение:

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

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

Configuration

1. Включаем family mpls:

[edit interfaces]
set ge-0/0/2.0 family mpls
set ge-0/0/3.0 family mpls

2. Добавляем интерфейсы в protocols ldp

[edit protocols ldp]
	set interface ge-0/0/2.0
	set interface ge-0/0/3.0

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

Можно проверить что будет происходить с меткой на каждом хопе LDP LSP:

show route protocol ldp 10.200.86.7
show ldp router
show route table inet.3  - если нет Lo нужного нам роутера, то проверяем есть ли Lo в inet.0 (IGP)

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

LDP tunneling

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

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

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

Можно использовать, когда не все устройства в сети поддерживают RSVP, но на ядре требуется TE. Также TE как таковой не требуется вообще на PE, нужно только на ядре, на P роутерах. Поэтому RSVP можно запустить только на ядре, а PE будут подцепляться по LDP.