Konfigurasi Internal External BGP dan Penjelasan Konsepnya

Akan selalu ada pertanyaan seperti ini: “Apa bedanya internal BGP (iBGP) dengan external BGP (eBGP)?”

… yang biasanya selalu diiikuti dengan jawaban seperti ini,

“Internal BGP jika peering BGP dilakukan dengan sesama AS (Autonomous System). Sedangkan external BGP jika peering BGP dengan berbeda AS number.”

Selesai, easy!

Ya, kan?

Jawabannya tidak salah. Jika yang menjawab adalah orang awam, bukan network engineer.

Kita sebagai network engineer hendaknya memahami bahwa perbedaan antara iBGP dengan eBGP itu tidak sekedar sama atau beda AS number yang digunakan.

Melainkan harus benar-benar paham seperti apa mekanisme penerimaan dan penyebaran routingnya atau bagaimana behaviour iBGP dengan eBGP terhadap well known mandatory attribute NEXT_HOP dan AS_PATH nya.

Inilah yang akan kita bahas.

Lab Internal dan External BGP

Ada topologi yang menurut saya lumayan ideal untuk belajar pemahaman konsep dasar internal dan external BGP juga konfigurasinya, seperti berikut:

internal-external-bgp
Gambar 1: Topologi Konfigurasi Internal dan External BGP

Skenario lab yang akan kita buat nantinya seperti ini:

  • Loopback 0 (1.1.1.x) merepresentasikan router-id dan digunakan untuk peering iBGP di AS200, prefix ini tidak diadvertise ke BGP.
  • Loopback 0 (1.1.1.x) RTR di AS200 harus bisa saling reach supaya peering iBGP dapat dilakukan.
  • Peering eBGP menggunakan ip interface fisik.
  • Loopback 10 (10.10.10.x) merepresentasikan prefix yang nantinya akan diadvertise oleh tiap router ke routing BGP.
  • Sehingga nantinya setiap router di masing-masing AS akan bisa saling reach ke Loopback 10 (prefix-BGP) router yang lainnya.

Topologi di atas akan saya simulasikan dengan router IOU/IOL L3, tentu lab ini sebaiknya kamu ikuti juga, kamu bisa menggunakan EVE-NG, PNETLAB, GNS3  atau apapun yang kamu suka.

Jelas ya?

Mari kita mulai.

Tahapan Konfigurasi Lab Internal External BGP

Agar bisa lebih fokus memahami konsepnya, konfigurasi secara detail tidak saya paparkan disini, kamu bisa mendowloadnya channel telegram ngonfig.net.

Berikut tahapan konfigurasi yang akan kita lakukan:

  1. Initial configuration: konfigurasi hostname, ip point-to-point dsb kemudian memastikan antar peer bisa saling ping point-to-point.
  2. Konfigurasi IGP di domain AS-200, dalam hal ini saya menggunakan routing OSPF process 1 area 0 dan mengadvertise loopback 0 RTR-01, RTR-02 dan RTR-03.
  3. Konfigurasi eBGP antar RTR-AS100 dengan RTR-01 dan eBGP antar RTR-AS300 dengan RTR-03
  4. Terakhir, konfigurasi iBGP di domain AS-200 

Tahapan ke 4 akan kita lakukan dengan beberapa skenario sembari mengulas detailnya, sebagai berikut:

#1. Perbedaan Attribute NEXT_HOP di Internal dan External BGP

Skenario pertama, kita lakukan konfigurasi peering internal BGP di domain AS-200 mengikuti topologi fisiknya, seperti berikut:

perbedaan NEXT_HOP di ibgp dengan ebgp
Gambar 2: Lab Internal External BGP – Skenario 1

Sesuai yang saya jelaskan pada awal tulisan, goal dari lab ini adalah setiap router bisa saling reach prefix BGP dari router yang lain.

Jadi yang perlu kita pastikan adalah prefix sudah bisa reach terlebih dahulu dari hop by hop nya, seperti dari RTR-AS100, sudah bisa direach oleh RTR-01, kemudian oleh RTR-02 dan seterusnya.

Dari point of view RTR-AS100 menuju prefix RTR-02, prefix sudah diterima di table routing BGP dan diinstall di routing table, namun belum reachable. Seperti gambar berikut:

Maka kita perlu cek sebaliknya, yaitu dari point of view RTR-02 menuju ke RTR-AS100, berikut:

Jika kamu perhatikan baik-baik screenshot di atas, maka beberapa informasi yang kita ketahui:

  • Di table bgp RTR-02 (show ip bgp), terdapat prefix 10.10.10.10/32 yang kita ketahui adalah milik RTR-AS100
  • Namun prefix 10.10.10.10/32 tersebut tidak terinstall di routing table
  • Next_hop dari prefix 10.10.10.10/32 adalah 223.255.255.253
  • 223.255.255.253 ini adalah ip point-to-point antara RTR-01 dengan RTR-AS100
  • Sedangkan RTR-02 tidak memiliki informasi mengenai next_hop tersebut

Jelas, kan?

next-hop di ibgp dan ebgp
Gambar 3: RTR-02 tidak memiliki informasi mengenai next_hop prefix 10.10.10.10

Jadi, disini kita pahami bahwa prefix yang ada di table bgp belum tentu terinstall di table routing, salah satu syaratnya adalah router harus memiliki informasi mengenai next_hop dari prefix tersebut.

Sehingga, agar 223.255.255.253 bisa direach oleh RTR-02, ada 2 opsi:

  1. Mengadvertise next_hop tersebut di BGP atau di IGP
  2. Menggunakan next-hop-self di RTR-01 sehingga RTR-02 akan melihat prefix 10.10.10.10/32 via 1.1.1.1 (RTR-01).

Opsi pertama bisa digunakan, namun tidak disarankan karena external BGP adalah antar Autonomous System, ini artinya kita membocorkan traffic diantara 2 autonomous system yang berbeda dan tentunya akan berimpact pada keamanan jaringan.

Jadi kita gunakan opsi ke dua. Setelah menggunakan next-hop-self pada RTR-01, maka semestinya prefix 10.10.10.10/30 sudah reachable. 

Hal yang sama juga kita konfigurasi di RTR-03, sehingga RTR-02 juga dapat reach ke prefix 10.10.10.30 RTR-AS300.

Konsep NEXT_HOP di internal dan external BGP

Tidak seperti IGP (ospf eigrp is-is dll), next_hop yang ada di BGP tidak selalu merupakan ip address si neighbornya, ada beberapa rules atau aturan, sebagai berikut:

Silakan check di lab masing-masing.

Aturan NEXT_HOP #1

Pengirim dan penerima di External BGP, next_hop menggunakan ip address interface si pengirim.

Dalam hal ini: RTR-AS100 menggunakan ip address 223.255.255.253 miliknya sebagai next_hop ketika mengirim prefix ke RTR-01

Aturan NEXT_HOP #2

Pengirim dan penerima di External BGP dan prefix berasal dari iBGP si pengirim, maka next_hop menggunakan ip address interface si pengirim.

Dalam hal ini: RTR-01 menggunakan ip address 223.255.255.254 miliknya sebagi next_hop ketika mengirimkan prefix 10.10.10.2/32 (milik RTR-02) ke RTR-AS100

… atau kita sebut next-hop-self atau next-hop-changed

Aturan NEXT_HOP #3

Pengirim dan penerima di Internal BGP dan prefix berasal dari external BGP si pengirim, maka next_hop nya adalah next_hop asli sebagaimana si pengirim mendapatkan prefix tersebut.

Dalam hal ini: RTR-01 tidak mengubah next_hop 223.255.255.253 dari prefix 10.10.10.30/32 saat mengirimkannya ke RTR-02

… atau kita sebut next-hop-unchanged


Sebenarnya simple, namun seringkali membingungkan memang, maka kita harus benar-benar mengingat dan memahami aturan diatas, caranya dengan sering latihan nge-lab seperti ini.

Btw, lab nya belum selesai.

#2. Konsep Attribute AS_PATH di Internal dan External BGP

Tadi RTR-02 sudah bisa reach ke prefix 10.10.10.10 RTR-AS100 dan 10.10.10.30 RTR-AS300. Tapi goal kita adalah router satu harus bisa reach prefix router yang lain, semuanya.

Sekarang, apakah RTR-01 sudah bisa reach prefix 10.10.10.30 RTR-AS300? atau RTR-03 sudah bisa reach ke prefix 10.10.10.10 RTR-AS100? Mari kita check.

Belum tembus, ya kan? Begitu juga RTR-01 ke prefix 10.10.10.30 pasti sama hasilnya.

Kalau kamu perhatikan, ada perbedaan yang menarik di kasus kali ini. Jika kondisi sebelumnya, RTR-02 sudah menerima prefix di table bgp, namun tidak diinstall di table routing karena next_hop nya unreachable.

Namun kali ini, RTR-03 (juga RTR-01) sama sekali tidak menerima prefix tersebut di table bgp nya, kenapa?

Secara flow topologi, maka RTR-02 lah yang berperan menyampaikan prefix ke RTR-01 dan RTR-03, ya kan?

Mari kita check.

Ternyata, bahkan RTR02 pun tidak mengirimkan prefix 10.10.10.30 ke RTR-01, juga tidak mengirimkan prefix 10.10.10.10 ke RTR-03. Padahal RTR-02 menerima prefix tersebut, namun tidak mengirimkannya.

Dari screenshot jelas terlihat “Not advertised to any peer” alias tidak disebarkan ke peer manapun. Tapi apa penyebabnya? Tidak ada di screenshot.

Maka untuk menjawabnya, kita perlu memahami konsep AS_PATH di BGP.

Penjelasan Konsep AS_PATH di internal dan external BGP

Jawaban dari permasalahan diatas adalah: dikarenakan di iBGP, router tidak akan mengadvertise prefix yang diterima dari peer iBGP satu ke peer iBGP lainnya.

note: penjabaran di bawah ini saling terkait satu dengan yang lain sehingga kamu harus memahami seluruhnya.

Aturan AS_PATH #1

Sebanyak apapun jumlah router dalam sebuah AS, maka prefix yang keluar dari AS tersebut akan dihitung dalam satu PATH tunggal. Perhatikan gambar berikut:

Dari point of view RTR-AS100, prefix 10.10.10.1 dan 10.10.10.2 memiliki AS_PATH yang sama, yaitu tunggal [200], ya kan?

Padahal secara topologi, prefix 10.10.10.2 harusnya lebih panjang, dong. Kan berasal dari RTR-02 (AS200), dikirim ke RTR-01 (AS200), lalu dikirim ke external, kenapa AS_PATH nya tidak menjadi [200, 200].

Seperti ini:

Gambar 4: Prefix yang keluar dari suatu AS terhitung satu AS_PATH, terlepas dari berapa banyak router di AS tersebut

Namun konsepnya tidak demikian.

Aturan AS_PATH #2

 AS_PATH diprint hanya ketika prefix tersebut mencapai AS number yang lain.

Bagi router RTR-02, prefix 10.10.10.1, 2 (miliknya sendiri) dan 3 tidak menyertakan AS_PATH pada informasi table bgp nya.

Berbeda dengan 2 prefix dibawahnya, kita dapat mengetahui 10.10.10.10 berasal dari AS 100, dan 10.10.10.30 dari AS 300.

Aturan AS_PATH #4

Kembali dengan kasus di atas.

Router tidak menerima prefix yang AS number pada AS_PATH nya sama dengan AS number miliknya sendiri. Ini merupakan loop prevention di BGP.

as loop prevention BGP
Gambar 5: Secara default: router tidak menerima prefix yang berasal dari AS nya sendiri

Dalam hal ini: RTR-01 juga tidak akan menerima prefix apapun dari RTR-02 jika prefix tersebut berasal dari RTR-03.

Nah.

Pusing kamu, kan?

Lantas, apa solusi agar prefix 10.10.10.10/32 bisa sampai ke RTR-03, juga agar prefix 10.10.10.30/32 tadi bisa sampai ke RTR-01?

Maka ada aturan AS_PATH nomer sekian

Aturan AS_PATH nomer sekian

Karena router di iBGP tidak akan mengirimkan prefix yang diterima dari peer iBGP satunya ke peer iBGP yang lainnya, maka peering di iBGP harus dilakukan dengan full-mesh.

Hore.

Sehingga topologi kita akan menjadi seperti ini:

ibgp memerlukan peering secara fullmesh
Gambar 6: Peering di Internal BGP harus full-mesh

Jangan lupa untuk menggunakan next-hop-self dari RTR-01 ke RTR-03, dan juga sebaliknya.

Jika tadi saya singgung bahwa RTR-02 lah seharusnya yang mengirimkan prefix 10.10.10.30 ke RTR-01, maka dari penjelasan AS_PATH di atas, pernyataan ini ternyata keliru, ya kan?

RTR-01 akan melihat RTR-03 1.1.1.3 sebagai NEXT_HOP mencapai prefix 10.10.10.30, juga RTR-03 akan melihat RTR-01 1.1.1.1 sebagai NEXT_HOP mencapai prefix 10.10.10.10 RTR-AS100.


Sampai disini, lab kita selesai dan 100 persen reachable, bisa reach prefix satu dengan yang lain.

Silakan, dicoba dengan lab sendiri dan ditanyakan jika ada kendala.

Bonus #1 Study Case BGP Peering

Mirip seperti sebelumnya, dalam AS200, dibangun koneksi fisik (bergaris solid) dan adjacency ospf routing sehingga reachable loopback 0 dan peering iBGP antar RTR-01 dan RTR-02 bisa dilakukan.

ibgp peering study case
Gambar 7: Study Case BGP Peering

Seperti gambar di atas, jelas kita memahami bahwa peering di iBGP harus full mesh, namun topologi kali ini sedikit berbeda, permasalahannya pun berbeda, penyebabnya bukan lagi NEXT_HOP atau AS_PATH seperti yang kita bahas di atas.

Apa kira-kira?

Pertanyaannya sebagai berikut:

  • Saat prefix 10.10.10.30/32 sampai di table bgp RTR-01, siapa yang menjadi next-hop nya?
  • Bagaimana cara RTR-01 menuju next-hop tersebut?
  • Apakah prefix 10.10.10.30/32 terinstall di table routing RTR-01?
  • Apakah RTR-01 bisa ping/reach ke prefix 10.10.10.30/32? Kenapa?

Silakan dianalisa di lab sendiri.

Dalam realitanya, kita sebagai network engineer tidak boleh terpaku pada 1 environment, karena faktanya akan banyak protokol yang bermain, ospf, eigrp, is-is, mpls dan lain-lain.

Sehingga kita harus bisa melihatnya secara out of the box. 

Ahshyiaapp!!!

Study case di atas akan kita bahas dalam artikel berikutnya mengenai MPLS Benefit – BGP Free Core, jika ada kesempatan.

Bonus #2 Soal Latihan

Dah kayak sekolah, yakan?

Soal #1 Siapa NEXT_HOP dari prefix-a dan prefix-x?
Soal #2 Siapa NEXT_HOP dari prefix-prefix mereka?

Sampai ketemu di lain kesempatan.

Jangan lupa subrek channel ngonfig.net di Telegram!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.