Peering haftalardır ayakta, prefix sayısı doğru görünüyor ve yine de bir müşterinin trafiği uzun yolu seçmeye ya da hiç ulaşmamaya devam ediyor. Aynı gösterge iki farklı şeyi yargılıyor. Bir BGP oturumu, iki peer'in bir TCP bağlantısı üzerinden mesaj alışverişi yapabildiğini bildirir; overlay'in tam o müşteri için etiketli bir paket taşıyıp taşıyamayacağı hakkında hiçbir şey söylemez.

Bu boşluk en kolay DMVPN üzerinde MPLS tasarımında görülür; burada hub yolu ile doğrudan spoke yolu, peering ile ilgisi olmayan nedenlerle farklı davranabilir.

Oturum gerçekte neyi kanıtlar

BGP TCP üzerinde çalışır, bu yüzden her peer'in başka bir şey olmadan önce diğer uç adresine bir rotası olmalıdır. O uç olarak bir loopback seçerseniz, iletme garantisi değil, erişilebilirlik koşulu yaratmış olursunuz. Oturum daha sonra müşteri trafiğinin asla kullanmayacağı bir arayüz üzerinden ayakta kalabilir.

Sonuç çıkarmadan önce iki uçta dört olguyu kaydedin: oturumun kaynak adresi, hedef adresi, içinde bulunduğu yönlendirme bağlamı ve çekirdeğin ya da yönlendiricinin o çift için seçeceği arayüz. Bu olgular kontrol düzlemini tanımlar. Müşteri paketleri bunların üzerine bir VRF, bir etiket yığını ve bir overlay eşlemesi ekler.

Dört mekanizma, bir değil

Cisco'nun DMVPN üzerinde MPLS belgeleri parçaları net biçimde ayırır. MP-BGP, müşterinin overlay etiketlerini sağlayıcının kenarındaki cihazlar arasında dağıtır. MPLS bu etiketleri bir paketin iletme bağlamını seçmek için kullanır. NHRP, overlay adresini dinamik bir tünelin ihtiyaç duyduğu taşıma ucuna eşler. IPsec, geçerli olduğu yerde peer yolunu korur.

Dördünden herhangi biri doğruyken bir diğeri yanlış olabilir ve trafiği taşıyan şey bu bileşimdir. Rota değişimi tamamlanabilirken bir VRF için etiket bağlaması eksik olabilir, NHRP eşlemesi eski bir taşıma adresini gösterebilir veya tünel var olsa da hiçbir politika iç pakete izin vermiyor olabilir. Bu durumların hiçbiri oturumu düşürmez.

Hub yolunu kestirme yolla karşılaştırın, her seferinde tek değişken

Kaynak ana bilgisayarı, hedef ana bilgisayarı ve VRF'yi sabitleyin, ardından aynı akışı iki kez izleyin. Hub yolunda sonraki atlamayı, uzak müşteri bağlamını tanımlayan hizmet etiketini ve kullanılan overlay-taşıma eşlemesini not edin. Amaçlanan doğrudan yolda da aynı üç şeyi not edin. İki listenin farkı arızadır ya da arızanın yokluğudur.

Karşılaştırma sırasında akışı sabit tutun. Gözlemler arasında kaynak ana bilgisayarı, VRF'yi veya hedefi değiştirmek birbiriyle ilgisiz iki hikâye üretir ve bu alıştırmanın bozulmasının en yaygın yolu budur.

Loopback testlerini kendi bölmesinde tutun

Bir yönlendiricinin loopback adresinden gönderilen ping yararlı bir testtir ve bir ana bilgisayardan gelen akıştan farklı bir durumu dener. Kaynak adres yönlendiriciye aittir, yönlendirme bağlamı VRF yerine genel olabilir ve yanıt yolu bir müşteri prefix'inin izleyeceği yoldan farklı olabilir. Bu yüzden yanıt veren loopback ile uygulamanın kestirme üzerinden çalışması ayrı sonuçlardır ve müşteriyi yalnızca ikincisi tanımlar.

İkisini de test edin, sonra notlarınızda ayrı ayrı işaretleyin. Birbirleriyle çeliştiklerinde tasarımın nerede saptığına dair somut bir şey öğrenmiş olursunuz ve bu, tek bir yeşil işaretin size söyleyebileceğinden fazladır.

Sürüm ve kusur iddiaları kendi kanıtlarını gerektirir

Saha raporları bazen bir ana bilgisayar maskesinin ya da BGP kaynak adresinin değiştirilmesini önerir ve bu tür raporlar yalnızca yazıldıkları kusur ve etkilenen sürümlerle birlikte okunmaya değer. Bir sürümden gelen geçici çözüm, mimarinin hiçbir /32 prefix'ini desteklemediği iddiası değildir.

DMVPN fazınıza, platformunuza ve sürümünüze uyan belgeleri kullanın ve bir bölümün FlexVPN dahil birkaç düzenlemeyi kapsayabileceğini unutmayın. Bir düzenlemeden alınan örnek sessizce diğerine geçmez. Oturum uçlarını gerçekten ihtiyaç duyduğunuz kontrol düzlemi tasarımına göre seçin, ardından müşterinin iletme yolunu ayrıca doğrulayın, çünkü her loopback maskesini yeniden yazmak hangi işin başarısız olduğunu bulmanın yerini tutmaz.

İlgili makaleler