EIGRP Neighborship – Authentication

topo

Halo, bahas EIGRP Neighborship dari kemaren nggak kelar-kelar…haha… Kalo ini saya coba bahas salah satu faktor penentu EIGRP Neighborship, Authentication. Yup, kalo neighbor authnya kagak match ya kagak bakal konek. Sebelum lanjut materi, ada pertanyaan dulu, Kenapa musti ada Auth? apa gunanya? yang pokok ya buat ngefilter router mana saja yang bakal dijadikan Adjacent Neighbor. Kenapa harus di filter? Lu tau kan kalo EIGRP mainnya pake multicast di 224.0.0.10, nah bayangin kalo ada router x, dia join ke multicastnya EIGRP, join sebagai neighbor si router EIGRP maksudnya, terus dia nyebar routingan yang sesat, misal dia advertise route fake gitu, terus traffic kita belok ke rute fake dia, terus data kita dicuri, terus anu….. nah kacau kan (wkwkwk… hayalan gw doang ini mah :-p ).

Nah jadi kisahnya, dengan Auth ini, router will authenticate every EIGRP Message. To do, so router have to use same PreShared key (PSK) (Key-String), then generating an MD5 digest for each EIGRP Message based on that PreShared key. If router configured for EIGRP Authentication receive an EIGRP Message, and message’s MD5 digest don’t pass the authentication checking based on local key, then router will discard this EIGRP Message. (nah loh, silahkan artikan sendiri. basic concept nih, musti paham dulu…haha).

Sederhananya dengan Auth, router bakal nge-auth setiap EIGRP message. Between routers harus match key index dan key-stringnya. Auth mode yang dipake EIGRP cuma MD5, kalo OSPF kan bisa MD5 bisa cleartext. Nah kalo si router dapet EIGRP message tapi nggak lolos pas dicheck authentikasinya, ya message ini bakal didiscard (diabaikan) oleh si router. Inget nih, konsep dasarnya, nanti bakal kita terapkan untuk topologi diatas.

Kalo konsep konfignya, pertama kita buat key chain, lalu kita buat key didalemnya, nah kita bisa buat banyak key nih karena bisa bikin banyak key index, nah didalem key itu kita specify key-string dan optional sent & recieve valid time kalo perlu, lalu enablekan auth di interface EIGRP. Mengenai aturan pemakaian Keynya seperti ini :

1. Key Chain boleh beda, Key-String dan Key index musti sama. Misal di R1 key-string yang dipake TO-R2 dan di R2 key string yang dipake TO-Planet-Mars pun tak masalah. Tapi Key Index dan Key-String harus match. misal R1 pake key index 2, ya di R2 juga pake key index 2 dan key-stringnya wajib sama.

2. Router bakal pakai key yang valid. Contohnya misal ada 5 Key, ternyata Key 1,2,4 udah nggak valid, jadi yang bakal kepakai ya cuma key 3 dan 5 doang

3. Kapan key menjadi tidak valid? Ketika dia sudah diluar masa operasi (Valid date). kita bisa nentuin kapan key itu valid digunakan, dari detik, menit, jam, tanggal, bulan, tahun kapan sampe kapan. Jadi bisa aja kita buat bulan januari-april 2014 pake key index 1, mei-desember 2014 pake key index 7…dll

Dah gitu doang, gampang kan? 😀

Jadi skenarionya kan di R1, kedua interfacenya di pasang auth semua, yang ke arah R2 pake key chain TO-R2, yang ke R3 pake key chain TO-R3. Di R2 juga kita enablekan Authnya. Nah di R3 yang nanti bakal kita mainkan 😀 Asumsi EIGRP dah configured properly yaa.. Let’s go….

1 key cha R1

Buat key chain di R1. Gampang, tinggal key chain nama-chain; key index-number; key-string your-secret. Sederhananya kayak gitu 🙂

2 R1 int cfg

Apply key chain yang sudah kita buat ke interface EIGRP. Commandnya cuma ip authentication mode eigrp as-number md5; ip authentication mode eigrp as-number key-chain.

Lakukan konfigurasi yang sesuai juga di R2. Tinggal buat key chain, enable Auth di interface EIGRP yang mengarah ke R1. dah gitu doang.

3 R1 debug

Nah hasilnya ketebak dong, R1-R2 bakal adjacent, tapi R1-R3 ndak bakal adjacent. Kenapa begitu? R1-R2 kan sama-sama pake Auth dan kita konfig sesuai, jadi ya Adjacent. Sedangkan R1-R3 nggak adjacent. Kenapa? yaa iya lah, lha wong di interface R1 yang mengarah ke R3 kita enablekan Authnya tapi di interface R3 yang ke arah R1 nggak enable Authnya kok. Ya kayak basic concept diatas, EIGRP Message bakal di discard/ignore. Perhatikan debug diatas, kelihatan kan, Fa0/1 ignored packet from 192.168.88.222. Why? ya karena nggak lolos authentikasi. Sekarang perhatikan bawahnya received packet with MD5 Auth, key id=1. Nah message ini nih yang bakal diproses karena lolos auth.

Sekarang perhatikan gambar dibawah ini. Yang ini adalah debug di R3.

4 R3 debug - missing

Nah kalo di debug R3 kelihatan pesan errornya Authentication off or key-chain missing. Artinya authentikasi ndak enable atau key-chainnya belom ada.

Lalu gimana caranya supaya R1-R3 bisa adjacent? ya sesuain authnya di R3 atau ilangin aja authnya di R1. yaa nggak?? 😀 Nah kita pake skenario kedua, kita sesuaikan authnya di R3. Kalo konfig bener dah pasti berhasil adjacent, tapi coba kita skenario lagi, ehhh…. ternyata key-string yang kita pake salah. Misal seperti gambar dibawah ini. Key-String harusnya S3cr3tR3 tapi di R3 malah K3ySalah. Alhasil ya tetep nggak adjacent, pesan errornya Invalid Authentication.

5 R3 debug - invalid

—————————————————————————-

Oke, Fine yaa, dah ngarti kalo pake single key. Lalu gimana kalo pake banyak key? yaa pake key index, emang kenapa musti pake banyak key? bukannya 1 doang aja dah cukup? Iye betol, 1 key dah cukup, dan walaupun kita punya banyak key ya yang kepake cuma 1 doang, paling-paling 2 yang kepake kalo send key sama accept key yang dipake beda.

Contoh nih di skenario sebelumnya, kita tambahkan key index 2 tapi tetap yang nggak cocok sama yang di R1.

6 R3 add key tetet missmatch

Perhatikan gambar diatas, walaupun kita dah punya 2 key index di R3, tapi yang kepake si R1 pake key index 1, yaa si R3 nanggep authnya juga pake key index 1. Nah sekarang dibawah kita buat key index 1 di R3 menjadi tidak valid dengan merubah validate time.

7 R3 valid key tetep missmatch

Perhatikan di show key chain, key 1 sudah jadi tidak valid untuk dipake auth (accept) maupun mengirim message (send). Maka sekarang yang bakal dipake adalah key 2. Tapi kok di debug paket key index yang dipake tetep 1? ya iya lah, kan itu paket yang ngirim si R1 dan di R1 key yang dipake key 1, makanya tetep R1 -_- . Coba aja kalo debug di R1, nanti kelihatan kalo key index yang dipake R3 adalah key 2.

Nah sampe sini kan sekarang R3 pake key 2, Jadi kalo di R1 kita bikin key 2 yang sesuai sama key 2 di R3 udah bisa adjacent dong? Ummm…. masak? Mari kita coba, tengok gambar dibawah.

8 R1 yeay tapi kok

Sipp… mantab, muncul nih R3 di neighbor EIGRP R1, berarti udah adjacent nih. Yup betul, ehhhh…. tapi bentar deh, tuh kok muncul retry limit exeded terus down, terus adjacent lagi? Oke sebelumnya aku kasih tau retry limit exeded itu penyebabnya karena neighbor EIGRP cuma bisa komunikasi 1 arah alias uniderectional. Disini R1 bisa ngartiin EIGRP message dari R3 (key udah oke), tapi R3 tidak bisa ngartiin EIGRP dari R1. Loh kok gitu?  yaaa kan di R1 key 1 masih valid, ya dia kalo ngirim pakenya key 1 dulu dong yaaa, sedangkan key 1 di R1 dan R3 kan kagak match, ya R3 bakal ngediscard EIGRP message dari R1, makanya kayak gitu. Nggak percaya??? mari kita cek di R3.

9 R3 masih error euy

Show ip eigrp neighbor – Nah loh iya kan masih kosong, R3 ngediscard EIGRP Message dari R1 sih

Debug EIGRP packet – Nah loh iya kan, R1 itu pake key 1, padahal kan di R3 key 1 udah kita bikin nggak valid, selain itu key 1 antara R1 dan R3 juga nggak match -_-

Lalu gimana dong? Yaa kita bikin saja R1 supaya pake key 2, kan key 2 antara R1 dan R3 cucok. kita bikin key 1 di R1 invalid, maka dia bakal pake key 2.

10 R1 yeay aman

Yeay…… berhasil kan, lihat tuh adjacent kan antara R1 dan R3, tidak ada pesan retry exceded lagi. di debug juga nggak ada error, kelihatan juga udah pada pake key 2 untuk R1 dan R3. Bentar bentar, gw belom yakin kalo belom cek R3. Okehhhh….. mari kita cek di R3.

11 R3 yeay aman jugaNah loh di R3, adjacent juga kan, cek di debug juga oke no problem. fine……. selesai dah…

Bentar-bentar, ane ada tantangan satu lagi nih, R1 sama R3, R1 kalo sent pake key 1, tapi kalo receive pake key 2. di R3 kalo send pake key 2, tapi kalo receive pake key 1. Gimana tuh???? yaa tinggal mainin accept sama sendnya aja 😀

Tantangan lagi, gw pengen tiap bulan ganti-ganti key yang dipake, gimana tuh?? yaudah tinggal mainin valid timenya aja kan..haha…

Sipp deh, ini aja tulisan singkat gw (singkat pale lu..wkwk) kali ini, perhatikan manfaat dan penerapan dari Auth ini supaya nggak ngerasa rugi dah baca sepanjang ini…haha…

That’s all… see u in next post about EIGRP Neighborship factor 😀

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