BGP Advanced Configuration ~ CATATANKU

Gw lebih suka nyebutnya BGP “Performance Tuning“ sih sebenernya (buat improves convergence time-nya BGP)

Teori dan Config basic uda bisa lah ya…

Ada beberapa yang akan gw bahas:

· BGP Timers (Keepalive and Holdtime)

· Advertisement Interval

· Initial Delay for sending updates

· BGP Scan-Time and NHT

· Fast-External Fallover

· BGP Bidirectional Forwarding Detection (BFD)

· BGP Route Dampening

· Graceful Restart (NSF)

· BGP Reflector and Confederations

· Peer Session/Policy Templates

· Deterministic med (and Always Compare)

===============================

Okeh the first one…BGP Keep Alive and Holdtime

Diatas adalah cara setting bgp timer (timer bgp [waktu keepalive] [waktu hold]), klo kita setting hold time kurang dari 20 detik nanti ada warning…bisa peer flapping

Kita harus pake “clear ip bgp” (ga pake soft) alias hard reset untuk “maksa” timer yang kita setting di-apply langsung (klo pake clear ip bgp * soft ga renegosiasi ulang timer soalnya)

Dan kita bisa liat keepalive packet-nya dengan debug ip bgp keepalive

Yang jadi pertanyaan terakhir adalah…kenapa kita mesti tuning ini timer?!?

Salah satu problem dari BGP apa sih??? Slow convergence kan?!?…IGP protocol udah kita tuning setuning2nya biar fast convergence…BGP tetep ga konek2…lambaaaat banget

Tapi hati2….kecepetan tuning-nya…bisa berabe, IGP belum selesai convergence…masak iya BGP attempt buat convergence, ya ga bisa lah (inget…BGP running on top of another protocol)

Eh…klo salah setting timer gimana??? Ada cara ga untuk prevent-nya? ada

Klo neighbor kita tiba2 jadi “router on-steroid” (wkwkwk…istilah orang2 network untuk router BGP yang ngirim update-nya terus2an dan dalam waktu cepet…”steroid” wkwkw) kita bisa bikin kek gini

Tambahin lagi…contoh: timer bgp 10 30 10, artinya router gw hanya accept holddown timer 10 detik…no less

Klo ada yang ngirim 9 detik kurang gimana??? BGP-nya putus…

===============================

Advertisement Interval

By default, BGP kirim updates ke BGP intra AS (iBGP) tiap 5 detik, klo ke eBGP tiap 30 detik

Kita bisa rubah behavior ini dengan cara:

===============================

Initial Delay for Sending Update

Buat apa sih kita “nge-delay” bgp update? To ensure BGP peer has supplied all the routing information

Jadi BGP protocol ga akan proses best-path selection klo bgp time-out atau bgp prefixes belum didapet semuanya, nah ini kita bisa tuning dengan update-delay

Bayangin klo BGP peer ngirim 10 prefix ke kita, belum abis time-out nya, trus router bgp sebelah uda kirim lagi…trus mau abis lagi time-out nya, dikirim lagi update-an terbaru

Alhasil ga akan di proses2 itu best path selection-nya…

Default bgp update-delay adalah 120s

Untuk nge-force supaya langsung di update?? Clear ip bgp * soft

===============================

BGP Scanner

BGP monitor next-hop dari route2 yang sudah terinstall untuk memverifikasi dan memvalidasi next-hop reachability dan best path, klo mati ya di buang dari routing table

Walaupun IGP uda ngasi tau bahwa ada rute invalid, BGP nge-detect-nya pas lagi scanning, nah default Timer-nya adalah 60s

Btw…untuk VPNv4, timer-nya 15 detik (setting config-nya juga di address family
yaks)

Setting this feature too low (too fast), it will be burden the CPU if many large BGP tables, karena akan perform full table scanning ketika di eksekusi

Setting this too high, yaaa ga akan perform2 scanner, itu next-hop mati apa engga ya cuek aja

Kita juga bisa bikin scan interval ngikutin kecepatan convergence IGP (OSPF, ISIS, dll)

Nah, yang lebih bagus daripada BGP Scanner adalah BGP Next-Hop Tracking (NHT)

Taken from Petr Lapukhov #16379:

“The idea is to make the BGP process register the next-hop values with the RIB “watcher” process and require a “call-back” every time information about the prefix corresponding to the next-hop changes“

Next-hop tracking ini enabled by default (mulai dari IOS 12.4T) dan default tracking-nya 5 detik

Jadi klo next-hop nya mati…ada agen asuransi (wkwkw) dari RIB yang ngasi tau BGP (watcher and callback)

Bahkan klo memang IGP-nya super-fast dalam hal convergence, tracking-nya kita bisa setting jadi 0

===========================================

Fast-External-Fallover

Biasanya klo Ebgp session mati, router akan nyari alternative path secara instant, hal ini karena ada fitur Fast-External Fallover yang di-enabled by default

Yang jadi masalah adalah kalau interfacenya FLAPPING (nyala-mati terus), bikin cpu naek gara2 proses bgp terus

Kita bisa matiin ini command dengan cara no bgp fast-external-fallover biar klo flapping, ga akan dianggep mati session peering-nya (klo mati-nya lama ya tetep di-close juga gara2 hold timer-nya abis)

See…ga langsung mati ebgp session-nya

====================================================

Bidirectional Forwarding Detection

Mirip kek hello packet dari routing2 protocol, Cuma dia di proses bukan di control plane kek routing2 protocol kebanyakan

Dia bisa nge-detect next-hop failure (udp-based routing protocol independent) dan bisa di proses di interface modules

Trus klo ini BFD nge-detect ada fail gimana? Ya dia ngasi tau si routing protocol, terserah protocol-nya, itu link mau di alihkan rute-nya ato diputus (jadi menghemat kinerja routing protocol, ga usa kirim hello packet untuk nge-detect ini link error apa kaga…ada “agen”-nya haha)

Anggep aja ini BFD kek IP SLA versi “generic” nya router

Untuk bisa perform BFD, minimal harus ada peering-nya, alias ga bisa Cuma 1 router aja yang dikonfig, router sebelahnya harus di konfig juga (biar ngerti “Bahasa” BFD)

Well…IOS gw ga support untuk show bfd neighbor, untuk lebih lengkapnya lu bisa ke sini:

http://routerjockey.com/2010/05/24/bidirectional-forwarding-detection/

=====================================================

Route Dampening

Well, ini mirip kek advertisement interval, Cuma ini kek di-“suppressed” (dampening) biar ga di advertise ke internal bgp peer yang lain klo ada route dari external bgp yang suka flapping

Keyword untuk implement route dampening adalah:

· Penalty: incremented numeric value setiap sebuah rute flap (jika sebuah rute flap, maka akan dikasi value, dan akan meningkat terus setiap flap…mirip kek konsepnya HSRP))

· Suppress Limit: limit penalty value, klo sebuah route dengan penalty value yang lebih dari suppress limit value, maka route itu akan di suppress

· Half life time: video game dari valve yang dimasukin ke Cisco *ngaco*, waktu yang diperlukan untuk ngurangin penalty value (biar ga kena suppress limit)

· Max Suppress Time: untuk ensure supaya itu rute ga di “dampen” indefinitely

First, we must activate the dampening mechanism first (klo mau global for all peer)

Klo untuk specific neighbor only, berarti kita harus pake route-map

Ups..ada yang ketinggalan

Diatas adalah default configuration (15 menit untuk half-time, 1000 untuk penalty value, suppress limit-nya pake 2000, maximum limit-nya: 60 menit)

Initial, no dampened path (bisa pake show ip bgp dampened-paths), karena memang ga ada yang flapping

….nyok kita coba rute 2.2.2.2 nya kita matiin trus idupin lagi, cek di R1

Look at dampinfo….flapped 1 times (tes lagi…harusnya 2x)

Noh…2x…klo uda lewat dari suppress-limit (biar yakin…coba itu rute 2.2.2.2 nya di shutdown lagi untuk ke-3x nya)

Di routing table?!?!?

=======================================================

Graceful Restart (NSF)

Well, you can take on this link:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3sg/irg-xe-3sg-book/irg-grace-restart-neighbor.html

intinya adalah router2 yang NSF capable bisa bikin route2 yang didapat jadi “stale” alias di”tahan” dulu…ga dibuang dari routing table klo lagi putus koneksi (ga langsung dibuang)

pas nyambung lagi, tinggal “refresh” alias update aja…

Cuma router2 yang support NSF (non-stop forwarding aja yang bisa, and therefore commandrouter(config-router)#graceful-restart cannot be showed here)

=======================================================

BGP Reflector and Confederation

Both of them useful for getting a BGP mesh capable network without using full-mesh capability

Contoh awal sebuah network

Klo setiap router yang ada “label” BGP-nya mau konek kesemua yang berlabel sama, tanpa cara khusus berarti kita harus membuat semua router2 BGP ini konek satu sama lain, yang artinya FULL MESH

Nah, untuk itulah Confederation dan Reflector berguna…

Untuk BGP Confederation:

Di AS 65000, di”pecah” lagi jadi sub-AS, jadi BGP 2 bisa peering dengan BGP 3 melalui internal BGP, untuk ke BGP 1 dan BGP 4 bisa pake “external” BGP (gw pake tanda kutip, karena memang seakan2 external, padahal bukan…masi 1 AS)

Untuk BGP Route-Reflector:

BGP 4 merefleksikan (kek cermin) rute2 yang di advertise dari BGP 5 ke BGP 6 dan BGP 7, begitu pula sebaliknya

Dalam istilah BGP, router BGP 4 disebut route reclector server, sedangkan BGP 5,6,7 disebut route reflector client

Most of us…yes, most of us, see these two guys competing each other

Padahal ini 2 technology bisa saling komplemen satu sama lain

Kok bisa?!? Gini, klo kita pake sub-AS (confederation), berarti router2 yang berbeda sub-AS akan “act like external peer” ke satu sama lain

Ada kalanya kita pengen route2 yang kita punya tidak di”treat” alias diperlakukan sebagai external ataupun internal, disinilah gunanya route reflector

Bahkan kita bisa bikin kek gini:

WHY NOT BOTH?!?

Untuk konfigurasi…liat disini aja yah wkwkwk

http://belajarcomputernetwork.wordpress.com/2013/06/04/bgp-configuration-part-4/

==========================================

BGP Peer-Policy/Policy Templates

Tau BGP
Peer-Group kan?!?! Itu kan digunain untuk shortening syntax alias menghemat ketikan2 yang berulang

Nah, Peer-Policy dan Policy Templates ini extend the usefulness even further

Contoh:

Take a look, disatu sisi…kita punya 2 peer-group, yang 1 ga pake ebgp-multihop, tapi yang satu pake

Nah, masalahnya…itu timer kan sama tuh ceritanya (itu baru timer yang harus diketik berulang 2x, belum lagi yang lain2)

Nah, kita bisa pake Templates, contohnya:

Nah, All-BGP ini bisa kita “inherit” ke masing2 neighbor peer-group (weeeeew, dah kaya programming aja ada inherit2 segala)

================================

BGP Deterministic Med (and Always-Compare-Med)

Gw Cuma men-translate apa yang ada di cisco.com

Biasanya di deploy di sebuah company yang punya 2 ISP, and those ISP’s are agree on somethin’ (like if you go to X Route…both ISP will influence the company which path is better, of course they will have some parameters agreement to each other ISP)

Contoh, gw punya 3 entry di router gw:

entry1: AS(PATH) 500, med 150, external, rid 172.16.13.1

entry2: AS(PATH) 100, med 200, external, rid 1.1.1.1

entry3: AS(PATH) 500, med 100, internal, rid 172.16.8.4

entry3 dateng paling duluan, trus yang entry2, dan terakhir entry1

Scenario 1: both command disabled

Entry1 dan entry2 akan dikompare (yang entry3 engga…soalnya dapet dari internal BGP),yang dipilih adalah entry2 (Router ID paling kecil)

Scenario 2: bgp always-compare-med enabled

Entry1 dan entry2 dikompare, tapi karena adanya command always-compare-med…dia ga liat Router-ID dulu tetapi liat MED, nah…entry 1 lah yang dipilih (MED value yang lebih kecil dari entry2)

Scenario 3: bgp deterministic-med enabled

BGP akan ngelompokin rute-nya berdasarkan AS-nya, baru di compare, jadi keliatan kek gini

entry1: AS(PATH) 100, med 200, external, rid 1.1.1.1

entry2: AS(PATH) 500, med 100, internal, rid 172.16.8.4

entry3: AS(PATH) 500, med 150, external, rid 172.16.13.1

entry1 adalah yang paling bagus (karena Cuma ini satu2nya rute dari AS 100), entry1 akan dikompare dengan “pemenang” dari group AS 500 (dimana yang menang adalah entry2 karena dia punya lowest MED)

nah, selanjutnya entry1 dan entry2 akan dikompare, karena TIDAK BERASAL DARI AS YANG SAMA, BGP tidak meng-kompare MED, melaikankan akan compare External/Internal,yang menang adalah entry1

Scenario 4: both feature enabled

Sama kek scenario 3, hanya saja…pemenang dari group AS 100 dan pemenang dari group AS 500 tetapkan akan di-kompare MED-nya, yang menang tentu saja entry2 (lowest med)

Contoh konfigurasi: