Serah terima L3VPN: rute privat, rute default, atau tabel penuh?

Sirkuit Anda sudah aktif, VRF sudah dikonfigurasi, dan penyedia mengajukan satu pertanyaan singkat yang menentukan sisa desainnya: apa yang harus diterima sisi pelanggan (CE)? Tiga jawaban lazim ditemui, dan tidak satu pun mengikuti fakta bahwa ada tumpukan label. Semuanya adalah keputusan layanan tentang dari mana lalu lintas meninggalkan cabang.

Menelusuri serah terima secara berurutan adalah cara termurah untuk melakukannya dengan benar. Anda mulai dari apa yang terjadi pada lalu lintas yang tidak cocok dengan apa pun, lalu menuliskan prefiks privat dan perilaku kegagalannya, dan baru setelah itu membahas seberapa besar umpan rute yang sanggup Anda bawa.

Mulai dari lalu lintas yang tidak direncanakan siapa pun

Ajukan satu pertanyaan sebelum daftar prefiks apa pun muncul: ketika sebuah paket tidak cocok dengan rute privat mana pun, ke mana ia harus pergi? Cabang yang punya sirkuit internet sendiri biasanya menyimpan default lokal, sehingga lalu lintas web biasa keluar melalui firewall lokal dan tidak pernah menyentuh penyedia. Dalam desain itu, VPN hanya membawa situs privat jarak jauh, dan prefiks yang lebih spesifik yang melakukan pemilihan.

Cabang yang dimaksudkan memakai pintu keluar terpusat adalah kasus sebaliknya. Di sana default menunjuk ke layanan, dan penyedia atau situs pusat memiliki penerusan, perutean balik, dan penerjemahan apa pun. Mengatakan "default ke VPN" tanpa pemilik itu hadir menghasilkan cabang yang bisa me-resolve nama tetapi tidak mencapai apa pun.

Kedua desain berbeda dalam bentuk kegagalan peruteannya, dan itulah sebabnya menebak itu mahal. Dengan default lokal, rute privat yang hilang mengirim lalu lintas itu ke internet, tempat ia dibuang oleh firewall atau, lebih buruk, dijawab oleh sesuatu yang tidak Anda maksudkan. Dengan default terpusat, kehilangan yang sama menghapus akses internet sepenuhnya dan tiketnya datang sebagai "seluruh cabang mati". Tidak ada kegagalan yang salah dengan sendirinya, tetapi hanya satu yang cocok dengan layanan yang Anda jual, dan konfigurasi BGP saja tidak akan memberi tahu yang mana yang Anda bangun.

Tuliskan prefiks privat beserta kasus kegagalannya

Daftar prefiks yang harus dijangkau cabang dan catat mana yang diringkas. Agregat yang satu bit terlalu lebar menarik tujuan tak dikenal masuk ke VPN, dan itu hanya boleh jika sisi jauh benar-benar memilikinya dan meneruskannya.

Lalu jelaskan perilaku yang dimaksudkan ketika layanan privat gagal. Rute discard yang dipertahankan menjauhkan lalu lintas dari jalur yang tidak sah dan menghasilkan pemadaman yang bersih dan terduga. Default mengambang dapat mempertahankan ketersediaan dengan berpindah ke jalur cadangan, tetapi hanya jika jalur cadangan itu berwenang membawa lalu lintas tersebut.

Pertahankan ketersediaan dan fallback yang diizinkan sebagai dua persyaratan terpisah dalam dokumen serah terima. Tim yang menggabungkannya akhirnya berdebat apakah cabang seharusnya gagal, bukan memeriksa apakah kebijakan yang disepakati sudah diterapkan.

Periksa apa yang sebenarnya dipasang CE

Niat konfigurasi dan status penerusan cukup sering menyimpang, sehingga verifikasi pantas masuk ke serah terima, bukan ke tinjauan insiden. Pada customer edge IOS-XE, tiga perintah di bawah menjawab tiga pertanyaan berbeda: apa yang ditawarkan, apa yang diterima, dan apa yang benar-benar dipakai.

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

Jalankan ketiganya pada hari serah terima, bukan sebulan kemudian, selagi masih ada orang yang ingat apa yang disepakati. Keluaran pertama bergantung pada soft-reconfiguration inbound atau route refresh yang tersimpan; tanpa salah satunya, CE tidak dapat menunjukkan apa yang ia tolak. Yang kedua menunjukkan jalur yang diterima dan terbaik setelah kebijakan. Yang ketiga memberi tahu ke mana default benar-benar pergi, dan itulah satu baris paling berguna di seluruh serah terima.

Jalankan pemeriksaan yang sama pada CE kedua jika situs memakai dua tautan. Penerimaan asimetris antara dua tepi adalah penyebab umum "berfungsi dari satu server tetapi tidak dari server lain", dan hal itu tak terlihat dalam diff konfigurasi yang tampak simetris.

Kualifikasikan umpan yang lebih besar, jangan mengasumsikannya

Kadang pelanggan benar-benar membutuhkan informasi jalur internet di dalam VRF, untuk policy routing atau untuk pintu keluar terpusat yang mengarahkan berdasarkan prefiks. Itu adalah persyaratan yang harus dinyatakan, dibatasi cakupannya, dan dihargai, bukan default tersembunyi. Ia membawa serta memori untuk RIB dan FIB, CPU untuk pembaruan, pemeliharaan filter, dan pemilik untuk tabel yang dihasilkan.

Argumen kapasitas bisa salah ke dua arah. Tabel penuh tidak dilarang di dalam VRF, dan juga tidak gratis. Sebaliknya, Anda tidak bisa menyimpulkan biaya hari ini dari jumlah rute lama, dan alokasi label yang lebih kecil tidak menghapus biaya penyimpanan rute.

Spesifikasi BGP/MPLS IP VPN membahas beberapa pengaturan akses internet di samping layanan VPN itu sendiri, dan tidak menyatakan tabel penuh atau default sebagai wajib bagi setiap pelanggan, dan itulah bagian yang layak ditunjuk ketika klaim tentang "praktik standar" muncul: RFC 4364.

Tutup serah terima dengan mencatat kumpulan yang diiklankan, kumpulan yang diterima, dan kumpulan yang dipilih di samping kebijakan keluar yang disepakati, serta menguji satu tujuan privat, satu tujuan publik yang dimaksudkan, dan satu kasus kehilangan rute. Catatan bertanda tangan atas ketiga uji itu menyelesaikan lebih banyak perdebatan daripada pernyataan apa pun tentang apa yang dilakukan kebanyakan jaringan.