Label per VRF atau per Prefiks? Tagihan Kapasitas yang Sebenarnya

Dua desain mengiklankan prefiks pelanggan yang sama di inti penyedia yang sama. Satu mengalokasikan satu label per prefiks, yang lain mengalokasikan satu label untuk seluruh VRF, dan yang kedua terlihat lebih murah di setiap slide. Jumlah label itu nyata, tetapi bukan anggaran yang biasanya habis lebih dulu. Memilih di antara keduanya berarti menghitung empat sumber daya, bukan satu, dan label adalah yang terkecil di antaranya.

Pilihan juga bergantung pada apa yang harus dilakukan router egress terhadap paket setelah melepas label. Perbedaan fungsional itulah, bukan aritmetika label, yang seharusnya memandu keputusan.

Apa yang sebenarnya dihemat setiap alokasi

Alokasi per prefiks membawa informasi penerusan di dalam label. Router egress dapat mengirim paket langsung ke adjacency yang tepat tanpa pencarian tujuan, itulah sebabnya ia berskala baik untuk kumpulan rute VRF besar dan sebabnya ia menghabiskan satu label untuk setiap prefiks yang diiklankan di setiap VRF. Alokasi per VRF, seperti Junos vrf-table-label, mengiklankan satu label per instans routing dan menggunakan label itu untuk memilih tabel VRF; router kemudian melakukan pencarian IP di dalam tabel.

Itu perbedaan arsitektural yang nyata, bukan tombol penyetelan. Pelabelan per VRF memberi ruang label yang lebih kecil dan iklan label yang lebih sederhana, dengan biaya satu pencarian dan label yang tidak mengatakan apa pun tentang tujuan. Pelabelan per prefiks memberi kartu jalur egress lebih banyak informasi di awal dan memakan label sebanding dengan rute yang Anda bawa.

Buku besar label adalah yang kecil

Label MPLS terbatas, tetapi ruang label cukup besar sehingga penyedia layanan biasa tidak menghabiskannya dengan beberapa ribu prefiks. Tempat pelabelan per VRF benar-benar membantu adalah pada platform dengan tabel label perangkat keras kecil, atau pada desain di mana satu VRF membawa feed Internet penuh dan label per prefiks akan mengalikan permintaan label dengan jumlah rute. Itu kendala nyata, dan itulah alasan fitur ini ada. Tidak satu pun dari itu tentang jumlah prefiks di tabel.

Hitung label untuk layanan dan untuk transport sebelum memilih. Desain per VRF tetap membutuhkan label transport untuk loopback dan untuk setiap hop di sepanjang jalur, dan tetap membutuhkan status adjacency. Jika ringkasan desain hanya menghitung label layanan, penghematan diukur pada buku besar yang salah.

Feed rute memakan memori sebelum label

Setiap jalur yang diterima memakan memori bidang kendali, pemrosesan pembaruan, dan waktu konvergensi, baik VRF memakai satu label maupun sepuluh ribu. Feed Internet penuh di dalam VRF mahal karena jalur BGP, RIB, entri FIB, dan gejolak di belakangnya, bukan karena label yang berada di depan tabel. Feed yang sama juga memperbesar radius dampak kebocoran rute atau kesalahan kebijakan di dalam penyewa itu.

Jadi tanyakan apa yang sebenarnya dibutuhkan pelanggan. Jika kontraknya adalah situs privat plus jalan keluar default, tabel penuh menambah biaya tanpa menambah persyaratan. Itu pertanyaan komersial, dan itu layak mendapat jawaban tertulis alih-alih asumsi yang diwarisi dari desain sebelumnya. Jika layanan benar-benar membutuhkan feed untuk kebijakan atau untuk pemilihan egress lokal, jadikan itu item baris eksplisit dengan reservasi kapasitasnya sendiri dan perilaku kegagalannya sendiri.

Kapan pelabelan per VRF menjadi default yang tepat

Itu default yang baik ketika platform mendokumentasikannya sebagai didukung, ketika jumlah rute VRF besar, dan ketika biaya pencarian egress dapat diterima untuk profil lalu lintas. Itu juga pilihan alami ketika kesederhanaan operasional lebih penting daripada memeras mikrodetik terakhir dari penerusan, karena satu label per penyewa lebih mudah dijelaskan dan diaudit daripada satu label per prefiks.

Itu default yang salah ketika dokumentasi platform mengikat fitur ke batasan perangkat keras atau rilis tertentu, atau ketika desain bergantung pada keputusan penerusan per prefiks di egress. Baca referensi statement platform itu sendiri sebelum mengasumsikan perilakunya; perintah Junos didokumentasikan, tetapi batas perangkat keras dan rilis di sekitarnya yang sebenarnya menentukan penerapan.

Anggaran yang bisa Anda pertahankan

Bangun kasus kapasitas sebagai lima angka terpisah: jalur yang diterima, rute yang dipilih, entri penerusan yang terpasang, label layanan, dan label transport. Tambahkan status next-hop dan adjacency, jumlah penyewa, dan model redundansi. Snapshot jalur bahagia satu VRF bukanlah angka skala, dan ukuran nominal ruang label bukanlah tabel perangkat keras yang tersedia.

Lalu sepakati mode kegagalan sekaligus kondisi mantap. Apa yang terjadi ketika feed tumbuh setengah, ketika penyewa menambah VRF kedua, atau ketika platform perlu reboot untuk mengubah ukuran tabel? Anggaran yang bertahan dari pertanyaan itu lebih bernilai daripada jumlah label yang hanya bekerja di atas kertas.

Pilih alokasi dari tindakan egress dan batas platform, lalu jadikan feed rute keputusan layanan yang eksplisit. Label adalah bagian yang terlihat dari desain; rute adalah bagian yang harus dibayar setiap hari.