OSPF, EIGRP, BGP Route Filtering Using Redistribute List

concept

How to controling routing table entries? yup, dengan mengontrol dari mana saja route itu berasal, entah dari static route, ataupun dinamik route. Of course di static route kita bisa full control terhadap route yang akan kita tambah/kurangi di entri routing table. But how if routes came from dynamic routing?? so we also can filter received/sent routes in dynamic routing configuration. There are many ‘jutsu’ to filter routes in dynamic routing, we can use redistribute list based on access list, prefix list, manipulating Metric or administrative distance. In this post i will explain about how to filter routes with Distribute-List in dynamic route. This is a ‘general basic jutsu’, so it can implemented on BGP, OSPF, EIGRP, RIP but i don’t know in ISIS, haven’t try ISIS yet 🙂

Konsepnya sederhana, mirip traffic filtering menggunakan ACL. Kita define ASC, permit mana, deny mana, di konfig routing protocol tinggal apply ACL tadi di distribute-list, directionnya apa, inbound apa outboud, udah deh jadi. Sederhananya, gitu doang, gampang kan??…haha….

Skenarionya kali ini sederhana, 2 router seperti topologi dibawah, aku pake BGP, kita main di IDN-R2, IDN-R2 bakal ngeadvertise IP loopbacknya, lalu kita filter outbound supaya ip 22.22.22.11-15 tidak keadvertise keluar, lalu di IDN-R1 juga bakal difilter inboundnya supaya hanya menerima ip 22.22.22.8-10, selain itu ditolak.

Contoh kasusnya semisal pada skenario ini IDN-R1 adalah sisi provider dan IDN-R2 adalah sisi client, maka dengan menerapkan filtering, sisi provider akan mencegah masuknya route yang tidak diinginkan, jadi hanya route yang benar-benar perlu aja yang bakal dipake oleh provider. Setidaknya hal ini mencegak kemungkinan kalau di klien ternyata miss-config lalu malah mengadvertise route sembarangan, bisa saja jaringan jadi kacau gara-gara route yang sembarangan tadi. Contoh kasus realnya kayak kasus kebocoran route salah satu ISP xxx yang mengakibatkan google tidak bisa diakses di sekitar Indonesia, yaitu karena miss config, rute yang nggak bener ‘bocor’ (kesebar) ke internet.

topo

Poin penting yang perlu diperhatikan disini adalah ACL, sama Directionnya. Jangan sampe kaco buat ACLnya, lalu directionnya perlu diperhatikan jangan kebalik, out sama in doang mah kalo sampe kebalik konyol juga..haha.. in berarti dia memfilter routes yang dia dapet, sedangkan out dia memfilter routes yang akan dia advertise.

Berikut konfig di IDN-R2

1 r2 cfgBuat access list buat filter route mana saja yang “boleh” dilewatkan, route mana yang “deny”.

Hasilnya di IDN-R1 akan seperti ini nih :

2 r1 ip rouTerlihat ip 22.22.22.11-15 tidak sampe di IDN-R1 walaupun sudah di advertise di IDN-R2 lewat redistribite connected. Next skenario, kita permit only ip 22.22.22.8-10 di inbound IDN-R1

3 r1 cfgMirip dengan rule yang di IDN-R2, cuma disini rule kita pake di direction-in, jadi route in (yang diterima) BGP bakal kena rule ini. Hasilnya hanya ip 22.22.22.8-10 doang yang bakal diterima oleh IDN-R1 walaupun tadi ip 22.22.22.5-6 sudah lolos di IDN-R2 dan  diadvertise ke IDN-R1.

4 r1 verifyYup, routes yang masuk ke IDN-R1 hanya routes yang di permit oleh access list yang dipasang di direction in tadi. 🙂

 

Komen dimari gann....

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s