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:
root@RT.MSK.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
Трассировка пути:
root@RT.MSK.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Тут видно, что у нас сразу происходит проверка всех путей:
root@RT.MSK.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Информация о сессияъ, интерфейсах и соседях:
root@RT.MSK.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]
root@RT.MSK.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]
root@RT.MSK.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Также можно посмотреть базу данных меток для определённой сессии. Тут видно что мы от него получли и что ему передали:
root@RT.MSK.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/324. Взаимодействие 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:
root@RT.MSK.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:
root@RT.MSK.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 всё сделает за нас.
Last updated
Was this helpful?