Adakah yang bisa menjelaskan mengapa kita membutuhkan iBGP untuk rute ketika kita memiliki protokol IGP (OSPF, RIP) untuk komunikasi internal dalam AS?
Saya telah membaca banyak artikel dan buku, tetapi saya tidak dapat menemukan jawabannya.
Adakah yang bisa menjelaskan mengapa kita membutuhkan iBGP untuk rute ketika kita memiliki protokol IGP (OSPF, RIP) untuk komunikasi internal dalam AS?
Saya telah membaca banyak artikel dan buku, tetapi saya tidak dapat menemukan jawabannya.
Jawaban:
Adakah yang bisa menjelaskan kepada saya apa perlunya komunikasi IBGP untuk rute, ketika kita memiliki protokol IGP (OSPF, RIP) untuk komunikasi internal?
Menegakkan batas-batas kepercayaan / kontrol: BGP memiliki lebih banyak cara untuk menyaring rekan-rekan daripada IGP (untuk mengendalikan apa yang Anda iklankan dan terima).
Struktur data yang fleksibel (agak terkait dengan bullet sebelumnya): komunitas BGP , komunitas BGP Extended , local-pref , dll ... ini menjadikan BGP cara yang menarik untuk menerapkan kebijakan perutean kustom dalam sistem otonom Anda sendiri (dengan menggunakan iBGP).
Seperti halnya semua ada kompromi; skalabilitas, kontrol, dan fleksibilitas yang Anda dapatkan dari iBGP berarti protokol ini lebih lambat daripada IGP (secara umum).
1 Skalabilitas :
2 contoh perutean iBGP :
Untuk memahami mengapa Anda ingin iBGP, pertimbangkan entri perutean ini ke 4.2.2.2 ...
R2>sh ip bgp 4.2.2.2
BGP routing table entry for 4.0.0.0/9, version 3146
Paths: (32 available, best #7, table Default-IP-Routing-Table)
... <!-- extra BGP RIB entries deleted -->
7660 2516 3356, (aggregated by 3356 4.69.130.4)
203.181.248.168 from 203.181.248.168 (203.181.248.168)
Origin IGP, localpref 100, valid, internal, atomic-aggregate
Community: 2516:1030
3356, (aggregated by 3356 4.69.130.6)
4.69.184.193 from 4.69.184.193 (4.69.184.193)
Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2012
... <!-- extra BGP RIB entries deleted -->
Ada 32 jalur untuk dipertimbangkan ... Dalam hal ini, BGP memilih untuk pergi ke 4.0.0.0/9 melalui 4.69.184.193 (perhatikan bagian di best
bawah entri RIB). Dalam hal ini, BGP memilih ini karena rute ini memiliki daftar AS Path terpendek. Namun, tidak semua rute akan lebih disukai melalui AS3356 (terlampir pada R1). Beberapa mungkin lebih disukai dari R3 (melalui AS7660). iBGP memberi Anda kemampuan untuk mengetahui (pada R2) ke mana harus pergi untuk mengambil jalur BGP terpendek.
BGP route to 4.0.0.0/9 via
NH: 4.69.184.193 [Path: 3356]
-------->
eBGP w/ AS3356 }{ iBGP inside AS64000 }{ eBGP w/ AS7660
S1/0 S1/2 S2/1 S2/3 S3/2 S3/0
Peered w/ AS3356 +------+ +------+ +------+ Peered w/ AS7660
4.69.184.193 <------| R1 |---------| R2 |--------| R3 |-----> 203.181.248.168
+------+ +------+ +------+
| S2/0
|
^
^
| Ingress packet to 4.2.2.2
|
R1, R2, dan R3 sepenuhnya terhubung ke iBGP. Ketika iBGP mengiklankan rute, hop berikutnya tetap tidak berubah . Ini berarti saya harus membawa subnet untuk 4.69.184.193 di OSPF ...
R2>sh ip route 4.69.184.193
Routing entry for 4.69.184.192/30
Known via "ospf 100", distance 110, metric 65536, type intra area
Last update from 192.0.2.109 on GigabitEthernet3/1, 1w0d ago
Routing Descriptor Blocks:
* 192.0.2.109, from 192.0.2.3, 1w0d ago, via Serial2/1
Route metric is 65536, traffic share count is 1
R2>
Jadi ketika sebuah paket untuk 4.2.2.2 tiba di R2, R2 mengirimkannya ke Serial2 / 1 karena di situlah iBGP memberitahu kita next-hop.
IGP biasanya adalah OSPF atau ISIS yang berbasis link-state, ini memberi kita semua informasi jaringan, semua orang tahu jaringan dari sudut pandang semua orang, yang memungkinkan untuk opsi konvergensi yang sangat menarik dan opsi rekayasa lalu lintas.
BGP pada dasarnya adalah distance-vector, ia tahu pandangan yang sangat terbatas pada jaringan secara keseluruhan. BGP menangani penyaringan dengan sangat baik dan memodifikasi informasi routing.
Protokol link-state cukup mahal dibandingkan dengan distance-vector, itu akan cukup bermasalah untuk skala itu ke ukuran INET DFZ.
Jadi alasan mengapa kita memiliki keduanya, adalah karena di dalam satu jaringan tertentu, kita memiliki kompleksitas yang cukup rendah untuk menanganinya dengan protokol link-state, yang memungkinkan kita untuk mendapatkan semua keuntungan dari tingkat pengetahuan jaringan yang tinggi.
Tetapi karena ukurannya tidak sesuai dengan ukuran Internet, kami membutuhkan jaringan lain untuk menghubungkan banyak pulau-pulau penghubung ini.
Anda bisa di dalam jaringan Anda sendiri membawa semua awalan (termasuk pelanggan) di IGP Anda, tetapi itu akan berdampak negatif pada kinerja IGP, sementara semua keuntungan konvergensi dan TE dapat diperoleh dengan hanya membawa alamat loopback dari router inti. Menambahkan awalan pelanggan ke IGP hanya akan merusak kinerja jaringan Anda dengan membuat IGP tidak perlu rumit.
iBGP tidak benar-benar digunakan untuk perutean internal, ini digunakan oleh semua perute eBGP Anda untuk berbagi rute mereka.
Mis: Jika Anda mengintip dengan 3 jaringan lain, Anda ingin semua router eBGP Anda mengetahui rute yang diterima oleh yang lain sehingga mereka dapat menyebarkan informasi itu ke rekan-rekan jika perlu / dibutuhkan (membuka dengan demikian kemungkinan rekan Anda menggunakan transit melalui kamu)