Sessiz EVPN konağı asla çözülmez: ARP'yi bağlamaya kadar izleyin

Uç nokta bağlı, portu etkin ve izleme konağı ona hâlâ ulaşamıyor. Birisi karşı taraftan ping çalıştırıyor ve çalışmaya başlıyor; bu da sorunu aralıklı gösteriyor ve fabric'i masum gösteriyor. Bu desen sessiz bir konağın imzasıdır: nadiren ilettiği için fabric'in keşif ve yenileme davranışı bağlantı durumundan daha önemlidir. Tek bir hedef IP, MAC ve bridge domain ile başlayın ve sonraki çözümleme alışverişini izleyin.

Sonraki ARP veya ND alışverişini izleyin

IPv4 için istekte bulunan konağın ARP alışverişini izleyin; IPv6 için Neighbor Solicitation ve Advertisement'ı takip edin. İsteğin amaçlanan yerel segmente ve amaçlanan VNI'ye girdiğini doğrulayın, çünkü doğru bridge domain'e asla ulaşmayan bir isteği hiçbir proxy yanıtlayamaz.

Sonra fabric'in hedef hakkında ne bildiğine bakın. Yalnızca MAC içeren bir rota Layer 2 hedefini tanımlayabilir, ancak proxy'nin henüz onun için IP-to-MAC bağlaması yoktur. Bunlar ayrı kayıtlardır ve birini kontrol etmek diğeri hakkında hiçbir şey söylemez.

Geçerli bir bağlama varsa proxy politikasına göre yanıt verebilir, ancak o bağlamadaki MAC hâlâ etkin bir iletim yoluna ihtiyaç duyar. Bağlama yoksa istek, bir şey yanıttan öğrenebilmek için önce flooding veya replikasyon yoluyla uç noktanın bağlantısına ulaşmalıdır.

Uyuşması gereken iki kayıt

MAC rotası Ethernet adresinin nerede yaşadığını yanıtlar. Proxy tablosu hangi IP'nin hangi MAC'e eşlendiğini yanıtlar. Yakın zamanda konuşmamış bir konak tamamen iyi bir MAC rotasına ve kullanılabilir hiçbir proxy girdisine sahip olmayabilir ve sağlıklı bir bağlantıda çözümleme arızası üreten tam olarak bu durumdur.

Uzak bağlantıda, uç noktanın alışverişi gerçekten alıp yanıtlayıp yanıtlamadığını kontrol edin. Yanıtı yerel öğrenmeyi ve ilgili EVPN duyurusunu yeniler; bu yüzden elle yapılan ping işleri düzeltiyor gibi görünür: fabric'in beklediği trafiği siz ürettiniz. Bu aynı zamanda düzeltmenin neden kalıcı olmadığını da açıklar: yenilenen girdi eskidiğinde uç nokta yeniden susar. Zamanlanmış bir ping semptomu tedavi eder ve tasarım boşluğunu gizler.

Yanıttan sonra seçilen rotayı ve yüklenmiş iletim durumunu istek sahibine doğru geriye izleyin. Çözümlemenin başarılı olması ve iletimin başarılı olması iki ayrı olaydır ve bunları karıştıran bir bilet sizi yanlış katmana gönderir.

Standardın gerçekte varsaydığı şey

RFC 9161 dinamik proxy öğrenimini ve bilinmeyen ARP ile ND isteklerinin varsayılan flooding'ini açıklar. Bu flooding'in tamamen bastırılması, öğrenme veya sağlama varsayımları onu güvenli kılan dağıtımlarla sınırlıdır; bu, çoğu yapılandırma kılavuzunun ima ettiğinden daha dar bir koşuldur.

Yeni keşfedilen uç noktaları bekleyen bir fabric'in bu istekler için çalışan bir yola ihtiyacı vardır. Birisi BUM trafiğini azaltmak için bilinmeyen istek flooding'ini kapatıysa, sessiz konaklar bunun bedelini ödeyen nüfustur ve semptom haftalar sonra aralıklı erişilebilirlik şikâyeti olarak gelir.

Bastırma ayarını fabric'in ne bilmeyi vaat ettiğine dair bir beyan olarak okuyun. Hiçbir şey bağlamaları sağlamıyorsa, vaat seyrek göndericiler için doğru değildir. Yapılandırılmış bastırmayı onu beslemesi gereken sağlama sistemiyle karşılaştırın. Bu ikisi uyuşmadığında fabric tam olarak yapılandırıldığı gibi davranır ve düzeltilmesi gereken şey beklentidir.

Yenileme, yaşlanma ve statik alternatif

Standart, dinamik girdiler yaşlanmadan önce desteklenen yenileme yoklamalarını açıklar. Yanıtlar ilgili bridge ve proxy durumunu yeniler; yanıtların yokluğu meşru olarak kaldırmaya ve rotanın geri çekilmesine yol açabilir. Bu, her zamanlayıcıyı uzatarak bastırılması gereken bir hata değildir.

Yaşlanma zamanlayıcılarını süresiz uzatmak görünür bir arızayı eskimiş bir arızayla değiştirir: fabric konağın terk ettiği bir konumu duyurmaya devam eder. Uygulamanın belgelenmiş kontrollerini kullanın ve uç noktanın konuşmasının makul olarak beklenebileceği sıklıkla eşleşen bir ömür seçin.

Bilinen, yönetilen uç noktalar için statik veya denetleyici tarafından sağlanan bir bağlama meşru ikinci modeldir. Değiştirme ve taşımayı yöneten bir sahibe ihtiyaç duyar, çünkü sağlanan kayıt konak başka bir porta geçtiğinde kendini güncellemez.

Bir sonraki biletten önce ne kaydedilmeli

Bağlamanın kaynağını, son yenileme zamanını, geçerli konumu ve herhangi bir geri çekme olayını MAC rotasının yanında tutun. Bu kayıt, biletin gerçekte sorduğu soruyu yanıtlar: uygulama keşfi mi bekliyor, eskimiş duruma mı güveniyor, yoksa başarılı çözümlemeden sonra iletmeyi mi başaramıyor?

Sonra üçünden hangisini işletmeye hazır olduğunuza karar verin. Flooding ile keşif, gerçekçi bir ömürle yenileme veya bir sahiple sağlama savunulabilir. Birine göre yapılandırılıp diğeri gibi davranması beklenen fabric, sessiz konakların kaybolduğu yerdir.