VRF'de kayıp rota: yerel, VPNv4 yoksa iletim tablosu mu?

Bir müşteri, rota hedefi değişikliğinden sonra bir önekin kaybolduğunu söylüyor ve gönderdiği ilk ekran görüntüsü genellikle yanlış tablo oluyor. Üç farklı tablo üç farklı soruya yanıt verir: önek VRF içinde var mı, VPNv4 rotası olarak duyuruldu ve içe aktarıldı mı ve gerçekten bir iletim girdisi kuruldu mu. Bunları sıra dışı okumak, kendinden emin ama yanlış sonuçlar üretir. Bu kılavuz bir yerel ve bir uzak öneki üç tablodan sırayla geçirir ve bunu başlatan RT değişikliği için bir geri alma planıyla bitirir.

Öneki ve ait olduğu tabloyu adlandırın

Bir şey yazmadan önce iki önek not edin. Biri müşteri sahasında yereldir, bağlı bir arayüzden veya CE duyurusundan öğrenilir. Diğeri uzaktır ve sağlayıcının omurgası üzerinden gelmesi beklenir. Aynı VRF'ye farklı yollardan girerler ve birindeki arıza diğeri hakkında hiçbir şey söylemez.

İki tanımlayıcı arasındaki ayrımı net tutun, çünkü bu biletlerdeki karışıklığın çoğu oradan gelir. Rota ayırt edicisi VPNv4 NLRI'nin bir parçasıdır ve aksi halde aynı olan müşteri öneklerini omurga boyunca benzersiz yapmak için vardır. Rota hedefi, öznitelik olarak taşınan genişletilmiş bir topluluktur ve içe aktarma ile dışa aktarma politikası onunla eşleşir. Bu, ayırt edicinin ikinci adı değildir ve müşterinin paketlerinde taşınmaz.

Adım 1: önekin VRF'de olduğunu kanıtlayın

Yerel görünümle başlayın, sonra içe aktarmayı yöneten RT'lerle devam edin. Yerel önek burada yoksa, yukarıda hiçbir şey suçlu olamaz:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

Bağlı veya statik görünen bir önek yerel olarak öğrenilmiştir ve varlığı, dışa aktarılıp aktarılmadığı hakkında hiçbir şey söylemez. Bu iş akışındaki en yaygın yanlış okuma budur: sağlıklı bir VRF tablosu yalnızca yerel öğrenmenin kanıtıdır. Dışa aktarma tarafı ayrı bir sorudur ve buna komşu görünümü ile bağlı dışa aktarma hedefi yanıt verir.

Burada bulunduğunuz sürece VRF'deki RT listelerini kontrol edin. Amaçlanan içe aktarma hedefi listede yoksa aşağıdaki her şey önemsizdir. Varsa ama uzak PE'nin dışa aktardığından farklıysa, tek bir paket yakalaması açmadan arızayı buldunuz.

Adım 2: VPNv4 tablosunu ve hedeflerini okuyun

VPNv4 tablosu, kontrol düzleminin gerçekte ne alışveriş ettiğini gösterir. Uzak öneki doğru ayırt edicinin altında arayın, ardından ona bağlı topluluklara bakın:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

Doğru rota hedefine sahip ancak yerel kurulumu olmayan bir girdi, erişilebilirliğe değil içe aktarma politikasına veya rota seçimine işaret eder. VPNv4 tablosunda hiç görünmeyen bir girdi yukarıyı işaret eder: kaynak PE onu dışa aktarmamış olabilir veya oturum adres ailesini taşımıyor olabilir.

Değişiklikler sırasında insanları şaşırtan üçüncü bir durum var. Bazı platformlar rota hedefi üyelik bilgisini kullanarak hangi VPN rotalarını isteyeceklerini veya tutacaklarını sınırlar, bu yüzden filtrelenmiş tek bir görünümde uzak bir NLRI'nin bulunmaması, duyurunun hiçbir yerde olmadığının kanıtı değildir. Bir rotanın küresel olarak geri çekildiği sonucuna varmadan önce filtrelenmemiş tabloyu ve komşunun duyurduğu rotaları kontrol edin.

Adım 3: bir şeyin kurulduğunu ve etiketlendiğini doğrulayın

BGP girdisi bir karardır, yol değil. İletim tabloları paketlerin gidecek yeri olup olmadığını söyler:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

Çözülmüş komşuluk ve giden etiket içeren bir CEF girdisi, veri düzlemi trafiğinin çalışması gerektiği anlamına gelir ve kalan her belirti uygulamaya veya VRF içindeki filtrelemeye aittir. Çözülmemiş sonraki atlama gösteren bir CEF girdisi, BGP sağlıklı görünse de etiket yolunun eksik olduğu anlamına gelir ve BGP tablosunun bir ekran görüntüsünün bir değişiklik incelemesini yanılttığı durum tam olarak budur.

Yerel PE'nin dayattığı etiketi uzak PE'nin almayı beklediği etiketle karşılaştırın. İki görünüm arasındaki uyuşmazlık etiket tahsisi veya oturum sorunudur ve rota hedeflerini düzenleyerek düzeltilmez, kaç kez yaparsanız yapın.

RT değişikliğini bildirilmiş kapsamla geri alın

Arıza bir rota hedefi düzenlemesiyle başladıysa, onu tek bir bilinçli adım olarak geri alın ve hangi kapsamı değiştirdiğinizi söyleyin. Bir içe aktarma hedefini kaldırmak, o VRF içindeki uygunluğu geri çeker. VPNv4 duyurusunu omurgadan silmez ve bazı platformlarda rota tabloda tutulmaya devam eder. Bunlar farklı sonuçlardır ve kullanıcıya görünen etki hangisini kastettiğinize bağlıdır.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

Oturum önekleri zaten saklıyorsa yumuşak gelen yeniden yapılandırma yeterlidir; çalışma saatlerinde sağlayıcıya bakan bir oturumun sert şekilde sıfırlanması başkasının vermesi gereken bir karardır. Junos'ta eşdeğer kontroller her VRF'nin tablosunu ve VPN tablosunu doğrudan okur ve geri alma komut başına iptal değil commit anında geri dönüştür, bu yüzden başlamadan önce yapılandırma farkını kaydedin.

Başladığınız aynı üç komutla ve aynı sırayla bitirin ve çıktılarını zaman damgasıyla kaydedin. RT'nin yanlış olduğunu ve şimdi doğru olduğunu söyleyen bilet yeniden kullanılamaz; önekin VRF'de, VPNv4'de ve CEF'te kurulu olduğunu gösteren bilet, sıradaki kişinin karşılaştırabileceği kanıttır. Yalnızca ilk ikisi değiştiyse değişikliği bitirmediniz.