L2/L3 VPN

Начнём с простого, с L2 Сircuit (Ethernet over MPLS). Построить туннель можно статикой (если нужно) либо при помощи Targeted LDP. RSVP для построения соседства не поддерживается, однако, трафик по маршруту построенному по RSVP пускать можно, в чём убедимся позже.

Также есть VPWS. Отличается тем, что сигнальный протокол тут BGP и метки распространяются при помощи него, а не tLDP, поэтому соседи (т.е. PE) обнаруживаются автоматически. Об этом лучше прочитать тут и тут. Но, вроде бы уже давно к Martini прикрутили auto-discovery.

1. L2 VPN (Martini Mode)

1.1. L2 Circuit (Ethernet over MPLS)

Можно отдавать услугу клиенту просто на всём физическом порту или по VLAN'у. Настроим VLAN-Based L2 Circuit. Выделим на нашей и клиентской стороне VLAN и Unit под номером 500. Физические порты можно оставить.

Настройка

RT.MSK.M34

[e-mail].M34# show | compare 
[edit interfaces ge-0/0/0]
+   flexible-vlan-tagging;
+   native-vlan-id 4094;
+   encapsulation flexible-ethernet-services;
[edit interfaces ge-0/0/0 unit 0]
+    vlan-id 4094;
[edit interfaces ge-0/0/1]
+   flexible-vlan-tagging;
+   native-vlan-id 4094;
+   encapsulation flexible-ethernet-services;
[edit interfaces ge-0/0/1 unit 0]
+    vlan-id 4094;
[edit interfaces ge-0/0/2]
+   flexible-vlan-tagging;
+   native-vlan-id 4094;
+   encapsulation flexible-ethernet-services;
[edit interfaces ge-0/0/2 unit 0]
+    vlan-id 4094;
[edit interfaces ge-0/0/2]
+    unit 500 {
+        encapsulation vlan-ccc;
+        vlan-id 500;
+        family ccc;
+    }                                  
[edit interfaces ge-0/0/3]
+   flexible-vlan-tagging;
+   native-vlan-id 4094;
+   encapsulation flexible-ethernet-services;
[edit interfaces ge-0/0/3 unit 0]
+    vlan-id 4094;
[edit protocols]
+   l2circuit {
+       neighbor 192.168.0.8 {
+           interface ge-0/0/2.500 {
+               virtual-circuit-id 1488;
+           }
+       }
+   }
[edit]
+  bridge-domains {
+      native {
+          vlan-id 4094;
+      }
+  }

RT.SPB.LNX

AS400

AS600

На самом деле тут всё довольно просто. Основная настройка пришлать на выдачу VLAN'ов, а сам туннель был настроен под "edit protocols l2circuit", где мы просто указали нашего tLDP PE-соседа, интерфейс в сторону CE и ID сервиса.

Вообще, главное в LDP включить интерфейс в сторону CE и Lo0. LSP можеть быть построен по любому протоколу. Хоть по RSVP, хоть статически. Подробнее.

Проверка работы

Проверим LDP-сессии

[e-mail].M34# run show ldp session 
  Address           State        Connection     Hold time  Adv. Mode
192.168.0.2         Operational  Open             22         DU
192.168.0.3         Operational  Open             22         DU
192.168.0.4         Operational  Open             22         DU
192.168.0.8         Operational  Open             27         DU

[edit]
[e-mail].M34# run show ldp neighbor   
Address            Interface          Label space ID         Hold time
192.168.0.8        lo0.0              192.168.0.8:0            34
10.0.0.11          ge-0/0/0.0         192.168.0.2:0            13
10.0.0.5           ge-0/0/1.0         192.168.0.3:0            13
10.0.0.1           ge-0/0/3.0         192.168.0.4:0            13

Тут видно, что нашим соседом стал маршрутизатор RT.SPB.LNX, хотя физически это не так. Его видно и в сессиях и в соседях. А теперь включим дамп на ge-0/0/3 RT.SPB.STL и посмотрим как выглядит трафик, проходящий по сети:

root@AS600# run traceroute monitor 10.0.0.1 source 10.0.0.2                   

​​​                             My traceroute  [v0.69]
AS600 (0.0.0.0)(tos=0x0 psize=64 bitpattern=0x00)      Fri Apr 30 14:57:19 2021
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 10.0.0.1                          0.0%   197    4.6   5.9   3.3  65.1   9.1

Но вот в дампе на порту ge-0/0/3 RT.SPB.STL трафика мы не увидим. Хоть соседство и было установлено по LDP трафик будет ходит по ранее установленному маршруту RSVP, так как в inet.3 RSVP имеет меньшую административную дистанцию. Дамп на RT.SPB.MIR:

Посмотреть tLDP подключения на PE:

[e-mail].M34# run show l2circuit connections extensive 
Layer-2 Circuit Connections:

Legend for connection status (St)   
EI -- encapsulation invalid      NP -- interface h/w not present   
MM -- mtu mismatch               Dn -- down                       
EM -- encapsulation mismatch     VC-Dn -- Virtual circuit Down    
CM -- control-word mismatch      Up -- operational                
VM -- vlan id mismatch           CF -- Call admission control failure
OL -- no outgoing label          IB -- TDM incompatible bitrate 
NC -- intf encaps not CCC/TCC    TM -- TDM misconfiguration 
BK -- Backup Connection          ST -- Standby Connection
CB -- rcvd cell-bundle size bad  SP -- Static Pseudowire
LD -- local site signaled down   RS -- remote site standby
RD -- remote site signaled down  HS -- Hot-standby Connection
XX -- unknown

Legend for interface status  
Up -- operational            
Dn -- down                   
Neighbor: 192.168.0.8 
    Interface                 Type  St     Time last up          # Up trans
    ge-0/0/2.500(vc 1)        rmt   Up     Apr 30 15:00:08 2021           1
      Remote PE: 192.168.0.8, Negotiated control-word: Yes (Null)
      Incoming label: 299936, Outgoing label: 299904
      Negotiated PW status TLV: No
      Local interface: ge-0/0/2.500, Status: Up, Encapsulation: VLAN
      Flow Label Transmit: No, Flow Label Receive: No
    Connection History:
        Apr 30 15:00:08 2021  PE route changed     
        Apr 30 15:00:08 2021  Out lbl Update                    299904
        Apr 30 15:00:08 2021  In lbl Update                     299936
        Apr 30 15:00:08 2021  loc intf up                 ge-0/0/2.500

По факту, по tLDP идёт распространение сервисными метками, которые привязаны к номеру service-id, который мы указали при настройке. Соединение по tLDP происходит аналогично, только установление сессии начинается с Unicast-отсылки нашего Hello-сообщения:

Далее установление сессии происходит аналогично обычному LDP. Отличие кроется в Label Message:

Тут мы видим, что FEC - это virtual-circuit-id, который мы указывали ранее, а метка в десятичном виде равна 299776. Именно её будет накидывать M34 "по просьбе" LNX:

[e-mail].M34# run show route table mpls.0 protocol l2circuit detail       

mpls.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
299936 (1 entry, 1 announced)
        *L2CKT  Preference: 7
                Next hop type: Router, Next hop index: 565
                Address: 0x96461e8
                Next-hop reference count: 2
                Next hop: via ge-0/0/2.500, selected
                Label operation: Pop       Offset: 4
                Load balance label: None; 
                Session Id: 0x0
                State: <Active Int>
                Local AS:   250 
                Age: 10:00 
                Validation State: unverified 
                Task: Common L2 VC
                Announcement bits (1): 0-KRT 
                AS path: I

ge-0/0/2.500 (1 entry, 1 announced)
        *L2CKT  Preference: 7
                Next hop type: Indirect
                Address: 0x9644e50
                Next-hop reference count: 2
                Next hop type: Router, Next hop index: 573
                Next hop: 10.0.0.11 via ge-0/0/0.0, selected
                Label-switched-path M34-LNX
                Label operation: Push 299776, Push 300064(top) Offset: 252, MTU 1488
                Label TTL action: no-prop-ttl, no-prop-ttl(top)
                Load balance label: Label 299776: None; Label 300064: None; 
                Session Id: 0x146
                Protocol next hop: 192.168.0.8
                Label operation: Push 299776 Offset: 252
                Label TTL action: no-prop-ttl
                Load balance label: Label 299776: None; 
                Indirect next hop: 0x96c8220 1048574 INH Session ID: 0x14a
                State: <Active Int>
                Local AS:   250 
                Age: 10:00      Metric2: 20 
                Validation State: unverified 
                Task: Common L2 VC
                Announcement bits (2): 0-KRT 2-Common L2 VC 
                AS path: I

Аналогично выглядит и сообщение посылаемое от M34:

Метка в 10ой системе счисления равна 299936

[e-mail]# run show route table mpls.0 protocol l2circuit detail 

mpls.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
299776 (1 entry, 1 announced)
        *L2CKT  Preference: 7
                Next hop type: Router, Next hop index: 575
                Address: 0x963e104
                Next-hop reference count: 2
                Next hop: via ge-0/0/3.500, selected
                Label operation: Pop       Offset: 4
                Load balance label: None; 
                Session Id: 0x0
                State: <Active Int>
                Local AS:   250 
                Age: 16:57 
                Validation State: unverified 
                Task: Common L2 VC
                Announcement bits (1): 0-KRT 
                AS path: I

ge-0/0/3.500 (1 entry, 1 announced)
        *L2CKT  Preference: 7
                Next hop type: Indirect
                Address: 0x963e280
                Next-hop reference count: 2
                Next hop type: Router, Next hop index: 572
                Next hop: 10.0.0.26 via ge-0/0/1.0, selected
                Label-switched-path M34-LNX
                Label operation: Push 299936, Push 300112(top) Offset: 252
                Label TTL action: no-prop-ttl, no-prop-ttl(top)
                Load balance label: Label 299936: None; Label 300112: None; 
                Session Id: 0x145
                Protocol next hop: 192.168.0.1
                Label operation: Push 299936 Offset: 252
                Label TTL action: no-prop-ttl
                Load balance label: Label 299936: None; 
                Indirect next hop: 0x96c4220 1048574 INH Session ID: 0x142
                State: <Active Int>
                Local AS:   250 
                Age: 16:57      Metric2: 20 
                Validation State: unverified 
                Task: Common L2 VC
                Announcement bits (2): 0-KRT 2-Common L2 VC 
                AS path: I

1.2. VPLS

Добавим в схему сети ещё 3 устройства и сделаем между ними VPLS. Вот пример настройки клиентского устройства:

Site1

system {
    host-name Site1;
    root-authentication {
        encrypted-password "$1$D04Hyvlf$3YmHgm40cCPxwcVzVBWop/"; ## SECRET-DATA
    }
}
interfaces {
    ge-0/0/9 {
        flexible-vlan-tagging;
        encapsulation flexible-ethernet-services;
        unit 0 {
            vlan-id 500;
            family inet {
                address 10.0.0.1/24;
            }
        }
    }
}

Настроим конечный порт под клиента и создадим под VPLS специальный Routing-Instance:

[e-mail].M8# show | compare 
[edit interfaces]
+   ge-0/0/9 {
+       flexible-vlan-tagging;
+       encapsulation flexible-ethernet-services;
+       unit 500 {
+           encapsulation vlan-vpls; ##Включаем на юните VPLS
+           vlan-id 500;
+           family vpls;
+       }
+   }
[edit]
+  routing-instances {
+      vpls-500 {
+          instance-type vpls;
+          interface ge-0/0/9.500; ##Интерфейс в сторону CE
+          protocols {
+              vpls {                  ##Не используем VT-интерфейсы, нужные для
+                  no-tunnel-services; ##мультикаста
+                  vpls-id 500;        ##Аналог virtual-circuit-id
+                  mac-flush;           ##Разрешаем очистку MAC-адресов
+                  neighbor 192.168.0.7 { ##Указываем соседа и разрешаем передачу
+                      pseudowire-status-tlv; ##состояния pseudowire-tlv
+                  }
+                  neighbor 192.168.0.6 {
+                      pseudowire-status-tlv;
+                  }                    
+              }
+          }
+      }
+  }

Подробнее о туннельных сервисах, туннельных интерфейсах, Pseudowire-status в TLV, MAC-flushing.

После настройки получаем следующий результат:

[e-mail].M8# run show vpls connections extensive  
Layer-2 VPN connections:

Legend for connection status (St)   
EI -- encapsulation invalid      NC -- interface encapsulation not CCC/TCC/VPLS
EM -- encapsulation mismatch     WE -- interface and instance encaps not same
VC-Dn -- Virtual circuit down    NP -- interface hardware not present 
CM -- control-word mismatch      -> -- only outbound connection is up
CN -- circuit not provisioned    <- -- only inbound connection is up
OR -- out of range               Up -- operational
OL -- no outgoing label          Dn -- down                      
LD -- local site signaled down   CF -- call admission control failure      
RD -- remote site signaled down  SC -- local and remote site ID collision
LN -- local site not designated  LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum designated
XX -- unknown connection status  IL -- no incoming label
MM -- MTU mismatch               MI -- Mesh-Group ID not available
BK -- Backup connection          ST -- Standby connection
PF -- Profile parse failure      PB -- Profile busy
RS -- remote site standby        SN -- Static Neighbor
LB -- Local site not best-site   RB -- Remote site not best-site
VM -- VLAN ID mismatch

Legend for interface status 
Up -- operational                       
Dn -- down

Instance: vpls-500
  VPLS-id: 500
    Number of local interfaces: 1
    Number of local interfaces up: 1
    ge-0/0/9.500       
    lsi.1048576                   Intf - vpls vpls-500 neighbor 192.168.0.6 vpls-id 500
    lsi.1048577                   Intf - vpls vpls-500 neighbor 192.168.0.7 vpls-id 500
    Neighbor                  Type  St     Time last up          # Up trans
    192.168.0.6(vpls-id 500)  rmt   Up     May  2 15:47:02 2021           1
      Remote PE: 192.168.0.6, Negotiated control-word: No
      Incoming label: 262145, Outgoing label: 262145
      Negotiated PW status TLV: Yes
      local PW status code: 0x00000000, Neighbor PW status code: 0x00000000
      Local interface: lsi.1048576, Status: Up, Encapsulation: ETHERNET
        Description: Intf - vpls vpls-500 neighbor 192.168.0.6 vpls-id 500
      Flow Label Transmit: No, Flow Label Receive: No
    Connection History:
        May  2 15:47:02 2021  status update timer  
        May  2 15:47:01 2021  PE route changed     
        May  2 15:47:01 2021  Out lbl Update                    262145
        May  2 15:47:01 2021  In lbl Update                     262145
        May  2 15:47:01 2021  loc intf up                  lsi.1048576
    192.168.0.7(vpls-id 500)  rmt   Up     May  2 15:48:09 2021           1
      Remote PE: 192.168.0.7, Negotiated control-word: No
      Incoming label: 262146, Outgoing label: 262145
      Negotiated PW status TLV: Yes
      local PW status code: 0x00000000, Neighbor PW status code: 0x00000000
      Local interface: lsi.1048577, Status: Up, Encapsulation: ETHERNET
        Description: Intf - vpls vpls-500 neighbor 192.168.0.7 vpls-id 500
      Flow Label Transmit: No, Flow Label Receive: No
    Connection History:
        May  2 15:48:09 2021  status update timer  
        May  2 15:48:09 2021  PE route changed     
        May  2 15:48:09 2021  Out lbl Update                    262145
        May  2 15:48:09 2021  In lbl Update                     262146
        May  2 15:48:09 2021  loc intf up                  lsi.1048577

Проверка:

root@Site3# run traceroute 10.0.0.1 source 10.0.0.3                         
traceroute to 10.0.0.1 (10.0.0.1) from 10.0.0.3, 30 hops max, 40 byte packets
 1  10.0.0.1 (10.0.0.1)  7.940 ms  2.950 ms  2.955 ms

[edit]
root@Site3# run traceroute 10.0.0.2 source 10.0.0.3    
traceroute to 10.0.0.2 (10.0.0.2) from 10.0.0.3, 30 hops max, 40 byte packets
 1  10.0.0.2 (10.0.0.2)  16.361 ms  6.277 ms  2.385 ms

При этом саму таблицу в RIB не найти, она есть тольков в FIB:

[e-mail].M8# run show route forwarding-table table vpls-500         
Routing table: vpls-500.vpls
VPLS:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
default            perm     0                    dscd      516     1
lsi.1048576        intf     0                    indr  1048578     4
                              10.0.0.21         Push 262145, Push 299856(top)      631     2 ge-0/0/4.0
lsi.1048577        intf     0                    indr  1048579     4
                              10.0.0.21         Push 262145, Push 299792(top)      633     1 ge-0/0/4.0
0x30003/51         user     0                    comp      613     2
ge-0/0/9.500       intf     0                    ucst      590     4 ge-0/0/9.500
0x30002/51         user     0                    comp      594     2
0x30001/51         user     0                    comp      593     2

Минусы Martini Mode очевидны. Главный минус - это отсутствие возможности автообнаружения PE. И чем больше точек в VPLS, тем больше соседей приходится конфигурировать вручную. Эту проблему решает Kompella Mode. Эта технология позволяет передавать сервисные метки при помощи MP-BGP (Multiprotocol BGP). Но, прежде чем приступить к разбору Kompella Mode стоить рассмотреть L3 VPN, так как по принципу работу есть схожесть в некоторых моментах.

2. L3 VPN

Прежде чем настраивать L3 VPN, нужно разобраться с различными Routing-Instances и, в особенности, с RD/RT. Если вкратце, то под L3 VPN используется VRF Routing Instance. RD - позволяет определить к какой VRF принадлежит маршрутная информация. Необходим, чтобы для MBGP всё не сливалось в кучу. RT - бывает export и import. По факту, Export RT - это extended community. Import RT - позволяет указать какие маршруты, помеченные соответствующим Community, мы хотим принимать. Import RT может состоять из нескольких значений.

Предварительно стоит донастроить iBGP. Настроим парочку RR. Пусть ими будут STL и OBV. Они будут резервом для одного кластера. Как настраиваются RR было показано в главе про BGP. iBGP в данном случае нужен, чтобы распространять информацию о приватных клиентских префиксах по нашей сети. Можно было бы настроить Full-Mesh связность между PE, но смысла в частичной настройке нет. При росте клиентов мы всё равно вернёмся к тому, что у нас везде будет настроен iBGP, только хаотично и неструктурированно. Этого стоит избегать.

Для L3 VPN можно использовать unit 100. На клиентской стороне пока просто настроим адресацию. Теперь приступим к настройке PE:

[e-mail].M8# show | compare 
[edit interfaces ge-0/0/9]
+    unit 100 {
+        family inet {
+            address 172.16.0.1/31;
+        }
+    }
[edit routing-instances]
+   L3VPN {
+       instance-type vrf; ##Указываем, что это VRF
+       vrf-table-label; ##Генерировать одну метку для всех анонсируемых маршрутов
+       interface ge-0/0/9.100; ##Указываем интерфейс
+       route-distinguisher 250:0; ##RD для связи маршрутов от клиента с VRF
+       vrf-target { ##Указываем Extended Community (одинаковы для обычного L3 VPN)
+           import target:250:500;##Импортируем только префиксы с community 250:500
+           export target:250:500;##Экспортируем маршруты с таким же community.
+       }                         ##это позволит маршрутизаторам различать в какую
+   }                             ##VRF импортировать маршруты

Однако, после этой настройки, маршрутная информация передаваться не будет. Для BGP необходимо также настроить address family. Можно настроить для всей iBGP-группы передачу как обычных префиксов IPv4, так и префиксов с RT (Если используется IPv6, то нужно включить и его. Также есть множество других Address Family, про них не стоит забывать, иначе передача маршрутной информации прекратится):

[e-mail]# show | compare 
[edit protocols bgp group iBGP]
+     family inet {
+         any;
+     }
+     family inet-vpn {
+         unicast;
+     }

Далее настраиваем с клиентом OSPF (Включаем в OSPF интерфейсы в сторону клиента, а у клиента просто интерфейсы в сторону провайдера и lo0). Но, это ещё не всё. Так как мы получаем маршруты от различных PE по BGP, то нам необходим экспорт этих маршрутов в протокол OSPF:

[e-mail].M8# show

routing-instances {
    L3VPN {
        protocols {
            ospf {
                export L3VPN_BGP-OSPF;
            }
        }
    }
}
policy-options {
    policy-statement L3VPN_BGP-OSPF {
        from protocol bgp;
        then accept;
    }
}

Проверка связности:

                             My traceroute  [v0.69]
Site3 (0.0.0.0)(tos=0x0 psize=64 bitpattern=0x00)      Mon May  3 01:40:57 2021
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 172.16.0.5                        0.0%     3    1.8   2.1   1.2   3.2   1.0
 2. ???
 3. 172.16.0.3                        0.0%     2    2.6   4.3   2.6   6.1   2.5
 4. 172.16.2.1                        0.0%     2    4.0   4.0   3.9   4.0   0.0

А вот так выглядит BGP Update:

Зачем же нужно передавать Update с метками? Это нужно чтобы трафик ходил по ядру сети при помощи MPLS, не используя таблицу маршрутизации. Т.е. мы как бы сообщаем, что если мы хотим достичь префикса 172.16.1.1, то на пакет нам нужно навешать метки 299968 (top), чтобы трафик дошёл до нужного нам PE, и 16 (bottom), чтобы попал в нужную Routing-Instance для маршрутизации. Т.е. мы передаём не столько маршрутную информацию, сколько FEC соседнему PE. Ну и сам маршрут, где видно сервисную и транспортную метки:

[e-mail]# run show route table L3VPN.inet.0 172.16.1.1 

L3VPN.inet.0: 11 destinations, 17 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.1.1/32      *[BGP/170] 00:16:52, MED 1, localpref 100, from 192.168.0.4
                      AS path: I, validation-state: unverified
                    > to 10.0.0.24 via ge-0/0/0.0, Push 16, Push 299968(top)
                    [BGP/170] 00:17:12, MED 1, localpref 100, from 192.168.0.5
                      AS path: I, validation-state: unverified
                    > to 10.0.0.24 via ge-0/0/0.0, Push 16, Push 299968(top)

Как видно, сама передача сервисных меток происходит по BGP. Это позволяет не указывать явно соседей, так как они находятся сами при помощи RT. Этот механизм был взят за основу Kompella Mode L2 VPN и VPLS.

3. VPLS (Kompella Mode)

Смысла настраивать VPWS Kompella Mode особо нет, так как нужно будет также создавать отдельную Routing-Instance. Изменится только указание instance-type с vpls на l2vpn и настройка будет чуть легче. Сразу приступим к VPLS.

Настроим адресацию на юнитах 250 интерфейсов ge-0/0/9 на Site1, Site2, Site3:

Router	Interface	Address
Site1	ge-0/0/9.250	10.250.0.1/24
Site2	ge-0/0/9.250	10.250.0.2/24
Site3	ge-0/0/9.250	10.250.0.2/24

А теперь настроим VPLS с сигнализацией BGP:

[e-mail].K12# show | compare                      
[edit interfaces ge-0/0/9]
+    unit 250 {
+        encapsulation vlan-vpls;
+        vlan-id 250;
+        family vpls;
+    }
[edit routing-instances]
+   kompella-vpls-250 {
+       instance-type vpls;
+       interface ge-0/0/9.250;
+       route-distinguisher 10.250.0.2:1;
+       vrf-target target:250:250; ##Можно указать так, если Import и Export равны 
+       protocols {
+           vpls {
+               no-tunnel-services;
+               site Sites { ##Указываем название для этой точки
+                   site-identifier 2; ##Указываем ID точки
+                   interface ge-0/0/9.250; ##и интерфейс в сторону CE
+               }
+            mac-flush;
+           }
+       }
+   }

Тут всё аналогично. RD служит для понимания какой NLRI какой routing-instance принадлежит, а RT служит для передачи маршрутной информации другим PE в соответствующие Routing-Instance. Site-ID указывает ID точки подключения. На каждом PE он должен быть уникален для интерфейса. Kompella Mode позволяет подключать с одного PE несколько клиентских точек, чего не может сделать Martini Mode, как раз за счёт site-identifier. Т.е. если нужно сюда подключить ещё одну точку клиента, то просто указываем новый site и новый уникальный ID.

Теперь посмотрим VPLS Connections:

[e-mail].M8# run show vpls connections instance kompella-vpls-250 
Layer-2 VPN connections:

Instance: kompella-vpls-250
  Local site: Sites (1)
No connections found.

Так происходит потому что у BGP не настроена соответствующая Address Family. Просто добаляем к уже существующей конфикурации следующие строчки на каждом iBGP маршрутизаторе:

set protocols bgp group iBGP family l2vpn signaling

Повторная проверка после коммита:

[e-mail].M8# run show vpls connections instance kompella-vpls-250    

Instance: kompella-vpls-250
  Local site: Sites (1)
    connection-site           Type  St     Time last up          # Up trans
    2                         rmt   Up     May  4 10:07:46 2021           1
      Remote PE: 192.168.0.7, Negotiated control-word: No
      Incoming label: 262402, Outgoing label: 262401
      Local interface: lsi.1048578, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls kompella-vpls-250 local site 1 remote site 2
    3                         rmt   Up     May  4 10:07:52 2021           1
      Remote PE: 192.168.0.6, Negotiated control-word: No
      Incoming label: 262403, Outgoing label: 262401
      Local interface: lsi.1048579, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls kompella-vpls-250 local site 1 remote site 3

Проверка пингом:

root@Site1# run ping 10.250.0.255  
PING 10.250.0.255 (10.250.0.255): 56 data bytes
64 bytes from 10.250.0.2: icmp_seq=0 ttl=64 time=4.072 ms
64 bytes from 10.250.0.3: icmp_seq=0 ttl=64 time=9.467 ms (DUP!)
64 bytes from 10.250.0.3: icmp_seq=1 ttl=64 time=3.917 ms
64 bytes from 10.250.0.2: icmp_seq=1 ttl=64 time=4.810 ms (DUP!)
64 bytes from 10.250.0.2: icmp_seq=2 ttl=64 time=4.865 ms
64 bytes from 10.250.0.3: icmp_seq=2 ttl=64 time=18.338 ms (DUP!)
64 bytes from 10.250.0.3: icmp_seq=3 ttl=64 time=3.171 ms
64 bytes from 10.250.0.2: icmp_seq=3 ttl=64 time=4.219 ms (DUP!)
^C
--- 10.250.0.255 ping statistics ---
4 packets transmitted, 4 packets received, +4 duplicates, 0% packet loss
round-trip min/avg/max/stddev = 3.171/6.607/18.338/4.786 ms

Вот так выглядит сообщение с сервисной меткой:

CE-ID - это тот самый site-identifier, который мы указывали при настройке.

4.VPLS (Martini Mode with PE Autodiscovery)

Отличется от Kompella Mode чуть менее длинной настройкой и тем, что сервисные метки также передаются по LDP, но PE находят друг друга самостоятельно по BGP. Указываем, что хотим использовать BGP не только для сигнализации, но и просто для обнаружения PE:

set protocols bgp group iBGP family l2vpn auto-discovery-only

Интерфейс в сторону CE настраивается аналогично. Пример настройки PE:

[e-mail].M8# show | compare 
[edit interfaces ge-0/0/9]
+    unit 2500 {
+        encapsulation vlan-vpls;
+        vlan-id 2500;
+        family vpls;
+    }
[edit protocols bgp group iBGP family l2vpn]
+       auto-discovery-only;
[edit routing-instances]
+   martini-auto {
+       instance-type vpls;
+       interface ge-0/0/9.2500;
+       route-distinguisher 2500:10001;
+       l2vpn-id l2vpn-id:2500:100;
+       vrf-target target:2500:1001;
+       protocols {
+           vpls {
+               no-tunnel-services;
+           }
+       }                               
+   }

Проверка пингом:

root@Site1# run ping 10.10.10.255 
PING 10.10.10.255 (10.10.10.255): 56 data bytes
64 bytes from 10.10.10.3: icmp_seq=0 ttl=64 time=8.327 ms
64 bytes from 10.10.10.2: icmp_seq=0 ttl=64 time=9.475 ms (DUP!)
64 bytes from 10.10.10.3: icmp_seq=1 ttl=64 time=4.352 ms
64 bytes from 10.10.10.2: icmp_seq=1 ttl=64 time=5.281 ms (DUP!)
64 bytes from 10.10.10.3: icmp_seq=2 ttl=64 time=3.452 ms
64 bytes from 10.10.10.2: icmp_seq=2 ttl=64 time=4.386 ms (DUP!)
64 bytes from 10.10.10.3: icmp_seq=3 ttl=64 time=3.745 ms
64 bytes from 10.10.10.2: icmp_seq=3 ttl=64 time=4.663 ms (DUP!)
^C
--- 10.10.10.255 ping statistics ---
4 packets transmitted, 4 packets received, +4 duplicates, 0% packet loss
round-trip min/avg/max/stddev = 3.452/5.460/9.475/2.072 ms

А теперь посмотрим на разницу между VPLS Kompella Mode и Martini Mode:

[e-mail].M8# run show vpls connections 
Layer-2 VPN connections:

Instance: kompella-vpls-250
  Local site: Sites (1)
    connection-site           Type  St     Time last up          # Up trans
    2                         rmt   Up     May  4 10:07:46 2021           1
      Remote PE: 192.168.0.7, Negotiated control-word: No
      Incoming label: 262402, Outgoing label: 262401
      Local interface: lsi.1048578, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls kompella-vpls-250 local site 1 remote site 2
    3                         rmt   Up     May  4 10:07:52 2021           1
      Remote PE: 192.168.0.6, Negotiated control-word: No
      Incoming label: 262403, Outgoing label: 262401
      Local interface: lsi.1048579, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls kompella-vpls-250 local site 1 remote site 3

Instance: martini-auto
  L2vpn-id: 2500:100
  Local-id: 192.168.0.2
    Remote-id                 Type  St     Time last up          # Up trans
    192.168.0.6               rmt   Up     May  4 11:11:48 2021           1
      Remote PE: 192.168.0.6, Negotiated control-word: No
      Incoming label: 262148, Outgoing label: 262148
      Negotiated PW status TLV: No
      Local interface: lsi.1048581, Status: Up, Encapsulation: ETHERNET
        Description: Intf - vpls martini-auto local-id 192.168.0.2 remote-id 192.168.0.6 neighbor 192.168.0.6
      Flow Label Transmit: No, Flow Label Receive: No
    192.168.0.7               rmt   Up     May  4 11:11:48 2021           1
      Remote PE: 192.168.0.7, Negotiated control-word: No
      Incoming label: 262147, Outgoing label: 262147
      Negotiated PW status TLV: No
      Local interface: lsi.1048580, Status: Up, Encapsulation: ETHERNET
        Description: Intf - vpls martini-auto local-id 192.168.0.2 remote-id 192.168.0.7 neighbor 192.168.0.7
      Flow Label Transmit: No, Flow Label Receive: No

Instance: vpls-500
  VPLS-id: 500
    Neighbor                  Type  St     Time last up          # Up trans
    192.168.0.6(vpls-id 500)  rmt   Up     May  4 08:46:50 2021           1
      Remote PE: 192.168.0.6, Negotiated control-word: No
      Incoming label: 262145, Outgoing label: 262145
      Negotiated PW status TLV: Yes
      local PW status code: 0x00000000, Neighbor PW status code: 0x00000000
      Local interface: lsi.1048576, Status: Up, Encapsulation: ETHERNET
        Description: Intf - vpls vpls-500 neighbor 192.168.0.6 vpls-id 500
      Flow Label Transmit: No, Flow Label Receive: No
    192.168.0.7(vpls-id 500)  rmt   Up     May  4 08:46:52 2021           1
      Remote PE: 192.168.0.7, Negotiated control-word: No
      Incoming label: 262146, Outgoing label: 262145
      Negotiated PW status TLV: Yes
      local PW status code: 0x00000000, Neighbor PW status code: 0x00000000
      Local interface: lsi.1048577, Status: Up, Encapsulation: ETHERNET
        Description: Intf - vpls vpls-500 neighbor 192.168.0.7 vpls-id 500
      Flow Label Transmit: No, Flow Label Receive: No

Первое, что бросается в глаза - это Encapsulation ETHERNRT в Martini и VPLS в Kompella а также, так или иначе, явно указанный neighbor в Description. Вот так выглядит сообщение о доступности PE в VPLS:

Т.е. в отличие от Kompella Mode, Тут просто указывается то, что PE доступен, а передачей сервисных меток всё также занимается LDP.