Wednesday, November 5, 2008

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.



No comments:

Post a Comment