Menentukan ukuran VPN bintang besar: hitung dulu sebelum memilih BGP
Prefiks adalah angka yang mudah. Sesi, gelombang pembaruan, dan pemulihan setelah kegagalan hub yang menentukan apakah desain bertahan di beberapa ribu cabang.
Tiga ribu cabang terdengar seperti masalah perutean tetapi berperilaku seperti masalah pembukuan. Total prefiks selesai dihitung dalam sepuluh menit, dan jarang itu angka yang menyakitkan. Yang menyakitkan adalah pekerjaan per sesi, gelombang pembaruan saat komponen bersama gagal, dan waktu sampai penerusan kembali cocok dengan topologi baru.
Jadi telusuri aritmetikanya dalam urutan yang benar. Hitung relasinya, hitung prefiks dan alternatifnya, lalu hitung apa yang terjadi pada jam buruk, dan baru setelah itu bandingkan protokol dan platform. Dalam urutan terbalik, latihan ini berubah menjadi perdebatan tentang batas rute yang tidak bisa diselesaikan siapa pun dengan informasi di atas meja.
Empat anggaran, bukan satu
Setiap anggaran menjawab pertanyaan berbeda, dan masing-masing bisa menjadi kendala pengikat di platform berbeda. Menuliskannya terpisah mencegah satu angka prefiks besar menggantikan seluruh desain.
| Budget | What you are really counting |
|---|---|
| Sessions | Peers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count |
| Prefixes | Alternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see |
| Churn | Updates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event |
| Recovery | Time to detect, reselect, reinstall and restore the application, measured end to end rather than per box |
Dua yang terakhir adalah yang dilewati dalam tinjauan desain. Jaringan yang dengan nyaman masuk memori dalam keadaan tunak tetap bisa berperilaku buruk ketika empat ratus cabang menyambung ulang dalam dua menit, karena pekerjaan tiba lebih cepat daripada kemampuan bidang kendali mengurasnya. Tuliskan ukuran gelombang sebagai angka, bersama berapa lama layanan boleh tetap terdegradasi. Itu mengubah kekhawatiran samar menjadi uji yang benar-benar bisa dijalankan seseorang.
Ada juga pertanyaan platform yang tersembunyi di keempatnya: apakah enkripsi, penerusan, dan perutean berbagi satu CPU atau memiliki jalur terpisah. Dua perangkat dengan kapasitas rute identik dapat berperilaku sangat berbeda di bawah gelombang, dan lembar data jarang menyebut mana yang Anda beli.
Lakukan aritmetika dengan angka Anda sendiri
Ambil desain rekaan: 3,000 cabang, masing-masing tiga prefiks sebelum agregasi, dan dua hub per cabang untuk redundansi. Pasangan hub harus menampung sekitar 9,000 prefiks cabang sebelum ringkasan, dan desain itu menyiratkan 6,000 sesi cabang-ke-hub jika setiap cabang berpeering dengan keduanya.
Sekarang tambahkan bagian yang bukan prefiks. Setiap sesi membawa status dan pesan berkala meski tidak ada yang berubah. Setiap hub dapat menyimpan lebih dari satu jalur per prefiks jika diharapkan beralih cepat, sehingga jumlah alternatif bisa melebihi jumlah yang dipilih. Dan pandangan setiap spoke adalah keputusan kebijakan tersendiri: memberi setiap cabang rute semua cabang lain melipatgandakan pekerjaan dengan cara yang tidak diungkapkan hitungan sisi hub.
Itu angka perencanaan untuk percakapan desain, bukan pengukuran produk mana pun. Keluaran berguna dari latihan ini adalah bentuk kurvanya, bukan klaim tentang di mana router tertentu menyerah.
Apa yang BGP berikan kepada Anda, dan apa yang diberikan IGP
BGP memisahkan apa yang diterima router, apa yang dipilihnya, dan apa yang diumumkannya, dan masing-masing dikendalikan kebijakan. Itulah tepatnya yang dibutuhkan jaringan cabang, karena spoke biasanya harus melihat rute default, layanan pusat, dan sangat sedikit lainnya. Menghitung hanya tabel akhir menyembunyikan alternatif dan pengumuman, dan justru itulah bagian yang tumbuh ketika Anda menambah redundansi.
IGP tidak otomatis salah. Ketika topologi, struktur area, dan model ketetanggaan cocok dengan layanan, protokol link-state berkonvergensi cepat dan membutuhkan lebih sedikit perancah kebijakan. Jebakannya adalah menganggapnya dapat menyatakan kontrol ekspor per tetangga yang sama seperti BGP: area OSPF adalah batas banjir, bukan filter yang bisa digantungkan pada satu cabang.
Apa pun pilihannya, tentukan model visibilitas lebih dulu. Rute default, ringkasan untuk layanan pusat, atau detail cabang penuh adalah tiga produk berbeda, dan ringkasan yang menyembunyikan kegagalan lebih spesifik adalah keputusan desain yang harus dituliskan, bukan ditemukan saat gangguan.
Uji gelombangnya, bukan keadaan tunaknya
Bangun perbandingan di sekitar kegagalan yang benar-benar Anda harapkan: hub mati, peristiwa WAN regional, atau jendela pemeliharaan yang mematikan separuh situs sekaligus. Ukur pemulihan dari sudut pandang cabang, termasuk aplikasinya, karena bidang kendali yang berkonvergensi dalam hitungan detik berarti sedikit jika sesi butuh menit untuk pulih.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFCatat apa yang dilakukan platform pada puncak gelombang dan bukan saat diam, lalu ulangi dengan fitur keamanan aktif. Bukti konsep yang hanya menunjukkan tabel tenang adalah uji memori, dan memori tidak pernah menjadi angka yang menarik.