EIGRP komşusu mu DMVPN geçişi mi? Önce rolü kontrol edin

Komşuluk yok ve ortadaki yönlendirici bariz şüpheli gibi görünüyor. Masum olabilir. Dış tünel paketlerini iletmek ile overlay yönlendirme protokolüne katılmak iki farklı iştir ve bir cihaz ikincisini yapmadan birincisini yapabilir. Aşağıdaki beş kontrolü sırayla yapın ve başarısız olan ilkinde durun.

Adım 1: iki rolü çizin

Amaçlanan EIGRP komşuluğunu iki yönlendirici arasında mantıksal bir bağ olarak çizin, ardından tünel paketlerini taşıyan underlay yönlendiricilerini çizin. Aynı cihazın iki listede de yer alması gerekmez ve listeleri karıştırmak, sağlıklı bir geçiş yönlendiricisinin komşuluğu bozduğu suçlamasıyla karşılaşmasının en yaygın nedenidir.

Geçiş yönlendiricisi dış paketleri olağan IP yönlendirmesi ve politikasıyla iletir. Korumalı tünelin içinde taşınan protokolü çalıştırması gerekmez ve bu paketleri ileri iletmek için bir EIGRP sürecine de ihtiyaç duymaz.

Adım 2: ortadaki cihazın neyi sonlandırdığını kontrol edin

Ortadaki yönlendirici tüneli sonlandırıyor ve spoke cihazlarla EIGRP komşulukları kurması gerekiyorsa cevap tamamen değişir. O cihaz desteklenen overlay yönlendirme davranışına ihtiyaç duyar ve ona geçiş demek komşu koşulunu ortadan kaldırmaz. Yönlendirme yapılandırmasından önce tünel yapılandırmasını okuyun. O cevap sonraki her kontrolü belirler.

Yani ilk gerçek soru hangi protokolün ayarlanacağı değil. Soru, kutunun hub mi, spoke mü, saf bir underlay atlaması mı yoksa uçlar arasında çerçeve taşıyan bir Layer 2 hizmeti mi olduğu.

Adım 3: komşunun kontrol düzlemini doğrulayın

Komşu olması gereken her cihazda dört şeyi onaylayın: EIGRP örneği ve özerk sistem numarası, kimlik doğrulama parametreleri, sürece katılan arayüz ve o arayüzü kapsayan ağ komutu. Bunlardan herhangi birindeki uyuşmazlık, arayüz açıkken ve ping çalışmaya devam ederken komşuluğu aşağıda tutar.

RFC 7868, EIGRP'yi çok noktaya yayın denetim değişimi olan bir IP protokolü olarak tanımlar; bu nedenle komşuluk ilişkisi, ara bir yönlendiricinin paketleri bir hedefe yönlendirerek yerine geçebileceği bir şey değildir. Ya denetim değişimi eşe ulaşır ya da komşuluk oluşmaz.

Adım 4: taşımanın denetim değişimini ilettiğini doğrulayın

Ardından, overlay'ın denetim trafiğini amaçlanan uçlar arasında gerçekten taşıyıp taşımadığını kontrol edin. Eşin NHRP eşlemesini ve ona ulaşan dış yolu inceleyin, ardından tünel arayüzünün açık olduğunu ve trafiği geçirdiğini onaylayın. Başarılı bir underlay ping dış yolun var olduğunu kanıtlar; overlay denetim değişiminin iletildiğini kanıtlamaz.

Şeffaf bir Layer 2 hizmeti, noktadan noktaya bir tünel ve çok noktalı DMVPN bulutu çok noktaya yayını farklı biçimlerde iletir. Üçünün de aynı davrandığını varsaymak yerine gerçekte kurulu olan için desteklenen arayüz, NHRP ve çok noktaya yayın modelini izleyin.

Adım 5: katılamıyorsa sınırı yeniden tasarlayın

Gerekli bir overlay cihazı protokolü çalıştıramıyorsa tasarımı açıkça değiştirin. O sınırda desteklenen bir protokol veya değişim modeli kullanın ya da komşuların gerçekten birbirleriyle konuşan uçlar olması için uygun bir uçtan uca tünel düzenleyin. Statik bir rotanın katılmayanı her denetim paketi için aktarıcıya çevirdiğini varsaymayın.

Diyagramda her cihazın rolünü not edin ve yapılandırmayla birlikte saklayın. RFC 7868 protokol değişimini tanımlar ve bu tanım, komşuluk ilişkisinin geçiş iletimiyle neden taklit edilemeyeceğinin referansıdır.

Beş kontrolün hepsinden sonra da komşuluk kurulmuyorsa, kalan şüpheliler tünel arayüzünde çok noktaya yayın işleme ve 88 numaralı protokolü filtreleyen politika gibi platform özellikleridir. Bunlar somut, test edilebilir nedenlerdir ve ortadaki yönlendiriciyi suçlamanın bir turundan daha değerlidir.