EIGRP Unequal Load Balancing - Variance
CLI Guru - Cisco Eğitim ve Danışmanlık Merkezi |

+ Konuyu Cevapla
Toplam 10 sonuçtan 1 ile 10 arasındakiler gösteriliyor.
EIGRP Unequal Load Balancing - Variance

Arkadaşlar selam. Şöyle bir şey geldi aklımıza çalışırken. Alttaki görüntüde çizmeye çalıştım. Amacımız R1-R2-R4-R6 (A) ve R1-R3-R5-R6 (B) arasında load balancing yapmak. Linklerden biri giderse R1-R6 (C) arasındaki direkt link

  1. #1
    Viking isimli Üye şimdilik offline konumundadır Member
    Üyelik tarihi
    Nov 2010
    Mesajlar
    32

    Standart EIGRP Unequal Load Balancing - Variance

    Arkadaşlar selam.

    Şöyle bir şey geldi aklımıza çalışırken. Alttaki görüntüde çizmeye çalıştım.

    Amacımız R1-R2-R4-R6 (A) ve R1-R3-R5-R6 (B) arasında load balancing yapmak. Linklerden biri giderse R1-R6 (C) arasındaki direkt link loadbalancinge katılsın istiyoruz.

    - Takıldığımız 2 nokta var, metrikleri ayarlamakta sıkıntı yaşıyoruz. Varyans değerini 2 aldık. En düşük metric*2 den, 60 altındaki tüm linkler dahil. Yani A ve B linkleri load balance yapar halde. Ancak A veya B linklerinden biri gittiğinde, sınır değer gene 60 kalacağından, C linki hesaba katılmayacak?

    - B linkinde değişiklik yapalım, R3-R5 arasındaki metriği 20 yapalım dedik. Böylece biri 30 diğeri 40 metriğine sahip 2 linkimiz olacak. Varyans gene 2.

    R1-R2-R4-R6 (A) ----> 10-10-10=30
    R1-R3-R5-R6 (B) ----> 10-20-10=40

    - Şu anki haliyle, matematiksel olarak A linki gittiğinde yeni sınır değer 40*2=80 olacak ve metriği 70 olan C linki hesaba katılacak ancak bu sefer de A ve B linkinin dengeleme yaparak çalışması imkansız çünkü B linkinin feasible distancei (30) successorın distanceından (30) küçük değil.

    Bunu nasıl ayarlarız yahu. Mutlaka ekstra bir yolu vardır, IP SLA içine varyans katma olasılığımız var mı? Yani mesela A ve B linkleri 30 metriğine sahiplerken 1 olan varyans değeri, linklerden birisi gittiğinde varyans değerinisi 3'e çıkarmamız mümkün müdür? Ama harika bir şey daha var, C linkinin 70 olan metriği gene Successorın metriğinden (30) küçük kalıyor.

    Bir el atan olursa çok sevinirim. Olmazı varsa farklı her yolu duymak isterim.
    Eklenmiş Resim Eklenmiş Resim
    • Dosya tipi: jpg ei2.jpg‎ (39.5 KB (Kilobyte), 1122 kez indirilmiştir)

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

    Standart

    Merhaba 1 ile 6 arasındaki komşuluğu şartlı olarak kurarsan söylediğini yapabilirsin.

    Yani a ve b de problem yokken komşuluk olmayacak . A veya B giderse c ile komşuluk kurulacak gibi.

    Bunun için 1 ile 6 arasındaki EIGRP komşuluğunda kullanılan paketleri policy-routing ile yönlendirebilirsin.

    Veya benzer şartlı durum ile metric değişimi yapabilirsin.
    “Bir kez kaçar uçurtman, sonra gökyüzüne küser insan…”

  3. #3
    Viking isimli Üye şimdilik offline konumundadır Member
    Üyelik tarihi
    Nov 2010
    Mesajlar
    32

    Standart

    doğru diyorsun hocam, 3ünü de aynı metriğe alıp eigrp hello paketlerini bu şekilde şarta bağlarsam olur sanırım. teşekkürler.

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

    Standart

    Söylemek istediğim o değil.

    1 ve 6 arasındakı komşuluk mekanizmasını statik olarak yapılandırdıktan sonra 1 ve 6 numaralı cihazlarda bir policy-routing yapılandır. Ve komşuluk kuracakları arayüzlere uygula. Aynı şekilde lokal policy olarak router'ların kendilerine de uygula.

    Bu policy ile 1-6 arası EIGRP komşuluk kurmak için gereken unicast paketleri boş bir arayüze veya null'a redirect et . Bunu set ip next hop ile yapabilirsin. Bu redirect işlemini ip sla + track desteği ile yaparsan A ve B kodlu route'lar çökerse track'i de çökertir. Bu sebeple track düşerse policy routingde yapılandırılan şartlı redirect işlemi ortadan kalkar.

    Redirectin kalkması sonrası komşuluk kurulur. Variance uygun yapılandırıldı ise unequal load balance C + sağlıklı rota üzerinden çalışmaya devam eder.

    Ancak bu kolay bir çözüm olmaz hatta anlamsız bir çözüm olur . Bir sürü sla ve track yapılandırman lazım ve sla'da kullanılan paketlerin path'lerini manuel set etmen lazım. Öğrenmek amaçlı bir uygulama olduğundan denemekten zarar görmezsin.

    Sana bu kısa yapılandırma söylemek istediğimi anlatır :



    Aşağıda da GNS topolojisi var.

    http://www.ciscotr.com/forum/attachm...1&d=1403954696

    R1-R3 komşuluğu R2'nin off olması şartı ile gerçekleşir.
    Eklenmiş Resim Eklenmiş Resim
    Eklenmiş Dosya Eklenmiş Dosya
    “Bir kez kaçar uçurtman, sonra gökyüzüne küser insan…”

  5. #5
    Viking isimli Üye şimdilik offline konumundadır Member
    Üyelik tarihi
    Nov 2010
    Mesajlar
    32

    Standart

    Teşekkürler Nexus, gönderdiğin konfigurasyon üzerinden ben de A linkinde deneme yapmak istedim ancak olmadı.

    - Çalışma şeklini anladığımdan emin olmak için soruyorum;

    - R1-R3 arasındaki EIGRP trafiğini yakalayıp track 10'nun gerçekleştiği müddetçe R2'ye yönlendirdin ve de track 10 da R1'in R3'ü R2 üzerinden pingleyebilmesi şartı üzerine oturtuldu. doğru mudur?

    - Bir de komşulukları unicast kurmanın sebebi nedir? aralarındaki eigrp trafiğini destination 224.0.0.10 olarak da yakalabilirdik sanıyorum. özel bir sebebi var mıdır?

    Tekrar teşekkürler bu arada.

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

    Standart

    Alıntı Viking Nickli Üyeden Alıntı Mesajı göster
    Teşekkürler Nexus, gönderdiğin konfigurasyon üzerinden ben de A linkinde deneme yapmak istedim ancak olmadı.

    - Çalışma şeklini anladığımdan emin olmak için soruyorum;

    - R1-R3 arasındaki EIGRP trafiğini yakalayıp track 10'nun gerçekleştiği müddetçe R2'ye yönlendirdin ve de track 10 da R1'in R3'ü R2 üzerinden pingleyebilmesi şartı üzerine oturtuldu. doğru mudur?

    - Bir de komşulukları unicast kurmanın sebebi nedir? aralarındaki eigrp trafiğini destination 224.0.0.10 olarak da yakalabilirdik sanıyorum. özel bir sebebi var mıdır?

    Tekrar teşekkürler bu arada.
    Track up state olduğu sürece R1-R3 komşuluğu için gereken paketler başka router'lara gidiyor. Bunu neden yapmış olabiliriz , Network komutu neye yarıyor ? EIGRP paketlerinin TTL değerinin önemini ne.

    Ayrıca neden 224.0.0.10'u kullanmadık onuda araştır bakalım .


    O ufak labda sadece R2'yi kapatıp R1-R3 komsulugunu gozlemleyebılırsın. Arayuzlerı kapatarak denemen sorunlu olabılır . Sorunsuz çalışması için uğraşmadım. Bir kaç sla+track ekleyerek bunu sen yapabilirsin belki
    “Bir kez kaçar uçurtman, sonra gökyüzüne küser insan…”

  7. #7
    Viking isimli Üye şimdilik offline konumundadır Member
    Üyelik tarihi
    Nov 2010
    Mesajlar
    32

    Standart

    224.0.0.10 u sanırım uyguladığımız local policyden ötürü kullanmadık.


    neighbor komutunun TTL'i arttırdığını biliyorum. TTL 2 de bize R2 üzerinden R1-R3 komşuluğu kurmaya müsade etmiyor zira 3 subnet değiştiriyoruz. ama neighbor komutunda da hello paketlerinin çıkış interfaceini direkt belirtiyoruz. garip bir yorum oluyor benim söylediğim durum böyle olunca

    kafa gitti

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

    Standart

    224.0.0.10 kullanamayız çünkü pbr multicast paketlere etki etmez.

    EIGRP paketleri ttl değeri 2 dir .
    Ama bunun bizim yaptığımızla ilgisi yok. Öğren diye sordum.

    Unicast EIGRP komşuluk kurabilmek için illaki "network x.x.x.x " parametresi ni girmek gerekir. Bu parametre ilgili interfacelerde EIGRP'yi aktif hale getirir. Bu aktif olma işleminden sonra gonderilmeye baslanan hello mesajları default olarak multicast paketlerdir. Biz "neighbor x.x.x.x fa 1/0" şeklinde statik komşuluk tanımlayarak komşulugun Unicast paketler kullanilarak devam etmesini sağlariz.

    Pbr ile bu paketleri başka router'a yolladigimiz da o router kendisi ile alakasız olan bu paketleri ignore eder.
    “Bir kez kaçar uçurtman, sonra gökyüzüne küser insan…”

  9. #9
    Viking isimli Üye şimdilik offline konumundadır Member
    Üyelik tarihi
    Nov 2010
    Mesajlar
    32

    Standart

    çok sağol Nexus. öğrendim epey şey ve bahsettiğim A linkinde de başarıyla uyguladım. çalışması için arayüzleri kapamam yeterli oldu.
    tekrardan çok sağol.

    yalnızca pathecho yerine type echo protocol ipIcmpEcho 192.168.26.6 source-interface FastEthernet0/0 bunu kullandım.

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

    Standart

    Alıntı Viking Nickli Üyeden Alıntı Mesajı göster
    çok sağol Nexus. öğrendim epey şey ve bahsettiğim A linkinde de başarıyla uyguladım. çalışması için arayüzleri kapamam yeterli oldu.
    tekrardan çok sağol.

    yalnızca pathecho yerine type echo protocol ipIcmpEcho 192.168.26.6 source-interface FastEthernet0/0 bunu kullandım.
    SLA yapılandırma biçimi IOS versiyonuna göre değişebiliyor.

    Rica ederim.
    “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