MPLS L3VPN laboratuvarı ping atmıyor mu? Bu beş atlamayı kontrol edin

İki müşteri yönlendiricisi, bir çift provider edge cihazı ve hata mesajı vermeden ölen bir ping. Küçük bir MPLS L3VPN laboratuvarında arıza neredeyse her zaman beş kontrol noktasından birinde oturur ve her birinin, bağımlılığın çalıştığını ya da eksik olduğunu gösteren bir komutu vardır. Hata, ping başarısız olduğunda bağımlılıkları sırayla test etmek yerine her seferinde BGP'yi yeniden başlatmaktır. Doğrudan VRF yapılandırmasına atlarsanız, iki cihaz ötede çözülmemiş bir sonraki atlama yüzünden başlayan bir soruna bir saat harcayabilirsiniz.

Listeyi aşağıdan yukarıya doğru işleyin. Geçen bir kontrol noktası geçmiş kalır ve ilk başarısızlık, hata ayıklamaya değer olanıdır.

Birinci kontrol noktası: PE'ler birbirine ulaşır

Her PE'nin diğer PE'nin loopback'ine bir rotası olmalıdır ve bu rota gerçek bir şey üzerinden çözülmelidir. Interior gateway protocol bunun için olağan yoldur, ancak özyinelemeli arama canlı bir adjacency'ye indiği sürece statik bir rota da işe yarar. IOS tarzı cihazlarda show ip route 10.0.0.2 ve ardından show ip cef 10.0.0.2, önekin var olup olmadığını ve arkasında çözülmüş bir adjacency bulunup bulunmadığını gösterir. Tabloda olup arkasında adjacency olmayan bir rota, erişilebilirlik değildir.

Her iki yönü de kontrol edin. Asimetrik IGP maliyetleri, yanlış taraftaki bir passive interface veya loopback'i filtreleyen bir distribute list, her biri yalnızca tek bir yönü bozar ve tek yön oturumu öldürmeye yeter. Loopback'ler ping atıyor ama BGP oturumu Active'te duruyorsa, başka bir şeye dokunmadan önce update source'a bakın.

İkinci kontrol noktası: bir etiket yolu var

Uzak loopback'e giden bir IP rotası, taşımanın bir etiket basacağını kanıtlamaz. Bir LDP tasarımında, uzak loopback'in hem yerel hem de uzak bir bağlaması olduğunu ve giden etiketin forwarding tablosunda göründüğünü doğrulayın. show mpls ldp bindings 10.0.0.2 32 etiket çiftlerini gösterir ve show mpls forwarding-table 10.0.0.2 line card'ın gerçekte neyi uygulayacağını gösterir. İkinci komut hiçbir etiket göstermiyorsa veya IP'ye geri düşüyorsa, taşıma VPN trafiğini tasarımın varsaydığı gibi taşımıyor demektir.

Ayrım, MPLS'in forwarding state'i hedef öneklerinden nasıl ayırdığından gelir; bu, RFC 3031 belgesinde tanımlanan modeldir. Laboratuvarınız LDP yerine RSVP-TE veya BGP'ye komşu etiketler kullanıyorsa o mekanizmanın kendi durumunu kontrol edin; LDP'nin her alt katman etiketini dağıttığını varsaymak, hayalet bir hatanın peşinden koşmanın yaygın bir yoludur. Bozuk bir etiket yolu genellikle daha sonra mevcut ama kullanılamaz bir VPN rotası olarak ortaya çıkar.

Üçüncü kontrol noktası: VPN rotası sağlam ulaştı

Oturum özetine değil, tam müşteri önekinin VPNv4 veya VPNv6 rotasına bakın. show bgp vpnv4 unicast all 10.10.1.0/24 route distinguisher'ı, uzak PE loopback'ine ayarlanmış next hop'u ve bir etiketi göstermelidir. Önek yoksa, kaynak PE'deki export politikası veya alıcı PE'deki import politikası ilk şüphelidir ve route target'lar olağan suçludur.

Route target kontrolünü BGP alımından ayrı okuyun. Bir rota doğru next hop ile gelebilir ve import target eşleşmediği için yine de VRF'ye yerleşmeyebilir. Alıcı PE'de show ip route vrf CUSTOMER 10.10.1.0 önemli olan testtir; BGP tablosu yalnızca rotanın kontrol düzlemini geçtiğini kanıtlar.

Dördüncü kontrol noktası: interface VRF içinde

Route distinguisher ve route target'larla tanımlanmış bir VRF, hiçbir interface'i içine taşımaz. CE tarafındaki interface'in VRF atamasına ihtiyacı vardır ve show ip vrf interfaces veya show ip interface brief onu doğru örnek altında listelemelidir. Bu, kopyalanmış bir yapılandırmanın en sık yanlış gittiği kontrol noktasıdır, çünkü VRF bloğu eksiksiz görünürken interface hâlâ global tabloda oturur.

Ardından PE'nin yerel müşteri önekini o VRF'ye öğrendiğini ve CE'nin bağlantı üzerinden geri bir rotası olduğunu doğrulayın. CE üzerinde PE'yi işaret eden statik bir default bir laboratuvar için yeterlidir, yeter ki PE'nin VRF'inde CE LAN'ine bir rota olsun. İki yarıdan biri eksikse, ping herhangi bir etiket uygulanmadan başarısız olur.

Beşinci kontrol noktası: yanıt eve giden yolu bulur

Giden paketi, ardından dönen paketi izleyin, çünkü farklı tablolar kullanırlar. Giriş PE'sinde müşteri kaynağı, VRF içinde uzak etiketle uzak öneğe çözülmelidir. Çıkış PE'sinde hedef, aynı VRF içinde CE tarafındaki interface'e çözülmelidir. PE'nin kendisinden gönderilen bir ping kanıt değildir: global tablodan veya farklı bir kaynak adresinden çıkabilir, bu yüzden çalıştırılacak test ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1'dir.

Ana bilgisayar güvenlik duvarları, reverse-path filtering ve CE access list'leri hâlâ geçerlidir. Giden yol çalışıyor ve yanıt ölüyorsa sorun dönüş tarafındaki bir rotada veya filtrede, MPLS taşımasında değildir.

Her kontrol noktası için ilk başarısız bağımlılığı adlandıran tek satır tutun. O satır, müşterinin ping atamadığı şikayetini erişilebilirlik, etiket durumu, rota importu, interface üyeliği veya dönüş yolu hakkında somut bir soruya dönüştürür ve bir sonraki hata ayıklama oturumunun aynı beş komutu aynı sırayla tekrarlamasını engeller.