BPG Communities Sebagai Pengganti Prepend

Tulisan ini menyadur dari tulisan Admin dari Cloudflare disini.

Cloudflare adalah penyedia jasa (salah satunya) CDN. Interkoneksi Cloudflare ke banyak provider IP Transit dengan kapasitas ratusan Gbps (Tera bit per second) membuat TE (Traffic Engineering) BGP menjadi tantangan tersendiri.

Menarik dalam artikel tsb, Admin Cloudflare menjelasakan sebuah kesimpulan bahwa TE menggunakan BGP Community jauh lebih efektif daripada Prepend. Kenapa? Akan dijelaskan sebentar lagi.

TE arah outgoing traffic

Asumsikan kita sebagai Admin Cloudflare punya dua provider IP Transit, IPT-A dan IPT-B. Bagaimana cara memindahkan outgoing traffic dari network kita ke IPT-A ke IPT-B?

Rata-rata semua admin BGP sepakat caranya sangat mudah. Yaitu dengan membuat local-preference ke IPT-B lebih besar nilainya.

loc-pref IPT-A 100

loc-pref IPT-B 200

Dengan cara ini maka outgoing traffic akan memilih keluar kearah IPT-B. Outgoing traffic ini bisa dipilih berdasarkan AS Number origin, berdasarkan /24 tertentu dsb.

Intinya TE ke arah outgoing ini, tidak masalah biasanya. Mudah! Dan agak jarang juga di TE di sisi outgoing traffic ini dilakukan. Sebab biasanya traffik outgoing ISP ke arah internet itu kecil. Yang besar adalah jumlah traffic incoming dari Internet ke arah ISP. Ini yang selalu jadi tantangan admin BGP.

Bagaimana caranya memindahkan incoming Traffic terhadap satu prefix /24 masuk nya dari arah IPT tertentu, misalkan IPT-A. Ini kepusingan kebanyakan admin BGP Router.

TE arah incoming traffic

Tantangan terbesar admin BGP adalah TE pada sisi incoming traffic dari arah Internet (bisa disebut juga incoming traffic dari Upstream Provider/IP Transit Provider) ke arah dalam network kita.

Teknik yang umum digunakan untuk TE disisi incoming traffic ini adalah AS Path Prepend.

Kita ikuti flow penjelasan dari artikel yang dibuat Admin BGP CloudFlare ini.

IP Transit Provider Tricky

Di artikel tsb, dijelaskan betapa Perusahaan IP Transit (IPT) selalu ingin memperbesar income (pendapatannya an cuan cuan nya). Dengan cara apa? Dengan cara semua traffic di pompa ke arah link customer yang direct, bukan via network lain. Ini tujuannya agar kapasitas cepat penuh dan customer tsb belanja lagi kapasitas tambahan.

Bagaiman teknik yang dilakukan IPT itu?

Bayangkan Anda sebagai Admin Cloudflare (sisi kanan) lalu Anda berlangganan ke IPT A (Transit A) dan IPT B (Transit B). Di ujung sana ada pelanggan Anda yang ingin kirim streaming video ke Anda (Origin A).

Nah Anda (sebagai Admin BGP Cloudflare) ingin traffic dari Origin A itu datang dari arah Transit A. Kenapa? Karena Transit A menjual layanan IP Transitnya lebih murah ke Anda. Jadi cost perusahaan Anda (Cloudflare) bisa ditekan.

Apa cara yang tersedia? Prepend!

Prefik yang Anda manage 192.0.2.0/24, Anda prepend 2x, kearah provider yang mahal (Transit B). Sedangkan ke Transit A tidak di prepend. Harapannya agar traffic dari Origin A, akan masuk via Transit A (yang lebih murah).

Apakah terjadi? Tidak... 

Kenapa?

Karena Transit B ingin link ke arah Anda cepat penuh. Sehingga Transit B akan men set local preference yang dia terima dari link ke arah Anda cukup tinggi (130).

Sedangkan Transit B ingin agar musuh nya Transit A mati bisnisnya. Sehingga local preference dari Transit A dia bikin rendah (80). [Ingat: Local Preference yang lebih tinggi lebih dipilih oleh Router BGP]

Nah, sebagai admin Anda heran. Kok tetap saja traffic dari Origin A itu masuknya dari arah link Transit B (yang mahal)?

Oh iya, perlu di ingat kembali cara BGP Router ambil best route sbb:

Terlihat bahwa yang pertama dilihat router BGP itu adalah local preference nya. Jika local preference sama maka akan dilihat BGP Path length nya. Artinya walau Anda prepend banyak (agar Path length panjang), jika local prerefence oleh Admin IP Transit anda di modifikasi, ya kemungkinan upaya Anda dengan memainkan Prepend itu akan tidak efektif (walaupun di kebanyakan situasi terkadang bisa berdampak juga).

Lalu Anda sebagai Admin BGP Router Cloudflare, telepon pelanggan Anda yang punya server Origin A.

"Mas untuk bisa lebih handal coba dong, Anda juga langganan IP Transit ke Provider Transit A"

Asumsikan si Mas nya setuju, sehingga Origin A sekarang punya 2 upstream, spt gambar berikut:

Setelah Origin A langganan ke Transit A, nah sekarang Prepend yang Anda terapkan bekerja!

Yessss..... Anda happy..

Sebab biaya yang perusahaan Anda (Cloudflare) keluarkan bisa berkurang karena traffic Origin A sekarang sudah lewat Transit A yang biayanya ditagihkan ke Anda lebih murah.

Bagaimana jika Admin Origin A tidak setuju?

Sewaktu Anda telepon Admin Origin A:

Anda: "Mas untuk bisa lebih handal coba dong, Anda langganan juga IP Transit ke Provider Transit A (Telia)"

Admin Origin A: "Waduh mas sorry banget nih, belum bisa.. boss belum approved nambah kaki baru upstream... Saat ini boss maunya satu kaki aja ke Cogent "

Anda: "yaahhhh... " 

Anda awalnya kecewa.

Anda putar otak lagi. Anda lihat-lihat lagi diagramnya...

Anda perhatikan lagi gambar diatas.. Prepend sudah, tapi gak ngefek... duh!

Lalu Anda ingat, Transit B itu kan nama perusahaanya Cogent. Dan Anda cari2 info apakah Cogent menerapkan BGP Community? Anda tanya kiri kanan. Anda check di website tech support Cogent. 

Jeng jeng..

Anda menemukan bahwa Cogent menerapkan Community Policy yang dia publish sbb:

Community	Local preference
174:10	10
174:70	70
174:120	120
174:125	125
174:135	135
174:140	140

Nah, Anda lihat tabel diatas ternyata local preference yang di set oleh Router Cogent itu ada beberapa:

10, 70, 120, sd 140

Tapi wait.. default Loc Pref itu kan 100, di tabel tidak ada 100. Anda tanya kiri kanan, Anda dapatkan informasi berikut:

When you know that Cogent uses the following default local preferences in their network:

Peers → Local preference 100
Customers → Local preference 130

Nah disini Anda tahu bahwa link dari Cogent ke arah network Anda diset oleh Cogent Loc-Pref 130. Sedangkan Cogent ke Peers lain menerapkan Loc-Pref 100.

Inilah penyebab kenapa Anda sudah capek2 Prepend, tapi tidak berpengaruh. Sebab Router BGP pertama2 lihat Loc-Pref ini dulu.

Setelah Anda tahu bahwa Loc-Pref ke arah Anda oleh Cogent di set 130, maka sekarang - disini inti sari tekniknya... Anda advertise ke Cogent prefix yang Anda manage 192.0.20.0/24 dengan tambahan community 70.

Community 70 artinya seolah2 Anda bilang: "Hai Router Cogent, ini ane advertise ke ente 192.0.20.0/24 tapi tolong set Loc Pref di ente 70 yah (jangan kayak yang standar 130)".

Jadi sekarang Anda Advertised ke Cogent tidak hanya prefix /24 standar, tapi juga anda set community nya, spt gambar berikut.

Sebagaimana yang Anda kemudian tulis di blog Anda: jika prepend 2, 3, 4x tidak mempan, maka menggunakan Community tag akan mempan.

At that point, an engineer could add another prepend, but for a well-connected network as Cloudflare, if two prepends didn’t do much, or three, then four or five isn’t going to do much either. Instead, we can leverage the Cogent communities documented above to change the routing within Cogent:

term ADV-SITELOCAL {
    from {
        prefix-list SITE-LOCAL;
        route-type internal;
    }
    then {
        community add COGENT_LPREF70;
        accept;
    }
}

Dengan cara diatas maka perhatikan traffic ke arah Anda sekarang akan lewat Telia, sebagaimana yang Anda harapkan. Yess.....

Kesimpulan

Dibanyak case, kita bisa menggunakan Community tag, sewaktu advertise ke Upstream Provider kita. Dan ini dijamin lebih mangkus daripada prepend. Dengan syarat kita tahu community tag nya nomer berapa saja yang diterapkan oleh provider upstream kita (spt Tabel 1, diatas Commuity tag yang digunakan Cogent).