Perutean cabang MPLS: apa yang dipelajari CE, dan dari siapa

Sebuah host di satu cabang membuka koneksi ke server di cabang lain, dan kedua lokasi berada di belakang VPN MPLS lapisan 3 terkelola yang sama. Host hanya mengetahui gateway bawaannya sendiri dan tidak yang lain, yang memang benar. Yang penting adalah tepi pelanggan lokal menyerahkan paket ke tepi penyedianya, dan status perutean VPN penyedia mengantarkannya ke cabang yang memiliki prefiks tujuan.

Menelusuri satu paket sepanjang jalur adalah cara tercepat untuk melihat bagian mana yang menjadi tanggung jawab pelanggan dan bagian mana yang milik layanan.

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

Di mana tugas setiap hop berakhir

CE-A memerlukan rute ke LAN jauh yang mengarah ke koneksi penyedia lokalnya, bukan ke alamat WAN cabang jauh. Penyedia kemudian membawa paket melintasi intinya sendiri menggunakan status perutean VPN, dan CE-B mengantarkannya ke LAN tujuan. Pada titik mana pun host tidak perlu memahami label, VRF, atau sirkuit internet sisi seberang.

Kesalahan yang terus muncul di tiket adalah mengonfigurasi alamat WAN cabang B sebagai hop berikutnya di cabang A. Kedua cabang membeli layanan yang sama, jadi terasa seolah-olah keduanya harus bertetangga. Padahal tidak: hop berikutnya harus dapat dijangkau melalui desain perutean yang benar-benar Anda miliki, dan CE jauh biasanya berjarak banyak hop di balik perangkat yang tidak Anda kelola. Rute statis yang dibangun di atas asumsi itu tampil aktif dan tidak menyelesaikan ke apa pun, yang lebih buruk daripada rute yang hilang karena di tabel tampak benar.

RFC 4364 memisahkan pertukaran antara tepi pelanggan dan tepi penyedia dari distribusi rute VPN oleh penyedia, dan itulah tepatnya batas yang dibahas buku panduan ini. Tugas pelanggan adalah memberi tahu tepinya apa yang dapat diserahkan dan menerima keterjangkauan yang ditawarkan kembali oleh layanan.

Apa yang harus disepakati penyerahan

Pilih mekanismenya bersama penyedia, bukan di sekitarnya. Rute statis, BGP, atau kesepakatan protokol perutean antara CE dan PE semuanya sah, dan OSPF memiliki model MPLS VPN yang terdefinisi untuk penyerahan tersebut. Tidak satu pun dari itu menjadi alasan membangun ketetanggaan OSPF antara dua tepi pelanggan jauh melintasi inti penyedia yang tidak ditentukan, karena itu desain yang tidak disetujui penyedia dan tidak dapat didukungnya.

Sebelum LAN baru beroperasi, tuliskan empat hal: prefiks, rute lokal berikutnya di CE, pengumuman yang akan diterima penyedia, dan rute yang akan dikembalikan penyedia. Tambahkan penyaringan, batas prefiks, atau pembatasan antar lokasi yang diwajibkan kontrak. Ketetanggaan yang sehat adalah saluran pertukaran informasi, dan itu bukan bukti bahwa prefiks tertentu diterima; sesi bisa hidup sementara subnet baru Anda berada di dalam filter.

Lalu ikuti jawabannya. Cabang B memerlukan rute kembali ke LAN sumber, dan host di sisi penerima memerlukan gateway serta izin layanannya sendiri. Rute yang muncul di CE-A menetapkan separuh perjalanan pulang-pergi, dan separuh perjalanan itulah sebabnya satu arah uji ping tampak sehat sementara aplikasi tetap gagal.

Verifikasi kedua penyerahan sebelum persetujuan

Kumpulkan status perutean di kedua tepi pelanggan, konfirmasikan kepada penyedia bahwa prefiks LAN yang dimaksud diterima ke dalam VPN, lalu uji satu aplikasi yang diizinkan di setiap arah. Tabel rute saja tidak membuktikan aplikasi berfungsi, dan uji aplikasi saja tidak memberi tahu Anda bidang kendali mana yang gagal ketika tidak berfungsi.

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

Baca ketiga keluaran bersama-sama. Yang pertama mengatakan apa yang diyakini tepi, yang kedua mengatakan apa yang dipelajari dan dari peer mana, dan yang ketiga mengatakan apa yang sebenarnya akan diteruskannya. Ketidaksepakatan di antaranya biasanya masalah kebijakan atau rekursi, bukan pengumuman yang hilang, dan layak diselesaikan sebelum penyedia diminta menyelidiki. Bawa ketiga keluaran itu ke panggilan dengan operator, karena jawaban mereka mencakup sebagian besar pertanyaan yang akan diajukan insinyur dukungan kepada Anda.

Ketahui apa yang tidak disediakan layanan

Ini adalah akses yang dirutekan pada lapisan 3. Ini bukan sirkuit lapisan 2 yang memperluas siaran antar kantor, sehingga protokol penemuan, aplikasi yang bergantung pada siaran, dan asumsi segmen bersama tidak ikut bersamanya. Pencetakan, penelusuran nama, dan apa pun yang bergantung pada segmen lokal memerlukan desainnya sendiri.

Pemisahan VPN juga bukan enkripsi. Pengalihan label menjaga pelanggan tetap terpisah di dalam jaringan penyedia, dan itu tidak membuat muatan menjadi rahasia jika kontrak mensyaratkan kerahasiaan. Di tempat hal itu penting, aplikasi atau lapisan tambahan harus menyediakannya.

Terakhir, simpan model layanan tertulis di samping konfigurasi perutean lokasi. Insinyur berikutnya yang menambahkan subnet harus dapat membaca prefiks mana yang diumumkan, siapa yang menerimanya, dan apa jalur kembali yang diharapkan: spesifikasi BGP/MPLS IP VPN adalah rujukan untuk model di balik semua ini.