17 Again

July 4, 2009

Di tengah-tengah kesibukan gue menghadapi tekanan project di Saudi, persiapan ujian CCDE yg sulit dilakukan dan sudah mepet, dan berbagai tantangan kehidupan pribadi yg harus gue hadapi, sore ini gue mengambil keputusan untuk membeli drum elekronik Yamaha DTXplorer series.

Dulu gue memang sering latihan main drum tiap hari pas SMA dan sempet beberapa kali manggung di acara sekolahan. Membeli drum baru ini bukan usaha untuk kembali ke usia 17 lagi. Walaupun harus gue akui masa-masa SMA itu mungkin merupakan masa yg terindah. Karena gue tidak terlalu banyak berpikir :) Tidak ada yg namanya CCIE, network, NGN bahkan Internet. Yg ada hanya mencoba bermain musik. Dan jual pesona ke gadis-gadis di sekolah. Dan mencoba menyetir mobil orang tua tanpa bilang-bilang untuk jalan-jalan sore. Ah, masa-masa tidak berpikir.

Walaupun demikian indah, tapi gue tidak hidup di masa lalu. Gue adalah gue yg sekarang karena semua keputusan yg gue ambil di masa lalu. Dan salah satu target baru gue dalam hidup memang untuk kembali bermain drum. Bahkan berencana untuk membentuk rock band, dan bermain di event International seperti Networkers! Kalo gue tidak bisa tampil sbg pembicara teknis di sana paling tidak gue bisa berpartisipasi dgn membuat keributan. Rock your world, I will.

Jadi sekarang gue sedang mencoba merekrut member buat band. Kalo ada yang bisa main gitar listrik atau bass, atau bisa nyanyi, dan tidak keberatan buat maenin Matchbox 20, Goo Goo Dolls, The Killers, U2 dan kadang-kadang Metallica, silahkan kirim resume ke gue.

Oh ya, hampir lupa. CCIE itu penting tapi tidak menjadi keharusan buat melamar :) Paling tidak mengerti format paket protokol BGP, atau IPv6 addressing, atau memahami RFC 2547 gue pikir sudah cukup lah.

Cisco Certified Architect

June 29, 2009

Cisco hari ini mengumumkan program sertifikasi baru yg merupakan level tertinggi yg pernah ada: Cisco Certified Architect. Di klaim sbg sertifikasi yg lebih susah dari CCIE, format ujian yg digunakan juga unik karena berupa board exam di mana kita harus mempresentasikan solusi kompleks infrastruktur di depan beberapa engineers.

Dari informasi awal ttg sertifikasi ini, syarat seseorang utk bisa ikut ujian adalah memiliki pengalaman paling tidak 10 tahun, dan harus mengajukan aplikasi yg harus disetujui. Selain harus bisa mempresentasikan proposal solusi infrastruktur dari customer requirement yg diberikan, kandidat juga harus mampu melakukan perubahan solusi secara langsung ketika diberikan penambahan requirement pada saat presentasi. Ditambah lagi adanya isu yg beredar bahwa engineer-engineer yg akan menguji kita adalah Cisco Distinguished Engineer :)

Gue dulu ketika mengambil ujian CCIE yg pertama masih berupa format ujian yg dua hari. Jadi masih ada sesi troubleshooting di 2.5 jam terakhir. Dan setiap habis satu sesi gue harus memberi penjelasan ke proctor mengapa konfigurasi gue lakukan seperti ini atau itu. Kadang gue harus menggambar di papan tulis buat menjelaskan. Ujian CCIE yg sekarang, gue rasa kekurangan dua hal tsb: troubleshooting secara mendalam, dan kemampuan menjelaskan alasan mengapa network di konfigur sedemikian rupa. Dan CCIE tentunya bukan ujian design, dan tidak ada aspek design yg diuji di situ. Oleh karena itu Cisco membuat program sertifikasi CCDE. Tapi walaupun dgn ujian design ini gue masih tetep merasa ada skill designer yg tidak diuji. Misalnya, kemampuan utk meng-capture customer requirement pada saat meeting awal dgn customer tidak bisa di test di ujian. Atau kemampuan utk memimpin workshop design. CCDE juga tidak menguji kemampuan seorang designer utk mengakomodasi perubahan yg dilakukan customer, atau adanya penambahan requirement di tengah-tengah proses design. Hal-hal seperti ini yg dicakup oleh Cisco Certified Architect.

Kalau di lihat-lihat, program sertifikasi Architect ini cakupannya mirip dgn level Architect yg gue bikin di Transformasi Skill Seorang Network Engineer. Orang bisa disebut Architect jika sudah mampu membangun suatu solusi infrastruktur yg komplit, juga mengerti hal yg detil di solusi tsb seperti misalnya arsitektur hardware dan cara kerja detil suatu protokol untuk mengetahui keterbatasan dari implementasi protokol atau fitur network yg akan mempengaruhi solusi infrastuktur itu juga. Architect juga mengerti korelasi antara bisnis dari customer dgn solusi infrastruktur sehingga solusi yg dibangun berdasarkan kebutuhan untuk membantu model bisnis customer. Paling tidak sekarang sertifikasi baru Cisco ini bisa menstandarisasi pengetahuan dan kemampuan minimum seorang Network Architect.

Tentu saja, walau sudah berhasil lulus ujian ini, atau sudah mendapat titel “Architect” di kerjaan, masih ada satu level lagi yg harus dicapai. Level expert. Ini adalah level yg harus menjadi target setiap orang yg bekerja di bidang ini. Kita harus berusaha menjadi expert, ikut serta mengembangkan teknologi dan bisa membagi pengetahuan dan pengalaman ke orang lain.

The expert level is something that must be earned.

So You Think My Life is Perfect?

June 27, 2009

Note: for those who are unable to read between the lines, please put your focus on the last two points
Catatan: buat yg tidak mengerti mengapa gue menulis ini, silahkan baca dan fokus ke dua poin terakhir

#curhat start, in summary mode

- Kemaren pagi resmi diumumkan kalo gue dapet assignment mendadak buat memimpin team dari Cisco AS buat meng-handle case besar di salah satu customer kunci di Arab Saudi

- Di Cisco ada Technical Assistance Center (TAC), kalo customer ada isu dgn produk atau solusi pada saat deployment bisa buka TAC case dgn prioritas P4 yg terendah dan P1 yg berarti “network meltdown” atau completely down

- Yg akan gue handle, levelnya lebih tinggi lagi dari P1, dan assignment spt ini biasanya gue berminggu-minggu di customer gak pulang-pulang (termasuk weekend)

- Kenapa gue yg berangkat? Kata mereka karena butuhnya seseorang yg punya profile spt gue, yg ‘can do the job whatever it takes’, berani mengambil keputusan on the spot under the pressure, sometime dare to break the rules, dan tidak pernah kerja ‘by the book’

- Dari dulu gue kerja di industri computer networking memang tidak pernah kerja sesuai prosedur, gue lebih sering ngerjain hal-hal yg belum pernah dikerjain sebelumnya oleh orang lain, making my own and the new procedure

- Project gue dulu di Vietnam yg melakukan migrasi core network ISP di tiga kota dgn routing policy yg sangat kompleks dalam kurun waktu 1 jam per lokasi adalah salah satu contoh, pada saat team lain dari Cisco Australia sudah angkat tangan

- Atau ketika gue melakukan migrasi dari produk non-Cisco ke Cisco utk perusahan minyak milik pemerintah Malaysia. Waktu itu sebenernya customer hanya ingin upgrade ke produk baru dari vendor yg sama, tapi ternyata vendor itu saja bilang proses upgrade tidak bisa dilakukan dgn limit maintenance window yg diberikan. Team yg gue pimpin mampu utk melakukan migrasi komplit ke produk Cisco sesuai target, dgn banyak melakukan improvisasi di lapangan

- Atau yg terakhir yg minggu lalu baru selesai dikerjakan, gue bikin arsitektur blueprint utk menjelaskan prosedur utk melakukan migrasi network buat customer di 28 negara eropa dgn jumlah 2200 total sites, ini juga belum pernah dilakukan orang lain di Cisco sebelumnya

- Di satu sisi gue seneng karena ini pengakuan akan skill dan expertise gue, apalagi gue juga suka bgt ama profile nya Jason Bourne: highly skilled (I wish), terbang kesana-kesini utk mengerjakan assignment, never ask questions

- Tapi di sisi lain gue juga bingung karena semenjak pindah ke Dubai memang gue banyak masalah pribadi, seperti kehamilan istri yg tidak direncanakan dan sempat bermasalah di trimester pertama, dan masalah-masalah yg berkaitan dgn kepindahan kita spt sekolah anak, tempat tinggal dan lain-lain

- Pergi meninggalkan keluarga di negara antah berantah selama berminggu-minggu akan merupakan pengalaman painful baru buat gue, apalagi anak gue yg pertama baru 10 tahun dan yg kedua masih 1.5 tahun, baru bisa jalan, dan gue tidak punya pembantu di rumah

- Gue dulu sering traveling meninggalkan anak istri, sampai 2 bulan, bahkan pernah 6 bulan tidak ketemu, tapi dgn catatan mereka selalu gue tinggalkan di rumah sendiri di Bandung. Dubai adalah tempat dimana semuanya belum stabil (bukan berarti Indonesia sudah stabil, tapi minimal di Indo kita dari kecil di sana dan sudah tau persis bagaimana cara mengatasi berbagai situasi)

- Yap, gue tahu kalo Dia yg di atas tidak akan menguji lebih dari kemampuan gue. Kata Harvey Dent di Batman juga: The night is darkest just before the dawn. What doesn’t kill you makes you stronger (stranger kalo kata The Joker). Jadi gue udah tahu kalo ini semua adalah pilihan, di semua hal pasti ada hikmahnya dan kata-kata mutiara lainnya. Tapi tetep pas ngejalanin pasti ada rasa kuatir, was-was, dan sebagainya

- Yang bisa gua lakukan sekarang adalah Tawakal, yg berarti gue percaya sepenuhnya bahwa yg di atas akan membantu gue, dan juga berusaha utk mempersiapkan kebutuhan keluarga selama gue pergi, spt menumpuk bahan makanan supaya keluarga tidak perlu keluar rumah jika tidak perlu, membereskan hal-hal yg berkaitan dgn sekolah anak (kebetulan anak gue pindah sekolah ke tempat baru), bayar-bayar fasilitas penunjang dan lain-lain

- Istri gue yg sedang menginjak masa kehamilan 6 bulan gue minta utk belajar nyetir dari minggu lalu. Dapet SIM di Dubai itu susahnya minta ampun, tapi kita tetep berusaha supaya sebelum gue pergi dia udah lulus ujian. Minimal kalo ada keperluan yg sangat penting dia bisa nyetir sendiri

- Gue masih ada waktu karena proses utk mendapatkan visa ke Saudi itu bisa makan waktu 1-2 minggu. Kalo biasanya gue pakai waktu sebelum ke customer utk mempelajari situasi di sana, kali ini semua waktu yg tersisa gue coba manfaatkan sebaik-baiknya utk mempersiapkan kepentingan keluarga. Kalo masalah kerjaan gue pikir ntar juga pasti bisa dikerjain: it’s already in my blood.
I’m a survivor anyway

- In this part of the world, dengan banyaknya tantangan dan sedikit sekali orang yg bisa dimintai tolong, gue pikir yg terbaik itu memang Tawakal. Berdoa dan percaya sepenuhnya akan pertolongan-Nya, dan juga berusaha untuk melakukan hal terbaik yg bisa dilakukan utk mempersiapkan segala sesuatu. Merencanakan terlalu detil juga tidak perlu, bikin persiapan sebaik mungkin dan dijalani saja

- Ini gue masukkan ke dalam blog, dgn topik “So You Think My Life is Perfect?” karena sampai hari ini gue masih sering mendapat email dari orang-orang yg minta petunjuk untuk bisa menjadi spt gue. Gue ingin mereka lihat bahwa hidup seseorang itu tidak ada yg sempurna dan jangan melihat hanya dari satu sisi saja

- Gue merasa tidak ada yg salah dgn mencari inspirasi dari orang lain. Tapi kesan yg lebih sering gue dapet itu orang-orang ingin spt gue (kerja di luar negri, bisa kesana-kesini dan sebagainya) tanpa mau mengerti bahwa di belakang itu ada harga yg harus dibayar. Yg suka bertanya ke gue itu lebih sering melihat ketika CCIE itu sudah kerja di tempat yg menurut mereka enak, tanpa mau melihat apa yg sudah dikerjakan utk mencapai ke sana

#end of curhat

Transformasi Skill Seorang Network Engineer

June 12, 2009

Gue lagi iseng nulis sambil nunggu Jum’atan. Walaupun sudah sering ditulis di blog masih banyak orang yg suka mengirim email ke gue untuk menanyakan bagaimana cara untuk memulai karir di networking, clueless ttg proses karir di networking spt apa, dan sebagainya. Di bawah ini gue tuliskan proses transformasi skill seorang network engineer, yg tentunya versi gue :) berdasarkan apa yg gue amati dan lakukan sendiri. Kalo mau dijadikan bahan perdebatan, silahkan. Cuma kalo boleh saran sih, daripada berdebat, mendingan lakukan saja garis karir spt yg mau dilakukan, dan suatu hari nanti bisa menulis versi masing-masing dari hal seperti ini.

Dan gue hubungkan dgn program sertifikasi dari Cisco hanya untuk memberi gambaran kesetaraan antara skill dgn sertifikasi.

Transformasi Skill Seorang Network Engineer

Level I Configurator
Semua orang mulai dari sini. Sebutan lain adalah Conf T engineer, karena di level ini engineer baru bisa melakukan konfigurasi router tanpa mengerti terlalu dalam konsep di belakangnya. Di level ini juga sebenernya ada 2 golongan: golongan pertama yg ingin melakukan konfigurasi router tapi gak ngerti harus ngapain dan paling sering ngirim pertanyaan satu kalimat ke milis “bagaimana sih caranya mengkonfigurasi MPLS?”. Golongan kedua adalah mereka yg ketika ingin mengkonfigurasi paling tidak mencoba mencari di website dan Internet terlebih dahulu command-command spt apa yg harus dimasukkan.

Kalo mau dibandingkan dgn program sertifikasi Cisco, mungkin golongan kedua di level ini setara dgn CCNA

Level II Troubleshooter
Ini level yg lebih maju karena selain tahu dimana mencari informasi tentang bagaimana cara mengkonfigurasi router/network device, mereka juga tahu konsep dan cara kerja dari produk atau sistem tsb. Karena sebelum bisa menyelesaikan masalah di suatu sistem, kita harus tahu dulu bagaimana sistem itu bekerja di saat normal, dan melakukan langkah-langkah troubleshooting secara sistematis. Bagaimana dgn mereka yg kalo troubleshoot selalu tembak langsung “pasti masalah network”, “harus restart dulu”, “pasti gara2 produk vendor ini” tanpa investigasi dulu? Gue gak mengkategorikan mereka di level ini, mungkin masih berada di level sebelumnya atau malahan termasuk golongan pertama di level I.

Kalo dibandingkan dgn program sertifikasi Cisco, mungkin level ini setara dgn CCNP dan sertifikasi yg setara

Level III Specialist
Sampai di level ini, si network engineer mulai merasakan ketertarikan pada satu bidang saja dari scope network engineering. Jadi kalo untuk level I dan II mungkin berangkatnya dari hal yg umum seperti Routing dan Switching, di level ini sudah ada perasaan untuk mendalami satu bidang misal security, voice, wireless dan sebagainya. Ini bukan level specialist murni karena biasanya dikerjaan sehari-hari tetap harus melakukan routing/switching sbg dasar tapi kemudian sudah fokus dan mampu mengerjakan teknologi lain yg lebih spesifik.

Kalo disetarakan dgn sertifikasi Cisco, ini mungkin CCIE. Engineer yg mengejar CCIE di track Routing & Switching pun bisa dikategorikan di sini, karena toh mereka fokus untuk mendalami scope di track tersebut.

Level IV Designer
Anehnya, dari level specialist untuk naik ke level berikutnya si network engineer harus belajar hal yg general lagi. Istilah yg umum adalah Sistem Integrator, dimana dibutuhkan kemampuan untuk menggabungkan beberapa produk dari teknologi bahkan vendor yg berbeda. Ketika sudah mencapai level ini, cap yg diberikan adalah Network Designer, karena sekarang sudah mampu untuk membangun satu solusi infrastruktur dari routing switching, security, voice, wireless dan sebagainya, sampai ke hal-hal yg berada di luar domain network spt Operating System, Database, physical Data Center dan lain-lain. Jadi ketika sudah mencapai level specialis spt CCIE, kemudian malahan belajar hal yg umum agar bisa membangun suatu solusi infrastruktur yg komplit.

Sertifikasinya sudah tidak ada lagi, tapi mungkin ini bisa disetarakan dgn CCIE yg sudah mempunyai pengalaman.

Level V Architect
Architect merupakan level Sistem Integrator II karena mempunyai kemampuan untuk membangun solusi komplit, juga mengerti hal yg detil di solusi tsb seperti misalnya arsitektur hardware dan detail cara kerja suatu protokol. Ini penting untuk mengetahui keterbatasan dari implementasi protokol atau fitur network yg akan mempengaruhi solusi infrastuktur itu juga. Architect juga mengetahui standar dari suatu protocol dan memahami implementasinya yg berbeda-beda di tiap vendor produk network, sehingga menguasai konstep interoperability antara produk-produk dan vendor yg berbeda. Ditambah lagi, architect mengerti korelasi antara bisnis dari customer dgn solusi infrastruktur sehingga solusi yg dibangun berdasarkan kebutuhan untuk membantu model bisnis customer.

Mungkin ini seperti CCIE yg sudah sering membaca standard dari suatu protokol dan juga arsitektur hardware, dan berpengalaman dgn project multi aspek baik dari sisi teknis maupun dari sisi non teknis.

Level VI Expert
Sesudah berada di level Architect, membangun solusi infrastruktur komplit yg bisa melibatkan multi-vendor, juga mengerti model bisnis yg dijalankan sehingga solusi yg dibangun bisa membantu customer, maka si engineer akan melakukan transformasi di level tertinggi dgn menjadi spesialis lagi. Spesialis dalam artian dgn beragam skill dan pengalaman yg sudah dimiliki, expert akan berfokus pada satu atau beberapa teknologi saja, untuk berkontribusi dalam mengembangkan teknologi tersebut. Para expert berkomunikasi satu sama lain untuk mengembangkan standard di bidang networking, menterjemahkan konsep suatu teknologi ke bahasa yg mudah dimengerti oleh banyak orang, dan membagikan informasi tersebut ke orang lain.

Memiliki berbagai sertifikasi sudah tidak relevan lagi. Yang paling penting adalah pengalaman ektensif dalam melakukan semua hal-hal seperti yg sudah disebutkan di atas, ditambah fokus ke satu atau beberapa scope teknologi secara mendalam, ikut terlibat dalam mengembangkan teknologi tsb dan membagikan informasi yg dimiliki ke orang banyak.

The expert level is something that must be earned.

Take Control Our TV

June 4, 2009

Ketika Cisco Systems membuat router yg kemudian menjadi produk router komersial pertama di dunia, tujuan utamanya adalah mengkoneksikan network dgn media fisik dan protocol yg berbeda. Saat itu tidak ada niatan untuk membedakan produk router utk berbagai segment yg berbeda, misal untuk Service Provider atau Enterprise. Hasilnya adalah produk-produk router tanpa ada pemisahan yg jelas di spesifikasi teknis untuk segment pasar yg berbeda. Semuanya menjalankan legacy IOS yg sama dan setiap router bisa menjalankan semua fitur walaupun tidak diperlukan.

Untungnya Cisco menyadari bahwa tidak ada satu produk untuk menjadi solusi dari semua kebutuhan. Sebuah project rahasia mulai dijalankan di akhir tahun 90-an untuk membuat next generation router dgn arsitektur hardware baru dan juga operating system yg baru. Ketika Cisco CRS-1 diluncurkan bulan Mei 2004 jelas terlihat bahwa produk ini adalah jawaban dari kebutuhan para Service Providers untuk core router yg handal, memiliki performance tinggi dan skalabilitas. Dan produk yg baru saja merayakan 5 tahun peluncuran bulan lalu itu terus berhasil mengalahkan ekspektasi dan sudah digunakan di lebih dari 300 service providers di dunia.

Setelah berhasil membuat suatu produk seperti ini, apa langkah selanjutnya? Tentunya berusaha membuat produk lain dgn cara menggunakan teknologi yg sudah berhasil dikembangkan. Arsitektur hardware dan IOS XR yg sudah terbukti kembali digunakan di produk baru Cisco ASR9000 router. Gue pribadi sangat bersemangat dgn produk ini karena tidak saja Cisco berhasil meluncurkannya di tengah krisis ekonomi global (ada beberapa produk lain yg sudah dibangun selama bertahun-tahun tapi harus dibatalkan karena krisis, dan mungkin kita harus menunggu kondisi ekonomi untuk membaik sebelum bisa melihat inovasi-inovasi baru lagi) dan juga ASR9000 menggunakan arsitektur hardware yg mirip dgn CRS-1 yg sudah terbukti di banyak production network.

Cukup sudah ngomongin sejarah, saatnya untuk membahas poin utama di tulisan gue ini.

Seperti kita tahu kebutuhan akan IP Video services menjadi faktor utama untuk mengembangkan banyak teknologi. Kita hidup di jaman High Definition di mana kualitas gambar DVD pun sudah tidak cukup. Dan kita mau video tsb bisa dikirim ke TV kita di rumah melalui network. Dulu kita sudah cukup puas dgn YouTube tapi sekarang kita ingin lebih. Kita mau kualitas yg lebih tinggi. Kita mau agar bisa menonton film secara utuh. Kita ingin punya kontrol kapan dan di mana kita mau menonton film. Video harus selalu tersedia kapan saja dan di mana saja selama kita masih terkoneksi dgn network.

Ini berarti kita memerlukan network dgn performance tinggi untuk bisa mengirim video. Kita harus memastikan paket-paket digital dari video bisa di switch secepat mungkin oleh network. Kita butuh storage yg semakin besar buat menyimpan video. Dan jangan lupa paket video ini harus berkompetisi dgn paket jenis lain di network. Ini berarti fitur Quality of Services harus bisa digunakan untuk untuk berbagai tipe paket dan menjamin service ini.

The Buggles pernah bilang Video Killed the Radio Star. Tapi saat ini video juga membunuh bandwidth, membuat infrastruktur network dan router-router bekerja di performance maksimum, dan memenuhi penyimpanan di storage kita dgn cepat. Dan Cisco adalah pemimpin industri di service ini dgn memiliki semua produk yg diperlukan untuk memberi end-to-end video service.

Ketika vendor-vendor lain sibuk mengkampanyekan bagaimana mereka bisa dengan cepat membawa fitur-fitur yg bekerja secara independen ke market, Cisco sudah melakukan hal yg jauh lebih maju. Tidak saja Cisco bisa menyediakan semua produk yg diperlukan untuk membangun solusi yg komplit, tapi juga mereka menunjukkan bagaimana solusi ini bisa dibangun berikut dgn hasil test yg dilakukan oleh third-party testing vendor.

Light Reading dan EANTC kemaren mengeluarkan laporan tentang bagaimana mereka menguji Cisco’s IP Video Service Delivery network. Test nya meliputi: the high availability with sub-second failover time for all network services, in-line video quality monitoring, massive scalability of IP video services and storage area network solutions and virtualization. Produk yg digunakan di dalam solusi adalah Cisco CRS-1, ARS9000, Cisco 7600-S dan Nexus.

Hasilnya adalah sebagai berikut:

- 8,188 multicast groups were replicated across 240 egress ports in a point of presence (PoP), showing that Cisco could serve 1.96 million IP video subscribers in a single metro PoP
- Accurate in-line video monitoring was demonstrated for video distribution and contribution over IP
- Sub-50 millisecond failover and recovery times were shown for video distribution and secondary distribution networks using, for the first time in a public test of Cisco equipment, point-to-multipoint RSVP-TE
- No video quality degradation in the face of realistic packet loss in the network
- Excellent quality of service (QoS) enforcement in Cisco’s new ASR 9010 router for both fabric oversubscription and head-of-line blocking
- Hitless control plane failover for converged network

Seperti gue pernah bilang, TV is evil. Tapi on-demand TV bukan. Karena sekarang kita yg pegang kontrol TV kita sepenuhnya.

Silahkan membaca hasil laporan dari test tsb.

Belajar Dari Kesalahan

May 31, 2009

Dari berbagai project yg sudah gue kerjakan, sering sekali gue melakukan suatu kesalahan. Bahkan banyak kesalahan-kesalahan dalam satu project yg sama. Ini adalah hal yg bagus, karena mengingatkan bahwa kita semua adalah manusia biasa yg bisa salah.

Yang jadi pertanyaan, apa yg harus dipelajari dari kesalahan tersebut? Tentunya berusaha untuk tidak melakukan hal yg sama di hari kemudian. Tapi buat gue pribadi gue mencoba melakukan suatu hal yg lebih lagi, dgn cara menuliskan kesalahan-kesalahan yg gue lakukan dan membaginya ke orang lain. Dan di team gue yg sekarang sebenernya memang sudah menjadi kewajiban kita untuk membagi ilmu dan pengalaman yg kita miliki ke team yg lain. Oleh karena itulah maka team gue disebut ‘practices’ team.

Jadi skrg gue sedang berusaha menuliskan kesalahan-kesalahan yg gue lakukan dalam implementasi dari project-project gue terdahulu. Sangat jarang gue terlibat dalam suatu infrastruktur network yg benar-benar baru atau dikenal dgn nama ‘Green Field’. Yg lebih sering adalah gue harus membangun dan mengimplementasikan network dgn cara meng upgrade network yg sudah ada. Dan sering kali ini tidak semudah yg terlihat.

Hasilnya nanti adalah strategi dan pendekatan detil yg gue (dan teman-teman se project dulu) lakukan untuk berbagai tipe implementasi dan skenario yg berbeda-beda.
Mudah-mudahan akan bermanfaat.

Dan gue mungkin bukan penulis yg bagus. Gue seorang blogger dan cara penulisan gue mungkin tidak bisa memenuhi persyaratan penulisan dokumen company gue yg sangat tinggi. Tapi gue akan memastikan bahwa tulisan itu nanti akan bisa dibaca oleh orang-orang di dalam organisasi company gue, dan juga buat umum. Paling tidak, tulisan tsb akan gue share di blog.

Gue tidak akan menulis banyak blog selama mengerjakan ini.

Anti BlackBerry

May 1, 2009

“I wake up every evening with a big smile on my face,
And it never feels out of place,
And you’re still probably working at a 9 to 5 pace,
I wonder how bad that tastes..”
- All American Rejects, Gives You Hell -

Kita hidup di masa di mana kita tidak perlu “pergi kerja” lagi. Kita kerja. Dari manapun, kapan saja. Dan kita hidup di dunia tanpa batas. Konsep negara selama meeting online hanya dibicarakan ketika perlu untuk menyamakan waktu karena timezone yg berbeda.

Gue sudah beberapa tahun terakhir masuk kategori mobile worker. Ini berarti gue bisa kerja dgn waktu yg fleksible dan dari mana saja selama gue punya koneksi ke perusahaan.

Jika gue tidak sedang berada di tempat customer, atau sedang berada di jalan mau ke customer, maka gue lebih suka kerja dari rumah. Kerja dari rumah berarti gue tidak perlu menghabiskan waktu untuk perjalanan ke kantor. Ini juga berarti gue mendukung gerakan lingkungan hijau karena lebih jarang memakai mobil, perusahaan gue tidak perlu menyewa kantor yg besar untuk mengakomodasi semua karyawan, dan gue bisa mengatur keseimbangan antara hidup dan kerja secara lebih baik, dan gue merasa bisa kerja lebih efisien. Terlebih karena gue punya semua tool kolaborasi sebagai pendukung.

Perusahaan gue berada di belakang tool-tool kolaborasi pendukung Work 2.0 ini. Gue biasanya tersambung ke Internet dan ke perusahaan gue dgn koneksi yg terenkripsi rata-rata 12 jam sehari. Gue memakai WebEx untuk berkomunikasi dgn customer. Dgn tool yg sama gue setiap minggu meeting dgn team. Anggota team gue tinggal di berbagai negara di Eropa dan Timur Tengah, tapi gue bisa mengadakan Kopi Virtual, meeting dgn mereka menggunakan TelePresence, paling tidak satu atau dua kali dalam sebulan. Gue nonton video training dan membaca buku online dari database internal perusahaan gue. Gue bisa upload dokumen yg sedang dikerjakan dgn WebEx Connect sehingga teman se team gue bisa memberikan review dan sistem akan meng update versi dokumen secara otomatis. Setelah dokumen selesai dan diterima oleh customer, harus di upload ke tempat penyimpanan internal yg bisa dicari menggunakan search engine. Gue bertemu manager gue untuk mendiskusikan karir ke depan menggunakan TelePresence seolah-olah berada di satu ruangan yg sama dgn dia. Kadang gue menggunakan WebEx untuk mengendalikan PC customer supaya bisa konek ke router. Kadang customer yg mengendalikan PC gue dgn tool yg sama supaya bisa konek ke internal lab kita. Gue juga menggunakan Instant Messaging internal yg merupakan tool komunikasi interaktif yg paling sering gue gunakan untuk berkomunikasi di perusahaan.

Semua hal itu kedengarannya keren dan hebat, terutama buat mereka yg belum pernah menggunakannya sendiri. Tapi poin utamanya bukan dari segi seberapa keren dan hebat cara kita bekerja. Yg paling penting adalah hasil kerjanya. Sbg contoh, fokus kerjaan gue adalah network design atau migration plan yg gue bikin untuk membantu customer dalam menjalankan bisnisnya. Gue menggunakan semua tool kolaborasi itu untuk memudahkan komunikasi dgn customer dan rekan-rekan team untuk menyelesaikan pekerjaan. Jadi tool itu bermanfaat utk membantu dalam bekerja, bukan supaya terlihat keren. Gue tahu gue tetap bisa menyelesaikan pekerjaan dgn kualitas yg sama walaupun tidak menggunakan tool-tool tsb, meskipun waktu yg diperlukan mungkin lebih lama atau memerlukan biaya yg lebih mahal. Tool-tool kolaborasi diperlukan untuk membuat proses pekerjaan semakin efisien.

Jadi ini alasan mengapa sampai sekarang gue tidak punya BlackBerry, dan tidak berencana untuk punya. Untuk alasan yg sederhana: gue percaya gue tidak membutuhkannya. Gue bisa menyelesaikan pekerjaan tanpa itu. Gue bisa tetap efisien tanpa itu.
Gue bisa hidup tanpa itu.

Gue hanya menggunakan tool seperlunya dan jika diperlukan saja. Gue gak mau ketagihan dan mulai menggunakan tool berlebihan yg membuat gue malah menjadi tidak efisien. Setelah terkoneksi 12 jam sehari ke Internet dan ke perusahaan, apakah gue masih perlu menerima email kapan saja, di mana saja? Gue rasa tidak. Apakah gue masih perlu untuk browse Internet selama di perjalanan? Gak tuh. Apakah gue harus selalu update status Facebook atau Twitter setiap menit? Yang bener aja.

Gue lebih suka menghabiskan waktu yg tersisa diluar kerjaan untuk menikmati hidup. Sekarang gue punya taman di belakang rumah yg memerlukan perawatan. Gue tinggal di dekat danau kecil dan gue suka menghabiskan waktu untuk jalan-jalan memutarinya. Gue punya daftar hal-yg-harus-dilakukan-selama-hidup dan gue pikir lebih baik mencoba melakukan hal-hal di daftar itu ketimabang berusaha selalu online di Internet. Lebih baik mempelajari hal baru dalam hidup ketimbang duduk di depan komputer. Gue terkoneksi ke Internet hanya jika merasa perlu dan untuk kerja. Dan ketika gue tidak terkoneksi ke Internet, gue masih punya mobile phone gue yg lama. Masih bisa buat nelpon dan ngirim SMS jadi gue pikir sudah lebih dari cukup.

Anti BlackBerry. Mungkin kalian akan bilang gue bego untuk ngomong spt ini di dunia di mana banyak orang percaya bahwa kita semua harus selalu terkoneksi satu sama lain dan menggunakan teknologi terbaru. Gue gak mau. Itu bukan untuk gue.

Gue bukan anti teknologi nya, apalagi anti produknya. Gue anti pemakaian berlebihan dari teknologi spt ini yg membuat kita bukannya menjadi lebih efisien tapi malahan ketagihan untuk tekoneksi ke Internet melakukan hal-hal yg menghabiskan waktu. Jika memang perlu BlackBerry dalam kerjaan ya gunakan saja seperlunya. Kalo gue sih merasa tidak perlu. Dan gue merasa senang hidup tanpa itu. Kalo ada yg mau mengontak gue ketika sedang offline dan tidak terkoneksi ke Internet, cukup dgn menelpon atau ngirim SMS.

Banyak orang bilang gue berpikiran kolot.
Tapi gue hanya mau menjalani hidup sebagaimana yg gue ingat dulu.

Beli Mobil di UAE

April 28, 2009

Iseng-iseng nulis habis begadang semaleman, ttg pendapat pribadi ketika beli mobil di negara Middle East spt UAE. Mudah-mudahan bermanfaat buat yg memang tinggal di daerah sini, dan juga untuk berbagi informasi dgn yg tinggal di Indonesia supaya bisa melihat contoh bagaimana pola pikir kita harus bisa mengikuti tempat di mana kita tinggal.

1. Harga dan Kesempatan
Harga mobil di negara spt UAE memang jauh lebih murah ketimbang di Indonesia untuk merek dan model yg sama dikarenakan pajak kendaraan yg jauh lebih kecil di sini (sebagai gambaran, harga mobil di sini bisa sekitar 50-60% dari harga di Indonesia). Bahkan harga kendaraan di Middle East bisa lebih murah dibandingkan negara-negara di Eropa. Ini menjadi penyebab banyak orang yg menggunakan kesempatan untuk membeli mobil-mobil dgn merek yg mungkin tidak bisa dibeli di negara lain atau di Indonesia karena harganya yg menjadi sangat mahal.
Tapi ada juga beberapa merek yg harganya relatif mahal dibandingkan merek-merek lain, misalnya beberapa mobil Jepang yg harganya jika full option mendekati harga mobil Eropa bekas. Kalau kasusnya seperti ini mungkin jangan pilih mobil Jepang tsb, apalagi jika harga jual bekasnya nanti juga tidak terlalu bagus.

2. Siapkan Mental sbg Pemakai
Di sini mental sbg pemilik mobil tidak bisa seperti di Indonesia “beli mobil untuk disimpan”, jadi mobil dipakai misalnya hanya selama weekend karena alasan sayang ke mobil dan ingin menjaga harga jualnya lagi suatu ketika nanti. Masalahnya adalah walapun kita pakai jarang-jarang dan sudah hati-hati mengendarai mobil kita, tapi sering sekali masalah datang dari orang lain. Kegores orang di parkiran mall, misalnya. Atau ditabrak dari belakang sama orang yg males nginjek rem. Bisa juga orang parkir di sebelah dan buka pintu tanpa mikir sehingga mengenai mobil kita.
Apalagi di kota spt Abu Dhabi yg parkiran mobilnya sangat-sangat rapat di beberapa tempat, mental kita sudah harus siap jika melihat hal spt ini.
Beli mobil untuk dipakai, tetap berhati-hati, tapi kalo ada kejadian spt yg di atas ya tidak perlu dipikirin apalagi sampai sakit hati. Barusan lihat di bemper depan mobil ada goresan kecil. Sepertinya sih ketabrak di tempat parkir :(
Untungnya semua mobil di sini harus dibeli dgn asuransi.

3. Sementara Menjadi ‘Sementahun’
Kebanyakan orang tinggal di negara spt UAE tidak untuk jangka lama. Konsep Permanen Resident tidak ada di sini, jadi mau tinggal lama juga memang sulit. Kita bisa tinggal hanya dgn visa kerja dan ketika tidak punya kerjaan hanya diberi waktu 30 hari untuk mendapat perusahaan yg mau memberi sponsor visa kerja baru atau harus keluar dari negara ini.
Jadi kebanyakan orang berpikir beli mobil hanya untuk sementara. Ada yg bilang sementara menjadi ’sementahun’ karena kenyataannya kita bisa tinggal di UAE sampai paling tidak beberapa tahun.
Nah, sementara kita tinggal di sini dgn harga mobil yg relatif murah, harga bensin yg juga murah, dan memang belum tersedianya transportasi umum yg memadai, mengapa tidak memakai kesempatan dan make the most of it?
Beli mobil dgn merek dan model yg kita suka, yg mungkin di Indonesia tidak mampu dibeli karena harganya yg jauh lebih mahal.

4. Mobil Baru vs. Mobil Bekas
Banyak orang yg suka beli mobil baru karena ingin mengetahui sejarah si mobil dari awal sampai akhir. Tapi masalahnya, harga mobil baru walaupun baru sehari keluar dari showroom sudah jatuh kalo mau dijual lagi. Jadi kalo mau menghemat sedikit, beli mobil bekas yg baru setahun dipakai dgn kilometer pemakaian yg belum terlalu tinggi. Apalagi beberapa mobil menawarkan garansi 3 sampai 5 tahun sehingga kita bisa memanfaatkan garansi tersebut.
Tapi tentunya kita harus berhati-hati dalam membeli mobil bekas walaupun baru setahun dipakai. Yg terbaik tentunya jika kita kenal si pemilik sebelumnya sehingga bisa melihat dari kebiasaannya menyetir dan merawat mobil. Paling tidak, periksa riwayat service mobil dan cari yg selalu menggunakan bengkel resmi. Coba tanya-tanya nama dari pemilik sebelumnya atau kalau ketemu langsung dan dia bawa mobil yg lain coba lihat kondisi mobil yg lain tsb.
Kalo bisa hindari beli mobil dari orang lokal (local UAE citizen) !
Tidak semua orang lokal mengendarai mobil gila-gilaan memang, tapi mereka kebanyakan punya kebiasaan beli mobil baru tiap tahun hanya untuk dicoba dan di push to the limit, untuk kemudian dijual dan beli mobil baru lainnya.
(Coba aja lihat bagaimana orang lokal mengendarai mobil di sekitar kita, atau cari videonya di Internet. Dulu pernah nonton orang lokal yg nyetir mobil mewah dgn kecepatan tinggi untuk kemudian di rem pake rem tangan supaya mobil bisa spin dan diukur siapa yg paling jauh spinnya!)

5. Model dan Warna
Ini memang tergantung preferensi masing-masing orang. Tapi kalo misalnya kita mau pakai mobil impian, paling tidak untuk beberapa tahun, dan juga berharap ketika dijual harganya tidak terlalu jatuh, bagaimana caranya?
Mudah saja, look around.
Lihat aja apa model dan warna yg paling banyak dipakai orang.
Kalau kita tipe yg konservatif, bisa mengikuti pola pikir kebanyakan orang India: beli Corolla. Kalo punya rejeki lebih, beli Camry. Kalo makin makmur, beli Land Cruiser :) Pokoknya harus Toyota yg murah perawatan dan juga gampang dijual lagi. Untuk urusan warna, putih menjadi pilihan kebanyakan orang. Di Indonesia mungkin warna putih bukan favorit, tapi kalau di sini karena matahari yg terik warna ini menjadi lebih bersinar dan tetap keliatan mengkilap walaupun kondisi mobil kotor. Orang lokal paling suka beli mobil Land Cruiser atau Nissan Patrol putih. Kalo punya mobil dgn merek spt salah satu di atas tidak perlu takut ketika akan menjualnya lagi nanti.
Bagaimana dgn mobil kelas atas? Yah, kalo untuk tipe Porsche GT3 atau Ferrari F430 sih pasti selalu ada orang yg mau membeli lagi walaupun jumlahnya sedikit. Dan kalo sudah mampu beli mobil sekelas Porsche atau Ferrari kayaknya gak akan pusing mikirin harga jual deh heheh

6. Kontan atau Nyicil
Sebagian orang tidak mau menyicil karena berkaitan dgn kepercayaan yg dianut. Buat yg bisa, kadang tidak mau karena males ribet dan ingin bisa menjual lagi secepatnya jika ada apa-apa. Kalau mau jujur UAE itu sebenernya terlihat sbg negara yg belum stabil dari segi peraturan. Pola pikir “sementara” masih harus dipertahankan karena peraturan atau kondisi yg bisa saja tiba-tiba berubah sehingga kita harus keluar dari negara ini secepatnya. Jadi kalo spt ini mungkin menyicil lebih baik karena uang kita tidak tertahan di mobil dalam jumlah besar. Dan untuk menghitung besar cicilan bisa memakai mental “sedang menyewa”. Jadi seandainya menyewa mobil perbulan mengeluarkan biaya 2000 Dhs, maka kita bisa saja beli mobil dgn harga cicilan 2000 Dhs. Apalagi kalau dulu bank memperbolehkan Down Payment 0% (di tengah krisis bulan Januari kemaren masih ada bank yg memberi cicilan mobil walaupun Down Payment minimal sudah 20%).
Jadi kalo ada apa-apa dan kita harus keluar dari negara ini secepatnya, mobil bisa kita tinggal saja. Toh hitung-hitung menyewa.
Dan kalo semuanya lancar, setelah cicilan lunas mobil mau kita jual lagi, kita bisa mendapat sebagian uang kita kembali yg tentunya lebih baik ketimbang menyewa beneran.

7. Say Yes to Green Environment, with a different way
Sayangnya di negara spt UAE sangat sulit untuk mendukung aksi ramah lingkungan dgn cara mengganti kendaraan pribadi dgn alternatif lain. Transportasi umum kurang memadai, mono rail baru akan selesai akhir tahun ini kalo lancar. Bike2work? Silahkan aja kalo mau kena kanker kulit heheh. Selain cuaca yg panas selama 7-8 bulan setahun, jalanan di kota seperti Dubai juga tidak dirancang untuk ramah ke pejalan kaki maupun pengendara sepeda. Naik sepeda motor sangat berbahaya karena lebar jalan yg sangat besar dan kecepatan pengendara mobil yg di dalam kota pun bisa mencapai 120 km/jam. Banyak orang termasuk gue merasa kurang aman jika harus mengendarai mobil-mobil ramah lingkungan karena bentuknya yg kecil di tengah-tengah jalan yg besar-besar dan lalu lintas yg sangat cepat. Mobil berbahan bakar alternatif? Kurang populer mungkin karena: banyak orang yg menggunakan mobilnya tidak saja harus kencang di jalan besar tapi juga mampu off road di padang pasir. Selain itu jarak tempuh yg dilalui perhari bisa sangat jauh sekali, banyak orang yg menempuh perjalanan sampai lebih dari 100 km per hari hanya untuk pulang pergi ke kantor.
Jadi mungkin ada cara lain untuk mendukung gerakan hijau. Misalnya, dgn cara kerja di rumah spt gue :) Jadi jarang pake mobil kecuali perlu. Selain ramah lingkungan juga kerja lebih efisien. Apa? Kerjaan yg sekarang tidak memungkinkan buat kerja di rumah? Ya udah, berhenti aja dan cari kerjaan yg bisa seperti ini. Dan mobil tetap SUV yg 4x4 biar bisa off road ke padang pasir heheh

Ini semua cuman pendapat, berdasarkan pengalaman pribadi.
Mudah-mudahan bermanfaat.

Suatu Hari di Kerjaan

April 20, 2009

Gue bangun setelah tidur hanya 2 jam. Tidak ada waktu untuk mandi ataupun sarapan. Masih mengenakan celana pendek gue membuka dokumen IP/MPLS Core Network Low Level Design yg baru saja gue selesaikan beberapa jam sebelumnya. Design ini dibuat berdasarkan diskusi ekstensif dgn customer dan rekan-rekan di team melalui fasilitas online dan conference call. Gue menggunakan best practice dan konsep design yg optimal untuk memastikan semua requirement customer telah terjawab. Materi presentasi design ini juga sudah selesai. Gue baca-baca lagi ke dua dokumen tersebut utk terakhir kalinya untuk memastikan tidak ada kesalahan penulisan.

Gue mengambil sekaleng Red Bull dari kulkas. Laptop gue masih terkoneksi ke network kantor menggunakan saluran yg secure dan terenkripsi. Gue sudah menghabiskan waktu tiap malam sampai jam 5 atau 6 pagi selama sekitar sebulan untuk menyelesaikan design ini. Biasanya gue mengerjakannya dari kamar tidur gue. Ini membuat gue merasa nyaman dan juga selalu dekat dgn keluarga. Gue biasa kerja setelah keluarga tidur, karena kalo siang gue akan sibuk untuk mengurusi hal-hal yg berkaitan dgn pindahan dan juga membantu sang ratu untuk mengurus anak-anak. Dan bekerja di waktu malam membuat waktu gue bisa sinkron dgn rekan-rekan di US. Instant Messaging company gue masih nyala dan berkedip-kedip karena semalaman gue berdiskusi tentang arsitektur hardware yg digunakan di design dengan para developer di San Jose.

Semua kerja keras sudah selesai, saatnya presentasi ke customer.

Gue menghabiskan minuman penambah energi yg sudah membantu gue bergadang selama bermingu-minggu. Gue login ke WebEx untuk menyiapkan sesi meeting yg akan dimulai sebentar lagi. Login juga ke WebEx Connect untuk meng-upload semua dokumen dan memeriksa jika teman-teman team gue memberikan review ke design yg gue buat. Fasilitas callback di WebEx gue gunakan untuk menghubungi IP phone gue, yg suaranya menggunakan speaker sehingga gue bisa ngomong sambil mempresentasikan design atau menggambar sesuatu di aplikasi yg gue share di WebEx. Gue juga mungkin akan men-share desktop gue sehingga customer bisa login ke internal lab dari PC gue untuk memeriksa konfigurasi yg gue gunakan di lab yg mensimulasikan design network mereka. Gue juga sebenernya ingin memakai kamera supaya customer bisa melihat gue ketika presentasi, tapi dgn hanya tidur 2 jam dan belum mandi sepertinya mereka tidak akan tertarik :)

Gue mengirim pesan melalui IM ke teman gue untuk memastikan jika dia bisa melihat materi presentasi gue di WebEx. Dalam beberapa menit customer dan pihak-pihak lain akan join ke sesi meeting ini.

Gue mempresentasikan Low Level Design dari kamar tidur gue di Dubai untuk customer yg berlokasi di salah satu negara di Africa. Teman-teman gue yg terlibat di project ini ada di Spanyol dan Hungaria. Project Manager nya ikut meeting dari rumahnya di Nigeria.

Beberapa orang berkata bahwa inilah cara bekerja di Internet era. Beberapa orang menyebutnya True Collaboration. Beberapa akan menyatakan bahwa tool-tool kolaborasi yg berbasis web ini merupakan perwujudan dari konsep Web 2.0. Beberapa yg lain menamakan fenomena ini sebagai Work 2.0.

Tapi buat gue, ini hanya suatu hari biasa di kerjaan.

Pendaftaran CCDE Practical Exam Dibuka!

April 1, 2009

Pendaftaran untuk CCDE practical lab sudah dibuka mulai tanggal 1 April. Hanya ada 3 tempat di dunia: Chicago, London atau Hong Kong. Ujiannya sendiri masih utk tanggal 26 Agustus 2009.

Cara mendaftar:
1. Lulus ujian CCDE qualification 352-001 exam
2. Punya account di pearsonvue.com (pastinya dong, soalnya pas mau ujian CCDE qualification harus bikin)
3. Klik link di Cisco Learning Network.
4. Klik salah satu lokasi di Registration Steps poin no.2: Chicago, London atau Hong Kong.
5. Lokasi yg dipilih akan me-redirect kita ke website pearsonvue, login, pilih 352-011 CCDE Practical, trus ikutin petunjuk buat bayar.

Buat orang Indo, yg murah sepertinya ke Hong Kong (ada jetstar airways, dan tidur bisa di hotel yg murah) dan juga tidak perlu Visa. Kalo ada yg mau bareng ama gue pilih London :)

Tempat sangat terbatas, jadi yg tertarik silahkan register secepatnya.

CCIE vs. CCDE

March 23, 2009

Barusan lulus ujian CCDE written. Gak belajar karena kesibukan project dan juga masalah pribadi. Gue cuman baca-baca beberapa networkers slides buat refresh dan langsung nekat ujian. Gak taunya lulus dgn score yg lumayan. Gue gak tau kalo bisa melakukan hal yg sama buat labnya nanti (baca: computer based exam dgn pertanyaan yg berbentuk scenario) tapi memang semua teknologi yg ditulis di blueprint sebenernya tidak ada yg baru. Hanya mungkin perlu lebih mendalami implikasi apa dari suatu protokol atau beberapa protokol sekaligus jika dijalankan di satu topologi dgn requirement tertentu.

Mana yg lebih baik: CCIE atau CCDE?

Bagaimana kalo spt ini: ambil CCIE dulu, trus cari pengalaman inplementasi dan design di real world network utk berbagai tipe project, scenario, customer, requirements, baru kemudian ambil CCDE. Bisa-bisa ntar ambil CCDE lab cuman langsung ujian tanpa belajar :)

Silahkan baca argumen gue selengkapnya di sini. Lagi males dan gak ada waktu buat nerjemahin. Selamat memilih, dan selamat belajar.

Mendalami Arsitektur Router, Bagian III

March 8, 2009

Di dua bagian sebelumnya kita sudah mendiskusikan banyak hal tentang arsitektur router. Apa yg harus kita lakukan sekarang? Mari kita melihat fitur dan aplikasi yg berkaitan dgn arsitektur hardware yg sudah kita diskusikan sebelumnya. Gue gak punya lagi gambar-gambar yg bisa ditemui di google untuk menjelaskan topik ini. Dan tentunya gue tidak boleh menggunakan materi dari internal dokumen perusahaan. Jadi biarkan bagian ini menjadi tulisan tanpa gambar sama sekali.

Berikut adalah beberapa contoh fitur dan aplikasi yg harus dimiliki oleh modern dan next generation router:

High Availability (HA) and Fast Convergence
Router pasti gagal suatu ketika. Kegagalan mungkin terjadi di modul route processor, di power supply, switch fabric, line card, atau di keseluruhan chassis. Poin utamanya adalah bukan di cara menghindari kegagalan, tapi bagaimana caranya mengatasi kegagalan tersebut dgn cara meminimalkan waktu yg diperlukan untuk mengarahkan traffic ke modul atau path yg lain.

Buat yg masih suka melihat network sbg suatu koleksi router atau node yg terkoneksi satu sama lain, kegagalan bisa terjadi di link antar node atau di node itu sendiri. Untuk kedua kasus ini, vendor router sudah lama mengenalkan konsep Fast Convergence (FC) seperti IGP FC dan MPLS Traffic Engineering Fast Re-Route (FRR) untuk mengurangi waktu yg diperlukan konvergensi network menjadi minimal. Kunci utamanya adalah kemampuan mendeteksi kegagalan secepat mungkin. Jika node-node tadi terhubung secara langsung, maka kita bisa menggunakan Loss of Signal (LoS) yg terjadi di fisik dari link untuk memberi tahu protokol di layer atas spt IGP. Jika node terkoneksi bukan secara langsung, misal ada layer 2 switch di tengah atau yg lain spt DWDM network, maka suatu node bisa menggunakan fitur Bidirectional Forwarding Detection (BFD) yg mengirimkan paket hello untuk mengetahui status dari node sebelahnya.

Ketika hardware gagal, kita kemungkinan akan melihat paket yg hilang (packet loss) dari network traffic selama beberapa waktu. Dalam banyak kasus ini tidak bisa dihindari dan yg bisa kita lakukan hanya meminimalkan jumlah packet loss dgn cara mereduksi waktu yg diperlukan network untuk meraih konvergensi. Untuk router yg memiliki router processor lebih dari satu, yg di set untuk menyediakan redudancy, fitur Non-Stop Forwarding (NSF) bisa digunakan selama waktu peralihan (switch over) dari primary route processor ke secondary route processor, sebelum secondary bisa mengambil alih sepenuhnya. NSF memberikan transparansi ke level tertentu, karena ketika satu node gagal dia bisa memberi tahu node lain yg terkoneksi bahwa dia akan gagal :) tapi membuat janji bahwa dia akan kembali lagi online (dgn menggunakan secondary route processor) jadi tolong para node yg lain jgn mem-flush routes yg ada di routing table mereka dan tetap mem forward traffic ke node yg gagal tadi.

Node yg gagal itu sendiri harus menggunakan konsep modular spt dijelaskan di tulisan bagian-bagian sebelumnya. Jadi forwarding plane harus dilakukan di lokasi lain selain di route processor, misal di line card. Sebelum terjadi kegagalan, router harus menjalankan fitur Stateful Switchover (SSO) untuk memastikan terjadi sinkronisasi antara primary route processor, secondary route processor, switch fabric dan line card. Selama switch over, sambil menunggu proses initialisasi secondary route processor sebelum bisa mengambil alih, forwarding paket masih bisa dilakukan di line card dgn menggunakan kondisi terakhir di line card forwarding table yg masih terupdate sampai di saat terjadi kegagalan. Jadi kalo node yg gagal masih bisa mem forward paket, meskipun dgn menggunakan forwarding table terakhir sebelum kegagalan, dan node-node lain yg terkoneksi masih mau untuk tetap mem forward paket ke node yg gagal tadi karena sebelumnya sudah diberitahu kalo node itu akan kembali online lagi, maka tidak seharusnya kita melihat ada packet loss sama sekali. Nantinya fitur SSO/NSF ini harus bisa men sinkronisasikan forwarding table ke status terakhir ketika secondary route processor sudah mengambil alih dan node yg gagal sudah berfungsi kembali.

Konsep baru yg sedang sering dibicarakan adalah fitur Non Stop Router (NSR). NSR diharapkan bisa memberi tranparansi penuh kepada node yg lain ketika terjadi kegagalan di satu node. Jika pada NSF meskipun node yg lain masih mau mem forward paket ke node yg gagal sampai jangka waktu yg disetujui, tapi hubungan IGP sudah dinyatakan berhenti. Sedangkan dgn NSR hubungan IGP tetap dipertahankan seolah-olah node yg gagal yg sedang melakukan switch over masih berfungsi seperti biasa.

Jika kita kembali ke diskusi design dan arsitektur hardware, bisa terlihat bahwa komponen utama untuk bisa menyediakan HA dan FC adalah kemampuan secondary route processor untuk selalu sinkron dgn primary route processor, fabric dan line card. Jika ini tidak bisa tercapai maka kita akan melihat packet loss selama proses switch over. Dan tentunya kita semua mengeri bahwa kegagalan di line card maupun fabric, ketika traffic sedang melewatinya, akan menyebabkan packet loss walaupun kita menjalankan fitur HA apa saja. Dan dgn konsep switch fabric yg modular, kita harus memiliki beberapa modul dan jika terjadi kegagalan pada satu modul tidak akan mengurangi kapasitas forwarding paket dari keseluruhan switch fabric.

Quality of Services

Quality of Services (QoS) fitur untuk bisa memberikan perlakuan yg berbeda terhadap paket adalah kebutuhan utama ketika terjadi congestion di network. Yang menjadi pertanyaan, di mana sebenarnya congestion bisa terjadi?

Jika kita menggunakan arsitektur carrier class router di tulisan bagian kedua sebagai referensi, terlihat bahwa congestion bisa terjadi di komponen yg berbeda:
- Egress queue, tempat queue di egress line card sebelum interface fisik: ketika menunggu paket untuk dikirimkan ke media fisik, karena di media fisiknya sendiri sudah terjadi congestion
- Fabric queue, queue untuk menerima paket dari switch fabric di egress line card: karena harus melakukan normalisasi dari paket misalnya kalau paket dikonversi ke cell dgn ukuran yg sama maka harus dikembalikan ke format dan ukuran aslinya. Atau bisa jadi karena di egress queue sudah terjadi congestion maka queue ini juga terkena dampaknya
- Ingress queue, queue sebelum mengirim paket ke switch fabric di ingress line card: sebagai konsekuensi terjadinya congestion di fabric queue atau di fabric, maka queue inipun bisa mengalami congestion

Congestion bisa terjadi di dalam switch fabric itu sendiri. Tapi biasanya untuk kelas carrier-class router design switch fabric sudah dibuat dgn kapasitas yg sangat besar untuk bisa mengakomodasi jika chassis router tadi penuh dgn line card. Kecuali jika switch fabric terdiri dari beberapa modul dan ada modul yg gagal sehingga mengurangi total kapasitas secara keseluruhan.

Jadi kunci utamanya di sini adalah kita harus bisa memberikan QoS atau perlakuan yg berbeda ke paket di berbagai titik di dalam router. Misal, jika di port fisik terjadi congestion maka kita harus bisa membuat paket dgn prioritas tinggi di egress queue untuk dikirimkan terlebih dahulu ke media network. Sama halnya dgn fabric queue. Dan bahkan di dalam fabric sendiri kita harus bisa memberikan prioritas kepada paket ketika terjadi congestion di fabric queue, atau congestion di dalam fabric itu sendiri. Dan ketika terjadi congestion di egress queue, harus ada mekanisme untuk memberi tahu ke fabric queue, yg akan memberi tahu ingress queue untuk memperlambat jumlah paket yg dikirim ke fabric. Mekanisme ini dikenal dgn nama back pressure, dan komunikasi antara fabric queue ke ingress queue bisa dilakukan di bypass link, seperti dijelakan di tulisan bagian kedua. Fabric biasanya hanya mem forward paket dgn satu arah, dari ingress ke egress, dan tidak sebaliknya. Memperlambat jumlah paket yg dikirim ke fabric sebenarnya dilakukan oleh ingress packet engine, karena di sana paket dgn prioritas rendah bisa di drop, sehingga paket yg dikirim ke ingress queue menjadi berkurang.

Sekarang jelas bahwa kita harus menjalankan fitur QoS yg tepat di lokasi yg tepat juga di dalam router. Policing, misalnya, biasa dilakukan di ingress packet engine. Egress queue bisa menggunakan shaping atau mekanisme queuing ataupun congestion avoidance. Fabric queue mungkin hanya perlu memberi tahu ingress queue ketika terjadi congestion di egress line card.

Btw, penandaan paket utk QoS yg biasa disebut marking ketika paket berada di dalam router biasanya diturunkan dari marking yg dilakukan di luar router ke paket dgn menggunakan nilai seperti CoS, DSCP atau EXP. Dan ketika paket berada di dalam router maka yg digunakan adalah internal marking, yg kemudian digunakan oleh fitur QoS di setiap komponen. Adalah tugas dari ingress line card untuk mengkonversi QoS marking dari luar menjadi internal marking.

Satu hal lain yg penting dari fitur QoS adalah kemampuan untuk mensupport QoS dgn model hirarki. Pada network yg biasa, paket yg datang ke line card mungkin hanya punya satu tag atau penanda paket dgn QoS marking yg harus dilakukan ke paket tsb misalnya MPLS EXP bit, atau CoS dan DSCP di IP network. Jadi hanya ada satu perlakuan QoS yg bisa dilakukan ke tipe paket yg memiliki marking yg sama. Tapi bagaimana jika ada paket yg memiliki beberapa tag, dan diperlukan untuk memberikan perlakuan yg berbeda berdasarkan tag yg berbeda-beda tsb? Misal di network Carrier Ethernet di mana suatu paket bisa datang dgn membawa dua 802.1q tag, yg paling atas disebut S-tag untuk mengindentifikasi dari aggregation router mana paket itu datang, dan yg kedua disebut C-tag yg digunakan untuk membedakan VLAN dari customer (ini biasa disebut teknologi Q-in-Q). Kita mungkin ingin memberi perlakukan QoS yg berbeda, jadi di satu hal ingin melakukan QoS untuk semua paket yg memiliki S-tag yg sama, tapi di lain hal kita juga ingin membedakan jika paket datang dgn C-tag yg berbeda atau dari customer yg berbeda. Ini berarti router (dan line card) harus mensupport model QoS secara hirarki, dimana QoS main class akan mempengaruhi semua paket dan kita bisa membuar QoS child class yg spesifik untuk setiap customer.

Multicast
Untuk sebuah network yg berisi beberapa node yg saling terkoneksi, traffic multicast berarti satu paket datang dari satu sumber atau source dan direplikasikan ke beberapa node lain tergantung dari request untuk join multicast group tsb. Sekarang saatnya kita untuk melihat lebih dalam dan bertanya: siapa yg melakukan proses replikasi paket di dalam router?

Paket multicast bisa dibedakan dgn cara melihat tujuan IP address yg merupakan multicast group address. Di dalam router replikasi paket bisa dilakukan di ingress line card, disebut ingress replication, atau di egress line card, disebut egress replication. Dgn menggunakan multicast control plane protokol seperti PIM, ingress line card mengetahui egress line card tujuan untuk setiap multicast group address. Contoh ada dua port di ingress line card, dan multicast paket (S,G) diterima di satu port. Dari lookup di ingress packet engine atau network processor bisa diketahui yg tertarik dgn multicast group itu dan menjadi tujuan adalah port lain di ingress line card yg sama dan juga line card yg lain. Ingress line card bisa melakukan ingress replication untuk memperbanyak paket dan mengirimkannya ke port yg berada di line card yg sama, dan juga ke line card yg lain melalui backplane atau switch fabric.

Jika kita selalu melakukan ingress replication ada isu performance yg bisa terjadi. Ambil contoh ada multicast traffic yg diterima oleh ingress line card dgn rate sebesar X Gbps. Dan ada 10 ports di engress line card yg tertarik untuk join multicast group itu. Jika kita melakukan ingress replication make ingress line card harus menperbanyak setiap multicast paket menjadi 10 kali, yg berarti total mutlicast traffic rate yg harus dikirimkan ke fabric menjadi 10 X Gbps. Untuk skenario spt ini tentu lebih baik menggunakan egress replication dimana ingress line card hanya perlu mengirim satu paket ke tiap egress line card yg tertarik. Dan jika ada beberapa port di egress line card itu yg tertarik utk join multicast group yg sama, maka replikasi bisa dilakukan oleh si egress line card utk mengirim paket ke semua port tadi. Jadi egress replication dalam hal ini digunakan untuk menghindari pengiriman multicast traffic yg tinggi oleh ingress line card ke switch fabric.

Di carrier-class router, switch fabric bahkan jauh lebih pintar sehingga bisa melakukan replikasi paket multicast di dalam fabric. Sehingga ingress line card hanya perlu mengirim satu paket saja ke fabric, kemudian fabric lah yg akan mereplikasi paket dan mengirimkan nya ke egress line card yg tertarik, kemudian egress line card bisa melakukan replikasi lagi jika ada beberapa port di line card yg sama yg tertarik ke multicast group itu.

Performance and Scalability
Setelah membaca sampai sini, harusnya kita semua sudah mulai selalu menanyakan ketika melihat suatu fitur atau protokol: apakah itu dilakukan di software atau di hardware? Apakah central CPU yg melakukannya atau di distribusikan ke line card? Apakah dilakukan di ingress line card atau egress? Jika iya, bagus, akhirnya sudah mulai kelihatan apa manfaat untuk mengetahui ini semua.

Sebelum melanjutkan gue mau menjelaskan secara singkat satu komponen penting lagi di hardware untuk forwarding plane, yaitu Ternary Content Addressable Memory (TCAM). Intinya sih TCAM ini adalah high speed memory yg digunakan untuk menyimpan data-data forwarding table atau fitur lain seperti access control list, misalnya, sehingga router bisa melakukan switching di hardware dgn performance tinggi. Masih ingat konsep forwarding table di push dari central processor ke line card, untuk kemudian dari line card processor ke hardware? TCAM digunakan untuk menyimpan informasi tsb. Jadi sekarang kita tahu bahwa harus ada memory yg cukup untuk menyimpan semua informasi itu, dgn kata lain TCAM merupakan salah satu yg membatasi forwarding path. Jika route processor mem push data lebih banyak dari yg TCAM bisa tangani, maka kita akan berada di kondisi yg tidak konsisten antara route processor dan line card. Sehingga meskipun route processor tahu apa yg harus dilakukan ke paket, tapi hardware bisa jadi tidak memiliki data tsb dan akan men drop paket yg lewat itu.

Dengan melihat arsitektur modular dari suatu next generation router, jelas sekarang jika kita ingin mendapat performance non-blocking atau line rate switching paket maka kita harus memastikan setiap komponen di forwarding path untuk mendukung performance line rate. Ini berarti jika kita mau mem forward X Gbps traffic tanpa ada congestion, maka tiap komponen dari ingress processor dan queue di ingress line card, kapasitas fabric, fabric queue, egress processor dan egress queue di line card harus mampu memproses X Gbps atau lebih. Jadi jika kita ingin tahu di mana terjadi bottleneck di dalam router, periksa kapasitas dan kemampuan memproses paket di tiap komponen. Jika kita tahu kemampuan dari ingress line card ke fabric hanya X Gbps, tapi kita memiliki beberapa port di line card itu dgn total kapasitas lebih dari X, ini berarti kita melakukan sesuatu yg disebut over subscription. Dan dengan mengetahui dimana terjadinya congestion maka kita bisa menjalankan fitur QoS yg tepat di komponen yg tepat juga. Misalnya, jika terjadi congestion seperti di atas maka penggunaan QoS egress queue tidak akan membantu karena masalahnya adalah di queue ke switch fabric.

Mungkin ada yg bertanya, mengapa kita harus memikirkan kapasitas dan performance dari route processor, jika kita tahu kemampuan router yg sebenarnya adalah di forwarding plane yg berarti ada di line card? Karena kita masih tetap membutuhkan route processor untuk menjalankan fungsi control plane. Kita butuh CPU yg bagus untuk bisa memproses banyaknya paket control dan routes dari IGP dan BGP. Kita masih tetap butuh memory yg besar di route processor karena ini adalah tempat menyimpan informasi yg diterima dari router lain, yg kemudian baru bisa di push ke line card. Kita juga masih memerlukan flash disk atau storage lainnya yg cukup untuk menyimpan image dari router software beserta file-file lain seperti logging dan crash dump.

NGN Multi-Service Features and Application
Sangat wajar di next generation network untuk membawa tipe servis dan aplikasi yg berbeda-beda. Aplikasi yg paling seri digunakan selain multicast untuk IPTV, adalah MPLS L3VPN untuk customer bisnis, Internet, L2VPN point-to-point atau multipoint dgn VPLS dan lain-lain. Kompleksitas menjadi bertambah ketika kita harus menggabungkan dan menjalankan beberapa fitur secara bersamaan.

Sebagai contoh, jika kita mempunyai network yg menjalankan teknologi MPLS, maka penambahan label atau imposition terjadi di ingress line card setelah lookup. Tapi bagaimana jika kita menjalankan fitur lain seperti salah satu tipe L2VPN yg bisa dijalankan di software atau di central route processor? Ini berarti kita membutuhkan label imposition untuk dilakukan di egress line card.

Dan bagaimana jika line card harus melakukan lookup beberapa kali untuk paket yg sama? Misalnya, jika kita harus membuang dua label MPLS sekaligus di router MPLS terakhir jika fitur Penultimate Hop Popping (PHP) tidak digunakan di MPLS L3VPN network. Biasanya ini dilakukan supaya router MPLS terakhir itu tetap mendapat EXP bit di MPLS label teratas untuk QoS. Lookup pertama yg harus dilakukan adalah dgn melihat tag MPLS teratas. Kemudian lookup berikutnya dilakukan untuk melihat MPLS VPN tag supaya bisa diasosiasikan dgn VRF. Kemudian setelah kedua MPLS tag tadi dibuang, router masih harus melakukan lookup lagi di IP forwarding table untuk menentukan ke egress interface mana paket harus dikirim. Melakukan lookup beberapa kali utk paket yg sama ini memperkenalkan kita akan konsep recirculation, dimana paket akan di loop di dalam ingress line card. Jadi setelah lookup yg pertama paket tidak dikirim ke fabric, tapi akan mendapat informasi layer 2 yg baru dan di re-write namun dikirimkan kembali ke line card yg sama seolah-olah ini adalah paket berikutnya yg harus diproses.

Multicast VPN bisa memberikan kita tantangan yg lain. Untuk sekedar menyimpulkan, dgn mengetahui bagaimana protokol dan fitur bekerja, dan digabungkan dgn pengetahuan tentang arsitektur hardware berikut komponen apa yg melakukan hal tertentu, kita bisa mencoba melihat masalah-masalah apa yg mungkin timbul pada saat suatu design di implementasikan. Dan kita mungkin sudah bisa memikirkan apa yg harus kita lakukan untuk mengatasinya.

Jujur saja, gue sudah sangat sulit untuk mendiskusikan hal ini secara lebih detil, karena berbagai alasan. Pertama, karena sekarang sudah jam 4 pagi. Dan gue belum tidur selama 2 hari untuk menulis Trilogi ini sambil mengerjakan hal yg lain juga. Apakah gue pernah bilang betapa berterima kasihnya gue kepada mereka yg menemukan Red Bull? Tapi untuk sekarang ini, minuman energi spt apa juga tidak akan bisa membuat gue tetap bangun.

Yang kedua, walaupun gue masih mau menulis lebih banyak tentang topik ini tapi kemungkinan sulit untuk bicara lebih detil tanpa mendiskusikan beberapa informasi internal dari perusahaan gue, yg tidak boleh gue lakukan. Well, kita lihat saja nanti. Mungkin gue akan dapet ide baru setelah tidur yg benar.

Selamat malam.
Akhir dari trilogi tulisan.

Mendalami Arsitektur Router, Bagian II

March 7, 2009

Jadi di bagian I gue sudah menjelaskan bagaimana dasar dari proses switching paket di dalam router. Biasanya memang kita selalu melihat router hanya sebagai node yg memiliki beberapa interface, sehingga fokus kita adalah di komunikasi antar router untuk membuat routing table. Setelah routing table jadi kita mengasumsikan bahwa paket masuk ke satu interface dan keluar dari interface lain router sesuai dgn tujuan. Untuk kasus paket multicast, maka paket akan masuk ke satu interface dan keluar ke beberapa interface, sesuai dgn request untuk join multicast group tersebut. Bahkan jika ada fitur spt filter maupun Quality of Services (QoS), ketika kita melihat router hanya sbg sebuah node dgn interface ingress dan egress, biasanya kita berpikir bahwa fitur tadi dijalankan dgn arah ingress ke router atau egress dari router, dan fitur tsb pasti jalan spt magic.

Setelah membaca bagian I jelas sekarang bahwa ada hal-hal lain yg sama pentingnya dgn membangun routing table. Yg pertama adalah membangun forwarding table. Forwarding table ini berisi informasi tentang next hop tujuan dan juga next hop interface untuk setiap network tujuan, seperti halnya routing table, dgn tambahan informasi Layer 2 dari next hop. Paket harus dikirimkan keluar dari router dgn header Layer 2 yg baru sehingga sangat penting untuk melakukan proses re-write layer 2 di paket. Hal berikutnya yg penting adalah proses lookup, yaitu mencari entry network tujuan yg sesuai di forwarding table. Paket juga harus disimpan di suatu tempat sambil menunggu proses lookup selesai dilakukan. Kemudian paket harus dipindahkan ke lokasi yg berbeda (di router yg lama paket yg sebenarnya masih berada di lokasi memory yg sama, namun dgn pointer yg berbeda untuk membedakan kondisi paket sebelum lookup dan sesudah lookup dilakukan). Terakhir, penting juga untuk menjalankan fitur atau policy ke paket di dalam router. Sangat penting untuk mengerti hal-hal di atas, termasuk di komponen mana hal tersebut dilakukan.

Pertama-tama, mari kita semua mengerti konsep untuk memisahkan router menjadi dua plane, control plane dan forwarding plane. Sebenarnya ada yg ketiga yg disebut management plane, yg digunakan untuk berinteraksi dgn router, tapi mari kita fokus ke dua yg pertama saja. Control plane adalah hal-hal yg berhubungan dgn komunikasi antar router menggunakan routing protokol, untuk membuat routing table dan forwarding table, yg bisa digunakan untuk switching paket dari interface ingress ke egress. Proses switching paket antar interface yg berbeda itu yg disebut data atau forwarding plane.

Mari kita melihat gambar dari salah satu contoh next generation dan carrier-class router di bawah ini.

Arsitektur router modern menggunakan konsep modular dimana hal-hal yg berbeda dilakukan di lokasi yg berbeda oleh komponen yg berbeda juga. Ini sangat kontras dgn arsitektur sederhana di tulisan bagian pertama dimana hanya ada satu main board, central route processor dan memory, dan komunikasi bus dgn PCI antara network card ke processor. Route processor di modern router tetap otak utama dari keseluruhan sistem. Tapi fungsi dari switching paket termasuk proses lookup bisa dilakukan di hardware lain yg berbeda. Network card, atau biasa disebut line card, bisa memiliki processor sendiri untuk melakukan lookup dan hardware khusus yg digunakan untuk melakukan switching paket yg sebenarnya. Dan untuk menghubungkan komunikasi antar line card maupun central route processor bisa menggunakan switch fabric, yg dikenal dgn istilah backplane dari sebuah router. Konsep modular digunakan untuk mengatasi isu skalabilitas dan juga untuk menghindari konsep all-in-one dimana kegagalan satu module bisa menyebabkan kegagalan dari keseluruhan sistem, atau disebut single point of failure.

Jadi si central route processor sendiri sudah berupa line card sekarang dan masih tetap dibutuhkan untuk menjalankan fungsi control plane, yaitu berkomunikasi dgn router lain dgn protokol routing untuk membuat routing table dan forwarding table. Forwarding table ini bisa di push ke network processor di tiap line card. Dgn memiliki informasi ini, network processor di line card bisa melakukan lookup sendiri dan re-write informasi layer 2 ke paket. Untuk meningkatkan performance dalam melakukan switching, atau menjalankan fitur spt filter sebagai contoh, hardware khusus bisa digunakan yg di program hanya untuk menjalankan instruksi khusus, biasa disebut Application Specific Integrated Circuit (ASIC).

Gambar di bawah bisa menjelaskan bagaimana informasi untuk forwarding paket dibangun di central route processor untuk kemudian di push ke line card.

Route processor menggunakan protokol routing spt ISIS, OSPF dan BGP untuk membangun Routing Information Base (RIB) yg dikenal dgn nama routing table. Di next generation networks, sangat wajar untuk menggunakan bukan IP sbg informasi dalam melakukan forwarding paket, tapi menggunakan MPLS label. Jadi MPLS label untuk route atau prefix yg spefisik dikomunikasikan dan disetujui oleh para router di network, dgn menggunakan protokol untuk mendistribusikan label spt LDP, RSVP atau bahkan dgn BGP. Tentunya protokol untuk mendistribusikan label ini masih bergantung pada protokol routing agar para router bisa saling berkomunikasi. Dan routing table berikut database label-label digunakan untuk membuat Label Forwarding Information Base (LFIB), yg berisi next hop dari tujuan beserta MPLS label yg harus digunakan, untuk ditambah (dikenal dgn istilah label push) atau dibuang (dikenal dgn istilah label pop) dari paket, sebelum paket dikirim keluar di interface egress.

Baik forwarding table maupun label forwarding table bisa di push ke network processor di line card menggunakan Inter Process Communication (IPC). Jika semua paket yg datang harus diproses oleh network processor di line card, maka kita hanya memindahkan kemampuan memproses paket dari sistem tersentralisasi menjadi sistem terdistribusi. Lebih jauh lagi, network processor bisa membuat instruksi specific untuk menjelaskan hal apa yg harus dilakukan ketika ada paket yg datang ke line card, dan mem push instruksi ini ke hardware khusus seperti ASIC. ASIC bisa melakukan instruksi untuk memproses paket tidak hanya di layer 2, tapi juga di layer 3 dan layer 4 berikut fitur spt filter dll, dan ini bisa dipisahkan di ASIC yg berbeda untuk mendapat performance yg lebih baik lagi.

Sampai ke titik dimana informasi untuk mem forward paket dikirim ke line card dan ke hardware khusus, adalah bagian dari control plane. Melakukan proses switching oleh hardware atau ASIC dari satu line card ke line card lain, adalah bagian dari forwarding plane.

Carrier class router dari Cisco malah mengembangkan konsep modular ini menjadi lebih jauh lagi, dgn memperkenalkan konsel Modular Services Card (MSC). Jadi line card dipisahkan menjadi dua bagian: fisik dan otak. Yg berupa fisik, dinamakan PLIM – Physical Layer Integrated Module, berurusan hanya dgn Layer 1 di TCP/IP stack, termasuk memberikan kita port fisik untuk mencolokkan kabel. Dan MSC adalah si otak line card yg memproses lebih lanjut setelah PLIM mengkonversikan bits dan sinyal digital di kabel untuk menjadi paket. Tujuannya adalah untuk memberikan kelebihan dalam hal skalabilitas. Jadi bagian fisik bisa diganti atau di upgrade ke port yg kapasitasnya lebih besar misalnya, dan MSC nya masih bisa tetap sama. Demikian juga suatu ketika kapasitas MSC bisa diperbesar tanpa harus mencabuti bagian fisik dan kabel-kabel yg tercolok di port.

Mari melihat lebih dekat tentang bagaimana paket diproses di line card menggunakan konsep arsitektur MSC di atas. Ini adalah diskusi yg sangat menarik yg biasa disebut Life of a Packet.

Dari PLIM paket dikirimkan ke MSC melalui midplane (atau untuk mempermudah bisa saja kita membayangkan semua process ini terjadi di satu line card tanpa ada pemisahan PIM, midplane dan MSC). Kemudian paket diproses oleh Ingress Packet Engine, yg sudah memiliki informasi dari processor di line card untuk instruksi apa yg harus dilakukan kepada paket yg datang. Setelah diputuskan apakah paket akan dikirim ke line card yg lain atau ke central route processor (untuk kasus dimana paket dikirim ke IP address dari si router atau paket-paket untuk mengkontrol router, maka paket akan dikirim ke central route procesor) kemudian paket akan dikirim ke switch fabric atau backplane, dgn menggunakan header internal tambahan untuk memastikan hanya line card tujuan yg akan menerima paket ini. Untuk beberapa arsitektur router, paket yg melalui switch fabric harus distandarkan untuk memiliki besar yg sama. Hal ini karena untuk sebuah hardware untuk memproses paket dgn besar yg sama akan menjadi lebih mudah dan lebih cepat. Di arsitektur lain paket dikonversi menjadi format yg baru (spt cells dgn besar yg sama dan header yg baru) ketika paket itu melewati backplane. Jadi tentunya harus ada buffer atau queue untuk meletakan paket sebelum dikirimkan ke backplane. Backplane sendiri bisa berupa module atau line card yg didesign untuk menghubungkan semua line card yg lain, termasuk route processor. Kita akan mendiskusikan tentang backplane atau switch fabric di pembahasan berikutnya.

Dari switch fabric paket dikirimkan ke line card tujuan dan tentu diperlukan buffer yg lain di sana untuk tempat mengkonversikan kembali paket menjadi bentuk yg semula dgn besar paket yg sesuai aslinya. Kemudian ada egress packet engine yg bisa digunakan jika ada fitur atau hal lain yg perlu dilakukan di paket. Untuk beberapa kasus khusus, MPLS label bisa di push di sini. Untuk kasus umumnya, layer 2 re-write atau MPLS label di push di ingress engine, jadi di egress tidak perlu lagi ada proses lookup selain mungkin menjalankan fitur dgn arah egress. Dan untuk carrier-class router engine ingress maupun egress bisa ada di hardware yg sama maupun hardware yg berbeda untuk memberi performance yg tinggi. Sebelum paket dikirimkan keluar melalui interface fisik, harus ada queue atau buffer lain untuk tempat paket menunggu giliran sebelum dikirim ke port dan dikonversikan menjadi sinyal digital.

Ketika melihat skema fisik dari MSC seperti gambar di bawah, sangat mudah untuk melihat tiap komponen dan ada beberapa hardware berbeda yg digunakan untuk melakukan hal yg berbeda. Jalur untuk memforward paket di dalam line card pun bisa terlihat jelas.

Di arsitektur router yg lain, hardware yg memproses paket yg datang mungkin tidak bisa melakukan lookup dan harus menanyakan central route processor. Tapi line card ini sebenarnya mampu untuk mem forward paket langsung ke line card yg lain, jika sudah tahu tujuannya ke mana. Untuk melakukan ini, line card tidak perlu mengirimkan keseluruhan paket ke route processor, namun hanya meng copy layer 3 header dari paket dan itu yg dikirimkan ke route processor. Setelah route processor menjawab dan line card tahu line card tujuan, maka paket bisa dikirim langsung melalui switch fabric.

Ketika kita mendiskusikan switch fabric atau backplane, router lama dan kelas mid-range ke bawah mungkin masih menggunakan arsitektur bus seperti gambar di bawah. Jadi meskipun setiap linecard sudah punya processor sendiri untuk melakukan lookup sekalipun, tapi dgn backplane bus setiap paket yg dikirim oleh line card akan diterima oleh semua line card yg lain.

Bus menggunakan konsep yg sama spt teknologi Ethernet, dimana ketika ingress line card mengirim paket ke bus maka semua line card yg lain akan menerima. Tapi hanya switching engine atau egress line card tujuan yg akan memproses paket itu lebih lanjut. Dari sini bisa kelihatan kalo bottleneck atau limit dari performance switching paket ada di kapasitas bus backplane tsb.

Arsitektur yg lebih baik menggunakan konsep crossbar spt di bawah.

Dengan teknologi crossbar, setiap ingress line card bisa mengirim paket ke semua line card lain dalam satu waktu. Tapi karena egress line card hanya bisa menerima paket dari satu ingress line card dalam satu waktu, maka harus ada controller atau scheduler untuk memastikan hanya ada satu ingress line card yg berhubungan dgn egress line card. Controller bisa berupa bagian dari switch fabric atau bisa menjadi module yg terpisah untuk alasan skalabilitas dan memberikan redundancy jika salah satu module gagal.

Ada arsitektur router yg masih menggunakan kedua teknologi crossbar fabric dan bus. Bus masih digunakan untuk bisa berkomunikasi dgn line card yg lama. Jadi misalnya line card yg lama masih belum memiliki koneksi backplane yg baru, hanya punya bus. Line card baru walaupun sudah memiliki koneksi backplane yg baru tapi tetap harus menggunakan bus untuk bisa berkomunikasi ke line card lama tsb. Dan pada beberapa kasus, bus masih digunakan oleh line card untuk mengirimkan paket ke central route processor.

Teknologi switch fabric terbaru sudah sangat pintar dan bisa melakukan lookup, replikasi paket di dalam fabric, dan menyediakan kapasitas maksimum yg disebut line rate ke egress line card. Sebagai contoh jika setiap line card terhubung ke fabric dgn koneksi X Gbps, maka pada setiap waktu selama paket yg dikirim dari fabric ke egress line card adalah X Gbps atau kurang, traffic dari ingress ke egress akan terjamin untuk berada dalam kapasitas performance maximum dan tidak ada congestion walaupun paket itu datang dari beberapa ingress line card yg berbeda. Dan di carrier-class router biasanya kapasitas untuk menerima paket dari fabric itu dua kali lipat atau lebih dibandingkan kapasitas untuk mengirim paket ke fabric. Jadi jika line card mampu mengirim paket ke fabric dgn koneksi maksimum X Gbps, maka setiap line card akan mampu menerima 2 sampai 2.5X Gbps dari fabric, untuk mengakomodasi beberapa line card mengirimkan paket ke egress line card yg sama secara bersamaan.

Dengan menggunakan fabric tipe ini, harus ada bypass link antara ingress line card dan egress line card yg tidak melalui fabric. Tujuan bypass link ini bukan untuk mem forward paket, tapi biasanya digunakan oleh egress line card untuk memberi tahu ingress line card jika terjadi congestion. Sehingga ingress line card kemudian bisa memperlambat jumlah paket yg dikirimkan ke switch fabric.

Ada hal-hal lain yg harus didiskusikan ketika paket berada di dalam fabric. Seperti sudah gue sebutkan sebelumnya, paket itu sendiri bisa di standarisasi untuk menjadi cells yg memiliki ukuran yg fix (dgn cara melakukan fragmentasi jika paket lebih besar, atau menambahkan pad jika paket lebih kecil dari ukuran tsb). Proses switching paket di fabric bisa menjadi sangat cepat jika paket itu sudah dikonversikan menjadi format internal dgn ukuran yg seragam dan menggunakan internal header. Di carrier class router bisa ada beberapa langkah ketika memproses paket, bahkan ada proses lookup untuk memastikan bahwa paket akan dikirimkan hanya ke egress line card tujuan saja. Tentu ini adalah alasan mengapa internal header harus digunakan di dalam fabric, karena proses lookup di fabric tidak sama dgn lookup di ingress line card processor yg masih menggunakan IP atau MPLS label forwarding table. Jika fabric tidak melakukan lookup, maka ingress line card bisa menambahkan internal header, yg kemudian akan digunakan oleh controller di crossbar fabric untuk menghubungkan ingress line card dgn egress line card. Jadi internal header ini merupakan suatu overhead pada paket di dalam fabric.

Setelah membaca sampai ini, apakah masih merasa bahwa pengetahuan ttg proses switching paket di dalam router tidak bermanfaat? Jika iya, silahkan meneruskan membaca ke bagian ketiga di mana gue akan mencoba menjelaskan implikasi dari arsitektur hardware ke fitur dan aplikasi yg berjalan di atasnya.

Akhir dari bagian kedua.