ANALISIS KONSEP VIRTUALISASI PADA CONTROLLER DALAM JARINGAN LAN BERBASIS OPENFLOW TESIS DANIEL HALOMOAN SARAGI NAPITU

(1)

TESIS

DANIEL HALOMOAN SARAGI NAPITU 117038026

PROGRAM STUDI S2 TEKNIK INFORMATIKA FAKULTAS ILMU KOMPUTER DAN TEKNOLOGI INFORMASI

UNIVERSITAS SUMATERA UTARA

MEDAN

2016

(2)

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

(3)

Judul : Analisis Konsep Virtualisasi pada Controller dalam Jaringan LAN berbasis Openflow

Kategori : Tesis

Nama : Daniel Halomoan Saragi Napitu

NIM : 117038026

Program Studi : S2 Teknik Informatika

Fakultas : ILMU KOMPUTER DAN TEKNOLOGI INFORMASI UNIVERSITAS SUMATERA UTARA

Komisis Pembimbing :

Pembimbing 2 Pembimbing 1

Prof. Dr. Tulus, Vor.Dipl.Math., M.Si Prof. Dr. Muhammad Zarlis

Diketahui/disetujui oleh S2 Teknik Informatika Ketua,

Prof. Dr. Muhammad Zarlis NIP : 19570701 198601 1 003

(4)

ANALISIS KONSEP VIRTUALISASI PADA CONTROLLER DALAM JARINGAN LAN BERBASIS OPENFLOW

TESIS

Saya mengakui bahwa tesis ini adalah hasil karya sendiri, kecuali beberapa kutipan dan ringkasan yang masing-masing telah disebutkan sumbernya.

Medan, 26 Agustus 2016

Daniel Halomoan Saragi Napitu NIM : 117038026

(5)

AKADEMIS

Sebagai sivitas akademika Universitas Sumatera Utara, saya yang bertanda tangan di bawah ini :

Nama : Daniel Halomoan Saragi Napitu

NIM : 117038026

Program Studi : S2 Terknik Informatika Jenis Karya Ilmiah : Tesis

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 (jika diperlukan). Dengan Hak Bebas Royalti Non- Eksklusif 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 dibuat dengan sebenarnya.

(6)

PANITIA PENGUJI TESIS

Ketua : Prof. Dr. Muhammad Zarlis

Anggota : 1. Prof. Dr. Tulus, Vor.Dipl.Math., M.Si 2. Prof. Dr. Opim Salim Sitompul 3. Dr. Erna Budhiarti Nababan, M.IT

(7)

DATA PRIBADI

Nama Lengkap : Daniel Halomoan Saragi Napitu, ST, M.Kom Tempat dan Tanggal Lahir : Medan, 17 Juni 1984

HP : 081957000069

e-mail : [email protected]

DATA PENDIDIKAN

SD : St. Yoseph Medan Tamat :1996

SMP : St. Thomas 1 Medan Tamat : 1999

SMA : St. Thomas 1 Medan Tamat : 2002

S1 : Teknik Elektro Universitas Sumatera Utara Tamat : 2007 S2 : Teknik Informatika Universitas Sumatera Utara Tamat : 2016

(8)

UCAPAN TERIMA KASIH

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-besarnya 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 FASILKOM-TI Universitas Sumatera Utara.

Ketua Program Studi Magister (S2) Teknik Informatika, Prof. Dr. Muhammad 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.

Muhammaad 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. Erna 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 Informatika Program Pascasarjana FASILKOM-TI Universitas Sumatera Utara yang membantu dan memberikan pelayanan yang baik selama perkuliahan hingga selesainya tesis ini.

(9)

Kepada kedua orangtua saya, Ir. Waldenhoff Saragi Napitu dan T.N.L Nainggolan, serta seluruh keluarga besar, terima kasih yang sebesar – besarnya 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.

(10)

ABSTRAK

Software defined networking (SDN) merupakan pendekatan pada teknologi jaringan yang melakukan penyederhanaan terhadap kontrol dan manajemen jaringan. 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 tersebut 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 optimasi keamanan maupun manajemen jaringan LAN berbasis Openflow. Hasil yang diperoleh melalui penelitian dengan emulasi tersebut dapat dijadikan rujukan dalam penerapan jaringan Openflow pada skenario jaringan di dunia nyata.

Kata Kunci : Openflow, jaringan komputer, virtualisasi, SDN

(11)

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 Openflow 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 separation 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 they 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 virtualization 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 world network scenario.

Keywords : Openflow, computer network, virtualization, SDN

(12)

DAFTAR ISI

Hal

UCAPAN TERIMA KASIH ... i

ABSTRAK ... iii

ABSTRACT ... iv

DAFTAR ISI ... v

DAFTAR TABEL ... vii

DAFTAR 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 Networking ... 4

2.2 Protokol Openflow ... 4

2.2.1 Openflow Controller ... 6

2.2.2 Openflow Switch ... 6

2.3 Forwarding pada Jaringan Openflow ... 7

BAB III METODOLOGI PENELITIAN ... 13

3.1 Rancangan Penelitian ... 14

3.2 Proses Penelitian ... 17

3.2.1 Emulasi jaringan dengan Mininet ... 17

3.2.2 Konfigurasi Open Network Operating System (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

(13)

4.1.2 Hasil Perhitungan Throughput ... 27

4.2 Analisis Hasil Penelitian ... 28

4.2.1 Analisis Hasil Virtualisasi terhadap Container ... 28

4.2.2 Analisis Terhadap Jaringan Data ... 30

BAB V KESIMPULAN DAN SARAN ... 38

5.1 Kesimpulan ... 38

5.2 Saran ... 38

DAFTAR PUSTAKA ... 40

LAMPIRAN .. ... 42

(14)

DAFTAR TABEL

Tabel 2.1. Fungsi control plane dan data plane...4

Tabel 3.1. Tabel informasi perangkat jaringan...18

Tabel 4.1. Nilai latency pada penelitian untuk skenario 1...25

Tabel 4.4. Nilai throughput pada tiap skenario penelitian...27

(15)

DAFTAR GAMBAR

Gambar 1.1. 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 pada jaringan tradisional...9

Gambar 2.4. Prinsip forwarding pada Openflow...11

Gambar 3.1. Pembagian instansi pada controller...13

Gambar 3.2. Skenario topologi penelitian ...15

Gambar 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...21

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 penelitian...24

Gambar 4.1. Tampilan perangkat yang dilihat oleh instansi 2...28

Gambar 4.2. Paket Link Layer Discovery Protocol (LLDP)...29

Gambar 4.3. Komunikasi packet-in dan packet-out pada instansi 2...30

Gambar 4.4. Grafik pengukuran latency pada percobaan 1...31

Gambar 4.7. Paket ARP pada awal komunikasi jaringan data...34

Gambar 4.8. Grafik pengukuran throughput...35

Gambar 4.9. Delay terhadap TCP pada skenario 1...36

Gambar 4.10. Delay terhadap TCP pada instansi 3 dalam skenario 3...36

(16)

ABSTRAK

Software defined networking (SDN) merupakan pendekatan pada teknologi jaringan yang melakukan penyederhanaan terhadap kontrol dan manajemen jaringan. 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 tersebut 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 optimasi keamanan maupun manajemen jaringan LAN berbasis Openflow. Hasil yang diperoleh melalui penelitian dengan emulasi tersebut dapat dijadikan rujukan dalam penerapan jaringan Openflow pada skenario jaringan di dunia nyata.

Kata Kunci : Openflow, jaringan komputer, virtualisasi, SDN

(17)

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 Openflow 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 separation 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 they 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 virtualization 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 world network scenario.

Keywords : Openflow, computer network, virtualization, SDN

(18)

BAB I PENDAHULUAN

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 tersebut. Informasi tersebut kemudian akan diproses di dalam perangkat.

Sebaliknya, pada SDN, sistem kontrol jaringan mirip dengan arsitektur sitem client dan server. Perangkat forwarding seperti switch memiliki keterbatasan dalam pengambilan keputusan dan harus mengimplementasikan perintah yang diberikan dari perangkat eksternal yang dinamakan controller. Dengan kata lain, switch tidak lagi memiliki control plane lokal seperti jaringan pada umumnya 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.

Gambar 1.1. Controller sebagai pusat kontrol logika untuk switch

(19)

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 tersebut apabila tidak dilakukan perlindungan, khususnya apabila controller tersebut terhubung dengan banyak switch. Namun, mereka juga meneliti bahwa menerapkan TLS merupakan 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 manajeman jaringan. Namun dalam jaringan Openflow, perlu dilihat faktor delay karena sebelum meneruskan paket dalam jaringan, sebuah switch Openflow perlu berkomunikasi 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 Internet2 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 hasil studi kasus tersebut dikatakan nilai latency dapat dikurangi dengan penambahan jumlah controller. Penelitian lain dilakukan oleh Turrul, Hidell dan Sjödin pada tahun 2014 yaitu dengan melakukan virtualisasi many to one dimana beberapa controller dengan vendor berbeda-beda divirtualisasikan seolah olah menjadi satu controller melalui sebuah proxy, lalu dilakukan uji performa jaringan 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 virtualiasasi pada controller tersebut.

(20)

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 pada jaringan berbasis Openflow.

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 satu jenis 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 meningkatkan keamanan serta manajemen pada jaringan berbasis Openflow.

(21)

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

Protokol Routing Unicast Protokol Routing Multicast Routing Information Base (RIB)

Forwarding Information Base (FIB) Access Lists

Quality of Service (QoS) Interface

2.2 Protokol Openflow

Protokol Openflow merupakan implementasi dari konsep SDN. Openflow merupakan standarisasi yang mendefenisikan antarmuka sistem komunikasi antara control plane dan forwarding/data 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

(22)

Openflow dapat dilihat pada Gambar 2.1. Model tersebut juga menjelaskan pemahaman umum dari SDN, yaitu sebagai berikut :

- Pemisahan control plane dan data plane

- Menggunakan protokol yang terstandarisasi, yaitu protokol Openflow, untuk menghubungkan controller (yang menjalankan fungsi control plane) dan elemen jaringan lainnya, seperti Openflow switch untuk menjalankan fungsi forwarding.

- Menjalankan fungsi pemrograman jaringan melalui API yang terpusat.

Gambar 2.1. Protokol Openflow (Nadeau & Grey, 2013)

Openflow terdiri dari sekelompok protokol dan sebuah API. Dengan kata lain, controller tidak dapat melakukan apapun tanpa adanya program aplikasi yang memberikan instruksi ke arah mana paket data akan mengalir dan ke perangkat mana.

Secara sederhana, Openflow controller dapat digambarkan sebagai sistem operasi pada komputer, sementara Openflow switch sebagai perangkat keras dari komputer.

(23)

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 Openflow, controller dapat menambah, memperbaharui maupun menghapus daftar flow (Hu, 2014). Beberapa jenis dari controller adalah NOX, POX, Ryu, Floodlight dan Opendaylight.

Openflow channel merupakan istilah yang digunakan terhadap sesi koneksi antara Openflow controller dan Openflow switch yang diinisiasi oleh Openflow switch. Koneksi tersebut menggunakan protokol TCP ,misalnya telnet dan untuk lebih aman (dengan enkripsi) menggunakan TLS. Dengan demikian, controller dan Openflow switch dapat terhubung melalui jaringan berbasis TCP/IP (jaringan tradisional) sehingga yang dibutuhkan agar channel ini dapat bekerja adalah koneksi yang bersifat routed connectivity. Hal tersebut membuat controller tidak perlu terkoneksi langsung secara fisik namun dapat juga berada pada lokasi remote (jarak jauh). Openflow channel juga disebut sebagai control network, yaitu jaringan yang khusus untuk komunikasi sistem/pengaturan kontrol antara controller dan switch. Sementara untuk komunikasi data antara switch maupun host disebut data network.

2.2.2 Openflow Switch

Openflow switch bisa dikatakan sama dengan switch jaringan biasa, tetapi tanpa/tidak memiliki protokol pintar yang terintegrasi di dalamnya. Openflow switch akan menjalankan perangkat lunak yang berfungsi menghubungkannya ke controller untuk menganalisa dan mengatur alur paket data. Secara spesifik, komponen dari Openflow switch terbagi atas 2 bagian, yaitu :

- Switch Agent

Switch Agent yaitu komponen dari switch yang berbicara kepada controller dengan protokol Openflow. Switch agent berkomunikasi dengan data plane dengan protokol internal. Demikian juga ketika menerima notifikasi dari data plane, switch agent akan

(24)

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 tindakan 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 termasuk flow yang mana, berdasarkan flow table.

Proses klasifikasi ini dilakukan oleh classifier. Parameter instruksi lalu menentukan apa yang harus dilakukan terhadap paket yang tiba tersebut, berdasarkan hasil klasifikasi sebelumnya (Flowgrammable, 2016)

Ada beberapa jenis perangkat lunak Openflow switch, antara lain Open vSwitch, Indigo dan LINC.

2.3 Forwarding pada Jaringan Openflow

Openflow switch melakukan proses forwarding berdasarkan informasi yang ada pada tabel flow. Informasi pada tabel flow 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 informasi 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 flow, dapat dikirim ke controller untuk ditanyakan mengenai instruksi yang perlu dilakukan.

Penggunaan tabel flow dalam Openflow mengalami perkembangan. Pada protokol Openflow versi 1.0 hanya 1 tabel flow yang didukung, tetapi dimulai versi 1.1 dan seterusnya, sebuah Openflow switch dapat mendukung lebih dari satu tabel flow.

Misalnya dengan Open vSwitch, dapat menggunakan 254 tabel flow. Tujuan didukungnya beberapa tabel flow dalam switch adalah optimisasi jaringan data, misalnya apabila terdapat terlalu banyak informasi flow data yang tersimpan dalam

(25)

sebuah tabel flow. Dengan menggunakan banyak tabel, sebuah data dapat diproses langsung ke tabel yang berisi informasi forwarding dari paket tersebut, sehingga tidak perlu mencari dari keseluruhan data flow seperti apabila hanya 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 tabel flow lain atau ditanyakan ke controller.

Gambar 2.2. Multiple flow table.

Menurut prinsip kerjanya, proses forwarding dalam Openflow switch dibagi tiga, yaitu :

- Reactive Forwarding.

Ketika sebuah paket data atau flow dalam jaringan Openflow diterima sebuah Openflow switch, switch agent di dalam switch tersebut melakukan pencarian dalam tabel flow. Jika tidak ditemukan pasangan instruksi untuk flow tersebut, switch akan membuat paket bernama packet-in dan dikirimkan ke controller. Fungsinya adalah untuk menanyakan instruksi yang perlu

(26)

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 paket/flow data baru yang baru 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 sebuah frame data diterima oleh switch. Kemudian algoritma pencarian data MAC address pun dimulai oleh switch itu sendiri. Proses tersebut dapat dilihat pada penjelasan berikutnya.

Gambar 2.3. Proses switching pada jaringan tradisional

Pada Gambar 2.3. dapat dilihat prinsip switching pada jaringan tradisional, dengan penjelasan sebagai berikut :

1. Komputer A hendak mengirimkan data ke komputer B. Diterima switch X pada port 1.

2. Karena switch X tidak mengetahui arah tujuan data tersebut, sehingga dikirimkan ke seluruh port kecuali port asalnya, yaitu port 2. Switch X

(27)

kemudian menyimpan informasi bahwa MAC address komputer A terhubung ke port 1 pada tabel CAM. Data yg dikirimkan diterima switch Y pada port 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 Openflow menerapkan algoritma yang berbeda untuk skenario jaringan sederhana yang sama. Dengan reactive forwarding, untuk jenis paket baru yang baru diterima, prosesnya akan dijelaskan berikutnya.

(28)

Gambar 2.4. Prinsip forwarding pada Openflow

Pada Gambar 2.4. dapat dilihat proses dalam jaringan Openflow, yaitu : 1. Komputer A mengirimkan data dengan tujuan komputer B.

2. Prinsip kerja switch pada Openflow dalam reactive forwarding yaitu ketika menerima paket data yang tidak diketahui tujuannya, akan dikirimkan pesan ke Openflow controller untuk menanyakan instruksi berikutnya yaitu melalui pesan packet-in. Pada switch X, ketika mengirimkan pesan ke controller, controller juga tidak mengetahui arah tujuan pengiriman 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 tersebut 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 mengirimkan packet-out berisi instruksi untuk melakukan broadcast.

5. Switch Y mengirimkan broadcast. Komputer B menerima paket yang dikirimkan.

6. Komputer B menjawab paket tersebut lalu dikirimkan ke switch Y.

(29)

7. Switch Y tidak mengetahui kemana tujuannya sehingga mengirimkan pesan Packet-in ke controller. Ketika menerima pesan tersebut, controller mempelajari bahwa komputer B terhubung pada port 2 di switch B.

Digabung dengan informasi sebelumnya, controller melakukan update pada tabel flow 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 tabel flow yang diterima dari controller.

9. Switch X kemudian mengirimkan paket ke komputer A. Untuk pengiriman berikutnya dari komputer A ke B ataupun sebaliknya, switch X dan Y tidak lagi menanyakan instruksi ke controller, dikarenakan sudah memiliki informasi pada tabel flow masing-masing. Paket langsung dikirimkan sesuai informasi dari tabel flow.

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 melibatkan 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 baru diterima, reactive forwarding cenderung menimbulkan latency dikarenakan membutuhkan komunikasi dengan perangkat eksternal.

(30)

BAB III

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 Gambar 3.1.

Gambar 3.1. Pembagian instansi pada controller

Penelitian akan dilakukan dengan dua komponen perangkat lunak yaitu Mininet (untuk emulasi jaringan Openflow) dan menggunakan controller Open Network Operating System (ONOS) yang diinstalasi ke dalam sistem operasi Linux Ubuntu Server 14.04 LTS 64 bit. Controller ONOS yang telah terinstalasi

(31)

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.

(32)

Gambar 3.2. Skenario topologi penelitian

(33)

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.

(34)

3.2 Proses Penelitian

3.2.1 Emulasi jaringan dengan Mininet

Mininet merupakan perangkan lunak yang dapat membangun emulasi sebuah jaringan Openflow, dimana Mininet mendukung Openflow 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 Openflow, 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 dapat dilihat pada Gambar 3.4. Apabila tidak dilakukan perintah untuk topologi yang dikembangkan, Mininet akan jalan dengan topologi awal yang terdiri dari sebuah swith (s1), dua buah host (h1 dan h2) dan sebuah controller (c0), dimana controller akan menggunakan alamat 127.0.0.1 sebagai identitasnya. Pada tampilan tersebut akan terlihat juga link yang diemulasi untuk menghubungkan host dan switch dalam jaringan.

Gambar 3.4. Tampilan awal Mininet

(35)

Sesuai skenario pada Gambar 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 perangkat jaringan

Nama Jenis Alamat

c0 Controller (instansi 1) 10.0.3.11 c1 Controller (instansi 2) 10.0.3.12 c2 Controller (instansi 3) 10.0.3.13

s1 Switch 1 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 1 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 adalah jaringan service provider dan ONOS telah dilengkapi fasilitas untuk mempermudah melakukan kontrol terhadap seluruh perangkat yang mendukung protokol Openflow (The Open Networking Lab, 2014). Spesifikasi perangkat keras minimum yang diperlukan untuk menjalankan 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

(36)

- Git - Bash

- Apache Karaf 3.0.5

Tampilan CLI dari ONOS setelah instalasi berhasil, dapat dilihat pada Gambar 3.5.

Gambar 3.5. Tampilan CLI dari ONOS

3.2.3 Konfigurasi Linux Containers (LXC)

Linux Containers (LXC) merupakan teknologi virtualisasi ringan. Berbeda dengan virtualisasi penuh seperti Qemu ataupun VMware, container tidak mengemulasikan perangkat keras dan setiap container yang dibentuk berbagi sistem operasi yang sama sebagai host (Ubuntu Documentation, 2015). Hal ini dapat menghemat sumberdaya seperti CPU, memory dan lain-lain. Dalam penelitian ini penulis akan melakukan pembagian instansi pada controller ONOS dengan melalui konfigurasi pada LXC dengan menggunakan sumberdaya pada sebuah server 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 interface (veth) yang akan terhubung melalui bridge. Konfigurasi LXC akan dilakukan dalam penelitian ini untuk melakukan virtualisasi pada sebuah controller, sehingga

(37)

terlihat seperti tiga unit controller, dimana ketiganya terhubung melalui sebuah bridge.

3.2.4 Konfigurasi Wireshark

Wireshark 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 dalam jaringan (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. Proses ini dinamakan round-trip time atau RTT ( Peterson & Davie, 2003). Pada penelitian ini, penulis mengukur throughput dengan menggunakan aplikasi iperf. Iperf merupakan perangkat lunak open source yang dapat melakukan pengukuran parameter jaringan menggunakan komunikasi data bidirectional maupun unidirectional melalui paket Transmission Control Protocol (TCP) maupun User Datagram Protocol (UDP) dalam prosesnya (Duarte & Pujolle, 2013). Untuk pengukuran latency, penulis menggunakan protokol ICMP.

3.2 Integrasi Komponen Penelitian

Tampilan hasil dari konfigurasi Mininet 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 c1. Pada skenario kedua ada 2 controller yaitu c1 dan c2, dan pada skenario ketiga terdapat tiga controller yaitu c1, c2 dan c3. Pada tampilan tersebut terlihat terhubungnya jaringan dengan jumlah controller

(38)

Gambar 3.6. Tampilan Mininet untuk skenario penelitian

ONOS dilengkapi dengan GUI untuk melihat tampilan topologi yang dibentuk.

Gambar hasil konfigurasi jaringan terhadap tiga skenario penelitian 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.

(39)

Gambar 3.7. Tampilan GUI pada ONOS untuk skenario penelitian

(40)

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 tersebut dapat dilihat pada Gambar 3.9. Tiap container diberi alamat IP sesuai alamat pada tiap controller.

(41)

Gambar 3.9. Tampilan konfigurasi LXC untuk penelitian

(42)

BAB IV

HASIL PENELITIAN DAN PEMBAHASAN

4.1 Hasil Perhitungan Pada Penelitian 4.1.1 Hasil Perhitungan Latency

Pengukuran latency dilakukan terhadap host 1 dan host 6 dengan pengiriman paket ICMP. Untuk tiap skenario penelitian, dilakukan tiga kali percobaan, dimana setiap percobaan dilakukan pengiriman paket ICMP sebanyak 20 sequence/urutan. Hasil 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 0.67 2.31

3 0.094 0.139 0.103

4 0.094 0.153 0.101

5 0.174 0.131 0.162

6 0.138 0.164 0.26

7 0.085 0.173 0.115

8 0.075 0.176 0.17

9 0.149 0.165 0.181

10 0.12 0.145 0.08

11 0.159 0.152 0.137

12 0.118 0.135 0.176

13 0.095 0.158 0.088

14 0.089 0.175 0.121

15 0.156 0.335 0.23

16 0.157 0.171 0.14

17 0.101 0.162 0.183

18 0.115 0.152 0.178

(43)

19 0.137 0.155 0.107

20 0.156 0.174 0.167

1 91 118 94.1

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.068

11 0.135 0.098 0.11

12 0.142 0.159 0.262

13 0.06 0.109 0.088

14 0.135 0.123 0.142

15 0.146 0.138 0.118

16 0.146 0.139 0.113

17 0.075 0.144 0.098

18 0.068 0.136 0.1

19 0.125 0.151 0.1

20 0.069 0.146 0.066

1 105 100 113

2 1.98 1.98 2.44

3 0.136 0.124 0.149

4 0.091 0.129 0.088

5 0.103 0.096 0.14

(44)

7 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 aplikasi iperf 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 Skenario 2 Skenario 3

1 17.7 18.4 19.5

2 18.9 18.7 20.9

3 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

(45)

4.2 Analisis Hasil Penelitian

4.2.1 Analisis Hasil 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 penelitian 3. Pada gambar tersebut tampak perangkat pada jaringan yang dilihat oleh instansi 2 dari controller.

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 Openflow mengirimkan paket broadcast secara periodik untuk mendeteksi topologi jaringan. Dalam hal ini, controller menggunakan Link Layer Discovery Protocol 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.

(46)

Gambar 4.2. Paket Link Layer Discovery Protocol (LLDP)

Untuk melihat alur paket komunikasi controller dan switch, dijalankan paket ICMP antara host 1 dan 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 bawahannya yaitu switch 2 dan 5.

(47)

Gambar 4.3. Komunikasi packet-in dan packet-out pada instansi 2

Paket packet-in dan packet-out yang diterima oleh instansi 2 berupa pertanyaan dari switch mengenai proses yang perlu dilakukan seputar paket ICMP yang diterima. Pada Gambar 4.3 tersebut juga tampak jenis paket ICMP tersebut, dimana Type 8 adalah echo request dan 0 adalah echo reply. Dari pengiriman paket ICMP tersebut, dapat dilihat bahwa switch 2 dan 5 berkomunikasi dengan instansi ke 2 dari controller, sehingga virtualisasi dan pemisahan kontrol dapat dikatakan telah berhasil.

4.2.2 Analisis Terhadap Jaringan Data

Berdasarkan hasil pengukuran pada Tabel 4.1, Tabel 4.2 dan Tabel 4.3, dapat dilihat bahwa nilai latency tertinggi terletak pada 2 sequence pertama. Grafik yang menunjukkan hasil pengukuran latency tersebut dapat dilihat pada Gambar 4.4, Gambar 4.5 dan Gambar 4.6.

(48)

Gambar 4.4. Grafik perhitungan latency pada percobaan 1

(49)

(50)

Berdasarkan grafik pada Gambar 4.4, Gambar 4.5, dan Gambar 4.6 dapat dilihat bahwa latency komunikasi pada jaringan data tidak berbeda jauh. Skenario satu digambarkan dengan warna biru, skenario dua warna merah, dan skenario tiga dengan warna hijau. Adapun latency tertinggi terjadi pada awal komunikasi.

(51)

Selain karena delay untuk packet-in dan packet-out yang dijelaskan pada sub bab 4.2.1, paket baru yang terlihat pada Wireshark adalah Address Resoulution Protocol (ARP), dimana host 1 mengirimkan paket broadcast ARP untuk mencari host 6. Dapat dilihat pada Gambar 4.7, yang merupakan daftar paket ARP yang muncul dan ditangkap pada lxcbr0 sejak paket ICMP dijalankan.

Gambar 4.7. Paket ARP pada awal komunikasi jaringan data

Untuk nilai latency terhadap sequence ICMP setelah proses ARP, pada tiap skenario memiliki nilai dibawah 1 ms. Sepanjang pengetahuan penulis, belum ada standarisasi kelayakan nilai latency pada jaringan LAN. Nilai latency terbaik yang diharapkan tentunya adalah 0 ms. Namun hal tersebut tidak memungkinkan dikarenakan ada faktor sumber datangnya latency, mulai dari delay propagasi sinyal, delay antarmuka jaringan untuk serialisasi, delay pemrosesan jaringan, delay di dalam perangkat dan delay antrian (Kay, 2016).

Melihat faktor tersebut dan membandingkan latency pada skenario penelitian mendekati 0 ms, maka penulis melihat trafik cukup baik dan normal.

Grafik pengukuran throughput dapat dilihat pada Gambar 4.8.

Percobaan pengukuran throughput dilakukan sebanyak 10 kali terhadap ketiga skenario penelitian.

(52)

Gambar 4.8. Grafik pengukuran throughput

Pada gambar tersebut dapat dilihat throughput yang diperoleh dari ketiga skenario bervariasi dengan percobaan ketiga skenario setelah dilakukan percobaan sebanyak sepuluh kali dari host 1 ke host 6. Ketika penulis mengirimkan paket TCP untuk mengukur throughput melalui iperf dari host 1 ke host 6 , penulis menemukan adanya delay berupa TCP retransmisson dan TCP out of order. Seperti pada Gambar 4.9 dalam skenario 1. TCP retransmission dan TCP out of order terlihat pada komunikasi antara switch dengan controller yang menjadi pusatnya.

0 5 10 15 20 25

1 2 3 4 5 6 7 8 9 10

Throughput (Gb/s)

Nomor Percobaan

Skenario 1 Skenario 2 Skenario 3

(53)

Gambar 4.9. Delay terhadap TCP pada skenario 1

Pada skenario tiga, seluruh instansi controller juga menerima TCP retransmission dan TCP out of order lebih sedikit, dikarenakan fungsi controller telah dibagi sehingga tidak seperti skenario 1 dimana controller melakukan kontrol terhadap seluruh switch. Hal ini dapat dilihat pada Gambar 4.10.

Gambar 4.10. Delay terhadap TCP pada instansi 3 dalam skenario 3.

(54)

Peringatan retransmission pada Wireshark muncul ketika Wireshark mendeteksi dua paket data dengan urutan/sequence yang sama. Pengirim akan mengirimkan kembali (retransmit) data tersebut ketika dia tidak menerima acknowledgement dari paket yang dikirimkan dalam jangka waktu yang ditentukan. Sementara peringatan out of order mengindikasikan bahwa Wireshark mendeteksi paket yang bergerak melalui jalur yang tidak tepat.

Peringatan ini pada umumnya tidak menjadi masalah, kecuali batas waktu penerima untuk menerima paket out of order tersebut telah lewat (Chappel, 2013). Berdasarkan hasil pengamatan penulis, tidak ditemukan indikasi lain dari komunikasi data melalui ONOS dan switch, yang berpengaruh terhadap throughput. Throughput yang diterima pada ketiga skenario berada pada rentang 17.7 s/d 22.1 dimana rata-rata throughput dalam sepuluh kali percobaan untuk skenario 1, skenario 2 dan skenario 3 masing-masing adalah 194.5, 193.1 dan 194.5. Berdasarkan data tersebut, penulis melihat throughput tetap stabil dalam keadaan dilakukan virtualisasi.

(55)

BAB V

KESIMPULAN DAN SARAN

5.1 Kesimpulan

Berdasarkan hasil pengukuran dan analisis yang dilakukan pada penelitian ini, dapat disimpulkan bahwa :

1. Konsep virtualisasi dapat diterapkan dengan baik pada controller dalam jaringan LAN berbasis Openflow yang diemulasikan, dimana komunikasi switch dalam control network dapat dibagi sesuai dengan jumlah instansi yang dibentuk. Trafik data dari switch pada control network tetap berkomunikasi pada instansi controller yang menjadi pusatnya.

2. Virtualisasi pada jaringan umumnya digunakan untuk optimasi/meningkatkan fungsi manajemen maupun keamanan. Dengan nilai latency dan throughput yang tidak berpengaruh terhadap penambahan jumlah instansi dalam jaringan LAN berbasis Openflow, maka berdasarkan hasil emulasi, konsep virtualisasi tepat untuk diterapkan pada implementasi jaringan tersebut.

5.1 Saran

Adapun saran dari penelitian ini yang dapat digunakan untuk penelitian yang akan dating adalah:

1. Dengan virtualisasi controller, switch hanya akan berkordinasi dengan instansi controller yang menjadi pusatnya. Dengan dimungkinkannya pemisahan instansi ini, dapat ditingkatkan kemampuan manajeman jaringan seperti penerapan Quality of Service (QoS) maupun peningkatan keamanan untuk melindungi control network yang terpisah secara logika. Penulis berpendapat perlu diadakan kajian untuk hal tersebut.

2. Penerapan virtualisasi pada jaringan salah satunya adalah untuk mendukung sistem distribusi, dimana sumber daya sebuah sistem dapat diperbantukan

(56)

untuk sistem lain. Dengan virtualisasi controller, dapat mendukung konsep tersebut, dimana sumber daya controller dapat diperbantukan ke jaringan lain khususnya yang berbeda lokasi secara fisik (remote area). Penulis berpendapat perlunya kajian lebih lanjut terhadap hal tersebut.

(57)

DAFTAR PUSTAKA

Azodolmolky, S. 2013. Software Defined Networking with Openflow. PACKT Publishing: Birmingham.

Benton, K., Camp, L.J., Small, C. 2013. Openflow Vulnerability Assessment.

HotSDN’13 Proceedings of The Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networks. Pp. 151-152.

Chappel, L. 2010. Wireshark Network Analysis. Protocol Analysis Institute:

San Jose.

Chappel, L. 2013. Wireshark 101 Essential Skills for Network Analysis.

Protocol Analysis Institute: San Jose.

Duarte, O.C.M.B., Pujolle, G. 2013. Virtual Networks. ISTE Ltd: London.

Flowgrammable. 2016. (Online). http://flowgrammable.org/sdn/openflow /#tab_switch (28 Juni 2016).

Heller, B., Sherwood, R. & McKeown, N. 2012. The Controller Placement Problem. HotSDN’12 Proceedings of The First Workshop on Hot Topics in Software Defined Networks, pp. 7-12.

Hu, F. 2014. Network Innovation through Openflow and SDN. CRC Press: Boca Raton.

Kay, R. 2016. Pragmatic Network Latency Engineering Fundamental Facts and Analysis. (Online) https://www.cpacket.com/wp-content/uploads/2016 /03/introductiontonetworklatencyengineering.pdf (28 Juni 2016).

Marschke, D., Doyle, J., Moyer, P. 2015. Software Defined Networking:

Anatomy of Openflow. Lulu Publishing Services: Raleigh.

Mininet Overview. (Online) http://mininet.org/overview (17 Agustus 2016).

Nadeau, T.D. & Gray, K. 2013. SDN: Software Defined Networks. O’Reilly Media: Sebastopol.

Open Networking Foundation. 2014. The Benefits of Multiple Flow Tables and TTPs. (Online) https://www.opennetworking.org/images/stories/downl oads/sdn-resources/technical-reports/TR_Multiple_Flow_Tables_and _TTPs.pdf (9 Oktober 2015).

(58)

Peterson, L., Davie, B. 2003. Computer Networks a System Approach. Morgan Kauffman Publisher: San Francisco.

The Open Networking Lab. 2014. Introducing ONOS – a SDN Network Operating System for Service Providers. (Online) htp://onosproject.org /wp-content/uploads/2014/11/Whitepaper-ONOS-final.pdf (9 Oktober 2015).

The Open Networking Lab. (Online) https://wiki.onosproject.org/display/ON OS/Guides (9 Oktober 2015).

Turull, D., Hidell, M., Sjödin, P. 2014. Performance Evaluation of Openflow Controllers for Network Virtualization. 2014 IEEE 15^th International Conference on High Performance Switching and Routing (HPSR), pp.

50-56.

Ubuntu Documentation. (Online) https://help.ubuntu.com/lts/serverguide/lxc.

html (9 Oktober 2015).

(59)

LAMPIRAN PROGRAM MININET

Untuk skenario 1 sebagai berikut :

#!/usr/bin/env python import sys

import mininet.node import mininet.link

from mininet.topo import Topo from mininet.link import TCLink from mininet.cli import CLI from mininet.net import Mininet

from mininet.node import RemoteController, OVSKernelSwitch from mininet.log import setLogLevel

def skenario1():

net = Mininet(controller=RemoteController,link=TCLink)

#info('***menambahkan controller\n***') c1=net.addController('c1',

Controller=RemoteController,ip="10.0.3.11",port=6633)

#info('***menambahkan host\n***') h1=net.addHost('h1',ip="10.0.0.1") h2=net.addHost('h2',ip="10.0.0.2") h3=net.addHost('h3',ip="10.0.0.3") h4=net.addHost('h4',ip="10.0.0.4") h5=net.addHost('h5',ip="10.0.0.5") h6=net.addHost('h6',ip="10.0.0.6")

(60)

#info('***menambahkan switch\n***')

s1=net.addSwitch('s1',mac='00:00:00:00:00:01') s2=net.addSwitch('s2',mac='00:00:00:00:00:02') s3=net.addSwitch('s3',mac='00:00:00:00:00:03') s4=net.addSwitch('s4',mac='00:00:00:00:00:04') s5=net.addSwitch('s5',mac='00:00:00:00:00:05') s6=net.addSwitch('s6',mac='00:00:00:00:00:06')

#info('***menambahkan link\n***') net.addLink(h1,s1)

net.addLink(h2,s2) net.addLink(h3,s3) net.addLink(h4,s4) net.addLink(h5,s5) net.addLink(h6,s6) net.addLink(s1,s2) net.addLink(s2,s3) net.addLink(s3,s4) net.addLink(s4,s5) net.addLink(s5,s6)

#info('***menjalankan network\n***') net.start()

c1.start() s1.start([c1]) s2.start([c1]) s3.start([c1]) s4.start([c1]) s5.start([c1]) s6.start([c1])

(61)

#info('***menjalankan CLI\n***') CLI(net)

info('***stop network***') net.stop()

if __name__ == '__main__':

setLogLevel( 'info' ) skenario1()

def skenario1():

net = Mininet(controller=RemoteController,link=TCLink)

controller=RemoteController,ip="10.0.3.11",port=6633) c2=net.addController('c2',

(62)

net.addLink(h2,s2) net.addLink(h3,s3) net.addLink(h4,s4) net.addLink(h5,s5) net.addLink(h6,s6) net.addLink(s1,s2) net.addLink(s2,s3) net.addLink(s3,s4) net.addLink(s4,s5) net.addLink(s5,s6)

c1.start()

(63)

c2.start() s1.start([c1]) s2.start([c2]) s3.start([c1]) s4.start([c2]) s5.start([c1]) s6.start([c2])

if __name__ == '__main__':

def skenario1():

(64)

controller=RemoteController,ip="10.0.3.13",port=6633)

net.addLink(h2,s2) net.addLink(h3,s3) net.addLink(h4,s4) net.addLink(h5,s5) net.addLink(h6,s6)

(65)

net.addLink(s1,s2) net.addLink(s2,s3) net.addLink(s3,s4) net.addLink(s4,s5) net.addLink(s5,s6)

c1.start() c2.start() c3.start() s1.start([c1]) s2.start([c2]) s3.start([c3]) s4.start([c1]) s5.start([c2]) s6.start([c3])

if __name__ == '__main__':

(66)

LAMPIRAN KONFIGURASI ONOS DAN LXC

Konfigurasi ONOS untuk 1 instansi : export ONOS_NIC=10.0.3.*

export OC1="10.0.3.11"

export OCI="10.0.3.11"

exportONOS_FEATURES="webconsole,onos-rest,onos-gui,onos-api,onos-core,onos- cli,onos-openflow"

export ONOS_APPS="drivers,openflow"

export OC1="10.0.3.11"

export OC2="10.0.3.12"

export OC1="10.0.3.11"

export OC2="10.0.3.12"

export OC3="10.0.3.13"

Konfigurasi LXC pada container instansi-satu : lxc.network.type = veth

lxc.network.link = lxcbr0