Лаба MPLS VPN. ALU/Junos/XR Interoperability

После прошлой статьи у меня появилось некое чувство удовлетворения. Конечно, реальный трафик не пошел, что очень печально. Однако, в общем и целом, я имею рабочую топологию, на которой можно строить VPN сервисы. Как в забытьи прошла пара дней, когда я как одержимый "прокидывал" сервисы через сеть. Этот пост - некое отступление от плана, по которому далее следовало бы включить RSVP-TE. Сегодня хардкор, который потом, скорее всего, придется аннулировать с лабы, потому как это форменный беспредел. Сегодня попытаемся поднять все между всем...

1. Epipe XR-XR
2. VPLS XR-XR
3. Epipe XR-Junos
4. VPLS XR-Junos
5. Epipe XR-ALU
6. VPLS XR-ALU
7. Epipe Junos-ALU
8. VPLS Junos-ALU
9. Epipe Junos-Junos
10. VPLS Junos-Junos

...методом научного тыка.

Забегая вперед, не все пройдет гладко... Осторожно, много текста и картинок. Прошу прощения за причиненные неудобства.
Все посты про MPLS VPN можно посмотреть по тегу MPLS или в обобщающем посте.

Стоит сразу определиться, есть большая путаница в терминологии. У Alcatel - Epipe, у Cisco - EVPL, но настраивается через xconnect, у Juniper - настраивается через l2circuit. Поэтому я полез в RFC 4026 и буду стараться использовать терминологию оттуда. Так же, часто встречается три подхода к организации MPLV L2VPN  вообще:

1. ССС - каждый VPN требует двух LSP по одному на каждое направление. Используется одна метка.
2. Martini - LSP может использоваться многими VPN Circuit'ами, для их разделения используется отдельная метка. Соответствтенно, метки используется две.
3. Komplella - аналогично Martini, но внутренняя метка сигнализируется средствами BGP (BGP AD у Alcatel, как я понимаю).

Ладно, что-то я отвлекся...

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

Ethernet VPWS (Virtual Private Wire Service) IOS-XR to IOS-XR

Начнем с простого, пока без interoperability.

Для начала настраиваем точку подключения - сабинтерфейс.

interface GigabitEthernet0/0/0/4.1 l2transport

 dot1q vlan 20

Потом настраиваем сам сервис. В нем указываем адрес точки выхода и pw-id, который должен совпадать на обоих точках.

l2vpn

 xconnect group Cust1

  p2p Customer1

   interface GigabitEthernet0/0/0/4.1

   neighbor ipv4 10.10.10.1 pw-id 1

Аналогичные операции производим на второй железке

interface GigabitEthernet0/0/0/4.1 l2transport

 dot1q vlan 20

l2vpn

 xconnect group Cust1

  p2p Customer1

   interface GigabitEthernet0/0/0/4.1

   neighbor ipv4 10.10.10.1 pw-id 1

Смотрим что получилось.

На картинке выше отмечено, что сам сервис cross-connect = xconect = xc поднялся. Наш Access Point (AC) в состоянии UP, на нем выставлено MTU 1500. Pseudowire до соседа 10.10.10.1 с ID 1 так же в состоянии UP. Это туннель MPLS с типом протокола LDP. Сигнализировались локальная и удаленная метка 24011(совпали). Галочками отмечены важные моменты при сигнализации туннеля. Ну и чуть ниже видно, что в Cisco уже включен механизм PW Status Notification, о которой я упоминал в посте про VLL. Этот механизм дает нам знать, что на удаленной стороне pseudowire в состоянии UP на обоих направлениях. В общем и целом, сервис поднялся.

Наш XR будет вешать метку 24011, а затем смотреть в CEF, где узнает много интересного (картинка ниже). Трафик с меткой 24011 он должен отправить своему соседу 10.10.10.1, который находится за интерфейсом Gi0/0/0/1 по адресу 10.0.0.1. На исходящий трафик он навесит ещё одну метку, так называемый Implicit Null, которая равна 3. На самом деле никакой метки в кадре не будет. Происходит это потому, что выходная точка из туннеля находится на соседнем маршрутизаторе. Для того чтобы чуть-чуть облегчить ему жизнь, трафик до него идет уже со снятой меткой. Меня, честно говоря, такое поведение несколько раздражает. Я бы предпочел видеть четкую границу MPLS домена, ну да не суть.

Получив такой трафик, второй XR поймет по внутренней VC метке 24011, что это трафик из VPNа и засунет его в нужный интерфейс с нужной инкапсуляцией.

Как видим, у Cisco намного меньше загонов с PSN туннелем, нет кучи ID, которые надо прописывать везде. Настройка выглядит проще. Однако мне подход Алкателя нравится больше, в нем больше порядка и он, на мой взгляд, легче будет поддерживаться при большом количестве клиентов. Он дает больше контроля над ситуацией и не оставляет ощущения того, что все как-то "automagically" заработало.

VPLS (Virtual Private Leased Line) IOS-XR to IOX-XR 

Наверное, тут тоже должно быть все просто.

Настраиваем ещё один AC

interface GigabitEthernet0/0/0/4.2 l2transport
 dot1q vlan 30

Затем настраиваем сам сервис. Добавляем в него наш интерфейс и создаем VFI (Virtual Forwarding Instance) аналог VSI из RFC. К нему добавляем pseudowire до 10.10.10.2 с VC-ID 2 (опять же, должен совпадать на всех устройствах)

l2vpn
 bridge group CUST2
  bridge-domain Customer2
   interface GigabitEthernet0/0/0/4.2
   !
   vfi Customer2
    neighbor 10.10.10.2 pw-id 2

Тоже самое делаем и на втором XR

interface GigabitEthernet0/0/0/4.2 l2transport
 dot1q vlan 30

l2vpn
 bridge group CUST2
  bridge-domain Customer2
   interface GigabitEthernet0/0/0/4.2
   !
   vfi Customer2
    neighbor 10.10.10.2 pw-id 2

Проверяем. На этот раз вывод небольшой, потому что в большей степени он повторяет предыдущие картинки, сосед-то один и тот же.

Как видим, наш сервис поднялся. Так же отмечены настройки виртуального коммутатора. У нашего VFI (VSI) стоит время жизни MAС в 300 секунд и ограничение на 4000 записей в таблице FDB. Наш единственный Access Point в "приподнятом" состоянии, как и VFI c единственным pseudowire. Кстати, есть тут намеки, что можно и с PBB поиграться и с H-VPLS. Писал об это в посте про VPLS. Интересненько...

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

C VPLS XR-XR все просто. Cisco культивирует простоту и некую ленивость, как мне кажется. Но настраивать сервис довольно приятно. В этот же VPLS я попытаюсь засунуть Juniper и ALU. Будет такой один большой кроссвендорный VPLS инстанс. Поглядим что из этого выйдет.

Ethernet VPWS (Virtual Private Wire Service) Junos to IOS-XR

Вероятно, тут будет посложней... Настройки на XR мы уже знаем, поэтому начнем с Juniper.

Настроим, как обычно в общем-то, точку подключения клиента. В Junos зарезервирован диапазон с 513 по 4094. Указываем инкапсуляцию vlan-ccc. ССС означает Circuit cross-connect, а vlan... ну вы поняли. Другими словами, Juniper будет забирать трафик из определенного VLAN и коммутировать его в определенный сервис.

set interface ge-0/0/5 vlan-tagging encapsulation vlan-ccc

set interface ge-0/0/5 unit 512 encapsulation vlan-ccc vlan-id 512 family ccc

Далее настраиваем сам сервис. Для этого настраиваем протокол l2circuit, адрес соседа, VC-ID (должен совпадать на обоих концах). Так же нужно указать локальный AC и тип инкапсуляции. При несовпадении последнего, pseudowire не поднимется.

set protocol l2circuit neighbor 10.10.10.1 interface ge-0/0/5.512 virtual-circuit-id 3 encapsulation-type ethernet-vlan

Настройки на XR уже знакомы

interface GigabitEthernet0/0/0/4.3 l2transport

 dot1q vlan 40

l2vpn

 xconnect group CUST3

  p2p Customer2

   interface GigabitEthernet0/0/0/4.3

   neighbor ipv4 10.10.10.3 pw-id 3

Вывод XR уже видели, теперь взглянем на show l2circuit connections на Juniper.

Видно, что для соседа 10.10.10.1 точка подключения ge-0/0/5.512 c VC-ID 3 в состоянии UP. Тут же сразу видны метки. Juniper и Cisco выбрали разные метки для входящего (299776) и исходящего (24014) трафика.

Выше вывод команды show route table mpls.0 ccc ge-0/0/5.512. Видно, что в таблице есть соответствующая запись. Маршрутизатор отправляет трафик на 10.0.0.6 через интерфейс ge-0/0/1.0 и вставляет метку 24014. По идее, это метка VPN, для того чтобы отправить трафик в интерфейс нужно добавить ещё одну метку в стэк. Узнать это можно командой ниже.

Как видно, роутер просто отправит голый трафик до соседнего 10.10.10.1. Почему? Тот самый Implicit Null. 10.10.10.1 на расстоянии одного хопа от нашего роутера. А вот к 10.10.10.6 трафик будет идти уже с меткой, к примеру. Картинка ниже. 

 

Ну с XR все ясно, приведу картинку для порядка.

VPLS (Virtual Private Leased Line) Junos to IOX-XR

Итак, мы добавляем наш vSRX к VPLSу, в котором уже болтаются два XR. Для этого нам нужно сигнализировать full-mesh из pseudowire, а именно нам понадобится один туннель от Juniper до XR1 и второй до XR2. 

Начнем настройку с Juniper. Как всегда, точка подключения. Я взял другой интерфейс для теста. Думаю, настройки ниже понятны.

set interface ge-0/0/4 vlan-tagging encapsulation vlan-vpls

set interface ge-0/0/4 unit 512 encapsulation vlan-vpls vlan-id 512 family vpls

Далее настраиваем сервис, в Junos это выглядит как routing-instance. Создаем новый инстанс с типом VPLS, добавляем в него наш локальный интерфейс, указываем тип, ID и прописываем пару соседей. В Junos по умолчанию не передаются дополнительные TLV о статусе pseudowire, поэтому я принудительно включил эту возможность. В будущем, это пригодится для дебага. Есть ещё опция no-tunnel-services, которую система попросила меня включить. Команда эта создает по сути LSI (label-switched interface) который будет вешать нужную метку на трафик.

set routing-instances VPLS instance-type vpls interface ge-0/0/4.512

set routing-instances VPLS protocols vpls encapsulation-type ethernet

set routing-instances VPLS protocols vpls no-tunnel-services

set routing-instances VPLS protocols vpls vpls-id 2

set routing-instances VPLS protocols vpls neighbor 10.10.10.1 pseudowire-status-tlv

set routing-instances VPLS protocols vpls neighbor 10.10.10.2 pseudowire-status-tlv

Пришло время взглянуть на вывод show vpls connections. По какой-то причине, два туннеля в состоянии Standby...

Взглянем на ситуацию со стороны XR (картинка ниже). Видно что pseudowire сигнализировался, метки тоже, но с удаленной стороны (от Juniper) пришло уведомление о том, что pseudowire в состоянии stanby. Очень интересно...

Видимо проблема со стороны Juniper, придется лезть в дебаги. Ниже настройка файла дебага для VPLS.

set routing-instances protocols vpls traceoptions file debug-vpls

set routing-instances protocols vpls traceoptions flag all

Из всего множества сообщений меня очень смущает VC NOT PRESENT. Покопавшись в CEF, посмотрев на метки я так и не понял пока в чем причина. AC подняты, метки выделены, LSP существует. Пока что не могу победить эту досадную особенность.

Ethernet VPWS (Virtual Private Wire Service) IOS-XR to ALU

Начнем с Alcatel. 

Создаем SDP до нашего P2

configure service sdp 20 mpls create

configure service sdp 20 far-end 10.10.10.2

configure service sdp 20 ldp

configure service sdp 20 no shutdown

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

configure service customer 4 create

configure service epipe 6 customer 4 create

configure service epipe 6 sap 1/1/3:10 create

configure service epipe 6 spoke-sdp 20:1 create

configure service epipe 6 spoke-sdp 20:1 no shutdown

configure service epipe 6 customer 4 no shutdown

Переходим к XR.

interface GigabitEthernet0/0/0/4.3 l2transport

 dot1q vlan 40

Alcatel создает Ethernet сервис, а XR Ethernet-Vlan. Поменяем тип сервиса на XR с помощью объявления pseudowire класса.

l2vpn

 pw-class ETH

  encapsulation mpls

   transport-mode ethernet

Создаем сервис и применяем к нему класс

 xconnect group Cust4

  p2p Customer4

   interface GigabitEthernet0/0/0/4.3

   neighbor ipv4 10.10.10.4 pw-id 1

    pw-class ETH

Сервис успешно поднялся.

Посмотрим как трафик будет передаваться. Сначала на него будет навешена метка, которая сигнализировалась при установки pseudowire. Источником трафика является наш роутер, то действует первое правило на картинке ниже. Маршрутизаптор добавит (Push) метку 24005 и отправит в интерфейс 1/1/2 на адрес 10.0.0.17. Ну а тот дальше уже пусть сам разбирается.

VPLS (Virtual Private Leased Line) ALU to IOS-XR to Junos

Нам нужно создать два новых SDP (PSN) туннеля, для того чтобы добавить PE1 в уже созданные ранее VPLS (P1-P2-P3). Приведу просто выгрузку из конфига, как создавать SDP уже знаем.

        sdp 10 mpls create

            far-end 10.10.10.1

            ldp

            keep-alive

                shutdown

            exit

            no shutdown

        exit

        sdp 30 mpls create

            far-end 10.10.10.3

            ldp

            keep-alive

                shutdown

            exit

            no shutdown

        exit

Создаем клиента и настраиваем сервис. По какой-то причине я не могу настраивать vc-id отличные от 4. Устройство ругалось на то, что значение не соответствует дефолтному. Пришлось сменить дефолтное...

        vpls 4 customer 5 create

            def-mesh-vc-id 2

            stp

                shutdown

            exit

            sap 1/1/3:20 create

            exit

            mesh-sdp 10:2 create

                no shutdown

            exit

            mesh-sdp 20:2 create

                no shutdown

            exit

            mesh-sdp 30:2 create

                no shutdown

            exit

            no shutdown

Настраиваем пару XR роутеров

l2vpn

 bridge group CUST2

  bridge-domain Customer2

   vfi Customer2

    neighbor 10.10.10.4 pw-id 2

И Juniper

set routing-instances protocols vpls neighbor 10.10.10.4 pseudowire-status-tlv

Смотрим вывод show service id 4 base на ALU

Оп... все поднялось... даже pseudowire до Juniper... А почему тогда от Juniper до XR не поднялось?.. Идем на Juniper.

Непонятно. По какой-то причине pseudowire от Juniper до ALU работает, а от Juniper до Cisco нет...

Ethernet VPWS (Virtual Private Wire Service) Junos to ALU

Так, быстро заделаем Epipe между P3 и PE1. Приведу только выгрузки конфигов.

На ALU все как обычно

   service
       customer 6 create

        epipe 7 customer 6 create

            sap 1/1/3:30 create

            exit

            spoke-sdp 30:3 create

                no shutdown

            exit

            no shutdown

        exit

    exit

На Juniper тоже все стандартно. Единственное, укажем тип l2circuit ethernet. Как вариант, можно было на ALU прописать ethernet-vlan.

    ge-0/0/5 {

        vlan-tagging;

        encapsulation vlan-ccc;

        unit 513 {

            encapsulation vlan-ccc;

            vlan-id 513;

            family ccc;

        }

protocols {

    l2circuit {

        neighbor 10.10.10.4 {

            interface ge-0/0/5.513 {

                virtual-circuit-id 3;

                encapsulation-type ethernet;

            }

        }

    }

Смотрим, радуемся.

Тут нужно взять некоторый перерыв, потому как прокинуть сервис Junos-Junos невозможно на нашей топологии. Придется добавить ещё один SRX. Схемка ниже. Довольно сложно оправдать его нашей легендой. Но пусть это будет резервный SRX, на котором инженеры просто захотели что-то протестировать. Ну и стоит он такой особнячком, ни туда, ни сюда. 

Ethernet VPWS (Virtual Private Wire Service) Junos to Junos

Для примера настроим Ethernet VLL. Принимаем трафик в интерфейс и отправляем на другое устройство, никаких VLANов. Уже нашел в документации, что трафик не пойдет, но полюбуемся на control plane.

Настраиваем точку подключения

    ge-0/0/7 {
        encapsulation ethernet-ccc;
        unit 0 {
            family ccc;

Настраиваем сам сервис

protocols {

    l2circuit {

        neighbor 10.10.10.10 {

            interface ge-0/0/7.0 {

                virtual-circuit-id 4;

                encapsulation-type ethernet;

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

    ge-0/0/2 {
        encapsulation ethernet-ccc;
        unit 0 {
            family ccc;

protocols {

    l2circuit {

        neighbor 10.10.10.4 {

            interface ge-0/0/2.0 {

                virtual-circuit-id 4;

                encapsulation-type ethernet;

На картинке выше видим, что все прекрасно поднялось.

Выводы

Как итог у нас настроена куча сервисов (VPLS и VPWS), которые затрагивают Juniper, Cisco и Alcatel. Честно говоря, я думал, что ситуация будет намного печальней. В принципе, можно сказать, что все работает. Пока что я так и не смог разобраться в VPLS в Juniper. Ясно, что проблемы в Juniper. По какой-то причине, он после сигнализирования pseudowire кладет её в состояние standby. Такая же ситуация наблюдается, кстати говоря, и между двумя Juniper. Толи ему не нравится, что трафика нет, то ли ещё что-то. В свободное время надо обязательно разобраться.

Итак, в этом посте мы проверили interoperability:

1. VPLS - Juniper + Alcatel + Cisco
2. VPWS - Juniper - Cisco
3. VPWS - Juniper - Alcatel
4. VPWS - Cisco - Alcatel

и просто создали сервисы:

1. Cisco - Cisco
2. Juniper - Juniper