LDP
Last updated
Was this helpful?
Last updated
Was this helpful?
Схема сети остаётся прежней. Перед настройкой LDP удалим все настройки статического LSP и включим на всех интерфейсах обработку меток (кроме интерфейсов в сторону eBGP-пиров).
LDP позволяет распространить метки и направлять трафик по меткам, согласно IGP Best Path. Однако, в LDP недоступен TE. В то же время LDP легко настраивается и сравнительно быстро перестраивается вместе с IGP-протоколами при изменениях в топологии. Используется для построения VPN-сервисов и формирования более простых iBGP-соседств. В JunOS по умолчанию по LDP распространяется только информация о LoopBack-адресах (В Cisco обо всех напрямую доступных префиксах), но это можно изменить при помощи Egress-Policy.
Тут всё довольно просто. Нужно просто добавить на нужные нам юниты family mpls (у нас уже сделано) и включить все интерфейсы в LDP:
На этом первоначальная настройка LDP заканчивается и между LoopBack-адресами устройств устанавливается Pseudowire-соединение.
Как происходит установка 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 далее по сети.
Трассировка пути:
Тут видно, что у нас сразу происходит проверка всех путей:
Информация о сессияъ, интерфейсах и соседях:
Также можно посмотреть базу данных меток для определённой сессии. Тут видно что мы от него получли и что ему передали:
А теперь вспомним, что у нас настроен iBGP, но только между двумя маршрутизаторами на границе автономной системы, которые передают друг другу маршруты с политикой Next-Hop Self. Если бы у нас не был развернут LDP, то при проходждении трафика от AS400 к AS600 возникла бы проблема: он застрянет на следующем же хопе, после нашего граничного роутера.
Но, так как у нас на сети есть LDP, то мы видим следующую картину:
Тут видно, что трафик проходит, при этом число прыжков явно меньше. Это происходит из-за MPLS, который туннелирует трафик. Если посмотреть на таблицу маршрутизации на M34, то мы увидим, что для пакета с Dst IP 160.0.0.1 Next-Hop - 192.168.0.8:
Соответственно, мы навешиваем ту же метку, что выделена в таблице inet.3 под FEC = 192.168.0.8:
Далее пакет просто коммутируется по меткам вплоть до маршрутизатора 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 всё сделает за нас.
