Mendalami Arsitektur Router, Bagian I

Waktu gue masih muda ceile heheh gue sering melihat router hanya sebagai “black box” atau “node”. Maksudnya, gue dulu tidak tertarik untuk melihat proses switching paket di dalam router itu sendiri dan lebih fokus ke protokol komunikasi dan fitur yg dijalankan antar router. Sebenernya mungkin bukan tidak tertarik. Tapi kalo tidak bekerja di perusahaan yg membuat router, memang bisa kita mendapat informasi yg sangat mendetil tentang ini? Paling tidak sekarang gue punya kesempatan untuk mendalami arsitektur router secara lebih detil.

Dan memang sebenernya pengetahuan tentang proses di dalam router tidak selalu dibutuhkan dalam kehidupan network engineer sehari-hari. Bahkan para CCIE sekalipun bisa jadi hanya melihat router sbg box yg memiliki banyak interface, yg berfungsi mem forward paket ke router berikutnya berdasarkan routing table yg dibangun secara dynamic maupun static. Maka biasanya kita lebih memberi fokus ke komunikasi antar router untuk membangun routing table itu ketimbang proses switching paket dari satu interface ke interface lain di dalam router. Sebagai contoh di OSPF, diskusi tentang LSA, database, algoritma SPF dll bisa sangat membingungkan, terutama jika kita harus melakukan redistribusi dgn protokol IGP yg lain atau BGP dan sebagainya. Sehingga yg penting itu adalah kita bisa melihat routes atau prefix tujuan di routing table, dan jika tidak ada filter atau policy yg lain, biasanya kita mengasumsikan paket akan di proses oleh si black box dan di forward ke box berikutnya dan seterusnya. Kemudian kita akan berurusan dgn fitur lain maupun aplikasi yg dijalankan di atas routing, misalnya MPLS, Traffic Engineering, VPN dll.

Jadi buat kebanyakan orang mungkin sudah cukup untuk mengatakan proses switching paket di dalam router adalah dari interface input, biasa disebut ingress, ke interface output atau egress. Mungkin ketika belajar CCIE kita akan mendalami sedikit untuk mengerti urutan dari implementasi beberapa fitur ketika dijalankan secara bersamaan. Misal, apakah NAT duluan atau Access Control List? Bagaimana dgn Policy Based Routing yg bisa membuat routing table diabaikan? Dan sebagainya. Tapi kita tidak pernah benar-benar melihat komponen apa saja di dalam router dan fungsi mereka dalam mem forward paket.

Mengapa penting untuk mengerti proses switching packet internal?
Buat gue pribadi, untuk mengerti keterbatasan dari implementasi protokol dan fitur karena hardware. Dan gue pikir ini penting buat setiap network designer. Kita bisa saja membangun network design berdasarkan data sheet. Jadi kita bisa merekomendasikan jumlah dan tipe hardware untuk core router, aggregation, access dst. Kemudian kita bisa merekomendasikan protokol dan fitur apa yg harus dijalankan, lengkap dgn konfigurasinya yg kita ambil dari Configuration Guide di website vendor router. Kenyataannya, walaupun untuk protokol itu ada standar internasional spt IEEE maupun RFC, tapi implementasi tiap vendor bisa berbeda karena pengertian masing-masing terhadap standar itu. Bisa jadi juga karena vendor menemukan metoda sendiri ketika mengikuti standar. Dan untuk beberapa fitur, atau bagaimana suatu protokol di implementasikan, sangat tergantung dari arsitektur hardware router. Jadi setelah network yg kita design selesai dibangun dan sudah jalan, mungkin baru kita mulai melihat adanya limitasi di performance atau isu dgn skalabilitas ketika jumlah traffic di network tinggi maupun ketika ingin mengembangkan design tersebut.

Gambar di atas bisa digunakan untuk memahami proses switching paket yg sangat sederhana. Paket datang dari media network dan kabel tentunya dgn Layer 3 dan Layer 2 dari standar TCP/IP stack. Interface processor di router mampu untuk mengambil paket tsb, memeriksa header Layer 2 sekaligus membuang header tsb, dan mengirimkan paket tadi ke route processor utk diproses lebih lanjut. Sambil menunggu route processor melakukan lookup atau pencarian di routing table (dan forwarding table) tentunya paket itu harus disimpan di suatu buffer atau queue. Setelah next hop dari tujuan si paket ditemukan di table, maka route processor sekarang tahu ke interface mana paket harus dikirimkan. Kemudian paket dapat dipindahkan ke output queue, tempat untuk menunggu sebelum paket bisa dikirimkan ke media network, dan paket akan di re-write atau mendapat layer 2 header yg baru yg berisi informasi untuk next hop berikutnya, kemudian paket keluar dari router melalui interface. Input queue atau output queue ini bisa virtual, jadi si paket sebenarnya berada di memory fisik yg sama dan tidak pernah berpindah. Tapi dgn membuat dua kondisi yg berbeda ketika paket berada di input queue (sebelum dilakukan lookup) dan ketika sesudah berada di output (setelah lookup dan tahu paket harus dikirim ke interface yg mana), maka router bisa menjalankan fitur atau melakukan perlakuan yg berbeda terhadap si paket di dua kondisi tersebut.

Jadi kata kuncinya adalah: Layer 3 dan layer 2 header, routing table dan forwarding table, lookup, perpindahan packet ke lokasi atau queue yg berbeda, output queue, layer 2 re-write.

Mari kita melihat sekali lagi dgn lebih detil. Ini adalah gambar dari buku Inside Cisco IOS Architecture karangan Vijay Bollapragrada, untuk proses switching paket yg sederhana yg disebut process switching.

Ketika interface processor menerima paket dari network media di input interface atau ingress, paket tsb harus disimpan di buffer atau memory (1) dan di saat yg bersamaan harus meng-interrupt main processor (2) untuk memberi tahu ada paket yg harus diproses. Buku ini fokus ke arsitektur software, maka dijelaskan kalo processor akan memanggil proses yg disebut ip_input di Cisco (3) untuk melakukan lookup di routing dan forwarding table. Lookup ini menghasilkan ke interface output atau egress mana paket harus dikirmkan (4). Processor kemudian melakukan layer 2 re-write atau memberi layer 2 header baru ke paket (5) dan memindahkan paket tadi untuk diproses oleh processor di interface egress (6), sehingga akhirnya paket keluar lagi ke network media. Step 7 hanya menjelaskan bahwa main processor akan diberi tahu kalau paket sudah dikirimkan keluar, sehingga memory yg digunakan untuk menyimpan paket bisa dibebaskan dan counter di interface bisa dinaikkan sesuai dgn jumlah paket yg keluar.

Gue harus mengakui kalo gue tidak akan bisa menjelaskan sebagus Vijay (dan pengarang lainnya), jadi gue menyarankan untuk membaca buku ini buat yg masih penasaran. Tapi poin utama gue disini adalah untuk menekankan ada hal-hal lain yg harus dilakukan selain lookup di routing table, yaitu memindahkan paket itu sendiri dari interface ingress ke egress, re-write layer 2 header ke paket dll yg akan menjadi penting dalam diskusi berikutnya.

Jadi mengapa penting untuk mengerti proses internal untuk switching paket di dalam router? Biasanya kita memang selalu fokus ke proses interaksi antar router dgn protokol routing untuk memastikan routing table bisa dibangun. Setelah table tsb jadi, proses lookup Layer 3 itu sendiri dapat dilakukan dgn sangat cepat. Untuk setiap paket yg datang kita harus melakukan pencarian di database yg berisi daftar network tujuan yg diketahui dgn interface egress yg berhubungan. Proses lookup atau pencarian bisa dilakukan sgt cepat terutama karena vendor spt Cisco sudah mengembangkan mekanisme dan algoritma sehingga perbandingannya tidak perlu satu-satu di daftar dari atas sampai bawah. Dgn menggunakan Cisco Express Forwarding (CEF), input dari routing table akan menjadi dasar pembuatan struktur data mtrie seperti digambarkan di bawah. Dgn melakukan proses lookup seperti di gambar, ketika entry ditemukan maka akan ada pointer ke table lain yg disebut adjacency table, yg berisi informasi dari Layer 2 untuk next hop tujuan.

Gue tidak mau terlalu detil mendiskusikan masalah lookup di CEF ini, karena ada satu buku berjudul sama yg khusus didedikasikan untuk itu. Dan gue mau mendiskusikan lebih ke arah arsitektur router hardware ketimbang algoritma CEF, jadi gue sarankan untuk membaca buku Cisco Express Forwarding tersebut dan juga buku Vijay yg tadi.

Sekarang mari bicara tentang proses perpindahan paket dari interface ingress ke egress. Seperti sudah dijelaskan sebelumnya, paket bisa disimpan di central memory selama menunggu proses lookup dilakukan. Jadi interface ingress bisa mengirimkan paket ke sana, dan kemudian egress bisa mengambil paket tsb dari tempat yg sama. Dgn prinsip spt ini terlihat bahwa keterbatasan atau bottleneck dari si proses ada di performance central memory, dan juga kemampuannya untuk melayani beberapa request dari interface processor yg berbeda secara bersamaan.

Untuk meningkatkan performance memory, penggunaan local memory di interface bisa dilakukan. Jadi paket akan disimpan di local memory interface ingress, kemudian di copy ke central memory melalui komunikasi bus yg bisa diakses interface mana saja, dan kemudian egress tujuan akan meng-copy paket tsb ke local memory nya. Mungkin timbul pertanyaan, mengapa dari ingress local memory tidak langsung dikirimkan ke egress local memory? Tunggu dulu. Ini bisa saja dilakukan tapi berarti si interface processor di ingress harus lebih pintar dan melakukan proses lookup sendiri untuk menentukan ke interface egress mana paket harus dikirimkan. Ini akan gue diskusikan di bagian berikutnya.

Ketika kita membuka penutup router lama utk kelas mid-range atau menengah, kemungkinan kita akan melihat sesuatu yg mirip spt gambar di bawah. Main board adalah komponen dasar tempat meletakan semua komponen lain untuk saling dihubungkan. Ada central atau main route processor, central memory, network card untuk interface keluar, PCI bus untuk komunikasi dari network card ke route processor, dan komponen lain spt flash memory tempat menyimpan software image si router, boot ROM untuk menyimpan firmware atau program kecil yg digunakan untuk booting router sebelum software image bisa dijalankan, dan sebagainya.

Balik lagi ke kata kunci: Layer 3 dan layer 2 header ada di dalam paket. Input queue atau buffer bisa berada di local memory ingress network card atau di central memory. Routing table dan forwarding table dibangun oleh route processor dgn menggunakan protokol routing untuk berkomunikasi dgn router-router lain. Layer 3 lookup (dan juga proses pencarian informasi untuk layer 2 next hop tujuan) dilakukan oleh route processor dgn menggunakan algoritma yg membandingkan tujuan si paket dgn daftar di routing table dan forwarding table. Proses perpindahan paket antara lokasi atau queue yg berbeda, bisa berarti paket dari local memory ingress network card di copy ke central memory menggunakan PCI atau komunikasi bus, untuk kemudian di copy oleh engress network card ke local memory nya. Output queue bisa ada di local memory egress network card atau central memory. Layer 2 re-write untuk memberi header layer 2 yg baru ke paket dilakukan oleh route processor sebelum paket bisa dikirimkan keluar router. Fitur-fitur spt filter ataupun NAT dilakukan oleh route processor. Menjalankan fitur di interface ingress atau egress bisa berarti route processor akan menjalankan fitur ke paket untuk kondisi sebelum lookup dilakukan dan sesudah lookup dilakukan, ketika interface egress sudah diketahui.

Apakah gambar yg terakhir mengingatkan kita akan sesuatu? Ya, gambar itu mirip sekali dgn gambar skema dan komponen dari sebuah PC! Ini adalah alasan mengapa beberapa orang yg berbakat bisa membuat software router mereka sendiri, untuk dijalankan oleh PC normal, menambahkan beberapa network card, dan meng-klaim bahwa router bikinan mereka bisa mengalahkan router bikinan vendor yg dijalankan di hardware khusus.

Pendapat gue tentang ini: tergantung. Jika kita membandingkan router bikinan di atas PC tadi dgn router lama di kelas mid-range, ini bisa saja benar. Karena hampir semua hal dilakukan oleh cetral processor dan memory, seperti halnya PC, sehingga yg harus kita lakukan adalah membuat software router yg mampu melakukan lookup dan switching paket, dan melakukan optimisasi untuk memastikan resource tsb digunakan dgn lebih baik.

Tapi bagaimana dgn fitur-fitur baru di next generation network? Fitur-fitur tsb sangat kompleks dan membutuhkan kerja sama team, termasuk juga non-teknis untuk membuat keputusan bagaimana suatu protokol dan fitur harus diimplementasikan meskipun sudah ada standar. Dan di bagian kedua gue akan menjelaskan apa yg vendor sudah lakukan untuk membuat router modern atau next generation router. Karena tentunya tantangannya bukan lagi melakukan switching paket dari interface ingress ke egress, tapi bagaimana melakukan itu secara cepat. Dan ini harus dilakukan secara konsisten untuk paket dgn tipe yg berbeda-beda, dgn besar paket yg berbeda, dgn jumlah yg sangat besar untuk mengakomodasi besarnya traffic di network sekarang ini. Kemudian tantangan berikutnya adalah bagaimana untuk menjalankan beberapa fitur yg harus dilakukan di hardware, sbg contoh bagaimana memberikan perlakuan yg berbeda ke paket di interface egress berdasarkan prioritas untuk dikirimkan ke network media. Atau ketika proses re-write layer 2 di paket harus dilakukan di hardware supaya bisa mendapat performance yg maximum.

Jika sudah membaca sejauh ini dan merasa informasi yg dibutuhkan sudah cukup dalam kerjaan sehari-hari, dan merasa lebih penting untuk berfokus ke komunikasi antar router, atau protokol dan fitur yg harus dijalankan di beberapa router, maka silahkan untuk tetap melihat sebuah router itu sbg black box atau node dgn banyak interface untuk paket masuk dan keluar. Dan tidak perlu untuk membaca bagian berikutnya dimana gue akan mendiskusikan dgn lebih detil bagaimana proses switching paket di dalam paket bekerja.

Akhir dari bagian pertama.

Menjadi CCIE Dengan Simulator FAQ

Gue menerima banyak email yg menanyakan hal-hal yg berhubungan dgn menjadi CCIE dgn menggunakan simulator/emulator. Gue jadikan FAQ berikut.

Mana yg lebih baik untuk latihan CCIE, emulator atau real lab?
Tergantung. Dynamips adalah sebuah emulator yg “menipu” IOS software beneran sehingga mau dijalankan di PC biasa. Sampai sekarang dynamips mensupport IOS untuk Cisco router tipe 7200, 3600, 3700 dan 2600. Jadi kalo kita harus mencoba feature untuk switch ataupun router diluar itu kita harus menggunakan real lab.

Apa sebenernya kekurangan dynamips?
Performance, walaupun ini tidak penting buat latihan CCIE, juga feature yg tergantung dari hardware/linecard spt beberapa feature QoS, dan feature diluar IOS yg sudah disupport dynamips seperti L2 feature dari Cisco switch 3550 dan 3560. Dan ketika menggunakan dynamips, jika ada masalah yg dihadapi kita harus tahu apakah masalahnya dari config yg salah, bugs di IOS atau bug di dynamips itu sendiri.

Track CCIE mana yg bisa dilatih hanya dgn emulator?
Untuk track Service Provider, kita bisa latihan sampai hampir 100% dari feature yg diujikan. Dan meskipun ada switch di track ini tapi fokus utamanya adalah infrastruktur core network sebuah ISP jadi gue percaya kita tidak perlu latihan terlalu dalam untuk feature L2 switch. Untuk track Routing & Switching, gue pikir dynamips masih bisa cover sampai 90% dari feature yg diujikan. Walaupun emulator ini sudah support ethernet module tapi memang belum bisa digunakan untuk mengetes feature L2 switch seperti VTP dan STP. Tapi kalo hanya L3 feature dari switch 3550 atau 3560 sebenarnya bisa dilakukan atau akan memiliki kesamaan prilaku dgn menggunakan router. Untuk security, dynamips masih bisa digunakan untuk latihan IOS Firewall, IOS IDS, VPN antara router, dan feature security dari router (ACL, NAT, RTBH dll) . Hanya memang lebih dari setengah feature yg diuji harus dilakukan di Firewall, VPN, IDS dan Cisco Secure ACS beneran. Untuk track yg lain sepertinya emulator ini tidak terlalu bermanfaat. Coba lihat CCIE lab blueprint dan daftar peralatan CCIE lab untuk mendapat gambaran lebih jauh.

Apa yg hanya bisa didapat di real lab?
Menggunakan real lab berarti kita akan bisa menguji semua feature yg ditanyakan atau terdaftar di CCIE lab blueprint. Kita juga mendapat performance router beneran, kemampuan untuk menguji feature yg bergantung dgn hardware/linecard, dan kita juga bisa menjualnya kembali setelah selesai. Terakhir, suara bising yg keluar dari real lab. Gue dulu sering tidur di sebelah lab gue jadi sampai sekarang gue merasa kadang-kadang suka mendengar suara bising tersebut di kepala.

Jadi bagaimana cara mengatasi kekurangan dynamips?
Ada beberapa pilihan. Kita bisa beli real lab walaupun ini berarti kita harus mencoba membuat lab yg sama persis dgn CCIE lab, yg berarti investasi yg dikeluarkan bisa mahal. Namun ketika sudah selesai, dan kondisi lab kita masih bagus, bisa jadi kita jual kembali real lab itu ke orang lain yg sedang belajar CCIE tanpa rugi sepeserpun. Pilihan lain adalah dgn menyewa online rack di Internet. Keuntungannya adalah kita hanya perlu PC biasa dan koneksi Internet untuk bisa latihan dari manapun, dan kita tidak perlu investasi besar di awal seperti kalo harus membeli real lab, walapun tentunya uang yg kita gunakan untuk membayar rental tidak akan kembali. Pilihan lain yg bagus adalah menggabungkan antara dynamips dan online rack. Jadi kita latihan sebanyak mungkin dgn dynamips dan ketika sudah dekat waktu ujian sewa online rack buat latihan. Untuk track seperti Security, bisa saja kita beli Firewall dan VPN kemudian dikoneksikan ke dynamips untuk latihan. Kemudian untuk belajar IDS, dan latihan dgn komplit lab, kita bisa sewa online rack selama beberapa hari. Tulis semua pilihan yg mungkin, beserta untung rugi masing-masing, sebelum memutuskan mau pakai yg mana.

Ada gak orang yg lulus CCIE dgn dynamips saja?
Ada. Gue kenal banyak orang yg lulus CCIE dgn menggunakan hanya dynamips atau emulator lain. Bahkan gue pribadi untuk CCIE yg ke-3 di track Service Provider hanya menggunakan emulator yg mirip dgn dynamips. Dan tidak, gue tidak akan menjelaskan itu apa, baik di sini maupun lewat email jika ada yg mau bertanya lebih jauh tentang apa yg gue pakai dulu itu.

Apakah orang yg lulus CCIE dgn dynamips bisa disebut CCIE juga, apalagi kalo tidak pernah pegang router beneran?
Lah, ya iya dong. CCIE itu kan didapat hanya dgn lulus ujian lab. Yang penting justru setelah itu, dimana CCIE harus punya pengalaman dan skill yg benar-benar bisa digunakan di kehidupan nyata. Jadi bisa jadi seseorang tidak pernah pegang router beneran dan lulus CCIE dgn hanya menggunakan dynamips. Setelah jadi CCIE dia harus punya pengalaman di kehidupan nyata. Ini yg menjadi pembeda antara CCIE yg satu dgn yg lain.

Tolong ajarin cara mengkonfigur dynamips ya?
Gak. RTFM. Googling

Boleh kirim IOS buat digunakan di emulator?
Gak. Dan sebenernya menggunakan IOS tanpa license itu melanggar hukum. Tapi kalo cuman untuk di lab sepertinya Cisco tidak akan mengejar-ngejar. Tapi gue tidak akan mengirim IOS ke siapapun.

Bagaimana untuk menemukan info jika ada masalah di dynamips?
Sekali lagi, RTFM dan Googling. Dan sangat baik jika mau bergabung dgn milis dan forum yg membahas ttg dynamips. Seperti gue sebutkan di atas, jika ada masalah ketika latihan CCIE dgn dynamips kemungkinan itu adalah masalah di salah config, atau IOS bugs, atau bug di dynamips. Dgn bergabung secara aktif di milis maka kita bisa berdiskusi dan membahas jika ada masalah dgn dynamips nya sendiri. Sehingga kita bisa membantu komunitas untuk menjaga dan mengembangkan emulator yg hebat ini.

Jadi kesimpulannya, mendingan pake emulator atau real lab?
????!@#$%^&* Balik lagi ke atas dan baca lagi dari awal.

Tahun Baru

Tahun baru. Harapan baru. Mimpi baru. Target baru. Teman baru. Tujuan baru. Tantangan baru. Petualangan baru.

Hmm, sepertinya lebih cocok:

Tahun baru. Team baru. Home base baru. Nomer HP baru. Apartment baru harus dicari. Mobil baru harus dibeli. Bank dan kartu kredit baru*

Selamat tahun baru 2009.

*bukan, ini bukan wishes tahun baru Ini adalah sebagian dari tantangan dan masalah yg harus gue selesaikan karena baru pindahan

Carrier Class Router

Dalam beberapa hari ke depan Cisco akan meluncurkan produk baru carrier-class router yg menurut gue pribadi termasuk salah satu produk yg revolutioner. Gue tidak bisa memberikan informasi lebih banyak di sini, yg jelas gue sudah mengikuti perkembangan produk ini di internal Cisco sejak beberapa waktu lalu. Sebenernya ada dua produk baru di segmen ini, yg satu malahan sudah dirilis langsung ke beberapa customer terpilih sedang yg satu lagi yg akan diluncurkan ke publik minggu depan. Jangan tanya mengapa dilakukan berbeda spt ini, kalopun gue punya jawabannya gue tidak boleh untuk menuliskannya di sini.

Mengapa sekarang? Mengapa produk baru dgn target market Carrier dan Service Provider? Gue yakin ini semua karena Cisco CRS-1. Butuh waktu bertahun-tahun buat Cisco untuk meriset CRS-1 dan ketika produk tsb diluncurkan tahun 2004 CRS telah berhasil membuat standar baru dari sebuah carrier-class atau next-generation router. Sudah beberapa tahun CRS diluncurkan dan gue pribadi bisa melihat sudah banyak sekali keberhasilan implementasi CRS-1 di customer seluruh dunia. CRS-1 diposisikan sbg Core router di network, jadi ketika berhasil maka sangat masuk akal untuk mulai menggunakan teknologi yg telah diriset untuk membuat produk-produk baru untuk segmen market yg berbeda atau posisi yg berbeda di network.

Beberapa hal di bawah ini adalah karakteristik dan teknologi baru yg kemungkinan besar akan menjadi standar dasar dari pengembangan sebuah produk baru untuk carrier dan service provider di masa depan:

Distributed Architecture - sudah lama kita meninggalkan arsitektur router yg tersentralisasi dan menggunakan sistem yg terdistribusi. Di arsitektur tersentralisasi CPU adalah otak dari sistem dan merupakan pusat dari segala kegiatan termasuk mem forward packet. Di arsitektur terdistribusi CPU atau Route Processor (RP) digunakan hanya untuk control plane: untuk adjacency routing protokol dgn router lain, membuat routing table, membuat forwarding table, dan mengirimkan forwarding table ini ke linecard. Jadi semua proses forwarding packet dilakukan oleh linecard tanpa perlu menggangu RP lagi. Bahkan fungsi RP menjadi lebih sedikit karena di CRS untuk mengatur sistem pendingin dan LED untuk alarm sudah ada fan controller sendiri dan alarm module yg terpisah. Jumlah RP di CRS bisa lebih dari dua yg akan bermanfaat untuk beberapa fitur baru yg akan dijelaskan kemudian.

High Availability - RP harus redundant, ini bukan hal baru sebenernya. Saat primary RP mati maka secondary RP akan mengambil alih. Bedanya sekarang: tidak boleh ada packet yg di drop dalam proses RP failover ini. Karena forwarding packet sudah dilakukan oleh linecard maka ketika RP mati dan melakukan failover ke backup RP, packet tetap bisa di forward dgn menggunakan forwarding table meskipun ini adalah table dgn status terakhir sebelum terjadi failover. Tapi bagaimana dgn switch fabric? Fabric menghubungkan semua linecard untuk memforward packet dari satu linecard ke linecard lain. Di router lama meskipun forwarding packet dapat dilakukan saat failover, tapi kadang saat backup RP yg menjadi aktif harus berkomunikasi dgn fabric dan semua linecard maka akan terjadi packet drop. Ini bukan isu di CRS dan tentunya switch fabric nya juga redundant.

Modular Line Card = PLIM + MSC - CRS memperkenalkan tipe baru dari linecard dimana satu module itu dibentuk oleh dua card yg dihubungkan di tengah chassis oleh passive midplane. Card yg pertama itu disebut Physical Layer Interface Module (PLIM) hanya untuk physical layer, menyediakan physical port dan melakukan framing. Sedang card yg kedua disebut Modular Services Card (MSC) yg merupakan otak dari linecard. MSC yg melakukan lookup ke forwarding table, mengimplementasikan QoS (di buffer atau interface queue) dan Access Control List dan lain-lain. Tanpa MSC maka PLIM adalah dump hardware dgn physical port tanpa intelegensi. Tanpa PLIM maka MSC hanyalah otak tanpa port yg bisa digunakan untuk berkomunikasi dgn dunia luar. Ini konsep yg menarik karena bisa saja ketika beli kita mulai dgn PLIM yg murah dan port dgn speed yg rendah, tapi di kemudian hari bisa PLIM itu bisa kita upgrade dgn port yg speed nya lebih tinggi tanpa harus meng upgrade MSC. Sebaliknya bisa saja kapasitas MSC kita upgrade dgn mengganti MSC yg baru tanpa harus mencopot kabel-kabel yg terpasang di port PLIM.

Non-blocking ports, non-blocking fabric - hardware yg sekarang mampu menjalankan 40Gbps dalam satu port. Ini harus benar-benar 40Gbps untuk input dan output dgn kecepatan linerate atau biasa disebut non-blocking. Bisa dicapai karena di PLIM/MSC ada dua ASIC yg berbeda untuk menghandle ingress dan egress traffic. Jadi walaupun ASIC yg menghandle ingress overload tetap tidak akan menggangu ASIC yg menghandle egress traffic. Dan port yg linerate harus disupport oleh switch fabric. Di router-router sebelumnya fabric itu dimulai dari yg paling sederhana dgn teknologi bus sampai ke cross-bar dan semuanya masih harus melakukan scheduling untuk mengatur linecard mana yg bisa mengakses fabric karena kapasitasnya yg tidak terlalu besar. Sekarang sangat berbeda karena semua linecard bisa mengirimkan packet ke fabric kapan saja. Btw, pada saat packet dikirim ke fabric maka akan diubah menjadi cell dgn size yg tetap, yg tentunya akan lebih efisien untuk diproses ketimbang packet biasa yg memiliki size yg berbeda-beda.

Multicast replication - multicast menjadi bagian penting dalam hidup kita terutama karena tingginya permintaan untuk teknologi IPTV maupun Video streaming yg menggunakan multicast. Semua router bisa menghandle multicast traffic tapi apakah router tsb bisa menghandle traffic multicast yg sangat besar? Replikasi packet untuk multicast harus dilakukan tidak saja di linecard tapi juga di switch fabric. Jadi ketika ingress linecard menerima packet multicast dan mengirimkan ke fabric, fabric harus melakukan replikasi sesuai dgn engress fabric mana yg memerlukan packet multicast tsb (karena adanya IGMP join misalnya). Kemudian ketika packet sudah mencapai egress linecard bisa jadi ada beberapa port yg memerlukan multicast packet tadi sehingga replikasi harus dilakukan lagi di sini. Jangan lupa kita juga harus punya buffer atau queue yg berbeda antara unicast dan multicast. Tujuannya adalah agar traffic unicast tidak bisa menggangu traffic multicast dan sebaliknya. Rata-rata service provider menggunakan networknya untuk kedua tipe traffic unicast dan multicast streaming jadi keduanya harus bisa bekerja dgn performance yg maksimum tanpa menggangu satu sama lain.

QoS in every aspect - next-generation carrier-class router dibangun dgn QoS mindset. Jika di produk sebelumnya QoS itu hanya ada di interface buffer maka harus ada mekanisme yg memberikan differentiated service jika terjadi congestion di switch fabric. Well, sebenernya sulit sekali untuk membuat switch fabric congest karena kapasitasnya yg besar sekali. Tapi congestion ini bisa terjadi misalnya di buffer ketika packet dikirim dari switch fabric ke linecard. Jadi meskipun klasifikasi ke packet atau class-of-service di fabric tidak bisa se extensive spt di interface queue, paling tidak kita harus bisa memprioritaskan packet tertentu agar tidak di drop ketika fabric buffer atau queue itu penuh. Ketika terjadi congestion di fabric queue ada mekanisme back-pressure yg akan memberi tahu ingress interface bahwa telah terjadi congestion dan ingress interface ini bisa memperlambat jumlah packet yg dikirim ke fabric dgn cara buffering atau men drop packet dgn prioritas yg rendah.

Multi Chassis - ini adalah konsep break-through dimana beberapa router bisa dihubungkan menjadi satu seolah-olah satu physical router. Sangat bermanfaat untuk meningkatkan kapasitas dari sistem secara keseluruhan, lebih efisien karena ada resource yg bisa digunakan bersama, dan mengenalkan beberapa konsep baru spt router collocation ataupun router hosting dgn teknologi Secure Domain Routers (SDR) yg akan dijelaskan kemudian. Dgn multi-chassis akan ada satu atau lebih chassis yg khusus berfungsi sbg switch fabric chassis. Jadi ingress linecard di satu chassis akan mengirimkan packet ke bagian pertama dari fabric masih di chassis yg sama, kemudian packet tsb (sudah menjadi cell skrg) akan dikirim ke switch fabric chassis yg akan melakukan lookup dari linecard tujuan dan replikasi jika diperlukan, kemudian packet akan dikirim ke linecard tujuan di chassis yg berbeda atau bahkan di chassis yg sama dgn ingress linecard yg pertama.

Zoning Power System - mekanisme redundancy dari power supply yg biasa dgn hanya dua power supply atau lebih untuk memberikan 1+1 redundancy ini tidaklah cukup. CRS-1 16-slot memperkenalkan zoning power system dimana ada 2 power slot dan setiap slot ada 3 power module, dan setiap power slot dibagi menjadi 6 zone. Zone 1 memberi power untuk 4 slot linecard yg pertama, sedangkan zone 6 memberi power untuk 4 slot linecard yg lain. Ada 2 zone yg digunakan untuk memberi power ke RP, Switch Fabric, dan Fan controller. Dgn sistem zoning ini bisa saja kita memasang 2 koneksi ke tujuan yg sama di 2 linecard yg berbeda yg berada di zoning power yg berbeda.

IOS XR for carrier-class router - siap-siap untuk belajar IOS XR suka atau tidak, karena ini adalah software pilihan untuk next-generation dan carrier-class router yg berbeda dgn IOS sebelumnya. Banyak orang yg bertanya mengapa size IOS itu sangat besar, mengapa IOS mempunyai family yg berbeda-beda, mengapa banyak sekali bugs yg ada di daftar bug tool di website Cisco. Pertama, semua software pasti ada bug. Kalo ada vendor router tidak mengumumkan bug list ke public karena mereka bilang softwarenya tidak ada bug, mereka pasti bohong. Dan sebagai pemakai router tsb siap-siap saja untuk mendapat kejutan dan behavior router yg aneh secara tiba-tiba, yg mungkin bisa dihindari jika kita punya daftar dari bug sebelumnya yg diketahui. Kedua, IOS itu dibuat sudah lama sekali dan ditujukan untuk bisa mengakomodasi semua tipe customer dgn requirement yg berbeda-beda. Ada versi IOS yg bisa mengakomodasi desktop protocol dan disaat bersamaan punya fitur MPLS untuk service provider. Jika satu software mau memiliki semua feature maka size nya akan menjadi besar sekali. Dan tentunya makin banyak feature makin besar kemungkinan untuk kena bug. Kalo kita mengumpulkan semua bug tsb, walaupun ada bug yg hanya kena di fitur tertentu yg tidak dijalankan, maka daftar bug nya bisa menjadi sangat panjang. Sekarang Cisco sudah memisahkan IOS untuk segmen yg berbeda walaupun untuk hardware platform yg mirip, misalnya untuk Cisco 7600 ada IOS SR yg lebih fokus ke fitur Service Provider sedangkan untuk Cisco 6500 ada IOS SX yg lebih fokus ke fitur Enterprise.

Micro kernel, modular and self-healing - perbedaan utama antara IOS XR dan IOS adalah IOS XR menggunakan micro kernel dan arsitektur yg modular, sedangkan IOS biasa disebut monolithic karena semua proses dan aplikasi ada di satu file besar. Di XR, micro kernel adalah jantung dari software dan kita bisa menambahkan subsystem, module-module software dan aplikasi di atasnya. Jadi proses-proses Control Plane, Data Plane dan Management Plane terpisah-pisah secara independen. Dgn konsep modular ini istilah self-healing menjadi masuk akal karena jika ada isu di salah satu subsystem tidak akan mengganggu subsystem yg lain. Dan setiap proses memiliki memory space sendiri yg terproteksi sehingga isu di satu proses bisa diperbaiki secara otomatis tanpa menggangu proses yg lain. Proses spt OSPF bisa di restart tanpa harus menggangu proses BGP, misalnya. Ini yg gue sebut true modular software.

In Service Software Upgrade - ISSU menjadi istilah yg sangat populer di kalangan para pengguna router. Namun banyak orang yg berpikiran ISSU berarti kita benar-benar bisa melakukan upgrade software tanpa downtime sama sekali di segala situasi. Mari berpikir spt ini: walaupun software sudah modular dgn micro kernel, sama spt operating system pada umumnya tentunya ada proses-proses dasar yg harus ada supaya sistem tsb bisa jalan. Jadi walaupun kita bisa melakukan hitless upgrade tanpa ada packet drop karena beberapa subsystem yg diupgrade hanya perlu restart proses, tapi ada juga subsystem yg memerlukan restart total saat upgrade. Dan yg gue tahu sampai sekarang belum ada vendor router yg bisa melakukan software upgrade untuk major version tanpa restart sama sekali. Jadi tanyakan pada vendor pertanyaan spesifik jika kita punya requirement utk ISSU. Dan walaupun arsitektur hardware sudah terdistribusi spt yg dijelaskan sebelumnya, sehingga walaupun RP direstart saat upgrade maka forwarding packet yg dilakukan di linecard akan tetap berfungsi. Pertanyaannya: bagaimana jika firmware dari linecard itu sendiri yg mau diupgrade? Gue gak bilang ISSU tidak sempurna, cuma menyarankan agar kita bisa melihat teknologi ini secara lebih spesifik dan untuk kondisi yg berbeda-beda kemudian menyesuaikannya dgn kebutuhan yg kita inginkan.

IOS XR was built for CRS - ya ini benar, XR dibuat dgn dasar arsitektur hardware nya CRS. Dan ketika sudah teruji dan dianggap berhasil, tentunya wajar jika menginginkan XR untuk platform router yg lain spt Cisco GSR. Walaupun GSR bisa menjalankan IOS XR, tapi file yg digunakan tentunya berbeda dgn file XR yg digunakan untuk CRS. Ini mudah dimengerti, sama halnya dgn adanya Linux untuk 32-bit dan 64-bit dgn file yg berbeda. Yg paling penting sekarang hanya ada satu IOS XR dgn CLI yg sama untuk router-router di core Service Provider, sehingga tidak ada family yg berbeda-beda spt IOS. Dan walaupun sama-sama IOS XR, karena file XR nya berbeda untuk GSR yg memiliki arsitektur hardware yg berbeda dgn CRS, maka IOS XR untuk CRS dan GSR (dan kemungkinan untuk produk-produk baru di masa depan) memiliki fitur yg sedikit berbeda. Btw, buat yg sudah terbiasa dgn IOS siap-siap untuk kaget ketika pertama kali pake IOS XR CLI. Hal-hal yg kita ingin diperbaiki di IOS sudah diakomodasi di IOS XR. Mulai dari hal kecil spt penulisan subnet mask yg bisa menggunakan /, konfigurasi yg tidak akan langsung di apply sampai kita ketik commit, fitur untuk rollback ke konfigurasi sebelumnya sampai fitur-fitur baru spt admin plane config mode dan juga always-on debug. Usahakan untuk bisa pegang satu XR router dan coba sendiri.

Say goodbye to route-map - next-generation router butuh cara yg next-generation juga untuk mengatur Route Policy. IOS XR mengenalkan Route Policy Language (RPL) untuk menggantikan route-map. Ini adalah bahasa programming baru yg di embedded di XR dgn tujuan agar bisa membuat route policy yg sangat scalable. Spt bahasa programming lainnya RPL punya conditional operators spt if, if-then, if-else, kemudian ada Booleans dan Compound Booleans dan lain-lain. Kita bisa menggunakan parameter dan variable, policy nya bisa di nested, dan yg terbaik adalah kita bisa menggunakan policy yg sama berulang-ulang di policy lain dgn variable yg berbeda-beda untuk kondisi yg berbeda-beda. Keliatannya susah namun begitu sudah terbiasa sangat sulit untuk kembali ke route-map.

Secure Domain Routers, beyond virtual routers - gue pribadi makin sering melihat customer Service Provider yg menggunakan kemampuan ini di live netowrk. Dgn SDR kita bisa mempartisi satu chassis router kita menjadi beberapa router yg benar-benar berbeda. Ini tidak sama dgn konsep virtual router karena setiap router di SDR memiliki RP sendiri, linecard dan memory space sendiri. Yg digunakan secara bersama hanya chassis dan switch fabric. Jika ada isu di salah satu router SDR tidak akan mengganggu router SDR yg lain. Untuk ini kita memerlukan RP yg akan digunakan untuk keseluruhan chassis, ini disebut admin SDR, dan juga perlu Distributed RP (DRP) yg diinstall di slot yg biasa digunakan oleh linecard. Dari admin plane config mode kita bisa mengalokasikan DRP tadi dgn beberapa linecard tertentu untuk menjadi satu SDR. Admin SDR bisa membuat dan menghapus SDR tapi tidak bisa tahu apa yg terjadi di dalam SDR karena seolah-olah adalah router yg berbeda. Bahkan komunikasi antara satu SDR dgn SDR lainnya harus melalui kabel eksternal. Hal ini memunculkan istilah baru yaitu collocation router karena satu physical router bisa menjadi beberapa router yg berbeda yg bisa digunakan untuk fungsi dan di posisi yg berbeda-beda di network (satu di core satu di edge misalnya). Bagaimana dgn ide router hosting? Jika kita punya chassis bisa saja kita menyewakan SDR buat customer sama halnya seperti server hosting. Kemungkinan untuk melakukan inovasi baru dalam mengimplementasikan ini sangat terbuka luas.

Control Plane Policing with Local Packet Transport Services - ada beberapa tipe packet yg tetap harus diproses oleh Route Processor. Misalnya packet-packet control plane spt routing protocol atau network management. RP juga harus memproses packet yg ditujukan ke router itu sendiri, misalnya dgn tujuan loopback IP address atau IP address dari interface si router. Dan bisa jadi ada yg mematikan CEF switching sehingga router menjalankan process switching yg berarti setiap packet harus diproses oleh RP sebelum bisa diforward. Jadi jelas RP harus dilindungi dari packet-packet yg memang harus diproses oleh RP. Yg pertama mungkin jika ada orang pintar yg mengirimkan Denial of Service attack dgn cara mengirim TCP syn packet yg sangat banyak ke loopback IP address misalnya. Dan kedua, RP juga harus dilindungi dari packet-packet yg memang harus diproses dan bukan attack spt routing protocol maupun network management agar tidak mengkonsumsi semua resource RP tsb. Ini gunanya Local Packet Transport Services (LPTS) yg di enable secara default di CRS untuk membatasi jumlah packet yg bisa mencapai RP.

So it’s true, just as in School of Rock “One great rock show can change the world”, I guess one great product can change the world too. Make one revolutionary product, and the rest is just history.

Get Ready.

Bratislava!

Setelah project gue di Prague selesai gue langsung terbang ke Munich untuk bertemu dgn team gue dan juga team WWSP lain yg sama-sama mengcover Europe and Emerging Markets (EUEM) tapi di teknologi yg berbeda. Yap, ternyata team gue mengcover negara-negara europe yg sudah mature spt UK, Spain, Italy dan juga Emerging Market yg mencakupi Central and Eastern Europe, Latin America and the Caribbean, the Middle East and Africa, and Russia and CIS. Gue juga tentunya menyempatkan diri untuk datang ke Oktoberfest. Apa yg gue temukan di Munich sudah gue tuliskan di blog gue yg lain.

Semenjak Jum’at kemarin gue sudah ada di Bratislava. Buat yg males googling, ini ibukota negara Slovakia, salah satu negara di Eastern Europe. Yg lucu gue masih inget ketika beberapa tahun yg lalu nonton film Eurotrip dan ada satu scene yg menggambarkan ttg Bratislava:

Film itu memang lucu bgt meskipun kenyataan yg sebenernya USD 1.83 mungkin cuman bisa buat beli sekaleng Coke. Dan Bratislava di kenyataan adalah kota yg sangat indah. Mirip dgn Prague yg punya banyak bangunan lama bersejarah, apalagi di tengah kota Bratislava berdiri Castle yg sangat megah, dengan jumlah turis yg lebih sedikit. Kalo tidak percaya silahkan saja google image sendiri. Gue sempet foto-foto weekend kemaren cuman belum sempet upload karena kesibukan project yg gue harus handle di sini. Ini ada contoh foto Bratislava castle yg gue ambil secara acak dari Google.

Quote paling lucu dari Bratislava scene di Eurotrip:
“Ah! A nickel! You see this? I quit! I open my own hotel!”

Go Where There Is No Path

Terima kasih untuk semua yg datang di acara di ITB kemarin. Terima kasih atas antusiasme dan keingintahuannya. Terima kasih untuk semua pertanyaan dan komentar-komentar yg membuat gue semakin yakin dgn apa yg gue kerjakan.

Mungkin tugas gue untuk saat ini memang hanya meng-inspirasi. Mungkin apa yg bisa gue lakukan buat bangsa ini sekarang hanyalah memberikan informasi. Memberi semangat dan membagi cerita untuk orang lain, orang sekitar, termasuk para generasi muda. And somebody has to do it. Walau sangat tipis batas antara menceritakan kisah dan menjadi riya. There is a thin line between being opened and showing off. Namun selama masih ada orang yg bisa mengambil hikmah dari cerita-cerita gue, selama masih ada orang yg terinspirasi, gue memilih untuk meneruskan apa yg gue lakukan. Gue hanya bisa memohon ampun kepada Nya atas kesombongan yg mungkin muncul dalam melakukan itu semua.

Mohon maaf untuk semua kesalahan. Dan selamat menjalankan ibadah puasa buat semua yg memilih untuk mengerjakan.

- Do not follow where the path may lead. Go instead where there is no path and leave a trail. (Ralph Waldo Emerson)

A Life Changing Trip

Setiap orang yg sering melakukan traveling tentu mempunyai tempat-tempat favorit atau perjalanan yg paling berkesan. Kalo dulu, setiap kali ditanya orang tempat apa yg paling favorit mungkin gue akan menjawab nama-nama tempat di San Francisco, Amsterdam, Bangkok atau Sydney. Tapi sekarang kalo gue ditanya lagi, cuma ada satu tempat yg benar-benar berkesan. Bahkan gue merasa perjalanan yg terakhir minggu lalu itu merupakan a life changing trip.

Untuk menghindari riya maka kali ini gue tidak akan menulis secara detil ttg perjalanan terakhir gue. Selain itu juga banyak hal yg sangat menakjubkan, yg tidak bisa dijelaskan oleh kata-kata dan hanya bisa dirasakan sendiri. Yg jelas gue berharap semua orang yg satu keyakinan dgn gue akan dapat kesempatan untuk pergi ke tempat yg sangat special tsb suatu hari nanti. Insya Allah.