ANALISIS KONSEP VIRTUALISASI P ADA CONTROLLER DALAM JARINGAN LAN BERBASIS OPENFLOW
TESIS
DANIEL HALOMOAN SARAGI NAPITU 117038026
PROGRAM STUDI S2 TEKNlK INFORMATIKA
FAKULTAS 1Ll\1U KOMPUTER DAN TEKNOLOGI INFORMASI UNIVERSITAS SUMATERA UTARA
MEDAN
2016
TESIS
Diajukan untuk melengkapi tugas dan memenuhi syarat memperoleh ijazah Magister Teknik Informatika
DANIEL HALOMOAN SARAGI NAPITU 117038026
PROGRAM STUDI S2 TEKNIK INFORMATIKA
FAKULTAS ILMU KOMPUTER DAN TEKNOLOGI INFORMASI UNIVERSITAS SUMATERA UTARA
MEDAN
2016
PERSETUJUAN
Judul : Analisis Konsep Virtualisasi pada Controller dalam Jaringan
Kategori Nama NIM
LAN berbasis Open.flow : Tesis
: Daniel Halomoan Saragi Napitu : 117038026
: Magister (S2) Teknik Infonnatika
~rogram Studi
Fakultas : ILMU KOMPUTER DAN TEKNOLOGI HWORMASJ
UNIVERSITAS SUMA.TERA UTARA
Komisi Pembimbing :
Pembimbing 2 Pembimbing 1
Prof Dr. l;,o,:ipl.M.ath.,
M.Si
Prof Dr. Muhammad ZarlisDiketahui/disetujui oleh
Program Studi S2 Teknik Infonnatika
.-K~f®L
.. ·:•
. :\ '-:•_. ,.>:: ,:, ' '' _,'. -j,1
\\~',,f.!~f;;~,-~:llqammad Zarlis
"~w :
tefs10101 198601 1 003AKADEMIS
Sebagai sivitas akademika Universitas Sumatera Utara, saya yang bertanda tangan di bawah ini:
Nama : Daniel Halomoan Saragi Napitu
NIM : 11703 8026
Program Studi : S2 Terknik Informatika J enis Kary a Ilmiah : T esis
Demi pengembangan ilmu pengetahuan, menyetujui untuk memberikan kepada Universitas Sumatera Utara Hak Bebas Royalti Non-Eksklusif (Non Exclusive Royalty Free Right) atas tesis saya yang berjudul :
ANALISIS KONSEP VIRTUALISASI PADA CONTROLLER DALAM JARINGAN LAN BERBASIS OPENFLOW
Beserta perangkat yang ada (iika diperlukan). Dengan Hak Bebas Royalti Non-Ek~klusif ini, Universitas Sumatera Utara berhak menyimpan, mengalih media, memformat, mengelola dalam bentuk database, merawat dan mempublikasikan tesis saya tanpa meminta izin dari saya selama tetap mencamtumkan nama saya sebagai penulis dan sebagai pemegang dan/atau sebagai pemilik hak cipta.
Demikian pernyataan ini dilJuat de11g~1_1 sebenarnya.
Medan, 26 Agustus 2016
~
Daniel Halomoan Saragi Napitu NIM : 117038026
RIWAYAT HIDUP
DATA PRIBADI
Nama Lengkap : Daniel Halomoan Saragi Napitu, ST, M.Kom Tempat dan Tanggal Lahir : Medan, 17 Juni 1984
Alamat Rumah : Jl. M. Nawi Harahap no. 107 Medan 20218
HP : 081957000069
e-mail : [email protected]
DATA PENDIDIKAN
SD : St. Yoseph Medan ri'imat : 1 996
SMP : St. Thomas 1 Medan Tamat: 1999
SMA : St. Thomas 1 Medan -Tamat: 2002
SI : Teknik Elektro Universitas Sumatera Utara Tamat: 2007 S2 : Teknik lnformatika Universitas Sumatera Utara Tamat: 2016
Pertama - tama saya ingin mengucapkan syukur kepada Tuhan yang Maha Esa atas berkat dan karunia yang terlah diberikan, sehingga tesis ini dapat diselesaikan. Dengan selesainya tesis ini, saya ingin mengucapkan terima kasih yang sebesar-besamya kepada:
Rektor Universitas Sumatera Utara, Prof. Dr. Runtung Sitepu, SH, M.Hum atas kesempatan yang diberikan kepada saya untuk mengikuti dan akhirnya menyelesaikan pendidikan Magister Teknik Informatika.
Dekan Fakultas Ilmu Komputer dan Teknologi Informasi Universitas Sumatera Utara Prof. Dr. Opim Salim Sitompul atas kesempatan yang telah diberikan kepada saya menjadi mahasiswa program Magister Teknik Informatika pada program Pascasarjana F ASILKOM-TI Universitas Sumatera Utara.
Ketua Program Studi Magister (S2) Teknik Informatika, Prof. Dr. Muhammaad Zarlis dan sekretaris Program Studi Magister (S2) Teknik Informatika M. Andri Budiman, S.T, M.Comp, M.E.M beserta seluruh staff pengajar pada Program Studi Magister (S2) Teknik Informatika Program Pascasarjana FASILKOM-TI Universitas Sumatera Utara.
Terima kasih yang setinggi - tingginya saya ucapkan kepada Prof Dr.
Muliammaad Zarlis, selaku pembimbing utama dan kepada Prof. Dr. Tulus, Vor.Dipl.Math., M.Si, selaku pembimbing anggota yang telah membimbing saya hingga selesainya tesis ini.
Terima kasih yang setinggi - tingginya saya ucapkan kepada Prof. Dr. Opim Salim Sitompul dan Dr. Ema Budhiarti Nababan, M.IT sebagai pembanding yang telah memberikan saran dan masukan demi semakin baiknya penyelesaian tesis ini.
Staff Pegawai dan Administrasi pada Program Studi Magister (S2) Teknik lnformatika Program Pascasaijana FASILKOM-TI Universitas Sumatera Utara yang membantu dan memberikan pelayanan yang baik selarna perkuliahan hingga selesainya tesis ini.
ii
Kepada kedua orangtua saya, Ir. Waldenhoff Saragi Napitu dan T.N.L Nainggolan, serta seluruh keluarga besar, terima kasih yang sebesar - besamya atas doa dan dukungannya untuk keberhasilan saya menyelesaikan pendidikan hingga saat ini.
Kepada sesama mahasiswa angkatan 2011 pada Program Magister Teknik Informatika, yang telah menjadi rekan belajar saya selama ini, atas dorongan semangat yang telah diberikan kepada saya untuk menyelesaikan pendidikan ini.
Kepada pihak lain yang tidak bisa saya ucapkan satu persatu, saya ucapkan terima kasih banyak atas dukungan yang telah kalian berikan kepada saya selama proses pendidikan saya.
Medan, 26 Agustus 2016
---
Daniel Halomoan Saragi Napitu NIM : 117038026
ABSTRAK
Software defined networking (SDN) merupakan pendekatan pada teknologi jaringan yang melakukan penyederhanaan terhadap kontrol dan manajemenjaringan. Salah satu realisasi dari SDN adalah pengembangan protokol Openflow, dimana prinsip utamanya adalah pemisahan fungsi control plane dari switching ASIC dengan memindahkannya ke perangkat controller, sehingga switching ASIC hanya menjalankan fungsi dari data plane. Pemisahan control plane dari data plane tidak berarti perangkat terse but terpisah secara operasional, karena switch tetap membutuhkan perintah dari controller dalam menjalankan fungsinya. Controller dapat membawahi banyak switch, dan komunikasi antara controller dan switch melalui control network. Selain munculnya celah keamanan, sifat dari controller tersebut membuat manajemen jaringan akan semakin sulit apabila sebuah switch berperan sebagi controller terhadap seluruh jaringan.
Melalui metode emulasi, dalam penelitian ini penulis melakukan analisis terhadap konsep virtualisasi yang diterapkan pada sebuah controller, dimana hasil yang diperoleh yaitu rancangan desain controller yang tepat untuk optimasj keamanar1 maupun manajemen jaringan LAN berbasis Openflow. Hasil yang diperoleh melalui penelitian dengan emulasi tersebut dapat dijadikan rujukan dalam penerapan jaringan Openjlow pada skenario jaringan di dunia nyata.
Kata Kunci : Openjlow, jaringan komputer, virtualisasi, SDN
iv
CONTROLLER VIRTUALIZATION CONCEPT ANALYSIS IN OPENFLOW BASED LOCAL AREA NETWORK
ABSTRACT
Software defined networking (SDN) is a concept in networking technology to simplify the management and control of the network. One of the implementation of the SDN concept is Openjlow protocol, which the main idea is to separate the function of control plane from the switching ASIC, by moving it to other device named controller. By doing the separation, the switch only has the data plane function. The se:19aration of control plane and data plane doesn't mean that the devices work individually as the switch still need instructions from the controller to operate. Controller could control one or many switches and thc:y communicate between a dedicated control network. Besides the appearance of security vulnerables, that controller's characteristic makes network
~
management more difficult to handle, especially if single controller used to handle all the network. Using emulation method, the author will analyze the vi1tualization concept in the controller. The result of this research to to find an approach in controller configuration to optimize network management and security in a Openflow based LAN.
The result of this emulated research could also be a reference in a real \Vorld network scenario.
Keywords : Open/low, computer network, virtuulization, SDN
Hal
UCAPAN TERIMA KASIH ... i
ABSTRAK ... iii
ABSTRACT ... .-... iv
DAFTAR ISi ... V DAFT AR T ABEL ... vii
DAFT AR GAMBAR .... ... viii
BAB I PENDAHULUAN ... 1
1.1 Latar belakang ... 1
1.2 Rumusan Masalah ... 3
1.3 Batasan Masalah ... 3
' 1.4 Tujuan Penelitian ... 3
BAB II LANDASAN TEORI ... 4
2.1 Software Defined Nenvorking ... 4
2.2 Protokol Openjlow ... ,. ... 4
2.2.1 Openjlow Controller ... ~ ... 6
2.2.2 Openj/tJ1v S1vitch ... 6
2.3 Fonvardir;g pada Jaringan Openjlow ... 7
BAB III METODOLOGI PENELITIAN ... 13
3 .1 Rancangan Penelitian ... 14
3 .2 Proses Penelitian ... 1 7 3.2.1 Emulasi jaringan dengan Mininet ... 17
3.2.2 Konfigurasi Open Ne!H'ork Operating S)•stem (ONOS) ... 18
3.2.3 Konfigurasi Linux Containers (LXC) ... 19
3.2.4 Konfigurasi Wireshark ... 20
3.2.5 Pengukuran Performa Jaringan ... 20
3 .2 Integrasi Komponen Penelitian ... 20
BAB IV HASIL PENELITIAN DAN PEMBAHASAN ... 25
4.1 Hasil Perhitungan Pada Penelitian ... 25
4.1.1 Hasil Perhitungan Latency ... 25
viii
DAFTARGAMBAR
Garn bar I. I. Controller sebagai pusat kontrol logika untuk switch. ... 2
Gambar 2.1. Protokol Openflow ... 5
Gambar 2.2. Multiple flow table ... 8
Gambar 2.3. Proses :Switching padajaringan tradisional.. ... 9
Gambar 2.4. Prinsipforwarding pada Openflow ... l I Garn bar 3 .1. Pembagian instansi pada controller ... .13
Garn bar 3 .2. Skenario topologi penelitian ... 15
Garn bar 3 .3. Flowchart proses penelitian ... 16
Gambar 3.4. Tampilan awal Mininet ... 17
Gambar 3.5. Tampilan CLI dari ONOS ... 19
Gambar 3.6. Tampilan Mininet untuk skenario penelitian ... 2I Gambar 3.7. Tampilan GUI pada ONOS untuk skenario penelitian ... 22
Gambar 3.8. Tampilan CLI pada ONOS terhadap skenario penelitian ... 23
Gambar 3.9. Tampilan konfigurasi LXC untuk peneli~ian ... 24
Gambar 4.1. Tampilan perangkat yang dilihat oleh instansi 2 ... 28
Garn bar 4.2. Paket Link Layer Discovery Protocol (LLDP) ... 29
Garn bar 4.3. Komunikasi packet-in danpacket-out pada instansi 2 ... 30
Gambar 4.4. Grafik pengukuran latency pada percobaan 1 ... 31
Gambar 4.5. Grafik pengnkuran latency pada percobaan 2 ... 32
Gambar 4.6. Grafik pengukurcm latency pada percobaan 3 ... 33
Gambar 4.7. Paket ARP pada awal komunikasijaringan data ... 34
Gambar 4.8. Grafik pengukuran throughput ... 35
Gambar 4.9. Delayterhadap TCP pada skenario 1 ... 36
Gambar 4.10. Delay terhaclap TCP pada instansi 3 dalarn skenario 3 ... 36
1.1 Latar belakang
Pada banyak protokol routing di jaringan tradisional, sebuah perangkat menerima informasi jaringan (misalnya topologi) dari perangkat yang bersebelahan atau tetangga dari perangkat terse but. Informasi tersebut kemudian akan diproses di dalam perangkat.
Sebaliknya, pada SDN, sistem kontroljaringan mirip dengan arsitektur sitem client dan server. Perangkatforwarding seperti switch memiliki keterbatasan dalam pengambilan keputusan dan harus rnengimplernentasikan perintah yang diberikan dari perangkat ekstemal yang dinamakan controller. Dengan kata lain, switch tidak lagi rnerniliki control plane lokal seperti jaringan pada umurnnya dan bergantung sepenuhnya pada controller dalam mengumpulkan informasi ke tabel flow. Kontrol logika dari pemrosesan paket dipindahkan ke sebuah perangkat controller tersebut. Perangkat controller ini dapat berfungsi membawahi satu maupun banyak switch, sehingga dapat dikatakan terpusat, seperti tergambar pada Gambar 1.1.
Controller Openflow
Gambai· 1.1. Controller sebagai pusat kontrol logika untuk s1vitch
2
Pentingnya peranan controller dalam jaringan Openflow membuat dibutuhkannya pertimbangan dalam implementasinya. Jalur penghubung controller dan switch dapat menggunakan TCP (plaintext) maupun dengan TLS. TLS merupakan pilihan terbaik untuk keamanan data yang dikirimkan. Berdasarkan penelitian pada tahun 2013 oleh Benton, Camp dan Small, banyak celah keamanan dalam jalur terse but apabila tidak dilakukan perlindungan, khususnya apabila controller tersebut terhubung dengan banyak switch. Namun, mereka juga meneliti bahwa menerapkan TLS merupakari hal kompleks dan rumit sehingga operator cenderung tidak menerapkannya.
Hal kompleks tersebut berupa membuat site-wide certificate, membuat controller certificate, membuat switch certificate, melakukan signing terhadap certificate dengan site-wide private key, lalu menerapkan kunci dan certificate pada seluruh perangkat (Benton, et al. 2013). Berdasarkan ini, penulis ingin menerapkan virtualisasi terhadap controller, sehingga sebuah controller tidak menjadi pusat untuk seluruh swith. Seperti konsep VLAN pada jaringan tradisional, konsep tersebut dapat meningkatkan keamanan maupun manajemanjaringan. Namun dalamjaringan Openflow, perlu dilihat faktor delay karena sebelum meneruskan paket dalam jaringan, sebuah switch OpeY/flow perlu berkomu11ikasi dengan controller yang menjadi pusatnya. Salah satu penelitian yang membahas ini yaitu penelitian oleh Heller, Sherwood dan McKeown pada tahun 2012. Penelitian tersebut dilakukan pada implementasi jaringan lnternet2 dengan berbagai titik controller yang berada pada kota - kota berbeda dengan trafik data yang bervariasi. Pada penelitian tersebut dijelaskan bahwa penempatan satu unit controller cenderung tidak cukup dan berdasarkan basil studi kasus tersebut dikatakan nilai latency dapat dikurangi dengan penambahan jumlah controller. Penelitian lain dilakukan oleh Turrul, Hi dell dan Sjodin pada tahun 2014 yaitu dengan melakukan virtualisasi many to one dimana beberapa controller dengan vendor berbeda-beda divi1iualisasikan seolah olah menjadi satu controller melalui sebuah proxy, lalu dilakukan uji performajaringan melalui paket TCP, UDP dan ICMP. Penelitian tersebut menunjukkan performa yang berbeda dikarenakan karakter controller yang berbeda.
Berdasarkan penelitian-penelitian tersebut penulis akan melakukan analisis pada jaringan terhadap konsep vi1iualiasasi pada controller tersebut.
1.2 Rumusan Masalah
Berdasarkan latar belakang, rumusan masalah yang dianalisis dalam penelitian yang dilakukan oleh penulis adalah menemukan metode untuk meningkatkan keamanan serta manajemen padajaringan berbasis Openjlow.
1.3 Batasan Masalah
Dalam penelitian ini, penulis membatasi hal -hal sebagai berikut :
1. Membatasi penilaian performa jaringan data dengan mengukur latency (melalui paket ICMP) dan throughput (melalui paket TCP).
2. Membatasi penelitian dengan menggunakan satujenis controller yaitu Open Network Operating System (ONOS) dengan virtualiasi maksimal sebanyak tiga bagian dengan metode LXC serta topologi emulasi jaringan LAN.
1.4 Tujuan Penelitian
Berdasarkan masalah yang dirumuskan pada rumusan masalah, maka penelitian ini bertujuan untuk menemukan metode yang dapat m,:•iingkatkan keamanan serta manajemen pada jaringan berbasis Openjlow.
BAB II
LANDASAN TEORI
2.1 Software Defined Networking
Software Defined Networking (SDN) adalah pendekatan model untuk pengaturan jaringan, yang didasari prinsip bahwa alur trafik dari jaringan dirancang untuk dapat diprogram sehingga memungkinkan terciptanya model - model baru dalam pengaturan trafik jaringan. Pemisahan dari control plane dan data plane merupakan ide utama dari prinsip kerja SDN. Contoh fungsi dan penerapan dari control plane dan data plane pada jaringan tradisional dapat dilihat pada Tabel 2.1.
Tabel 2.1. Fungsi control plane dan data plane (Marschke, et al. 2015)
Control Plane Data Plane
Data konfigurasi Forwarding Information Base (FIB) Protokol Routing Unicast Access Lists
Protokol Routing Multicast Quality of Service (QoS) Routing Information Base (RIB) Interface
2.2 Protokol Openjlow
Protokol Ope11flow merupakan implementasi dari konsep SDN. Openjlow merupakan standarisasi yang mendefenisikan antamrnka sistem komunikasi antara control plane dan fonvardingldata plane pada arsitektur SDN. Fokus dari rancangan ini awalnya adalah untuk membuat protokol eksperimen pada jaringan antar gedung yang bisa digunakan dalam penelitian. Rancangan protokol ini kemudian dilihat memiliki potensi untuk menggantikan fungsi protokol layer 2 maupun layer 3 yang selama ini terintegrasi pada perangkat-perangkat switch maupun router komersial. Model dari protokol
Open.flow dapat dilihat pada Gambar 2.1. Model terse but juga menjelaskan pemahaman umum dari SDN, yaitu sebagai berikut:
Pemisahan control plane dan data plane
Menggunakan protokol yang terstandarisasi, yaitu protokol Open.flow, untuk menghubungkan controller (yang menjalankan fungsi control plane) dan elemenjaringan lainnya, seperti Open.flow switch untuk menjalankan fungsi forwarding.
Menjalankan fungsi pemrograman jaringan melalui API yang terpusat .
...
Control Plane pada Swl!ch
Gambar 2.1. Protokol Openjlow (Nadeau & Grey, 2013)
Ope11flow terdiri dari sekelompok protokol dan sebuah APL Dengan kata lain.
controller tidak dapat melakukan apapun tanpa adanya program aplikasi yang memberikan instruksi ke arah rnana paket data akan mengal ir dan ke perangkat mana.
Secara sederhana, Openflmv controller dapat digambarkan sebagai sistem operasi pada komputer, sementara Ope11flow switch sebagai perangkat keras dari komputer.
6
2.2.1 Openflow Controller
Dalam jaringan Openflow, fungsi control plane dilakukan pada controller dan data plane dilakukan pada switch. Sebuah channel komunikasi digunakan sebagai penghubung kedua plane tersebut. Dengan protokol Openjlow, controller dapat rnenarnbah, rnernperbaharui rnaupun rnenghapus daftar flow (Hu, 2014). Beberapajenis dari controller adalah NOX, POX, Ryu, Floodlight dan Opendaylight.
Openflow channel rnerupakan istilah yang digunakan terhadap ses1 koneksi antara Openflow controller dan Openflow switch yang diinisiasi oleh Openflow switch. Koneksi tersebut rnenggunakan protokol TCP ,rnisalnya telnet dan untuk lebih arnan (dengan enkripsi) rnenggunakan TLS. Dengan demikian, controller dan Openflow switch dapat terhubung rnelalui jaringan berbasis TCP/IP Uaringan tradisional) sehingga yang dibutuhkan agar channel ini dapat bekerja adalah koneksi yang bersifat routed connectivity. Hal tersebut rnembuat controller tidak perlu terkoneksi langsung secara fisik narnun dapat juga berada '
pada lokasi remote Uarakjauh). Openflow channel juga disebut sebagai control network, yaitu jaringan yang khusus untuk kornunikasi sistem/pengaturan kontrol antara controller dan switch. Sernentara untuk komunikasi data antara switch maupun host disebut data network.
2.2.2 Openjlow Switch
Openflo-w switch bisa dikatakan sama dengan switch jaringan biasa, tetapi tanpa/tidak memiliki protokol pintar yang terintegrasi di dalamnya. Open.flow switch akan rnenjalankan perangkat lunak yang berfungsi menghubungkannya ke controller untuk rnenganalisa dan mengatur alur paket data. Secara spesifik, komponen dari Ope11flow switch terbagi atas 2 bagian, yaitu :
Switch Agent
S\vitch Agent yaitu komponen dari swi1ch yang berbicara kepacla controller dengan protokol Ope11flow. Switch agent berkomunikasi dengan data plane dengan protokol internal. Demikian juga ketika menenrna notifikasi dari data plane, switch agent akan
menerjemahkan dengan protokol Openflow, lalu akan dikirimkan ke controller
Data Plane
Data plane akan melakukan proses forwarding dan manipulasi dari paket data. Apabila diperlukan, data plane akan mengirimkan paket data ke switch agent untuk mengetahui tir,dakan yang perlu dilakukan terhadap paket tersebut. Komponen data plane dari switch yaitu port, flow table, flow, classifier dan instruksi yang perlu dilakukan. Paket tiba dan keluar melalui port. Paket kemudian diklasifikasikan termasukflow yang mana, berdasarkanflow table.
Proses klasifikasi ini dilakukan oleh classifier. Parameter instruksi lalu menentukan apa yang hams dilakukan terhadap paket yang tiba tersebut, berdasarkan hasil klasifikasi sebelumnya (Flowgrammable, 2016)
Ada beberapajenis perangkat lunak Openflow switch, antara lain Open vSwitch, Indigo dan LINC.
2.3 Forwarding pada Jaringan Openflow
Open.flow switch melakukan proses forwarding berdasarkan informasi yang ada pada tabel.f/ow. Informasi pada tabeljlow diperoleh dari instruksi yang diberikan controller.
Tabel flow berisi parameter MAC address, IP address, nomor port dan parameter lainnya yang dapat dikonfigurasi sesuai kebutuhan. Berdasarkan infonnasi dalam tabel flow, instruksi terhadap paket data yang datang dapat diatur, misalnya berupa forwarding ke port tertentu, dilakukan drop paket dan apabila parameter untuk paket tersebut tidak ditemukan pada tabel//ow, dapat dikirim ke controller untuk ditanyakan mengenai instruksi yang perlu dilakukan.
Penggunaan tabel fl011· dalam Openflov1· mengalarni perkembangan. Pada protokol Open/low versi 1.0 hanya 1 tabeljlmv yang didukung. tetapi dimulai versi 1.1 dan seterusnya, sebuah Ope,?flmv switch dapat mendukung lebih dari satu tabel _flmv.
Misalnya dengan Open vSwitch, dapat menggunakan 254 tabel flow. Tujuan didukungnya beberapa tabel flmv dalam switch adalah optimisasi jaringan data, misalnya apabila terdapat terlalu banyak informasi flow data yang tersimpan dalam
8
sebuah tabel flow. Dengan menggunakan banyak tabel, sebuah data dapat diproses langsung ke tabel yang berisi informasi forwarding dari paket terse but, sehingga tidak perlu mencari dari keseluruhan data flow seperti apabila han_ya menggunankan satu tabel flow (Open Networking Foundation, 2014). Penulis mengilustrasikan konsep multiple flow table ini pada Gambar 2.2. Dapat dilihat proses paket data yang diterima dapat
dilakukan drop, pencocokakn terhadap tabelflow lain atau ditanyakan ke controller.
}91J68.0.l I
1~¢
191.168.l.l I 1~
¢
' 171.16.l.l I 16
¢
10.o.o.11s
¢
I
TAB[l.iJ
P.illT DI DROP
IP ADDRISS C'\STRl"KSI 192.168.0.0 '1~ DROP 191.16S.I.0 •:~
1~1.16.1.0 16 PORD 10.0.0.0 S lu T.\B[L J
IP ADDRISS C-STRll(SI
Gambar 2.2. Multiple.flow table.
IP .IDDRISS l:\STRll(Sl
10.0.0.0 '8 PORT!
Menurut prinsip ke1janya, proses forwarding dalam Openflow switch dibagi tiga, yaitu :
Reactive Fonvarding.
Ketika sebuah paket data atau flow dalam jaringan Openflow diterima sebuah Ope11fl01r s1vitch, s1vitch agent di dalam s1ritch tersebut rnelakukan pencarian dalam tabelflow. Jika tidak ditemukan pasa1~gan instruksi untuk flow tersebut, switch akan membuat paket bemamapockt't-in clan dikirimkan ke controller. Fungsinya adalah untuk menanyakan instruksi yang perlu dilakukan terhadap paket(flow data yang barn saja diterima. Dari infonnasi
packet-in yang diterima, controller juga secara dinamis dapat mempelajari perangkat yang berada dalam topologi jaringan.
Proactive Forwarding.
Berbeda dengan reactive forwarding, proactive forwarding tidak bereaksi terhadap jenis paketiflow data baru yang ham diterimanya. Switch telah menerima informasi flow dari controller mengenai seluruh flow/paket data yang kemungkinan akan diterima switch tersebut. Dengan begitu, sebelum menerima sebuah flow/paket baru, switch telah mengetahui instruksi yang perlu dilakukannya terhadap jenis flow tersebut. Hal tersebut membuat komunikasi dengan controller, misalnya packet-in tidak perlu diinisiasi, sehingga akan mengurangi latency. Prinsip ini mirip dengan routing table pada router, dimana seluruh alamat trafik telah tersimpan sebelum paket dari trafik tertentu diterima (Nadeau & Grey, 2013).
Proses awal dari switching tradisional dimulai ketika sebuahframe data diterima oleh switch. Kemudian algoritma pencarian data MAC address pun dimulai oleh switch itu sendiri. Proses tersebut dapat dilihat pada penjelasan berikutnys.
II) ) 1,2,i )
■
{, 15 I■
Tabel :\UC Address T abel :\UC Addi·es s
Kompu1~r .-\
Kornputer .\ Port l Kompllier . .\ Pon lKomputc-r B
Komputer B Port ::: Kompu'.er B ?on ~Gambar 2.3. Proses switching padajaringan tradisional
Pada Gambar 2.3. dapat dilihat prinsip .,wi1ching pacla jaringan tradisional, dengan penjelasan sebagai berikut :
1. Komputer A hendak mengirirnkan data ke komputer B. Diterima switch X padaport 1.
2. Karena switch X tidak mengetahui arah tujuan data tersebut, sehingga dikirirnkan ke seluruh port kecuali port asalnya, yaitu port 2. Switch X
10
kemudian meny1mpan informasi bahwa MAC address komputer A terhubung ke port 1 pada tabel CAM. Data yg dikirimkan diterima switch Y padaport 1.
3. Switch Y tidak mengetahui arah tujuan data tersebut, sehingga dikirimkan ke seluruh port kecuali port asalnya, yaitu port 2. Switch Y kemudian menyimpan informasi bahwa MAC address komputer A terhubung ke port 1 pada tabel CAM. Data yang dikirimkan diterima komputer B.
4. Komputer B menjawab data yg dikirimkan. Data tersebut diterima switch Y pada port 2. Switch Y kemudian menyimpan informasi bahwa MAC address komputer B terhubung ke port 2.
5. Berdasarkan informasi sebelumnya, diketahui bahwa tujuan data adalah komputer A, sehingga switch Y mengirimkan data tersebut melalui port 1 ke switch X.
6. Berdasarkan informasi pada tabel CAM, switch X mengetahui bahwa tujuan data adalah komputer A, sehingga switch X mengirimkan data tersebut melalui port 1 ke komputer A.
Berdasarkan penjelasan diatas maka dapat dilihat bahwa setiap switch membuat keputusan secara lokal, setiap switch memiliki otaknya masing-masing dan pembaharuan tabel CAM dilakukan secara individu.
Sementara disisi lain, protokol Open.flow menerapkan algoritma y:mg berbeda untuk skenario jaringan sederhana yang sama. Dengan reactivefhrwarding, untukjenis paket barn yang barn diterima, prosesnya akan dijelaskan berikutnya.
(2) (4 (7)
• (1) ) (3)
·---(-9)-- • (8) ) •
--(6) (5) _ _ ➔ ~
Komputer A Tabe!Flow Tabel Flow KomputerB
Tiook dikctatm Controller Tiook dikctatut Controller KO!llDuterA Port I KOr.1PuterA ?ort I KomputerB Port.2 Kol'.lputerB ?ort.2
Gambar 2.4. Prinsip forwarding pada Openjlow
Pada Gambar 2.4. dapat dilihat proses dalamjaringan Ope1'iflow, yaitu:
1. Komputer A mengirimkan data dengan tujuan komputer B.
2. Prinsip kerja switch pada Openjlow dalam reactive forwarding yaitu ketika menerima paket data yang tidak diketahui tujuannya, akan dikirimkan pesan ke Ope11flow controller untuk menanyakan instruksi berikutnya yaitu melalui pesan packet-in. Pada switch X, ketika mengirimkan pesan ke controller, controller juga tidak mengetahui arah tujuan pengirirnan data, sehingga mengirimkan pesan ke switch untuk melakukan broadcast. Pesan ini dinamakan packet-out. Disaat yang bersamaan controller mempelajari bahwa komputer A terhubung pada port 1 di switch X. Informasi terse but disimpan oleh controller.
3. Switch X kemudian broadcast ke port lain, yaitu port 2.
4. Switch Y tidak mengetahui arah tujuan paket, sehingga mengirimkan Packet-in ke controller. Controller rnengirimkan packet-out berisi instruksi untuk rnelakukan broadcast.
5. Switch Y mengirimkan broadcast. Kornputer B menenma paket yang dikirimkan.
6. Komputer B menjawab paket tersebut lalu dikirimkan ke switch Y.
12
7. Switch Y tidak mengetahui kemana tujuannya sehingga mengirimkan pesan Packet-in ke controller. Ketika menenma pesan tersebut, controller mempelajari bahwa komputer B terhubung pada port 2 di switch B.
Digabung dengan informasi sebelumnya, controller melakukan update pada tabeljlow di seluruh switch mengenai informasi yang dimilikinya, sehingga switch Y mengetahui arah pengiriman, yaitu ke switch X.
8. Paket tidak dilakukan broadcast, tetapi dikirimkan ke switch X sesuai informasi terbaru pada tabeljlow yang diterima dari controller.
9. Switch X kemudian mengirimkan paket ke komputer A. Untuk pengiriman berikutnya dari komputer Ake B ataupun sebaliknya, switch X dan Y tidak lagi menanyakan instruksi ke controller, dikarenakan sudah memiliki informasi pada tabelflow masing-masing. Paket langsung dikirimkan sesuai informasi dari tabeljlow.
Dari proses tersebut, dapat dilihat bahwa controller mempelajari bagaimana switch terhubung dan informasi pada controller dibagikan ke tabel flow pada switch, sehingga pengiriman data yang sama pada giliran berikutnya tidak perlu melih.tkan controller lagi.
Melalui penjelasan prinsip kerja switching tradisional dan reactive forwarding pada protokol Openflow pada skenario yang sama, dapat dilihat perbedaan algoritma dalam proses pengaluran data. Dalam pencarian proses instruksi terhadap sebuah paket data baru yang barn diterima. reactive forwarding cenderung menimbulkan latency dikarenakan membutuhkan komunikasi dengan perangkat eksternal.
METODOLOGI PENELITIAN
Dalam penelitian ini penulis akan melakukan penelitian terhadap hasil virtualisasi pada sebuah controller. Melalui virtualisasi, sebuah controller dibagi menjadi beberapa instansi controller dan berada dalam perangkat yang sama. Dengan konsep ini, setiap switch hanya berkomunikasi dengan controller yang menjadi master baginya. Hal ini dapat dilihat pada Garn bar 3 .1.
Instansi 2
Garn bar 3 .1. Pembagian instansi pada controller
Penelitian akan dilakukan dengan dua komponen perangkat lunak yaitu Min incl (untuk emulasi jaringan Openflow) dan menggunakan controller Open Net .. rork Opemting System (ONOS) yang diinstalasi ke dalam sistem operasi Linux Ubuntu Server 14.04 LTS 64 bit. Controller ONOS yang telah terinstalasi
14
dihubungkan dengan skenario topologi/sistem jaringan yang telah diemulasi dengan Mininet.
3.1 Rancangan Penelitian
Adapun rancangan yang akan dilakukan untuk dapat melakukan penelitian adalah sebagai berikut:
1. Perancangan topologi dan emulasi dengan konfigurasi Mininet.
2. Instalasi ONOS pada sistem operasi server.
3. Konfigurasi container dengan Linux Containers (LXC) 4. Konfigurasi ONOS terhadap tiap container yang terbentuk.
Dalam penelitian ini, penulis akan menggunakan 3 topologi masing-masing menggunakan satu, dua dan tiga instansi controller dalam sebuah controller. Skenario ini dapat dilihat pada Gambar 3.2.
SKENARIOl
. / ' / I " ' " ' -
_.,,..,,,,,---....
. / / I , , . . . . _ _ _ . , , . / I \ ' - . . . _
. / / I \ " - ~
- - - ~ · - _j
_.,,, / I \ "-. -...._
. / / I \ "- -...._
. / / I \ '- ..._
@lht-HlilliHiikii-Miliiki\UNii IUild
~
.~
Host 1 Host 2
SKENARI02
,~ONrll~LL~I
1
n
2 1171'< ?K:
/ I '-._ . / I --..._
/ I ' - " ' I --..._
/ I / ' - . _ I ....,.._
. / I / "-1 "-
/ ./1 ,... ...
/ . / I I..._,_ ..._,_
. / / I I "- ,
m1,1H11#ul , 1 Ml1.uafiP-lltA
Host 1 Host 2
SKENARI03
D-0~
7 \ 7\..1
/",,I
/
'
/ ··, .. / .A..
/ '\.
/
,,
/
'
. /
'
. / /
'
.J{Hf f;,.HNili;iHi31 iiiiitilii:14AHiliJi-lii1Ji=H
•✓
Host 1~
Host 2Gambar 3.2. Skenario topologi penelitian
16
Dari ketiga skenario tersebut, akan diukur nilai throughput dan latency antar host yang didapat. Nilai throughput akan dilihat dan dibandingkan dengan keadaan tanpa pembagian instansi. Dari rencana penelitian ini, akan dilihat efektifitas dan pengaruh dari pembagian fungsi kontrol pada controller. Flowchart dari proses penelitian dapat dilihat pada Gambar 3.3.
!
YAHul"""°"'
d4g,n
conttolla3.1~ t'i.ui~ ;i :onncil..•1 ckn?~~1 LX( L.
- - ~ '
TIDAK
Ht1h.mgk111 :DF cc~m·,-.11..-r deng;1n ,\\'lh:l! m.,:u:g•m~,:mg ---T-
.:r. l
r · -~~~;\ -·
l1
Gambar 3.3. Flowchart proses penelitian
3.2 Proses Penelitian
3.2.1 Emulasi jaringan dengan Mininet
Mininet merupakan perangkan lunak yang dapat membangun emulasi sebuah jaringan Openjlow, dimana Mininet mendukung Openjlow versi 1.0, namun dapat dirancang untuk dapat menjalankan perangkat lunak switch yang menggunakan versi yang terbaru (Azodolmolky, 2013). Dalam sebuah mesin tunggal baik perangkat keras komputer, virtual maupun melalui media cloud, Mininet dapat membangun sebuah jaringan dengan komponen virtual seperti switch, controller maupun link yang menghubungkan. Jaringan yang dibentuk oleh Mininet menjalankan code yang sesungguhnya, termasuk aplikasi jaringan Unix/Linux yang sesungguhnya termasuk kernel yang sesungguhnya juga.
Dengan demikian, jaringan maupun code yang dikembangkan dan diuji pada Mininet untuk controller Openjlow, swith maupun host dapat dipindahkan ke sistem yang sesungguhnya dengan perubahan yang minimal, untuk uji coba pada sistem yang sesungguhnya, evaluasi performa, maupun pengembangan dan penelitian (Mininet Overview, 2016).
Tampilan awal dari Mininet ;lapat dilihat pada Gambar 3.4. Apabila tidak dilakukan perintah untuk topologi yang dikembangkan, Mininet akanjalan dengan topologi awal yang terdiri dari sebuah swith (sl), dua buah host (h1 dan h2) dan sebuah controller ( c0), dimana controller akan mengguDakan alamat 127.0.0.1 sebagai identitasnya. Pada tampilan te1sebut akan terlihat juga link yang diemulasi untuk menghubungkan host dan svvitch dalam jaringan.
root@daniel-thesis:/# sudo mn
--• Creating network
a A & Adding controller
••· Adding hosts:
hl h2
••· Adding switches:
sl
•·• Adding links:
(hl, sl) (h2, sl)
••· Configuring hosts hl h2
Starting controller c0
•·• Starting 1 switches sl ...
••• Starting CLI:
mininet>
Gambar 3.4. Tampilan awal A1ininet
18
Sesuai skenario pada Garn bar 3 .1, Mininet akan digunakan untuk membangun topologi jaringan. Adapun informasi mengenai parameter perangkat yang akan dilakukan emulasi dalam Mininet dapat dilihat pada Tabel 3 .1.
Tabel 3.1. Tabel informasi perangkatjaringan
Nama Jenis Alamat
co Controller (instansi 1) 10.0.3.11 cl Controller (instansi 2) 10.0.3.12 c2 Controller (instansi 3) 10.0.3.13
s1 Switch I 00:00:00:00:00:01
-
s2 Switch 2 00:00:00:00:00:02
s3 Switch 3 00:00:00:00:00:03
s4 Switch 4 00:00:00:00:00:04
s5 Switch 5 00:00:00:00:00:05
s6 Switch 6 00:00:00:00:00:06
h1 Host I 10.0.0.1 - -
h6 Host 6 10.0.0.6
3.2.2 Konfigurasi Open Network Operating System (ONOS)
ONOS merupakan sistem operasi jaringan SDN bersifat open source yang pertama. Fokus untuk ONOS adalahjaringan service provider dan ONOS telah dilengkapi fasilitas untuk mempermudah melakukan kontrol terhadap seluruh perangkat yang mendukung protokol Ope,ilow (The Open Networking Lab, 2014 ). Spesifikasi perangkat keras minimum yang diperlukan untuk rnenjalankan ONOS untuk diinstalasi dalam sebuah virtual machine adalah :
Ubuntu Server 14.04 LTS 64-bit 2 GB RAM atau lebih
2 atau lebih processor
Untuk membangun dan menjalankan ONOS diperlukan : Java 8 SDK
Apache Maven 3.3.9
Git Bash
Apache Karaf3.0.5
Tampilan CLI dari ONOS setelah instalasi berhasil, dapat dilihat pada Gambar 3.5.
Welcome to Open Network Operating System (ONOS)!
! ; I I -' \ I \}
/ / ; / / / / /\
Hit '<tab>' for a list of available commands and '[cmd) --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown ONOS.
Gambar 3.5. Tampilan CLI dari ONOS
3.2.3 Konfigurasi Linux Containers (LXC)
Linux Containers (LXC) rnerupakan teknologi vi1iualisasi ringan. Berbeda dengan vi1iualisasi penuh seperti Qemu ataupun Vi\1ware, container tidak rnengernulasikan perangkat keras dan setiap container yang dibentuk berbagi sistern operasi yang sama sebagai host (Ubuntu Documentation, 2015). Hal ini dapat rnenghernat surnberdaya seperti CPU, m2mory dan lain-lain. Dalan, penelitian ini penulis akan rnelakukan pembagian instansi pada controller ONOS dengan melalui konfigurasi pada LXC dengan menggunakan sumberdaya pada sebuah sener dengan sistem operasi Ubuntu Server.
Setiap container membutuhkan alamat IP agar dapat terdeteksi dan terhubung dalam jaringan. Linux bridges digunakan untuk menghubungkan container yang dibentuk. Pada LXC, bridges yang digunakan dinamai lxcbr0.
Setiap container akan menggunakan virtual Ethernet bridge inte1:face (veth) yang akan terhubung rnelalui bridge. Konfigurasi LXC akan dilakukan dalam penelitian ini untuk rnelakukan virtualisasi pada sebuah controller, sehingga
20
terlihat seperti tiga unit controller, dimana ketiganya terhubung melalui sebuah bridge.
3.2.4 Konfigurasi Wireshark
Wires hark merupakan perangkat lunak open source yang dapat menangkap dan melakukan decode terhadap paket data dalam jaringan. Proses decode menggunakan dissector yang dapat mengidentifikasi dan menampilkan nilai dari paket data dalamjaringan (Chappel, 2013). Untuk instalasi perangkat lunak ini, dilakukan terhadap sistem operasi utama.
3.2.5 Pengukuran Performa Jaringan
Pengukuran performa jaringan dilakukan dengan dua cara, yaitu pengukuran throughput dan latency, dimana throughput merupakan jumlah bit yang dapat dikirimkan dalam jaringan pada periode waktu tertentu dan latency merupakan lama waktu yang dibutuhkan sebuah pesan data untuk dikirim dari satu titik awal ke titik akhir. Pengukuran latency diutamakan untuk pengiriman data dari titik awal ke titika akhir, lalu kembali lagi. Pro.;;es ini dinamakan round-trip time atau RTT ( Peterson & Davie, 2003). Pada penelitian ini, penulis rnengukur throughput dengan menggunakan aplikasi iper.f Ipe,f merupakan· perangkat lunak open source yang dapat melakukan pePgukuran parameter jaringan menggunakan komunikasi data bidirectional maupun unidirectional melalui paket Transmission Control Protocol (TCP) maupun User Datagram Protocol (UDP) dalam prosesriya (Duarte & Pujolle, 2013). Untuk pengukuran latency.
penulis menggunakan protokol ICMP.
3.2 lntegrasi Komponen Penelitian
Tampilan hasil dari konfigurasi Mininef dan integrasinya terhadap controller dapat dilihat pada CLI dari Mininet di Gambar 3.6. Dapat dilihat pada skenario pertama seluruh switch terhubung pada sebuah controller yaitu c 1. Pada skenario kedua ada 2 controller yaitu c 1 dan c2, dan pada skenario ketiga terdapat tiga controller yaitu cl, c2 dan c3. Pada tampilan tersebut terlihat terhubungnyajaringan denganjumlah controller sesuai skenario penelitian.
root@daniel-thesis:/home/# sudo python skenario-satu.py
*** Configuring hosts hl h2 h3 h4 h5 h6
*** Starting controller Cl
*** Starting 6 switches sl s2 s3 s4 s5 s6
*** Starting CLI:
mininet>
root@daniel-thesis:/home/# sudo python skenario-dua.py
*** Configuring hosts hl h2 h3 h4 h5 h6
*•* Starting controller Cl c2
*** Starting 6 switches sl s2 s3 s4 s5 s6
*** Starting CLI:
mininet>
root@daniel-thesis:/home/# sudo python skenario-tiga.py
*** Configuring hosts hl h2 h3 h4 h5 h6
~•• Starting controller cl c2 c3
••• Starting 6 switches sl s2 s3 s4 sS s6
**• Starting CLI:
mininet>
Gambar 3.6. Tampilan lhninet untuk skenario penelitim---:.
ONOS dilengkapi dengan GUI untuk melihat tampilan topologi yang dibentuk.
Gambar hasil konfigurasi jaringan terhadap tiga skenario peneliti2.n dapat dilihat pada Gambar 3.7 dan Gambar 3.8. Dapat dilihat pada GUI, setiap pasangan controller dan switch digambarkan dengan warna yang sama. Pada CLI, terlihat pasangan dari switch dengan controller yang menjadi master terhadapnya.
_J.
10.0.3,11I I 1 1..::
Q rr; • • ' ':._ J
•
_J
10.0.3.11)I) /J '11
Q # Sv', ,lc,1, ::, 1
•
_j
'1.0.0.~.12 10 0 3 12# Sw1tcl1es. J
... J
~ OpenNetwork Operating System_ ) 10.0.3.ll.· . 10.0.J.IJ
J;!_ # Switch<>,;:· 2
.. ..
. .·
J
l.0.0.3.12 1/J.0.3.12"' sw;iches, 2
• • 'l' •
SKENARI01
•
SKENARI02
SKENAR103.
Gambar 3.7. Tampilan GUI pada ONOS untuk skenario penelitian
22
SKENARIO 1
011,:is> roles
of:8888888888888881: master=l8.8.3.ll, standbys=[
J
of:8888888888888882: master=l8.8.3.ll, standbys=[
J
of:8888888888888883: master=l8.8.3.ll, standbys=[]
of:8088888888888884: master=l8.8.3.ll, standbys=[ ] of:8808888888888885: master=18.8.3.11, standbys=[]
of:8888888888888886: master=18.8.3.ll, standbys=[ ]
SKENARI02
,~,:1'.:,::.. roles
of:8888888988888881:
of:8989988899988882:
of:8988898889888883:
of:9889888898888884:
of:8888888888888885:
of:8888888888808886:
·:,<, 0 > roles
master=l8.8.3.ll, master=l8.8.3.12, master=l8.8.3.ll, master=l0.8.3.12, master=l0.0.3.ll, master=l0.8.3.12,
SKENARI03
standbys=[
standbys=[
standbys=[
standbys=[
standbys=[
standbys=[
of:8808000808000801: master=l0.0.3.li, standbys=[ } of:0000080080000002: master=l0.0.3.12, standbys=[ ] of:eee0000ee0000003: master=l0.0.3.13, standbys=[ ] of:0000800000000004: master=l0.0.3.ll, standbys=[ ] of:0000000000000005: master=l0.0.3.12, st3ndbys=[ ] of:0000000000000006: master=l0.0.3.13, standbys=[ ]
Gambar 3.8. Tampilan CLI pada ONOS terhadap skenario penelitian
Pada penelitian ini, penulis menamai container yang dibentuk pada LXC dengan nama instansi-satu, instansi-dua dan instansi-tiga. Untuk veth pada tiap container penulis menamainya veth-satu, veth-dua dan veth-tiga. Hasil konfigurasi terse but dapat dilihat pada Gambar 3. 9. Tiap container diberi alamat IP sesuai alamat pada tiap controller.
root@daniel-thesis:/# sudo lxc-ls --fancy
NAME STATE IPV4 IPV6 GROUPS AUTOSTART instansi-dua RUNNING 18.8.3.12 -
instansi-satu
RUNNING18.8.3.11 -
instansi-tiga RUNNING 18.8.3.13 -root@daniel-thesis:/#
root@daniel-thesis:/#
root@daniel-thesis:/#
root@daniel-thesis:/# brctl show bridge name bridge id
lxcbre 8888.fel624bc7bl8
root@daniel-thesis:/#
YES YES YES
STP
enabled no
interfaces veth-dua veth-satu veth-tiga
Gambar 3.9. Tampilan konfigurasi LXC untuk penelitian
24
4.1 Hasil Perhitungan Pada Penelitian 4.1.1 Hasil Perhitungan Latency
Pengukuran latency dilakukan terhadap host 1 dan host 6 dengan pengirirnan paket ICMP. Untuk tiap skenario penelitian, dilakukan tiga kali percobaan, dimana setiap percobaan dilakukan pengirirnan paket ICMP sebanyak 20 sequencelurutan. Basil pengukuran dapat dilihat pada Tabel 4.1, Tabel 4.2, dan Tabel 4.3. Satuan latency adalah milliseconds (ms).
Tabel 4.1. Nilai latency pada penilitian untuk skenario 1
Urutan Skenario 1
Percobaan 1 Percobaan 2 Percobaan 3
1 57.2 105 62.5
2 1.26 - C.67
3 0.004 iJ. l ,9 0.103
1 - - - - -
4 0.!J94 0.101
5 0.174 0 162
6 0.138 0.26
7 0.085 \..!. ' i _) I ; · ' ) 0.115
8 0.075 (,. ! 76 0.17
9 0.149 0.181
10 0. 1:2 ; J_ _- 0.08
11 0. i 59 0.U7
12 0.118 O. l
13
14 ., '. __ l
15
16 0.14
17 0.101 , ! ·; in~-/ ~~ 0.183
18 0.115 0.1.52 0.178
26
0.1371
0.156
0.1551
0.174
0.1071
0.167
Tabel 4.2. Nilai latency pada penilitian untuk skenario 2
Urutan Skenario 2
Percobaan 1 Percobaan 2 Percobaan 3
1 91 118 94. l
2 2.06 0.698 2.36
3 0.124 0.192 0.142
4 0.128 0.22 0.178
5 0.129 0.137 0.086
6 0.147 0.17 0.219
7 0.204 0.16 0.178
8 0.211 0.214 0.107
9 0.138 0.127 0.135
- · -
10 0.164 0.151
.
0.06811 0.135 0.098 0.1 l
12 0.142 0.159 0.262
13 0.06 0.109
r
0.08814 0.135 0.123 0.142
15 0.146 0.138 0.11 S
.
16 0.146 0.139 0.113
17 0.075 0.14~ 0.098
18 0.008 0.136 0.1
19 0.125 0.151 O. l
20 0.06() 0.; c~6 0.066
Tabel 4.3. Nilai latency pada penilitian untuk skenario 3
Urutan Skenario 3
Percobaan 1 Percobaan 2 Percobaan 3
1 11 i ,; 1 ()f'l l l J
2 l .98 I <c>8 :2.--H
,., 0 ; -~ (~ { \ < -; 0.149
.) \;
4 0. 091 0 l :?9 0.088
5 0.103 0.096 0.14
6 0.064
o.on
0.0897 0.098 0.137 0.231
8 0.092 0.067 0.07
9 0.065 0.068 0.074
10 0.073 0.079 0.107
11 0.074 0.073 0.088
12 0.074 0.127 0.162
13 0.071 0.146 0.065
14 0.06 0.141 0.089
15 0.084 0.091 0.085
16 0.076 0.113 0.088
17 0.082 0.08 0.126
18 0.081 0.064 0.089
19 0.097 0.119 0.085
20 0.129 0.102 0.081
4.1.2 Hasil Perhitungan Throughput
Pengukuran throughput dilakukan dengan aplikas_i ipe1:f dengan mengirimkan paket TCP antara host 1 dan host 6. Pengiriman iperf dilakukan sebanyak 10 kali. Hasil pengukuran terlihat pada Tabel 4.4, dimana satuan dari throughput dalam Gigabit tiap detik (Gbit/s).
Tabel 4.4. Nilai throughput pada tiap skenario penelitian Percobaan Skenario 1 Skcnario 2 Skenario 3
1
.
17.7 18.4 19.52 18.9 18.7 20.9
,., 19.8 17.8 18.4
.)
· -
4 21.5 18.3 20
5 19.6 18.8 18.2
6 18.4 18.9 19.7
7 18.7 19.8 20.1
8 19.4 19.8 19.8
9 20.7 22.1 19.4
10 19.8 20.5 18.5
28
4.2 Analisis Basil Penelitian
4.2.1 Analisis Basil Virtualisasi terhadap Container
Dilihat dari output CLI pada ONOS, identitas setiap switch yang berada pada emulasi jaringan ketika berkomunikasi dengan controller dalam control network menggunakan alamat IP dari lxcbr0 namun dengan port komunikasi yang berbeda-beda. Nomor port ini diberi secara acak. Untuk analisis, penulis mengunakan instansi 2 pada skenario peneli tian 3. Pada gambar terse but tampak perangkat padajaringan yang dilihat oleh instansi 2 dari controller.
devices
id=of:8888888888888881, available=true, role=NONE, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.l.3, serial=None, protocol=OF_ 18, channelld=18.8.3.l:47793
id=of:8888888988888882, available=true, role=MASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitc h, sw=2 .1. 3, serial=None, protoco l=OF 18, channelld=18. 0. 3 .1: 36234
id=of:8888888889888883, available=true, role=NONE, type=SWITCH, mfr=N1cira, Inc., hw=Open vswitch, sw=2.1.3, serial=None, protocol=OF 18, channelid=lS.8.3.1:60998
id=of:8888888888888884, available=true, role=NONE, type=SWITCH, mfr=Nicira, Inc., hw=Open vswitch, sw=2.l.3, serial=None, protocol=OF 10, channelid=l8.8.3.l:47882
id=of:0888888888888885, available=true, role=MASTER, type~SWITCH, mfr=Nicira, Inc., hw-=Open vswitcl h, sw=2.1.3, serial=None, protocol=OF 18, channelld=lS.8.3.1:36243
i
id=of:0880088880888886, available=true, role=NONE, type=SWITCH, mfr=Nicira, Inc., hw=Open vswitch,;
sw=2.l.3, serial_=None, protocol=OF_18, channelld=l0 8.3.1:61008 ·
Gambar 4.1. Tampilan perangkat yang dilihat oleh instansi 2
Pada Gambar 4.1 juga dapat dilihat bahwa instansi 2 menjadi controller untuk switch 2 dan 5 (sesuai dengan skenario 3) dimana switch 2 terhubung dengan controller melalui port 36234 dan switch 5 melalui port 36243. Sebuah controller dalam jaringan Openjlow mengirimkan paket broadcast secara periodik untuk mendeteksi topologi jaringan. Dalam hal ini, controller menggunakan Link Layer Discovery Pro10col atau LLDP (Hu, 2014).
Berdasarkan pengamatan penulis, controller ONOS yang digunakan dalam penelitian menggunakan alamat de:ad:be:ef:ba: 11 untuk pengiriman paket LLDP. Pada Gambar 4.2 dapat dilihat controller hanya mengirimkan pakett LLDP ke switch yang dikontrolnya.
!No, I !
Tore Soi.rce Destination
73 0.493915 de:ad:be:ef:ba:11 75 0.494057 de:ad:be:ef :ba:11 77 0.494195 de:ad:be:ef:ba:11 78 0.494299 de:ad:be:ef:ba:11 0.567185 de: ad:be:ef :ba:11 de:ad:be:ef:ba:11
105 0.568654 de :ad:be:ef :ba:11 117 0.619454 de:ad:be:ef :ba:11 118 0.619723 de:ad:be:ef :ba:11 120 0.620365 de:ad:be:ef:ba:11 121 0.621333 de: ad: be: ef :ba: 11 140 0, 766659 de:ad:be:ef :ba:11
- - - - · -----~--··--·-·----
. ------- --- ----
NidraNe _ 00: 00: 01 Broadcast tliciraNe _ 00: 00: 01 Broadcast NidraHe_00:00:01 Broadcast NiciraNe_00:00:01 Brea cast tliciraNe _ 00: 00: 01 Broadcast fliciratle _ 00: 00: 01 tlidratle_00:00:01 Broadcast Broadcast tlidraNe~~:00:01
Protocol OpenFlow OpenFlow OpenFlow OpenFlO'II OpenFlow
enF ow OpenFlo-11 OpenFlow OpenFlow OpenFlow OpenFlow OpenFlow
Type
.. _ OpenFlow ____ _
11:
Port Asal OFPT _PACKET_ IN 36243 OFPT_PACKET_IN 36243 OFPT _PACKET_ IN 36234 Of PT _PACKET_ IN 36234 OFPT _PACKET_ OUT 6633 OFPT PACKET OUT 6633
OFPT_PAC OFPT_PACKET_OUT 6633 OFPT _PACKET_ OUT 6633 OFPT _PACKET_ IN 36234 OFPT_PACKET_IN 36243 OFPT _PACKET_ IN 36234 OFPT_PACKET_IN 36243 Of PT _PACKET_ OUT 6633
PortTujuan 6633 6633 6633 6633 36234 36234 36234 3 36234 36234 6633 6633 6633 6633 36243
• Ethernet II, Src: de:ad:be:ef:ba:11 (de:ad:be:ef:ba:11), Os':: lliciratle_00:00:01 (01:23:20:00:00:01\
Destination: Nidcafle _00:00:01 (01:23:20:00:00:01) Source: de:ad:be:ef:ba:11 (de:ad:be:ef:ba:11) Type: 802.1 Link Layer Discovery Protocol (LLDP) (0x88cc)
· ~ink Layer Dhcovery Protocol
Gambar 4.2. Paket Link Layer Discovery Protocol (LLDP) '
Untuk melihat alur paket komunikasi controller dan switch, dijalankan paket ICMP antara host l dc1n host 6 (yang melewati switch yang dikontrol controller yang berbeda). Pada gambar 4.3, dapat dilihat bahwa instansi 2 hanya menerima packet-in dan packet-out dari switch yang menjadi bawahmmya yaitu switch 2 dan 5.
