LLDP, bitişik ağ cihazlarının kendi kimliklerini ve portlarını etkin biçimde tanıtmasını sağlayarak bakım personelinin “bu kablonun gerçekte hangi cihaza bağlı olduğunu” doğrulamasına yardımcı olur. Terminallere IP adresleri atamaz, döngüleri otomatik olarak gidermez ve video veya kontrol hizmetlerinin hâlihazırda normal çalıştığını garanti etmez. Komşu tablosunu arıza giderme kanıtı olarak kullanmak, yalnızca bir topoloji şeması gördüğünüz için ağ kabulünün tamamlandığını ilan etmemek için duyuruların nasıl alındığını, kayıtların nasıl yenilendiğini ve sürelerinin nasıl dolduğunu anlamanız gerekir.
1. Önce cihazı ve portu ayrı ayrı, açıkça tanımlayın
Panodaki A anahtarının GE1 üzerinden B anahtarının GE2 portuna bağlandığını varsayalım. Yalnızca iki uçtaki bağlantı ışıklarına bakarak arayüzün bir tür bağlantı kurduğunu biliriz; ancak karşı cihazın adını ve portunu bilmeyebiliriz. LLDP’nin tam adı Link Layer Discovery Protocol’dür ve IEEE 802.1AB, bitişik istasyonlar arasındaki keşif mekanizmasını tanımlar. Bilgiyi veri bağlantı katmanında iletir ve önce IP yönlendirmesi aracılığıyla karşı tarafı bulması gerekmez; bu nedenle doğrudan bağlantı ilişkilerinin belirlenmesine yardımcı olmak için uygundur.
Cihaz kimliği ile port kimliği birlikte değerlendirilmelidir. Chassis ID cihazı tanımlamak, Port ID ise duyurunun gönderildiği portu tanımlamak için kullanılır; kullanılan kodlama bir MAC adresi, arayüz adı veya cihazın desteklediği başka bir biçim olabilir ve her Port ID türü ağ portunun MAC adresi olarak yorumlanmamalıdır. Sistem adı, insanların kolay okuyabilmesi için sunulan isteğe bağlı bir bilgidir; değiştirilebilir veya birden fazla cihazda aynı olabilir. “A’nın GE1 portu B’nin GE2 portuna bağlıdır” şeklinde kayıt tutmak, sahada kablo takibine rehberlik etmek açısından yalnızca iki adı kaydetmekten daha yararlıdır.
2. Tek yönlü denmesi, yalnızca bir yönün görülebilmesini değil, bağımsız duyuruları ifade eder
A’nın LLDP gönderme işlevi, yerel bilgileri yapılandırmaya göre gönderir; B’nin alma işlevi ise bunları okur. A’nın önce B’ye bir sorgu göndermesi gerekmez; ayrıca mesajın ulaştığını kanıtlamak için B’nin bir LLDP alındı onayı göndermesine dayanmaz. B de kendi duyurusunu A’ya bağımsız olarak gönderebilir; böylece iki uç da komşu kayıtları oluşturabilir. Bunlar bir istek ve bir yanıt değil, iki bağımsız duyuru sürecidir; yalnızca “tek yönlü protokol” ifadesini kullanan eski makaleler, yeni başlayanların bağlantının yalnızca tek yönde keşfedilebileceğini düşünmesine kolayca yol açabilir.
Gönderme ve alma genellikle ayrı ayrı yapılandırılabilir. A yalnızca alırken B normal biçimde gönderiyorsa A, B’yi görebilir; ancak B, A’yı göremez. Bir yönde kayıt yoksa önce her iki uçta işlevlerin gerçekten etkin olup olmadığını kontrol edin ve hemen fiberin veya ağ portunun hasarlı olduğu sonucuna varmayın. Gönderme aralığı, değişiklikle tetiklenen davranış ve başlangıç davranışı uygulamaya göre değişir; bir markanın saniye cinsinden varsayılan süresi veya hızlı başlatma sayısı, tüm Feichang Technology modellerinde aynıymış gibi yazılamaz.
3. Bir duyuruda neler bulunur?
LLDP, Ethernet çerçeveleri içinde taşınır. En yakın köprü kapsamı için yaygın hedef MAC adresi 01:80:C2:00:00:0E, EtherType ise 0x88CC’dir; bu, ping gönderilebilen bir yönetim IP adresiyle aynı türde bir adres değildir. Çerçevedeki keşif bilgisine LLDPDU denir ve TLV’ler kullanılarak düzenlenir. TLV, “tür, uzunluk, değer” anlamına gelir: tür, alıcıya bu bölümün ne olduğunu bildirir; uzunluk, ne kadar içerik bulunduğunu belirtir; değer ise cihazın sağladığı asıl bilgidir.
Temel bir duyuru, cihaz kimliğini, port kimliğini ve geçerlilik süresi TTL’yi içerir; sonu da bir bitiş TLV’siyle işaretler. Destek ve yapılandırmaya bağlı olarak sistem adı, port açıklaması, yetenekler veya yönetim adresi de taşıyabilir. Alıcı cihaz bu alanları kontrol edip ayrıştırır, ardından “duyuruyu alan yerel arayüz” ile “karşı tarafın bildirdiği kimliği” ilişkilendirir. Karşı tarafın bildirdiği Port ID, yerel giriş portu olarak değerlendirilemez; bir port açıklamasından gerçek optik modül parametreleri veya sertifikaları çıkarılamaz.
4. Neden tek bir anahtarın tüm ağın topolojisini yayınlaması değildir?
Yaygın en yakın köprü kapsamındaki LLDP, doğrudan bitişik cihazlar için kullanılır. Sıradan bir A—B—C anahtarlamalı bağlantısında B, A’nın duyurusunu bu kapsam içinde işler ve sıradan hizmet yayın trafiği gibi değiştirmeden C’ye kadar iletmez. B, diğer etkin portlarında kaynak olarak A’nın kimliğine bürünmek yerine kendisini tanıtır. Özel amaçlı kapsamların, doğrudan geçişin veya tünelleme yöntemlerinin kendi kuralları vardır; üç cihazlı basit örnek, tüm cihaz türlerinin kesinlikle hiçbir zaman iletme yapmadığı şeklinde genellenemez.
Bir yönetim platformunun nispeten eksiksiz bir topoloji elde etmesi için genellikle kontrollü bir yönetim kanalı üzerinden birden fazla cihazın komşu verilerini okuması, ardından cihazları, portları ve zamanları karşılaştırarak ilişkileri birleştirmesi gerekir. Tüm düğümleri toplamak için tek bir LLDP çerçevesinin bütün ağı dolaşmasına dayanmaz. Platformun ilgili izinlere, protokollere ve cihaz desteğine ihtiyacı vardır; yönetim bağlantısı arızaları da eşzamanlı yapılmayan veri toplama işlemleri de görünümü etkileyebilir. Bir cihazın komşu tablosuna sahip olması, herhangi bir üçüncü taraf platformun otomatik olarak uyumlu olabileceğini de kanıtlamaz.
5. TTL, eski kayıtlara bir son geçerlilik zamanı verir; bir hizmet paketinin kaç atlama yapabileceğini belirtmez
Buradaki TTL, komşu bilgilerinin geçerli kaldığı süredir; bir IP paketinin her yönlendiriciden geçtiğinde azalan atlama sayısı değildir. Alıcı, yeni ve geçerli bir duyuru aldığında ilgili komşu bilgisini ve sona erme koşulunu günceller; uzun süre yeniden bir şey alınmazsa kayıt yaşlanır ve kaldırılır. Bağlantı durumu değişiklikleri veya duyuruların devre dışı bırakılması gibi olaylar, uygulamaya bağlı olarak cihazın kaydı daha erken temizlemesine yol açabilir; herhangi bir arızanın saptanması için mutlaka TTL’nin tamamının dolmasının beklenmesi gerektiği yazılamaz.
Eğitim örneğinde B, 0. saniyede A’nın 120 saniyelik TTL bildirdiği bir duyuru alır ve 30. saniyede başka bir geçerli duyuru alır; böylece bu kaydın sona erme noktası 150. saniyeye güncellenebilir. Ardından duyurular durursa ve kaydı erken temizleyen başka olaylar yoksa kayıt, süresi dolduktan sonra kaldırılır. Bunlar yenileme mantığını açıklamak için kullanılan varsayımsal sayılardır; Feichang Technology modellerinin varsayılan değerleri veya toparlanma süreleri değildir. LLDP gönderiminin durdurulması, kablonun çıkarıldığı veya tüm hizmet verilerinin durdurulduğu anlamına da gelmez.
6. Feichang Technology modellerinin yetenekleri gerçek bir çözüme nasıl uygulanır?
Feichang Technology ürün merkezindeki 3422 yönetilebilir Katman 3 anahtarının ayrıntılarında LLDP, port istatistikleri, aynalama ve yönetim işlevleri açıkça listelenir. Bir projede bağlantı doğrulaması için LLDP, hizmet sayaçlarını gözlemlemek için istatistikler ve gerektiğinde desteklenen yeteneklere göre aynalama yoluyla paket analizi kullanılabilir. Bu araçların her biri farklı soruları yanıtlar: komşunun kim olduğu, hizmet trafiğinin durumu ve gerçekte hangi çerçevelerin alındığı. Hiçbiri tüm kabul kontrollerinin yerini alamaz.
İlgili ayrıntı sayfasının PoE bölümünde “yok” yazdığı için, yalnızca LLDP’ye sahip olması veya sayfada LLDP-MED’den söz edilmesi nedeniyle modelin PoE ile beslendiği yazılamaz.
7. Önce yapılandırmada bir temel oluşturun, ardından gerekli bilgileri duyuruya açın
Önce cihaz ve ürün yazılımı bilgilerini, yapılandırma yedeklerini ve yönetim erişimini geri kazanma yollarını kaydedin; doğru çalıştığı bilinen bir bakım bağlantısında her iki ucun gönderme ve alma durumunu kontrol edin. Anahtarlar ve portlar için hassas kullanım amaçlarını açığa çıkarmayan, anlaşılır adlar veya açıklamalar girin; ardından gerçekten duyurulması gereken isteğe bağlı alanları seçin. Menü adları ile kaydetme veya gönderme adımları için bu modelin talimatları izlenmelidir; eski makalelerdeki diğer markalara ait varsayılan hesaplar veya komutlar kopyalanmamalıdır.
Sistem açıklaması ve yönetim adresi gibi bilgiler bakıma yardımcı olur; ancak cihaz ve sürüm hakkında ipuçlarını da açığa çıkarabilir. Güvenilmeyen erişim portlarından hangilerinde gönderme veya almanın devre dışı bırakılacağına ya da isteğe bağlı bilgilerin azaltılacağına güvenlik tasarımına göre karar verilmelidir. Bir komşunun kendi bildirdiği kimlik, kimlik doğrulaması değildir; “çekirdek anahtar” olarak adlandırılması ona güven kazandırmaz. Erişim kontrolünü ve yönetim izinlerini hizmet tasarımına göre koordine edin; LLDP’nin etkinleştirilmesini ağ güvenliği çalışmalarının tamamlanmasıyla bir tutmayın.
8. Bir komşu kaybolduğunda kanıta dayanarak katman katman sorun giderin
Önce mevcut yerel porta ve gerçekten bağlı olan cihaza baktığınızı doğrulayın; ardından fiziksel bağlantıyı, her iki uçtaki işlevleri ve duyuruların politika gereği filtrelenip filtrelenmediğini kontrol edin. Alma veya gönderme sayaçlarının artıp artmadığını, en son güncelleme zamanını ve yaşlandırma davranışını kaydedin. Paket yakalama gerektiğinde, gerçek çerçeveleri kontrol etmek için yetkilendirilmiş yalıtılmış bir ortamda veya onaylanmış bir zaman aralığında desteklenen aynalama ve analiz araçlarını kullanın; teyit almadan üretim ağında kabloları çıkarmayın, fabrika ayarlarına dönmeyin veya çok sayıda parametreyi değiştirmeyin.
B, A’nın duyurularını alabiliyor ancak A, B’ninkileri alamıyorsa B’nin gönderme yolunu ve A’nın alma yolunu ayrı ayrı kontrol edin. Her iki uçta da kayıt varsa ancak hizmetler çalışmıyorsa VLAN’ları, IP adreslerini, yönlendirmeyi, erişim politikalarını ve terminal uygulamalarını kontrol edin. LLDP’nin görünmesi, kamera kaydının, PLC kontrolünün veya alt ağlar arası iletişimin doğru çalıştığını kanıtlamaz; bir komşunun kaybolması da yalnızca karşı tarafın göndermeyi durdurduğu anlamına gelebilir. Yanlış teşhisi önlemenin tek yolu, yönetim kanıtlarını gerçek hizmet testlerinden ayrı tutmaktır.
9. Kabulü tek bir kontrollü değişiklikle tamamlayın
Önce normal durumda her iki cihazın ve portlarının kimliklerini, isteğe bağlı alanlarını ve güncelleme zamanlarını kaydedin; bunları kablolama kayıtlarıyla madde madde karşılaştırın. Onaylanmış test koşullarında bir açıklamayı değiştirin veya bir tarafta LLDP gönderimini duraklatın; karşı taraftaki kaydın güncellenmesini ya da yaşlanarak silinmesini gözlemleyin, ardından ayarı geri yükleyip kaydın yeniden oluştuğunu doğrulayın. Bu test keşif mekanizmasını doğrular; tüm ağın arızalara dayanıklılığının veya kesintisiz çalışabilmesinin kanıtı değildir.
Son olarak, planlanan hizmetleri ve yönetim erişimini ayrı ayrı doğrulayın; öncesi ve sonrası kayıtlarını, zamanları, cihaz sürümlerini ve yapılandırmaları saklayın. Cihazları değiştirdikten, bağlı portları değiştirdikten veya adlandırmayı düzenledikten sonra kayıtları eşzamanlı olarak güncelleyin. LLDP’nin en değerli sonucu güzel bir çizgi çizmek değil, “hangi yerel portun hangi karşı porta bağlandığını” zamana duyarlı, incelenebilir bir kanıta dönüştürmek ve hangi hizmet sorunlarının doğrulanması için hâlâ başka yöntemler gerektiğini netleştirmektir.
Doğrulama kaynakları: IEEE 802.1AB proje açıklaması ; Cisco LLDP çerçevesi ve duyuru mekanizması ; Juniper komşu keşfi ve yapılandırma kavramları ; Feichang Technology Katman 3 anahtar kategorisi ; Feichang Technology 3422 ürün ayrıntıları. Üçüncü taraf materyaller genel mekanizmalar için kullanılır; Feichang Technology komutlarının veya varsayılan parametrelerinin kanıtı değildir. İki çalışma prensibi şeması, içerik açısından kontrol edilmiş genel çizimlerdir; gerçek ürün fotoğrafları, modelin iç devreleri veya ölçümler değildir. Örnek portlar ve zamanlamalar, teknik özellik taahhüdü değildir.
Çince teknik makaleden çevrilmiştir. Kaynağın ilk yayımlanma tarihi: 2022-11-07. Kaynağın son revizyon tarihi: 2026-10-13T10:22:10+08:00. Çince kaynağı okuyun
