LDP

Схема сети остаётся прежней. Перед настройкой LDP удалим все настройки статического LSP и включим на всех интерфейсах обработку меток (кроме интерфейсов в сторону eBGP-пиров).

LDP позволяет распространить метки и направлять трафик по меткам, согласно IGP Best Path. Однако, в LDP недоступен TE. В то же время LDP легко настраивается и сравнительно быстро перестраивается вместе с IGP-протоколами при изменениях в топологии. Используется для построения VPN-сервисов и формирования более простых iBGP-соседств. В JunOS по умолчанию по LDP распространяется только информация о LoopBack-адресах (В Cisco обо всех напрямую доступных префиксах), но это можно изменить при помощи Egress-Policy.

1. Настройка LDP

Тут всё довольно просто. Нужно просто добавить на нужные нам юниты family mpls (у нас уже сделано) и включить все интерфейсы в LDP:

[e-mail].M34# show | compare 
[edit protocols]
+   ldp {
+       interface all;
+   }

На этом первоначальная настройка LDP заканчивается и между LoopBack-адресами устройств устанавливается Pseudowire-соединение.

2. Процесс обмена меток

Как происходит установка LDP-сессии и обмен метками (На примере сообщени M9, отсылаемых в сторону M34):

1) Рассылка Hello-пакетов на multicast-адрес 224.0.0.2 (Все роутеры в сети) на 646 UDP-порт

2) Далее идёт установка TCP-соединения, но уже между адресами интерфейсов:

3) Далее идёт обмен Initialization Message, в ходе которого идёт согласование параметров:

4) После чего произошёл обмен KeepAlive и пересылка Address Message с напрямую доступными сетями от нашего роутера:

5) Далле мы просто выделяем метку и говорим, что если хочешь добраться до 192.168.0.3, то используй метку 3 (Это Penultimate-Hop Popping, так как 192.168.0.3 это наш LoopBack).

Далее этот FEC попадает соседям, они также под него выделяют свою метку, записывают, что её нужно Swap'нуть на принятую и уже со своей меткой передают информацию об этом FEC далее по сети.

3. Проверка работы LDP

Трассировка пути:

[e-mail].M34# run traceroute mpls ldp 192.168.0.5  
  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299824  LDP         10.0.0.5         (null)           Success           
    2        3  LDP         10.0.0.15        10.0.0.5         Egress            

  Path 1 via ge-0/0/1.0 destination 127.0.0.64

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299824  LDP         10.0.0.11        (null)           Success           
    2        3  LDP         10.0.0.21        10.0.0.11        Egress            

  Path 2 via ge-0/0/0.0 destination 127.0.1.64

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299824  LDP         10.0.0.1         (null)           Success           
    2        3  LDP         10.0.0.17        10.0.0.1         Egress            

  Path 3 via ge-0/0/3.0 destination 127.0.2.64

Тут видно, что у нас сразу происходит проверка всех путей:

[e-mail].M34# run show route table inet.3 192.168.0.5     

inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.5/32     *[LDP/9] 00:53:44, metric 1
                      to 10.0.0.11 via ge-0/0/0.0, Push 299824
                    > to 10.0.0.5 via ge-0/0/1.0, Push 299824
                      to 10.0.0.1 via ge-0/0/3.0, Push 299824

Информация о сессияъ, интерфейсах и соседях:

[e-mail].M34# run show ldp session 
  Address           State        Connection     Hold time  Adv. Mode
192.168.0.2         Operational  Open             20         DU
192.168.0.3         Operational  Open             20         DU
192.168.0.4         Operational  Open             20         DU

[edit]
[e-mail].M34# run show ldp interface  
Interface            Label space ID        Nbr count   Next hello
lo0.0                192.168.0.1:0            0           0
ge-0/0/0.0           192.168.0.1:0            1           3
ge-0/0/1.0           192.168.0.1:0            1           4
ge-0/0/3.0           192.168.0.1:0            1           3

[edit]
[e-mail].M34# run show ldp neighbor     
Address            Interface          Label space ID         Hold time
10.0.0.11          ge-0/0/0.0         192.168.0.2:0            14
10.0.0.5           ge-0/0/1.0         192.168.0.3:0            12
10.0.0.1           ge-0/0/3.0         192.168.0.4:0            10

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

[e-mail].M34# run show ldp database session 192.168.0.2     
Input label database, 192.168.0.1:0--192.168.0.2:0
  Label     Prefix
 299776      192.168.0.1/32
      3      192.168.0.2/32
 299792      192.168.0.3/32
 299808      192.168.0.4/32
 299824      192.168.0.5/32
 299840      192.168.0.6/32
 299856      192.168.0.7/32
 299872      192.168.0.8/32

Output label database, 192.168.0.1:0--192.168.0.2:0
  Label     Prefix
      3      192.168.0.1/32
 299776      192.168.0.2/32
 299792      192.168.0.3/32
 299808      192.168.0.4/32
 299824      192.168.0.5/32
 299840      192.168.0.6/32
 299856      192.168.0.7/32
 299872      192.168.0.8/32

4. Взаимодействие MPLS и BGP:

А теперь вспомним, что у нас настроен iBGP, но только между двумя маршрутизаторами на границе автономной системы, которые передают друг другу маршруты с политикой Next-Hop Self. Если бы у нас не был развернут LDP, то при проходждении трафика от AS400 к AS600 возникла бы проблема: он застрянет на следующем же хопе, после нашего граничного роутера.

Но, так как у нас на сети есть LDP, то мы видим следующую картину:

root@AS400> traceroute monitor 160.0.0.1 source 140.0.0.1    

                             My traceroute  [v0.69]
AS400 (0.0.0.0)(tos=0x0 psize=64 bitpattern=0x00)      Mon Apr 26 18:22:57 2021
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 40.0.0.3                          0.0%     9    1.2   1.7   1.1   2.1   0.4
 2. ???
 3. 10.0.0.9                          0.0%     9    2.9   4.0   2.4  10.1   2.3
 4. 160.0.0.1                         0.0%     8    3.6   3.9   3.6   4.3   0.3

Тут видно, что трафик проходит, при этом число прыжков явно меньше. Это происходит из-за MPLS, который туннелирует трафик. Если посмотреть на таблицу маршрутизации на M34, то мы увидим, что для пакета с Dst IP 160.0.0.1 Next-Hop - 192.168.0.8:

[e-mail].M34> show route 160.0.0.1 detail
inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden)
160.0.0.0/16 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
...
Label operation: Push 299776
Protocol next hop: 192.168.0.8

Соответственно, мы навешиваем ту же метку, что выделена в таблице inet.3 под FEC = 192.168.0.8:

[e-mail].M34> show route 192.168.0.8 table inet.3  

inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.8/32     *[LDP/9] 00:24:35, metric 1
                    > to 10.0.0.1 via ge-0/0/3.0, Push 299776

Далее пакет просто коммутируется по меткам вплоть до маршрутизатора LNX, который сможет отправить этот пакет уже без метки.

При этом если мы хотели пускать трафик по статическому LSP, то нужно было прописывать статический маршрут или использовать Route Leaking для переноса маршрутов из inet.3 в inet.0. Тут же для ничего конфигурировать не нужно, метки автоматически попадают в таблицу inet.0, но только для BGP-маршрутов. Т.е. внутренняя маршрутизация происходить по IGP.

Один из главных минусов LDP - отсутствие возможности Traffic Engineering'а. Далее будет рассмотрен протокол RSVP, который обладает такой возможностью. На основе RSVP мы развернём L2 и L3 VPN c типами соединений VPWS и VPLS. На основе LDP также возможно развернуть эти сервисы. Настройка PE-роутеров будет идентична, за исключением некоторых деталей, а в настройке провайдерской сети не будет необходимости, так как LDP всё сделает за нас.