1. Amaç
Önceki yazıda OSPF ve LDP ile PE1 ile PE2 arasında bir LSP kurmuştum. Bu yolun üstünden henüz kimse bir şey taşımıyor. Bu yazıda o yola bir servis bindiriyorum: VPLS. Sonunda CE1 ile CE2, aralarında MPLS çekirdeği olduğunu hiç bilmeden aynı switch’e bağlıymış gibi konuşacak.
Aynı topolojiyi kullanıyorum, bir şey değişmedi.

CE1 ve CE2 aynı subnet’te: 192.168.10.1/24 ve 192.168.10.2/24. VPLS tek bir sanal switch olduğu için iki CE’nin aynı subnet’te olması gerekiyor. Aralarında OSPF ya da başka bir routing protokolü çalıştırmıyorum, aynı L2 ağındalar.
2. LSP varken neden SDP gerekiyor?
İlk aklıma gelen soru buydu: IGP ile LDP zaten bir LSP kurdu, tünel tablosunda duruyor, servis neden doğrudan onu kullanmıyor?
Cevap, SR OS’un servis katmanını taşıma katmanından ayırması. LSP sadece yol. Servisin “karşı PE’ye hangi tünelle gideceğini” ve “hangi etiketi kullanacağını” ayrıca bilmesi lazım. Bunu SDP (Service Distribution Point) yapıyor.
far-endile karşı PE’nin loopback’ini söylüyorum.ldpile “bu uca giderken LDP’nin kurduğu LSP’yi kullan” diyorum.- Servis etiketini (VC label) PE1 ile PE2’nin kendi aralarında konuşması gerekiyor. Mevcut LDP oturumu sadece komşular arası (PE1-P, P-PE2). O yüzden SDP açılınca PE1 ile PE2 arasında loopback’ten loopback’e bir targeted LDP oturumu kuruluyor.
SDP yeni bir tünel değil. Altında hâlâ aynı LSP var. Sadece servis katmanının o LSP’ye baktığı kapı.
Kargo analojisi
Önceki yazıdaki kargo benzetmesine devam edersek: LSP iki merkez arasındaki kamyon yolu. SDP kargo firmasının karşı merkezle yaptığı sözleşme: “oraya giden koliler şu yoldan gidecek.” VPLS ise o sözleşmeyle müşteriye sattığın hizmet. Müşterinin kolisine ayrıca bir müşteri barkodu (servis etiketi) yapıştırılıyor, ortadaki merkez (P) sadece yolun barkoduna bakıyor, müşteri barkoduna bakmıyor.
3. Konfigürasyon
CE portları
CE tarafındaki portlar SR OS’ta varsayılan olarak kapalı. İlk denemede bunu unuttum, o yüzden CE’de interface Down göründü. İki CE’de de portu açmak gerekiyor.
CE1
configure port 1/1/1 no shutdown
CE2
configure port 1/1/2 no shutdown
CE interface’leri (192.168.10.1/24 ve 192.168.10.2/24) zaten tanımlı.
PE1
CE’ye bakan port access moduna geçmeli, çünkü müşteriden gelen Ethernet frame’ini servise sokacak olan kapı bu. Mod değişikliği için port shutdown olmalı.
configure port 1/1/1
shutdown
ethernet
mode access
exit
no shutdown
exit all
Sonra servis tarafı:
configure service
customer 1 create
description "Musteri-1"
exit
sdp 12 mpls create
far-end 4.4.4.4
ldp
no shutdown
exit
vpls 100 customer 1 create
sap 1/1/1 create
no shutdown
exit
mesh-sdp 12:100 create
no shutdown
exit
no shutdown
exit
exit all
PE2
Aynısı, sadece port, SDP numarası ve far-end farklı:
configure port 1/1/2
shutdown
ethernet
mode access
exit
no shutdown
exit all
configure service
customer 1 create
description "Musteri-1"
exit
sdp 21 mpls create
far-end 2.2.2.2
ldp
no shutdown
exit
vpls 100 customer 1 create
sap 1/1/2 create
no shutdown
exit
mesh-sdp 21:100 create
no shutdown
exit
no shutdown
exit
exit all
Komutlar ne yapıyor?
| Komut | Ne yapıyor |
|---|---|
customer 1 | Servisin ait olduğu müşteri. Sadece bir etiket, ama SR OS her servis için istiyor. |
sdp 12 mpls | PE2’ye giden servis tüneli. Numara sadece bu router’da anlamlı, PE2’de 21 yazıyorum. |
far-end 4.4.4.4 | Karşı PE’nin loopback’i. |
ldp | Taşıma için LDP LSP’sini kullan. |
vpls 100 | Sanal switch. Numara servis ID’si. |
sap 1/1/1 | Müşterinin servise girdiği kapı. Bu porttan gelen her frame VPLS’e giriyor. |
mesh-sdp 12:100 | Servisi SDP’ye bağlıyor. 12 SDP numarası, 100 VC-ID. |
VC-ID konusu kafamı karıştırmıştı. 21:100‘deki 100, “VPLS 100” demek değil, sanal kablonun numarası. İki PE’de aynı olması şart. Servis ID’si ile aynı olmasının sebebi varsayılan davranış: VC-ID yazılmazsa servis ID’si kullanılıyor (çıktıda Def. Mesh VC Id : 100).
Aynı SDP üzerinden birden fazla servis geçebilir. Her servisin kendi sanal kablosu (12:100, 12:200, …) ve kendi servis etiketi olur. Paketlerin üzerinde VC-ID yazmıyor, onu sadece kurulum sırasında PE’ler birbirine söylüyor. Veri düzleminde ayıran şey servis etiketi.
4. Doğrulama
Aşağıdaki çıktıları kendi lab’ından yapıştır.
SDP durumu
A:PE1-R2# show service sdp
============================================================================
Services: Service Destination Points
============================================================================
SdpId AdmMTU OprMTU Far End Adm Opr Del LSP Sig
----------------------------------------------------------------------------
12 0 0 4.4.4.4 Up Down MPLS L TLDP
----------------------------------------------------------------------------
Number of SDPs : 1
----------------------------------------------------------------------------
Legend: R = RSVP, L = LDP, B = BGP, M = MPLS-TP, n/a = Not Applicable
I = SR-ISIS, O = SR-OSPF
============================================================================
*A:PE2-R4>config>service>vpls# show service sdp
============================================================================
Services: Service Destination Points
============================================================================
SdpId AdmMTU OprMTU Far End Adm Opr Del LSP Sig
----------------------------------------------------------------------------
21 0 8914 2.2.2.2 Up Up MPLS L TLDP
----------------------------------------------------------------------------
Number of SDPs : 1
----------------------------------------------------------------------------
Legend: R = RSVP, L = LDP, B = BGP, M = MPLS-TP, n/a = Not Applicable
I = SR-ISIS, O = SR-OSPF
============================================================================
Adm ve Opr ikisi de Up olmalı. OprMTU: 0 görüyorsan SDP tüneli bulamamış demektir, LDP LSP’sine bak.
Tunnel table
SDP açılınca tunnel table’a kendini de yazıyor:
A:PE1-R2# show router tunnel-table
===============================================================================
IPv4 Tunnel Table (Router: Base)
===============================================================================
Destination Owner Encap TunnelId Pref Nexthop Metric
-------------------------------------------------------------------------------
3.3.3.3/32 ldp MPLS 65537 9 10.23.23.3 100
4.4.4.4/32 sdp MPLS 12 5 4.4.4.4 0
4.4.4.4/32 ldp MPLS 65538 9 10.23.23.3 200
-------------------------------------------------------------------------------
Flags: B = BGP backup route available
E = inactive best-external BGP route
===============================================================================
4.4.4.4/32 için iki satır var: ldp ve sdp. SDP bir tünel değil, LSP’ye servisten bakan giriş. Altındaki yol hâlâ aynı LDP LSP’si.
Targeted LDP oturumu
A:PE1-R2# show router ldp session
==============================================================================
LDP IPv4 Sessions
==============================================================================
Peer LDP Id Adj Type State Msg Sent Msg Recv Up Time
------------------------------------------------------------------------------
3.3.3.3:0 Link Established 15 16 0d 00:00:24
4.4.4.4:0 Targeted Established 8 10 0d 00:00:20
------------------------------------------------------------------------------
No. of IPv4 Sessions: 2
==============================================================================
3.3.3.3 ile Link ve 4.4.4.4 ile Targeted oturum. İkincisi SDP’nin getirdiği, servis etiketlerini taşıyan oturum.
VPLS servis durumu
A:PE1-R2# show service id 100 base
===============================================================================
Service Basic Information
===============================================================================
Service Id : 100 Vpn Id : 0
Service Type : VPLS
Customer Id : 1 Creation Origin : manual
Admin State : Up Oper State : Up
MTU : 1514 Def. Mesh VC Id : 100
SAP Count : 1 SDP Bind Count : 1
...
-------------------------------------------------------------------------------
Service Access & Destination Points
-------------------------------------------------------------------------------
Identifier Type AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------
sap:1/1/1 null 1514 1514 Up Up
sdp:12:100 M(4.4.4.4) Mesh 0 8914 Up Up
===============================================================================
Alttaki tabloda SAP ve SDP bind satırlarının ikisi de Up/Up. sdp:12:100 M(4.4.4.4) satırındaki M, bunun bir mesh bağlantı olduğunu ve karşı ucun 4.4.4.4 olduğunu söylüyor. Def. Mesh VC Id: 100 ise VC-ID’yi ayrıca yazmadığım için servis numarasını aldığını gösteriyor.
Servisin kurulduğunu tek satırda görmek için:
A:PE1-R2# show service service-using
===============================================================================
Services
===============================================================================
ServiceId Type Adm Opr CustomerId Service Name
-------------------------------------------------------------------------------
100 VPLS Up Up 1
2147483648 IES Up Down 1 _tmnx_InternalIesService
2147483649 intVpls Up Down 1 _tmnx_InternalVplsService
-------------------------------------------------------------------------------
Matching Services : 3
100 VPLS Up Up satırı bizim servisimiz. Alttaki iki _tmnx_ servisi sistemin kendi iç servisleri, aldırma.
Servisin hangi SDP’yi kullandığı ve servis etiketleri:
A:PE1-R2# show service sdp-using
===============================================================================
SDP Using
===============================================================================
SvcId SdpId Type Far End Opr I.Label E.Label
State
-------------------------------------------------------------------------------
100 12:100 Mesh 4.4.4.4 Up 131068 131068
-------------------------------------------------------------------------------
Number of SDPs : 1
I.Label ve E.Label servis (VC) etiketleri, yani paketin içindeki etiket. Wireshark’ta iç etiket olarak 131068’i görmem gerekiyor.
MAC öğrenme
CE1’den CE2’ye ping attıktan sonra:
A:PE1-R2# show service id 100 fdb detail
===============================================================================
Forwarding Database, Service 100
===============================================================================
ServId MAC Source-Identifier Type Last Change
Age
-------------------------------------------------------------------------------
100 0c:1d:fd:69:00:02 sdp:12:100 L/0 10/05/26 13:03:13
100 0c:23:f2:7c:00:01 sap:1/1/1 L/0 10/05/26 13:03:00
-------------------------------------------------------------------------------
No. of MAC Entries: 2
-------------------------------------------------------------------------------
Legend: L=Learned O=Oam P=Protected-MAC C=Conditional S=Static
===============================================================================
CE1’in MAC’i sap:1/1/1 üzerinden, CE2’nin MAC’i sdp:12:100 üzerinden öğrenilmiş. VPLS gerçekten sanal bir switch gibi MAC öğreniyor.
Ping
A:CE1-R1# ping 192.168.10.2
PING 192.168.10.2 56 data bytes
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=46.7ms.
64 bytes from 192.168.10.2: icmp_seq=2 ttl=64 time=31.2ms.
64 bytes from 192.168.10.2: icmp_seq=3 ttl=64 time=197ms.
64 bytes from 192.168.10.2: icmp_seq=4 ttl=64 time=71.5ms.
A:CE1-R1# show router arp
===============================================================================
ARP Table (Router: Base)
===============================================================================
IP Address MAC Address Expiry Type Interface
-------------------------------------------------------------------------------
1.1.1.1 b6:e5:ff:00:00:01 00h00m00s Oth system
192.168.10.1 0c:23:f2:7c:00:01 00h00m00s Oth[I] toPE1
192.168.10.2 0c:1d:fd:69:00:02 03h59m38s Dyn[I] toPE1
-------------------------------------------------------------------------------
No. of ARP Entries: 3
===============================================================================
5. Paketin yolu (Wireshark)
PE1-P ve P-PE2 linklerinde capture alıp
mplsfiltresiyle baktım.
PE1 ile P arasındaki linkte ping isteği iki etiketle gidiyor:
- Dış etiket: transport label (LDP’nin dağıttığı, bizde 131069).
- İç etiket: servis etiketi (VC label), PE1 ile PE2’nin targeted LDP ile anlaştığı etiket.

P ile PE2 arasında ise aynı paket tek etiketle gidiyor:

Önceki yazıda anlattığım PHP burada devreye giriyor: P, dış etiketi (implicit null) söküyor, PE2’ye sadece servis etiketi kalıyor. P’nin servisten haberi yok, sadece dış etikete bakıyor.
İki yön farklı görünüyor:
| Link | Yön | Etiket sayısı |
|---|---|---|
| PE1 - P | PE1 → P (ping isteği) | 2 (transport + servis) |
| PE1 - P | P → PE1 (ping cevabı) | 1 (sadece servis) |
| P - PE2 | P → PE2 (ping isteği) | 1 (sadece servis) |
| P - PE2 | PE2 → P (ping cevabı) | 2 (transport + servis) |
LDP’nin servis etiketi anlaşması da yakalanabiliyor. ldp filtresinde PE1 ile PE2 loopback’leri arasındaki TCP 646 oturumunda bir Label Mapping mesajı var. FEC olarak PWid FEC, VC ID 100 yazıyor:

Bu mesajdaki etiket, router tarafında şu komutta da görünüyor:
A:PE1-R2# show service id 100 sdp 12:100 detail
===============================================================================
Service Destination Point (Sdp Id : 12:100) Details
===============================================================================
-------------------------------------------------------------------------------
Sdp Id 12:100 -(4.4.4.4)
-------------------------------------------------------------------------------
Description : (Not Specified)
SDP Id : 12:100 Type : Mesh
Mesh Descr : (Not Specified)
Split Horiz Grp : (Not Specified)
Etree Root Leaf Tag: Disabled Etree Leaf AC : Disabled
VC Type : Ether VC Tag : n/a
Admin Path MTU : 0 Oper Path MTU : 8914
Delivery : MPLS
Far End : 4.4.4.4
Tunnel Far End : 4.4.4.4 LSP Types : LDP
Hash Label : Disabled Hash Lbl Sig Cap : Disabled
Oper Hash Label : Disabled
Admin State : Up Oper State : Up
Acct. Pol : None Collect Stats : Disabled
Ingress Label : 131068 Egress Label : 131068
Ingr Mac Fltr-Id : n/a Egr Mac Fltr-Id : n/a
Ingr IP Fltr-Id : n/a Egr IP Fltr-Id : n/a
Ingr IPv6 Fltr-Id : n/a Egr IPv6 Fltr-Id : n/a
Admin ControlWord : Not Preferred Oper ControlWord : False
BFD Template : None
BFD-Enabled : no BFD-Encap : ipv4
Last Status Change : 10/05/2026 13:03:01 Signaling : TLDP
Last Mgmt Change : 10/05/2026 13:01:50
Endpoint : N/A Precedence : 4
PW Status Sig : Disabled
Force Vlan-Vc : Disabled Force Qinq-Vc : Disabled
Class Fwding State : Down
Flags : None
Local Pw Bits : None
Peer Pw Bits : None
Peer Fault Ip : None
Peer Vccv CV Bits : lspPing bfdFaultDet
Peer Vccv CC Bits : mplsRouterAlertLabel
Ingress Label ve Egress Label satırları Wireshark’taki iç etiketlerle eşleşiyor.
6. Nerede takıldım
Bu lab’da dört yerde takıldım, hepsi küçük ama ilkini bulmam bayağı sürdü.
1. CE’de interface Down. show router interface çıktısında CE’nin toPE1 interface’i Adm: Up ama Opr: Down idi. Interface açık olunca port da açık sanıyordum. SR OS’ta portlar varsayılan olarak kapalı. İki CE’de de no shutdown ile açınca düzeldi.
2. SDP Down, OprMTU 0. Lab’ı açtıktan hemen sonra bakınca OSPF komşuluğu yoktu, LDP yoktu, SDP Down idi. İki dakika bekleyince hepsi kendiliğinden oturdu. Yani lab’ı açtıktan sonra biraz sabır gerekiyor.
3. PE2’de VPLS kapalı. PE1’de SDP bind Down kalmıştı. PE2’ye bakınca vpls 100 servisinin Admin State: Down olduğunu gördüm. no shutdown eksikti. Karşı taraf kapalı olunca PE1’deki bind de ayağa kalkmıyor. Bu yüzden bir bind Down ise sadece kendi tarafına değil karşı PE’ye de bakmak lazım.
4. PE’den ping. Ping’i PE1’den attım ve No route to destination aldım. PE’nin üzerinde 192.168.10.0/24’e ait bir interface yok, CE portu L2 kapısı (SAP). Ping CE1’den atılmalı.
Hata ayıklarken bana en çok yardım eden komutlar:
show service sdp
show service id 100 base
show service id 100 fdb
show router arp
7. Kafamı karıştıran şeyler
Lab çalışınca asıl kafa karışıklığı başladı. Üç soruyu kendime sordum, cevapları bir yere yazayım.
VPLS ile Epipe farkı ne?
- Epipe sanal bir kablo. Tek SAP ile tek spoke-sdp’yi bağlıyor, yani sadece iki uç var. MAC öğrenmiyor, gelen her şeyi karşıya atıyor.
- VPLS sanal bir switch. Üç ya da daha fazla site olabiliyor, MAC öğreniyor (FDB), bilinmeyen MAC’e flood ediyor.
vpls 100 içine 21:100, 21:200, 21:300 yazarsam bunlar ayrı müşteriler mi?
Hayır. Müşteri ayrımı VPLS’in içindeki satırlarla değil, servis numarasıyla yapılıyor. Bir VPLS’in içindeki her mesh-sdp aynı müşterinin başka bir PE’deki sitesine giden pseudowire. Üç siteli bir müşteri için PE1’de şöyle olur:
vpls 100 customer 1 create
mesh-sdp 12:100 create ... exit <- PE2'ye giden
mesh-sdp 13:100 create ... exit <- PE3'e giden
İki satırda da VC-ID 100, SDP numaraları farklı (12 ve 13). Aynı PE’ye giden birden çok pseudowire’i aynı VPLS’e koymak ise loop riski yaratır, o yüzden yapılmaz.
Peki müşteri nerede ayrılıyor?
Her servis numarası ayrı bir hizmet:
epipe 100bir hizmet,epipe 200başka bir hizmet.vpls 100bir müşteri,vpls 200başka bir müşteri.
Hepsi aynı SDP’den geçebiliyor. SDP numarası yolu (hangi PE’ye gittiğini), VC-ID ise servisi seçiyor. SDP 12 : VC-ID 100 ile SDP 12 : VC-ID 200 aynı LSP’yi paylaşıyor ama paketin içindeki VC label farklı olduğu için karşı PE hangi servise ait olduğunu anlıyor.
Küçük bir ince nokta: servis numarası müşteri değil, hizmet. Müşteriyi customer 1 create kısmındaki sayı belirliyor. Bir müşteri hem vpls 100 hem epipe 200 alabilir. Lab’da hepsine customer 1 yazdım ama gerçekte müşteri ayrımı bu alandan yapılır. Pratikte “bir müşteri = bir servis” gibi düşünmek çoğu zaman yeterli.
8. Özet
- LSP sadece yol. Servis için SDP ve servise özel bir VC label gerekiyor.
- SDP, LSP’ye işaret eden bir giriş. PE1 ile PE2 arasında targeted LDP oturumu açıyor ve servis etiketlerini bu oturumdan konuşuyorlar.
- VPLS, PE’lerde sanal bir switch gibi çalışıyor ve MAC adreslerini öğreniyor. CE’ler aralarındaki MPLS’ten habersiz.
- Pakette iki etiket var: dış etiketi P router’ı swap ediyor (sonra PHP ile söküyor), iç etiketi sadece PE2 okuyor.
- VC-ID iki PE’de aynı olmalı. Aynı SDP’den birden fazla servis geçebilir, her birinin kendi VC-ID’si ve etiketi var.
- Müşteri ayrımı servis numarası (ve
customeralanı) ile yapılır. Bir VPLS’in içindeki mesh-sdp’ler aynı müşterinin farklı siteleridir.
Üçüncü yazıda aynı SDP üzerine kısa bir Epipe kurup VPLS ile farkına bakacağım.