fantas1st0 Nov 22 2020 at 14:05

Внедрение Multicast VPN на Cisco IOS (часть 2 — mLDP)

9 min

3.5K

В прошлой статье мы познакомились с Вами с исторически первым способом организации построения multicast VPN с помощью технологий PIM и mGRE (Часть 1, Profile 0).

На сегодняшний день существуют альтернативы запуску P-PIM в опорной сети. В частности, для организации многоадресных деревьев можно использовать протокол mLDP. Разберемся как он работает. Но прежде вспомним основные концепции LDP.

LDP пиры находят друг друга посредством рассылки Hello сообщений на адрес 224.0.0.2. В рамках Hello передается параметр “transport address” (который, по-умолчанию в Cisco IOS совпадает с IP адресом LDP router-id)
Маршрутизаторы устанавливают ТСР сессию и в рамках неё обмениваются метками для FEC (читай — IP префиксов из таблицы маршрутизации)
Результат обмена — однонаправленный LSP типа Point-to-Point.

Помимо этого, пиры в рамках ТСР сессии обмениваются сообщениями типа Initialization, внутри которых передается информация о поддерживаемых возможностях (Capabilities). За обмен информацией отвечают Capabilities TLV.
- Т.е. обмениваться можно не только информацией об P2P LSP, но и ещё чем-то ...

Вся соль mLDP в том, что для этого протокола FEC представляет собой не какой-то один конкретный префикс, а скорее некую комбинацию из четырёх элементов:

Тип дерева
Адресное семейство (IPv4/IPv6)
IP адрес корневого устройства
Корневое устройство — заранее определенный коммутатор, в котором начинается mLDP LSP
Некое дополнительно значение, в оригиналье именуемое «Opaque Value».
- Используется для обозначения конкретного дерева (читай C-VRF) внутри MPLS инфраструктуры.

Всего для mLDP определено три различных FEC:

P2MP FEC (тип дерева = 0x06)
MP2MP Upstream FEC (тип дерева = 0x07)
MP2MP Downstream FEC (тип дерева = 0x08)

Дерево P2MP характеризуется тем, что только одно устройство (корневое) может передавать трафик. Все остальные участники дерева используются для передачи трафика в сторону заинтересованных получателей. Т.е. Дерево является однонаправленным. LSP типа P2MP визуально можно представить себе следующим образом:

Дерево MP2MP характеризуется тем, что любой заинтересованный маршрутизатор может передавать трафик (равно, как и получать его). При этом трафик всегда бежит в одном из двух направлений: либо по направлению к корневому устройству, либо от него. LSP типа MP2MP визуально можно представить себе следующим образом:

Теперь попробуем разобраться с тем, как именно строится MP2MP LSP в mLDP (P2MP нам будет интересен в следующих статьях цикла).

Построение MP2MP LSP

Точно также как в обычном unicast LSP, направление сигнализации (распространение меток) противоположно направлению следованию трафика.

Весь процесс сигнализации можно разделить на два этапа (очень похожих на процесс построения многоадресного дерева в PIM ASM через точку рандеву):

Downstream сигнализация
- РЕ распространяют метки в сторону корневого маршрутизатора
- Согласно распространённым меткам, корневой маршрутизатор передаёт трафик в сторону РЕ
Upstream сигнализация
- Корневой маршрутизатор распространяет метки в сторону РЕ
- Согласно распространённым меткам, РЕ передаёт трафик в сторону корневого маршрутизатора

Как видно, корневой маршрутизатор является центральной точки сети, через который проходит как Downstream, так и Upstream трафик. Технически им может быть любое устройство сети (как Р, так и РЕ). При этом (насколько мне известно) не существует какого-либо динамического протокола выбора корневого маршрутизатора, поэтому требуется ручная конфигурация на всех РЕ (и только на них).

Рассмотрим вариант замены ранее рассмотренного метода построения Default MDT через BGP ipv4 MDT на mLDP на следующей топологии:

В качестве корневого маршрутизатора будем использовать R8.

Проведем базовую преднастройку (подразумевается, что сделаны все настройки из 1-ой части статьи):

Отключим на всех маршрутизаторах протокол PIM:
```
interface Gi2.X
no ip pim sparse-mode
<br>
```
адресное семейство BGP MDT (на РЕ):
```
router bgp 65001
no address-family ipv4 mdt
```
и адрес рассылки MDT
```
ip vrf C-ONE
no mdt default 239.1.1.1
```

Для полной настройки FEC нам остается ввести IP адрес корневого маршрутизатора и Opaque Value. Начнём с РЕ1:

PE1(config)#mpls mldp logging notifications
PE1(config)#!
PE1(config)#ip vrf C-ONE
PE1(config-vrf)# vpn id 65001:1
PE1(config-vrf)# mdt default mpls mldp 8.8.8.8
PE1(config-vrf)#
*Nov 21 22:41:03.703: %MLDP-5-ADD_BRANCH: [mdt 65001:1 0] Root: 8.8.8.8, Add MP2MP branch MDT(Lspvif0) remote label , local label no_label
*Nov 21 22:41:03.742: MLDP: Reevaluating peers for nhop: 10.1.5.5
PE1(config-vrf)#
*Nov 21 22:41:04.647: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up
PE1(config-vrf)#
*Nov 21 22:41:05.840: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Lspvif0
PE1(config-vrf)#

PE1 создаёт новый интерфейс Lspvif0 (LSP virtual interface, ничто иное как новый PMSI) для MDT с Opaque Value = [65001:1 0] и запускает на нём PIM в рамках C-VRF.

Прим. Opaque Value состоит из двух частей: vpn id и некоторого дополнительного индекса. Если индекс равен нулю, то это указание на использование Default MDT.

Проверим некоторые параметры вновь созданного интерфейса:

PE1#show ip interface Lspvif0
Lspvif0 is up, line protocol is up
  Interface is unnumbered. Using address of Loopback0 (1.1.1.1)
  Multicast reserved groups joined: 224.0.0.1 224.0.0.2 224.0.0.22 224.0.0.13
  VPN Routing/Forwarding "C-ONE"

PE1#show ip pim vrf C-ONE interface 

Address          Interface                Ver/   Nbr    Query  DR         DR
                                          Mode   Count  Intvl  Prior
172.1.11.1       GigabitEthernet2.111     v2/S   1      30     1          172.1.11.11
172.1.15.1       GigabitEthernet2.115     v2/S   1      30     1          172.1.15.15
1.1.1.1          Lspvif0                  v2/S   0      30     1          1.1.1.1

Посмотрим базу данных по меткам:

PE1#show mpls mldp neighbors 

 MLDP peer ID    : 5.5.5.5:0, uptime 2w0d Up, 
  Target Adj     : No
  Session hndl   : 1
  Upstream count : 1
  Branch count   : 0
  Path count     : 1
  Path(s)        : 10.1.5.5          LDP GigabitEthernet2.15
  Nhop count     : 1
  Nhop list      : 10.1.5.5

PE1#show mpls mldp database 
  * For interface indicates MLDP recursive forwarding is enabled
  * For RPF-ID indicates wildcard value
  > Indicates it is a Primary MLDP MDT Branch

LSM ID : 5 (RNR LSM ID: 6)   Type: MP2MP   Uptime : 00:07:53
  FEC Root           : 8.8.8.8 
  Opaque decoded     : [mdt 65001:1 0] 
  Opaque length      : 11 bytes
  Opaque value       : 02 000B 0650010000000100000000
  RNR active LSP     : (this entry)
  Upstream client(s) :
    5.5.5.5:0    [Active]
      Expires        : Never         Path Set ID  : 6
      Out Label (U)  : 1013          Interface    : GigabitEthernet2.15*
      Local Label (D): 10017         Next Hop     : 10.1.5.5
  Replication client(s): 
>   MDT  (VRF C-ONE)
      Uptime         : 00:07:53      Path Set ID  : 7
      Interface      : Lspvif0       RPF-ID       : *

На РЕ1 присутствует Upstream сосед, которому была передана метка 10017. Трафик, который будет передавать от РЕ1 в сторону R8 получит метку 1013 от Р1.

На Р1 соседей гораздо больше (согласно топологии — шестеро):

P1#show mpls mldp neighbors 

 MLDP peer ID    : 4.4.4.4:0, uptime 2w0d Up, 
  Target Adj     : No
  Session hndl   : 1
  Upstream count : 0
  Branch count   : 0
  Path count     : 1
  Path(s)        : 10.4.5.4          LDP GigabitEthernet2.45
  Nhop count     : 0

 MLDP peer ID    : 1.1.1.1:0, uptime 2w0d Up, 
  Target Adj     : No
  Session hndl   : 2
  Upstream count : 0
  Branch count   : 1
  Path count     : 1
  Path(s)        : 10.1.5.1          LDP GigabitEthernet2.15
  Nhop count     : 0

 MLDP peer ID    : 8.8.8.8:0, uptime 2w0d Up, 
  Target Adj     : No
  Session hndl   : 3
  Upstream count : 1
  Branch count   : 0
  Path count     : 1
  Path(s)        : 10.5.8.8          LDP GigabitEthernet2.58
  Nhop count     : 1
  Nhop list      : 10.5.8.8 

 MLDP peer ID    : 6.6.6.6:0, uptime 2w0d Up, 
  Target Adj     : No
  Session hndl   : 4
  Upstream count : 0
  Branch count   : 0
  Path count     : 1
  Path(s)        : 10.5.6.6          LDP GigabitEthernet2.56
  Nhop count     : 0

 MLDP peer ID    : 7.7.7.7:0, uptime 2w0d Up, 
  Target Adj     : No
  Session hndl   : 5
  Upstream count : 0
  Branch count   : 0
  Path count     : 1
  Path(s)        : 10.5.7.7          LDP GigabitEthernet2.57
  Nhop count     : 0

 MLDP peer ID    : 9.9.9.9:0, uptime 1w5d Up, 
  Target Adj     : No
  Session hndl   : 6
  Upstream count : 0
  Branch count   : 0
  Path count     : 1
  Path(s)        : 10.5.9.9          LDP GigabitEthernet2.59
  Nhop count     : 0

P1#show mpls mldp database 
  * For interface indicates MLDP recursive forwarding is enabled
  * For RPF-ID indicates wildcard value
  > Indicates it is a Primary MLDP MDT Branch

LSM ID : 3   Type: MP2MP   Uptime : 00:13:23
  FEC Root           : 8.8.8.8 
  Opaque decoded     : [mdt 65001:1 0] 
  Opaque length      : 11 bytes
  Opaque value       : 02 000B 0650010000000100000000
  Upstream client(s) :
    8.8.8.8:0    [Active]
      Expires        : Never         Path Set ID  : 9
      Out Label (U)  : 8017          Interface    : GigabitEthernet2.58*
      Local Label (D): 1014          Next Hop     : 10.5.8.8
  Replication client(s): 
    1.1.1.1:0 
      Uptime         : 00:13:23      Path Set ID  : A
      Out label (D)  : 10017         Interface    : GigabitEthernet2.15*
      Local label (U): 1013          Next Hop     : 10.1.5.1

Обратите внимание на тот факт, что на Р1 C-VRF не настроен, однако маршрутизатор понимает MP2MP дерево согласно по-умолчанию включённому функционалу recursive fec.

На Р1 есть один Upstream сосед (тот, через которого можно добраться на корня дерева) и один Downstream сосед. Для передачи данных в сторону РЕ1, как и ожидалось, используется метка 10017. При получении mLDP метки 10017, Р1 генерирует метку 1014 и отправляет её в сторону Upstream соседа.

Здесь можно сформулировать правило: каждый раз, когда маршрутизатор получает Downstream MP2MP метку, он реагирует созданием Upstream MP2MP метки и отправлением её в сторону Upstream соседа.

Таким образом на текущий момент организуется дерево от РЕ до ROOT.

В ответ на получение метки 1014, ROOT генерирует метку 8017 которая для Р1 будет являться Upstream меткой. В ответ на получение 8017, Р1 генерирует Downstream метку 1013 и отправляет её в сторону PE1.

Добавим настройку на РЕ4:

PE4(config-subif)#ip vrf C-ONE
PE4(config-vrf)# vpn id 65001:1
PE4(config-vrf)# mdt default mpls mldp 8.8.8.8

*Nov 21 23:25:03.638: %PIM-5-NBRCHG: VRF C-ONE: neighbor 1.1.1.1 UP on interface Lspvif0

Обратите внимание, что mLDP метки на R8 (ROOT) никоим образом не меняются при появлении нового устройства. Это происходит из-за того, что Р1 не создаёт новую метку при получении сигнализации от РЕ4 в силу того, что сообщаемая метка от РЕ4 принадлежит тому же FEC, что полученная ранее от PE1.

Однако на Р1 появляются новые метки (и это ожидаемо, т.к. РЕ4 произвёл дополнительную сигнализацию):

P1#show mpls mldp database             
  * For interface indicates MLDP recursive forwarding is enabled
  * For RPF-ID indicates wildcard value
  > Indicates it is a Primary MLDP MDT Branch

LSM ID : 3   Type: MP2MP   Uptime : 00:46:10
  FEC Root           : 8.8.8.8 
  Opaque decoded     : [mdt 65001:1 0] 
  Opaque length      : 11 bytes
  Opaque value       : 02 000B 0650010000000100000000
  Upstream client(s) :
    8.8.8.8:0    [Active]
      Expires        : Never         Path Set ID  : 9
      Out Label (U)  : 8017          Interface    : GigabitEthernet2.58*
      Local Label (D): 1014          Next Hop     : 10.5.8.8
  Replication client(s): 
    1.1.1.1:0 
      Uptime         : 00:46:10      Path Set ID  : A
      Out label (D)  : 10017         Interface    : GigabitEthernet2.15*
      Local label (U): 1013          Next Hop     : 10.1.5.1
    4.4.4.4:0 
      Uptime         : 00:02:11      Path Set ID  : B
      Out label (D)  : 40017         Interface    : GigabitEthernet2.45*
      Local label (U): 1012          Next Hop     : 10.4.5.4

Стоит создать дополнительный VRF C-TWO на РЕ4, как сигнализируется дополнительное дерево с новыми метками.

PE4(config)#ip vrf C-TWO
PE4(config-vrf)# rd 4.4.4.4:2
PE4(config-vrf)# vpn id 65001:2
PE4(config-vrf)# mdt default mpls mldp 8.8.8.8
PE4(config-vrf)# route-target export 65001:2
PE4(config-vrf)# route-target import 65001:2

RR#show mpls mldp database 
  * For interface indicates MLDP recursive forwarding is enabled
  * For RPF-ID indicates wildcard value
  > Indicates it is a Primary MLDP MDT Branch

LSM ID : 1   Type: MP2MP   Uptime : 00:54:07
  FEC Root           : 8.8.8.8 (we are the root)
  Opaque decoded     : [mdt 65001:1 0] 
  Opaque length      : 11 bytes
  Opaque value       : 02 000B 0650010000000100000000
  Upstream client(s) :
    None
      Expires        : N/A           Path Set ID  : 1
  Replication client(s): 
    5.5.5.5:0 
      Uptime         : 00:54:06      Path Set ID  : 2
      Out label (D)  : 1014          Interface    : GigabitEthernet2.58*
      Local label (U): 8017          Next Hop     : 10.5.8.5

LSM ID : 2   Type: MP2MP   Uptime : 00:00:48
  FEC Root           : 8.8.8.8 (we are the root)
  Opaque decoded     : [mdt 65001:2 0] 
  Opaque length      : 11 bytes
  Opaque value       : 02 000B 0650010000000200000000
  Upstream client(s) :
    None
      Expires        : N/A           Path Set ID  : 3
  Replication client(s): 
    5.5.5.5:0 
      Uptime         : 00:00:48      Path Set ID  : 4
      Out label (D)  : 1019          Interface    : GigabitEthernet2.58*
      Local label (U): 8018          Next Hop     : 10.5.8.5

Проверим связность между сайтами, находящимися за РЕ1 и РЕ4.

CE1#ping 230.0.0.1 source Lo0
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 230.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11 

Reply to request 0 from 14.14.14.14, 15 ms

Связность есть, что хорошо. Однако, давайте задумаемся над одним вопросом — по каком пути ходит трафик? Доходит ли он до корневого маршрутизатора и потом возвращается обратно (так называемый U-turn) или же P1 может передавать пакеты напрямую в сторону РЕ4?

Чтобы ответить на этот вопрос, проанализируем таблицу меток на Р1 и ROOT и дополнительное воспользуемся Wireshark.

Мы уже знаем, что для передачи многоадресного трафика РЕ1 будет использовать метку 1013 (см пояснения выше) (для интерфейса 802.1Q vlan id = 15). Это подтверждается дампом трафика.

Что делает Р1 при получении данной метки?

P1#show mpls forwarding-table labels 1013
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
1013       8017       [mdt 65001:1 0]  198024        Gi2.58     10.5.8.8    
           40017      [mdt 65001:1 0]  184856        Gi2.45     10.4.5.4

На что здесь необходимо обратить пристальное внимание. P1 знает об этой метке, т.к он сам её сгенерировал (смотри вывод show mpls mldp database ранее). Ранее мы с Вами говорили о том, что РЕ передаёт пакет в сторону ROOT, а уже ROOT должен вернуть пакет обратно на заинтересованные РЕ. Однако в данном примере видно, что при получении пакета на Р1, он «раздваивается» и отправляется в сторону РЕ4 и ROOT. Т.е U-turn не происходит из-за того, что Р1 видит

Downstream сигнализацию от РЕ4
Upstream передачу данных от РЕ1

В результате Р1 коммутирует MPLS пакеты напрямую, отправляя на ROOT «копию» трафика.

На ROOT на текущий момент пакет должен быть уничтожен:

RR#show mpls forwarding-table | i 8017
8017       No Label   [mdt 65001:1 0]  0

Активируем VRF на всех остальных РЕ. В результате можем ожидать создания интерфейсов типа Lspvif на каждом РЕ устройстве и установление PIM соседства между ними.

PE1#show ip pim vrf C-ONE neighbor | i Lsp
3.3.3.3           Lspvif0                  00:01:02/00:01:41 v2    1 / S P G
2.2.2.2           Lspvif0                  00:01:09/00:01:40 v2    1 / S P G
4.4.4.4           Lspvif0                  10:49:57/00:01:40 v2    1 / DR S P G

Дополнительно, проверим таблицу коммутации на ROOT и убедимся, что теперь для метки 8017 (которая была получена от Р1) есть собственная локальная метка.

RR#show mpls forwarding-table | i 8017
8017       2013       [mdt 65001:1 0]  982           Gi2.68     10.6.8.6

Рассмотренный выше вариант реализации multicast VPN известен под кодовым именем «Profile 1». Его основные характеристики:

Нет необходимости в P-PIM для опорной сети
В качестве PMSTI используется интерфейс Lspvif
Нет необходимости в специализированном адресном семействе BGP
Для передачи трафика используется Default MDT
Построение Default MDT осуществляется с помощью протокола mLDP.
- Проблема с тем, что многоадресный трафик коммутируется в сторону всех РЕ (в рамках VPN) также присутствует, как и в Profile 0.
В качестве протокола многоадресной маршрутизации внутри C-VRF на опорной сети используется протокол PIM (автоматически активируется на интерфейсе Lspvif)

Продолжение следует...

Tags:

Hubs: