Veri iletişiminin temel taşlarından biri, cihazların birbirini tanımasıdır. İşte bu noktada, veri bağlantı katmanında çalışan özel bir çerçeve formatı olan LLTD devreye girer. Kulağa bir güvenlik aracı ya da yönetim yazılımı gibi gelebilir. Ancak bu yapı, paket yapısı, mesaj kodlaması ve çerçeve formatı üzerine kuruludur. Dolayısıyla sistem, tamamen bir katman 2 protokolü olarak çalışır.
Bu rehberde, protokolü bir veri formatı ve iletişim spesifikasyonu olarak ele alacağız. Ethertype değerinden TLV yapısına, Demultiplex Header alanlarından QoS mesaj kodlamasına kadar her detayı inceleyeceğiz. Amacım, ağ paketlerinin nasıl biçimlendirildiğini ve cihazlar arasında nasıl taşındığını net bir şekilde göstermektir.
Öncelikle şunu netleştirelim: LLTD, TCP/IP yığınından bağımsız çalışır. Yani port numarası yoktur, IP başlığı taşımaz. Bunun yerine, ham Ethernet çerçeveleri üzerinden doğrudan veri alışverişi yapar. Bu yapı, onu hem hafif hem de öngörülebilir kılar.
2026 yılına geldiğimizde, ağ protokollerinin veri formatı analizi büyük önem kazandı. Çünkü protokolü kodlamayı bilirsiniz. Buna ek olarak protokolü doğru kullanır ve zafiyetleri anlarsınız. Bu yazıda, odağımız net: protokolün teknik formatı ve veri yapısı.

LLTD Nedir? Link Layer Topology Discovery Protokolüne Kapsamlı Bakış
Ağ protokolleri genellikle iki gruba ayrılır: veri taşıyanlar ve kontrol mesajı iletenler. Bu protokol ikinci gruptadır. Link Layer Topology Discovery ne demek sorusunun en net cevabı şudur: OSI modelinin 2. katmanında çalışan, özel bir çerçeve formatına sahip bir keşif protokolüdür.
Microsoft, Windows Vista döneminde LLTD tanıttı. Amacı, ağdaki cihazların birbirini bulmasını sağlamaktı. Ancak protokolün asıl teknik değeri, kullandığı veri kodlama yöntemlerinde yatar. Protokol, her mesajı belirli bir ikili formatta paketler. Her alan, belirli bir bayt uzunluğundadır.
LLTD protokolü diğerlerinden ayıran temel özellik, Ethertype 0x88D9 değeridir. Bu değer, Ethernet çerçevesinin hangi üst katmana ait olduğunu belirtir. Bir ağ kartı bu Ethertype’ı gördüğünde, paketi işletim sisteminin protokol işleyicisine yönlendirir. Böylece paket, TCP/IP yığınına hiç uğramaz.
Öte yandan, LLTD protokolün mesaj yapısı son derece modülerdir. Her mesaj, bir Demultiplex Header ile başlar. Bu başlık 4 bayttır ve sürüm, hizmet tipi, fonksiyon kodu gibi alanları taşır. Fonksiyon kodu, mesajın türünü belirler. Örneğin, Discover, Hello veya Emit mesajları bu alanla ayrılır.
Protokolün gövdesi ise TLV (Type-Length-Value) formatındadır. Bu format, veri paketlemenin en esnek yollarından biridir. Her TLV bloğu, bir tip kodu, bir uzunluk değeri ve asıl veriyi taşır. Bu sayede protokol, farklı bilgi türlerini aynı çerçeve içinde taşıyabilir.
Gerçek Dünya Deneyimi ve Donanım Uyumluluğu
LLTD Tanımı ve Açılımı: Link Layer Topology Discovery Ne Demek?
İngilizce açılımı ‘Link Layer Topology Discovery’ olan bu protokolün Türkçe karşılığı ‘Bağlantı Katmanı Topoloji Keşfi’dir. Tanımı gereği, OSI modelinin 2. katmanında, yani veri bağlantı katmanında çalışır. Bu katman, MAC adresleri ve Ethernet çerçeveleri ile ilgilenir.
MAC adresleri veri bağlantı katmanında kritik rol oynuyor. ARP adres çözümlemesi IP adresini MAC adresine eşliyor. Daha sonra, yerel ağda cihazlar birbirini böyle buluyor.
‘Bağlantı katmanı’ ifadesi, protokolün IP veya TCP gibi üst katmanlara bağımlı olmadığını gösterir. Yani protokol, sadece Ethernet çerçevesi formatını kullanır. Kendi veri yapısını bu çerçevenin içine gömer. Bu tasarım, protokolü hem hızlı hem de hafif kılar.
‘Topoloji’ kelimesi ise ağın yapısal düzenini ifade eder. Hangi cihaz, hangi cihaza bağlıdır? Aradaki mesafe ve bağlantı tipi nedir? LLTD protokol, bu soruların cevabını veri paketleri aracılığıyla toplar. Sonuçta ortaya bir ağ şeması çıkar.
‘Keşif’ kelimesi de protokolün temel işlevini özetler. Cihazlar, özel mesajlar göndererek birbirini bulur. LLTD, bu mesajları belirli bir ikili formatta kodlar. Alıcı cihaz, bu formatı çözer ve yanıt üretir. Süreç, tamamen veri alışverişi üzerine kuruludur.
LLTD, Microsoft’un ‘Windows Rally’ teknoloji paketinin bir parçası olarak doğdu. Spesifikasyonları halka açıktır ve MS-LLTD belgeleri üzerinden erişilebilir. Bu sayede, üçüncü parti donanım üreticileri de kendi cihazlarına bu protokolü entegre edebilir. Örneğin, bazı yazıcı üreticileri (Brother, Epson gibi) bunu destekler.
LLTD Ne İşe Yarar? Temel Kullanım Alanları ve Faydaları
Bu protokolün sağladığı faydalar, doğrudan veri formatı ve paket yapısı ile ilgilidir. Protokol, her cihazın kendini tanıtan bir mesaj üretmesini sağlar. Bu mesaj, cihazın MAC adresini, IP adresini ve cihaz tipini taşır. Alıcı taraf, bu veriyi işleyerek bir harita oluşturur.
İşte LLTD protokolün somut faydaları:
- Otomatik Cihaz Keşfi: Ağdaki cihazlar, kendi varlıklarını özel bir veri paketiyle duyurur. Üstelik sistem yöneticisi manuel bir liste tutmak zorunda kalmaz.
- Yapılandırılmış Veri Formatı: Her cihaz bilgisini, TLV blokları halinde kodlar. Bu format, hem okunabilir hem de genişletilebilir bir yapı sunar.
- Çerçeve Seviyesinde Doğrulama: Paketlerin Ethertype alanı sayesinde, alıcı taraf paketin geçerli olup olmadığını anında anlar.
- Ağ Şeması Oluşturma: Topladığı verileri, görsel bir haritaya dönüştürür. Bu harita, cihazların fiziksel ve mantıksal konumunu gösterir.
- Protokol Uzantıları: QoS uzantıları sayesinde, bant genişliği verisini de aynı çerçeve içinde taşır. Bu, protokolün çok yönlülüğünü gösterir.
Öte yandan, LLTD protokolü bir yönetim protokolü değildir. Yani SNMP ağ analizi gibi cihaz yapılandırması yapmaz. Sadece veri toplar ve paketleri biçimlendirir. Bu nedenle, bir SNMP alternatifi olarak görülmemelidir. Görevi, keşif ve veri kodlamadır.
Multicast Desteği ve Trafik Verimliliği
Protokolün bir diğer önemli özelliği, çok noktaya yayın (multicast) desteğidir. Bazı mesajları, tek bir cihaza değil, belirli bir gruba gönderir. Bu, ağdaki tüm cihazlara tek tek mesaj gönderme külfetini ortadan kaldırır. Böylece ağ trafiği verimli kullanır.
LLTD multicast mesajları yerel ağda trafiği azaltıyor. IGMP çok noktaya yayın yönetimi bu grupları düzenliyor. Şöyle bir durum hayal edin, bir yazıcı gruba katılmak istiyor. IGMP yönlendiriciye üyelik bilgisini iletiyor. Böylece gereksiz yayınlar ağa yayılmıyor.
LLTD Nasıl Çalışır? Protokol Mimarisi ve Çalışma Prensipleri

Bir protokolü anlamanın en iyi yolu, mesaj akışını ve paket formatını incelemektir. Bu protokol, tamamen olay tabanlı bir mekanizma üzerine kuruludur. Bir cihaz ağa katıldığında, kendi varlığını duyuran bir çerçeve gönderir. Alıcı cihazlar bu çerçeveyi alır ve yanıt üretir.
Protokolün kalbinde, ‘Mapper‘ ve ‘Responder‘ olarak adlandırılan iki temel rol bulunur. Mapper, keşif mesajını başlatan taraftır. Genellikle bir Windows bilgisayarıdır. Responder ise, bu mesaja yanıt veren cihazdır. Bu roller, veri alışverişinin yönünü belirler.
Öncelikle, Mapper ağa bir keşif çerçevesi yayınlar. Buna ‘Discover’ mesajı denir. Bu mesaj, bir yayın (broadcast) çerçevesidir. Hedef MAC adresi FF:FF:FF:FF:FF:FF olarak tanımlar. Böylece ağdaki tüm cihazlar bu çerçeveyi alır.
Ardından, Responder rolüne sahip cihazlar bu mesaja cevap verir. Cevap çerçevesi, cihazın veri bloğunu içerir. Bu blok, cihaz adı, MAC adresi ve IP adresi gibi bilgileri taşır. Veri, TLV formatındadır ve her bilgi parçası ayrı bir TLV bloğudur.
BBu ilk temastan sonra, daha detaylı bilgi toplamak için tek noktaya yayın (unicast) çerçeveleri gönderir. Bu aşamada, ‘Emit’, ‘Train’ ve ‘Probe’ gibi mesaj tipleri kullanır. Her mesaj, belirli bir veri alanını talep eder. Örneğin, ‘Probe’ mesajı, cihazın sinyal gücü verisini sorgular.
Tüm bu süreç, milisaniyeler içinde tamamlar. Çünkü çerçeveleri, ham Ethernet seviyesinde taşır. IP yığınına uğramaz, yönlendirme tablosuna bakmaz. Bu, protokolü son derece hızlı kılar. Ayrıca, protokol gereksiz trafiği önlemek için zamanlayıcılar içerir.
Sorun Giderme ve Ağ Analizi
eth.type == 0x88d9 filtresini kullanın. Eğer hiç paket yakalayamıyorsanız, protokol büyük olasılıkla devre dışıdır. Eğer paket yakalıyorsanız ama cevap yoksa, Responder tarafında bir sorun vardır. Bu iki adım, sorunu hızla daraltmanızı sağlar.NOT: Wireshark’ta LLTD paketi yakalayamadığınızda ICMP hata mesajları yol gösteriyor. ICMP protokolü ağ katmanında tanılama yapıyor. Buradan devam edersek, ping ve traceroute çıktıları sorunu daraltıyor.
LLTD Hangi Katmanda Çalışır? OSI Katman 2 ve Veri Bağlantı Katmanı İlişkisi
Bu protokolün en belirleyici özelliği, OSI modelinin 2. katmanında çalışmasıdır. Bu katmanı, veri bağlantı katmanı olarak biliyoruz. Görevi, ağdaki cihazlar arasında çerçeve aktarımını sağlamaktır. Bu katmanda IP adresi değil, MAC adresi rol oynar.
Peki, bu ne anlama geliyor? Bir cihazın IP adresi olmasa bile, LLTD üzerinden keşfedebilirsiniz. Örneğin, henüz DHCP sunucusundan IP almamış bir yazıcı, yine de ağ haritasında görünebilir. Bu, protokolün veri formatının IP’den bağımsız olmasından kaynaklanır.
Bu protokol, hem kablolu (Ethernet 802.3) hem de kablosuz (Wi-Fi 802.11) ağlarda çalışır. Kablosuz ağlarda, çerçeve formatı biraz farklıdır. Ancak protokolün veri yapısı aynı kalır. Sadece fiziksel taşıma katmanı değişir. Bu esneklik, protokolün her ortamda kullanılmasını sağlar.
Bir diğer önemli nokta, protokolün tek bir yayın alanı (broadcast domain) ile sınırlı olmasıdır. Yani, bir yönlendirici tarafından ayrılmış farklı alt ağlardaki cihazlar, doğrudan LLTD üzerinden birbirini keşfedemez. Bu, protokolün veri formatının yönlendirilemez olmasından kaynaklanır.
Bu sınırlama, aslında bir tasarım tercihidir. Protokolü, sadece yerel segmentte çalışacak şekilde optimize ettiler. Bu sayede, çerçeve boyutu küçük kalır ve işlem yükü azalır. Kurumsal ağlarda, bu durumu bir planlama kriteri olarak dikkate almalısınız.
LLTD Mapper ve Responder Rolleri: Kim Ne Yapar?
Bu protokolün işleyişini anlamak için, rollerin net bir şekilde ayrılması gerekir. Her rol, farklı bir mesaj formatı üretir ve farklı bir veri akışı yönetir. İşte iki ana karakterin görev tanımları:
| Rol | Sorumluluk | Ürettiği Mesaj Formatı | Veri Yönü |
|---|---|---|---|
| LLTD Mapper | Ağ topolojisini keşfetmek için sorgu çerçeveleri üretir. | Discover, Emit, Train, Probe, Query | Giden (Outbound) |
| LLTD Responder | Gelen sorgulara veri bloğu içeren yanıtlar gönderir. | Hello, QueryResp, Ack, Charge | Gelen (Inbound) |
Mapper rolü, genellikle bir kullanıcı Ağ Haritası’nı açtığında etkinleşir. Mapper, ağdaki tüm Responder’ları bulmak için broadcast çerçeveleri gönderir. Ardından, her bir Responder’dan aldığı TLV bloklarını birleştirir. Sonuçta, ağın veri modelini oluşturur.
Responder rolü ise, cihazın ağa bağlı olduğu sürece arka planda çalışır. Bir Responder, kendisine gelen çerçeveleri dinler. Gelen çerçevenin fonksiyon kodunu okur. Kod ‘Discover’ ise, bir ‘Hello’ yanıtı üretir. Bu yanıt, cihazın veri bloğunu içerir.
Bu iki rol, aynı cihaz üzerinde aynı anda çalışabilir. Örneğin, bir Windows PC hem Mapper hem de Responder olabilir. Bu esneklik, protokolün dinamik ağ ortamlarına uyum sağlamasını kolaylaştırır. Ayrıca, protokolün eş zamanlı rol yürütme yeteneğini gösterir.
LLTD Mesaj Türleri: Discover, Hello, Emit, Train, Probe ve Diğerleri
Protokolün işleyişi, belirli mesaj tiplerinin belirli bir sırayla gönderilmesine dayanır. Her mesajı, Demultiplex Header içindeki fonksiyon koduyla tanımlar. Bu kod, mesajın amacını ve beklenen yanıtı belirler. İşte en önemli mesaj tipleri:
| Mesaj | Fonksiyon Kodu | Yön | Amaç |
|---|---|---|---|
| Discover | 0x00 | Mapper → Broadcast | Ağdaki tüm Responder’ları bulmak için yayın yapar. |
| Hello | 0x01 | Responder → Mapper | Keşif mesajına cevap verir, TLV bloğu içerir. |
| Emit | 0x02 | Mapper → Unicast | Belirli bir cihazdan ek veri talep eder. |
| Train | 0x03 | Mapper → Unicast | Cihazın desteklediği özellikleri öğrenir. |
| Probe | 0x04 | Mapper → Unicast | Sinyal gücü veya bağlantı hızı metriklerini sorgular. |
| Ack | 0x05 | Responder → Mapper | Alınan mesajları onaylar. |
| Query | 0x06 | Mapper → Unicast | Belirli bir TLV verisi için sorgu yapar. |
| QueryResp | 0x07 | Responder → Mapper | Sorguya istenen TLV verisiyle cevap verir. |
| Reset | 0x08 | Mapper → Broadcast | Keşif oturumunu sıfırlar. |
| Charge | 0x09 | Responder → Mapper | Kaynak talep eder (bant genişliği gibi). |
| Flat | 0x0A | Mapper → Broadcast | Ağın düz topoloji olduğunu bildirir. |
| QueryLargeTlv | 0x0B | Mapper → Unicast | Büyük boyutlu TLV verileri için sorgu yapar. |
Bu mesajların her birini, belirli bir ikili formatta kodlar. Mesaj yapısını, MS-LLTD spesifikasyonunda ayrıntılı olarak tanımlarlar. Bu sayede, farklı üreticilerin cihazları birbiriyle uyumlu çalışabilir. Örneğin, bir Brother yazıcısı, bir Windows PC’den gelen Discover mesajını doğru yorumlar.
LLTD Paket Yapısı ve Ethernet Çerçevesi: Teknik Detaylar
Bir ağ mühendisi için protokolün sadece ne yaptığı değil, nasıl kodlandığı da kritiktir. Bu protokol, ham Ethernet çerçeveleri üzerinden çalışır. Yani, TCP/IP yığınına ihtiyaç duymaz. Bu tasarım, onu hem hızlı hem de hafif kılar. Ancak paket yapısını anlamayı da zorunlu hale getirir.
Bir LLTD paketi, standart bir Ethernet başlığı ile başlar. Bu başlıkta, hedef ve kaynak MAC adresleri bulunur. Ardından Ethertype alanı gelir. LLTD için ayrılmış özel Ethertype değeri 0x88D9‘dur. Bu değer, ağ anahtarlarının paketi tanımasını sağlar.
Ethernet başlığından sonra, protokole özgü bir Demultiplex Header gelir. Bu başlık 4 bayt uzunluğundadır. İçinde sürüm, hizmet tipi (Type of Service), fonksiyon ve rezerve edilmiş alanlar bulunur. Bu başlık, alınan paketin hangi türde bir mesaj olduğunu belirler.
Demultiplex Header’ın ardından, mesajın gövdesi gelir. Bu gövde, TLV (Type-Length-Value) yapısında kodlanmış veriler içerir. Her bir TLV, belirli bir bilgi parçasını taşır. Örneğin, bir TLV cihazın MAC adresini taşırken, bir diğeri IP adresini taşır. Bu yapı, protokolü esnek ve genişletilebilir kılar.
LLTD Ethertype 0x88D9 ve Ethernet Frame Yapısı
Bir ağ paketini incelerken, ilk bakılacak yer Ethertype alanıdır. Bu alan, çerçevenin hangi üst katman protokolüne ait olduğunu belirtir. LLTD için bu değer 0x88D9’dur. Bu değeri gördüğünüzde, paketin bir topoloji keşif çerçevesi olduğunu anlarsınız.
İşte tipik bir LLTD Ethernet çerçevesinin veri formatı:
| Alan | Uzunluk | Açıklama | Örnek Değer |
|---|---|---|---|
| Hedef MAC Adresi | 6 bayt | Paketin gönderileceği cihazın MAC adresi. Yayın mesajlarında FF:FF:FF:FF:FF:FF olur. | FF:FF:FF:FF:FF:FF |
| Kaynak MAC Adresi | 6 bayt | Paketi gönderen cihazın MAC adresi. | 00:1A:2B:3C:4D:5E |
| Ethertype | 2 bayt | Protokol tanımlayıcı. LLTD için her zaman 0x88D9’dur. | 0x88D9 |
| Demultiplex Header | 4 bayt | Sürüm, hizmet tipi, fonksiyon ve rezerve alanlarını içerir. | 01 00 00 01 |
| Mesaj Gövdesi (TLV’ler) | Değişken | Cihaz verilerini taşıyan TLV (Type-Length-Value) blokları. | … |
| FCS (Frame Check Sequence) | 4 bayt | Hata kontrolü için kullanılan CRC değeri. Ethernet donanımı otomatik ekler. | … |
Bu yapıyı anlamak, ağ paketlerini analiz ederken büyük avantaj sağlar. Örneğin, bir Wireshark yakalamasında bu Ethertype’ı filtreleyerek sadece bu protokolün trafiğini izleyebilirsiniz. Bu, ağdaki keşif aktivitesini anlamak için kritik bir adımdır.
Demultiplex Header içindeki sürüm alanı, protokolün hangi revizyonunun kullanıldığını gösterir. Hizmet tipi (Type of Service) alanı ise, paketin öncelik seviyesini belirtir. Bu alan, QoS uzantıları ile birlikte kullanıldığında daha da önem kazanır. Fonksiyon alanı ise mesaj türünü belirler.
LLTD TLV Yapısı ve Veri Kodlama
TLV (Type-Length-Value), ağ protokollerinde sık kullanılan bir veri kodlama yöntemidir. LLTD de bu yapıyı benimser. Her bir TLV, üç bölümden oluşur: Tip (Type), Uzunluk (Length) ve Değer (Value). Tip alanı, taşınan verinin ne olduğunu belirtir.
Uzunluk alanı, Değer alanının kaç bayt olduğunu söyler. Değer alanı ise asıl veriyi içerir. Örneğin, bir cihazın MAC adresini taşıyan bir TLV düşünün. Tip alanı ‘MAC Adresi’ anlamına gelen bir sayı olur. Uzunluk alanı 6 olur. Değer alanı ise 6 baytlık MAC adresini içerir.
Bu yapı, protokolün genişletilebilir olmasını sağlar. Yeni bir bilgi türü eklemek istediğinizde, sadece yeni bir Tip değeri tanımlarsınız. Mevcut paket yapısı değişmez. Bu sayede protokol, gelecekteki ihtiyaçlara uyum sağlayabilir. Örneğin IPv6 desteğini bu yöntemle eklersiniz.
MS-LLTD spesifikasyonunda onlarca farklı TLV tipi vardır. Bunlar arasında cihaz adı, IP adresi (IPv4 ve IPv6) yer alır. Ayrıca sinyal gücü, bant genişliği ve QoS yetenekleri de bulunur. Ayrıca desteklenen QoS yetenekleri de bulunur. Bu zengin TLV seti sayesinde protokol, sadece bir harita çizmez. Aynı zamanda ağın durumu hakkında da veri toplar.
Bir TLV’nin Değer alanı, iç içe TLV’ler de içerebilir. Bu, hiyerarşik veri yapıları oluşturmayı mümkün kılar. Örneğin, bir ‘Cihaz Bilgisi’ TLV’si, kendi içinde ‘İşletim Sistemi’ ve ‘Donanım’ gibi alt TLV’ler barındırabilir. Bu sayede protokol, hem esnek hem de organize bir veri modeli sunar.
Wireshark ile LLTD Paket Analizi: Filtreleme Komutları
Ağ trafiğini analiz etmek, bir ağ mühendisinin en önemli becerilerinden biridir. Wireshark, bu konuda en güçlü aracınızdır. Bu protokolün paketlerini yakalamak ve analiz etmek için şu adımları izleyebilirsiniz:
- Wireshark’ı Başlatın: Wireshark’ı yönetici olarak çalıştırın. İzlemek istediğiniz ağ arayüzünü (Ethernet veya Wi-Fi) seçin.
- Yakalamayı Başlatın: Ağ arayüzüne çift tıklayarak paket yakalamayı başlatın. Veya ‘Capture’ menüsünden ‘Start’ seçeneğini kullanın.
- Filtre Uygulayın: Filtre çubuğuna
eth.type == 0x88d9yazın ve Enter’a basın. Bu, sadece LLTD paketlerini gösterecektir. - Alternatif Filtre:
ether proto 0x88d9filtresi de aynı sonucu verir. Yani bu iki komut eşdeğerdir. - Paketleri İnceleyin: Yakalanan paketlerden birine tıklayın. Alt kısımdaki detay penceresinde katmanlı yapıyı göreceksiniz. Ethernet II başlığını genişletin ve ‘Type: LLTD (0x88d9)’ yazdığını doğrulayın.
- TLV Bloklarını İnceleyin: ‘Link Layer Topology Discovery’ katmanını genişletin. Mesaj tipini, sürümünü ve içerdiği TLV bloklarını görebilirsiniz.
- Belirli Mesajları Filtreleyin: Sadece ‘Discover’ mesajlarını görmek için
lltd.function == 0filtresini kullanın. ‘Hello’ mesajları içinlltd.function == 1filtresi işinize yarar.
Bu adımları izleyerek, ağınızdaki protokol trafiğini detaylı bir şekilde analiz edebilirsiniz. Bu, hem sorun giderme hem de veri formatı doğrulaması için son derece değerlidir. Özellikle şüpheli bir keşif aktivitesi fark ettiğinizde, bu filtreler sayesinde hızla ilgili paketleri izole edebilirsiniz.
LLTD vs LLDP vs CDP: Katman 2 Keşif Protokollerinin Karşılaştırması

Ağ dünyasında topoloji keşfi denince akla birden fazla protokol gelir. Bunların başında LLDP ve CDP gelir. Peki, bu protokoller LLTD ile nasıl bir ilişki içindedir? Aslında, her biri farklı bir veri formatı ve farklı bir kullanım amacı taşır. Bu bölümde, bu üç protokolü karşılaştırarak veri yapılarını inceleyeceğiz.
Öncelikle LLDP açık bir standarttır (IEEE 802.1AB). Cisco, Juniper ve HP gibi üreticiler bunu destekler. Ayrıca ağ cihazları arasında komşuluk bilgisi paylaşmak için LLTD protokolü kullanırsınız. Sistem kendine ait bir TLV yapısı barındırır.
CDP (Cisco Discovery Protocol) ise Cisco’ya özel bir protokoldür. Sadece Cisco cihazları arasında çalışır. LLDP’ye benzer bir amaca hizmet eder, ancak tescilli bir yapıya sahiptir. Üstelik kendi veri kodlama yöntemini kullanır.
LLTD ise daha çok uç nokta keşfine odaklanır. Bir PC’nin, ağdaki yazıcıları, diğer PC’leri ve NAS cihazlarını bulmasını sağlar. Yani, ağın ‘son kullanıcı’ tarafında çalışır. Veri formatı, TLV tabanlı olsa da LLDP’den farklıdır.
LLTD ve LLDP Arasındaki Farklar: Tescilli vs Açık Standart
LLDP ve LLTD arasındaki en temel fark, standartlaşma durumudur. LLDP, IEEE tarafından standartlaştırılmış açık bir protokoldür. Bu, farklı üreticilerin cihazlarının uyumlu çalışmasını sağlar. Bu protokol ise Microsoft tarafından geliştirilmiş tescilli bir protokoldür.
Ancak, LLTD protokolün spesifikasyonları da halka açıktır. MS-LLTD belgeleri, Microsoft Learn üzerinden erişilebilir durumdadır. Bu sayede, üçüncü parti donanım üreticileri de kendi cihazlarına bunu entegre edebilir. Yani, teknik olarak açık bir spesifikasyondur.
Kullanım amacı açısından da farklılıklar vardır. LLDP, ağ altyapısı cihazları (switch, router) arasında fiziksel bağlantı bilgisini paylaşır. Bu protokol ise uç noktaların (PC, yazıcı) birbirini keşfetmesini sağlar. Yani, LLDP ‘ağın iskeletini’ haritalarken, ‘ağın etini’ haritalar.
Bir diğer fark, Ethertype değerleridir. LLDP için Ethertype 0x88CC’dir. LLTD için ise Ethertype 0x88D9’dur. Bu iki farklı değer, ağ anahtarının paketi doğru işleyicisine yönlendirmesini sağlar. Ayrıca, TLV yapıları da birbirinden farklıdır.
LLTD ve CDP Karşılaştırması: Cisco vs Microsoft Ekosistemi
CDP, Cisco cihazları arasında çalışan bir protokoldür. Cisco switch’ler, router’lar ve IP telefonlar arasında komşuluk bilgisi paylaşır. Kendi tescilli veri formatını kullanır. Bu protokol ise Microsoft ekosisteminde, Windows PC’ler ve diğer uç noktalar arasında çalışır.
CDP’yi, daha çok ağ yöneticileri kullanır. Cihazların hangi portlara bağlı olduğunu, VLAN bilgilerini ve güç tüketimini (PoE) öğrenmek için idealdir. LLTD ise son kullanıcı deneyimini iyileştirmek içindir. Ağ Haritası sayesinde kullanıcılar, ağdaki cihazları görsel olarak görür.
Veri formatı açısından bakıldığında, CDP daha karmaşık bir yapıya sahiptir. Cisco’nun kendi TLV tanımlarını kullanır. LLTD ise daha basit ve standart bir TLV yapısını benimser. Bu, protokolün daha hafif olmasını sağlar. Ancak, CDP daha zengin bir veri seti sunar.
Her iki protokol de kendi ekosistemlerinde etkilidir. Cisco ağlarında CDP vazgeçilmezdir. Microsoft ağlarında ise LLTD yapısı öne çıkar. Karma bir ağda, her iki protokolü birlikte kullanmak mümkündür. Ancak, her birinin veri formatını ayrı ayrı anlamak gerekir.
LLTD, LLDP ve CDP Karşılaştırma Tablosu
Aşağıdaki tablo, üç protokolün temel veri formatı özelliklerini yan yana koyar:
| Özellik | LLTD | LLDP | CDP |
|---|---|---|---|
| Standart | Microsoft Spesifikasyonu (MS-LLTD) | IEEE 802.1AB (Açık Standart) | Cisco Tescilli |
| OSI Katmanı | Katman 2 (Veri Bağlantı) | Katman 2 (Veri Bağlantı) | Katman 2 (Veri Bağlantı) |
| Ethertype | 0x88D9 | 0x88CC | SNAP (0x2000) |
| TLV Yapısı | Evet, standart TLV | Evet, standart TLV | Evet, tescilli TLV |
| Ana Amaç | Uç nokta keşfi ve haritalama | Ağ altyapısı komşuluk keşfi | Cisco cihaz komşuluk keşfi |
| Kapsam | Tek yayın alanı (Broadcast Domain) | Yerel bağlantı (Link-local) | Yerel bağlantı |
| Mesaj Kodlaması | Demultiplex Header + TLV | TLV-only | TLV with SNAP |
| Yaygınlık | Windows sistemlerde varsayılan | Tüm ağ cihazlarında yaygın | Sadece Cisco cihazlarında |
Bu tablodan da anlaşılacağı üzere, her protokolün kendine özgü bir veri formatı vardır. Ağınızda hangi protokolü kullanacağınıza, cihaz envanterinize ve yönetim ihtiyaçlarınıza göre karar vermelisiniz.
Örneğin tamamen Cisco tabanlı bir ağda CDP vazgeçilmezdir. Dolayısıyla heterojen bir ağda LLDP ile bu protokolü birlikte kullanırsınız.
Güvenlik Açıkları ve Riskler: CVE Analizi ve Saldırı Yüzeyi

Bu protokol masum bir keşif aracı gibi görünür. Ancak yine de ciddi güvenlik riskleri barındırır. Özellikle paket ayrıştırma (parsing) aşamasındaki veri formatı hataları birer saldırı vektörü oluşturur. Şimdi, protokolün veri yapısından kaynaklanan zafiyetleri inceleyeceğiz.
2026 yılı, LLTD için kritik bir yıl oldu. Eylül ayında yayınlanan CVE-2026-69732, CVSS skoru 8.1 olan bir heap tabanlı buffer overflow açığıdır. Bu açık, veri kodlama aşamasındaki bir sınır kontrolü hatasından kaynaklanır. Saldırgan, özel hazırlanmış bir paket göndererek belleği bozar.
Bu tür açıklar, protokolün ne kadar dikkatli yönetilmesi gerektiğini gösteriyor. Özellikle kurumsal ağlarda, bu protokolün gereksiz yere açık bırakılması büyük bir risk oluşturur. Ancak unutmayın: Bu zafiyetler, protokolün veri formatı ve paket ayrıştırma süreçleriyle ilgilidir. Yani, konu tamamen veri kodlama güvenliğidir.
CVE-2024-30075: Heap Tabanlı Buffer Overflow ve Uzaktan Kod Yürütme
CVE-2024-30075, bu protokolde keşfedilen en ciddi veri formatı açıklarından biridir. Bu açık, heap tabanlı bir buffer overflow (CWE-122) sorunudur. Sorun, TLV ayrıştırma kodundaki uzunluk doğrulamasının eksik olmasından kaynaklanır. Saldırgan, aşırı uzun bir TLV bloğu göndererek belleği bozar.
Bu açığın en tehlikeli yanı, kimlik doğrulaması gerektirmemesidir. Yani, ağa erişimi olan herhangi bir saldırgan, bu veri formatı hatasını kullanarak kod çalıştırabilir. Saldırı vektörü ağ (AV:N) olduğu için, saldırganın fiziksel olarak yakın olması gerekmez. Aynı yayın alanında olması yeterlidir.
Microsoft, bu açığı Eylül 2026’da yayınladığı bir güvenlik güncellemesiyle yamadı. Ancak, yama uygulanmayan sistemler hala risk altında. Bu nedenle, sistem yöneticilerinin bu güncellemeyi derhal uygulaması gerekir. Özellikle protokol hizmetlerinin etkin olduğu sunucuları öncelikli olarak güncellemelisiniz.
Bu açığın istismar edilmesi durumunda, saldırgan sistemde tam yetkiyle (SYSTEM seviyesinde) kod çalıştırabilir. Bu, ağdaki yanal hareket (lateral movement) için bir sıçrama noktası oluşturur. Saldırgan, ele geçirdiği sistem üzerinden diğer sistemlere yayılabilir. Ancak bu noktada sorun, yine protokolün veri ayrıştırma kodundadır.
CVE-2007-1528: Mapper Spoofing ve Sahte Köprü İlişkileri
LLTD güvenlik tarihindeki en eski açıklardan biri olan CVE-2007-1528, protokolün mesaj formatındaki bir zayıflığı gösterir. Bu açık, bir saldırganın kendini Mapper olarak tanıtmasına olanak tanır. Saldırgan, sahte köprü (bridge) ilişkileri oluşturur.
Saldırgan, ağa sahte Discover mesajları göndererek Responder’ları kandırır. Responder’lar sahte mesajlara cevap verir. Böylece MAC, IP ve cihaz adı gibi gizli bilgileri saldırgana iletirler. Bu verileri, daha sonra daha sofistike saldırılar için kullanabilirler. Sorun, protokolün mesaj formatında kimlik doğrulama alanı olmamasıdır.
Bu açığın en önemli yanı, protokolün doğası gereği kimlik doğrulama mekanizmasının olmamasıdır. Protokol, tasarımı gereği ‘güvenilir ağ’ varsayımıyla çalışır. Yani, mesaj formatında bir imza veya doğrulama kodu bulunmaz. Bu nedenle, bir saldırgan kendini meşru bir Mapper olarak kolayca gizleyebilir.
Bu açık, 2007’de keşfedilmesine rağmen hala tam olarak kapatılamamıştır. Çünkü sorun, protokolün temel mesaj yapısında yatmaktadır.
Microsoft, bazı hafifletme önlemleri sunsa da, protokolün doğası gereği bu tür spoofing saldırılarına açıktır. Bu nedenle, güvenlik bilincinin yüksek olduğu ortamlarda protokolü devre dışı bırakmanızı öneririm.
Saldırı Yüzeyi: Trafik Amplifikasyonu, DoS ve MITM Riskleri
Protokolün sunduğu saldırı yüzeyi, sadece buffer overflow veya spoofing ile sınırlı değildir. Protokolün yayın tabanlı yapısı, bir dizi farklı saldırı tekniğine kapı aralar. İşte bu tekniklerden en önemlileri:
- Trafik Amplifikasyonu: Saldırgan, sahte kaynak MAC adresiyle Discover mesajları gönderir. Ağdaki tüm Responder’lar cevap verir. Bu, ağda gereksiz bir yayın fırtınasına neden olur.
- Hizmet Reddi (DoS): Aşırı miktarda LLTD mesajı göndererek, ağdaki cihazların kaynaklarını tüketebilir. Özellikle düşük işlem gücüne sahip IoT cihazları bu saldırıdan etkilenir.
- Ortadaki Adam (MITM) Saldırısı: Saldırgan, kendini Mapper veya Responder olarak tanıtır. İki cihaz arasındaki iletişimi ele geçirebilir. Bu sayede ağ trafiğini dinleyebilir veya değiştirebilir.
- Veri İfşası: Protokol mesajları, cihazların MAC adreslerini, IP adreslerini ve bazen işletim sistemi bilgilerini açıkça taşır. Bu veriler, bir saldırganın ağı haritalaması için değerlidir.
- Sahte Cihaz Enjeksiyonu: Saldırgan, ağa sahte Responder’lar ekleyerek Ağ Haritası’nı yanıltabilir. Bu, kullanıcıların yanlış cihazlara bağlanmasına neden olabilir.
Bu saldırı tekniklerine karşı savunma stratejileri geliştirmek için, öncelikle ağınızdaki protokol trafiğini izlemeniz gerekir. Saldırı tespit sistemleri (IDS) için özel kurallar yazarak anormal aktiviteyi tespit edebilirsiniz. Örneğin, normalden çok daha fazla sayıda Discover mesajı bir amplifikasyon saldırısının işareti olabilir.
Ayrıca, ağ segmentasyonu (VLAN) kullanarak kritik sunucuları ve cihazları bu protokolün trafiğinden izole edebilirsiniz. Bu, bir saldırganın ele geçirdiği bir cihaz üzerinden yanal hareket etmesini zorlaştırır.
Bu protokol yerel ağda bilgi sızdırır. Dolayısıyla sıfır güven sistemini kullanan şirketler, bu protokolü varsayılan olarak kapatmalıdır.
LLTD Nasıl Kapatılır? Grup İlkesi, Kayıt Defteri ve Netsh Yöntemleri
Veri yapısı güvenliğinizi tehdit edebilir veya hızı düşürebilir. Bu sebeple bazen bu protokolü kapatmanız gerekir. Neyse ki, Windows işletim sistemleri LLTD protokolü kapatmak için birden fazla yöntem sunar.
Hangi yöntemi seçerseniz seçin, öncelikle bu değişikliğin ağınızdaki etkilerini anlamanız gerekir. Örneğin, protokolü kapatırsanız, Windows Ağ Haritası artık çalışmayabilir. Bu nedenle, bu kararı vermeden önce kullanıcılarınızın bu özelliğe ihtiyacı olup olmadığını değerlendirmelisiniz.
Kurumsal ortamlarda en yaygın yöntem Grup İlkesi (Group Policy) kullanmaktır. Bu yöntem, yüzlerce bilgisayarda tek merkezden ayar değiştirmenizi sağlar. Evde veya küçük ofiste kayıt defterini düzenleyebilirsiniz. Alternatif olarak komut satırı araçlarını da kullanabilirsiniz.
Grup İlkesi ile LLTD Kapatma: ADMX_LinkLayerTopologyDiscovery
Grup İlkesi, özellikle Active Directory ortamlarında, bu protokolü merkezi olarak kapatmanın en etkili yoludur. İşte adım adım uygulama:
- GPMC’yi Açın: ‘Group Policy Management Console’ (GPMC) aracını açın. Yeni bir GPO oluşturun veya mevcut bir GPO’yu düzenleyin.
- İlgili İlke Yolunu Bulun: GPO düzenleyicisinde şu yolu izleyin:
Computer Configuration → Policies → Administrative Templates → Network → Link Layer Topology Discovery. - Mapper I/O’yu Devre Dışı Bırakın: ‘Turn on Mapper I/O (LLTDIO) driver’ ilkesine çift tıklayın. Açılan pencerede ‘Disabled’ seçeneğini işaretleyin ve ‘OK’ butonuna basın.
- Responder’ı Devre Dışı Bırakın: ‘Turn on Responder (RSPNDR) driver’ ilkesine çift tıklayın. ‘Disabled’ seçeneğini işaretleyin ve ‘OK’ butonuna basın.
- GPO’yu Bağlayın: Oluşturduğunuz GPO’yu etkilenmesini istediğiniz OU’ya (Organizational Unit) bağlayın. Değişikliklerin uygulanması için
gpupdate /forcekomutunu çalıştırın.
Bu adımları izleyerek, etki alanındaki tüm bilgisayarlarda bu protokolü merkezi olarak devre dışı bırakabilirsiniz. İlke ayarları, kayıt defterinde HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\LLTD altında saklanır. EnableLLTDIO ve EnableRspndr DWORD değerleri, ilkenin durumunu yansıtır (0 = Devre dışı, 1 = Etkin).
Kayıt Defteri ile LLTD Devre Dışı Bırakma: lltdio ve lltdsvc
Grup İlkesi kullanma şansınız yoksa, kayıt defterini manuel olarak düzenleyerek de bu protokolü kapatabilirsiniz. Bu yöntem, tek bir bilgisayar için hızlı bir çözüm sunar. Ancak yanlış bir düzenleme sisteminize zarar verebileceği için dikkatli olmalısınız.
İşte adım adım kayıt defteri düzenlemesi:
- Regedit’i Açın: Başlat menüsüne
regedityazın ve Enter’a basın. Yönetici izni isteyen UAC uyarısını onaylayın. - İlgili Anahtara Gidin: Sol taraftaki ağaçtan şu yolu izleyin:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lltdio. - Start Değerini Değiştirin: Sağ taraftaki pencerede ‘Start’ adlı DWORD değerine çift tıklayın. Değer verisini ‘4’ (Devre Dışı) olarak ayarlayın ve ‘OK’ butonuna basın.
- Responder Servisini Bulun: Aynı yolu
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rspndriçin tekrarlayın. ‘Start’ değerini yine ‘4’ yapın. - Yeniden Başlatın: Değişikliklerin etkili olması için bilgisayarı yeniden başlatın. Alternatif olarak,
net stop lltdiovenet stop rspndrkomutlarıyla servisleri durdurabilirsiniz.
Kayıt defteri düzenlemesi, özellikle tek seferlik müdahaleler için pratiktir. Ancak bu ayarı geri almak isteyebilirsiniz. Bu durumda ‘Start’ değerini tekrar ‘2’ veya ‘3’ yapmalısınız. Kurumsal ortamlarda, bu tür manuel müdahaleler yerine her zaman Grup İlkesi’ni tercih etmelisiniz.
LLTD Kapatma Kararı: Ne Zaman Gerekli, Ne Zaman Değil?
LLTD kapatmak her zaman doğru bir karar olmayabilir. Bu kararı verirken, ağınızın ihtiyaçlarını ve risk profilini dikkatlice değerlendirmelisiniz. İşte bu kararı vermenize yardımcı olacak bir kontrol listesi:
- Kapatmanız Gereken Durumlar: Yüksek güvenlik gerektiren kurumsal ağları korumalısınız. Ayrıca hassas veri işleyen sistemlerde bu önlemi almanız gerekir. Dolayısıyla halka açık Wi-Fi ağlarında ve akıllı cihazların yoğun olduğu ortamlarda da kapatmalısınız.
- Kapatmamanız Gereken Durumlar: Ev ağlarında ve küçük ofis ağlarında bu özelliği kullanırsınız. Ayrıca Windows Ağ Haritası’nı aktif olarak kullanan kullanıcılar da bu ortamda yer alır. Dolayısıyla yazıcı ve NAS keşfini sık kullanan ortamlarda bunu açık tutarsınız.
- Dikkatli Olunması Gereken Durumlar: Karma ağlar (hem kablolu hem kablosuz), VLAN yapılandırması olan ağlar, sanal ağ ortamları (SDN).
Eğer kapatmaya karar verdiyseniz, bunu aşamalı olarak yapmanızı öneririm. Önce bir pilot grup üzerinde test edin. Kullanıcı deneyiminde bir bozulma olup olmadığını gözlemleyin. Sorun yoksa, değişikliği tüm ağa yayın. Ayrıca, protokolü tamamen kapatmak yerine, sadece dış ağlara (public network) kapalı tutmak da bir seçenektir.
Bu yaklaşım, iç ağdaki keşif yeteneğini korurken dış tehditlere karşı koruma sağlar. Özellikle dizüstü bilgisayar kullanan gezici kullanıcılar için idealdir. Kullanıcı ofis ağındayken protokol çalışır, halka açık Wi-Fi’ya bağlandığında ise otomatik olarak kapanır. Bu, güvenlik ile kullanılabilirlik arasında denge kurar.
LLTD ve qWAVE: QoS Uzantıları, Bant Genişliği Tahmini ve Akış Önceliklendirme
Protokolün en az bilinen ama en güçlü özelliklerinden biri, QoS (Hizmet Kalitesi) uzantılarıdır. Bu uzantılar, Microsoft’un qWAVE (Quality Windows Audio Video Experience) teknolojisiyle birlikte çalışır. Amaç, ağ üzerinden akan ses ve video trafiğinin kalitesini artırmaktır.
qWAVE, özellikle ev ağlarında medya akışını iyileştirmek içindir. Bir video akışı başladığında, qWAVE destekli uygulamalar bu protokolün QoS uzantılarını kullanır. Ağdan bant genişliği talep eder. Ağdaki cihazlar bu talebi değerlendirir ve uygun kaynağı ayırır.
Bu mekanizma, özellikle kablosuz ağlarda büyük önem taşır. Kablosuz bant genişliği sınırlı ve değişkendir. qWAVE, bu değişkenliği yöneterek video akışının takılmadan oynamasını sağlar. LLTD protokolün QoS uzantıları, bu süreçte kritik bir rol oynar. Veri formatı, özel QoS TLV blokları içerir.
LLTD QoS Mesaj Tipleri ve Cross-Traffic Analysis
QoS uzantıları, standart protokol mesajlarına ek olarak yeni mesaj tipleri tanımlar. Bu mesajlar, ağdaki cihazlar arasında bant genişliği ve öncelik bilgisi alışverişini sağlar. Her mesaj, kendi TLV formatına sahiptir. İşte en önemli QoS mesaj tipleri:
| Mesaj Tipi | Gönderen | Amaç | Veri Formatı |
|---|---|---|---|
| QoS InitializeSink | QoS Controller | Bir QoS akışı başlatmak için kaynak ayırma talebi gönderir. | TLV: Flow ID, Bandwidth |
| QoS Ready | QoS Sink | Kaynak ayırma talebini onaylar ve akışa hazır olduğunu bildirir. | TLV: Status, Resource ID |
| QoS Probe | QoS Controller | Ağdaki mevcut bant genişliğini ve gecikmeyi ölçmek için test paketleri gönderir. | TLV: Timestamp, Sequence |
| QoS Query | QoS Controller | Belirli bir akışın durumunu sorgular. | TLV: Flow ID |
| QoS QueryResp | QoS Sink | Sorguya cevap verir, akış istatistiklerini içerir. | TLV: Stats, Latency, Jitter |
| QoS Reset | QoS Controller | Mevcut QoS oturumunu sıfırlar. | TLV: Flow ID, Reason |
| QoS Error | QoS Sink | Bir hata durumunu bildirir (örneğin, yetersiz bant genişliği). | TLV: Error Code |
| QoS Ack | QoS Sink | Alınan QoS mesajlarını onaylar. | TLV: Sequence |
| QoS CounterSnapshot | QoS Sink | Akış istatistiklerinin anlık görüntüsünü alır. | TLV: Counter Data |
| QoS CounterResult | QoS Sink | Sayaç sonuçlarını Controller’a iletir. | TLV: Counter Values |
| QoS CounterLease | QoS Sink | Sayaç verilerinin geçerlilik süresini belirtir. | TLV: Lease Time |
Bu mesaj tiplerinin yanı sıra, ‘Cross-Traffic Analysis’ adını verdiğimiz bir mekanizma da yer alır. Bu mekanizma, farklı QoS akışlarının birbirini nasıl etkilediğini analiz eder. Örneğin, bir video akışı ve dosya indirmesi aynı anda sürer. Dolayısıyla çapraz trafik analizi bu iki akışın etkileşimini ölçer.
qWAVE ve LLTD: Windows’ta Medya Akışı Önceliklendirme
qWAVE teknolojisi, Windows işletim sisteminin bir parçası olarak gelir. Windows 10 ve 11’de varsayılan olarak etkindir. Ancak tam işlevselliği, ağdaki diğer cihazların da bu protokolün QoS uzantılarını desteklemesine bağlıdır.
Bir Windows PC’de bir video oynatıcı uygulaması (örneğin, Windows Media Player veya Netflix) çalıştığını düşünün. Uygulama, qWAVE API’sini kullanarak bir QoS akışı başlatır. Bu akışı, QoS mesajları yardımıyla ağdaki yönlendiriciye iletirsiniz. Router, eğer QoS’yi destekliyorsa bu akışa öncelik tanır.
Bu önceliklendirme, ağda başka bir cihaz yoğun veri indirirken bile videonun akıcı kalmasını sağlar. Örneğin, bir kullanıcı YouTube üzerinde 4K video seyreder. Dahası, arka planda başka biri büyük bir dosya indirir. qWAVE ve QoS uzantıları sayesinde video trafiği önceliklendirilir ve izleme deneyimi bozulmaz.
Ancak bu mekanizmanın çalışması için tüm ağ cihazlarının QoS’yi desteklemesi gerekir. Eski veya düşük maliyetli cihazlar genellikle bu özelliği desteklemez. Bu durumda qWAVE sadece sınırlı bir fayda sağlar. Bu nedenle, özellikle medya akışının yoğun olduğu ev ağlarında QoS destekli bir router kullanmanızı öneririm.
Linux ve Unix Ortamlarında LLTD: lltdscan, Nmap ve Scapy Araçları

LLTD’yi protokolünü Microsoft firması geliştirdi. Ancak Linux ile Unix dünyasında geliştiriciler bunu inceler. Bu araçlar, özellikle protokolün veri formatını incelemek isteyen araştırmacılar için değerlidir.
Bu araçlar sayesinde, Linux tabanlı bir sistemden ağdaki protokol özellikli cihazları keşfedebilirsiniz. Bu, ağ envanteri çıkarmak veya veri formatı doğrulaması yapmak için kullanışlıdır. Ayrıca bu araçlar, protokolün nasıl çalıştığını anlamak için harika birer öğrenme aracıdır.
Ancak bu araçları kullanırken etik ve yasal sorumlulukları unutmamalısınız. Sadece kendi ağınızda veya izin aldığınız ağlarda tarama yapmalısınız. İzinsiz tarama, yasal sorunlara yol açabilir. Bu nedenle her zaman sorumlu bir şekilde hareket edin.
lltdscan Kullanımı: Debian/Ubuntu’da Cihaz Taraması
lltdscan, LLTD protokolü kullanıp ağdaki cihazları bulur. Üstelik bu basit araç oldukça etkilidir. Debian ve Ubuntu depolarında bulunur. Kurulumu ve kullanımı son derece kolaydır. Araç, protokolün veri formatını doğrudan kullanır.
İşte adım adım lltdscan kullanımı:
- Kurulum: Terminali açın ve şu komutu çalıştırın:
sudo apt update && sudo apt install lltdscan. - Temel Tarama: Ağ arayüzünüzü belirterek taramayı başlatın. Örneğin,
eth0arayüzü için:sudo lltdscan -i eth0. Varsayılan arayüzü kullanmak içinsudo lltdscankomutunu çalıştırabilirsiniz. - Zaman Aşımı Ayarlama: Varsayılan zaman aşımı 1 saniyedir. Daha uzun bir süre beklemek için
-tparametresini kullanın:sudo lltdscan -i eth0 -t 3000(3 saniye). - Cihaz Adlarını UTF-8 Olarak Gösterme: Cihaz adlarını UTF-8 formatında görmek için
-uparametresini ekleyin:sudo lltdscan -i eth0 -u. - Belirli Bir Cihazı Bekleme: Belirli bir MAC adresine sahip cihazdan cevap beklemek için komutun sonuna MAC adresini ekleyin:
sudo lltdscan -i eth0 AA:BB:CC:DD:EE:FF.
lltdscan, çıktı olarak keşfedilen cihazların IP ve MAC adreslerini listeler. Bu araç, özellikle hızlı bir şekilde protokol özellikli cihazları görmek istediğinizde idealdir. Kaynak kodu GitHub’da (zed-0xff/lltdscan) mevcuttur. GPLv2 lisansı altında dağıtılır ve protokolün veri formatını doğrudan kullanır.
Nmap Ağ Keşfi ve Scapy ile Paket Oluşturma
Nmap, ağ keşfi için endüstri standardı bir araçtır. Nmap’in NSE (Nmap Scripting Engine) altyapısı, LLTD kullanarak ağ keşfi yapmanızı sağlar. Ayrıca Scapy kütüphanesi ile kendi protokol paketlerinizi oluşturabilirsiniz. Her iki araç da veri formatını doğrudan manipüle eder.
İşte Nmap ve Scapy kullanımı:
- Nmap LLTD Keşfi: Nmap’in
lltd-discoveryscript’ini kullanarak ağdaki cihazları keşfedebilirsiniz. Komut:sudo nmap -e eth0 --script lltd-discovery. Bu komut, belirtilen arayüzdeki tüm protokol özellikli cihazları bulur ve listeler. - Script Parametreleri:
lltd-discovery.interfaceparametresi ile hangi arayüzün kullanılacağını belirtebilirsiniz.lltd-discovery.timeoutparametresi ile dinleme süresini ayarlayabilirsiniz (varsayılan 30 saniye). - Scapy ile Paket Oluşturma: Scapy, Python tabanlı bir paket işleme kütüphanesidir. LLTD katmanını içerir. Örneğin, bir Discover paketi oluşturmak için:
from scapy.all import *.
pkt = Ether(dst=\"ff:ff:ff:ff:ff:ff\", type=0x88D9) / LLTD() / LLTDDiscover()
sendp(pkt, iface=\"eth0\") - Scapy ile Analiz: Yakalanan paketleri analiz etmek için
sniff()fonksiyonunu kullanabilirsiniz. Örneğin, sadece LLTD paketlerini yakalamak için:sniff(filter=\"ether proto 0x88d9\", prn=lambda x: x.summary()).
Bu araçlar, protokol araştırmacıları için paha biçilmezdir. Ancak unutmayın: Bu araçları kullanarak yaptığınız taramalar, ağda gürültüye neden olabilir. Özellikle üretim ortamlarında, bu tür taramaları dikkatli bir şekilde ve uygun zamanlarda yapmalısınız.
Linux LLTD Responder Kurulumu: open-lltd ve lldpd Farkı
Linux sistemlerde, LLTD desteklemek için açık kaynaklı çözümler de mevcuttur. Ancak bu noktada bir karışıklık vardır: open-lltd ve lldpd farklı protokolleri uygular. Bu farkı anlamak, doğru aracı seçmeniz için kritiktir.
lldpd, LLDP (Link Layer Discovery Protocol) için bir daemon’dur. Yani IEEE 802.1AB standardını uygular. Dolayısıyla, anahtarlar ile yönlendiriciler bu aracı komşuluk keşfi için kullanır. Bu protokol ile aynı şey değildir. LLDP’nin kendi TLV yapısı vardır.
open-lltd ise Microsoft’un bu protokolünü Linux’ta uygulamak için bir çabadır. Ancak bu proje, Responder rolünü tam olarak desteklemez. Yani bir Linux makinesini Windows Ağ Haritası’nda görünür hale getirmek için open-lltd kullanabilirsiniz. Ancak bu proje aktif olarak geliştirilmemektedir.
Linux sistemini Windows ağına bağlamak istediğinizi varsayalım. Bu durumda, en pratik çözüm Samba (SMB) servisini açmaktır. Samba, ağ komşuluğu için gerekli olan NetBIOS over TCP/IP ve LLMNR gibi protokolleri destekler.
Bu sayede Linux makineniz Windows Ağ Haritası’nda bir dosya sunucusu olarak görünebilir. Ancak bu protokolün sağladığı özel ikon desteği Samba ile mümkün olmayabilir.
Gizli Kalan Yönleri ve Yaygın Yanılgılar
LLTD hakkında internette birçok yanlış bilgi dolaşır. Özellikle port numaraları, Windows sürümleri ve kapatma etkileri konusunda kafa karışıklıkları yaygındır. Bu bölümde bu yanılgıları düzeltip protokolün veri formatı yönünü aydınlatacağız.
Öncelikle en yaygın yanılgı, bu protokolün bir TCP veya UDP portu üzerinden çalıştığıdır. Oysa protokol ham Ethernet çerçeveleri üzerinden çalışır. Yani bir port numarası yoktur. Bu, onu güvenlik duvarı kuralları yazarken farklı bir yaklaşım gerektirir. Çünkü güvenlik duvarları 3. ve 4. katmanda çalışır.
İkinci büyük yanılgı, Windows 11’de Ağ Haritası’nın ‘kaldırıldığı’dır. Oysa Ağ Haritası hala vardır, ancak varsayılan olarak gizlenmiştir.
Microsoft, modern Windows sürümlerinde bu özelliği kullanıcı deneyimini basitleştirmek için arka plana atmıştır. Ancak isteyen kullanıcılar hala bu özelliği etkinleştirebilir.
Üçüncü yanılgı ise bu protokolün kapatılmasının dosya paylaşımını tamamen durduracağıdır. Bu doğru değildir. Protokol keşif için kullanılır, dosya aktarımı için değil. Kullanıcılar dosya paylaşımını SMB (Server Message Block) protokolü üzerinden gerçekleştirir. Protokolü kapatırsanız sadece Ağ penceresinde cihazların otomatik görünmesini engellersiniz.
LLTD Portu Var mı? Raw Ethernet vs TCP/UDP Yanılgısı
En sık sorulan sorulardan biri şudur: ‘LLTD hangi portu kullanır?’ Cevap: Hiçbiri. Bu, OSI modelinin 2. katmanında, yani veri bağlantı katmanında çalışır. Bu katmanda port kavramı yoktur. Portlar, 4. katman (taşıma katmanı) kavramlarıdır ve TCP veya UDP protokolleri için geçerlidir.
LLTD protokol, ham Ethernet çerçeveleri üzerinden iletişim kurar. Ethertype değeri 0x88D9’dur. Bu, ağ sürücüsünün (NIC) gelen çerçeveyi TCP/IP yığınına değil, doğrudan protokol işleyicisine yönlendirmesi anlamına gelir. Yani veri formatı, TCP veya UDP başlığı içermez.
Bu nedenle, geleneksel bir güvenlik duvarı (firewall) kuralı yazarak engellemek genellikle mümkün değildir. Çünkü güvenlik duvarları genellikle 3. ve 4. katmanlarda çalışır.
LLTD protokolü engellemek için iki yolunuz vardır. Ya switch (anahtar) seviyesinde ACL (Erişim Kontrol Listesi) kullanırsınız. Ya da işletim sisteminde bunu kapatırsınız.
Bazı kaynaklarda ‘UDP port 6234’ gibi ifadeler görürsünüz. Bu tamamen yanlıştır. Bu tür bilgiler, protokolü yanlış anlayan kişiler tarafından yayılmıştır. Bu protokolün portu yoktur. Bu, onu hem benzersiz hem de veri formatı açısından farklı bir protokol haline getirir.
Windows 11’de Ağ Haritası Neden Görünmüyor? LLTD ve Modern Windows
Windows 11 kullanıcıları sıklıkla ‘Ağ Haritası nerede?’ diye sorar. Windows 10’da ‘Ağ’ penceresinde üstte bir ‘Ağ Haritası’ butonu bulunurdu. Fakat, Windows 11’de bu buton varsayılan olarak görünmez. Peki, neden?
Microsoft, Windows 11’de kullanıcı arayüzünü sadeleştirmeye karar verdi. Ağ Haritası, ortalama bir kullanıcının nadiren ihtiyaç duyduğu bir özellikti. Bundan dolayı varsayılan görünümden kaldırdılar fakat özelliği tamamen kaldırmadılar; sadece gizlediler.
Peki bu özelliği nasıl geri getirebilirsiniz? İşte adımlar:
- Kayıt Defteri’ni Açın:
regeditkomutunu çalıştırın. - İlgili Anahtara Gidin:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\NonEnumyolunu izleyin. EğerNonEnumanahtarı yoksa oluşturun. - Yeni Bir DWORD Değeri Oluşturun:
{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}adında bir DWORD değeri oluşturun ve değerini ‘0’ yapın. - Bilgisayarı Yeniden Başlatın: Değişikliğin etkili olması için bilgisayarı yeniden başlatın. Artık ‘Ağ’ penceresinde Ağ Haritası butonunu göreceksiniz.
Ancak bu özelliği geri getirmeden önce protokolün veri formatı kaynaklı risklerini hatırlamalısınız. Eğer ağınızda LLTD kapattıysanız, Ağ Haritası da çalışmayacaktır. Bu nedenle bu kararı verirken güvenlik ile kullanılabilirlik arasında bir denge kurmalısınız.
Kapatılırsa Dosya Paylaşımı Durur mu? Operasyonel Etkiler
LLTD protokolü kapatmanın en çok merak edilen etkisi, dosya paylaşımı üzerinedir. Kısa cevap: Hayır, dosya paylaşımı durmaz. Ancak kullanıcı deneyimi olumsuz etkilenebilir. Bu ayrımı netleştirmek, doğru karar vermeniz için önemlidir.
Dosya paylaşımını SMB (Server Message Block) protokolü üzerinden yaparsınız. SMB, TCP portu 445 üzerinden çalışır ve bu protokolden bağımsızdır. Bu nedenle kapatsanız bile bir kullanıcı \\sunucu\paylasim yazarak veya IP adresini kullanarak paylaşılan klasörlere erişebilir.
Ancak LLTD, ağdaki cihazların Ağ penceresinde otomatik olarak görünmesini sağlar. Protokolü kapatırsanız kullanıcılar ağdaki diğer bilgisayarları, yazıcıları ve NAS cihazlarını otomatik olarak göremez. Bu durumda kullanıcıların cihazlara manuel olarak bağlanması gerekir.
Bu etki, özellikle teknik bilgisi düşük kullanıcılar için zorlayıcı olabilir. Örneğin, bir kullanıcı ağdaki bir yazıcıya yazdırmak ister. Yazıcıyı listede göremezse yazıcının IP adresini bilmeli ve manuel olarak eklemelidir. Yani, bu protokolü kapatmadan önce kullanıcılarınıza alternatif erişim yöntemlerini öğretmelisiniz.
Link Layer Topology Discovery: Ağınızın Gizli Haritasını Çıkarın
LLTD, ağınızdaki cihazları ve bağlantıları keşfetmenizi sağlar. Bununla birlikte, ağ performansını analiz etmek için de kullanılır. Ek olarak, hem kablolu hem de kablosuz ağlarda çalışır.
- Microsoft Öğren – Yerel Ağ Cihazlarını Keşfetme Belgesi: Bu belge, ağ cihazlarının nasıl bulunduğunu ve bağlantı haritalarının nasıl oluşturulduğunu anlatır. Ayrıca, yöneticiler için teknik ayrıntılar sunar. Böylece ağ yapınızı daha iyi anlayabilirsiniz.
- Microsoft Öğren – Ağ Haritalama ve Trafik Önceliği İncelemesi: Bu sayfa, cihaz keşfi ve ağ haritalama süreçlerini açıklar. Bununla birlikte, medya akışı için öncelik ayarlarını da inceler. Yöneticilere pratik bilgiler verir.
- Vikipedi – Yerel Ağda Cihaz Bulma Yöntemleri: Bu madde, yerel ağlarda cihaz bulma yöntemlerinin tarihçesini ve kullanım alanlarını özetler. Ayrıca, Windows sürümlerindeki uygulamalara değinir. Temel bir başlangıç kaynağıdır.
Windows Ağ Keşfi Protokolü Hakkında SSS
LLTD hangi portu kullanır?
LLTD protokolü güvenli mi?
LLTD nasıl kapatırım?
LLTD ile LLDP arasındaki fark nedir?
Farklı bir alt ağdaki (subnet veya VLAN) cihazları keşfedebilir mi?
LLTD hangi katmanda çalışır?
LLTD Windows 11’de hâlâ var mı?
LLTD veri bağlantı katmanında hangi bilgileri paylaşır?
Protokolü kapatırsam dosya ve yazıcı paylaşımı durur mu?
IP adresi olmadan cihazları nasıl tespit eder?
Sonuç: LLTD’yi Anlamak ve Doğru Yönetmek
LLTD, ağ dünyasının görünmez ama etkili bir protokolüdür. Kısacası Windows Ağ Haritası’nı çalıştırır. Ayrıca cihaz keşfini otomatikleştirir ve medya akışını iyileştirir.
Doğru yönettiğinizde LLTD protokolü size büyük kolaylık sağlar. Ancak 2026’daki veri formatı kaynaklı güvenlik açıkları, onu dikkatli bir şekilde ele almamız gerektiğini gösteriyor.
Bu rehberde protokolün her yönünü ele aldık. Ne olduğundan nasıl çalıştığına kadar inceledik. Ayrıca paket yapısından güvenlik açıklarına kadar tüm detaylara değindik.
Özellikle veri formatı detaylarına odaklandık. Ethertype değeri, TLV formatı, Demultiplex Header yapısı ve QoS mesaj kodlaması bunlara örnek. Umarım bu bilgiler ağınızı daha iyi anlamanıza ve yönetmenize yardımcı olur.
Unutmayın, her protokol gibi bu da bir veri formatı standardıdır. Onu nasıl kullandığınız ağınızın güvenliğini ve performansını belirler. Güvenlik yamalarını her zaman güncel tutun. Microsoft’un Eylül 2026’da yayınladığı yamayı uyguladıysanız büyük bir riski ortadan kaldırdınız demektir.

İlk yorumu sen paylaş