L3VPN devri: özel yollar, varsayılan bir yol mu yoksa tam tablo mu?

Devreniz açık, VRF yapılandırılmış ve sağlayıcı tasarımın geri kalanını belirleyen kısa bir soru soruyor: müşteri kenarının ne alması gerektiği? Üç yanıt yaygındır ve hiçbiri bir etiket yığınının var olmasından kaynaklanmaz. Bunlar, trafiğin şubeden nereden çıktığına dair hizmet kararlarıdır.

Devri sırayla yürütmek, bunu doğru yapmanın en ucuz yoludur. Hiçbir şeyle eşleşmeyen trafiğe ne olduğuyla başlarsınız, ardından özel önekleri ve hata durumundaki davranışlarını yazarsınız ve ancak ondan sonra ne kadar büyük bir akışı taşımaya hazır olduğunuzu konuşursunuz.

Kimsenin planlamadığı trafikle başlayın

Herhangi bir önek listesi ortaya çıkmadan önce bir soru sorun: bir paket hiçbir özel yolla eşleşmediğinde nereye gitmelidir? Kendi internet devresi olan bir şube genellikle yerel bir varsayılan tutar, böylece sıradan web trafiği yerel güvenlik duvarından çıkar ve sağlayıcıya hiç dokunmaz. Bu tasarımda VPN yalnızca uzak özel siteleri taşır ve seçimi daha belirgin önekler yapar.

Merkezi bir çıkış kullanması amaçlanan şube bunun tersidir. Orada varsayılan hizmetin içine işaret eder ve sağlayıcı veya merkezi site iletmeyi, dönüş yönlendirmesini ve her türlü çeviriyi sahiplenir. O sahip olmadan "VPN'e varsayılan" demek, adları çözen ama hiçbir yere ulaşmayan bir şube üretir.

İki tasarım yönlendirme hatasının nasıl göründüğünde farklıdır ve bu yüzden tahmin etmek pahalıdır. Yerel varsayılanla, kaybolan bir özel yol o trafiği internete gönderir; orada güvenlik duvarı onu atar ya da daha kötüsü, amaçlamadığınız bir şey yanıtlar. Merkezi varsayılanla, aynı kayıp internet erişimini tamamen ortadan kaldırır ve bilet "tüm şube çöktü" olarak gelir. İki hatanın hiçbiri kendi başına yanlış değildir, ancak yalnızca biri sattığınız hizmetle eşleşir ve tek başına bir BGP yapılandırması hangisini kurduğunuzu söylemez.

Özel önekleri hata durumlarıyla birlikte yazın

Şubenin ulaşması gereken önekleri listeleyin ve hangilerinin özetlendiğini not edin. Bir bit fazla geniş bir toplu kayıt, bilinmeyen hedefleri VPN'e çeker ve bu yalnızca uzak taraf onlara gerçekten sahipse ve onları iletiyorsa uygundur.

Ardından özel hizmet başarısız olduğunda amaçlanan davranışı tanımlayın. Tutulan bir atma yolu trafiği yetkisiz bir yoldan uzak tutar ve temiz, beklenen bir kesinti üretir. Yüzen bir varsayılan, yedek bir yola geçerek kullanılabilirliği koruyabilir, ancak yalnızca o yedek yolun bu trafiği taşımaya yetkisi varsa.

Kullanılabilirliği ve izin verilen yedeği devir belgesinde iki ayrı gereksinim olarak tutun. Bunları birleştiren ekipler sonunda şubenin düşmesi gerekip gerekmediğini tartışır, bunun yerine kararlaştırılan politikanın uygulanıp uygulanmadığını kontrol etmek yerine.

CE'nin gerçekte ne kurduğunu kontrol edin

Yapılandırma niyeti ile iletim durumu yeterince sık ayrışır, bu yüzden doğrulama olay incelemesine değil devre aittir. Bir IOS-XE müşteri kenarında, aşağıdaki üç komut üç farklı soruyu yanıtlar: ne teklif edildi, ne kabul edildi ve gerçekte ne kullanılıyor.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Üçünü de devir gününde çalıştırın, bir ay sonra değil, birileri neyin kararlaştırıldığını hâlâ hatırlarken. İlk çıktı soft-reconfiguration inbound veya saklanan bir route refresh'e bağlıdır; ikisinden biri olmadan CE neyi reddettiğini gösteremez. İkincisi politikadan sonra kabul edilen ve en iyi yolları gösterir. Üçüncüsü varsayılanın gerçekte nereye gittiğini söyler ve bu tüm devirdeki en yararlı satırdır.

Site iki bağlantıya sahipse aynı kontrolleri ikinci CE'de çalıştırın. İki kenar arasındaki asimetrik kabul, "bir sunucudan çalışıyor diğerinden çalışmıyor" durumunun yaygın bir nedenidir ve simetrik görünen yapılandırma farkında görünmez.

Daha büyük bir akışı varsaymak yerine nitelendirin

Bazen müşteri gerçekten VRF içinde internet yol bilgisine ihtiyaç duyar, politika yönlendirmesi veya öneğe göre yönlendiren merkezi bir çıkış için. Bu, beyan edilmesi, sınırlandırılması ve fiyatlandırılması gereken bir gereksinimdir, gizli bir varsayılan değil. Bununla birlikte RIB ve FIB için bellek, güncellemeler için CPU, filtre bakımı ve ortaya çıkan tablonun bir sahibi gelir.

Kapasite tartışmaları iki yönde de yanılır. Tam bir tablo VRF içinde yasak değildir ve bedava da değildir. Aynı şekilde, bugünün maliyetini eski bir yol sayısından çıkaramazsınız ve daha küçük bir etiket tahsisi yolları saklamanın maliyetini ortadan kaldırmaz.

BGP/MPLS IP VPN belirtimi, VPN hizmetinin yanında birkaç internet erişim düzenlemesini tartışır ve her müşteri için tam bir tablo veya varsayılanı zorunlu ilan etmez ve "standart uygulama" hakkında bir iddia ortaya çıktığında işaret edilmeye değer bölüm tam da budur: RFC 4364.

Devri, duyurulan kümeyi, alınan kümeyi ve seçilen kümeyi kararlaştırılan çıkış politikasının yanına kaydederek ve bir özel hedefi, bir amaçlanan genel hedefi ve bir yol kaybı durumunu test ederek kapatın. O üç testin imzalı kaydı, çoğu ağın ne yaptığına dair herhangi bir ifadeden daha fazla tartışmayı çözer.