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.

LDP Lab Topolojisi

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-end ile karşı PE’nin loopback’ini söylüyorum.
  • ldp ile “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?

KomutNe yapıyor
customer 1Servisin ait olduğu müşteri. Sadece bir etiket, ama SR OS her servis için istiyor.
sdp 12 mplsPE2’ye giden servis tüneli. Numara sadece bu router’da anlamlı, PE2’de 21 yazıyorum.
far-end 4.4.4.4Karşı PE’nin loopback’i.
ldpTaşıma için LDP LSP’sini kullan.
vpls 100Sanal switch. Numara servis ID’si.
sap 1/1/1Müşterinin servise girdiği kapı. Bu porttan gelen her frame VPLS’e giriyor.
mesh-sdp 12:100Servisi 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 mpls filtresiyle 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.

PE1-P linkinde ping isteği, iki MPLS etiketi

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

P-PE2 linkinde ping isteği, tek MPLS etiketi

Ö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:

LinkYönEtiket sayısı
PE1 - PPE1 → P (ping isteği)2 (transport + servis)
PE1 - PP → PE1 (ping cevabı)1 (sadece servis)
P - PE2P → PE2 (ping isteği)1 (sadece servis)
P - PE2PE2 → 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:

LDP Label Mapping, PWid FEC VC ID 100

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 100 bir hizmet, epipe 200 başka bir hizmet.
  • vpls 100 bir müşteri, vpls 200 baş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 customer alanı) 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.