Начнём с простого, с 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. Физические порты можно оставить.
На самом деле тут всё довольно просто. Основная настройка пришлать на выдачу VLAN'ов, а сам туннель был настроен под "edit protocols l2circuit", где мы просто указали нашего tLDP PE-соседа, интерфейс в сторону CE и ID сервиса.
Проверка работы
Проверим LDP-сессии
root@RT.MSK.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]
root@RT.MSK.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:
root@RT.MSK.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:
root@RT.MSK.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
root@RT.SPB.LNX# 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. Вот пример настройки клиентского устройства:
root@RT.MSK.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:
root@RT.MSK.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
Предварительно стоит донастроить iBGP. Настроим парочку RR. Пусть ими будут STL и OBV. Они будут резервом для одного кластера. Как настраиваются RR было показано в главе про BGP. iBGP в данном случае нужен, чтобы распространять информацию о приватных клиентских префиксах по нашей сети. Можно было бы настроить Full-Mesh связность между PE, но смысла в частичной настройке нет. При росте клиентов мы всё равно вернёмся к тому, что у нас везде будет настроен iBGP, только хаотично и неструктурированно. Этого стоит избегать.
Для L3 VPN можно использовать unit 100. На клиентской стороне пока просто настроим адресацию. Теперь приступим к настройке PE:
root@RT.MSK.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, про них не стоит забывать, иначе передача маршрутной информации прекратится):
root@RT.SPB.MIR# show | compare
[edit protocols bgp group iBGP]
+ family inet {
+ any;
+ }
+ family inet-vpn {
+ unicast;
+ }
Далее настраиваем с клиентом OSPF (Включаем в OSPF интерфейсы в сторону клиента, а у клиента просто интерфейсы в сторону провайдера и lo0). Но, это ещё не всё. Так как мы получаем маршруты от различных PE по BGP, то нам необходим экспорт этих маршрутов в протокол OSPF:
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. Ну и сам маршрут, где видно сервисную и транспортную метки:
root@RT.SPB.MIR# 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:
root@RT.SPB.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:
root@RT.MSK.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
Повторная проверка после коммита:
root@RT.MSK.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:
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:
root@RT.MSK.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.
Вообще, главное в LDP включить интерфейс в сторону CE и Lo0. LSP можеть быть построен по любому протоколу. Хоть по RSVP, хоть статически. .
Подробнее о , , , .
Прежде чем настраивать L3 VPN, нужно разобраться с различными и, в особенности, с . Если вкратце, то под L3 VPN используется VRF Routing Instance. RD - позволяет определить к какой VRF принадлежит маршрутная информация. Необходим, чтобы для MBGP всё не сливалось в кучу. RT - бывает export и import. По факту, Export RT - это extended community. Import RT - позволяет указать какие маршруты, помеченные соответствующим Community, мы хотим принимать. Import RT может состоять из нескольких значений.
