MPLS şube yönlendirmesi: CE neyi, kimden öğrenir

Bir şubedeki ana makine başka bir şubedeki sunucuya bağlantı açar ve iki saha da aynı yönetilen MPLS 3. katman VPN'nin arkasındadır. Ana makine yalnızca kendi varsayılan ağ geçidini bilir, başka bir şey bilmez; bu doğrudur. Önemli olan, yerel müşteri kenarının paketi kendi sağlayıcı kenarına devretmesi ve sağlayıcının VPN yönlendirme durumunun paketi hedef öneki taşıyan şubeye ulaştırmasıdır.

Tek bir paketi yol boyunca izlemek, hangi bölümün müşteri sorumluluğunda ve hangi bölümün hizmete ait olduğunu görmenin en hızlı yoludur.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Her atlamanın işi nerede biter

CE-A, uzak LAN'a giden ve yerel sağlayıcı bağlantısına işaret eden bir rotaya ihtiyaç duyar, uzak şubenin WAN adresine değil. Ardından sağlayıcı paketi VPN yönlendirme durumunu kullanarak kendi çekirdeğinden taşır ve CE-B paketi hedef LAN'a teslim eder. Hiçbir noktada ana makinenin etiketleri, VRF'leri veya karşı tarafın internet devresini anlaması gerekmez.

Biletlerde tekrar tekrar görülen hata, A şubesinde B şubesinin WAN adresini sonraki atlama olarak yapılandırmaktır. İki şube de aynı hizmeti satın aldı, bu yüzden komşu olmaları gerekiyormuş gibi geliyor. Değiller: sonraki atlama gerçekten sahip olduğunuz yönlendirme tasarımı üzerinden erişilebilir olmalıdır ve uzak CE genellikle yönetmediğiniz ekipmanın arkasında birçok atlama uzaktadır. Bu varsayım üzerine kurulmuş statik bir rota etkin olarak görünür ve hiçbir şeye çözülmez; bu, tabloda doğru göründüğü için eksik rotadan daha kötüdür.

RFC 4364, müşteri kenarı ile sağlayıcı kenarı arasındaki değiş tokuşu sağlayıcının VPN rotalarını dağıtmasından ayırır ve bu kılavuzun konusu tam olarak bu sınırdır. Müşterinin işi, kenarına ne teslim edebileceğini söylemek ve hizmetin karşılığında sunduğu erişilebilirliği kabul etmektir.

Devrin üzerinde anlaşması gerekenler

Mekanizmayı sağlayıcıyla birlikte seçin, onun etrafından değil. Statik rotalar, BGP veya CE ile PE arasında bir yönlendirme protokolü düzenlemesi hepsi meşrudur ve OSPF'nin böyle bir devir için tanımlanmış bir MPLS VPN modeli vardır. Bunların hiçbiri, iki uzak müşteri kenarı arasında belirtilmemiş bir sağlayıcı çekirdeği üzerinden OSPF komşuluğu kurmak için gerekçe değildir; çünkü bu, sağlayıcının kabul etmediği ve destekleyemeyeceği bir tasarımdır.

Yeni bir LAN devreye girmeden önce dört şeyi yazın: öneki, CE üzerindeki yerel sonraki rotayı, sağlayıcının kabul edeceği duyuruyu ve sağlayıcının geri döndüreceği rotaları. Sözleşmenin dayattığı her filtrelemeyi, önek sınırını veya sahalar arası kısıtlamayı ekleyin. Sağlıklı bir komşuluk bilgi alışverişi kanalıdır ve belirli bir önekin kabul edildiğinin kanıtı değildir; oturum ayakta dururken yeni alt ağınız bir filtrenin içinde olabilir.

Sonra yanıtı izleyin. B şubesinin kaynak LAN'a dönüş rotasına ihtiyacı vardır ve alıcı taraftaki ana makinenin kendi ağ geçidine ve kendi hizmet izinlerine ihtiyacı vardır. CE-A'da görünen bir rota gidiş-dönüşün yalnızca yarısını kurar ve bu yarım gidiş-dönüş, ping testinin bir yönü sağlıklı görünürken uygulamanın hâlâ başarısız olmasının nedenidir.

Kabulden önce iki devri de doğrulayın

İki müşteri kenarında yönlendirme durumunu toplayın, amaçlanan LAN öneklerinin VPN'e kabul edildiğini sağlayıcıyla teyit edin, ardından her yönde izin verilen bir uygulamayı test edin. Yalnızca rota tabloları uygulamanın çalıştığını kanıtlamaz ve yalnızca uygulama testi çalışmadığında hangi kontrol düzleminin başarısız olduğunu söylemez.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Üç çıktıyı birlikte okuyun. Birincisi kenarın neye inandığını, ikincisi neyi hangi eşten öğrendiğini, üçüncüsü gerçekte neyi ileteceğini söyler. Aralarındaki uyuşmazlık genellikle eksik bir duyuru değil, bir ilke veya özyineleme sorunudur ve sağlayıcıdan inceleme istemeden önce çözmeye değer. Bu üç çıktıyı operatörle görüşmeye götürün, çünkü bir destek mühendisinin size soracağı soruların çoğunu yanıtlarlar.

Hizmetin ne sağlamadığını bilin

Bu, 3. katmanın yönlendirilmiş erişimidir. Bu, ofisler arasında yayını genişleten 2. katman devresi değildir, bu nedenle keşif protokolleri, yayına bağımlı uygulamalar ve paylaşılan segment varsayımları onunla birlikte seyahat etmez. Yazdırma, ad taraması ve yerel bir segmente bağlı her şey kendi tasarımına ihtiyaç duyar.

VPN ayrımı da şifreleme değildir. Etiket anahtarlama, müşterileri sağlayıcının ağı içinde ayrı tutar ve sözleşme gizlilik istiyorsa yükü gizli hale getirmez. Bunun önemli olduğu yerde uygulama veya bir üst katman sağlamalıdır.

Son olarak, hizmet modelini sahanın yönlendirme yapılandırmasının yanında yazılı tutun. Alt ağ ekleyecek sonraki mühendis hangi öneklerin duyurulduğunu, kimin kabul ettiğini ve beklenen dönüş yolunun ne olduğunu okuyabilmelidir: BGP/MPLS IP VPN belirtimi tüm bunların arkasındaki modelin referansıdır.