LoopGuard ve UDLD Nedir ?
CLI Guru - Cisco Eğitim ve Danışmanlık Merkezi |

2007 yılından bu yana aktif olan ciscotr.com, artık " www.bilisim.pro " olarak devam edecektir.  
Mevcut mesajlarınız ve kullanıcı bilgilerinizle sitemizde katılıma devam edebilirsiniz.

+ Konuyu Cevapla
Toplam 6 sonuçtan 1 ile 6 arasındakiler gösteriliyor.
Like Tree7Likes
  • 4 Post By MCyagli
  • 1 Post By Nexus
  • 2 Post By Nexus
LoopGuard ve UDLD Nedir ?

LoopGUARD ve UDLD _________________ LOOPGUARD ============ STP nin BPDU diye bir mesaj kullandığını biliyoruz. Bunun bir sürü yararı var. Olayın tamamı bu pakettir zaten. Root Bridge her iki saniyede bir

  1. #1
    MCyagli isimli Üye şimdilik offline konumundadır Administrator
    Üyelik tarihi
    Jul 2009
    Bulunduğu yer
    Corum - Turkiye
    Mesajlar
    565

    Standart LoopGuard ve UDLD Nedir ?

    LoopGUARD ve UDLD
    _________________




    LOOPGUARD
    ============


    STP nin BPDU diye bir mesaj kullandığını biliyoruz.

    Bunun bir sürü yararı var.
    Olayın tamamı bu pakettir zaten.


    Root Bridge her iki saniyede bir BDDU gonderir ( STP de )

    Ve bunu alanlar ilgili bölümleri degiştirip arkadaşların gönderirler.


    BPDU - Designated Portlardan gönderilir.
    Root Portlardan alınır.

    STP ortamında Root Port, Designated Port ve Altn port vardır.
    Bunlar Portlerin Rolleridir.


    ALTN port - BLOCKING durumdadır.
    Ve sadece BPDU alır.

    Zaten topology nize bakarsanız karşısında DEsignated POrt vardır.

    Designated Port - Bpdu GÖnderir idi.
    Karşıdaki kişi de bunu alacaktır.

    ALTN port sadece BPDU alır ve onu kara deliğe gönderir.
    STP nin Loop engelleme mantıgı budur zaten.



    Peki Layer 1 de bir sıkıntı oldu.

    Ve ALTN nin karşsındaki Designated Port BPDU
    gönderemiyor.
    Ve sebebi ise Layer 1.

    Bu durum da ALTN port umuz MaxAGe kadar bekleyip
    Portu kullanıma açar.

    Ve LOOP başlar.


    Onun için LOOPGUARD geliştirmişler.

    BU komutun uygulandığı PORT
    BPDU almayı bırakırsa
    Forwarding State e geçmektense,

    INCONSISTENCE duruma geçer.

    Bunun anlamı ise benim mevcut State de kalıp ( Blocking Mode olsun )
    BPDU almam gerekirken şuan alamıyorum demesidir.

    TAki tekrar BPDU alana kadar öylece kalır...



    KOnfigurasyon Nasıldır ?
    ---------------------------------


    Tüm PORT lara uygulanabilir.


    CONF T
    SPANNING-TREE LOOPGUARD default



    Yada sadece bir porta.

    CONF T
    INT FA01
    SPANNING-TREE GUARD LOOP



    Gerçi bu komut sadece BPDU alan portlar için
    önem taşır.
    Designated Port a uygulasak ne olur ki


    Kod:
    sh spanning-tree interface fa0/2
    
    Loop guard is enabled on the port
    ile görebiliriz.

    Deneme yapalım.


    Sw1 -------- Sw2 olsun. ( BU kocaman bir topologynin küçük bir kısmıdır gerçekde 4 switch var )

    Sw1 in portu Designaated Port olsun.
    Sw2 nin portu ALTN olsun.

    Hadi Layer 1 sorun oluşturalım

    Sw1 e gidip Designated Port alında BPDUFILTER uygulayalım !
    BPDU gönderimi durmuştur.

    İçinden sayalım MAx Age kadar...

    Ve

    Kod:
    
    *Mar  1 10:32:35.329: %SPANTREE-2-LOOPGUARD_BLOCK: 
    Loop guard blocking port FastEthernet0/2 on VLAN0001

    Aynı şekilde tekrar BPDU almaya başlarda
    otomatikman bu inconsistent state kalkar
    yine BLOCKing mode a geçer.




    UDLD
    ======




    Aslında UDLD birazcık geniş bir konu.


    Buda Layer 1 sorunlarını anlamak için tasarlanmıştır.
    Ancak LoopGuard dan farklıdır.



    LoopGuard Layer 1 sorunu anlamı için
    BPDU almamaya başlaması gerekirdi.
    Cidden LoopGuard Layer 1 sorunlarını yakalabilir mi ?
    Elbette hayır. O sadece BPDU almayınca Layer 1 sorunu
    oldugunu varsayar.
    Az önce BPDUFILTER ile öyle sanmasını sağladık




    UDLD ise Layer 1 sorunlarınu anlamak için
    kendi HELLO packetlerini kullanır.
    Bu biraz daha iyi gibi görünüyor.
    UDLD nin STP ile işi olmaz.
    BPDU ile işi olmaz.
    Ve STP Looplarını yakalayamaz.
    Ama UDLD layer 1 sorunlarını yakalayabilir.

    Onun için UDLD ve LOOPGUARD beraber kullanılmalıdır.

    UDLD fiber kablolar için çıkarılmış ilk önceleri.
    Ama biz bunu bildiğimi bakır kablolar içinde kullanırız.
    Sadece olayın kablo ile ilgisi yok.

    UDLD karşılıklı hello gönderecek iki port birbirine,
    eger Hello gonderim durursa Layer 1 problem var demektir.

    UDLD hakkında bazı terimleri yazalım.


    -> Öncelikle UDLD Cisconun çözümüdür.
    ve VTP/CDP/PaGP gibi o da 0100.0ccc.cccc adresine gönderilir.

    -> İki modda çalışır. Normal ve Aggressive Mode.
    Normalde Mode da iken Hello almayı bırakırsa port sadece UNDETERMINED olur.
    AGGRESSIVE MODE da ise Hello almassa sinirlenip portu Err-Disabled eder.

    UDLD ile ilgili bir sürü küçük ayrıntıyı yazmaya gerek duymuyorum.


    KOnfigurasyon
    ____________

    UTP ve Fiber portamında farklıdır.

    UTP için
    ********


    KArşılık her iki switch portunda

    Kod:
    
    CONF T
    INT FA0/1
    UDLD PORT     ---> Sadece bunu yazarsanız Normal Mode da çalışır.
    UDLD PORT AGGRESSIVE   ---> Bunu yazarsanız AGGRESSIVE mode da çalışır.

    UTP ortamında UDLD sadece interface bazında enable
    edilebilir. GLOBAL olmaz. Fİberde ise GLOBAL olarak enable olabilir.




    Buraya kadar olanlar benim okuduklarım ve uygulayıp test ettiklerim.
    ( Fiber dışında )


    Şu ise benim tecrübem ve benzer şeyi tecrübe etmiş bir iki
    kişi gördüm internette.
    ------------------------------------------------------------------------

    UTP ortamında,
    Her ne kadar NOrmal Mode da çalıştırsanızda,
    Hello almayınca Aggressive mode da gibi ERR-DISABLE olur.




    Denemesini şöyle yaptım.


    Sw3 ----- SW4 arasinda Fa0/1 e UDLD uyguladim.
    Normalde modda uyguladım hemde.



    SW4 de geldim

    Kod:
    CONF T
    MAC ACCESS-LIST EXTENDED ABC
    DENY ANY HOST 0100.0ccc.cccc
    PERMIT ANY ANY
    
    INT FA0/1
    MAC ACCESS-GROUP ABC IN
    Dedim.

    VE

    Current operational state: Link down.

    Kod:
    sw3#sh int status err-disabled
    
    Port      Name               Status            Reason               Err-disabled Vlans
    Fa0/1                          err-disabled   udld
    
    Aynı şekilde bunu Fiber de uygulayıp benzer sonucu almış kişiler oldugunu
    okudum.


    Ya UDLD ile alakalı bu kısmı anlamadım.
    Ya da yazılanlar dogru degil.
    tcos, Nexus, cheat and 1 others like this.
    Mehmet Ceyhan YAĞLI
    I learn, I teach

    www.mcyagli.com

  2. #2
    Nexus isimli Üye şimdilik offline konumundadır Administrator - Founder
    Üyelik tarihi
    May 2012
    Mesajlar
    1,994

    Standart

    Hocam cisco'da bir yanlışlık yok . Cisco her zaman haklıdır biliyosun

    UDLD L2 bir protokoldür unidirect link tespiti yapar. Autonegotiate'e benzer ancak mekanizma tamamen aynı değildir. Auto negotiate L1 çalışır... UDLD linkin logical durumunu kontrol eder. Kontrol ettiği şey ise tek taraflı iletişim problemidir.


    Karşılıklı UDLD çalışan linklerde UDLD Hello trafiği devam ettiği sürece mantıksal olarak link ayaktadır. İlk alınan hello sonrası bir echo-echo reply süreci olur.. Bu bir komşu keşfi sürecidir... Ama hello beklenir ve alınmazsa kaydedilen en son hello age out olur. Komşuluk silinmeden önce hello göndermeyen arkadasa son bir rsync mesajı gonderılır. Bu mesaj sonrası sorunlu arayüze ait neighbor bilgileri temizlenir.

    Şimdi hello gönderemeyen karşıdaki cihaz ne yapar ? Resync mesajını aldığında anlar ki fiziksel olarak up olan hatta bir problem var. Bu sefer echo göndermeye başlar... Echo yanıtı alamazsa linkin unidirectional olduğu kararına varılır...



    Unidirect link tespit edildi şimdi UDLD modlarına bakalım :

    Önce şaibesiz olan aggressive moda bakalım :

    Uni. link tespit edildi ise UDLD son bir kaç kez bağlantı kurmayı dener (Link up süreci) olmazsa artık logical linkin sorunlu oldugunu dusunerek arayüzü err-disable state'e çeker.

    Aggressive risk almaz. Hep hatta ciddi problemler varmıs gıbı dusunur.

    Normal modda ise : Normal modda UDLD mesajlarının içeriklerine göre hareket edilir. Eğer neden link unidirect olmuş konusunda bir yanıt UDLD mesajları içinde bulunamaz ise port belirsiz yani undetermined olur düzeleceği umut edilerek kendi haline bırakılır ve syslog uretilir... . Ancak normal modda link uzunca bir süre arızalı kalırsa port err-disable olur mesela uzunca bir sure UDLD mesajı alınmaması veya karsı lınkte udld'nin disable edilmesi gibi ... Hello alınamaması sebebi ile cache'deki en son hellonun age out olması gibi .... Senin uyguladıgın mac acl ise bu age out olayının simulesi olmus

    Son olarak utp kabloda UDLD arada fiber media converter varsa kullanılır. Normal zamanda bakır kablo zaten down oluverıyor hemen .


    Her iki tarafta UDLD olmazsa UDLD tetiklenmez ve çalışmaz.

    İki tane cihazla deneyıp bakayım .
    “Bir kez kaçar uçurtman, sonra gökyüzüne küser insan…”

  3. #3
    MCyagli isimli Üye şimdilik offline konumundadır Administrator
    Üyelik tarihi
    Jul 2009
    Bulunduğu yer
    Corum - Turkiye
    Mesajlar
    565

    Standart

    Ben cevap verildiğini görmemişim kusura bakma Üstad



    Evet bu ve buna benzer bir sürü açıklama var bir çoğunu okumuşumdur.


    BU tür konularda Örnek yapıp kanıtlayarak açıklanmayan yorumlardan bir sürü var internette.





    UDLD nin Normal MODE da nasıl çalıştıgı hakkında :
    -----------------------------------------------------------------


    Resmi CCNP Switch kitabında
    .................................................. ..........


    ( Sayfa 184 )


    Normal mode—When a unidirectional link condition is detected, the port is allowed to continue its operation.
    UDLD merely marks the port as having an undetermined state and generates a syslog message.






    Nexus 7000 Swithc lerde ( http://www.cisco.com/en/US/docs/swit...sign_guide.pdf )
    .................................................. ..




    Sayfa 68.


    Normal mode: UDLD detects the link error by examining the incoming UDLD packets from the peer port.
    These error conditions are: Empty Echo packet, Unidirection, TX/RX loop, and Neighbor Mismatch. UDLD
    will then error-disable the port.

    Aggressive mode: Same behavior as in Normal mode, but UDLD also sets the port to the error-disable
    state in case of sudden cessation of UDLD packets in both directions. By default, the port is put in errdisable mode if no UDLD packets are received for (3 X hello-time) + 5 sec =50 seconds


    ***


    Senin açıklaman ise :



    Normal Mode un


    Resmi CCNP Switching kitabındaki UDLD Normal MODE tanımı


    ve


    NEXUS 7000 üzerinde UDLD Normal Mode tanımını


    birleştirip ortaya karışık bir tanım çıkarmış gibi olmuş



    ***

    Eğer fırsat bulup test yapıp kanıtlarsan bu sefer kesin adresini ver hemen leblebi göndericem söz ( essahtan )

    AYrıca UDLD nin packet içeriğinin Platform a göre değişip değişmediğini bile bilmiyorum açıkcası.
    Mehmet Ceyhan YAĞLI
    I learn, I teach

    www.mcyagli.com

  4. #4
    Nexus isimli Üye şimdilik offline konumundadır Administrator - Founder
    Üyelik tarihi
    May 2012
    Mesajlar
    1,994

    Standart

    Ne yani önceki leblebi sözleri yalancıktan mıydı ?
    MCyagli likes this.
    “Bir kez kaçar uçurtman, sonra gökyüzüne küser insan…”

  5. #5
    Nexus isimli Üye şimdilik offline konumundadır Administrator - Founder
    Üyelik tarihi
    May 2012
    Mesajlar
    1,994

    Standart

    2x 2960 G ile test yaptım :

    Normal modda bakır kabloda udld namına bir sorun yok. UDLD'ye fırsat kalmadan zaten port down oluverıyor. Down oluncada zaten STP ve dolayısıyla loop dıye bır sey kalmıyor ortada.

    Yıne normal modda bakır ile denedım ama araya bir çift full duplex fiber utp dönüştürücü attım. Auto neg yokken udld'ye yıne fırsat kalmıyor ama autonegotıate olarak bir tarafın rX'ini çıkardıgımda portu undetermıned'a çekıyor.

    Herşey normalken boyle :

    Udld komsuluk varken komşudan gelen UDLD mesajları her bir TLV'de azaltılarak (TLV1-7) cache'e interface bazında alınıyor ve checksum hesaplanıyor , link state bidirect (2way) oldugunu anlıyor , cache time out olunca komsuya reg_timeout flag'li bir prob mesaj gonderılıyor sanırım burada bu checksum degerıde var, sonra beklemeye geçiliyor. Prob mesajı alanın yenıden bılgı gondermesı gerekıyor...
    (Bu arada her bir TLV numarasında farklı bilgi cache'e alınıyor. Seri nu(chassis nu ) , inner-outer port numaraları , hostname , link tipi vs vs aşağıda acıklamasını yazdım .. ., önemli olan nokta ise bu mesajlarda kendı (own) id gorunce good packet aldım dıyor) , yeni den cacheleyıp checksum hesaplayıp dönguye devam edıyor. Bır nevı ıkısıde chechsum'lar vasıtası ıle cache'lerını senkronıze edıyorlar. Ama cache'de sadece 1 adet entry tutuyorlar. Sureklı doldur bosalt...Zaten bu olayada Neighbor database maintenance denıyor... Birinci tedbir bu , diğerinide agressıve modda anlatıcam ... )

    Bu mesajlara gore show udld gig 0/23 ile yapılandırmaya bakınca

    entry :

    Burası bıze aıt
    expiration time : xx secs ( Burası maksimum 45 sanıye ve her bir mesaj interval'da aging resetlenıyor.Ayrıca exp.time = 3 x mesaj interval))
    Device id : 1 (diğeri 2 )
    Current state : bidirect
    Devica name : fasdfasdfasdf ( chassıs no )
    Port : gig 0/23

    Aynı entry ıcınde burasıda komsuya aıt :

    neighbor echo 1 device : FOVC452234 ( komşu chassıs no )
    neighbor echo 1 port : gig 0/23

    Cdp name : Üst ( komsunun hostname)
    Timeout interval : 5 sn
    Mesaj Interval : 15 sn...

    Bir tarafın rx fiberi çıkardım . Arada converter var arayuzler hala up durumda . Reg_timeout flagli mesajda gonderıldi. Beklıyo beklıyo karşıdan ses yok...Expire time 0'a düşünce port err-dis veya down olmuyor. Undermıned oluyor. Bunu auto neg kapatıp denersem port normal modda err-disable oluyor.


    Bence burada UDLD'nin görevi portu err-dis yapmak ama normal modda auto neg açıksa bunu yapmıyor.

    Tımer ile oynayınca tek taraflı dusunemıyosun , hangisinde interval daha buyukse ona gore surec ıslıyor. Time ayarı dediğimiz ise sadece mesaj interval değeri değiştirilebiliyor. (1-90 sn) Buraya daha acıklık getırelım : Ben 1 nolu sw'de message interval 90 yapınca 2 nolu sw'de exp time = 270 sn oluyor ve mesaj interval 90 oluyor ama 1 nolu aynen kalıyor. Ama gidip 2 noluda message interval 20 yaparsam 1 noluda exp int 60 sn oluyor msj interval 20 oluverıyor). İlginç.... Belkide her biri cache'de birbirine ait udld verilerini tuttuklarından bana öyle geldi...


    Aynı fızıksel yapıda bakır portlara agressıve mod uyguluyorum .Arada yıne converter'lar var .. Paket trafıgı stabıl yapıda debug'a bakılırsa yukarıdakı normal mod ıle aynı ... Rx cıkardım ...

    Exp. time , doluyor... (Agressive'de echolar arası time out 5sn) Sonra sureklı tekrar komsu olmayı denıyor bunu 8 kere yapıyomus ama ben buna dıkkat etmedım... Re-establish yapmak için her denemede komsuluk resetlenmek ıstenıyor ve yanıt beklenıyor. Eger gelırse hemen yukarıdakı gibi sync olacaklar ama gelmeyınce amca dırek err dısable yapıyor. Buda Event-driven detection and echoing denen dıger tedbir...

    Cihazda SFp var ve LC/LC fiber patch'ler press oldugu ıcın ayıramıyorum , bu sebeple dırek fıberle deneyemedım ama muhtemelen aynı sonuc cıkacak.
    MCyagli and tcos like this.
    “Bir kez kaçar uçurtman, sonra gökyüzüne küser insan…”

  6. #6
    Nexus isimli Üye şimdilik offline konumundadır Administrator - Founder
    Üyelik tarihi
    May 2012
    Mesajlar
    1,994

    Standart

    Buraya düzeltme babında ufak bir detay eklemek istiyorum.

    UDLD normal modu sadece Fiber media'da kullanılıyorken aggressive modu bakır + fiber'de kullanılabilmekte..
    “Bir kez kaçar uçurtman, sonra gökyüzüne küser insan…”

+ Konuyu Cevapla

Bu Konuyu Paylaşın !

Bu Konuyu Paylaşın !

Yetkileriniz

  • Konu Acma Yetkiniz Yok
  • Cevap Yazma Yetkiniz Yok
  • Eklenti Yükleme Yetkiniz Yok
  • Mesajınızı Değiştirme Yetkiniz Yok