Saat mengonfigurasi MP-BGP, pada perangkat keras Juniper, situasi pembentukan kembali lingkungan (yang tidak jelas) mungkin muncul. Alasannya dijelaskan secara rinci di dalam Basis Pengetahuan Junuper KB20870 , berikut adalah pengisahan ulang singkat dengan komentar saya.
Seperti yang Anda ketahui, saat bekerja dengan VPN, beberapa tabel routing digunakan. Kami akan tertarik pada 2 yang utama: vrf.inet.0 dan bgp.l3vpn.0 (selanjutnya dijelaskan situasi dengan L3VPN, tetapi ini juga berlaku untuk layanan lain di mana BGP adalah protokol pensinyalan).
Tabel bgp.l3vpn.0 berisi semua rute yang diterima dari tetangga BGP.
Rute langsung / statis dari router PE tertentu ditempatkan di tabel vrf.inet.0 , dan rute yang masuk dari tetangga dari tabel bgp.l3vpn.0 yang memenuhi kebijakan impor (jika dikonfigurasi) juga diimpor.
Pada saat yang sama, ekspor dari vrf.inet.0 ke bgp.l3vpn.0 tidak terjadi, dan rute diumumkan secara langsung ke tetangga.
Jika router bertindak sebagai reflektor rute, atau jika ada tetangga MP eBGP, rute ditempatkan baik di tabel vrf.inet.0 dan di bgp.l3vpn . Dalam hal ini, perbandingan dibuat dengan rute lokal dan (jika perlu) jalur terbaik dipilih.
Dengan demikian, router dapat beroperasi di salah satu dari dua mode yang ditentukan:
- tidak ada reflektor router yang dikonfigurasi pada router dan tidak ada tetangga eBGP;
- router adalah reflektor rute dan / atau ada tetangga eBGP di atasnya.
Mengubah mode memerlukan memulai kembali sesi MP-BGP. Jelas, ini bisa dilihat pada topologi berikut:
Pada versi pertama (Gbr. 1), skema iBGP full-mesh klasik disajikan. Sekarang bayangkan kita perlu menambahkan router R4. Untuk satu alasan atau yang lain, kami memutuskan untuk melakukan ini dengan menetapkan R1 sebagai reflektor rute untuk R4 (Gbr. 2). Melakukan pengaturan reflektor rute pada R1 akan memerlukan penginstalan ulang semua sesi MP-BGP (dengan router R2 dan R3), yang akan menyebabkan downtime dalam penyediaan layanan.
Untuk menghindari hal ini, diusulkan untuk mentransfer router ke mode operasi ke-2. Salah satu caranya adalah membuat grup eBGP dummy. Sebagai contoh:
group fake-vpn { type external; description "## Preventing mpbgp sessions flap ##"; passive; family inet { any; family inet-vpn { any; family iso-vpn { unicast; family l2vpn { signaling; family evpn { signaling; family inet-mvpn { signaling; family inet-mdt { signaling; neighbor 192.0.2.1 { peer-as 65536; }
AS: 65536 dan IP: 192.0.2.1 dapat menjadi segalanya, dan mode pasif memungkinkan Anda menghindari upaya yang tidak perlu untuk membuat sesi yang tidak ada dari router.
Kapan mungkin berguna:
- tidak ada reflektor rute khusus pada jaringan. Peran RR adalah router inti dari jaringan. Pada saat yang sama, ada kemungkinan perubahan peran mereka (misalnya, dari P-router ke P / RR atau sebaliknya);
- ada kemungkinan antarmuka eBGP akan muncul dengan keluarga MP-BGP, misalnya Inter-AS.