Dari rute CE RIP ke VRF jarak jauh: di mana ekspor terjadi

Pembaruan RIPv2 tiba di tepi penyedia, masuk ke tabel perutean VRF, dan berhenti di sana kecuali ada yang mengekspornya secara eksplisit. Tiga keputusan terjadi berurutan, dan masing-masing dapat menolak prefiks karena alasannya sendiri. Membacanya sebagai satu peristiwa adalah alasan orang mengejar perangkat yang salah ketika situs jarak jauh tidak dapat mencapai jaringan yang jelas diiklankan oleh CE. Ikuti rute melalui PE dan urutannya menjadi jelas.

Apa yang PE lakukan dengan pembaruan RIP

PE menerima pembaruan pada antarmuka VRF, memeriksa bahwa sumbernya adalah tetangga yang diizinkan, dan memasang prefiks ke tabel perutean VRF dengan jumlah hop yang diturunkan dari iklan. Tabel itu adalah tabel perutean biasa dengan jarak administratif sendiri dan pemilihan jalur terbaik sendiri. Jika CE mengiklankan prefiks yang sama dua kali dengan metrik berbeda, hanya yang lebih baik bertahan di tabel. Tidak ada bagian dari langkah ini yang melibatkan backbone penyedia.

Prefiks sekarang ada di dalam konteks perutean satu pelanggan, yang jauh dari dapat dijangkau di tempat lain.

Ekspor adalah tindakan kebijakan, bukan konsekuensi protokol

Untuk meninggalkan VRF, rute harus didistribusikan ulang ke dalam proses MP-BGP yang membawa rute VPN, dan rute itu membutuhkan komunitas diperluas target rute yang mengidentifikasi VRF jarak jauh mana yang boleh mengimpornya. Arsitektur dalam RFC 4364 menjaga pertukaran itu terpisah dari protokol CE-ke-PE justru karena alasan ini. Menggunakan RIP di tepi tidak mengatakan apa pun tentang apa yang harus melintasi jaringan penyedia.

Tuliskan kontrak ekspor sebelum mengonfigurasi apa pun: prefiks pelanggan yang harus dapat dijangkau dari jarak jauh, rute yang harus tetap lokal, dan semua default, lebih spesifik, atau pengecualian layanan bersama. Cocokkan kontrak itu dengan VRF yang sebenarnya, bukan dengan VRF bernama serupa milik pelanggan lain.

Sisi impor adalah kebijakan kedua dengan target rutenya sendiri, dan ekspor yang cocok dengan impor yang tidak cocok menghasilkan prefiks yang ada di backbone dan tidak muncul di tabel jarak jauh mana pun.

Redistribusi dan origination eksplisit berperilaku berbeda

Redistribusi mengambil rute yang sudah ada di tabel VRF dan menyalinnya ke BGP, disaring oleh peta rute. Peta memutuskan prefiks mana yang memenuhi syarat dan atribut apa yang dibawanya, dan metrik harus ditetapkan secara eksplisit karena jumlah hop RIP tidak bermakna sebagai metrik BGP. Apa pun yang Anda biarkan tidak diatur diwarisi dengan cara yang biasanya mengejutkan orang yang membaca konfigurasi enam bulan kemudian.

Redistribusi timbal balik adalah tempat kerusakan senyap terjadi. Prefiks yang diekspor ke BGP dapat kembali melalui titik redistribusi kedua, dan tanpa tag atau filter rute berayun sementara kedua tabel tampak masuk akal pada setiap saat. Saring berdasarkan tag yang diterapkan di tepi alih-alih mengandalkan topologi untuk mencegah jalur kembali.

Origination eksplisit terlihat lebih rapi dan tidak tanpa syarat. Pernyataan jaringan biasanya membutuhkan rute yang cocok di tabel perutean sebelum prefiks dioriginasikan, sehingga iklan hilang pada saat CE berhenti mengiklankannya. Itu sering merupakan perilaku yang Anda inginkan, dan itu tidak sama dengan rute statis yang tetap dikonfigurasi selamanya. Periksa aturan sebenarnya platform alih-alih mengasumsikan salah satu perilaku.

Bagaimanapun, pertanyaan yang harus diajukan tentang setiap prefiks adalah sumber aktif mana yang membuatnya memenuhi syarat dan apa yang terjadi ketika sumber itu hilang.

Verifikasi rantai di empat tempat

Lihat iklan CE, tabel perutean VRF, tabel rute VPN dengan target rutenya, dan impor VRF jarak jauh, dalam urutan itu. Di IOS itu berarti keluaran tetangga CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, dan perintah yang sama di PE jauh. Di IOS-XR keluaran yang setara berada di bawah show bgp vrf CUSTOMER ipv4 unicast. Nama perintahnya berbeda, empat titik pemeriksaan tidak.

Periksa prefiks yang seharusnya ditolak dengan hati-hati seperti yang seharusnya lolos, karena kebijakan yang mengizinkan semuanya terlihat identik dengan yang benar sampai pengecualian pertama datang. Lalu amati penarikan: matikan antarmuka CE, dan pastikan entri jarak jauh hilang dalam timer yang diharapkan alih-alih bertahan.

Catat siapa yang memiliki setiap kebijakan. Ketika penyedia menjalankan CE, perilaku yang dikirimkan termasuk dalam kontrak layanan, dan protokol atau kebijakan penarikan yang berbeda pada perangkat terkelola adalah masalah dokumentasi sebelum menjadi masalah perutean.