QFX MAC neden EVPN'de görünür ama iletim tablosunda görünmez

EVPN veritabanında MAC bulmak, onun bir rota olarak duyurulduğunu veya alındığını kanıtlar, daha fazlasını değil. İletim tablosu daha sonra programlanan başka bir yapıdır, bu nedenle aynı MAC birinde görünüp diğerinde eksik olabilir, üstelik her protokol doğru davranır. Bu iki çıktıyı birbirinin kopyası saymak, gerçek boşluk bir içe aktarma politikası veya çözülmemiş bir sonraki atlama iken mühendisleri BGP arızasının peşine düşürür. Sormaya değer soru, fabric'in MAC'i bilip bilmediği değil, hangi aşamada onu iletmeyi bıraktığıdır.

Farklı sorulara yanıt veren iki tablo

Junos EVPN'de veritabanı her örnek için MAC adreslerini ve her birinin nasıl geldiğini listeler: erişim portundan öğrenilmiş, Type 2 rotasında alınmış veya multihoming grubunun parçası olarak işaretlenmiş. Juniper'ın show evpn database referansı, görünümü okunabilir kılan MAC ve örnek bazlı filtreleri kapsar. Bu, örnek ve MAC anahtarlı bir kontrol düzlemi özetidir; donanımın çerçeveleri anahtarladığı tablo değildir.

Anahtarlama tablosu tam olarak bu iletim durumudur. Her iki çıktı da MAC'leri VLAN veya VNI bağlamının yanında listeler; tam da bu yüzden satır satır karşılaştırılırlar ve tam da bu yüzden karşılaştırma yanıltıcıdır. Veritabanındaki kayıt, rotanın var olduğunu ve örneğe kabul edildiğini söyler; platformun onu iletim için kurup kurmadığı hakkında hiçbir şey söylemez.

Type 2 rotası MAC'i, isteğe bağlı IP'yi, etiketi veya VNI'yi, rota ayırt edicisini ve uzak VTEP'i adlandıran sonraki atlamayı taşır. Kablo ile o rota arasında dört şey bozulabilir: ana bilgisayar hiç öğrenilmez, rota hiç duyurulmaz, içe aktarmada reddedilir veya sonraki atlaması çözülemez. Her başarısızlık farklı bir tablo kümesini dolu bırakır ve bu dizinin neden teşhis edilebildiğinin nedeni budur.

Yerel öğrenme hâlâ önce gerçekleşir

Yaygın varsayım, EVPN'nin MAC öğrenmesini devraldığıdır, dolayısıyla boş veritabanı bir overlay sorunu anlamına gelmelidir. Yerel öğrenme hâlâ erişim tarafında çalışır, VXLAN var olmadan önceki gibi: anahtar, izin verilen bir çerçevenin kaynak MAC'ini doğru VLAN ve hizmette öğrenir ve ancak ondan sonra bunun için bir Type 2 oluşturur. İlgili çerçeve göndermemiş bir ana bilgisayarın duyuracak hiçbir şeyi yoktur. Çerçeveleri VLAN üyeliği, bir filtre veya bir topluluğun devre dışı üyesi tarafından atılan bir ana bilgisayar, overlay açısından aynı görünür.

Ek noktasından başlayın ve salt okunur komutlarla ilerleyin. Amaç, ana bilgisayardan gelen bir çerçevenin amaçlanan hizmetten geçtiğini kanıtlamaktır, çünkü hiç ulaşmamış bir çerçeveyi aşağı akışta hiçbir şey telafi etmez.

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

Seçili LACP üyeleri, demetin ayakta olmasından daha önemlidir, çünkü bir topluluk bir üyede ayakta olabilirken ana bilgisayarın trafiği kapalı veya engelli bir bağlantıya hash'lenir. Arayüz sayaçları sessiz ana bilgisayarı düşüren ana bilgisayardan ayırır, çünkü hiç göndermeyen ana bilgisayar ile çerçeveleri sınıflandırmayla atılan ana bilgisayar aynı boş tabloyu bırakır.

Uzak MAC nerede kaybolur

Uzak MAC ters yönde başarısız olur, üstelik sessizce. Type 2 rotası gelir, ancak yalnızca rota hedefi ve VNI yerel yapılandırmayla eşleştiğinde bir örneğe girer ve ancak sonraki atlaması erişilebilir bir VTEP'e çözüldüğünde kullanılabilir olur. Rota hedefi uyuşmazlığı, BGP tablosunda hiçbir örneğin asla istemediği geçerli bir rota bırakır.

Üç görünümü sırayla okuyun: rotanın varlığı, veritabanı kaydı, iletim kaydı. Aşağıdaki komutlar her aşamada aynı MAC'i sorar ve örnek adres çıktıları karşılaştırılabilir tutar.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

Bu çıktılar üç ayrı soruya yanıt verir. bgp.evpn.0 içinde veritabanı kaydı olmayan bir rota içe aktarma politikasına, rota hedefine veya örnek yapılandırmasına işaret eder. İletim kaydı olmayan bir veritabanı kaydı, başka bir yükseltme yoluna ait olan platform programlamasına işaret eder. Sonraki atlaması çözülemeyen etkin bir rota, taşıma veya etiket sorunudur ve hiçbir MAC hata ayıklaması onu onarmaz.

Bunu düzelten bir yeniden başlatma çok az şey kanıtlar

Bir yeniden başlatma belirtiyi ortadan kaldırdığında, yapılandırmanın sağlıklı olması gerektiği sonucu caziptir. Yeniden başlatma her tabloyu sıfırdan programlar, bu nedenle eski bir kaydın bir politika hatasını gölgelediği durumu da gizler; arıza genellikle bir sonraki değişiklikte, bağlantı dalgalanmasında veya rota geri çekilmesinde geri döner.

Herhangi bir bakım penceresinden önce, yeniden başlatmanın neyi sileceğini kaydedin. Bu üç komut öncesi ve sonrasını karşılaştırmaya yeter ve cihazda hiçbir şeyi değiştirmez.

show evpn database instance blue
show route table bgp.evpn.0
show version

Bu çıktıları tarih ve yazılım sürümüyle birlikte arşivleyin. Aynı yeniden başlatmanın daha önce de işe yaradığına dair sonraki bir rapor kanıt değil ipucudur ve fark ancak biri önceki çıktıyı sakladıysa görünür.

Çoğu durumu çözen dört gözlem

Dört gözlem neredeyse her durumu kapsar: ek noktası ve hizmeti, örnek değer olarak MAC, rotanın ve veritabanının durumu ve kullanılan sürüm. Açıkça örnek olan bir MAC seçin ki kimse onu üretim adresiyle karıştırmasın: ilk oktet 02 yerel olarak yönetilen bir unicast adresini işaret eder, kalan oktetler serbesttir ve bu nedenle 02:00:00:00:00:5c güvenli bir yer tutucudur.

Sonra yanıtların başarısız olan aşamayı göstermesine izin verin. Ek noktasında öğrenme yoksa erişim tarafı; veritabanı kaydı olmayan rota içe aktarma; iletim durumu olmayan veritabanı kaydı programlama anlamına gelir. Ne olursa olsun, toplanan çıktıları ana bilgisayar, arayüz, hizmet ve sürümle birlikte teslim edin, böylece sonraki mühendis sorguyu tekrarlamak yerine yolu yeniden üretebilsin.