Сигнализация/Распространение MPLS меток с помощью LDP (Label Distribution Protocol) и RSVP TE (Resource ReSerVation Protocol – Traffic Engineering)
LDP
Рассмотрим работу LDP. Ниже часть взята прямиком из статьи linkmeup
1. После включения LDP LSR делает мультикастовую рассылку UDP-дейтаграмм во все интерфейсы на адрес 224.0.0.2 и порт 646, где активирован LDP — так происходит поиск соседей.
TTL таких пакетов равен 1, поскольку LDP-соседство устанавливается между непосредственно подключенными узлами.
Такие сообщения называются Hello.
Вообще говоря, это не всегда так — LDP сессия может устанавливаться для определённых целей и с удалённым узлом, тогда это называется tLDP — Targeted LDP.2. Когда соседи обнаружены, устанавливается TCP соединение с ними, тоже по порту 646 — Initialization. Дальнейшие сообщения (кроме Hello) передаются уже с TTL равным 255.
3. Теперь LSR периодически обмениваются сообщениями Keepalive адресно по TCP и по-прежнему не оставляют попыток найти соседей с помощью Hello.
4. В какой-то момент один из LSR обнаруживает в себе вторую личность — Egress LSR — то есть он является выходным для какого-то FEC. Это факт, о котором нужно сообщить миру.
В зависимости от режима он ждёт запроса на метку для данного FEC, либо рассылает его сразу же.
Далее будем работать со следующей топологией (рассмотрим LDP внутри красного треугольника):
Включим LDP между B-ASBR1 и B-P2 и посмотрим процесс.
RP/0/0/CPU0:B-ASBR1#show conf com ch last 1 dif
Mon Mar 14 18:59:51.991 UTC
Building configuration...
!! IOS XR Configuration 6.1.3
# mpls ldp
+ interface GigabitEthernet0/0/0/1
+ !
+ !
end
RP/0/0/CPU0:B-P2#show conf com ch last 1 dif
Mon Mar 14 18:59:46.442 UTC
Building configuration...
!! IOS XR Configuration 6.1.3
# mpls ldp
+ interface GigabitEthernet0/0/0/2
+ !
+ !
end
В дампе видим, что после включения LDP на интерфейсах идет рассылка Hello Message, это UDP с source адресом интерфейса и destination мультикаст адреса 224.0.0.2 (он для всех одинаков). Destination и Source UDP порт одинаков – 646. Как мы помним все hello message пакеты с TTL = 1.
После двухстороннего обмена Hello Message, идет TCP Handshake и последующая установка LDP сессии (последовательно по нумерации из дампа):
1. B-P2 отправляет SYN сторону B-ASBR1. В качестве src и dst адресов уже используются lookback адреса. Source порт уже “динамический”, а вот Destination порт будет 646, но уже TCP а не UDP, как при Hello Message.
2. B-ASBR1 получает сегмент (segment – pdu (protocol data unit) layer 4) и отвечает таким же SYN и ACK, при этом в сегменте в поле «номер подтверждения» (acknowledgement number) будет увеличен на 1. В примере SYN содержал значение acknowledgement number – 0, а ответный SYN+ACK уже был = 1.
3. B-P2 получает SYN+ACK и отправляет ACK, подтверждая получения от него SYN+ACK.
TCP установилось – established.
4. – 6. Далее идет обмен “initialization message” с подтверждением пакетами KeepAlive.
Заострю внимание на обмене init сообщениями.
Кусок древа “Parameters” из “Initialization Message“:
Common Session Parameters
00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x0)
TLV Type: Common Session Parameters (0x500)
TLV Length: 14
Parameters
Session Protocol Version: 1
Session KeepAlive Time: 180
0... .... = Session Label Advertisement Discipline: Downstream Unsolicited proposed
.0.. .... = Session Loop Detection: Loop Detection Disabled
Session Path Vector Limit: 0
Session Max PDU Length: 0
Session Receiver LSR Identifier: 11.11.11.11
Session Receiver Label Space Identifier: 0
Часть описания содержимого init взял отсюда.
Данное сообщение (init) содержит
- Версию протокола (
Protocol Version) - Таймер KeepAlive (
KeepAlive Time) - Тип распространения метки (
Label Advertisement Discipline) / A-bit - Механизм предотвращения циклов (
Loop Detection) - Переменная используется для работы механизма предотвращения циклов (
Path Vector Limit) - Максимальная длина PDU сообщений – Max PDU Length – означает максимально возможную длину совмещенных сообщений LDP в байтах. Соседи могут предлагать различные значения, но оба должны выбрать минимальное.
- Идентификатор LSR получателя –
Receiver LSR Identifier– идентификатор LSR, который должен быть уникальным в рамках одного MPLS домена и един (один единственный) для каждого LSR. - “Идентификатор пространства меток” –
Receiver Label Space Identifier– “Label_Space_ID – это идентификатор множества меток. Label Space Identifier указывается в заголовке PDU, идентифицируя тем самым соседа и интерфейс по которому установлено соседство. Например, два LSR-а могут быть соединены двумя каналами, и для каждого канала должен быть выделен разные Label Space Identifier, отличаться которые будут только значением Label_Space_ID.”
LDP сессия устанавливается при выполнении следующих условий:
- Версии протокола должны совпадать. Хотя как подсказывают, что в RFC прямым тестом это не говорится;
- Значений А-бит должно совпадать, в сети на разных соединениях возможно использование различных режимов распространения информации о метках, но на одном соединение режим должен совпадать
Вернёмся к разбору установки LDP сессии.
7. – 8. Идет обмен Address Message, в котором хранятся все ip адреса этого роутера (на интерфейсе) и Label Mapping Message, в котором хранится выделенные метки для каждого FEC.
9. Подтверждение на получение предыдущего сообщения.
Стоит упомянуть, что Address Message информирует пиров о наличии локальных адресов (т.е. ip адреса навешанные непосредственно на интерфейсе этого роутера).
Address Withdraw - это сообщение уже уведомляет соседей об "исчезновении" непосредственно подключенных адресов (падении интерфейса и т.д.)На рисунках ниже, пример Address Message и Label Mapping Message.
Тут у нас часть дампа (пункт 7 выше) от B-ASBR1 в сторону B-P2.
ASBR1 перечисляет свои, непосредственно навешанные на интерфейс, ip адреса.
RP/0/0/CPU0:B-ASBR1#show route local
Mon Mar 14 22:23:25.374 UTC
L 11.11.11.11/32 is directly connected, 04:48:53, Loopback0
L 100.200.1.200/32 is directly connected, 04:48:52, GigabitEthernet0/0/0/2
L 200.2.1.1/32 is directly connected, 04:48:52, GigabitEthernet0/0/0/1Вторая часть того же дампа (п. 7), в которой уже видны Label Mapping Message – перечисление FEC (префиксов) и сгенерированной для них метки:
Для примера выбрал несколько FEC‘ов для демонстрации.
Из примеров видим, что для FEC 11.11.11.11/32 (т.е. собственного лупбека) он выделил ImpNull т.е. метка 3 и сообщил об этом соседям LDP (т.е. непосредственно одному B-P2). Для FEC 44.44.44.44/32 он выделил метку 24004.
Проверим это непосредственно с самого B-ASBR1, посмотрев в LFIB. Cмотрим на Local binding, нам же нужно узнать какую метку он выделил, верно?
RP/0/0/CPU0:B-ASBR1#show mpls ldp bindings 11.11.11.11/32
Mon Mar 14 23:03:50.068 UTC
11.11.11.11/32, rev 8
Local binding: label: ImpNull <<< Та же метка 3
Remote bindings: (1 peers)
Peer Label
----------------- ---------
22.22.22.22:0 24001
RP/0/0/CPU0:B-ASBR1#show mpls ldp bindings 44.44.44.44/32
Mon Mar 14 23:04:11.237 UTC
44.44.44.44/32, rev 16
Local binding: label: 24004 <<< Метка для данного FEC
Remote bindings: (1 peers)
Peer Label
----------------- ---------
22.22.22.22:0 24000 Пример Address Message и Address Withdraw
Address Message:
Подняв интерфейс между B-ASBR1 и B-ASBR5 и навесив ip адрес
1. B-ASBR1 сразу же отправляет LDP Address Message соседям (в примере это в сторону B-P2) с содержимым ip адреса, настроенного непосредственно на интерфейсе
Label Distribution Protocol
Version: 1
PDU Length: 24
LSR ID: 11.11.11.11
Label Space ID: 0
Address Message
0... .... = U bit: Unknown bit not set
Message Type: Address Message (0x300)
Message Length: 14
Message ID: 0x00000053
Address List
00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x0)
TLV Type: Address List (0x101)
TLV Length: 6
Address Family: IPv4 (1)
Addresses
Address 1: 200.5.1.1
2. B-P2 сразу же в ответ отправляет ACK, подтверждая что Address Message получил.
3. Следом B-ASBR1 отправляет Label Mapping Message, уведомляя что выделил метку для этого FEC
Label Mapping Message
0... .... = U bit: Unknown bit not set
Message Type: Label Mapping Message (0x400)
Message Length: 23
Message ID: 0x00000055
FEC
00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x0)
TLV Type: FEC (0x100)
TLV Length: 7
FEC Elements
FEC Element 1
FEC Element Type: Prefix FEC (2)
FEC Element Address Type: IPv4 (1)
FEC Element Length: 24
Prefix: 200.5.1.0 <<< FEC
Generic Label
00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x0)
TLV Type: Generic Label (0x200)
TLV Length: 4
.... .... .... 0000 0000 0000 0000 0011 = Generic Label: 0x00003 <<< ImpNull
4. B-P2 подтверждает получение Label Mapping Message, путём TCP с флагом ACK
Пример из wireshark’а ниже
Address Withdraw:
В данном примере у нас на B-ASBR1 падает интерфейс в сторону B-ASBR5
1. B-ASBR1 отправляет Address Withdrawal Message, в котором указан ip адрес B-ASBR1, который был на упавшем интерфейсе.
2. B-P2 подтверждает получение Address Withdrawal Message, путем отправки ACK
3. B-ASBR1 отзывает выделенную им ранее метку для FEC 200.5.1.2 (ip на стороне B-ASBR5 *была статика на ASBR1*) – Label Withdrawal Message
4.