Лаба MPLS VPN. LDP и первые клиенты

У нас уже есть полностью рабочая L3 сеть с запущенным MPLS. Сегодня запускаем LDP и настраиваем первые Epipe и VPLS. Вперед...
Все посты про MPLS VPN можно посмотреть по тегу MPLS или в обобщающем посте.

Сразу стоит сказать, что я столкнулся с некоторыми проблемами. Выяснилось, что IOS-XR 5.1.3 при согласовании LDP сессии передает слишком низкое значение Max PDU. От этого Juniper не хочет с ней дружить. Я даже нашел топик на supportforums.cisco.com. Правда полдня я уже потерял на тот момент. Я пытался поменять vSRX на другой, но решилось проблема заменой 5.1.3 на 5.3.0, но обо всем по порядку.

Топология тоже немного изменилась. Пришел техдир, как это водится, и попросил сделать L2VPN между двумя очень важными точками (CE6 - CE7), которые можно подключить только напрямую к P маршрутизаторам. Бред... По отработанной схеме начнем вонять на тему переноса линков на PE железки, но придется сделать. Итоговая схемка ниже.

Время поджимает, нужно пропускать трафик первых пользователей. Нет времени играться с RSVP-TE, так что организуем сервис на старом добром LDP. Он нам и потом пригодится, т.к. существует рекомендация оставлять LDP на линках на всякий случай, даже при работающем RSPV-TE. 

Для того чтобы поднять MPLS домен, нужно сделать следующее:

1. Включить MPLS на нужных интерфейсах
2. Включить LDP на нужных интерфейсах

Alcatel-Lucent

В Алкателях есть такая важная сущность как System адрес. LDP, например, устанавливается с них при насройках по умолчанию. Я решил эту логику не ломать и убрал loopback интерфейсы, настроив адреса на system интерфейсах. Соответсвтенно, пришлось добавить их в OSPF.

1. Включаем MPLS

configure router mpls

configure router mpls interface "system"

configure router mpls interface "PE1-P1"

configure router mpls interface "PE1-P3"

configure router mpls interface "PE1-PE2"

2. Включаем LDP

configure router ldp

configure router ldp interface-parameters

interface "PE1-P1"

interface "PE1-P3"

interface "PE1-PE2"

Juniper

1. Включаем MPLS

set protocols mpls interface ge-0/0/0.0

set protocols mpls interface ge-0/0/1.0

set protocols mpls interface ge-0/0/2.0

set protocols mpls interface ge-0/0/3.0

2. Включаем LDP

set protocol ldp transport-address router-id

set protocol ldp interface ge-0/0/0.0

set protocol ldp interface ge-0/0/1.0

set protocol ldp interface ge-0/0/2.0

set protocol ldp interface ge-0/0/3.0

set protocol ldp interface lo0.0

Cisco IOS-XR

1. Включаем MPLS

mpls ip

2. Включаем LDP

router ospf 110

mpls ldp auto-config

Вуаля! В теории, все должно заработать можно смотреть show. Мы должны увидеть LDP-соседство на линках и метки, которые распротранил этот протокол.

На ALU видно два P роутера

На  XRe видно все "пэшки" и две "пэешки".

На vSRXе тоже все в порядке

На картинке выше, долгое время сессии с 10.10.10.1 и 10.10.10.2 у меня не поднимались из-за проблемы с Max PDU, о которой я говорил ранее.

Распространение меток

Ну что же, можно проследить метки для какой-нибудь префикса. Глянем на активный путь от PE1 до PE3 для префикса 10.10.10.6/32.

1. LDP распространяет метки для всех префиксов своим соседям и полагается на внутренний протокол маршрутизации для передачи трафика. OSPF сошелся и осноной путь от PE1 до PE2 для достижения 10.10.10.6/32 лежит через P1.

 2. PE1 выделил для этого префикса свою метку 131062, позднее мы увидим, что он отправил её соседям. Ну типа, если вдруг захотите отправить мне трафик для 10.10.10.6/32, то отправляйте его с меткой 131062. Конечно, сложно представить себе такую ситуацию, но так работает LDP. Наиболее интересна первая строчка, в которой указано, что для отправки трафика для этого префикса на него нужно навесить (Push) метку 24004 и отправить в интерфейс 1/1/2 на адрес 10.0.0.17. Он там дальше уже разберется...

3. На P1 видно, что он получил метки для 10.10.10.6/32 от всех своих соседей. В том числе и 131062 от PE1.

Но использует P1 метку 131071, о которой ему рассказал PE3. Решил он так, проконсульировавшись с OSPF. P1 принимает трафик с метой 24004 от PE1 и меняет метку на 131071. Далее трафик отправляется в интерфейс Gi0/0/0/3 в сторону 10.0.0.30

4. Трафик приходит на PE3. Тот смотрит на свои метки и понимает, что он должен отбросить (Pop) метку 131071 и далее передать этот трафик в соответсвующую инстанцию.

Таким образом, для каждого префикса на сети сейчас сущесвтует путь, даже для тех, которые особо и не нужны )

Настройка Epipe

Настройка сервиса происходит на PE устроуства, в нашем случае это PE1 и PE2. Для настроки сервиса нужно:

1. Настроить точку подключения
2. Настроить транспортный туннель (две штуки) до точки выхода
3. Настроить клиента
4. Настроить сам сервис, что сигнализирует pseudowire туннель и свяжет точку подключения с ним

Настроим точку подключения на прием тегированного трафика, что позволит нам принимать много клиентов на одном порту. Сами теги настраиваются на уровне сервиса.

configure port 1/1/3 ethernet mode access encap-type dot1q
configure port 1/1/3 no shutdown

Настроим транспортный туннель до PE2, он же зовется PSN (в терминологии PWE3) или SDP (в терминологии Alcatel).

configure service sdp 2 mpls create
configure service sdp 2 far-end 10.10.10.5
configure service sdp 2 ldp
configure service sdp 2 no shutdown

ID  можно выбрать любой, я выбрал 2. Ну что-то вроде SDP ведущий к PE2.

Добавим клиента.

configure service customer 1 create
configure service customer 1 description "Epipe Customer"
configure service customer 1 phone "+7999887766"

ID клиента должен быть уникальным в пределах одной железки, но будет хорошей практикой сделать его уникальном в пределах всей сети.

Самое вкусное, собираем все воедино. У нас имеется сервис с ID 1 (уникален в пределах железки) с типом Epipe, который принадлежит первому клиенту. Точка подклюения клиента - порт 1/1/3:0. "0" значит принимать только нетегированный трафик. Сделал я так, потому как на клиентских линуксах мне просто не хочется ставить пакет VLAN. Далее создаем spoke-pseudowire, которая будет сигнализирована через SDP под номером два с ID равным единице. Это VC-ID, который должен совпадать на двух концах pseudowire. Ах да, mesh-pseudowire создать не получится, да и не логично это. Трафик пришедший из mesh-pseudowire не будет отправлен назад, а это нарушает весь замысел сервиса epipe.

configure service epipe 1 customer 1 create
configure service epipe 1 customer 1 description "EPIPE"
configure service epipe 1 customer 1 sap 1/1/3:0 create
configure service epipe 1 customer 1 spoke-sdp 2:1 create
configure service epipe 1 customer 1 spoke-sdp 2:1 no shutdown
configure service epipe 1 customer 1 no shutdown

На PE2 делаем аналогичный конфиг, приведу только его выгрузку.

   port 1/1/3
        ethernet
            mode access
            encap-type dot1q
        exit
        no shutdown

    service
        sdp 1 mpls create
            far-end 10.10.10.4
            ldp
           no shutdown

        customer 1 create
            description "Just a customer"

       epipe 1 customer 1 create
            sap 1/1/3:0 create
            exit
            spoke-sdp 1:1 create
                no shutdown
            exit
            no shutdown

Смотрим, все ли поднялось...

Обратите внимание на SAP MTU, он выбирается в зависимости от типа инкапсуляции

и какие метки выбрались...

Pseudowire в отличии от SDP штука двунаправленая и для обоих направлений были сигнализированы одинаковые метки

Таким образом, мы создали сервис. В нем присутсвует:

• два SDP тунеля, по одному в каждое направление
• две точки подключения с выбраной инкапсуляцией
• один pseudowire, который связывает две точки подключения

Пришло время для первого пинга! Но ничего не заработает... Уж не знаю почему, но data plane не хочет передавать трафик. Возможно, это связано с ограничениями лицензии. Парни с алкателевского форума пока не ответили. Забегая вперед, с XR тоже не прокатит, но Cisco хотя бы открыто заявляет, что работать будет только control plane. К сожалению, проверить работу не удастся, придется довольствоваться хорошим выводом show service id 1 base. Но какой-то трафик все же пролезает, я вижу как один хост отправляет ARP запрос, другой хост его получает и отправляет ответ. А вот ответ уже не доходит до получаетеля... К слову, в VPLS будет такая же ситуация, но там ещё и MACи будут изучаться. Последнее обстоятельство сигнализирует о том, что скорее всего все работает и я столкнулся с ограничением платформы...

Настройка VPLS

Для настройки VPLS нам нужно сделать примерно такие же шаги, только туннели проложить придется до каждой выходной точки создав full-mesh.

Настроим точку подключения. Пусть на этот раз весь порт будет отдан абоненту (невиданное расточительство)

configure port 1/1/4 ethernet mode access
configure port 1/1/4 no shutdown

Транспортные туннели от PE1 до PE2 и обратно у нас уже есть. Осталось проложить туннели от PE1 до PE3 и обратно, от PE2 до PE3 и обратно. Я даю теннулям ID в зависимости от назначения. Туннель от PE3 до PE2 будет иметь ID 2, например. Cоздадим SDP от PE1 до PE3.

configure service sdp 3 mpls create
configure service sdp 3 mpls far-end 10.10.10.6
configure service sdp 3 mpls ldp
configure service sdp 3 mpls no shutdown

Создадим клиента

configure service customer 2 create

Создадим сервис с ID 2  и типом VPLS. Закинем в него наш абонентский sap и сигнализируем два pseudowire до точек выхода (PE2 и PE3). Испольщуем новый транспортный туннель до PE3 и созданый на этапе настроки epipe.

configure service vpls 2 customer 2 create
configure service vpls 2 customer 2 sap 1/1/4 create
configure service vpls 2 customer 2 mesh-sdp 2:2 create
configure service vpls 2 customer 2 mesh-sdp 2:2 no shutdown
configure service vpls 2 customer 2 mesh-sdp 3:2 create
configure service vpls 2 customer 2 mesh-sdp 3:2 no shutdown
configure service vpls 2 customer 2 no shutdown

На PE2 и PE3 имеем аналогичные настройки

Для PE2

    port 1/1/4
        ethernet
            mode access
        exit
        no shutdown
   
    service
        customer 2 create
            description "VPLS"

        vpls 2 customer 2 create
            stp
                shutdown
            exit
            sap 1/1/4 create
            exit
            mesh-sdp 1:2 create
                no shutdown
            exit
            mesh-sdp 3:2 create
                no shutdown
            exit
            no shutdown

Для PE3

    port 1/1/3
        ethernet
            mode access
        exit
        no shutdown
  
service
       customer 2 create
      
        vpls 2 customer 2 create
            stp
                shutdown
            exit
            sap 1/1/3 create
            exit
            mesh-sdp 1:2 create
                no shutdown
            exit
            mesh-sdp 2:2 create
                no shutdown
            exit
            no shutdown

Обратите внимание, что на точках выхода можно использовать разные вариант инкапсуляции. Я использовал "чистый" трафик, но можно на PE1 настроить VLAN ID 10, на PE2 - untagged, а на PE3 - qinq.

Взглянем но выводы команд.

 Все поднялось

 

MACи есть

Однако и по VPLS трафик у меня не пошел. Ситуация аналогичная epipe. Будем разбираться, а настройку L2VPN на XR отложим на следующий раз.