L2VPN: различия между версиями

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску
 
(не показано 48 промежуточных версий этого же участника)
Строка 1: Строка 1:
{{#description2: L2VPN Martini (LDP). L2VPN Kompella (BGP). L2VPN Stitching. Конфигурация L2VPN. Траблшутинг L2VPN. Информация для подготовки к экзаменам Juniper.}}
ISP предоставляет только транспорт. Маршрутизация ложится на клиента.
ISP предоставляет только транспорт. Маршрутизация ложится на клиента.


Строка 5: Строка 7:
Martini - даже нет понятия VPN, это просто объединение 2х точек.
Martini - даже нет понятия VPN, это просто объединение 2х точек.


L2VPN нуждаются в BGP route refresh, без разрыва BGP сессии. Эта функция автоматически включается для L2VPN, дополнительных настроек не требует.
==Martini (LDP)==
==Martini (LDP)==
L2 circuit (RFC 4447)
===Signaling===
===Signaling===
На PE2 int 1 приходит l2-пакет. Пакет нужно туннелировать. Но если просто отправить пакет, то на PE1: не понятно что делать с пакетом. Поэтому при передаче через туннель нужно добавить 2 метки. Верхняя, чтобы передать по туннелю, нижняя связана с интерфейсом.  
На PE2 int 1 приходит l2-пакет. Пакет нужно туннелировать. Но если просто отправить пакет, то на PE1: не понятно что делать с пакетом. Поэтому при передаче через туннель нужно добавить 2 метки. Верхняя, чтобы передать по туннелю, нижняя связана с интерфейсом.  
Строка 23: Строка 28:
* vlan-id - одинаковый (в Cisco может быть одинаковым)
* vlan-id - одинаковый (в Cisco может быть одинаковым)
* MTU - одинаковый, задается только для сигналинга, не имеет практического значения.
* MTU - одинаковый, задается только для сигналинга, не имеет практического значения.
Lo интерфейсы должны быть добавлены в [protocols ldp]
Для корректной работы:
*Между PE должна быть LSP (LDP или RSVP)
*Lo интерфейсы PE должны быть добавлены в [protocols ldp]
 
'''BGP Autodiscovery'''
*FEC 129 BGP autodiscovery for VPWS requires the ''l2vpn-id, source-attachment-identifier'', and ''target-attachment-identifier'' statements.
*Kompella Layer 2 VPNs require the ''site-identifier'' and ''remote-site-id statements''.


===Forwarding===
===Forwarding===
Строка 32: Строка 43:
Мак-адреса не изучаются. Вообще фрейм просто передается тупо и все.
Мак-адреса не изучаются. Вообще фрейм просто передается тупо и все.


Circuit - это по сути 2 метки: на вход (inncoming), на выход (outgoing).  
Circuit - это по сути 2 метки: на вход (incoming), на выход (outgoing).  


Пример (часть ненужных полей в выводе удалена):
Пример (часть ненужных полей в выводе удалена):
Строка 67: Строка 78:
         description l2-to-lagavulin;
         description l2-to-lagavulin;
         encapsulation vlan-ccc;
         encapsulation vlan-ccc;
         vlan-id 560;
         vlan-id 560;}
    }
  [edit protocols l2circuit neighbor 10.200.86.7]
  [edit protocols l2circuit neighbor 10.200.86.7]
       interface ge-0/0/0.560 {
       interface ge-0/0/0.560 {
         virtual-circuit-id 560;
         virtual-circuit-id 560;
         description l2-to-lagavulin;
         description l2-to-lagavulin;
         mtu 9000;
         mtu 9000;}
    }
  [edit protocols ldp]
  [edit protocols ldp]
     interface Lo0.0
     interface Lo0.0
Строка 84: Строка 93:
       interface ge-0/0/3.200
       interface ge-0/0/3.200


===Troubleshooting===
===Verification===
Можно смотреть только состояние l2circuit connection. =(
Можно смотреть только состояние l2circuit connection. =(
Если исключить всякие тупые ошибки, типа mtu mismatch, ненастроенный сигналинг с двух сторон и т.п., то в основном проблемы сводятся к проблемам с обменом метками между PE. В таком случае проверяем:  
Если исключить всякие тупые ошибки, типа mtu mismatch, ненастроенный сигналинг с двух сторон и т.п., то в основном проблемы сводятся к проблемам с обменом метками между PE. В таком случае проверяем:  
Строка 94: Строка 103:
* Поднимать l3 интерфейсы и смотреть свзяность через l2circuit.  
* Поднимать l3 интерфейсы и смотреть свзяность через l2circuit.  
* Если физически нет возможности поднять l3, то можно задействовать logical-tunnel.
* Если физически нет возможности поднять l3, то можно задействовать logical-tunnel.
===psn-tunnel-endpoint===
Строит туннель до адреса, отличного от LDP соседа.
*PE1 lo = 1.1.1.1
*PE2 lo = 2.2.2.2 primary, 10.2.2.2 secondary
2.2.2.2 - LDP LSP, 10.2.2.2 - RSVP LSP.
Если хотим построить l2circuit, который пойдёт по RSVP LSP, достаточно просто в конфиге на PE указать ''psn-tunnel-endpoint'':
set protocols l2circuit neighbor 2.2.2.2 interface ge-0/0/0.10 psn-tunnel-endpoint 10.2.2.2
set protocols l2circuit neighbor 2.2.2.2 interface ge-0/0/0.10 virtual-circuit-id 10
set protocols l2circuit neighbor 2.2.2.2 interface ge-0/0/0.20 virtual-circuit-id 20
ge-0/0/0.20 - будет использовать для построения LDP LSP
ge-0/0/0.10 - будет использовать для построения RSVP LSP. лукап в inet.3 будет делаться для 10.2.2.2.
psn-tunnel-endpoint - не обязательно адрес именно на loopback.


==Kompella (BGP)==
==Kompella (BGP)==
[[Файл:Kireeti Kompella.jpg|thumb|справа|альт=Kireeti Kompella|Компелла. Собственной персоной!]]
Цель - создать полноценный VPN. В l2circuit используется LDP-full-mesh.
Цель - создать полноценный VPN. В l2circuit используется LDP-full-mesh.


Строка 101: Строка 131:


* Для клиента создается '''отдельный RI'''.  
* Для клиента создается '''отдельный RI'''.  
* В него добавляются локальные интерфейсы клиента и
* В него добавляются локальные интерфейсы клиента и указывается с каким удаленным роутером RI будет соединяться. Router-ID - не очень надежно, т.к. его можно заменить, и в таком случае придется переделывать все RI для клиента по всей сети. Поэтому привязку сделали по '''site-id''' - задаются вручную, определяют схему коммутации между роутерами (в рамках RI).  
* указывается с каким удаленным роутером RI будет соединяться. Router-ID - не очень надежно, т.к. его можно заменить, и в таком случае придется переделывать все RI для клиента по всей сети. Поэтому привязку сделали по '''site-id''' - задаются вручную, определяют схему коммутации между роутерами (в рамках RI).  
* Метка назначается каждому '''локальному интерфейсу''', который ассоциирован с site ('''per interface''').
* Метка назначается каждому '''локальному интерфейсу''', который ассоциирован с site ('''per interface''').
* Роутеры между собой обмениваются выделенными метками, чтобы удаленные site знали push какой метки делать, чтобы достичь нужного site. Набор меток - новый NLRI - '''family l2vpn signaling'''.
* Роутеры между собой обмениваются выделенными метками, чтобы удаленные site знали push какой метки делать, чтобы достичь нужного site. Набор меток - новый NLRI - '''family l2vpn signaling'''.
* У каждого клиента также присутствует свой идентификатор - route-target.
* У каждого клиента также присутствует свой идентификатор - route-target.
LSP между PE должна быть предустановлена, можно использовать как LDP так и RSVP.


===L2vpn signaling и выделение меток===
===L2vpn signaling и выделение меток===
Строка 119: Строка 150:


*PE2 видит:  
*PE2 видит:  
я - site 2, site 1 ассоциирован с int 1, site 1 прислал, что для отправки пакета ему, я должен сделать push 102 => int 1: push 102 push 50 (LSP до PE1) резолвим next-hop для PE1 в inet.3))
Я - site 2. Site 1 ассоциирован с int 1. Site 1 прислал, что для отправки пакета ему, я должен сделать push 102 => int 1: push 102 push 50 (LSP до PE1) резолвим next-hop для PE1 в inet.3))


*PE3 видит:
*PE3 видит:
я - site 3, site 1 ассоциирован с int 1, site 1 прислал, что для отправки пакета ему, я должен сделать push 103 => int 1: push 103 push 60.
Я - site 3. Site 1 ассоциирован с int 1. Site 1 прислал, что для отправки пакета ему, я должен сделать push 103 => int 1: push 103 push 60.


То есть все PE получают от site 1 '''все''' метки, хотя им нужна всего одна, которая соответствует его site.
То есть все PE получают от site 1 '''все''' метки, хотя им нужна всего одна, которая соответствует его site.


Kompella решил, что это излишняя инфа и что достаточно пересылать только метки, не указывая каким site они соответствуют. Метки просто будут располагаться ровно в том порядке, в котором они предназначены удаленным site.
Kompella решил, что это излишняя инфа и что достаточно пересылать только метки, не указывая каким site они соответствуют. Просто метки будут располагаться ровно в том порядке, в котором они предназначены удаленным site.
  101 - 1
  101 - 1
  102 - 2
  102 - 2
Строка 132: Строка 163:
  ...
  ...


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


Если на сети будет так: PE1 - site 1, PE2 - site 50, то PE1 будет вынужден выделить метки [1, ..., 50], хотя требуется только 1 и 50. Те site, которые пропускаются, для них будут созданы фейковые метки 2, 3, ..., 49, но метки использоваться не будут.  
Если на сети будет так: PE1 - site 1, PE2 - site 50, то PE1 будет вынужден выделить метки [1, ..., 50], хотя требуется только 1 и 50. Те site, которые пропускаются, для них будут созданы фейковые метки 2, 3, ..., 49, но метки использоваться не будут.  
Строка 167: Строка 198:


Исходя из полученных данных PE вычисляет свою метку для связи с тем PE, кот переслал блок:
Исходя из полученных данных PE вычисляет свою метку для связи с тем PE, кот переслал блок:
  label = label base + site-ID - 1 (offset)
  label = label base (remote) + site-ID (local) - 1 (offset) (remote)


Данная метка заносится в mpls.0
Данная метка заносится в mpls.0


Т.о. получается, что каждый PE хранит у себя 1 метку, а не кучу лишних.
Т.о. получается, что каждый PE хранит у себя одну метку, а не кучу лишних.


Когда добавляется еще один site:
Когда добавляется еще один site:
Строка 191: Строка 222:
* 3 - offset
* 3 - offset
* /96 - mask
* /96 - mask
L2 extended community содержит информацию об MTU: MTU, сконфигурированное PE-CE линке на отправляющем PE. Т.к. на L2 участке нет места фрагментации, то PE, получивший NLRI с не совпадающим MTU, проигнорирует такой NLRI.
*vlan-id = [0 - 511] - обычные vlan-tagged interfaces
*vlan-id = [512 - 4094] - специальные, для ccc-encapsulation.
По факту в настройки vlan-ccc с vlan-id < 512 у меня проблем не возникало.


В случаях, когда на одном роутере подключены 2 site клиента, которые также требуется соединить между собой, можно просто внутри VRF разным интерфейсам назначаем разные site-ID. В этом случае просто для каждого site будет создан свой NLRI. Так тоже можно.
В случаях, когда на одном роутере подключены 2 site клиента, которые также требуется соединить между собой, можно просто внутри VRF разным интерфейсам назначаем разные site-ID. В этом случае просто для каждого site будет создан свой NLRI. Так тоже можно.
Строка 199: Строка 236:
  blair# top show | compare   
  blair# top show | compare   
  [edit interfaces ge-0/0/0]
  [edit interfaces ge-0/0/0]
encapsulation flexible-ethernet-services;
     unit 601 {
     unit 601 {
         encapsulation vlan-ccc;
         encapsulation vlan-ccc;
Строка 239: Строка 277:
                     remote-site-id 1;
                     remote-site-id 1;


 
===Verification===
===Проверка===
  blair> show l2vpn connections     
  blair> show l2vpn connections     
  Instance: fox-services
  Instance: fox-services
Строка 376: Строка 413:
                     > via ge-0/0/0.850, Pop      Offset: 4
                     > via ge-0/0/0.850, Pop      Offset: 4


=Stitching=
Для ститчинга VPN можно использовать ''iw-interface'' или ''lt-interface''.


====Примечание====
В конфиге iw-interface можно задать только инкапсуляции:
Можно соединять Kompella и Martini!
  ethernet-ccc        Ethernet for a cross-connect
Внутри RI, logical-tunnel: 1 int - заносим в instance, указываем его как локальный интерфейс, 2 int - локальный интерфейс для circuit. Можно использовать вместо logical-tunnel специальный интерфейс: iw.0 (он не требует включения tunnel-services). Включается аналогично logical-tunnel.
  frame-relay-ccc      Frame Relay DLCI for CCC
==EVPN==
  ppp-ccc              Serial PPP device for a cross-connect
===About EVPN===
  vlan-ccc            802.1q tagging for a cross-connect
Обеспечивает виртуальную многоточечную связность между разными L2 доменами через IP или MPLS сеть.
Соответственно он работает только для ститчинга L2VPN (разных типов) между собой.


По аналогии с другими VPN, для EVPN на PE роутера создается отдельный Instance (EVIs), который логически разделяет клиентов.  
Если хочется объединить L2VPN+VPLS, или L2VPN+L3VPN, то это делается при помощи ''lt-interface''.


CE имеют соединение с PE. PE обмениваются между собой информацией, использую MP-BGP и инкапсулированный трафик также передают между PE.
==L2VPN BGP (Kompella)==
[[Файл:L2VPN_stitching.png|1024px]]


'''Особенность''': есть mac-learning, который осуществляется на control plane. Новый мак-адрес изученный PE, передается остальным удаленным PE, используя '''MP-BGP MAC route'''. Mac-learning в EVPN намного более тонко работает, чем в VPLS.
Можно объединить два L2VPN, используя '''stitching''' в виде '''interworking interface''' (или иногда используют ''logical-tunnel'', кот требует физического включения на оборудовании и специальную плату):
 
*задаем interface iw.0 внутри [edit interfaces], encapsulation и vlan-id должны быть как и для удаленных концов VPN
С использованием EVPN, можно реализовать на сети много разных топологий: E-LINE, E-LAN, E-TREE.
[interfaces]
 
    iw0 {
MAC-learning на control-plane позволяет примерять policy и другие опции к MAC, изученными между PE, что делает подобный mac-learning более эффективным и дает возможность обеспечивать защиту на сети.
        unit 0 {
 
            encapsulation vlan-ccc;
EVPN полезно внедрят ISP, предоставляющим своим клиентам L2VPN, L3VPN, Internet access и которые дополнительно хотели бы для существующих клиентов предоставить облачные сервисы и хранение данных.
            vlan-id 10;
 
            peer-unit 1;}
Но в основном EVPN полезно использовать дата-центрам, которым требуется l2 связность между дата-центрами. Для внедрения в сеть дата-центров, EVPN обладает такими функиями:
        unit 1 {
*'''Multi-homing между CE-PE''' с поддержанием active-active линков.
            encapsulation vlan-ccc;
Дает возможность подключиться одному CE к нескольким PE, при этом трафик передается по всем активным линкам.
            vlan-id 10;
 
            peer-unit 0; }}
'''Aliasing''' дает возможность удаленным PE делать балансировку к multi-homed PE, через core, даже в том случае, когда удаленный PE изучил мак с одного из Multi-homed PE.
*создаем RI, которые нужно будет скрепить между собой, добавляя в них interface iw0:
 
  [routing-instances]
Также в EVPN есть механизмы для предотвращения BUM петель.
    bear {
 
        instance-type l2vpn;
В случае, когда CE не поддерживает балансировку или PE не имеет средств защиты от BUM петель, тогда можно организовать multi-homing с одним активным линком между PE и CE.
        interface iw0.1;
 
        route-distinguisher 10.200.86.5:999;
*Быстрое восстановление сервиса.
        vrf-target target:1111:999;
С помощью multi-homing, обеспечивается быстрое восстановление сервиса, т.к. при падении PE или линка до PE, трафик переходит на другой активный линк.
        protocols {
 
            l2vpn {
Трафик с другой стороны: удаленный PE обновляет свою forwarding table и также посылает трфик в сторону оставшихся активных PE.
                encapsulation-type ethernet-vlan;
 
                site dalw {
*Поддержка миграции виртуальных машин или MAC mobility.
                    site-identifier 5;
У PE есть возможность отслеживать перемещение мак-адреса виртуальной машины (VM).
                    interface iw0.1 {
При этом, когда VM переместилась, то новый PE, который изучил ее MAC, делает MAC route update. Старый PE, получив таком update, удаляет у себя информацию об этом MAC.
                        remote-site-id 8; }}}}}
 
     fox {
*Интреграция L3 роутинга с оптимальным forwarding.
         instance-type l2vpn;
Для L2 домена можно внедрить L3 routing, путем добавления IRB интерфейса для влана в EVPN instance. Хосты будут использовать этот irb как default gateway.
         interface iw0.0;
 
         route-distinguisher 10.200.86.5:8765;
Irb IP и MAC анонсируются остальным удаленным PE EVPNа путем ''Default Gateway Synchronization''. Это полезно с той точки зрения, что все PE будут в курсе def Gateway и при переезде VM на другой PE, PE будет proxy arp от имени изученного def gateway и маршрутизировать трафик от VM напрямую к destination.
         vrf-target target:1111:8765;
 
Таким же образом, через snooping ARP и DHCP пакетов, происходит заучивание ip-адресов хостов EVPN дата-центров. Называется это ''Host MAC/IP Synchronization'''. После этого появляется возможность передавать трафик к PE, ближайшему к хосту дата-центр. Этот метод совместим в MAC migration.
 
''Asymmetric IRB Forwarding'': L2 заголовок перезаписывается ingress PE перед отправкой пакета. Это позволяет dest PE обойтись без L3 lookup, когда он производит передачу пакета.
 
*Уменьшение утилизации полосы пропускания для multi-destination трафика между разными частями дата-центра в разных местах.
:*PE делают Proxy ARP: изучая ip хостов и def gateway.
:*P2MP or MP2MP LSPs между сторонами дата-центров.
*Поддерживает инкапсуляцию разных данных.
Например, GRE tunnels с IPSEC.
 
===Configuration===
Для поддержки trio-based FPCs, требуется включение '''enhanced-ip'''
  blair# set chassis network-services enhanced-ip   
 
====В ядре:====
*OSPF, на всех интерфейсах. Также включаем TE внутри OSPF.
*MPLS с RSVP-TE LSP. LSP будут использоваться как для EVPN, так и для IP VPN.
*MP-BGP для EVPN и IP VPN. Конфигурируется сессия с P-роутером, который в свою очередь также является и RR (и советуют настроить bfd-detection).
 
====На доступе:====
*В сторону CE настраиваем отдельный интерфейс для каждого Instance с требуемыми вланами.
 
*ESI - Ethernet Segment ID: тербуется для multi-homing. Первый октет = Type, остальные - ID. Вид: ''00:11:11:11:11:11:11:11:11:11''.
 
Задаем ''all-active'', что обеспечивает балансировку между линками.
*LACP даже с одним линком имеет смысл: дает возможность определить действительно ли по линку ходит трафик или нет. Если LACP развалится, значит сигнальные сообщения не проходят по физическим линкам внутри LACP. Также при добавлении или исключении линка из LACP не страдает передача трафика.
 
set interface xe-1/0/0 gither-options 802.3.ad ae0 '''hold-time up 180000 down 0'''
 
*также задается одинаковый system-id для LACP на обоих РЕ. При этом СЕ думает, что LACP установлен с одним устройством.
 
====Сервисы====
*'''EVPN VLAN-based''': один влан, который принадлежит одному bridge домену.
Пример конфига:
routing-instances {
     EVPN-1 {
         instance-type '''evpn''';
        '''vlan-id 100''';
         interface ae0.100;
        routing-interface '''irb.100''';
         route-distinguisher 11.11.11.11:1;
         vrf-target target:65000:1;
         protocols {
         protocols {
             evpn {
             l2vpn {
                 '''default-gateway do-not-advertise'''; }}}}
                 encapsulation-type ethernet-vlan;
                site dalw {
  interfaces {
                    site-identifier 5;
     irb {
                    interface iw0.0 {
        unit 100 {
                        remote-site-id 3; }}}}}}
            family inet {
*включаем l2iw protocol:
                address 100.1.1.1/24; }
  [protocols]
            '''mac 00:00:00:01:01:01'''; }}}
     l2iw;
{{note|text=При выключении protocols l2iw наш ститчинг проложит работать. После выключения и перезагрузки роутера - перестанет работать. Работоспособность восстановится только после повторного включения l2iw.}}
Проверяем:
dalwhinnie> show l2vpn connections
Instance: bear
  Local site: dalw (5)
    connection-site          Type  St    Time last up          # Up trans
    8                        rmt  Up    Feb  9 12:52:35 2017          1
      Remote PE: 10.200.86.8, Negotiated control-word: Yes (Null)
      Incoming label: 800005, Outgoing label: 800006
      Local interface: iw0.1, Status: Up, Encapsulation: VLAN
Instance: fox
  Local site: dalw (5)
    connection-site          Type  St    Time last up          # Up trans
    3                        rmt  Up    Feb 9 12:52:35 2017          1
      Remote PE: 10.200.86.3, Negotiated control-word: Yes (Null)
      Incoming label: 800006, Outgoing label: 800006
      Local interface: iw0.0, Status: Up, Encapsulation: VLAN


Для этого EVPN используется только 1 влан = 100, в данном случае.
==L2VPN LDP (Martini)==
iw interface и протокол l2iw - задаются аналогично, конфигурация l2circuit:
[protocols l2circuit]
    neighbor 10.200.86.3 {
        interface iw0.0 {
            virtual-circuit-id 10;
            encapsulation-type ethernet-vlan; }}
    neighbor 10.200.86.8 {
        interface iw0.1 {
            virtual-circuit-id 10;
            encapsulation-type ethernet-vlan;}}}


mac 00:00:00:01:01:01 - для irb-интерфейсов одного EVPN на разных частях, используют одинаковые ip/mac. Делается для упрощения конфига, уменьшения control plane перезгрузки, и минимизации времени восстановления при падении PE.
dalwhinnie> show l2circuit connections
Neighbor: 10.200.86.3
    Interface                Type  St    Time last up          # Up trans
    iw0.0(vc 10)              rmt  Up    Feb 11 15:51:15 2017          1
      Remote PE: 10.200.86.3, Negotiated control-word: Yes (Null)
      Incoming label: 299872, Outgoing label: 300832
      Negotiated PW status TLV: No
      Local interface: iw0.0, Status: Up, Encapsulation: VLAN
Neighbor: 10.200.86.8
    Interface                Type  St    Time last up          # Up trans
    iw0.1(vc 10)              rmt  Up    Feb 11 15:51:16 2017          1
      Remote PE: 10.200.86.8, Negotiated control-word: Yes (Null)
      Incoming label: 299888, Outgoing label: 300128
      Negotiated PW status TLV: No
      Local interface: iw0.1, Status: Up, Encapsulation: VLAN


default-gateway do-not-advertise - т.к. для irb указаны одинаковые ip/mac, то можно выключить функцию анонсирования MAC/IP binding между PE.


*EVPN VLAN-aware: несколько пользователей с независимыми vlan и ip.
==Kompella + Martini==
Оба сервиса могут использовать vlan translation (настраивается на PE), что дает возможность использовать разные вланы в разных частях.
Опять же interface iw0 и protocols l2iw - такие же.
 
  [protocols l2circuit]
Хорошей практикой считается настраивать VLAN-aware, даже используется всего 1 vlan. Так сказать, задел на будущее.
     neighbor 10.200.86.3 {
 
        interface iw0.0 {
Пример конфига:
            virtual-circuit-id 10;
  routing-instances {
            encapsulation-type ethernet-vlan; }}
     EVPN-2 {
  [routing-instances bear]
      instance-type '''virtual-switch''';
     instance-type l2vpn;
      interface ae0.200;
     interface iw0.1;
      route-distinguisher 11.11.11.11:2;
     route-distinguisher 10.200.86.5:999;
      vrf-target target:65000:2;
     vrf-target target:1111:999;
      protocols {
     protocols {
          evpn {
        l2vpn {
            '''extended-vlan-list 200-202''';
            encapsulation-type ethernet-vlan;
            '''default-gateway advertise'''; }}
             site dalw {
  bridge-domains {
                site-identifier 5;
     V200 {
                interface iw0.1 {
      vlan-id 200;
                    remote-site-id 8;}}}}}
      routing-interface irb.200; }
     V201 {
      vlan-id 201;
      routing-interface irb.201;}
     V202 {
        vlan-id 202;
        routing-interface irb.202; }}}}
interfaces {
        irb {
            unit 200 {
                family inet {
                    address '''200.1.1.1/24'''; }
                mac '''00:00:c8:01:01:01'''; }
            unit 201 {
                family inet {
                    address '''201.1.1.1/24'''; }
                mac '''00:00:c9:01:01:01'''; }
            unit 202 {
                family inet {
                    address '''202.1.1.1/24'''; }
                mac '''00:00:ca:01:01:01''' }}}
 
extended-vlan-list 200-202 - определяет список вланов, которые будут передаваться через ядро.
 
Пример настройки vlan-translation на PE:
interfaces {
     ae0 {
      flexible-vlan-tagging;
      encapsulation flexible-ethernet-services;
      esi {
          00:22:22:22:22:22:22:22:22:22;
          all-active; }
     aggregated-ether-options {
      lacp {
          system-id 00:00:00:00:00:02; }}
    unit 100 {
      encapsulation vlan-bridge;
      vlan-id 100;
      family bridge; }
    unit 200 {
        family bridge {
        interface-mode trunk;
        vlan-id-list [ 200 201 '''202''' ];
        '''vlan-rewrite {'''
             '''translate 222 202'''; }}}}}
 
*IP-VPN: За маршрутизацию между VLAN отвечает irb-интерфейс, присвоенный с общий IP VPN. Также через него можно осуществлять маршрутизацию и с внешним миром.
 
Можно добавлять разные irb в разные IP VPN, чтобы разделить L3 трафик.
 
Пример конфига:
routing-instances {
        IPVPN-1 {
            instance-type vrf;
            interface irb.100;
            interface irb.200;
            interface irb.201;
            interface irb.202;
            route-distinguisher 11.11.11.11:111;
            vrf-import IpVpnDiscardEvpnSubnets;
            vrf-export IpVpnAddCommunities;
            vrf-table-label;
 
policy-options {
        prefix-list PL-EVPN {
            100.1.1.0/24;
            200.1.1.0/24;
            201.1.1.0/24;
            202.1.1.0/24; }
        policy-statement IpVpnAddCommunities {
            term 10 {
                from {
                    prefix-list-filter PL-EVPN orlonger; }
                then {
                    community add COMM-EVPN;
                    community add COMM-IPVPN-1;
                    accept; }}
            term 100 {
                then accept;}}
          policy-statement IpVpnDiscardEvpnSubnets {
            term 10 {
                from community COMM-EVPN;
                then reject; }
            term 100 {
                from community COMM-IPVPN-1;
                then accept; }}
          community COMM-EVPN members 65000:1234;
          community COMM-IPVPN-1 members target:65000:101;}
 
- vrf-export IpVpnAddCommunities; - добавляет community помимо ipvpn (основное) еще и evpn (дополнительно обозначает evpn subnets and hosts).


- vrf-import IpVpnDiscardEvpnSubnets; - т.к.  evpn subnets and hosts уже синхронизируются путем ''Host MAC/IP Synchronization'', что передавать эту информацию через IP VPN - избыточно, поэтому маршруты с таким community будут отброшены, прилетев на PE.
=Дополнительная информация=
*[[VPLS]]
*[[EVPN]]
*[[Реализация MPLS в ядре сети]]

Текущая версия на 18:32, 15 июля 2021


ISP предоставляет только транспорт. Маршрутизация ложится на клиента.

Обе схемы работают одинаково с точки зрения forwarding (используют одинаковую инкаспуляцию). Разница только в signaling (control plane)- BGP vs LDP.

Martini - даже нет понятия VPN, это просто объединение 2х точек.

L2VPN нуждаются в BGP route refresh, без разрыва BGP сессии. Эта функция автоматически включается для L2VPN, дополнительных настроек не требует.

Martini (LDP)

L2 circuit (RFC 4447)

Signaling

На PE2 int 1 приходит l2-пакет. Пакет нужно туннелировать. Но если просто отправить пакет, то на PE1: не понятно что делать с пакетом. Поэтому при передаче через туннель нужно добавить 2 метки. Верхняя, чтобы передать по туннелю, нижняя связана с интерфейсом.

  • Каждый PE каждому интерфейсу выделяет метку (VC label).
  • Приходящие пакеты будут сразу обрабатываться по mpls.0: 40 pop -> int 1, 50 pop -> int 2, 60 pop -> int 3.
  • Как только сконфигурирован l2circuit, интерфейсу выделена метка и записана в mpls.0.
  • Cо стороны PE1 (ingress) - mpls.0: int 1 push 40 push 20 -> P (резолв LDP соседа из inet.3), int 3 push 60 push 20 -> P.

PE1 должен получить информацию о метках, которые нужно назначать. Как??

  • Для передачи используется LDP сессия PE1 <> PE2, в конфигурации задано куда строить LDP туннель. Помним, что по умолчанию LDP поднимает сессии только с непосредственно подключенными соседями.
  • Метки (40, 50, 60) передали от PE2 к PE1.
  • PE1 должен определить какая метка какому интерфейсу соответствует. Этот параметр задаем руками. Virtual curcuit-ID (VCI) - должен быть уникальным для пары устройств, размер 4 байта. VCI передается вместе с метками.

Дополнительно передается:

  • инкапсуляция, которая должна быть одинаковой с обоих концов l2curcuit
  • vlan-id - одинаковый (в Cisco может быть одинаковым)
  • MTU - одинаковый, задается только для сигналинга, не имеет практического значения.

Для корректной работы:

  • Между PE должна быть LSP (LDP или RSVP)
  • Lo интерфейсы PE должны быть добавлены в [protocols ldp]

BGP Autodiscovery

  • FEC 129 BGP autodiscovery for VPWS requires the l2vpn-id, source-attachment-identifier, and target-attachment-identifier statements.
  • Kompella Layer 2 VPNs require the site-identifier and remote-site-id statements.

Forwarding

Фрейм: ip(1500) + l2 header(18) + CW-control word (4) + mpls int (4) + mpls tunnel (4) - это минимальный вариант, но он уже получается большой => стоит ставить MTU с запасом ~1570 или больше.

Форвардинг строится только на метках mpls.0. Внутри сети провайдера пакет передается в 2ми метками (туннельная и интерфейсная).

Мак-адреса не изучаются. Вообще фрейм просто передается тупо и все.

Circuit - это по сути 2 метки: на вход (incoming), на выход (outgoing).

Пример (часть ненужных полей в выводе удалена):

lagavulin> show route table l2circuit.0 detail 
l2circuit.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
10.200.86.3:CtrlWord:4:550:Local/96 (1 entry, 1 announced)
       *L2CKT  Preference: 7
               Next hop type: Indirect
               Next hop: 192.168.86.1 via ge-0/0/0.30 weight 0x1, selected
               Label-switched-path lagavulin-to-oban
               Label operation: Push 300592
               Protocol next hop: 10.200.86.3
               Age: 41:24 	Metric2: 4 
               Announcement bits (1): 0-LDP 
               AS path: I
               VC Label 299968, MTU 9000, VLAN ID 550
10.200.86.3:CtrlWord:4:550:Remote/96 (1 entry, 1 announced)
       *LDP    Preference: 9
               Next hop type: Discard
               Age: 37:49 
               Announcement bits (1): 1-l2 circuit 
               AS path: I
               VC Label 300064, MTU 9000, VLAN ID 550
  • 300064 - push VC label for that destination (метка для интерфейса)
  • 300592 - push MPLS label (для LSP туннеля)
  • 299968 - роутер будет ожидать для данного circuit пакет с этой меткой

Configuration

[edit interfaces ge-0/0/0]
  encapsulation flexible-ethernet-services;
[edit interfaces ge-0/0/0]
   unit 560 {
       description l2-to-lagavulin;
       encapsulation vlan-ccc;
       vlan-id 560;}
[edit protocols l2circuit neighbor 10.200.86.7]
     interface ge-0/0/0.560 {
        virtual-circuit-id 560;
        description l2-to-lagavulin;
        mtu 9000;}
[edit protocols ldp]
   interface Lo0.0

Для ссс-инкапсуляции зарезервирован диапазон 512-4094

Кстати, можно объединять интерфейсы между собой на одном роутере.

[edit protocols l2circuit local-switching]
interface ge-0/0/1.200
   end-interface
      interface ge-0/0/3.200

Verification

Можно смотреть только состояние l2circuit connection. =( Если исключить всякие тупые ошибки, типа mtu mismatch, ненастроенный сигналинг с двух сторон и т.п., то в основном проблемы сводятся к проблемам с обменом метками между PE. В таком случае проверяем:

  • LDP соседство
  • LDP database
  • Наличие Lo в inet.3 и т.д.

Если control plane поднялся:

  • Можем смотреть только обмен пакетами на интерфейсе.
  • Поднимать l3 интерфейсы и смотреть свзяность через l2circuit.
  • Если физически нет возможности поднять l3, то можно задействовать logical-tunnel.

psn-tunnel-endpoint

Строит туннель до адреса, отличного от LDP соседа.

  • PE1 lo = 1.1.1.1
  • PE2 lo = 2.2.2.2 primary, 10.2.2.2 secondary

2.2.2.2 - LDP LSP, 10.2.2.2 - RSVP LSP.

Если хотим построить l2circuit, который пойдёт по RSVP LSP, достаточно просто в конфиге на PE указать psn-tunnel-endpoint:

set protocols l2circuit neighbor 2.2.2.2 interface ge-0/0/0.10 psn-tunnel-endpoint 10.2.2.2
set protocols l2circuit neighbor 2.2.2.2 interface ge-0/0/0.10 virtual-circuit-id 10
set protocols l2circuit neighbor 2.2.2.2 interface ge-0/0/0.20 virtual-circuit-id 20

ge-0/0/0.20 - будет использовать для построения LDP LSP

ge-0/0/0.10 - будет использовать для построения RSVP LSP. лукап в inet.3 будет делаться для 10.2.2.2.

psn-tunnel-endpoint - не обязательно адрес именно на loopback.

Kompella (BGP)

Kireeti Kompella
Компелла. Собственной персоной!

Цель - создать полноценный VPN. В l2circuit используется LDP-full-mesh.

Для Kompella используется сигнализация на основе BGP, можно соорудить full-mesh iBGP, можно использовать RR.

  • Для клиента создается отдельный RI.
  • В него добавляются локальные интерфейсы клиента и указывается с каким удаленным роутером RI будет соединяться. Router-ID - не очень надежно, т.к. его можно заменить, и в таком случае придется переделывать все RI для клиента по всей сети. Поэтому привязку сделали по site-id - задаются вручную, определяют схему коммутации между роутерами (в рамках RI).
  • Метка назначается каждому локальному интерфейсу, который ассоциирован с site (per interface).
  • Роутеры между собой обмениваются выделенными метками, чтобы удаленные site знали push какой метки делать, чтобы достичь нужного site. Набор меток - новый NLRI - family l2vpn signaling.
  • У каждого клиента также присутствует свой идентификатор - route-target.

LSP между PE должна быть предустановлена, можно использовать как LDP так и RSVP.

L2vpn signaling и выделение меток

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

Изначально, исходя из схемы, рассмотрим что требуется передавать между PE, на примере того, что передаст PE1:

  • метки:
  • 102 -> site 2
  • 103 -> site 3
  • 104 -> site 4
  • local site-id:
  • site-id = 1
  • PE2 видит:

Я - site 2. Site 1 ассоциирован с int 1. Site 1 прислал, что для отправки пакета ему, я должен сделать push 102 => int 1: push 102 push 50 (LSP до PE1) резолвим next-hop для PE1 в inet.3))

  • PE3 видит:

Я - site 3. Site 1 ассоциирован с int 1. Site 1 прислал, что для отправки пакета ему, я должен сделать push 103 => int 1: push 103 push 60.

То есть все PE получают от site 1 все метки, хотя им нужна всего одна, которая соответствует его site.

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

101 - 1
102 - 2
103 - 3
...

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

Если на сети будет так: PE1 - site 1, PE2 - site 50, то PE1 будет вынужден выделить метки [1, ..., 50], хотя требуется только 1 и 50. Те site, которые пропускаются, для них будут созданы фейковые метки 2, 3, ..., 49, но метки использоваться не будут.

PE2 получит:

102
103
104

и выберет для себя 103, что будет не правильным поведением.

Отсюда вытекает еще один важный момент, что PE1, который генерирует NLRI с метками - должен запихнуть себя туда, чтобы не нарушить порядок меток.

В итоге от PE2 будет такое распределение меток:

int 1 (site 1) - 201 label
int 2 (site 3) - 203 label
int 3 (site 4) - 204 label
202 label - выделена, но не связана ни с каким интерфейсом.

И будет передан такой NLRI:

201
202
203
204
site-id 2

В Juniper выделен отдельный блок (для Kompella), начиная с 800000, в рамках 1 PE метки не повторяются, должны быть уникальными.

Затем Kompella решил оптимизировать алгоритм, и вместо того, чтобы передавать блок меток, будут передаваться параметры, а метку для себя каждый PE вычислит сам.

В итоге в NLRI передается:

  • label base (начальная)
  • site-ID
  • label range

Исходя из полученных данных PE вычисляет свою метку для связи с тем PE, кот переслал блок:

label = label base (remote) + site-ID (local) - 1 (offset) (remote)

Данная метка заносится в mpls.0

Т.о. получается, что каждый PE хранит у себя одну метку, а не кучу лишних.

Когда добавляется еще один site: site-5: создал RI, сгенерировал NLRI, NLRI проанонсировался остальным PE, через RR. PE1 получил NLRI, понял, что появился site 5, требуется построить до него туннель, посмотрел какую метку push в сторону site 5 - все нормально.

PE5 получил NLRI всех PE от RR, начинает строить до них туннели. Для site 1 - возьмет 105 метку, которой в блоке нет, это понятно по label range. Что делать?

PE1, когда был получен NLRI от PE5, должен изменить NLRI, но метка 105 возможно будет уже занята для других целей. И + уже построенные туннели должны буду заново создаться, т.к. прилетит новый NLRI.

Поэтому, PE1 не меняет текущий блок, а добавляет к нему новый блок, тогда NLRI (конечный вариант):

  • label base = 110
  • site-id = 1
  • label-range = 3
  • label offset = 5 - равен начальному site-ID, которому выделена первая метка блока.

Выглядит так: 10.200.86.1:1212:1:3/96:

  • 10.200.86.1:1212 - RD
  • 1 - site-id
  • 3 - offset
  • /96 - mask

L2 extended community содержит информацию об MTU: MTU, сконфигурированное PE-CE линке на отправляющем PE. Т.к. на L2 участке нет места фрагментации, то PE, получивший NLRI с не совпадающим MTU, проигнорирует такой NLRI.

  • vlan-id = [0 - 511] - обычные vlan-tagged interfaces
  • vlan-id = [512 - 4094] - специальные, для ccc-encapsulation.

По факту в настройки vlan-ccc с vlan-id < 512 у меня проблем не возникало.

В случаях, когда на одном роутере подключены 2 site клиента, которые также требуется соединить между собой, можно просто внутри VRF разным интерфейсам назначаем разные site-ID. В этом случае просто для каждого site будет создан свой NLRI. Так тоже можно.

L2vpn labels.png

Configuration

blair# top show | compare  
[edit interfaces ge-0/0/0]
encapsulation flexible-ethernet-services;
   unit 601 {
       encapsulation vlan-ccc;
       vlan-id 601;
   }
[edit protocols bgp group internal]
  family l2vpn {
      signaling;
[edit routing-instances]
fox-services {
   instance-type l2vpn;
   interface ge-0/0/0.600;
   interface ge-0/0/0.601;
   route-distinguisher 10.200.86.1:1212;
   vrf-target target:1111:1212;
   protocols {
       l2vpn {
           encapsulation-type ethernet-vlan;
           site blair {
               site-identifier 1;
               interface ge-0/0/0.600 {
                   remote-site-id 9;
               }
               interface ge-0/0/0.601 {
                   remote-site-id 4;
tormore:
fox-services {
   instance-type l2vpn;
   interface ge-0/0/0.850;
   route-distinguisher 10.200.86.9:1212;
   vrf-target target:1111:1212;
   protocols {
       l2vpn {
           encapsulation-type ethernet-vlan;
           site tormore {
               site-identifier 9;
               interface ge-0/0/0.850 {
                   remote-site-id 1;

Verification

blair> show l2vpn connections    
Instance: fox-services
 Local site: blair (1)
   connection-site           Type  St     Time last up          # Up trans
   4                         rmt   Up     Nov  7 14:49:02 2016           1
     Remote PE: 10.200.86.4, Negotiated control-word: Yes (Null)
     Incoming label: 800001, Outgoing label: 800000
     Local interface: ge-0/0/0.601, Status: Up, Encapsulation: VLAN
   9                         rmt   Up     Nov  7 17:47:21 2016           1
     Remote PE: 10.200.86.9, Negotiated control-word: Yes (Null)
     Incoming label: 800002, Outgoing label: 800004
     Local interface: ge-0/0/0.600, Status: Up, Encapsulation: VLAN
blair> show route advertising-protocol bgp 10.200.86.9 detail 
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
*  10.200.86.1:1212:1:3/96 (1 entry, 1 announced)
BGP group internal type Internal
    Route Distinguisher: 10.200.86.1:1212
    Label-base: 800000, range: 2, status-vector: 0x0 
    Nexthop: Self
    Flags: Nexthop Change
    Localpref: 100
    AS path: [1111] I
    Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
*  10.200.86.1:1212:1:9/96 (1 entry, 1 announced)
BGP group internal type Internal
    Route Distinguisher: 10.200.86.1:1212
    Label-base: 800002, range: 2, status-vector: 0x0 
    Nexthop: Self
    Flags: Nexthop Change
    Localpref: 100
    AS path: [1111] I
    Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
blair> show route receive-protocol bgp 10.200.86.9 detail table fox-services.l2vpn.0 
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
*  10.200.86.9:1212:9:1/96 (1 entry, 1 announced)
    Import Accepted
    Route Distinguisher: 10.200.86.9:1212
    Label-base: 800004, range: 2, status-vector: 0x0 
    Nexthop: 10.200.86.9
    Localpref: 100
    AS path: I
    Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
blair> show route table bgp.l2vpn.0 detail 
bgp.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
10.200.86.4:1212:4:1/96 (1 entry, 0 announced)
       *BGP    Route Distinguisher: 10.200.86.4:1212
               Source: 10.200.86.4
               Protocol next hop: 10.200.86.4
               Age: 3:01:31 	Metric2: 1 
               Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
               Import Accepted
               Label-base: 800000, range: 2, status-vector: 0x0 
               Localpref: 100
               Router ID: 10.200.86.4
               Secondary Tables: fox-services.l2vpn.0
10.200.86.9:1212:9:1/96 (1 entry, 0 announced)
       *BGP    Route Distinguisher: 10.200.86.9:1212
               Source: 10.200.86.9
               Protocol next hop: 10.200.86.9
               Age: 3:12       Metric2: 1 
               Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
               Import Accepted
               Label-base: 800004, range: 2, status-vector: 0x0 
               Localpref: 100
               Router ID: 10.200.86.9
               Secondary Tables: fox-services.l2vpn.0
tormore> show route receive-protocol bgp 10.200.86.1 table fox-services.l2vpn.0 detail 
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
*  10.200.86.1:1212:1:3/96 (1 entry, 1 announced)
    Import Accepted
    Route Distinguisher: 10.200.86.1:1212
    Label-base: 800000, range: 2, status-vector: 0x0 
    Nexthop: 10.200.86.1
    Localpref: 100
    AS path: I
    Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
*  10.200.86.1:1212:1:9/96 (1 entry, 1 announced)
    Import Accepted
    Route Distinguisher: 10.200.86.1:1212
    Label-base: 800002, range: 2, status-vector: 0x0 
    Nexthop: 10.200.86.1
    Localpref: 100
    AS path: I
    Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100

Forwarding Только метки и ничего больше! 1 метка для L2VPN, одна для передачи через LSP.

Ingress:

blair> show route table fox-services.l2vpn.0 detail
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 10.200.86.9:1212:9:1/96 (1 entry, 1 announced)
       *BGP Route Distinguisher: 10.200.86.9:1212
               Source: 10.200.86.9
               Protocol next hop: 10.200.86.9
               Age: 35:59 	Metric2: 1 
               Announcement bits (1): 0-fox-services-l2vpn 
               Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
               Import Accepted
               Label-base: 800004, range: 2, status-vector: 0x0 
               Localpref: 100
               Router ID: 10.200.86.9
               Primary Routing Table bgp.l2vpn.0
blair> show route table fox-services.l2vpn.0           
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
...
10.200.86.9:1212:9:1/96                
                  *[BGP/170] 00:37:40, localpref 100, from 10.200.86.9
                     AS path: I
                   > to 192.168.86.25 via ge-0/0/0.110, label-switched-path blair-to-tormore
blair> show rsvp session name blair-to-tormore detail 
Ingress RSVP: 2 sessions 
10.200.86.9
 From: 10.200.86.1, LSPstate: Up, ActiveRoute: 0
 LSPname: blair-to-tormore, LSPpath: Primary
 LSPtype: Static Configured
 Resv style: 1 FF, Label in: -, Label out: 301168

На транзитных будет swap и pop с метками для LSP.

Egress:

tormore> show route label 800004  
mpls.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
800004             *[L2VPN/7] 00:05:53
                   > via ge-0/0/0.850, Pop       Offset: 4

Stitching

Для ститчинга VPN можно использовать iw-interface или lt-interface.

В конфиге iw-interface можно задать только инкапсуляции:

 ethernet-ccc         Ethernet for a cross-connect
 frame-relay-ccc      Frame Relay DLCI for CCC
 ppp-ccc              Serial PPP device for a cross-connect
 vlan-ccc             802.1q tagging for a cross-connect

Соответственно он работает только для ститчинга L2VPN (разных типов) между собой.

Если хочется объединить L2VPN+VPLS, или L2VPN+L3VPN, то это делается при помощи lt-interface.

L2VPN BGP (Kompella)

L2VPN stitching.png

Можно объединить два L2VPN, используя stitching в виде interworking interface (или иногда используют logical-tunnel, кот требует физического включения на оборудовании и специальную плату):

  • задаем interface iw.0 внутри [edit interfaces], encapsulation и vlan-id должны быть как и для удаленных концов VPN
[interfaces]
   iw0 {
       unit 0 {
           encapsulation vlan-ccc;
           vlan-id 10;
           peer-unit 1;}
       unit 1 {
           encapsulation vlan-ccc;
           vlan-id 10;
           peer-unit 0; }}
  • создаем RI, которые нужно будет скрепить между собой, добавляя в них interface iw0:
[routing-instances]
   bear {
       instance-type l2vpn;
       interface iw0.1;
       route-distinguisher 10.200.86.5:999;
       vrf-target target:1111:999;
       protocols {
           l2vpn {
               encapsulation-type ethernet-vlan;
               site dalw {
                   site-identifier 5;
                   interface iw0.1 {
                       remote-site-id 8; }}}}}
   fox {
       instance-type l2vpn;
       interface iw0.0;
       route-distinguisher 10.200.86.5:8765;
       vrf-target target:1111:8765;
       protocols {
           l2vpn {
               encapsulation-type ethernet-vlan;
               site dalw {
                   site-identifier 5;
                   interface iw0.0 {
                       remote-site-id 3; }}}}}}
  • включаем l2iw protocol:
[protocols]
   l2iw;

При выключении protocols l2iw наш ститчинг проложит работать. После выключения и перезагрузки роутера - перестанет работать. Работоспособность восстановится только после повторного включения l2iw.

Проверяем:

dalwhinnie> show l2vpn connections 
Instance: bear
 Local site: dalw (5)
   connection-site           Type  St     Time last up          # Up trans
   8                         rmt   Up     Feb  9 12:52:35 2017           1
     Remote PE: 10.200.86.8, Negotiated control-word: Yes (Null)
     Incoming label: 800005, Outgoing label: 800006
     Local interface: iw0.1, Status: Up, Encapsulation: VLAN
Instance: fox
 Local site: dalw (5)
   connection-site           Type  St     Time last up          # Up trans
   3                         rmt   Up     Feb  9 12:52:35 2017           1
     Remote PE: 10.200.86.3, Negotiated control-word: Yes (Null)
     Incoming label: 800006, Outgoing label: 800006
     Local interface: iw0.0, Status: Up, Encapsulation: VLAN

L2VPN LDP (Martini)

iw interface и протокол l2iw - задаются аналогично, конфигурация l2circuit:

[protocols l2circuit]
   neighbor 10.200.86.3 {
       interface iw0.0 {
           virtual-circuit-id 10;
           encapsulation-type ethernet-vlan; }}
   neighbor 10.200.86.8 {
       interface iw0.1 {
           virtual-circuit-id 10;
           encapsulation-type ethernet-vlan;}}}
dalwhinnie> show l2circuit connections 
Neighbor: 10.200.86.3 
   Interface                 Type  St     Time last up          # Up trans
   iw0.0(vc 10)              rmt   Up     Feb 11 15:51:15 2017           1
     Remote PE: 10.200.86.3, Negotiated control-word: Yes (Null)
     Incoming label: 299872, Outgoing label: 300832
     Negotiated PW status TLV: No
     Local interface: iw0.0, Status: Up, Encapsulation: VLAN
Neighbor: 10.200.86.8 
   Interface                 Type  St     Time last up          # Up trans
   iw0.1(vc 10)              rmt   Up     Feb 11 15:51:16 2017           1
     Remote PE: 10.200.86.8, Negotiated control-word: Yes (Null)
     Incoming label: 299888, Outgoing label: 300128
     Negotiated PW status TLV: No
     Local interface: iw0.1, Status: Up, Encapsulation: VLAN


Kompella + Martini

Опять же interface iw0 и protocols l2iw - такие же.

[protocols l2circuit]
   neighbor 10.200.86.3 {
       interface iw0.0 {
           virtual-circuit-id 10;
           encapsulation-type ethernet-vlan; }}
[routing-instances bear]
   instance-type l2vpn;
   interface iw0.1;
   route-distinguisher 10.200.86.5:999;
   vrf-target target:1111:999;
   protocols {
       l2vpn {
           encapsulation-type ethernet-vlan;
           site dalw {
               site-identifier 5;
               interface iw0.1 {
                   remote-site-id 8;}}}}}

Дополнительная информация