Mengapa menggunakan iBGP di dalam Sistem Otonom, jika protokol IGP memenuhi kebutuhan untuk komunikasi internal


22

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:


26

Adakah yang bisa menjelaskan kepada saya apa perlunya komunikasi IBGP untuk rute, ketika kita memiliki protokol IGP (OSPF, RIP) untuk komunikasi internal?

  • Skalabilitas 1 : Bayangkan Anda menerima 500.000 rute EBGP di lebih dari satu lokasi 2 , dan Anda perlu memengaruhi titik keluar per rute di AS. BGP dapat menangani lebih banyak rute daripada protokol IGP. Dengan demikian, iBGP diperlukan kecuali Anda bersedia mendistribusikan ulang semua rute yang telah Anda pelajari melalui eBGP
  • 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).


Catatan Akhir:

1 Skalabilitas :

  • Anda menggunakan BGP karena Anda tidak ingin membawa seluruh tabel perutean internet di IGP Anda (yaitu dalam kasus saya, OSPF) ...
  • OSPF tidak dirancang untuk menangani ribuan rute dalam tabel BGP internet ... jika Anda mencoba menggunakan OSPF untuk tujuan ini, itu akan merusak jaringan Anda. Menggunakan contoh OSPF, persyaratan pemrosesan / banjir LSA dari 500.000 rute menggunakan terlalu banyak sumber daya di router Anda. Sebutkan IGP lainnya (EIGRP, RIPv1 / 2, IS-IS, IGRP) dan kisah yang sama juga benar.
  • Ada beberapa contoh yang terkenal di mana ISP Tier-1 secara tidak sengaja mendistribusikan ulang tabel BGP mereka ke dalam IGP mereka (bahkan ketika tabel internet sebagian kecil dari ukurannya saat ini) dan itu menyebabkan pemadaman besar. Penanggulangan sekarang telah diimplementasikan dalam protokol IGP ( seperti ini untuk OSPF di iOS ) untuk mencegah redistribusi dari BGP ke OSPF dari menyebabkan pemadaman besar.

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 bestbawah 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.


Tidak yakin apakah saya memahami bagian ini: 'iBGP diperlukan kecuali Anda bersedia untuk mendistribusikan kembali semua rute yang telah Anda pelajari melalui eBGP'. Jika kita memiliki dua router eBGP perbatasan, router A tidak akan tahu rute yang dipelajari router B, atau sebaliknya. Mereka perlu saling bertukar informasi dan ini biasanya dilakukan menggunakan iBGP. Bagaimana Anda menggunakan eBGP untuk ini? Saya tidak yakin bagaimana eBGP dapat membuat A dan B keduanya mengetahui rute yang dipelajari router lain.
user4205580

Pernyataan yang Anda maksudkan berasumsi bahwa Anda memiliki beberapa pembicara non-eBGP. Dengan asumsi Anda tidak bisa hanya hidup dengan rute default ke upstreams eBGP Anda, pada titik ini Anda dapat: A) mendistribusikan ulang awalan eBGP ke IGP Anda (biasanya ide yang buruk), atau B) menggunakan iBGP. Jawaban saya menghabiskan sebagian besar waktu menjelaskan mengapa iBGP bermanfaat.
Mike Pennington

10

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.



3
Path vector pada dasarnya adalah case spesifik dari distance vector. Sangat penting untuk menyadari bahwa mereka sangat mirip dalam kompleksitas dan biaya sementara keadaan-link benar-benar berbeda. Dari buku BGP Sam Halabi dan Danny McPhersons, halaman 98 'Bagian ini tidak akan lengkap tanpa menyebutkan bahwa BGP termasuk dalam kategori vektor jarak'
ytti

2
Path vector mirip tetapi masih algoritma yang berbeda. Anda dapat membaca lebih lanjut tentang ini dalam buku Danny McPherson dan Russ White, Practical BGP , yang diterbitkan pada tahun 2004. Tautan seluler
Mike Pennington

2
Halaman mana yang mengklaim BGP bukan vektor jarak?
ytti

2
Jalur AS adalah vektor jarak. Ya, Anda dapat memanipulasi pemilihan jalur secara opsional dengan parameter lain juga. Jadi Sam dan Danny meletakkannya sebagai vektor jalur selain menjadi vektor jarak, saya sepenuhnya berbagi pandangan mereka tentang masalah ini. Mungkin cara yang menyenangkan untuk mengkonsumsi pint untuk berdebat tentang masalah ini, tetapi tidak konstruktif.
ytti

7

Salah satu alasan yang sering saya lihat adalah kejelasan: semua rute dilakukan dalam satu protokol routing (BGP), IS-IS, OSPF atau RIP hanya digunakan untuk adjacency. Akibatnya, tidak perlu lagi mendistribusikan rute dari satu protokol routing ke protokol routing lainnya.


3

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)

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.