Mou Jualan Beras

DESAIN DAN IMPLEMENTASI VPN SITE-TO-SITE
BERBASIS SDN MENGGUNAKAN NETWORK HYPERVISOR:

FLOWVISOR DAN OPENVIRTEX
TESIS
Karya tulis sebagai salah satu syarat

untuk memperoleh gelar Magister dari
Institut Teknologi Bandung
Oleh
GALIH NUGRAHA NURKAHFI

NIM : 23213361
(Program Magister Teknik Elektro)
SEKOLAH TEKNIK ELEKTRO DAN INFORMATIKA

INSTITUT TEKNOLOGI BANDUNG
2016
ABSTRAK
DESAIN DAN IMPLEMENTASI VPN SITE-TO-SITE BERBASIS SDN

MENGGUNAKAN NETWORK HYPERVISOR:
Oleh
NIM: 23213361
Program Magister Teknik Elektro
SDN adalah suatu bentuk desain, arsitektur dan manajemen jaringan komputer yang dibuat
untuk bisa menjawab perkembangan kebutuhan jaringan komputer serta mengatasi kekurangan
yang ada pada jaringan komputer tradisional. Konsep dasar SDN yaitu pemisahan control plane
dan data plane, sentralisasi controller serta kemampuan untuk menjalankan aplikasi jaringan
yang dijalankan di atas controller dibuat untuk memudahkan manajemen dan optimalisasi
jaringan serta memudahkan provisioning untuk skala jaringan yang besar. OpenFlow adalah
protokol yang menjadi standar protokol pada SDN yang digunakan untuk komunikasi antara
controller dan perangkat jaringan yang membuat suatu jaringan dapat diprogram berdasarkan
pada spesifikasi protokolnya.
Kehadiran SDN juga membawa berbagai macam perubahan terhadap berbagai macam
implementasi teknologi untuk menjalankan layanan jaringan termasuk juga teknologi untuk
menjalankan jaringan virtual, Implementasi konsep SDN mulai dilakukan pada berbagai
macam teknologi jaringan komputer, termasuk teknologi layanan jaringan yang dibuat oleh
pihak operator. Di era jaringan tradisional, kita mengenal teknologi virtual private
network(VPN) site-to-site untuk menjalankan komunikasi data yang aman dan bersifat privat
antara dua jaringan yang terpisah secara geografis, contohnya adalah jaringan pada kantor pusat
yang dihubungkan ke jaringan pada kantor cabang. Ketika jaringan SDN mulai dikembangkan,
mulai muncul juga wacana tentang virtualisasi berbasis SDN. Solusi virtualisasi jaringan
berbasis SDN mulai banyak dikembangkan oleh para peneliti, ada banyak jenis aplikasi
virtualisasi dengan berbagai macam karakteristiknya. Perlu ada banyak pengujian-pengujian
terhadap teknologi virtualisasi berbasis SDN untuk memastikan kapasitas dan kapabilitas
solusi tersebut, dan untuk bisa menilai kelayakan teknologi diatas sebagai solusi teknologi
virtualisasi jaringan berbasis SDN. Dalam tulisan ini akan dikaji dua buah aplikasi virtualisasi
i
SDN yaitu FlowVisor dan OpenVirtex untuk melihat karakteristik, kelebihan dan kekurangan
serta kelayakan kedua buah teknologi tersebut untuk diimplementasikan sebagai solusi VPN
site-to-site berbasis SDN.
Dari hasil penelitian ini didapatkan fakta bahwa, Solusi virtualisasi jaringan berbasis SDN
memiliki keunggulan dalam hal kemudahan konfigurasi di sisi jaringan operator, implementasi
fungsi virtualisasi jaringan untuk tenant yang lebih mudah, manajemen yang lebih mudah.
Selain itu didapatkan fakta bahwa dari segi fitur solusi OpenVirtex lebih baik dibandingkan
FlowVisor sebagai solusi jaringan virtual SDN, namun keduanya masih memiliki banyak
masalah bug dan kestabilan dan harus dikembangkan lebih lanjut.
Kata Kunci: Software Defined Networking, OpenFlow, Virtualisasi, Network hypervisor,

FlowVisor, OpenVirtex, Testbed.
ii
ABSTRACT
DESIGN AND IMPLEMENTATION OF SDN BASED SITE-TO-SITE
VPN SERVICES USING NETWORK HYPERVISOR:
FLOWVISOR AND OPENVIRTEX
By
NIM: 23213361
Electrical Engineering Master Program
SDN is a network computer design, architecture and management, that made to address the
needs future computer network development and overcome the limitation on the traditional
computer network. The basic of SDN concept is separating control plane and data plane,
centralize network controller and capability to running network application on the top of the
controller. SDN is made to facilitate the management and optimization of the network as well
as facilitate provisioning for large-scale network. OpenFlow is a protocol that became the
standard protocol on SDN are used for communication between the controller and the
network devices that create a network can be programmed based on the protocol
specification.
Presence Technology SDN also carries a wide variety of changes to a wide range of technology
implementations for running network services as well as technology to run virtual network.
Implementation of the concept of SDN is spread in a wide variety of computer network
technology, including technology network services made by the operator. In the era of the
traditional network, we know the technology of virtual private network (VPN) site-to-site to
run a secure and private data communication between two geographically separate networks,
for an example is the network at the central office connected to the network at the branch office.
When the research of SDN network began to spread, there is also several communities started
to research about virtualization-based SDN. There are many kinds of virtualization applications
with a variety of characteristics. There are needs a lot of tests on SDN-based virtualization
technology to ensure the capacity and capability of the solution, and to be able to assess the
feasibility of the technology as a mature network virtualization technology solutions. In this
document will be reviewed two SDN virtualization technology: FlowVisor and OpenVirtex, to
see the characteristics, advantages and disadvantages and the feasibility of the two kinds of the
application to be implemented as a SDN based VPN site-to-site solution.
iii
From the results of this research, the author found the fact that, SDN-based network
virtualization solution has advantages in terms of ease of configuration on the side of the carrier
network, the easier of network virtualization functionality implementation for tenant, and of
course the easier network management. In addition it obtained the fact that OpenVirtex have
better features than FlowVisor as a virtual network SDN solution, but both still have a lot of
bugs and stability issues and should be developed further.
Key Word: Software Defined Networking, OpenFlow, Virtualization, Network hypervisor,

FlowVisor, OpenVirtex, Testbed.
iv
LEMBAR PENGESAHAN
DESAIN DAN IMPLEMENTASI VPN SITE-TO-SITE BERBASIS SDN

MENGGUNAKAN NETWORK HYPERVISOR:
Oleh
Galih Nugraha Nurkahfi

NIM : 23213361
(Program Magister Teknik Elektro)
Bandung, 1 Februari 2016
Menyetujui
Pembimbing
Dr. Ing. Eueung Mulyana, S.T., M.Sc.

NIP. 19741218 200801 1009
v
PEDOMAN PENGGUNAAN TESIS
Tesis S2 yang tidak dipublikasikan terdaftar dan tersedia di Perpustakaan Institut Teknologi
Bandung, dan terbuka untuk umum dengan ketentuan bahwa hak cipta ada pada pengarang
dengan mengikuti aturan HaKI yang berlaku di Institut Teknologi Bandung, Referensi
kepustakaan diperkenankan dicatat, tetapi pengutipan atau peringkasan hanya dapat dilakukan
seizin pengarang dan harus disertai dengan kebiasaan ilmiah untuk menyebutkan sumbernya.
Memperbanyak atau menerbitkan sebagian atau seluruh tesis haruslah seizin

Direktur Program Pascasarjana, Institut Teknologi Bandung.
Perpustakaan yang meminjam tesis ini untuk keperluan anggotanya harus mengisi nama dan
tanda tangan peminjam dan tanggal pinjam
vi
KATA PENGANTAR
Alhamdulillahirabbil'alamin, dengan mengucapkan syukur kehadirat Allah SWT yang

senantiasa memberikan petunjuk serta melimpahkan berkah dan rahmat- Nya, sehingga tesis
ini dapat diselesaikan dengan judul “Desain dan Implementasi VPN Site-to-Site Berbasis SDN
Menggunakan Network Hypervisor: FlowVisor dan OpenVirtex". Tesis ini disusun sebagai
salah satu syarat untuk memperoleh gelar magister pada jurusan Telekomunikasi, opsi
Telematika dan Jaringan Komputer, program Magister Teknik Elektro, Sekolah Teknik
Elektro dan Informatika, Institut Teknologi Bandung.
Ucapan terima kasih saya ucapkan kepada segenap pihak yang secara langsung maupun tidak
langsung telah membantu serta memudahkan proses terselesaikannya Tesis ini. Untuk itu,
penulis ingin mengucapkan terima kasih kepada :
1. Allah SWT Tuhan semesta alam yang mentakdirkan penulis untuk bisa menimba setetes
dari lautan ilmunya, yang menghadirkan banyak makna di hidup penulis.
2. Rasulullah Muhammad Salallahu Alaihi Wassalam, nabi akhir zaman, suri tauladan bagi
umat manusia.
3. Kedua orang tua, Bapak Sutrisno dan Ibu Maridah yang selalu memberikan dukungan tanpa
lelah semenjak awal penulis menuntut ilmu, serta doa yang tak henti yang mengiringi
setiap langkah-langkah penulis dalam menyelesaikan tulisan ini.
4. Lisa Ayu Larasati selaku istri tercinta dari penulis yang selalu memberikan dukungan
kepada penulis selama menjalani studi.
5. Kedua mertua, Bapak Sudi Pratolo dan Ibu Rostika Lokawati yang banyak memberikan
dukungan dan doanya.
6. Bapak Dr. Ing. Eueung Mulyana, selaku pembimbing yang telah memberikan bimbingan,
memberikan waktunya dalam membimbing serta memberikan banyak inspirasi bagi
penulis.
7. Bapak Dr. Tutun Juhana selaku Ketua Kelompok Keahlian Telematika dan Jaringan
Komputer yang telah membantu penulis dalam menyediakan beasiswa, sehingga penulis
bisa menyelesaikan studi dengan tanpa memikirkan biaya serta banyak menginspirasi
penulis untuk menjadi seorang yang memiliki intelektualitas tinggi namun tetap rendah
hati dan membumi.
8. Bapak Ir. Hardi Nusantara, MT. dan Bapak Dr. Tutun Juhana serta Bapak Rifky Hakimi
vii
ST. MT. yang telah memberikan waktu dan perhatian untuk menguji penulis dalam sidang
tesis.Dosen-dosen yang telah memberikan ilmunya selama penulis menempuh studi.
9. Staff Tata Usaha Lab Telematika, Pak Asep dan Pak Dadang yang telah membantu semua
administrasi dalam menempuh studi Magister serta Tesis ini.
10. Teman-teman dari Teknik Elektro Lab Telematika-Telekomunikasi Kreatif yang telah
banyak memberikan makna mengena dari perjalanan menempuh studi. Ayie, Havid, Ady,
Pories, Wervyan, Rifqy dan Izzati.
11. Ghulam Faqih yang secara khusus membantu merapikan dokumen tesis milik penulis.
12. Teman-teman group whatssap Residensi Allstar yang banyak memberikan dukungan
kepada penulis selama menempuh studi: Rifqy, Ayie, Havid, Vano, Arya, Ady, Pories,
Firman, Dynal, Jun, Rohmat.
13. Teman-teman seangkatan kuliah S2: Cokde, Galuh, Evan, Bagus, Hamzah, Galuh, Dwina,
Triadi dan Dito yang menjadi rekan-rekan seperjuangan dari awal masuk sampai sekarang.
14. Teman-teman residensi yang lain: Mas Mukti, Arief, Jude, Beny, Rizky, Maya, Nisa dan
Suci yang juga menjadi rekan-rekan seperjuangan menempuh kuliah demi kuliah.
15. Pories Ediansyah yang secara khusus yang telah banyak memberikan masukkan dalam
proses penulisan thesis ini.
16. Semua pihak yang tidak dapat disebutkan karena kekhilafan penulis selaku manusia yang
telah membantu dalam proses penyelesaian Tesis ini.
Penulis menyadari bahwa tesis ini masih jauh dari sempurna, untuk itu kritik dan saran sangat
diharapkan. P e n u l i s berharap tulisan ini dapat menjadi sesuatu yang bermanfaat,
menambah wawasan dan pengetahuan bagi pembacanya. Amin.
Bandung, 1 Februari 2016
Penulis
viii
DAFTAR SINGKATAN
API Application Programming Interface

ARP Address Resolution Protocol
CPU Control Processing Unit
ICMP Internet Control Message Protocol
IP Internet Protocol
LLDP Link Layer Discovery Protocol
MAC Media Access Control
MPLS Multi Protocol Label Switching
NIC Network Interface Card
NFV Network Function Virtualization
OFP OpenFlow Packet
OVX OpenVirtex
PC Personal Computer
SDN Software Defined Networking
TCP Transmission Control Protocol
UDP User Datagram Protocol
VLAN Virtual LAN
VPLS Virtual Private Lan Service
VPN virtual private network
ix
DAFTAR ISI
ABSTRAK…………………………………………………………………………………………i
ABSTRACT……………………………………………………………………………………...iii
LEMBAR PENGESAHAN……………………………………………………………………….v
PEDOMAN PENGGUNAAN TESIS……………………………………………………………vi
KATA PENGANTAR…………………………………………………………………………...vii
DAFTAR SINGKATAN…………………………………………………………………………ix
Bab I PENDAHULUAN...………………………………………………………………………..1
I.1 Latar Belakang…………………………………………………………………….1
I.2 Rumusan Masalah………………………………………………………................3
I.3 Tujuan……………………………………………………………………………..3
I.4 Batasan Masalah………………………………………………...………………...4
I.5 Metoda Penelitian………………………………………………………………....4
I.6 Sistematika Penelitian……………………………………………………………..5
Bab II TINJAUAN PUSTAKA..…………………………………………………………………6
II.1 Jaringan Tradisional Sebelum Adanya SDN……………………………………...6
II.2 SDN, OpenFlow dan Cara Kerjanya………………………………………………7
II.3 Protokol OpenFlow………………………………………………………………10
II.4 Format Header OpenFlow…………………………………………………….....12
II.5 Cara Kerja OpenFlow …………………………………………………………....13
II.6 Reactive dan Proactive Flow…………………………………………………….15
II.6.1 Reactive Flow……………………………………………………………15
II.6.2 Proactive flow……………………………………………………………16
I.7 Jaringan Virtual SDN………………………………………………………….....16
II.8 MPLS…………………………………………………………………………….18
II.9 VPN……………………………………………………………………………...19
II.10 OpenVirtex……………………………………………………………………….21
II.10.1 Virtualisasi alamat IP…………………………………………………….22
II.10.2 Virtualisasi Link dan Route……………………………………………...24
II.11 FlowVisor………………………………………………………………………..26
II.11.1 Virtualisasi jaringan……………………………………………………...26
II.12.2 Forwarding table………………………………...………………………28
II.12.3 Arsitektur FlowVisor…………………………………………………….28
Bab III METODOLOGI PENELITIAN dan DESAIN PERCOBAAN….……………………...30
III.1 Metodologi Penelitian………………………………………………………………30
III.1.1 Studi Literatur………………...………………………………………….31
III.1.2 Mengidentifikasi Permasalahan..………………………………………...31
III.1.3 Menentukan Tujuan………….…………………………………………..31
III.1.4 Perancangan dan Implementasi..…………………………….…………...32
III.1.5 Analisis dan Hasil Penelitian..…………………………………………...32
III.1.5 Penyusunan Tesis…………....…………………………………………...32
III.2 Kebutuhan Perangkat Keras……………………………………………………...33
III.3 Kebutuhan Perangkat Lunak…...………………………………………………...34
III.3.1 Software untuk Controller…………………………...…………………..35
III.3.2 Software untuk switch P dan PE…………………………….…………...36
III.3.3 Software untuk Hypervisor……………………………………………....36
III.3.4 Software untuk CE……………………………………………………….37
III.3.5 Software untuk host……………………………………………………...37
III.4 Desain Topologi Jaringan………………………………………………………..37
III.5 Desain Percobaan pada Testbed………………………………………………….41
III.6 Metode Pengukuran Kinerja Testbed VPN Site-to-Site………………………….43
BAB IV Hasil PERCOBAAN dan ANALISIS…………………...……………………………..46
IV.1 Pengujian Fungsionalitas Dasar Testbed……………….………………………..44
IV.2 Pengujian Fungsionalitas Virtualisasi dengan Menggunakan FlowVisor…..…...46
IV.2.1 Implementasi Virtualisasi Fungsi Layanan Jaringan…………………….49
IV.2.2 Pengujian Fungsi Failover pada FlowVisor……………………………...50
IV.3 Pengujian Fungsionalitas dengan OpenVirtex……...…………………………....54
IV.3.1 Implementasi Virtualisasi Fungsi Layanan Jaringan…………………….61
IV.3.2 Pengujian Fungsi Failover pada OpenVirtex……………………………62
IV.4 Pengujian Kinerja Virtualisasi………..………………………………………….71
IV.4.1 Pengukuran Delay………………………………………………………..71
IV.4.2 Pengukuran Jitter………………………………………………………...73
IV.4.3 Pengukuran Througput pada OpenVirtex dan FlowVisor..……………...74
IV.4.4 Pengukuran Througput untuk Testbed Tanpa Virtualisasi.………………75
IV.4.5 Pengukuran CPU dan Memory Hypervisor Dalam Kondisi Idle dan
Melakukan Pemrosesan Flow Data….…………………………………………...76
IV.4.6 Pengukuran CPU dan Memory pada Controller Dalam Kondisi Idle dan
Melakukan Pemrosesan Flow Data………………………...…………………….77
IV.5 Bug dan Error pada Masing-Masing HyperVisor………………………………..79
BAB V KESIMPULAN dan SARAN………………………………………………...………...82
V.1 Kesimpulan………………………………………………………………………82
V.2 Saran……………………………………………………………………………..83
DAFTAR PUSTAKA……………………………………………………………………………84
LAMPIRAN
LAMPIRAN A……………………………………………………………………………I
LAMPIRAN B……………………………………………………………………….XXII
DAFTAR GAMBAR
Gambar II-1 Arsitektur Sederhana SDN………………………………………………………....7

Gambar II-2 Breakdown Arsitektur SDN...………………………………………………………9
Gambar II-3 Header OpenFlow…………………………………………………………………12
Gambar II-4 Cara Kerja OpenFlow……………………………………………………………..13
Gambar II-5 Diagram Switch OpenFlow………………………………………………………..13
Gambar II-6 Flow Paket Data di Dalam OpenFlow 1.0………………………………………...14
Gambar II-7 Mekanisme Reactive Flow………………………………………………………...15
Gambar II-8 Mekanisme Proactive Flow…………………………..…………………………...16
Gambar II-9 Server dan Network Hypervisor………..………………………………………….17
Gambar II-10 VPN pada Jaringan Operator…………………………….………………………21
Gambar II-11Arsitektur Besar OpenVirtex………………….……………………………….....23
Gambar II-12 Interaksi OpenVirtex dengan Controller dan Switch…………………………….23
Gambar II-13 Modifikasi Flow oleh OpenVirtex……………………………………………….24
Gambar II-14 Skema Link Pada OpenVirtex………………...………………………………….25
Gambar II-15 Skema Link Virtual pada OpenVirtex………………………..…………………..25
Gambar II-16 Slicing Topologi dengan FlowVisor……………...……………………………...27
Gambar III-1 Metodologi Penelitian…………………………………………………………….30
Gambar III-2 Implementasi Testbed……………………………………………………………..33
Gambar III-3 Topologi Jaringan Fisik Testbed………..…………………………………………38
Gambar III-4 Jaringan Virtual Tenant OpenVirtex……………………………………………...42
Gambar III-5 Jaringan Virtual Tenant FlowVisor……………………………………………….42
Gambar IV-1 Topologi Fisik Testbed Multitenant………………………………………….…..45
Gambar IV-2 Topologi Logic Testbed Multitenant…….……………………………………….45
Gambar IV-3 Sampel Flowspace untuk Tenant1 dan Tenant2………………………………….47
Gambar IV-4 Topologi Utama Tenant 1……………………………………………………...…48
Gambar IV-5 Topologi Utama Tenant 2………………………………………………………...48
Gambar IV-6 Topologi Utama Virtualisasi pada FlowVisor untuk Kedua Tenant..…………..51
Gambar IV-7 Topologi Backup untuk Tenant 1…………………………………..…………….51
Gambar IV-8 Topologi Backup untuk Tenant 2………………………………………………...52
Gambar IV-9 Fow baru di switch P2……………………………………………………………53
Gambar IV-10 Topologi Jaringan Virtual Tenant 1……………………………………….……58
Gambar IV-11 Topologi Jaringan Virtual Tenant 2……………………………………….……58
Gambar IV-12 Flow-entry Jaringan Tenant 1 pada Switch virtual 1……………………………59
Gambar IV-13 Flow-entry Jaringan Virtual Tenant 1 pada Switch Virtual 2…………………...59
Gambar IV-14 Flow-entry Jaringan Virtual Tenant 2 pada Switch Virtual 1…………………..60
Gambar IV-15 Flow-entry Jaringan Virtual Tenant 2 pada Switch Virtual 2…………………..60
Gambar IV-16 Topologi Utama dan Backup Virtualisasi pada OpenVirtex
untuk Kedua tenant……………………………………………………………..………………..64
Gambar IV-17 Proses Ping Sewaktu Failover…………………………………………………...66
Gambar IV-18 Flow-entry Jaringan Virtual Tenant 1………………………….……………….67
Gambar IV-19 Flow-entry Jaringan Virtual Tenant 2………………..………………………....68
Gambar IV-20 Grafik Perbandingan untuk FlowVisor dan OpenVirtex………………………..71
Gambar IV-21 Delay pada Testbed……………………………………………………………...72
Gambar IV-22 Grafik Perbandingan Jitter……..……………………………………………......73
Gambar IV-23 Jitter pada Testbed ……………………………………………………………...74
Gambar IV-24 Grafik Throughput pada FlowVisor dan OpenVirtex…………………………...75
Gambar IV-25 Grafik Throughput TCP dan UDP untuk Testbed…..…………………………..75
Gambar IV-26 Grafik Hypervisor saat FlowVisor dan OpenVirtex Idle…………………...…..76
Gambar IV-27 Grafik Hypervisor pada saat FlowVisor dan OpenVirtex
Memproses Flow Data……………………………………………………………………….…..77
Gambar IV-28 Grafik Controller pada saat FlowVisor dan OpenVirtex Idle……………...…....78
Gambar IV-29 Grafik controller pada saat FlowVisor dan OpenVirtex Memproses Paket……..79
Gambar IV-30 Anomali Penggunaan Sumberdaya Komputasi pada FlowVisor….…………….79
Gambar IV-31 Error pada Operasional FlowVisor……………………………………………...80
Gambar IV-32 Error pada Penggunaan Sembarang Blok IP……………………………………81
DAFTAR TABEL
Tabel II-1 Versioning OpenFlow..………………………………………………………………11

Tabel II-2 Penjelasan Header OpenFlow ……………………………………………………….12
Tabel III-1 Spesifikasi Komponen Server Fisik..………………………………………………..33
Tabel III-2 Spesifikasi Komponen Logic Server Virtual…………….…………………………..34
Tabel III-3 Software untuk controller………………………………….………………………...35
Tabel III-4 Software untuk Switch P dan PE…………………………………………………….36
Tabel III-5 Software untuk HyperVisor………………………………….………………………36
Tabel III-6 Software Untuk switch CE…………………………………………………………..37
Tabel III-Software untuk Host……………………………...……………………………………37
Tabel III-8 Datapath Switch .........................................................................................................39
Tabel III-9 Konfigurasi Bridge…………………………………………………………………..40
Tabel IV-1 Baris Konfigurasi yang Berbeda pada Setiap Instance Controller. …….…..…..…..47
Tabel IV-2 Rute Antar Switch CE di Dalam Suatu Tenant ……………………………………..48
Tabel IV-3 Pengujian Firewall pada Masing-Masing Tenant………………………………...…49
Tabel IV-4 Jalur Utama Tenant pada FlowVisor……………………………….……………..…50
Tabel IV-5 Jalur Backup Tenant 1 dan Tenant 2……..……………..….……….……………….52
Tabel IV-6 Daftar Blok IP Address Site Tenant…..………...…………………………………...53
Tabel IV-7 Konfigurasi Lengkap OpenVirtex untuk Kedua Tenant………..……...……………55
Tabel IV-8 Flow-entry di Setiap Switch untuk Tenant 1……………...……….….……………..55
Tabel IV-9 Flow-entry di Setiap Switch untuk Tenant 2………...….…………….…………..…56
Tabel IV-10 Translasi Pengalamatan untuk Tenant 1…………………………….………….…..57
Tabel IV-11 Translasi Pengalamatan untuk Tenant 2…………………………….……………...58
Tabel IV-12 Pengujian Firewall pada Masing-Masing Tenant………….……….……………...61
Tabel IV-13 Jalur Utama Maupun Backup Logic Tenant pada OpenVirtex……….……………62
Tabel IV-14 Jalur Backup Tenant 1 dan Tenant 2………………………………….……………63
Tabel IV-15 Tabel Blok IP Address untuk Setiap Site Milik Tenant…...…………..………...…66
Tabel IV-16 Flow Table untuk Percobaan Koneksi antar Host Dalam Satu tenant………….….68
Tabel IV-17 Translasi Pengalamatan untuk Tenant 1………………..……………………….…70
Tabel IV-18 Translasi Pengalamatan untuk Tenant 2…………………..…………………….…70
Tabel IV-19 Pengukuran Delay pada FlowVisor dan OpenVirtex……………………………....71
Tabel IV-20 Pengkuruan Jitter pada FlowVisor dan OpenVirtex……………………………….73
Tabel IV-21 Pengkuruan Throughput pada FlowVisor dan OpenVirtex…………………….......74
Tabel IV-22 Pengukuran Throughput TCP dan UDP pada Testbed Tanpa Virtualisasi…….......75
Tabel IV-23 Pengukuran Sumberdaya Hypervisor Saat FlowVisor dan OpenVirtex Idle……....76
Tabel IV-24 Pengukuran Sumberdaya Hypervisor pada saat FlowVisor dan
OpenVirtex Memproses Flow Data……………………………………………………………...77
Tabel IV-25 Pengukuran Sumberdaya Controller pada saat OpenVirtex dan FlowVisor Idle….78
Tabel IV-26 Pengukuran Sumberdaya Controller pada saat OpenVirtex dan FlowVisor
Memproses Paket………………………………………………………………………………...78
Bab I
PENDAHULUAN
I.1 Latar Belakang
Internet adalah jaringan komputer global yang di atasnya berjalan berbagai macam layanan.
Layanan-layanan ini memiliki karakteristik yang bervariasi dan menggunakan protokol-protokol
yang berbeda-beda. Hal tersebut diatas menyebabkan kompleksitas dalam hal desain,
manajemen dan operasional dari sistem jaringan komputer, ditambah lagi dengan beragamnya
peralatan jaringan komputer yang diproduksi oleh vendor.
Software Defined Networking(SDN) adalah suatu bentuk desain, arsitektur dan manajemen
jaringan komputer yang dibuat untuk bisa mengatasi permasalahan tersebut diatas. SDN adalah
sebuah konsep untuk memisahkan control plane, management plane dari forwarding plane di
perangkat jaringan. Konsep SDN juga dibutuhkan karena didalam dunia jaringan komputer yang
sebenarnya tidak ada pemakaian yang seimbang antara control plane dengan forwarding data
plane.Control plane dan data plane memiliki fungsi yang berbeda didalam penggunaanya dalam
operasional jaringan komputer. Sebagai contoh dalam aplikasi network switch, forwarding plane
lebih banyak terpakai sumberdayanya dibandingkan control plane. Contoh lainnya adalah pada
perangkat firewall, Intrussion Detection System(IDS) dan Deep Packet Inspection(DPI), control
plane lebih dominan terpakai sumber dayanya dibandingkan dengan forwarding plane. Dari
fakta diatas, SDN dapat menjadi solusi untuk suatu sistem yang bisa lebih bisa menjalankan
keseimbangan antara control plane maupun forwarding plane. Selain itu dengan kemampuan
jaringan SDN untuk diprogram, menjadikan jaringan tidak lagi bersifat tertutup dan kaku.
Jaringan berbah menjadi lebih terbuka dan bisa diprogram untuk mengaplikasikan suatu
kebutuhan yang spesifik. SDN memberikan kontrol yang lebih luas terhadap jaringan, yang
memungkinkan optimalisasi dan kustomisasi serta mengurangi biaya pembelian dan operasional
jaringan secara keseluruhan.
Openflow adalah salah satu protokol dalam SDN yang menjadi standar de facto. yang
digunakan untuk komunikasi antara controller dan perangkat jaringan yang membuat suatu
1
jaringan dapat diprogram berdasarkan pada spesifikasi protokolnya. Keberadaan protokol
OpenFlow telah menjadikan keistimewaan-keistimewaan pada jaringan SDN bisa ada
Teknologi virtualisasi telah ada sejak cukup lama, namun sampai sekarang, fokus dari
pengembangan teknologi virtualisasi lebih condong kepada virtualisasi komputer dan virtualisasi
pada jaringan agak tertinggal di belakang. Hal ini menghambat kemampuan operator jaringan
untuk menyediakan layanan virtualisasi jaringan yang lebih baik. tujuan ideal dari virtualisasi
jaringan pada operator adalah untuk menyediakan suatu jaringan virtual, yang topologi,
manajemen dan penggunaannya berada dalam kontrol penuh dari tenant yang menyewa jaringan
tersebut. Keberadaan dari SDN dan protokol OpenFlow telah memungkinkan hal tersebut diatas
dilakukan.
Salah satu teknologi yang lahir dari keberadaan konsep SDN adalah network hypervisor, yang
berfungsi untuk menjalankan jaringan virtual diatas jaringan fisik dengan cara menjadi penengah
untuk menjalankan translasi antara jaringan fisik dan jaringan virtual, komunikasi antara
jaringan virtual-Network, hypervisor dan jaringan fisik dilakukan dengan menggunakan protokol
OpenFLow. Solusi virtualisasi jaringan berbasis SDN mulai banyak dikembangkan oleh para
peneliti, ada banyak jenis aplikasi dengan berbagai macam karakteristiknya. Perlu ada banyak
pengujian-pengujian terhadap teknologi virtualisasi berbasis SDN untuk memastikan kapabilitas
dan kapabilitas solusi tersebut, untuk bisa menilai kelayakan teknologi diatas sebagai solusi
teknologi virtualisasi jaringan. Dalam tulisan ini akan dikaji dua buah teknologi virtualisasi SDN
yaitu FlowVisor dan OpenVirtex untuk melihat karakteristik, kelebihan dan kekurangan serta
kelayakan kedua buah teknologi tersebut untuk diimplementasikan sebagai solusi virtualisasi
jaringan berbasis SDN. FlowVisor hadir terlebih dahulu dibandingkan OpenVirtex sebagai
aplikasi network hypervisor yang banyak diujicoba di banyak institusi pendidikan dan penelitian,
OpenVirtex hadir belakangan dan digadang-gadang sebagai calon pengganti FlowVisor dengan
kelebihan-kelebihan fiturnya. FlowVisor merupakan suatu aplikasi network hypervisor yang
bekerja secara cukup sederhana dengan fitur-fitur: slicing topologi, bandwidth, CPU dan
protokol. Sedangkan pengembang OpenVirtex mengklaim OpenVirtex memiliki kemampuan
yang lebih baik dibandingkan dengan FlowVisor.
2
Kemampuan leih dari OpenVirtex adalahadalah kemampuannya untuk menghadirkan suatu
virtualisasi jaringan secara penuh. Tenant akan bisa secara leluasa untuk menjalankan fungsi
kontrol terhadap jaringan virtual yang topologinya spesifik sesuai dengan kebutuhan tenant dan
tidak bergantung pada bentuk jaringan fisik, selain itu tenant bisa memiliki address space
sendiri.
I.2 Rumusan Masalah
Permasalahan yang diangkat pada penelitian ini adalah:

1. Bagaimana cara mengimplementasikan VPN site-to-site berbasis SDN dengan
menggunakan FlowVisor dan OpenVirtex.
2. Apakah fungsionalitas dan fitur yang dimiliki oleh FlowVisor dan OpenVirtex bisa
berjalan secara baik untuk bisa menjalankan layanan VPN site-to-site berbasis SDN.
3. Bagaimana kinerja dari FlowVisor dan OpenVirtex dalam segi penggunaan sumber daya
komputasi dan jaringan.
4. Network hypervisor mana yang lebih baik antara FlowVisor atau OpenVirtex untuk
menjalankan VPN site-to-site berbasis SDN. dan apakah solusi tersebut sudah layak
untuk diimplementasikan dalam jaringan real.
5. Apakah solusi berbasis SDN lebih baik jika dibandingkan dengan solusi jaringan
tradisional untuk menjalankan layanan VPN site-to-site.
I.3 Tujuan
Tujuan dari penelitian ini adalah:

1. Mendesain dan mengimplementasikan testbed jaringan VPN site-to-site berbasis SDN
yang bisa menjalankan fungsi multi tenant.
2. Menjalankan jaringan virtual di dalam testbed yang memisahkan traffic antara dua
tenant yang berbeda dengan menggunakan FlowVisor dan OpenVirtex
3. Menguji dan membandingkan fungsionalitas VPN site-to-site berbasis SDN yang
menggunakan network hypervisor FlowVisor dan OpenVirtex serta menganalisis
kelebihan dan kekurang dari keduanya.
3
4. Menguji kinerja VPN site-to-site berbasis SDN yang menggunakan network
hypervisor FlowVisor dan OpenVirtex yang meliputi parameter kinerja jaringan(delay,
jitter, througput) dan penggunaan sumber daya komputasi(CPU, memory).
I.4 Batasan Masalah
1. Controller SDN yang digunakan secara adalah Floodlight versi 0.9 karena kestabilannya
yang sudah terbukti.
2. OpenFlow versi terakhir yang digunakan saat penelitian berlangsung adalah versi 1.5
eksperimental dan versi stabil 1.4. Sedangkan yang digunakan saat pengujian adalah
openflow 1.0 karena versi ini bisa berjalan pada kedua aplikasi OpenVirtex maupun
FlowVisor.
3. Fungsionalitas dari teknologi jaringan virtual yang diuji adalah: isolasi traffic, failover,
penambahan aplikasi firewall untuk setiap tenant dan fungsi VPN site-to-site.
4. Performa dari teknologi virtualisasi yang diuji adalah: performa jaringan virtual yang
dijalankan dan penggunaan sumber daya komputasi dari penggunaan kedua buah solusi
virtualisasi
5. Pengujian yang dilakukan adalah dengan metode blackbox.
I.5 Metoda Penelitian
Metoda yang dilakukan pada penelitian ini adalah:

1. Studi literatur.
2. Desain testbed dan pemilihan teknologi pada testbed.
3. Implementasi VPN site-to-site SDN dengan menggunakan FlowVisor dan OpenVirtex.
4. Pengujian fungsionalitas dan kinerja dari testbed yang akan digunakan untuk
menjalankan VPN site-to-site berbasis SDN.
5. Pengujian fungsionalitas dan kinerja dari VPN site-to-site berbasis SDN menggunakan
network hypervisor FlowVisor dan OpenVirtex.
4
I.6 Sistematika Penelitian
Penulisan laporan tesis ini disusun dengan sistematika sebagai berikut:
BAB I : Pendahuluan
Bab ini berisi dan menjelaskan latar belakang, perumusan masalah, tujuan dari penelitian,
batasan masalah dalam penelitian, metoda penelitian, dan sistematika penulisan laporan
BAB II : Tinjauan Pustaka

Bab ini membahas mengenai SDN, OpenFlow, testbed, virtualisasi jaringan, VPN, virtualisasi,
network hypervisor, OpenVirtex, FlowVisor serta perangkat-perangkat untuk membangun
jaringan berbasis SDN.
BAB III : Metodologi Penelitian dan Desain Percobaan

Bab ini menjelaskan mengenai spesifikasi perangkat keras yang digunakan, perangkat lunak
yang digunakan didalam testbed, rancangan jaringan virtual berbasis SDN dengan menggunakan
network hypervisor OpenVirtex dan Flowvisor serta implementasi virtualisasi jaringan berbasis
SDN di atas testbed.
BAB IV :Hasil Percobaan dan Analisis

Bab ini menjelaskan mengenai metoda yang digunakan dalam pengujian, hasil pengujian dan
analisis implementasi testbed virtualisasi jaringan dengan menggunakan network hypervisor
OpenVirtex dan FlowVisor
BAB V: Kesimpulan dan Saran

Bab ini berisi kesimpulan akhir dari penelitian ini, serta saran untuk kelanjutan penelitian
berikutnya
5
Bab II
TINJAUAN PUSTAKA
II.1 Jaringan Tradisional Sebelum Adanya SDN
Jaringan komputer tradisional dibuat dengan cara mengkoneksikan komputer dengan kombinasi
dari kabel dan media nirkabel serta hardware jaringan. Tanpa melihat topologi jaringan atau skala
jaringan, hardware jaringan terdiri dari tiga buah komponen utama: aplikasi, control plane dan
data plane. Control plane menyimpan informasi yang bisa digunakan untuk menangani paket data,
informasi ini yang selanjutnya digunakan oleh data plane, membuat informasi ini membuntuhkan
penanganan signaling protocol yang rumit. Data plane adalah subsistem dari node jaringan yang
menerima dan mengirim paket dari interface, memprosesnya sesuai dengan protokol yang
digunakan untuk selanjutnya mengalami perlakuan: send, drop atau forward.
Switch dan router tradisional dibuat dengan jutaan kode program dan ratusan atau bahkan ribuan
kode program. Semuanya di tuliskan di atas chip yang ada pada hardware jaringan. Keterbatasan
dalam melakukan pengaturan jaringan telah menciptakan beberapa masalah, termasuk kesulitan
untuk mengubah penggunaan hardware, support jangka panjang, restriksi kontrol pengguna dan
banyak lagi yang lainnya. Keberadaan SDN banyak mendorong perubahan besar pada cara seorang
administrator jaringan memandang jaringan yang dikelolanya. Dengan adanya SDN, data plane
dan control plane bisa dipisahkan sehingga menghadirkan jaringan yang fleksibel dan bisa
diprogram. Satu teknologi utama yang ada di belakang SDN adalah protokol OpenFlow yang
bersifat opensource, yang berfungsi untuk komunikasi antara perangkat jaringan dan controller.
6
Gambar II-1 Arsitektur Sederhana SDN
II.2 SDN, OpenFlow dan Cara Kerjanya
Dalam arsitektur SDN, control plane dan data plane dipisahkan, infrastruktur jaringan dipisahkan
dari aplikasi. Dengan pendekatan ini para pengguna perangkat jaringan memperoleh kendali penuh
dan kemampuan memprogram pada jaringan yang sebelumnya tidak ada, sehingga hal ini
menjadikan administrator jaringan bisa memperluas dan mengadaptasi jaringan untuk kebutuhan
institusi mereka dengan lebih mudah dan lebih murah.
Software Defined Network (SDN) adalah istilah yang merujuk pada konsep/paradigma baru dalam
mendesain, mengelola dan mengimplementasikan jaringan, terutama untuk mendukung kebutuhan
dan inovasi di bidang ini yg semakin lama semakin kompleks. Konsep dasar SDN adalah dengan
melakukan pemisahan eksplisit antara control dan forwarding plane, serta kemudian melakukan
abstraksi sistem dan mengisolasi kompleksitas yg ada pada komponen atau sub-sistem dengan
mendefinisikan interface yang standar. Beberapa aspek penting dari SDN adalah :
a. Adanya pemisahan secara fisik/eksplisit antara forwarding/data-plane dan control-plane.
b. Antarmuka standard untuk memprogram perangkat jaringan.
7
c. Control-plane yang terpusat atau adanya sistem operasi jaringan yang mampu membentuk
peta logika dari seluruh jaringan dan kemudian memrepresentasikannya melalui sejenis
API (Application Programming Interface).
d. Virtualisasi, yang dilakukan agar beberapa sistem operasi jaringan dapat mengkontrol
bagian-bagian dari perangkat yang sama.
Di dalam arsitektur SDN, control plane dipisahkan dari data plane, network intelligence dan
network state dipusatkan secara logic, dan infrastruktur jaringan dipisahkan dari aplikasi.
Hasilnya, perusahaan dan operator bisa memperoleh programabilitas, otomatisasi, dan kendali
pada jaringan yang belum pernah ada sebelumnya sehingga memungkinkan mereka untuk
membuat jaringan yang bisa diperluas dengan mudah dan fleksibel yang siap untuk beradaptasi
sesuai dengan kebutuhan bisnis.
Tujuan dari SDN adalah untuk menyediakan antarmuka terbuka yang dapat mendukung
pengembangan software yang dapat mengendalikan konektivitas suatu network resources dan
aliran dari traffic jaringan yang melaluinya, bersamaan dengan inspeksi dan modifikasi traffic
yang mungkin dapat diterapkan pada jaringan. Pada layer terbawah, data plane terdiri dari
network element yang kemampuannya dimanfaatkan oleh SDN Datapath melalui Control-Data-
Plane interface(CDPI). Pada layer teratas, application plane mencakup berbagai macam SDN
application yang saling bertukar informasi tentang requirement masing-masing melalui
NorthBound interface(NBI) Drivers. Pada layer di tengah, SDN Controller menerjemahkan
kebutuhan dari layer atasnya dan mengirimkan low-level control melalui SDN Datapath sambil
memberikan informasi yang relevan kepada SDN applications.
Management dan Admin Plane bertanggung jawab untuk menyiapkan network elements,
menetukan SDN Datapath pada SDN Controller, dan melakukan konfigurasi policy yang
mendefinisikan ruang lingkup kendali yang diberikan kepada SDN controller atau SDN
application. Arsitektur jaringan SDN ini dapat dijalankan berdampingan dengan jaringan non-
SDN, khususnya untuk tujuan migrasi ke jaringan SDN secara keseluruhan.
8
Gambar II-2 BreakdownArsitektur SDN[3]
Control Plane diimplementasikan sebagai suatu perangkat server yang diatasnya diinstall sistem
operasi jaringan dan diatasnya lagi dijalankan aplikasi jaringan, data plane diimplementasikan
dalam bentuk infrastruktur jaringan. Melalui controller SDN ini seorang administrator jaringan
dapat melakukan administrasi jaringan secara terpusat.
Berikut adalah istilah-istilah penting dalam SDN yang harus dipahami
e. SDN application
SDN application adalah program yang dibuat diatas sebuah controller dan melakukan
komunikasi dengan controller melalui Northbound Interface (NBI).
f. SDN controller
SDN controller adalah suatu sistem terpusat yang berfungsi sebagai pengontrol jaringan
secara terpusat, dan menterjemahkan perintah dari aplikasi jaringan ke data plane.
g. SDN datapath
SDN datapath adalah perangkat jaringan yang bisa berupa fisik maupun virtual yang bekerja
mengontrol forwarding dan memproses paket data berdasarkan aturan yang telah ditetapkan
oleh controller.
9
h. SDN Control to Data-Plane Interface (CDPI)
SDN CDPI adalah interface antara SDN controller dengan SDN datapath yang
menyediakan kontrol yang terprogram untuk seluruh operasi dalam forwarding packet data,
melakukan advertisement rute, pelaporan statistik dari interface dan notifikasi.
i. SDN Northbound Interfaces (NBI)
SDN NBI adalah interface antara SDN application layer dengan SDN controller.
j. Interface Drivers & Agents
Setiap agents dan drivers berfungsi sebagai jembatan yang menghubungkan komunikasi
antara Northern Bridge (Application Plane dengan Control Plane) dan Southern Bridge
(Control Plane dengan Data Plane).
II.3 Protokol OpenFlow
OpenFlow merupakan sebuah protokol yang menjadi salah satu bagian dari SDN. OpenFlow
adalah sebuah protokol SDN yang memungkinkan seorang network administrator dapat mengatur
jalur pengiriman paket data didalam sebuah switch. Jaringan konvensional yang kita kenal yaitu
jaringan non-OpenFow, setiap switch hanya berfungsi meneruskan paket data melalui standar kerja
yang berdasarkan Network Layer. OpenFlow bersifat terbuka, sehingga bisa diadaptasi oleh semua
kalangan, baik peneliti maupun vendor. Para peneliti membuat banyak penelitian terkait
OpenFlow, sementara vendor banyak mengadaptasi OpenFlow untuk diterapkan pada perangkat
komersial yang diproduksinya. OpenFlow adalah sebuah antarmuka terbuka untuk mengontrol
forwarding table secara remote pada perangkat jaringan. Secara lebih terperinci berikut adalah
nilai tambah dari keberadaan OpenFLow.
 Kontrol terpusat dan dapat dijalankan pada berbagai macam perangkat I: switch, router,
wireless access point, baik yang bersifat fisik maupun virtual
 Mengurangi kompleksitas manajemen jaringan komputer dengan menghadirkan
penyederhanaan manajemen jaringan secara terpusat. Dengan adanya protokol OpenFLow
juga, memungkinkan adanya konfigurasi dan kebijakan yang terpusat yang akan
diterjemahkan ke infrastruktur dibawahnya. Konfigurasi yang harus dibuat oleh
administrator juga akan berkurang, jika dalam jaringan tradisional, konfigurasi harus
10
dilakukan untuk setiap perangkat jaringan sampai ke titik akhir layanan, maka dalam
jaringan berbasis SDN hal ini tidak perlu lagi dilakukan.
 Meningkatkan inovasi dalam teknologi jaringan komputer, karena sifat jaringan yang
menjadi terbuka dan bisa diprogram, sehingga banyak pihak bisa terlibat untuk ikut turut
serta mengembangkan teknologi jaringan komputer.
 Keberadaan OpenFLow membuat pengaturan jaringan bisa dilakukan lebih rinci dan
terpusat.
 User experience yang lebih baik: Dengan kontrol jaringan yang terpusat, infrastruktur
jaringan SDN dapat dengan mudah beradaptasi terhadap kondisi jaringan secara dinamis.
Misalnya pada layanan video streaming prioritas akan bisa diberkan secara langsung pada
seorang pelanggan jaringan yang memiliki prioritas lebih tinggi.
Versi protokol OpenFlow yang sekarang sedang dikembangkan adalah versi 1.5 dan versi 1.4
sudah dinyatakan sebagai versi yang matang, dengan diadaptasinya versi tersebut oleh beberapa
vendor yang memproduksi perangkat jaringan yang bisa menjalankan OpenFlow. Berikut adalah
tabel yang menjelaskan perkembangan fitur dari versi ke versi.
Tabel II-1 Versioning OpenFlow
Elemen SDN Perubahan spesifikasi kemampuan Switch OFP Versi OFP
Pemisahan control plane Cookies - pemberian policy identifier ke flow entries 1.0
Vacancy events - mengontrol table resource policy 1.4
Delegasi flow learning kepada switch 1.5
Pemusatan controller Mekanisme pemilihan controller (multi-controller) 1.2
Event filtering (multi-controller) 1.3
Bundles – menjalankan satu set requests bersama 1.4
Flow monitoring (multi-controller) 1.4
Northbound API Per port priority queues – per application QoS 1.0
Per flow meters – per application QoS 1.3
Tunnel-id field – mendukung overlay logical ports 1.3
Kemampuan untuk Groups – guna ulang flow actions 1.1
diprogram Extensible fields untuk matching dan rewriting headers 1.2
Table features (ekstensi) 1.3
Flow entries Multiple tables flow entries 1.1
Egress tables – output processing menggunakan flow entries 1.5
Encapsulation action – tunnelling menggunakan flow entries 1.5
11
II.4 Format Header OpenFlow
Berikut adalah format header dari protokol OpenFlow.
Switch MAC MAC Eth VLAN IP IP IP Port Port

port Src Dst Type ID Src Dst Proto Src Dst
Gambar II-3 Header OpenFlow
Tabel berikut berisi penjelasan mengenai isi dari Header OpenFLow.
Tabel II-2 Penjelasan Header OpenFlow
Field Bits Diterapkan pada Keterangan
Inggress Port Tergantung Semua paket Penomoran paket yang datang dari port,
Implementasi mulai dari 1
Dst MAC Semua paket yang

diaktifkan
Src MAC Semua paket yang

diaktifkan
Ethernet Type Semudiaktifkana paket Openflow switch yang membutuhkan standar

yang tipe dari Ethernet dan standar 802.2
Vlan ID Semua paket dengan tipe

ethernet 0x8100
Vlan Priority Semua paket dengan tipe VLAN PCP field

ethernet 0x8100
Dst IP Semua IP dan Paket ARP Bisa dengan subnet mask
Src IP Semua IP dan Paket ARP Bisa dengan subnet mask
IP Protocol Semua IP dan IP over Hanya ARP dengan bit kurang dari 8 yang
ethernet, paket ARP bisa menggunakannya
IP ToS Semua paket IP Menentukan nilai 8 bit yang digunakan dan
ditetapkan di ToS
TCP/UDP Src Semua TCP, UDP, ICMP

Port
TCP/UDP dst Semua TCP, UDP, ICMP
Port
12
II.5 Cara Kerja OpenFlow
Rule Action Stats
Packet + Byte Counters
 Forward Paket ke port atau banyak port

 Enkapsulasi dan forward ke controller
 Drop paket
 Kirim ke normal pipeline processing
Switch MAC MAC Eth VLAN IP IP IP Port Port

port Src Dst Type ID Src Dst Proto Src Dst
Gambar II-4 Cara Kerja OpenFlow
Gambar II-5 Diagram Switch OpenFlow
13
Secara sederhana cara kerja dari protokol OpenFlow dapat dijelaskan dengan diagram berikut.
Gambar II-6 Flow Paket Data Di dalam OpenFlow 1.0[5]
Setiap paket data yang masuk (packet in) akan diproses dengan cara melakukan parsing terhadap
header paket data tersebut dan flow table yang ada di data plane switch. Jika adanya kecocokan
data header dengan data yang ada di flow table maka paket data akan langsung diteruskan ke
tujuan. Proses pencocokan forwarding table dan header dilakukan secara recursive berdasarkan
atas prioritas yang telah di atur. Jika tidak ada kecocokan antara tabel forwarding plane dengan
data header packet data maka data dari header akan diteruskan langsung ke controller melalui
protokol OpenFlow. Selanjutnya controller akan melihat header dari paket data tersebut dan
dicocokan dengan rule yang ada, jika ada rule yang sesuai maka controller akan mengirimkan
informasi flow ke switch untuk dimasukan ke dalam flow table.
Detail flowchart openflow v1.0 pengolahan pencocokan paket data di header fields
a. Paket yang masuk (Packet In) dianalisa mulai dari tipe paket data ethernet.
0x8100 merupakan paket data pada interface VLAN, 0x0806 merupakan paket data pada
ARP Request. 0x0800 merupakan paket data pada protokol IP
b. Bila :
i. Ethernet Type menunjukan 0x8100 maka header field yang akan diproses adalah VLAN
ID dan PCP
14
ii. Ethernet Type menunjukan 0x0806 maka header field yang akan diproses adalah IP
Source dan IP Destination
iii. Ethernet Type menunjukan 0x0800 maka header field yang akan diproses Transport
Layer (TCP, UDP, ICMP). Untuk IP protokol yang menunjukan 1, maka akan diproses
sebagai ICMP type dan code pada field Layer 4. Untuk IP protokol yang menunjukan 6
atau 17 maka akan diproses menggunakan TCP/UDP source dan destination pada
field Layer 4.
II.6 Reactive dan Proactive Flow
II.6.1 Reactive Flow
Reactive flow adalah sebuah situasi ketika sebuah flow baru datang kedalam sebuah perangkat
switch. Dalam situasi ini switch akan melihat ke dalam flowtable, jika field yang ada tidak ada
yang cocok dengan header paket data, maka switch akan mengirimkan sebuah (OpenFLow
packet)OFP kepada controller, kemudian controller akan menginstruksikan FlowMod kepada
switch untuk menciptakan sebuah baris flow baru pada switch.
Gambar II-7 Mekanisme Reactive Flow[7]
15
II.6.2 Proactive Flow
Proactive flow berbalik dengan tipe reactive flow, dalam tipe ini seluruh hasil kalkulasi rute di sisi
controller akan langsung dikirimkan kepada switch, dan akan diinstal dalam bentuk flow table.
Dalam mode ini sistem pencarian hanya akan dilakukan disisi flow table switch yang ada dalam
TCAM(Ternary Content Addressable Memory) dengan hanya menggunakan tabel yang ada di
switch akan mengurangi latency yang disebabkan oleh adanya komunikasi protokol OpenFlow
untuk setiap flow yang ada.
Gambar II-8 Mekanisme Proactive Flow[7]
II.7 Jaringan Virtual SDN
Virtualisasi jaringan telah banyak menjadi topik riset di dalam komunitas peneliti. Dengan adanya
teknologi virtualisasi jaringan, memungkinkan adanya sejumlah jaringan yang bersifat logic yang
saling terisolasi satu sama lain, yang masing-masing boleh memiliki pengalamatan yang berbeda,
mekanisme forwarding yang berbeda, yang kesemuanya menggunakan infrastruktur jaringan fisik
yang sama. Umumnya virtualisasi ini dilakukan dengan bantuan software atau dengan komponen
fisik jaringan yang khusus.
16
Untuk bisa lebih memahami virtualiasi jaringan SDN, kita harus melihat dengan lebih dekat
virtualisasi komputer. Dalam virtualisasi komputer, sebuah lapisan abstaksi dijalankan diantara
guest OS dan hardware untuk menghadirkan slicing dan sharing sumber daya antar guest OS yang
ada. setiap guest OS akan melihat bahwa masing-masing memiliki hardware sendiri-sendiri yang
terpisah.
Hal yang sama juga bisa dilakukan untuk jaringan. Maka dengan cara berpikir yang sama, jaringan
harus mempunyai satu buah lapisan abstraksi. Lapisan ini harus bisa membagi resource fisik
jaringan berupa: link, port, switch maupun resource logicnya: link b/w, cpu switch kedalam
beberapa tenant, dimana masing-masing tenant akan melihat bahwa dirinya memiliki resource
hardware jaringan sendiri.
Perangkat yang sekarang dideploy di jaringan komputer tradisional tidak dirancang untuk
kebutuhan virtualisasi, dan tidak memiliki lapisan abstraksi hardware. Teknologi yang dijalankan
sekarang ini cenderung hanya membagi resource hardware tertentu saja. contoh: MPLS
memvirtualkan forwarding table, WDM membagi layer fisik. VLAN membagi datalink layer
ataupun dengan cara enkapsulasi layer. Tidak ada suatu teknologi tunggal yang secara penuh bisa
mengabstraksikan jaringan secara penuh. Sebelum adanya SDN. Selain hal diatas, keistimewaan
dari jaringan virtual SDN adalah kemampuan untuk mengimplementasikan network function
virtualization untuk layanan tambahan bagi para tenant yang menyewa jaringan virtual dari
operator. Dengan adanya NVF implementasi layanan jaringan akan lebih mudah
diimplementasikan dan dikelola.
Gambar II-9 Server dan Network Hypervisor[9]
17
II.8 MPLS
Multiprotocol Label Switching (MPLS) yaitu adalah teknologi penyampaian paket pada jaringan
backbone berkecepatan tinggi. Asas kerjanya menggabungkan beberapa kelebihan dari sistem
komunikasi circuit-switched dan packet-switched yang melahirkan teknologi yang lebih baik dari
keduanya. Sebelumnya, paket-paket diteruskan dengan protokol routing seperti OSPF, IS-IS,
BGP, atau EGP. Protokol routing berada pada layer network dalam model OSI, sedangkan MPLS
berada di antara lapisan kedua dan ketiga.
Prinsip kerja MPLS ialah menggabungkan kecepatan switching pada layer 2 dengan kemampuan
routing dan skalabilitas pada layer 3. Cara kerjanya adalah dengan menyelipkan label di antara
header layer 2 dan layer 3 pada paket yang diteruskan. Label dihasilkan oleh label-switching router
dimana bertindak sebagai penghubung jaringan MPLS dengan jaringan luar. Label berisi informasi
tujuan node selanjutnya kemana paket harus dikirim. Kemudian paket diteruskan ke node
berikutnya, di node ini label paket akan dilepas dan diberi label yang baru yang berisi tujuan
berikutnya. Paket-paket diteruskan dalam path yang disebut LSP (Label Switching Path).
Komponen MPLS :
a. Label Switched Path (LSP): Merupakan jalur yang melalui satu atau serangkaian LSR
dimana paket diteruskan oleh label swapping dari satu MPLS node ke MPLS node yang
lain.
b. Label Switching Router: MPLS node yang mampu meneruskan paket-paket layer-3.
c. MPLS Edge Node atau Label Edge Router (LER): MPLS node yang menghubungkan
sebuah MPLS domain dengan node yang berada di luar MPLS domain.
d. MPLS Egress Node: MPLS node yang mengatur traffic saat meninggalkan MPLS domain.
e. MPLS ingress Node: MPLS node yang mengatur trafik saat akan memasuki MPLS domain.
f. MPLS label: merupakan label yang ditempatkan sebagai MPLS header.
g. MPLS node: node yang menjalankan MPLS. MPLS node ini sebagai control protocol yang
akan meneruskan paket berdasarkan label.
Data plane disebut juga sebagai forwarding yang bekerja untuk proses pengiriman paket,
pemberian label, enkapsulasi, dekapsulasi pada jaringan.Control Plane bekerja untuk memastikan
pembentukan serta pertukaran informasi label. Antara control plane dan data plane memiliki
tugas dan tanggung jawab saling terpisah, akan tetapi keduanya saling berhubungaan.
18
Data plane dalam menjalankan tugasnya untuk proses forwarding berpedoman pada informasi
yang disediakan oleh LSR (Label Switching Router).
Control Plane bertugas mengatur semua informasi mengenai penomoran label pada setiap
router, bagaimana paket MPLS itu dikirimkan antar router pada jaringan MPLS.Jika
dibandingkan dengan data plane, control plane memiliki proses yang lebih kompleks karena
control plane bisa dianalogikan sebagai otak dari router yang mengatur seluruh aktivitas data
plane. Informasi-informasi yang diatur oleh control plane berupa IP/MPLS databases yang
digunakan untuk membentuk jaringan MPLS.
II.9 VPN
VPN adalah singkatan dari “Virtual Private Network”, merupakan suatu koneksi antara satu
jaringan dengan jaringan lain secara privat melalui jaringan Internet (publik). Disebut dengan
Virtual Network karena VPN menggunakan jaringan Internet sebagai media perantaranya alias
koneksinya bukan secara langsung. Dan disebut Private Network karena VPN sifatnya privat yaitu
hanya orang tertentu saja yang dapat mengaksesnya. VPN dapat digunakan pada jaringan eksisting
seperti internet untuk memfasilitasi transfer data secara privat, transfer data privat ini dilakukan
dengan alasan keamanan. Solusi menggunakan jaringan public untuk melakukan transfer data yang
sensitive dilakukan dengan alasan ekonomis, jauh lebih murah menggunakan jaringan public jika
dibandingkan dengan menyewa sambungan tersendiri yaitu leased line dari perusahaan
telekomunikasi. VPN menggunakan jaringan public juga menyediakan solusi untuk menyediakan
keamanan komunikasi data antar kantor suatu perusahaan yang memiliki site yang berbeda.
Terdapat tiga model arsitektur VPN yaitu:
a. Host-to-host: Model ini digunakan untuk mengamankan komunikasi antara dua buah
komputer.
b. Host-to-gateway: Model ini digunakan untuk mengamankan komunikasi antara satu atau
lebih host untuk terhubung secara aman ke jaringan internal milik organisasi. Contoh
paling mudah dari tipe ini adalah layanan VPN yang dibuat di ITB.
c. Site-to-site: Model ini digunakan untuk menjalankan komunikasi privat antar dua jaringan.
Misalkan jaringan pada kantor pusat dan kantor cabang yang terhubung.
19
Jenis VPN yang erat kaitannya dengan penelitian yang dilakukan oleh penulis yaitu VPN yang
dibuat dengan mengimplementasikan MPLS VPN. MPLS VPN bekerja pada layer 2 dan layer 3
model OSI, MPLS VPN membuat virtual leased line pada jaringan milik operator. Cara-cara lain
yang digunakan untuk mengimplementasikan VPN yaitu:
a. L2TP adalah standar IETF untuk pengamanan komunikasi antara client dan server. L2TP
bekerja pada lapisan datalink model OSI dengan mengenkapsulasi traffic menggunakan point
to point protocol(PPP) yang ditransmisikan menggunakan tunnel L2TP.
b. PPTP dikembangkan oleh perusahaan Microsoft, cara kerjanya mirip dengan L2TP namun
menggunakan tunneling Generic Routing Encapsulation (GRE) untuk mentransmisikan
traffic PPP.
c. L2F dikembangkan oleh perusahaan perangkat jaringan Cisco. L2F bekerja seperti protol
L2TP namun tunneling yang digunakannya adalah L2F untuk mentransmisikan traffic PPP.
d. IPsec yang bekerja pada merupakan suatu framework penerapan saluran aman yang dibuat
oleh IETF, IPsec bekerja pada layer 3 OSI. IPsec mengamankan dan melakukan autentikasi
tiap paket IP yang ditransmisikan antara perangkat yang menjalankan IPsec.
e. SSL bekerja pada layer 4 OSI dan melakukan pengamanan komunikasi dengan melakukan
enkripsi pada layer transport, salah satu penggunaan yang paling popular di ITB adalah
sebagai protokol yang digunakan untuk menjalankan layanan VPN host-to-gateway.
Pemilihan implementasi VPN tipe ini adalah karena protokol SSL rata-rata di allow oleh
firewall milik organisasi, sehingga bisa mengurangi restriksi.
20
Host Tenant 1.1 CE Tenant 1.1 CE Tenant 1.2 Host Tenant 1.2
CE Tenant 2.2 Host Tenant 2.2
Host Tenant 2.1 CE Tenant 2.1
Operator Network
Gambar II-10 VPN pada Jaringan Operator
II.10 OpenVirtex
Keberadaan teknologi virtualisasi jaringan membuat lebih dari satu tenant bisa mempergunakan
infrastruktur jaringan fisik yang sama, seakan-akan, masing-masing tenant tersebut
mempergunakan jaringan komputer miliknya sendiri. OVX menghadirkan teknologi virtualisasi
ini dengan cara melakukan virtualisasi terhadap topologi fisik jaringan dan memberikan
pengalamatan IP address secara penuh, seakan-akan IP address tersebut dimiliki oleh tenant
tersebut. Tenant bisa meminta bentuk topologi virtual yang diperlukannya kepada penyedia
layanan jaringan, termasuk IP address space yang diinginkannya, tanpa terpengaruh dengan IP
address space milik tenant yang lainnya. Isolasi penuh dalam sistem virtualisasi yang ditawarkan
oleh OVX menjadikan overlapping IP Address space antar tenant bukan masalah lagi.
Virtualisasi jaringan berbeda dengan konsep network slicing yang ditawarkan oleh solusi-solusi
seperti FlowVisor. Dalam terminologi network slicing sebuah jaringan diiris menjadi beberapa
bagian dengan memanfaatkan satu IP address space yang sama dan bahkan port TCP/UDP yang
sama, masalah yang akan muncul tentu saja bandwidth yang akan terbagi antar tenant. Dalam
konsep virtualisasi, sebuah jaringan virtual milik tenant tidak harus merupakan subgraph
isomorphic dari jaringan fisik, namun untuk konsep network slicing, hal ini adalah sebuah
keharusan.
21
OVX mengimplementasikan virtualisasi dengan cara membuat sebuah proxy yang ada diantara
jaringan fisik dan network controller milik tenant, OVX melakukan rewrite terhadap OpenFlow
messages untuk ditranslasikan antara network controller milik tenant yang mengirimkan pesan
dan pesan OpenFlow messages yang berasal dari virtual network milik tenant.
Gambar II-11 Arsitektur Besar OpenVirtex[11]
II.10.1 Virtualisasi Alamat IP
OVX menghindari address space collision antara aliran traffic tenant dengan menciptakan OVX
IP address yang bersifat virtual dan physical IP address yang bersifat fisik untuk setiap host. Yang
disebutkan pertama bersifat unik dalam satu virtual OVX network dan yang selanjutnya disebutkan
bersifat unik dalam seluruh physical network seluruhnya. Translasi antara IP address virtual dan
fisik menjamin bahwa setiap controller milik tenant bisa menangani flow milik sendiri
berdasarkan alamat tersebut, dan datapath bisa membedakan traffic milik tenant yang berbeda-
beda.
Translasi alamat memisahkan datapath kedalam dua kelompok yaitu:
a. Edge: datapath yang merupakan host attachment point.
b. Core: datapath yang hanya mengkoneksikan ke datapath lainnya.
22
c. Datapath edge bertugas untuk melakukan fungsi rewriting IP address.
d. Match pada OVX IP address pada field nw_src dan nw_dst, lalu melakukan rewriting ke
physical IP address, untuk traffic network-bound(dari arah host).
e. Match pada physical IP address, rewriting physical IP address ke OVX IP address, untuk
traffic host-bound traffic(ke arah host). Gambar berikut memperlihatkan fungsi translasi ip
address dan tabel selanjutnya menunjukan berbagai macam FlowMods yang mungkin yang
dihasilkan oleh controller milik tenant ke OVX dan dari OVX ke datapath(switch fisik).
Gambar II-12 Interaksi OpenVirtex dengan Controller dan Switch[11]
f. Packet In dikirimkan dari virtual switch milik tenant ke ke controller milik tenant tanpa
modifikasi. Isi dari PacketIn adalah OVX IP address.
g. FlowMod balasan dari controller milik tenant menginstruksikan patern matching pada OVX
IP dan melakukan rewrite OVX IP ke physical IP.
h. Virtual link dipetakan kembali ke path dua hop yang melewati PSW2
i. OVX menjalankan FlowMods pada physical IP dan melakukan rewrite ke OVX IP
23
II.10.2 Virtualisasi Link dan Route
Gambar II-13 Modifikasi Flow oleh OpenVirtex[11]
OVX merepresentasikan koneksi antara switch dan switch yang masing-masing dengan
menggunakan port tersendiri, dengan menggunakan links. Links didefinisikan sebagai dua buah
endpoints, yaitu pasangan dari source dan destination switch/ports. Links bersifat bidirectional.
Gambar berikut akan menjelaskan struktur dan hubungan antara tiga tipe links yang ada.
24
Gambar II-14 Skema Link pada OpenVirtex[11]
a. Bentuk awal, dimana dua link fisik menghubungkan port fisik(lingkaran putih) pada tiga
switch fisik.(ps1, ps2 dan ps3).
b. Virtual link OVX menghubungkan dua buah switch virtual OVX(vs1, vs2) melalui dua buah
port virtual OVX(lingkaran hitam). Dua buah link fisik antara ps1,ps2 dan ps3 sekarang di
mapping ke satu buah link virtual OVX yang menghubungkan switch virtual vs1 dan vs2.
c. Satu buah bigswitch OVX memiliki dua buah link fisik antara ps1,ps2 dan ps3 dan memiliki
dua buah port virtual.
Gambar II-15 Skema Link Virtual pada OpenVirtex[11]
Pada gambar diatas, terdapat dua buah tenant. Pada bagian atas masing-masing gambar,
memperlihatkan jaringan virtual OVX milik masing-masing tenant. Dan pada gambar bagian
bawah terdapat gambaran dari jaringan fisik. Dari gambar diatas, bisa dilihat bahwa tenant 1
25
memiliki dua buah virtual link yaitu vlink1 dan vlink2 yang masing-masing dipetakan ke link fisik
sebagai berikut: vlink1: l2 dan l3 dan vlink2: l5. tenant 2 memiliki dua buah virtual link juga yaitu
vlink1 dan vlink2, yang masing-masing dipetakan ke link fisik sebagai berikut: vlink1: l1 vlink2:
l4, dan untuk bigswitch vs2 didalamnya terdapat link fisik yang menghubungkan ps2 dan ps3 yaitu
l3 yang diberi warna biru.
II.11 FlowVisor
FlowVisor berada di antara hardware fisik dan software yang mengontrolnya. Seperti sistem
operasi yang menggunakan instruction set untuk mengontrol underlying hardware, FlowVisor
menggunakan protokol OpenFlow untuk mengontrol underlying physical network. FlowVisor
menghosting beberapa guest OpenFlow controller, satu controller mengontrol satu slice.
FlowVisor bisa dilihat sebagai Proxy untuk protokol OpenFlow antara controller dan hardware
switch. FlowVisor menggunakan protokol OpenFlow untuk sistem komunikasi antara hardware
jaringan dan dirinya serta antara dirinya dan pengontrol yang masing-masing akan berinteraksi
dengan jaringan yang di virtualkan.
II.11.1 Virtualisasi Jaringan
Untuk dapat melakukan virtualisasi jaringan, kita perlu mengetahui resource apa saja yang bisa
dibagi.
a. Flow traffic
Suatu jaringan virtual bisa dibuat tidak hanya berdasarkan suatu kebutuhan topologi tertentu
saja, tapi bisa juga berdasarkan jenis traffic yang berjalan berdasarkan identitas
layer2(komunikasi host tertentu), layer3(komunikasi subnet tertentu) ataupun
layer4(komunikasi aplikasi tertentu)
b. Bandwidth
Tiap jaringan virtual bisa diberikan sejumlah bandwidth tertentu untuk suatu link virtual
yang dimilikinya. Ada dua pengertian dari slicing bandwidth disini, yang pertama adalah
slicing bandwidth sebagai fungsi turunan dari slicing topologi. Dalam pengertian ini,
26
topologi dibagi berdasarkan saluran, dan contoller akan mengatur siapa-siapa saja yang bisa
melewati slice berdasarkan kebutuhan bandwidth.
Gambar II-16 Slicing Topologi dengan Flowvisor[9]
c. Topologi
Tiap jaringan virtual memiliki suatu topologi sendiri berdasarkan topologi fisik(switch dan port).
d. CPU
27
Tiap jaringan virtual bisa mendefinisikan prosentase resource switch yang bisa digunakannya.
Fitur ini masih bersifat pengembangan dan mengandalkan juga pengembangan yang dilakukan
oleh pihak vendor perangkat keras switch, fitur dasar yang diperlukan oleh perangkat keras adalah
rate limiters, untuk membatasi rate komunikasi OFP suatu tenant tertentu dan process schedulling
untuk menjadwalkan proses untuk menangani event-event seperti:
 New flow message: ketika suatu paket datang dan tidak ada flow entry yang match di flow
table maka switch akan mengirim flow message ke controller untuk meminta entry baru di flow
table.
 Controller request: OpenFlow controller mengirim pesan ke switch untuk mengubah entry
flow table ataupun melakukan query statistik.
II.11.2 Forwarding Table
Untuk virtualisasi dari jaringan OpenFlow SDN dan isolasi flow, network virtualization layer yang
disebut FlowVisor di jalankan diantara controller OpenFlow dan perangkat fisik jaringan.
FlowVisor bekerja sebagai proxy controller untuk perangkat fisik jaringan. FlowVisor telah
diadaptasi secara luas karena kesederhanaan dan kemudahan untuk digunakan, namun FlowVisor
memiliki beberapa kelemahan Yaitu:
a. Overhead proses, karena pesan kontrol yang dienkapsulasi dan di dekapsulasi dua kali.
b. Implementasi FlowVisor yang bisa menggunakan protokol OpenFlow versi 1.0
II.11. 3 Arsitektur FlowVisor
Seperti lapisan virtualisasi dalam sebuah komputer. FlowVisor berada diantara hardware fisik
dan software yang mengontrolnya. Seperti sistem operasi yang menggunakan instruction set untuk
mengontrol underlying hardware, FlowVisor menggunakan protokol OpenFlow untuk mengontrol
underlying physical network. FlowVisor menghosting beberapa guest OpenFlow controller, satu
controller mengontrol satu slice. FlowVisor bisa dilihat sebagai proxy untuk protokol OpenFLow
antara controller dan hardware switch.
a. Slice:Adalah istilah lain untuk satu jaringan virtual yang didefinisikan oleh FlowVisor, satu
slice berisi satu set flowspace
28
b. FlowSpace:Berisi serangkaian regular expresion yang mendefinisikan kategori flow yang
masuk kedalam suatu kategori slice. Misalkan: slice-http: berisi flowspace yang
mendefinisikan aturan port 80 dan port 443 yang masing-masing akan dikontrol trafficnya
oleh suatu controller tersendiri. Slice-tenant1, berisi flowspace yang mendefinisikan port-
port dan switch yang masuk kedalam suatu jaringan virtual milik tenant.
c. Pengaturan routing FlowVisor: harus dilakukan secara static, berdasarkan port_in, buatlah
actionnya berdasarkan port_out
d. Versi OpenFlow yang didukung oleh FlowVisor adalah versi 1.0 dan versi sesudahnya tidak
dikenali.
29
Bab III
METODOLOGI PENELITIAN dan DESAIN PERCOBAAN
Sebelum melakukan analisis fungsionalitas dan kinerja teknologi virtualisasi berbasis SDN
sebagai solusi virtualisasi berbasis SDN terlebih dahulu perlu ada suatu desain sistem, desain
topologi jaringan pemilihan perangkat keras, pemilihan perangkat lunak. Desain topologi dibuat
dengan mempertimbangkan ketersediaan sumber daya perangkat keras namun tetap mengacu
kepada topologi real jaringan milik penyedia jaringan dan konektivitasnya dengan jaringan milik
tenant.
Perangkat keras dipilih berdasarkan ketersediaan di lab, dengan mempertimbangkan kebutuhan

minimal fungsi perangkat lunak yang akan dipakai dan juga desain topologi yang akan
diimplementasikan didalam percobaan. Pemilihan perangkat lunak dilakukan berdasarkan fungsi-
fungsi yang diperlukan, kompatibilitas dengan perangkat lunak yang lain serta sistem operasi,
selain itu pemilihan versi perangkat lunak juga dilakukan atas dasar kestabilan dari perangkat
lunak terkait.
III.1 Metodologi Penelitian
Dalam penyusunan dan penulisan tesis ini menggunakan beberapa metodologi, yaitu sebagai
berikut:
Pembuatan
analisis
Perancangan
dan
Menetapkan implementasi
tujian riset percobaan
Identifikasi
permasalahan
Studi
literatur:
Gambar III-1 Metodologi Penelitian
30
III.1.1 Studi Literatur
Studi literatur dilakukan untuk mendapatkan berbagai macam sumber yang terdiri dari konsep,
implementasi, pengujian, serta aspek non teknis berkaitan dengan kontribusi apa yang bisa
diberikan oleh penulis dalam penelitian. Selain itu studi literatur dilakukan untuk mendapatkan
kondisi nyata kebutuhan akan solusi virtualisasi berbasis SDN. Penulis melakukan studi literatur,
dari berbagai sumber: ebook, jurnal, internet, diskusi dan sumber lainnya yang memiliki
keterkaitan dengan virtualisasi pada software defined networking(SDN). Dari hasil studi literatur
didapatkan informasi sebagai pedoman untuk menerapkan teknologi virtualisasi berbasis SDN di
lingkungan testbed.
III.1.2 Mengidentifikasi Permasalahan
Dalam tahap mengidentifikasi permasalahan dilakukan pencarian terhadap permasalahan yang ada
kemudian diangkat sebagai topik dari penelitian. Berdasarkan studi literatur yang sudah dilakukan
terdapat permasalahan yang bisa diangkat dalam penelitian ini, khususnya permasalahan mengenai
peranan OpenFlow dalam penerapanan virtualisasi di jaringan berbasis SDN. Ada cukup banyak
solusi virtualisasi berbasis SDN yang diujicoba di level lab, namun ada satu buah solusi yang
banyak digunakan pada banyak testbed yaitu FlowVisor, dan ada satu buah solusi lain yang
dianggap sebagai pengganti dari FlowVisor yaitu OpenVirtex yang digadang-gadang memiliki
fitur dan performa yang lebih baik. Hal ini memunculkan juga pertanyaan bisakah solusi
virtualisasi SDN ini dipakai sebagai teknologi untuk layanan VPN.
III.1.3 Menentukan Tujuan
Setelah mengidentifikasikan permasalahan, langkah selanjutnya dalah menentukan tujuan dari

penelitian dan penyusunan tesis ini agar penelitian tesis tetap fokus dalam menjawab permasalahan
yang sudah diidentifikasi pada tahap sebelumnya. Tujuan dari penelitian ini adalah perancangan
dan implementasi testbed untuk menjalankan virtualisasi jaringan SDN multi tenant, untuk
menentukan kapabilitas, kelebihan dan kekurangan dari solusi virtualisasi FlowVisor dan
OpenVirtex.
31
III.1.4 Perancangan dan Implementasi
Pada tahap ini dilakukan perancangan dan implementasi dari testbed yang akan dibangun.
Perancangan testbed dibuat sesederhana mungkin mengikuti ketersediaan sumber daya perangkat
keras namun menyerupai topologi yang sesungguhnya dari layanan jaringan virtual yang
dijalankan oleh operator, sehingga dapat memberikan hasil yang valid dalam penelitian.
Perancangan dan implementasi dalam penelitian serta penyusunan tesis ini dilakukan dengan
beberapa tahap yaitu sebagai berikut:
a. Melakukan survei terhadap perangkat lunak yang akan diperlukan dalam implementasi
b. Melakukan pengujian terhadap perangkat lunak yang sudah ditentukan sebelum
mengimplementasikannya
c. Membuat rancangan dari topologi jaringan yang akan digunakan pada implementasi
d. Mengimplementasikan rancangan topologi menggunakan perangkat lunak yang sudah
ditentukan
e. Pengujian terhadap rancangan yang sudah dibuat.
III.1.5 Analisis dan Hasil Penelitian
Pada tahapan ini dilakukan analisis terhadap rancangan yang sudah diimplementasikan.Analisa
tersebut meliputi bagaimana kinerja dan fungsionalitas dari FlowVisor dan OpenVirtex untuk
mendukung layanan virtualisasi, apa kelebihan dan kekurangan keduanya, dan bagaimana
kesiapan solusi virtualisasi berbasis SDN untuk diterapkan dalam skala system produksi.
III.1.6 Penyusunan Tesis
Tahapan ini adalah tahapan terakhir dalam penelitain yaitu membuat laporan tesis. Pada
penyusunan laporan tesis harapannya adalah bisa seabgai keluaran untuk menjabarkan serta
menyampaikan topik penelitian di hadapan pembimbing serta penguji. Selain itu memberikan jalan
dan celah untuk mengembangkan penelitian selanjutnya.
32
Desain
percobaan
Desain
pada
topologi
testbed
Pemilihan jaringan
perangkat
lunak
Pemilihan
perangkat
keras
Gambar III-2 Implementasi Testbed
III.2 Kebutuhan Perangkat Keras
Pada penyusunan tesis ini dibutuhkan perangkat keras dan perangkat lunak untuk mensimulasikan
bagaimana teknologi virtualisasi diterapkan dengan dukungan protokol OpenFlow. Perangkat
keras yang dipergunakan dalam tesis ini menggunakan enam belas buah mesin server virtual.
terdiri dari enam jenis yaitu openflow controller dan openflow switch. Enam jenis ini mengikuti
kebutuhan dari lab testbed yang disesuaikan dengan situasi nyata. Perangkat keras yang
dipergunakan dalam tesis ini menggunakan dua buah mesin server yang dijadikan sebagai virtual
machine server untuk semua perangkat lab. Untuk menjalankan virtualisasi di masing-masing
server, aplikasi virtualisasi yang digunakan adalah VMware ESXi 5.0 untuk server fisik pertama
dan Virtual Box 4.3.16 untuk server fisik kedua. Server fisik kedua digunakan untuk meng-hosting
controller dan hypervisor sedangkan server fisik pertama digunakan untuk meng-hosting sisanya.
Tabel III-1 Spesifikasi Komponen server fisik
Nomor Komponen Spesifikasi

Server Fisik
1 CPU Xeon 3.10 GHz @ 4 Core
Memory 8 GB DDR3 Non-ECC
Hardisk 1 TB Sata
33
Network Interface Intel 1 GbE
Vendor Rainer
2 CPU I Core-5@ 2 Core
Memory 4 GB DDR3
Hardisk 1 TB Sata
Network Interface Intel 1 GbE
Vendor Intel
Adapun alasan penggunaan perangkat virtual dilakukan karena keterbatasan perangkat fisik yang
ada di lab, ketiadaan switch yang bisa menjalankan protokol OpenFlow dan juga keterbatasan
jumlah network interface card yang dimiliki oleh PC yang ada di Lab. Berikut adalah spesifikasi
dari seluruh komponen lab, berikut adalah spesifikasi server virtual yang digunakan.
Tabel III-2 Spesifikasi Komponen Logic Server Virtual
No Nama template virtual server CPU Memory Hardisk
1 OpenVswitch untuk P dan PE 2 core 1 GB 15 GB
2 OpenVirtex 2 core 1 GB 15 GB
3 Controller 2 core 1 GB 15 GB
4 CE 1 core 512 MB 15 GB
5 Host 1 core 256 MB 1 GB
III.3 Kebutuhan Perangkat Lunak
Ubuntu merupakan salah satu distro Linux yang berbasiskan sistem operasi Debian dan
didistribusikan sebagai perangkat lunak bebas. Ubuntu dirancang untuk kepentingan penggunaan
34
pribadi, namun versi server Ubuntu juga tersedia, dan telah dipakai secara luas. Proyek Ubuntu
resmi disponsori oleh Canonical Ltd. Tujuan dari distribusi Linux Ubuntu adalah membawa
semangat yang terkandung di dalam filosofi Ubuntu ke dalam dunia perangkat lunak. Ubuntu
adalah sistem operasilengkap berbasis Linux, tersedia secara bebas, dan mempunyai dukungan
baik yang berasal dari komunitas maupun tenaga ahli profesional.
JDK adalah Java yang dikembangkan oleh Oracle sedangkan OpenJDK adalah Java versi open
source yang dikembangkan oleh komunitas. Jika menggunakan distro linux, anda dapat memilih
menggunakan OpenJDK. JDK / OpenJDK berisi komponen yang digunakan untuk membuat
program, compile, dan menjalankan program Java. Didalam JDK terdapat JRE (Java Runtime
Environment), JRE ini yang dapat menjalankan program Java karena didalam JRE terdapat JVM
(Java Virtual Machine).
Tiny Core adalah salah satu varian Linux yang berkonsentrasi untuk memberikan kemampuan
Sistem Operasi dengan ukuran berkas sekecil mungkin. Tiny Core bisa didapat mulai dari versi
teks yang disebut Core, Tiny Core yang sudah punya Graphical User Interface atau Core Plus yang
disertai kemampuan deteksi perangkat keras WiFi dan aplikasi untuk remaster kumpulan extensi
yang diikutkan dalam penyebarannya.
Iperf adalah salah satu tool untuk mengukur troughput bandwidth dalam sebuah link network, agar
bisa dilakukan pengukuran diperlukan Iperf yang terinstall point-to-point, baik di sisi server
maupun client. Iperf sendiri bisa digunakan untuk mengukur performansi link dari sisi TCP
maupun UDP.
III.3.1 Software untuk Controller
Tabel III-3 Software untuk Controller
No Nama program Versi Fungsi dari program
1 Ubuntu 14.04 Sebagai sistem operasi
35
2 OpenJDK 1.7 Sebagai framework yang menjalankan program openflow controller
3 Floodlight 0.9 Sebagai program openflow controller
III.3.2 Software untuk Switch P dan PE
Tabel III-4 Software untuk Switch P dan PE
1 Linux Ubuntu 14.04 Sebagai sistem operasi
Sebagai virtual switch openflow yang mendukung hingga openflow

2 OpenvSwitch 2.3
versi 1.4
III.3.3 Software untuk Hypervisor
Tabel III-5 Software untuk HyperVisor
No Nama Program Versi Fungsi dari Program
Sebagai framework yang menjalankan program Network HyperVisor

2 OpenJDK 1.7
OpenVirtex
3 OpenVirtex 0.0-MAINT Network HyperVisor untuk virtualisasi
4 Python 2.7.6 Sebagai antarmuka OpenVirtex
5 Flowvisor 1.0.8 Network HyperVisor untuk virtualisasi
36
III.3.4 Software untuk Switch CE
Tabel III-6 Software untuk Switch CE
III.3.5 Software untuk Host
Tabel III-7 Software untuk Host
1 Linux Tiny core 6.4.1 Sebagai sistem operasi
2 Iperf3 3.1.1 Tools pengujian antar host milik client
III.4 Desain Topologi Jaringan
Topologi jaringan yang dibuat, didesain agar bisa memodelkan topologi pada jaringan milik
penyedia layanan yang terdiri dari core dan edge serta topologi jaringan milik tenant yang
terhubung dengan jaringan milik penyedia layanan. Dalam topologi ini ada dua buah tenant yaitu
tenant 1 dan tenant 2 yang memiliki dua buah office di dua buah area yang berbeda, kedua tenant
tersebut memerlukan koneksi jaringan privat antara kedua buah office yang dimilikinya. Berikut
adalah topologi jaringannya.
37
Network controller
OVX Hypervisor
OOB Management
linkt11 linkt12
linkc1 linkc3
link2 link3
SwitchP2
link1 link7 link6
link4 link5
SwitchPE1 SwitchP1 SwitchP4 SwitchPE2
linkc4
linkc2
Linkt22
SwitchP3
linkt21
Gambar III-3 Topologi Jaringan Fisik Testbed
38
Dalam rancangan topologi testbed ini, jaringan milik operator menggunakan topologi layer 2,
tidak ada konfigurasi ip address yang setiap perangkatnya. Setiap perangkat switch OpenFlow
memiliki satu buah alamat pengenal yang mirip dengan alamat layer 2, alamat ini disebut
dengan datapath ID(DPID), berikut adalah datapath ID dari masing-masing.
Tabel III-8 Datapath Switch
Nama Perangkat Datapath ID

P1 00:00:00:00:00:01:01:00
P2 00:00:00:00:00:01:02:00
P3 00:00:00:00:00:01:03:00
P4 00:00:00:00:00:01:04:00
PE1 00:00:00:00:00:02:01:00
PE2 00:00:00:00:00:02:02:00
Jaringan pada sisi Operator menggunakan jaringan komputer berbasis SDN sedangkan pada
sisi tenant menggunakan jaringan komputer tradisional. Konektifitas antara switch dan
controller menggunakan out of band(OOB), yaitu jaringan khusus yang diperuntukan sebagai
jalur komunikasi untuk keperluan manajemen jaringan seperti monitoring dan konfigurasi.
Dengan adanya OOB maka konfigurasi yang harus dilakukan akan lebih sederhana, karena
tidak perlu ada routing tradisional yang harus dikonfigurasi di sisi perangkat switch. Tanpa
adanya OOB maka perangkat switch yang digunakan harus menggunakan perangkat switch
hybrid, yang bisa mempergunakan routing tradisional untuk melewatkan traffic protocol
OpenFlow dan traffic lainnya akan dilewatkan melalui mekanisme pemilihan rute datapath.
Masing-masing switch baik P, PE didalam jaringan virtual SDN memiliki spek dan fitur yang
sama, hal ini berbeda dengan jaringan tradisional. Ketika operator menjalankan layanan VPN
berbasis MPLS, router P dan PE memiliki fungsi dan spek yang berbeda, router PE berfungsi
untuk menjalankan VRF(VPN routing and forwarding) dan komunikasi iBGP antar router PE.
Router P berfungsi menjalankan label switching dan internal routing protocol. Dalam jaringan
virtual SDN switch PE akan memiliki akses langsung dari controller milik tenant baik secara
langsung pada FlowVisor maupun secara virtual penuh pada OpenVirtex. Berikut adalah
konfigurasi lengkap dari bridge OpenVswitch yang dibuat dalam percobaan ini.
39
Tabel III-2 Konfigurasi Bridge
No Router Interface Bridge hardware address Konfigurasi bridge

OpenFlow bridge
1 P1 Eth1, 00:00:00:01:01:00 ovs-vsctl add-br vmbr0

eth2, eth3, ovs-vsctl add-port vmbr0 eth1
eth4 ovs-vsctl add-port vmbr0 eth2
ovs-vsctl add-port vmbr0 eth3
ovs-vsctl set bridge vmbr0 other-
config:hwaddr=00:00:00:01:01:00
2 P2 Eth1,eth2 00:00:00:01:02:00 ovs-vsctl add-br vmbr0

config:hwaddr=00:00:00:01:02:00
3 P3 Eth1, eth2 00:00:00:01:03:00 ovs-vsctl add-br vmbr0

config:hwaddr=00:00:00:01:03:00
4 P4 Eth1, 00:00:00:01:04:00 ovs-vsctl add-br vmbr0

eth2, eth3, ovs-vsctl add-port vmbr0 eth1
eth4 ovs-vsctl add-port vmbr0 eth2
config:hwaddr=00:00:00:01:04:00
5 PE1 Eth1, 00:00:00:02:01:00 ovs-vsctl add-br vmbr0

eth2, eth3 ovs-vsctl add-port vmbr0 eth1
config:hwaddr=00:00:00:02:01:00
6 PE2 Eth1, 00:00:00:02:02:00 ovs-vsctl add-br vmbr0

eth2, eth3 ovs-vsctl add-port vmbr0 eth1
config:hwaddr=00:00:00:02:02:00
40
III.5 Desain Percobaan pada Testbed
Dalam percobaan secara garis besar ada beberapa tahap yang dilakukan, yaitu pengujian untuk
testbed, pengujian untuk OpenVirtex dan pengujian untuk FlowVisor. Untuk pengujian
testbed, hal yang dilakukan adalah melakukan pengujian fungsionalitas switch OpenFlow dan
datapath. Pada pengujian FlowVisor, dilakukan pengujian, fungsionalitas virtualisasi,
pengujian fungsionalitas koneksi end-to-end host di suatu tenant, pengujian fungsionalitas
layanan aplikasi di atas controller SDN, pengujian fungsionalitas failover, implementasi
aplikasi firewall, sebagai pembuktian kapabilitas untuk menjalankan network function
virtualization(NFV) untuk masing-masing tenant dan pengujian penggunaan sumberdaya
hypervisor dan pengujian delay akibat proses tambahan pada hypervisor. Pengujian
fungsionalitas OpenVirtex dilakukan persis sama dengan pengujian yang dilakukan pada
FlowVisor.
Pengujian fungsionalitas switch OpenFlow, dilakukan satu per satu pada switch yang ada pada
testbed dengan cara menyambungkan seluruh swith yang ada menjadi suatu topologi testbed
dan kemudian menghubungkan semuanya dengan controller dan kemudian menjalankan
modul topologi serta switch pada controller untuk bisa membuat peta jaringan utuh serta
membentuk rute antar host. Proses ping kemudian dilakukan antar host milik tenant dan
melihat flow yang terbentuk pada switch OpenFlow.
Pengujian fungsionalitas pada OpenVirtex dan FlowVisor pertama kali dilakukan dengan cara
membuat konfigurasi dua buah jaringan virtual milik masing-masing tenant. konfigurasi
jaringan virtual pada OpenVirtex dilakukan dengan membuat dua buah switch virtual yang
masing-masing berasal dari hasil virtualisasi switch PE1 dan PE2, sebut saja vPE1 dan vPE2,
diantara keduanya kemudian dihubungkan dengan link virtual yang sejatinya adalah jaringan
fisik yang berada di antara PE1 dan PE2. Berikut adalah gambar dari konfigurasi virtualisasi
yang dilakukan.
41
SDN Controller
OOB Management
Router CE tenant Router CE tenant PC tenant
Vlink
vPE1 vPE2
Gambar III-4 Jaringan Virtual Tenant OpenVirtex
Setelah jaringan virtual di jalankan, pengujian selanjutnya adalah pengujian link failover dan
fungsi penambahan layanan aplikasi untuk tenant, serta pengujian koneksi end to end antar
host milik tenant yang berbeda site. Pengujian penggunaan sumber daya komputasi pada server
network hypervisor dilakukan untuk mengetahui seberapa besar masing-masing network
hypervisor menghabiskan sumber daya CPU dan memory untuk bisa menjalankan flow yang
diperlukan untuk menghubungkan kedua site milik tenant. Pengujian delay yang ditimbulkan
oleh keberadaan hypervisor dilakukan untuk mengetahui seberapa besar delay yang
ditimbulkan oleh penambahan proses yang dilakukan oleh network hypervisor. Untuk
FlowVisor pengujian yang dilakukan adalah sama, namun dengan topologi jaringan virtual
yang tidak bisa sama, karena fitur dari OpenVirtex yang bisa melakukan virtualisasi secara
penuh, termasuk kemampuan untuk membuat link virtual yang tidak dimiliki oleh FlowVisor,
serta keharusan dari jaringan virtual pada FlowVisor yang harus merupakan graph isomorph
dari jaringan fisik. Namun secara tujuan dan fungsionalitas akan sama, yaitu membuat
konektifitas antara kedua site tenant. Tenant 1 akan melewati switch P2 sementara tenant 2
akan melewati switch P3. Berikut adalah gambar dari jaringan virtual yang dibentuk oleh
FLowVisor.
SDN Controller
OOB Management
PC Tenant Router Tenant Router Tenant 1.2 PC Tenant
Switch PE1 SwitchP1 Switch P2/P3 Switch P4 Switch PE2
Gambar III-5 Jaringan Virtual Tenant FlowVisor
42
III.6 Metode Pengukuran Kinerja Testbed VPN Site-to-Site
Pada tahap ini dilakukan perancangan pengukuran performansi testbed yang diatasnya
dijalankan virtualisasi untuk layan VPN site-to-site. Pengujian dilakukan dari segi performa
jaringan, overhead komunikasi OFP akibat dari keberadaan network hypervisor serta
penggunaan sumber daya komputasi baik di sisi controller maupun hypervisor. Dalam
penelitian ini hal yang diukur adalah throughput, delay dan jitter untuk mengukur performa
jaringan serta overhead OFP, dan penggunaan CPU dan memory pada controller maupun
hypervisor untuk mengukur penggunaan sumberdaya komputasi sebagai akibat adanya proses
yang dijalankan oleh hypervisor dan interaksinya dengan komponen.n yang lainnya.
Implementasi pengukuran kinerja jaringan menggunakan ping dan iperf dengan parameter
sebagai berikut:
a. Pengukuran delay dan jitter menggunakan perangkat lunak ping sebanyak 10 paket
dengan parameter default dan dilakukan sebanyak sepuluh kali percobaan, sehingga ada
100 data untuk setiap jenis solusi yang diimplementasi.
b. Pengukuran throughput menggunakan perangkat lunak iperf dengan menggunakan
ukuran paket 1 GB, pengambilan data setiap interval 20 detik dan dilakukan sebanyak
10 kali per percobaan dan diulang sebanyak 10 kali, sehingga terdapat 10 sampel.
c. Pengukuran sumber daya komputasi dilakukan di sisi hypervisor maupun controller
dengan jumlah percobaan sebanyak 10 kali, perangkat lunak yang digunakan adalah
htop, dan nilai pengukuran yang dilakukan adalah prosentase dari penggunaan sumber
daya.
43
Bab IV
HASIL PERCOBAAN dan ANALISIS
Untuk mengetahui fungsionalitas dan performa dari sistem yang dibuat, maka penulis
melakukan dua jenis pengujian yaitu pengujian fungsionalitas dan pengujian performa.
Pengujian fungsionalitas bertujuan untuk mengetahui apakah seluruh fungsi sistem yang
sebelumnya telah didefinisikan berjalan dengan benar, sedangkan pengujian performa
bertujuan untuk mengetahui dan membandingkan seberapa besar jumlah sumber daya jaringan
dan sumber daya komputasi yang diperlukan oleh sistem untuk menjalankan fungsi layananan
VPN site-to-site beserta. Pengujian fungsionalitas terdiri dari 3 bagian yaitu, pengujian
fungsionalitas dasar testbed, pengujian fungsionalitas virtualisasi dengan menggunakan
FlowVisor dan pengujian fungsionalitas virtualisasi dengan menggunakan OpenVirtex.
IV.1 Pengujian Fungsionalitas Dasar Testbed
Penelitian ini berhasil mengimplementasikan testbed jaringan SDN yang terdiri dari core dan
edge network penyedia layanan, dan jaringan milik tenant 1 dan tenant 2. Jaringan milik
penyedia layanan(switch P dan switch PE) menggunakan teknologi SDN sedangkan jaringan
milik tenant(router CE dan host) menggunakan teknologi jaringan tradisional. Bisa dilihat
hasilnya dari gambar yang berasal dari menu topologi di sisi controller, perangkat milik
penyedia layanan akan terdeteksi sebagai switch SDN, sedangkan perangkat router milik
tenant yaitu CE akan terlihat sebagai host bagi controller SDN milik tenant. Sedangkan host
milik tenant tidak terlihat. Topologi fisik testbed yang digunakan untuk menguji dua buah
aplikasi virtualisasi dapat dilihat pada gambar IV-1 Topologi fisik testbed multitenant.
Sedangkan topologi yang terbaca di sisi controller bisa terlihat pada gambar IV-2 Topologi
logic testbed multitenant
44
Network controller
OVX Hypervisor
OOB Management
linkt11 linkt12
linkc1 linkc3
link2 link3
SwitchP2
link1 link7 link6
link4 link5
SwitchPE1 SwitchP1 SwitchP4 SwitchPE2
linkc4
linkc2
Linkt22
SwitchP3
linkt21
Gambar IV-1 Topologi Fisik Testbed Multitenant
Gambar IV-2 Topologi Logic Testbed Multitenant
Switch yang terlihat pada gambar IV-1 maupun IV-2 yang bersesuaian. Dihubungkan melalui
link fisik testbed. Topologi logic bisa terbentuk karena adanya protokol (link layer discovery
protocol) LLDP, sebuah protokol layer 2 yang berfungsi untuk melakukan pemetaan perangkat
layer 2 didalam sebuah jaringan SDN. Setiap switch akan mengirimkan pesan LLDP ke setiap
port aktif yang dimilikinya, yang kemudian akan dipetakan menjadi switch-switch tetangga.
45
Informasi ini kemudian akan dikirimkan ke controller oleh seluruh switch yang terkoneksi ke
controller. Controller kemudian akan mengolah informasi tersebut dan membuat peta utuh
jaringan berdasarkan dpid switch dan link-link yang menghubungkan switch-switch tersebut.
Untuk menjalankan pengujian virtualisasi, baik dengan menggunakan OpenVirtex maupun

Flowvisor, akan digunakan dua buah instance controller yang berada didalam satu buah server
yang sama namun dengan konfigurasi port yang berbeda. Berikut adalah baris konfigurasi
controller floodlight yang berbeda di kedua instance. Dua buah controller dijalankan didalam
sebuah server yang sama untuk menghemat resource. Dalam implementasi sesungguhnya,
sebuah controller untuk setiap tenant bisa dibuat didalam sebuah virtual machine yang berbeda
yang dikelola langsung oleh tenant.
Tabel IV-1 Baris Konfigurasi yang Berbeda pada Setiap Instance Controller
1 2
FloodlightProvider.openflowport 10000 20000
net.floodlightcontroller.restserver.RestApiServer.httpPort 10001 20001
net.floodlightcontroller.restserver.RestApiServer.httpsPort 8082 8083
IV.2 Pengujian Fungsionalitas Virtualisasi dengan Menggunakan FlowVisor
Selanjutnya untuk bisa jalankan langkah-langkah berikut untuk bisa menjalankan FlowVisor
sesuai dengan kebutuhan konfigurasi yang sudah dijelaskan pada bab sebelumnya. Langkah
pertama adalah dengan melakukan konfigurasi awal Flowvisor.dengan menginisiasi
konfigurasi FlowVisor. Langkah selanjutnya adalah melakukan slicing topologi untuk tenant1
dan tenant 2. Slicing artinya adalah melakukan pembagian topologi jaringan fisik berdasarkan
kriteria protokol, pembagian bisa berdasarkan layer fisik(port), layer datalink(alamat fisik),
layer 3(alamat IP) maupun layer 4(protokol transport dan port aplikasi) slicing yang dilakukan
disini adalah slicing topologi berdasarkan port dan alamat layer2. Slicing topologi fisik murni
dilakukan pada perangkat switch yang hanya digunakan oleh satu tenant saja, sedangkan slicing
berdasarkan port dan alamat fisik dilakukan pada perangkat switch yang digunakan oleh kedua
tenant. Slicing utama untuk topologi tenant1 terdiri dari switch: PE1, P1, P2, P4, PE2 dan
tenant 2 terdiri dari switch.: PE1, P1 P4, PE2, bisa dilihat di sini, switch P1 dan P4 dilewati
oleh traffic tenant 1 maupun tenant 2. Sementara untuk jalur backup masing-masing tenant
akan dimasukan switch P2 untuk tenant1 dan switch P3 untuk tenant2. Dalam pembuatan
topologi jaringan di FlowVisor, virtual link tidak bisa dibuat, sehingga controller milik tenant
46
bisa langsung mengakses perangkat core milik penyedia layanan. Dalam gambar bisa dilihat
sampel flowspace yang terbentuk, untuk kedua tenant. Selengkapnya bisa dilihat di lampiran.
Configured Flow entries:

{"force-enqueue": -1, "name": "switch-pe1-port1", "slice-action": [{"slice-name": "tenant1", "permission": 7}],
"queues": [], "priority": 1, "dpid": "00:00:00:00:00:02:01:00", "id": 1, "match": {"wildcards": 4194274, "dl_type":
2048, "dl_dst": "00:0c:29:19:c5:4e", "dl_src": "00:0c:29:de:79:31", "in_port": 1}}
{"force-enqueue": -1, "name": "switch-pe1-port1", "slice-action": [{"slice-name": "tenant1", "permission": 7}],
"queues": [], "priority": 1, "dpid": "00:00:00:00:00:02:01:00", "id": 2, "match": {"wildcards": 4194274, "dl_type":
Gambar IV-3 Sampel Flowspace untuk Tenant 1 dan Tenant 2
Secara singkat masing-masing field bisa dijelaskan sebagai berikut:
a. Name: nama dari flowspace

b. Slice-action
 Slice-name: slice yang menjadi pemilik dari flow-space, hal ini berkaitan
dengan controller yang digunakan untuk mengatur flow untuk setiap
flowmatch.
 Permission: pengaturan hak untuk controller untuk setiap flow-match.
Dalam penelitian ini permission yang diberikan adalah 7 yang artinya, flow
terkait bisa didelegasikan ke controller dan kemudian controller boleh
menginstall flow entry terkait di sisi switch.
 Priority: mengatur prioritas flow-space yang akan digunakan untuk suatu
flow yang match ke lebih dari satu buah flow-space.
 Dpid: datapath id untuk perangkat switch terkait.
 Match:
i. Wildcards: jumlah flow yang match dengan flow-space.
ii. dl_type: tipe payload yang diangkut, dalam hal ini 2048 artinya
adalah IP.
iii. dl_src, dl_dst dan in_port berkaitan dengan alamat datalink asal dan
tujuan serta source port terkait.
Langkah selanjutnya adalah kita melihat topologi yang terbentuk via GUI controller
Floodlight. Baik untuk tenant 1 maupun tenant 2.
47
Gambar IV-4 Topologi Utama Tenant 1
Gambar IV-5 Topologi Utama Tenant 2
Selanjutnya kita bisa melihat rute yang dibentuk oleh kalkulasi modul switch milik controller
Floodlight berdasarkan dpid.
Tabel IV-2 Rute antar Switch CE di Dalam Suatu Tenant

Tenant 1 [{"switch":"00:00:00:00:00:02:01:00","port":3},{"switch":"00:00:00:00:00:02:01:00","port":1},{"swit
ch":"00:00:00:00:00:01:01:00","port":1},{"switch":"00:00:00:00:00:01:01:00","port":4},{"switch":"00
:00:00:00:00:01:04:00","port":4},{"switch":"00:00:00:00:00:01:04:00","port":3},{"switch":"00:00:00:
00:00:02:02:00","port":1},{"switch":"00:00:00:00:00
48
Tenant 2 [{"switch":"00:00:00:00:00:02:01:00","port":2},{"switch":"00:00:00:00:00:02:01:00","port":1},{"swit
ch":"00:00:00:00:00:01:01:00","port":1},{"switch":"00:00:00:00:00:01:01:00","port":4},{"switch":"00
:00:00:00:00:01:04:00","port":4},{"switch":"00:00:00:00:00:01:04:00","port":3},{"switch":"00:00:00:
00:00:02:02:00","port":1},{"switch":"00:00:00:00:00:02:02:00","port":2}]
IV.2.1 Implementasi Virtualisasi Fungsi Layanan Jaringan
Implementasi virtualisasi fungsi layanan jaringan dilakukan dengan cara

mengimplementasikan firewall untuk setiap tenant, aplikasi yang dibuat sangat sederhana yaitu
dengan sebuah script yang menjalankan firewall dan melakukan blocking untuk traffic yang
datang dari suatu jaringan milik tenant. Implementasi layanan aplikasi firewall bisa dijalankan
dengan baik, percobaan dilakukan dengan cara menyalakan aplikasi firewall pada tenant 1,
yang secara default akan mendrop seluruh koneksi, dan melihat kondisi koneksi antar host
dalam tenant 1, lalu membandingkannya dengan tenant 2. Sebelum firewall diaktifkan, koneksi
antar host dalam tenant 1 bisa dijalankan, dan ketika firewall di tenant 1 diaktifkan. Koneksi
pada tenant 1 mengalami drop sdeangkan pada tenant 2 masih bisa berjalan. Berikut adalah
langkah-langkah yang dilakukan:
a. Cek modul firewall: curl http://localhost:10001/wm/firewall/module/status/json

{"result" : "firewall disabled"}
b. Jalankan firewall: curl http://localhost:10001/wm/firewall/module/enable/json
{"status" : "success", "details" : "firewall running"}
c. Cek kondisi koneksi pada kedua sisi tenant
Tabel IV-3 Pengujian Firewall pada Masing-Masing Tenant

Tenant 1 Tenant 2
Ping berhenti: Ping tetap berjalan:
oot@RouterCETenant11:/home/galih# ping -c 10 root@RouterCETenant21:/home/galih# ping -c 10
10.0.0.2 20.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. PING 20.0.0.2 (20.0.0.2) 56(84) bytes of data.
From 10.0.0.1 icmp_seq=10 Destination Host 64 bytes from 20.0.0.2: icmp_seq=1 ttl=64
Unreachable time=20.0 ms
64 bytes from 20.0.0.2: icmp_seq=2 ttl=64 time=2
--- 10.0.0.2 ping statistics --- ms
10 packets transmitted, 0 received, 100% packet 64 bytes from 20.0.0.2: icmp_seq=3 ttl=64
loss, time 8098ms time=1.22 ms
64 bytes from 20.0.0.2: icmp_seq=4 ttl=64
time=0.564 ms
time=0.987 ms
time=1.21 ms
time=1.00 ms
49
time=1.22 ms
time=1.12 ms
time=0.678 ms
--- 20.0.0.2 ping statistics ---

10 packets transmitted, 10 received, 0% packet
loss, time 8013ms
rtt min/avg/max/mdev = 0.564/3.455/20.0/9.874
ms
IV.2.2 Pengujian Fungsi Failover pada FlowVisor
Langkah selanjutnya adalah melakukan pengujian failover pada FlowVisor. Pengujian ini
ditujukan untuk mengetahui apakah fungsi failover bisa dijalankan dengan menggunakan
FlowVisor. Langkah pertama yang dilakukan adalah dengan melihat jalur yang digunakan
untuk menyampaikan paket data antar host yang terhubung ke jaringan. Langkah pertama
adalah melihat jalur utama milik masing-masing tenant. Terlihat pada tabel berikut, jalur yang
ditempuh untuk tenant1 maupun tenant 2 adalah sama.
Tabel IV-4 Jalur Utama Tenant pada FlowVisor

Tenant 1 #curl
http://localhost:10001/wm/topology/route/00:00:00:00:00:02:01:00/2/00:00:00:0
0:00:02:02:00/2/json
[{"switch":"00:00:00:00:00:02:01:00","port":2},{"switch":"00:00:00:00:00:02:01:00
","port":1},{"switch":"00:00:00:00:00:01:01:00","port":1},{"switch":"00:00:00:00:00
:01:01:00","port":4},{"switch":"00:00:00:00:00:01:04:00","port":4},{"switch":"00:00
:00:00:00:01:04:00","port":3},{"switch":"00:00:00:00:00:02:02:00","port":1},{"switc
h":"00:00:00:00:00:02:02:00","port":2}]
Tenant 2 #curl
0:00:02:02:00/3/json
[{"switch":"00:00:00:00:00:02:01:00","port":3},{"switch":"00:00:00:00:00:02:01:00
","port":1},{"switch":"00:00:00:00:00:01:01:00","port":1},{"switch":"00:00:00:00:00
:01:01:00","port":4},{"switch":"00:00:00:00:00:01:04:00","port":4},{"switch":"00:00
50
:00:00:00:01:04:00","port":3},{"switch":"00:00:00:00:00:02:02:00","port":1},{"switc
h":"00:00:00:00:00:02:02:00","port":3}]
Jika di visualisasikan bisa dilihat dalam gambar berikut
SDN Controller
OOB Management
PC Tenant 1.1 PC Tenant 1.2

linkc1 linkc3
link1 Link7 link6
Router PE1 Router P1 Router P4 Router PE2
Gambar IV-6 Topologi Utama Virtualisasi pada FlowVisor untuk Kedua Tenant
Langkah Selanjutnya lakukan pemutusan link antara P1 dan P4, dan lihat rute baru yang dibuat,
bisa dilihat bahwa jalur baru yang dipilih oleh tenant 1 adalah melalui P2, sedangkan untuk
tenant 2 adalah melalui P3, sesuai dengan konfigurasi yang dilakukan.
SDN Controller
OOB Management
Router Tenant 1.1 Router Tenant 1.2

linkc1 linkc3
link2 link3
Switch P2
link1 link6
Switch PE1 SwitchP1 Switch P4 Switch PE2
Gambar IV-7 Topologi Backup untuk Tenant 1
51
SDN Controller
OOB Management
link1 link6
link4 link5
Switch PE1 Switch P1 Switch P4 Switch PE2
linkc4
linkc2
Switch P3
Router Tenant 2.2
Router Tenant 2.1
Gambar IV-8 Topologi Backup untuk Tenant 2
Tabel IV-5 Jalur Backup Tenant 1 dan Tenant 2

Tenant 1 #curl
0:00:02:02:00/2/json
[{“switch”:”00:00:00:00:00:02:01:00”,”port”:2},{“switch”:”00:00:00:00:00:02:01:00
”,”port”:1},{“switch”:”00:00:00:00:00:01:01:00”,”port”:1},{“switch”:”00:00:00:00:0
0:01:01:00”,”port”:2},{“switch”:”00:00:00:00:00:01:02:00”,”port”:1},{“switch”:”00:
00:00:00:00:01:02:00”,”port”:2},{“switch”:”00:00:00:00:00:01:04:00”,”port”:1},{“s
witch”:”00:00:00:00:00:01:04:00”,”port”:3},{“switch”:”00:00:00:00:00:02:02:00”,”p
ort”:1},{“switch”:”00:00:00:00:00:02:02:00”,”port”:2}]
Tenant 2 #curl
0:00:02:02:00/3/json
[{“switch”:”00:00:00:00:00:02:01:00”,”port”:3},{“switch”:”00:00:00:00:00:02:01:00
”,”port”:1},{“switch”:”00:00:00:00:00:01:01:00”,”port”:1},{“switch”:”00:00:00:00:0
0:01:01:00”,”port”:3},{“switch”:”00:00:00:00:00:01:03:00”,”port”:1},{“switch”:”00:
00:00:00:00:01:03:00”,”port”:2},{“switch”:”00:00:00:00:00:01:04:00”,”port”:1},{“s
witch”:”00:00:00:00:00:01:04:00”,”port”:2},{“switch”:”00:00:00:00:00:02:02:00”,”p
ort”:1},{“switch”:”00:00:00:00:00:02:02:00”,”port”:3}]
Selama proses pemutusan link utama, ping terhenti dan baru bisa berjalan lagi, setelah proses
ping di restart di sisi host. Hal ini dikarenakan walaupun rute baru sudah di kalkulasi, flow
baru tidak langsung di push ke perangkat switch OpenFlow. Sehingga entry flow baru tidak
akan terbentuk di perangkat switch yang menjadi jalur baru. Entry flow baru akan diberikan
begitu idle_timeout suatu flow tercapai di sisi switch dan dihapus. Kemudian setelah ping
dilakukan kembali, maka perangkat switch akan mengirimkan flow_messages ke controller
untuk meminta flow entry, dan yang diberikan adalah flow entry yang dihasilkan dari hasil
52
kalkulasi jalur baru. Dari hasil ini bisa disimpulkan bahwa failover tidak berhasil di lakukan
untuk percobaan dengan FlowVisor, hal ini dikarenakan FlowVisor secara default tidak bisa
menjalankan langsung proses pengaturan link dan langsung menyerahkan fungsi tersebut
kepada controller. Sementara modul switching pada controller Floodlight tidak mendukung
push flow baru secara otomatis ketika link utama mati. Bisa dilihat bahwa di perangkat switch
P2 terbentuk flow baru.
root@OpenVSwitch-P2:/home/galih# ovs-ofctl dump-flows vmbr0

NXST_FLOW reply (xid=0x4):
cookie=0x20000000000000, duration=383.05s, table=0, n_packets=383, n_bytes=37534, idle_timeout=5,
idle_age=0,
priority=1,ip,in_port=1,dl_src=00:0c:29:56:21:76,dl_dst=00:0c:29:ed:25:c6,nw_src=10.0.0.1,nw_dst=10.0.0.2
actions=output:2
cookie=0x20000000000000, duration=383.065s, table=0, n_packets=383, n_bytes=37534, idle_timeout=5,
idle_age=0,
priority=1,ip,in_port=2,dl_src=00:0c:29:ed:25:c6,dl_dst=00:0c:29:56:21:76,nw_src=10.0.0.2,nw_dst=10.0.0.1
actions=output:1
Gambar IV-9 Flow Baru di Switch P2
Pengujian selanjutnya adalah memastikan fungsi dari VPN site-to-site bisa dijalankan, yaitu
dengan cara melakukan ping antar host yang berada di belakang router di masing-masing site
milik suatu tenant, pengujian ini dilakukan dengan melakukan konfigurasi host-host yang berada
di belakang router CE milik tenant dengan address space sebagai berikut:
Tabel IV-6 Daftar Blok IP Address Site Tenant

Tenant site Blok ip address
Tenant 1 Site 1 192.168.112.0/24
Tenant 1 Site 2 192.168.113.0/24
Tenant 2 Site 1 192.168.114.0/24
Tenant 2 Site 2 192.168.115.0/24
Proses ping berhasil dilakukan antara host yang berada dalam satu tenant, yang membuktikan
bahwa fungsionalitas VPN site-to-site bisa dijalankan dengan baik oleh FlowVisor. Namun
karena idle_timeout dengan nilai 0 yang diset pada FlowVisor kita tidak mengamati flow entry
baik yang bersifat fisik disisi switch maupun yang bersifat logic di sisi controller. Keterangan
lebih lengkap bisa dilihat pada lampiran.
53
IV.3 Pengujian Fungsionalitas dengan OpenVirtex
Selanjutnya untuk bisa jalankan langkah-langkah berikut untuk bisa menjalankan OpenVirtex
sesuai dengan kebutuhan konfigurasi yang sudah dijelaskan pada bab sebelumnya. Langkah
pertama adalah dengan menjalankan daemon OpenVirtex. Langkah selanjutnya adalah
melakukan pembuatan topologi virtual untuk tenant1 dan tenant 2. Pembuatan topologi virtual
artinya adalah membuat topologi dengan komponen switch, link dan port yang bersifat virtual.
Masing-masing tenant akan diberikan komponen jaringan virtual yang memiliki identitas
berbeda dengan perangkat fisik. HyperVisor OpenVirtex akan menjalankan proses translasi
identitas perangkat maupun flow. Sehingga jaringan fisik akan tersembunyikan dari controller
milik tenant. Dan tenant seolah-olah mengelola jaringan fisik sendiri dengan bebas.
Implementasi yang dilakukan adalah dengan membuat virtual link antar PE sehingga core
network milik penyedia layanan akan tidak terlihat disisi tenant. Kedua buah tenant akan
memiliki address space virtual yang sama yaitu blok IP address 10.0.0.0/16. Dan address
space fisik yang berbeda yaitu blok IP address 1.0.0.0/16 untuk tenant 1 dan 2.0.0.0/16 untuk
tenant 2. Id perangkat virtual milik masing-masing tenant bisa sama antar tenant.
Berikut adalah langkah-langkah dalam mengimplementasikan jaringan virtual berbasis

OpenVirtex:
a. buat jaringan virtual masing-masing tenant dan masukan perangkat switch PE1 dan
PE2 kedalam jaringan yang baru dibuat. buat virtual port di switch PE1 dan PE2
masing-masing di port pertama dan kedua.
b. sambungkan antara kedua virtual port antara kedua switch virtual dan antar switch
virtual ke host. Untuk hubungan antar switch, gunakan datapath id virtual switch yang
di buat dari switch 1 dan switch 2.
c. hubungkan port virtual, dan definisikan berapa jumlah backup link yang ingin di
kalkulasi berdasarkan algoritma SPF.
d. Hubungkan antara switch PE ke host, host di sini adalah perangkat router CE milik
tenant, host diberi akses ke port virtual dengan id 2 di setiap switchnya, identitas yang
digunakan adalah datapath id virtual switch dan mac address host yang dihubungkan.
e. Jalankan jaringan virtual milik tenant 1 dan tenant 2.
Berikut adalah tabel yang berisi konfigurasi lengkap untuk kedua buah tenant.
54
Tabel IV-7 Konfigurasi Lengkap OpenVirtex untuk Kedua Tenant
Tenant 1 python ovxctl.py -n createNetwork tcp:167.205.64.67:10000 10.0.0.0 16

python ovxctl.py -n createSwitch 1 00:00:00:00:00:02:01:00
python ovxctl.py -n createPort 1 00:00:00:00:00:02:01:00 1
python ovxctl.py -n connectLink 1 00:a4:23:05:00:00:00:01 1 00:a4:23:05:00:00:00:02 1 spf 1
python ovxctl.py -n connectHost 1 00:a4:23:05:00:00:00:01 2 00:0c:29:19:c5:4e
python ovxctl.py -n connectHost 1 00:a4:23:05:00:00:00:02 2 00:0c:29:de:79:31
python ovxctl.py -n startNetwork 1
Tenant 2 python ovxctl.py -n createNetwork tcp:167.205.64.67:20000 10.0.0.0 16

python ovxctl.py -n connectHost 2 00:a4:23:05:00:00:00:01 2 00:0c:29:56:21:76
python ovxctl.py -n connectHost 2 00:a4:23:05:00:00:00:02 2 00:0c:29:ed:25:c6
Berikut adalah tabel flow yang terbentuk di masing-masing switch, bisa dilihat juga jalur utama
yang dipilih oleh tenant 1 adalah melalui P1-P4
Tabel IV-8 Flow-entry di Setiap Switch untuk Tenant 1
PE1 root@OpenVSwitch-PE1:/home/galih# ovs-ofctl dump-flow vmbr0
cookie=0x100000003, duration=829.884s, table=0, n_packets=852, n_bytes=82546,

idle_timeout=5, idle_age=2,
priority=0,in_port=1,vlan_tci=0x0000,dl_src=a4:23:05:01:00:00,dl_dst=a4:23:05:10:00:04
actions=mod_nw_src:10.0.0.2,mod_nw_dst:10.0.0.1,mod_dl_src:00:0c:29:de:79:31,mod_
dl_dst:00:0c:29:19:c5:4e,output:2

priority=0,in_port=2,vlan_tci=0x0000,dl_src=00:0c:29:19:c5:4e,dl_dst=00:0c:29:de:79:31
actions=mod_nw_dst:1.0.0.4,mod_nw_src:1.0.0.3,mod_dl_src:a4:23:05:01:00:00,mod_dl_
dst:a4:23:05:10:00:02,output:1
55
P1 root@OpenVSwitch-P1:/home/galih# ovs-ofctl dump-flows vmbr0

actions=output:4

actions=output:1

actions=output:3

actions=output:4
PE2 root@OpenVSwitch-PE2:/home/galih# ovs-ofctl dump-flows vmbr0

priority=0,in_port=2,vlan_tci=0x0000,dl_src=00:0c:29:de:79:31,dl_dst=00:0c:29:19:c5:4e
dst:a4:23:05:10:00:04,output:1

actions=mod_nw_src:10.0.0.1,mod_nw_dst:10.0.0.2,mod_dl_src:00:0c:29:19:c5:4e,mod_
dl_dst:00:0c:29:de:79:31,output:2
Tabel IV-9 Flow-entry di Setiap Switch untuk Tenant 2

actions=output:4
56
actions=output:1

actions=output:4
actions=output:3

priority=0,in_port=3,vlan_tci=0x0000,dl_src=00:0c:29:56:21:76,dl_dst=00:0c:29:ed:25:c6
dst:a4:23:05:10:00:02,output:1
actions=mod_nw_src:10.0.0.2,mod_nw_dst:10.0.0.1,mod_dl_src:00:0c:29:ed:25:c6,mod_
dl_dst:00:0c:29:56:21:76,output:3

priority=0,in_port=3,vlan_tci=0x0000,dl_src=00:0c:29:ed:25:c6,dl_dst=00:0c:29:56:21:76
dst:a4:23:05:10:00:04,output:1
actions=mod_nw_src:10.0.0.1,mod_nw_dst:10.0.0.2,mod_dl_src:00:0c:29:56:21:76,mod_
dl_dst:00:0c:29:ed:25:c6,output:3
Bisa dilihat pada perangkat switch yang terhubung langsung ke tenant ada modifikasi
datalink address maupun network address milik tenant 1 yang berasal dari dan ke arah
tenant. Konversi yang terjadi adalah sebagai berikut.
Tabel IV-10 Translasi Pengalamatan untuk Tenant 1
Fisik Virtual
00:0c:29:19:c5:4e a4:23:05:10:00:04
00:0c:29:de:79:31 a4:23:05:01:00:00
10.0.0.1 1.0.0.3
10.0.0.2 1.0.0.4
57
Fisik Virtual
00:0c:29:56:21:76 a4:23:05:02:00:00
00:0c:29:ed:25:c6 a4:23:05:10:00:02
10.0.0.1 2.0.0.1
10.0.0.2 2.0.0.2
Berikut adalah gambar dari jaringan virtual yang terbentuk, hasil ini bisa dilihat lewat GUI
controller beserta flow-entry logicnya.
Gambar IV-10 Topologi Jaringan Virtual Tenant 1
Gambar IV-11 Topologi Jaringan Virtual Tenant 2
58
Gambar IV-12 Flow-entry Jaringan Virtual Tenant 1 pada Switch Virtual 1
Gambar IV.13 Flow-entry Jaringan Virtual Tenant 1 pada Switch Virtual 2
59
Bisa kita lihat flow-entry dengan dengan menggunakan OpenVirtex bisa dilihat baik di switch
maupun GUI controller sedangkan pada FlowVisor hal ini tidak bisa dilakukan karena
FlowVisor melakukan override terhadap nilai idle_timeout dari controller yang semula di set
bernilai 5 menjadi 0, sehingga tidak ada cache_flow dan setiap kali ada flow harus ada
flow_message yang dikirim ke controller dari switch, untuk menginstall flow. Nilai ini tidak
60
bisa diubah dari sisi konfigurasi dan hal ini sangat mempengaruhi performa sistem secara
keseluruhan.
IV.3.1 Implementasi Virtualisasi Fungsi Layanan Jaringan
Implementasi layanan aplikasi firewall bisa dilakukan, percobaan dilakukan dengan cara
menyalakan aplikasi firewall pada tenant 1, yang secara default akan mendrop seluruh koneksi,
dan melihat kondisi koneksi antar host dalam tenant 1, lalu membandingkannya dengan tenant
2. Sebelum firewall diaktifkan, koneksi antar host dalam tenant 1 bisa dijalankan, dan ketika
firewall di tenant 1 diaktifkan. Koneksi pada tenant 1 mengalami drop sdeangkan pada tenant
2 masih bisa berjalan. Berikut adalah langkah-langkah yang dilakukan:
a. Cek modul firewall: curl http://localhost:10001/wm/firewall/module/status/json

{"result" : "firewall disabled"}
b. Jalankan firewall: curl http://localhost:10001/wm/firewall/module/enable/json
{"status" : "success", "details" : "firewall running"}
c. Cek kondisi koneksi pada kedua sisi tenant
Tabel IV-12 Pengujian Firewall pada Masing-Masing Tenant

Tenant 1 Tenant 2
Ping berhenti: Ping tetap berjalan:
oot@RouterCETenant11:/home/galih# ping -c root@RouterCETenant21:/home/galih# ping -c
10 10.0.0.2 10 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
--- 10.0.0.2 ping statistics --- time=0.982 ms
10 packets transmitted, 0 received, +2 errors, 64 bytes from 10.0.0.2: icmp_seq=4 ttl=64
100% packet loss, time 9070ms time=0.946 ms
pipe 2 64 bytes from 10.0.0.2: icmp_seq=5 ttl=64
time=0.990 ms
time=1.09 ms
time=1.04 ms
time=1.08 ms
time=1.04 ms
time=1.06 ms
--- 10.0.0.2 ping statistics ---
61
10 packets transmitted, 10 received, 0% packet
loss, time 9010ms
rtt min/avg/max/mdev =
0.946/5.175/40.085/11.658 ms
IV.3.2 Pengujian Fungsi Failover pada OpenVirtex
Langkah selanjutnya adalah melakukan pengujian failover pada OpenVirtex. Pengujian ini
ditujukan untuk mengetahui apakah fungsi failover bisa dijalankan dengan menggunakan
OpenVirtex. Langkah pertama yang dilakukan adalah dengan melihat jalur yang digunakan
untuk menyampaikan paket data antar host yang terhubung ke jaringan. Langkah pertama
adalah melihat jalur utama milik masing-masing tenant. Terlihat pada tabel berikut, jalur yang
ditempuh untuk tenant1 maupun tenant 2 adalah sama, baik untuk jalur utama maupun jalur
backup karena jalur backup tersembunyi di sisi HyperVisor OpenVirtex.
Tabel IV-13 Jalur Utama Maupun Backup Logic Tenant pada OpenVirtex
Tenant 1 #curl
http://localhost:10001/wm/topology/route/00:a4:23:05:00:00:00:01/2/
00:a4:23:05:00:00:00:02/2/json
[{"switch":"00:a4:23:05:00:00:00:01","port":2},{"switch":"00:a4:23:05:00:00:00:01"
,"port":1},{"switch":"00:a4:23:05:00:00:00:02","port":1},{"switch":"00:a4:23:05:00:
00:00:02","port":2}]
Tenant 2 #curl
http://localhost:20001/wm/topology/route/00:a4:23:05:00:00:00:01/2/
00:a4:23:05:00:00:00:02/2/json
[{"switch":"00:a4:23:05:00:00:00:01","port":2},{"switch":"00:a4:23:05:00:00:00:01"
,"port":1},{"switch":"00:a4:23:05:00:00:00:02","port":1},{"switch":"00:a4:23:05:00:
00:00:02","port":2}]
62
Jika di visualisasikan bisa dilihat dalam gambar berikut
SDN Controller
OOB Management
Virtual switch1 Virtual switch 2
PC Tenant 2.2
Router Tenant 2.1
Gambar IV-16 Topologi Utama dan Backup Virtualisasi pada OpenVirtex untuk Kedua Tenant
Langkah Selanjutnya lakukan pemutusan link antara P1 dan P4, dan lihat rute baru yang dibuat,
bisa dilihat bahwa jalur baru yang dipilih oleh tenant 1 dan tenant 2.
Tabel IV-14 Jalur Backup Tenant 1 dan Tenant 2

priority=0,in_port=3,vlan_tci=0x0000,dl_src=00:0c:29:56:21:76,dl_dst=00:0c:29:ed:25:c
6
actions=mod_nw_dst:2.0.0.3,mod_nw_src:2.0.0.2,mod_dl_src:a4:23:05:02:00:00,mod_
dl_dst:a4:23:05:10:00:02,output:1
4
actions=mod_nw_src:10.0.0.2,mod_nw_dst:10.0.0.1,mod_dl_src:00:0c:29:de:79:31,mo
d_dl_dst:00:0c:29:19:c5:4e,output:2
priority=0,in_port=2,vlan_tci=0x0000,dl_src=00:0c:29:19:c5:4e,dl_dst=00:0c:29:de:79:3
1
dl_dst:a4:23:05:10:00:02,output:1
4
actions=mod_nw_src:10.0.0.2,mod_nw_dst:10.0.0.1,mod_dl_src:00:0c:29:ed:25:c6,mod
_dl_dst:00:0c:29:56:21:76,output:3
63
2 actions=output:3
4 actions=output:1
2 actions=output:3
4 actions=output:1


priority=0,ip,in_port=1,dl_src=a4:23:05:02:00:00,dl_dst=a4:23:05:10:00:02
actions=output:2
cookie=0x20000000000000, duration=383.02s, table=0, n_packets=383,
n_bytes=37534, idle_timeout=5, idle_age=0,
priority=0,in_port=2,dl_src=a4:23:05:01:00:00,dl_dst=a4:23:05:10:00:04
actions=output:1
priority=0,ip,in_port=1,dl_src=a4:23:05:10:00:02,dl_dst=a4:23:05:02:00:00
actions=output:2
n_bytes=37332, idle_timeout=5, idle_age=0,
priority=0,in_port=2,dl_src=a4:23:05:10:00:04,dl_dst=a4:23:05:01:00:00
actions=output:1

4 actions=output:2
2 actions=output:3
4 actions=output:2
64
2 actions=output:3

priority=0,in_port=3,vlan_tci=0x0000,dl_src=00:0c:29:ed:25:c6,dl_dst=00:0c:29:56:21:7
6
dl_dst:a4:23:05:10:00:04,output:1
2
actions=mod_nw_src:10.0.0.1,mod_nw_dst:10.0.0.2,mod_dl_src:00:0c:29:56:21:76,mo
d_dl_dst:00:0c:29:ed:25:c6,output:3
priority=0,in_port=2,vlan_tci=0x0000,dl_src=00:0c:29:de:79:31,dl_dst=00:0c:29:19:c5:4
e
dl_dst:a4:23:05:10:00:04,output:1
2
actions=mod_nw_src:10.0.0.1,mod_nw_dst:10.0.0.2,mod_dl_src:00:0c:29:19:c5:4e,mod
_dl_dst:00:0c:29:de:79:31,output:2
Selama proses pemutusan link utama, ping tidak terhenti sama sekali dan tidak ada packet loss,
flow baru langsung di push ke perangkat switch OpenFlow. Sehingga entry flow baru akan
terbentuk di perangkat switch yang menjadi jalur baru. Dari hasil ini bisa disimpulkan bahwa
link failover berhasil dilakukan untuk percobaan dengan OpenVirtex, hal ini dikarenakan fitur
link failover milik OpenVirtex.yang membuat kalkulasi link backup ketika membuat virtual
link. Bisa dilihat bahwa di perangkat switch P3 terbentuk flow baru. Namun tidak semua
percobaan berhasil, dari sekian banyak percobaan link failover ada beberapa kali proses gagal
dengan output error di sisi log OpenVirtex. Dengan konfigurasi yang sama ternyata sistem
mengalai inkonsistensi prilaku.
65
64 bytes from 10.0.0.2: icmp_seq=882 ttl=64 time=1976 ms
64 bytes from 10.0.0.2: icmp_seq=884 ttl=64 time=2.17 ms
Gambar IV-17 Proses Ping Sewaktu Failover
Dari hasil ping diatas tidak terlihat perbedaan yang signifikan dalam hal delay time, agak sulit
untuk melihat mana proses ping yang terjadi pada saat failover terjadi. Pengujian selanjutnya
adalah memastikan fungsi dari VPN site-to-site bisa dijalankan, pengujian ini dilakukan
dengan melakukan konfigurasi host-host yang berada di belakang router CE milik tenant
dengan address space sebagai berikut, address space yang digunakan adalah address space
yang sama dengan yang digunakan oleh percobaan dengan Flowvisor, sebagaimana terlihat
pada tabel berikut:
66
Tabel IV-15 Tabel blok IP Address Untuk Setiap Site Milik Tenant
Tenant site Blok ip address
Tenant 1 Site 1 192.168.112.0/24
Tenant 1 Site 2 192.168.113.0/24
Tenant 2 Site 1 192.168.114.0/24
Tenant 2 Site 2 192.168.115.0/24
Proses ping berhasil dilakukan antara host yang berada dalam satu tenant, yang membuktikan
bahwa fungsionalitas VPN site-to-site bisa dijalankan dengan baik oleh OpenVirtex, ping
dilakukan antara host didalam satu tenant, flow entry fisik dan logic bisa dilihat pada gambar
berikut.
Gambar IV-18 Flow-entry Jaringan Virtual Tenant 1
67
Gambar IV-19 Flow-entry Jaringan Virtual Tenant 2
Tabel IV-16 Flow table untuk Percobaan Koneksi Antar Host Dalam Satu Tenant

n_bytes=8105636, idle_timeout=5, idle_age=2, hard_age=65534,
priority=0,in_port=1,vlan_tci=0x0000,dl_src=a4:23:05:02:00:00,dl_dst=a4:23:05:10:00:
02
actions=mod_nw_src:192.168.115.2,mod_nw_dst:192.168.114.2,mod_dl_src:00:0c:29:
ed:25:c6,mod_dl_dst:00:0c:29:56:21:76,output:3
priority=0,in_port=3,vlan_tci=0x0000,dl_src=00:0c:29:56:21:76,dl_dst=00:0c:29:ed:25:
c6
actions=mod_nw_dst:2.0.0.7,mod_nw_src:2.0.0.6,mod_dl_src:a4:23:05:02:00:00,mod
_dl_dst:a4:23:05:10:00:04,output:1

04
de:79:31,mod_dl_dst:00:0c:29:19:c5:4e,output:2
priority=0,in_port=2,vlan_tci=0x0000,dl_src=00:0c:29:19:c5:4e,dl_dst=00:0c:29:de:79:
31
_dl_dst:a4:23:05:10:00:02,output:1
68
02 actions=output:4
02 actions=output:1
04 actions=output:4
04 actions=output:1
P2
P3

02 actions=output:3
02 actions=output:4
04 actions=output:3
04 actions=output:4

priority=0,in_port=3,vlan_tci=0x0000,dl_src=00:0c:29:ed:25:c6,dl_dst=00:0c:29:56:21:
76
_dl_dst:a4:23:05:10:00:02,output:1
priority=0,in_port=2,vlan_tci=0x0000,dl_src=00:0c:29:de:79:31,dl_dst=00:0c:29:19:c5:
4e
_dl_dst:a4:23:05:10:00:04,output:1
69
02
19:c5:4e,mod_dl_dst:00:0c:29:de:79:31,output:2
04
56:21:76,mod_dl_dst:00:0c:29:ed:25:c6,output:3
Bisa kita lihat dari tabel diatas, ip address milik host masing-masing tenant akan digantikan
oleh ip address baru yang di berikan oleh OVX. Berikut adalah translasi yang terjadi.
Fisik Virtual
00:0c:29:19:c5:4e a4:23:05:10:00:04
00:0c:29:de:79:31 a4:23:05:01:00:00
192.168.112.2 1.0.0.4
192.168.113.2 1.0.0.5
Fisik Virtual
00:0c:29:56:21:76 a4:23:05:02:00:00
00:0c:29:ed:25:c6 a4:23:05:10:00:02
10.0.0.1 2.0.0.6
10.0.0.2 2.0.0.7
Dari hasil diatas bisa ditarik kesimpulan bahwa seluruh ip address yang ada didalam suatu blok
milik site suatu tenant akan ditranslasikan kepada ip address fisik yang pool yang ditentukan oleh
konfigurasi OpenVirtex, sementara mac address yang akan ditranslasikan adalah mac address dari
interface router CE yang terhubung ke jaringan SDN milik operator.
70
IV.4 Pengujian Kinerja Virtualisasi
Berikut adalah hasil pengukuran kinerja jaringan yang meliputi throughput, delay, jitter.
Packet loss. Serta pengukuran penggunaan sumber daya komputasi yang meliputi penggunaan
CPU dan Memory. Pengukuran secara umum. dilakukan untuk tiga kondisi yaitu kondisi tanpa
adanya HyperVisor, dengan FlowVisor dan OpenVirtex. Masling-masing pengukuran
dilakukan dengan menggunakan aplikasi Iperf. Pengukuran dilakukan 100 kali untuk pengujian
delay dan jitter, 10 kali untuk pengukuran throughput, packet loss dan penggunaan sumber
daya komputasi. masing-masing. Data mentah bisa dilihat pada lampiran.
IV.4.1 Pengukuran Delay
Tabel IV-19 Pengukuran Delay pada FlowVisor dan OpenVirtex
Hypervisor Kondisi Delay

Tanpa CacheFlow 2.417908257
Flowvisor Tidak bisa
Dengan CacheFlow
dicari
OpenVirtex Dengan CacheFlow 2.00922
Grafik Perbandingan Delay

30
26.18408163
25
20
Delay (ms)
15
10
5 2.417908257 2.00922
0
0
Tanpa CacheFlow Dengan CacheFlow Tanpa CacheFlow Dengan CacheFlow
Flowvisor OpenVirtex
Delay 2.417908257 0 26.18408163 2.00922
Gambar IV-20 Grafik Perbandingan Delay untuk FlowVisor dan OpenVirtex
Dari hasil pengukuran diatas bisa dilihat bahwa secara umum keberadaan cache flow di sisi
perangkat switch akan menurunkan waktu untuk melakukan forwarding data, karena ketika
71
cache flow diaktifkan maka ketika ada flow data yang masuk ke switch tidak harus selalu ada
proses untuk menanyakan rute kepada controller, akses ke controller hanya dilakukan ketika
tidak ada flow entry yang match untuk suatu flow data yang masuk. Bisa kita lihat dengan
keberadaan cache flow tidak ada perbedaan yang signifikan antara proses forwarding untuk
virtualisasi berbasis OpenVirtex maupun ketika testbed diuji tanpa adanya Hypervisor untuk
menjalankan virtualisasi. Untuk pengujian dengan FlowVisor hal ini tidak bisa dilakukan
karena secara konfigurasi nilai idle_timeout=0 tidak bisa diubah.
Ketika cache flow dimatikan, maka setiap kali ada flow data yang datang ke perangkat switch
maka switch akan selalu bertanya kepada controller mengenai flow table terkait dengan rute
yang harus dilewati oleh flow data tersebut. Bisa kita lihat delay yang meningkat sangat
signifikan pada penggunaan virtualisasi menggunakan OpenVirtex. Bila dibandingkan dengan
FlowVisor, proses yang dijalankan didalam OpenVirtex lebih kompleks, dengan intensitas
proses yang tinggi untuk keperluan translasi antara controller milik tenant dengan HyperVisor
OpenVirtex dan perangkat fisik jaringan, sehingga waktu yang diperlukan cukup tinggi.
Sementara pada FlowVisor fungsi utamanya adalah untuk melakukan proses penyampaian
flow_message dari perangkat switch ke controller dan sebaliknya, jelas overhead proses lebih
kecil dan waktu yang diperlukan juga lebih kecil. Jika dibandingkan dengan delay yang terjadi
pada testbed terjadi kenaikan delay pada OpenVirtex dan FlowVisor
Delay pada Testbed

1.4 1.21971
1.2
1
Delay (ms)
0.8
0.6
0.4
0.2
0
Testbed
Delay 1.21971
Gambar IV-21 Delay pada Testbed
72
IV.4.2 Pengukuran Jitter
Tabel IV-20 Pengkuruan Jitter pada FlowVisor dan OpenVirtex
HyperVisor Kondisi Jitter

Flowvisor Tidak bisa
Dengan CacheFlow
dicari
OpenVirtex Dengan CacheFlow 0.818936582
Grafik Perbandingan Jitter

25
19.36699603
20
Jitter (ms)
15
10 8.91146247
5
1.743338117
0
0
Tanpa CacheFlow Dengan CacheFlow Tanpa CacheFlow Dengan CacheFlow
Jitter 8.91146247 0 19.36699603 1.743338117
Gambar IV-22 Grafik Perbandingan Jitter
Pada pengukuran jitter bisa kita lihat dengan menggunakan OpenVirtex nilai jitter juga lebih
besar jika dibandingkan dengan FlowVisor dalam kondisi cache flow di non aktifkan , jika
dilihat data mentah dari keduanya bisa dilihat bahwa variasi nilai round trip time delay juga
cukup besar, hal ini berbeda ketika cache flow diaktifkan. Dari hal ini bisa disimpulkan
bahwa ada variasi waktu proses yang besar yang dijalankan pada Hypervisor, terutama pada
OpenVirtex, hal ini sebenarnya bukan hal yang baik karena untuk jenis transaksi proses yang
sama waktu prosesnya bisa sangat berbeda. Untuk sistem yang stabil waktu proses transaksi
yang sama dengan kondisi jaringan yang sama akan dikerjakan dengan waktu yang variasinya
tidak terlalu besar. Jika dibandingkan dengan delay yang terjadi pada testbed terjadi kenaikan
jitter pada OpenVirtex dan FlowVisor.
73
Grafik Jitter pada testbed
0.9 0.818936582
0.8
0.7
0.6
Jitter (ms)
0.5
0.4
0.3
0.2
0.1
0
Jitter
Testbed 0.818936582
Gambar IV-23 Jitter pada Testbed
IV.4.3 Pengukuran Throughput pada OpenVirtex dan FlowVisor
Pengukuran througput dilakukan dengan bantuan tools iperf. Pengukuran Througput yang
dilakukan bisa dilihat bahwa sistem bekerja secara benar dengan kondisi trhougput TCP lebih
kecil dibandingkan dengan UDP, hal ini dikarenakan overhead pada protokol TCP lebih besar
dibandingkan dengan UDP. Pengukuran troughput dilakukan dengan kondisi cache flow
dijalankan untuk OpenVirtex, namun tidak dijalankan pada penggunaan FlowVisor. Terjadi
penurunan nilai throughput TCP pada OpenVirtex jika dibandingkan dengan FlowVisor dan
testbed tanpa virtualisasi. Walaupun dengan penggunaan FlowVisor cache flow dimatikan
namun ternyata penurunan throughput paling besar tetap terjadi pada penggunaan OpenVirtex.
Secara keseluruhan jika dibandingkan dengan throughput testbed tanpa virtualisasi terjadi
penurunan throughput.
Tabel IV-21 Pengkuruan Throughput pada FlowVisor dan OpenVirtex
HyperVisor Protokol Throughput

TCP 922.4
Flowvisor UDP 993.7
TCP 912.4
OpenVirtex UDP 993.2
74
Throughput
1000
980
960
940
920
Throughput
900
880
860
TCP UDP TCP UDP
Gambar IV-24 Grafik Throughput pada FlowVisor dan OpenVirtex
IV.4.4 Pengukuran Througput untuk Testbed Tanpa Virtualisasi
Tabel IV-22 Pengkuruan Throughput TCP dan UDP pada testbed tanpa virtualisasi
Hypervisor Protokol Throughput

Flowvisor TCP 922.4
OpenVirtex TCP 912.4
Flowvisor UDP 993.7
OpenVirtex UDP 993.2
Throughput
1000
980
960
940
920 Throughput
900
TCP UDP
Testbed
Gambar IV-25 Grafik Throughput TCP dan UDP untuk Testbed
75
IV.4.5 Pengukuran CPU dan Memory Hypervisor dalam Kondisi Idle dan Melakukan
Pemrosesan Flow Data
Pengujian dilakukan dengan melewatkan data antara dua ujung tenant, kondisi yang dibuat
adalah dengan kondisi cache flow dimatikan untuk FlowVisor dan cache flow dinyalakan untuk
OpenVirtex. Pada kondisi idle proses OpenVirtex sudah menghabiskan CPU dan memory yang
berukuran lebih besar dibandingkan dengan FlowVisor, hal ini karena program OpenVirtex
lebih kompleks dibandingkan dengan FlowVisor. Pada saat memproses flow data bisa kita lihat
penggunaan CPU untuk OpenVirtex lebih meningkat lebih besar jika dibandingkan dengan
FLowVisor, walaupun perbandingan yang dilakukan dengan kondisi berlawanan dimana cache
flow dimatikan pada FlowVisor dan dinyalakan pada OpenVirtex bisa dilihat bahwa
penggunaan sumberdaya komputer untuk OpenVirtex masih lebih besar dibandingkan dengan
FlowVisor.
Tabel IV-23 Penggunaan sumberdaya Hypervisor Saat FlowVisor dan OpenVirtex Idle
Grafik Hypervisor saat OpenVirtex dan FlowVisor Idle

Aplikasi kuantitas CPU Memory
Openvirtex Avarage 0.7 20
Flowvisor Avarage 0.3 6.9
Gambar IV-26 Grafik Hypervisor saat FlowVisor dan OpenVirtex Idle
76
Tabel IV-24 Penggunaan Sumberdaya Hypervisor saat OpenVirtex dan FlowVisor Memproses Flow
Data
Grafik Hypervisor saat OpenVirtex dan

Flowvisor Menerima Paket
Aplikasi CPU Memory
Openvirtex Avarage 1.33 20
Gambar IV-27 Grafik Hypervisor pada saat FlowVisor dan OpenVirtex Memproses Flow Data
IV.4.6 Pengukuran CPU dan Memory pada Controller Dalam Kondisi Idle dan
Melakukan Pemrosesan Flow Data
Pada saat idle penggunaan sumber daya memori untuk OpenVirtex dan FlowVisor tidak terlalu
signifikan, namun ada sedikit perbedaan dalam hal penggunaan CPU. OpenVirtex tampak
melakukan proses komunikasi lebih intensif dalam kondisi idle jika dibandingkan dengan
FlowVisor. Pada kondisi memforward paket, controller untuk FlowVisor lebih menghabiskan
sumber daya jika dibandingkan dengan OpenVirtex, hal ini dikarenakan karena proses
pemilihan rute seluruhnya dilakukan sepenuhnya oleh controller, sedangkan pada OpenVirtex,
proses forwarding pada link virtual dilakukan pada OpenVirtex.
77
Tabel IV-25 Pengukuran Sumberdaya Controller pada saat OpenVirtex dan FlowVisor Idle
Grafik saat OpenVirtex dan Flowvisor Idle

Aplikasi CPU Memory
Openvirtex Avarage 1.62 30.8
Gambar IV-28 Grafik Controller pada saat FlowVisor dan OpenVirtex Idle
Tabel IV-26 Pengukuran Sumberdaya Controller pada saat OpenVirtex dan FlowVisor Memproses Paket
Grafik saat OpenVirtex dan Flowvisor Saat Memproses Paket

Aplikasi CPU Memory
Openvirtex Avarage 2.2 30.8
78
Gambar IV-29 Grafik Controller pada saat FlowVisor dan OpenVirtex Memproses Paket
IV.5 Bug dan Error pada Masing-Masing Hypervisor
Dalam implementasi jaringan virtual SDN dengan menggunakan FlowVisor, terdapat dua buah
error yaitu penggunaan sumber daya komputasi oleh proses Java, yang menyebabkan memory
penuh dan tidak bisa didealokasi secara otomatis. Hal ini disebabkan karena gagalnya Java
garbage collector untuk membuang objek yang sudah tidak dipakai, hal ini menyebabkan
proses penyampaian data ke tujuan tidak bisa dilakukan secara lancar, berikut adalah gambar
yang menunjukan penggunaan memory dan CPU yang cukup besar, hal tersebut terjadi berkali-
kali.
Gambar IV-30 Anomali Penggunaan Sumberdaya Komputasi pada FlowVisor
79
Error lain yang terjadi dalam percobaan ini adalah FlowVisor mengalami inkonsistensi dalam
prilaku forwarding data, untuk konfigurasi yang sama, terkadang FlowVisor tidak bisa
melakukan fungsinya sebagai mana mestinya. Dalam implementasi jaringan virtual SDN
dengan menggunakan OpenVirtex terdapat dua jenis error yang terjadi, yaitu inkonsistensi
prilaku forwarding data. Untuk konfigurasi yang sama, terkadang OpenVirtex tidak bisa
melakukan fungsinya sebagai mana mestinya, error log yang menyatakan bahwa virtual source
port unknown hal ini cukup sering terjadi dalam percobaan yang dilakukan.
04:03:20.996 [pool-5-thread-21] ERROR OVXPacketIn - Virtual Src Port Unknown:

00:00:00:00:00:01:04:00:66560, port 4 with this match
OFMatch[in_port=4,dl_dst=a4:23:05:10:00:02,dl_src=a4:23:05:01:00:00,dl_type=0x806,dl_vlan=0xffff,dl_vl
an_pcp=0,nw_dst=10.0.0.2,nw_src=10.0.0.1,nw_proto=2,nw_tos=0]; dropping packet
an_pcp=0,nw_dst=1.0.0.5,nw_src=1.0.0.7,nw_proto=1,nw_tos=0,tp_dst=0,tp_src=8]; dropping packet
an_pcp=0,nw_dst=10.0.0.2,nw_src=10.0.0.1,nw_proto=2,nw_tos=0]; dropping packet
Gambar IV-31 Error pada Operasional FlowVisor
Error lain yang terjadi adalah pada saat percobaan failover, dari lima kali percobaan yang
dilakukan, terjadi empat kali error yang menyebabkan failover tidak bisa dilakukan dengan
baik, error yang terjadi menyebabkan rute baru tidak bisa di push ke perangkat switch sehingga
tidak bisa terjadi failover. Dari log yang terlihat, informasi error yang yang sama seperti
gambar IV-31 juga terjadi pada kasus failover. Setelah mencari informasi lebih jauh di situs
resmi maupun mailing-list FlowVisor, memang ada beberapa laporan bug dan error yang sama
seperti yang penulis alami. Masalah lain terkait dengan penggunaan OpenVirtex adalah subnet
mask untuk IP address tenant tidak boleh menggunakan selain 10.0.0.0/16, 20.0.0.0/16 dan
seterusnya, ketika blok IP address lain yang digunakan, maka akan terjadi error karena
kegagalan mapping IP address ke blok IP address OVX(1.0.0.0/16, 2.0.0.0/16 dan seterusnya).

OFMatch[in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,dl_src=42:3a:ae:41:fe:ae,dl_type=0x800,dl_vlan=0xffff,dl_vlan_pcp
=0,nw_dst=255.255.255.255,nw_src=0.0.0.0,nw_proto=17,nw_tos=4,tp_dst=67,tp_src=68]; dropping
packet
18:17:00.820 [pool-5-thread-11] WARN OVXPacketIn - PacketIn
packetIn:bufferId=632ofmsg:v=1;t=PACKET_IN;l=88;x=0 does not belong to any virtual network; dropping
and installing a temporary drop rule
80
18:17:01.111 [pool-5-thread-4] ERROR OVXPacketIn - Virtual Src Port Unknown: 00:00:00:00:00:00:00:02:2,
port 1 with this match
OFMatch[in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,dl_src=46:70:14:b3:1f:13,dl_type=0x800,dl_vlan=0xffff,dl_vlan_pcp
packet
OFMatch[in_port=2,dl_dst=ff:ff:ff:ff:ff:ff,dl_src=d6:80:11:43:f4:a7,dl_type=0x800,dl_vlan=0xffff,dl_vlan_pcp
packet
Gambar IV-32 Error pada Penggunaan Sembarang Blok IP
Dari percobaan yang dilakukan bisa disimpulkan bahwa FlowVisor sebagai aplikasi virtualisasi
berbasis SDN yang sudah lebih dahulu ada, ternyata masih memiliki bug yang cukup
mengganggu kerja sistem. OpenVirtex sebagai aplikasi yang diproyeksikan akan
menggantikan FlowVisor sebagai aplikasi virtualisasi berbasis SDN memiliki fitur yang lebih
mendukung untuk perkembangan teknologi virtualisasi berbasis SDN namun masih memiliki
cukup banyak error.
81
Bab V
KESIMPULAN dan SARAN
V.1 Kesimpulan
Adapun kesimpulan yang dapat ditarik pada penelitian mengenai implementasi virtualisasi
berbasis FlowVisor dan OpenVirtex yaitu.
1. Pengujian fungsi utama dari virtualisasi berbasis SDN yaitu: Pemisahan traffic antar
tenant dan pengaturan jaringan virtual oleh controller milik tenant serta menjalankan
konektivitas antar host yang berbeda site dalam satu tenant bisa dilakukan oleh
FlowVisor maupun OpenVirtex, sesuai dengan spesifikasi fitur yang tertera pada
dokumentasi kedua aplikasi.
2. Pengaturan Address space dan topologi bisa lebih leluasa dilakukan pada OpenVirtex
yang memiliki skema virtualisasi penuh, sesuai dengan spesifikasi fitur yang tertera pada
dokumentasi aplikasi OpenVirtex. Selain itu virtualisasi penuh menghindarkan tenant
untuk memiliki kontrol langsung ke perangkat jaringan milik penyedia layanan, yang
artinya memenuhi constrain kemanan.
3. Failover bisa berjalan pada OpenVirtex dibandingkan dengan FlowVisor, dimana tidak
ada traffic yang terputus pada saat link utama putus pada percobaan dengan OpenVirtex,
dan hal ini berbeda dengan pada saat menggunakan FlowVisor. Hal ini sesuai dengan
spesifikasi fitur yang tertara pada dokumentasi kedua aplikasi.
4. Pada implementasi virtualisasi dengan menggunakan OpenVirtex, topologi jaringan SDN
virtual bisa diatur dengan lebih leluasa jika dibandingkan dengan virtualisasi berbasis
FlowVisor.
5. Implementasi layanan jaringan virtual pada operator jaringan lebih mudah dibuat dengan
teknologi virtualisasi berbasis SDN, karena penyedia layanan cukup menyediakan
topologi switching dengan konfigurasi yang lebih minim dibandingkan dengan
implementasi virtualisasi pada jaringan tradisional.
6. OpenVirtex menjanjikan solusi virtualisasi berbasis SDN yang lebih baik untuk masa
depan dibandingkan dengan FlowVisor, namun sampai saat, solusi ini belum layak untuk
diimplementasikan pada jaringan real mengingat masih banyak bug dan error yang
terjadi serta stabilitas dari sistem yang berjalan, seperti yang terlihat pada bagian analisis
dan hasil percobaan.
82
7. Dari pengujian penggunaan sumber daya komputasi baik pada server controller maupun
server hypervisor didapatkan hasil sebagai berikut:
a. Implementasi virtualisasi dengan menggunakan OpenVirtex dibandingan dengan
FlowVisor menghasilkan rasio delay 1086 %, jumlah ini mengindikasikan bahwa
overhead akibat proses dan protokol OpenFlow pada OpenVirtex jauh lebih besar
dibandingkan dengan FlowVisor.
b. Pada kondisi idle server HyperVisor OpenVirtex lebih banyak memakan sumber
daya, dengan penggunaan CPU: 0.7 % berbanding 0.3 % dan penggunaan memory
20 % berbanding 6.9 %
c. Penggunaan CPU pada server hypervisor naik 0.63 % untuk penggunaan
OpenVirtex sedangkan pada FlowVisor naik 0.97 %
d. Penggunaan memory pada server hypervisor, tidak mengalami perubahan pada
penggunaan OpenVirtex sedangkan pada FlowVisor mengalami kenaikan 0.03 %.
e. Penggunaan CPU pada controller naik 0.58 % untuk OpenVirtex dan 0.68 % untuk
FlowVisor.
f. Penggunaan memory pada controller, tidak mengalami perubahan pada
penggunaan OpenVirtex sedangkan pada FlowVisor naik dengan signifikan 27%,
hal ini dikarenakan FlowVisor berinteraksi lebih intensif dengan controller dan
mengandalkan controller untuk mengatur seluruh rute.
V.2 Saran
Adapun saran yang dapat diberikan untuk pengembangan penelitian ini kedepannya antara lain
1. Percobaan bisa dilakukan pada level hardware yang lebih tinggi agar bisa mengukur
kinerja secara lebih presisi.
2. Perangkat keras dan jumlah titik pengujian harus ditambah disesuaikan dengan tingkat
kebutuhan untuk pengukuran yang lebih real seperti di sistem produksi.
3. Riset bisa dilanjutkan untuk menguji fungsionalitas lain yang belum teruji dari kedua
buah solusi virtualisasi FlowVisor dan OpenVirtex.
4. Perlu lebih banyak kontribusi pengembangan kedua aplikasi ini untuk bisa masuk ke level
implementasi pada jaringan real.
83
DAFTAR PUSTAKA
[1] Sakir Sezer et al., "Are We Ready for SDN? Implementation Challenges for Software
Defined Networks," IEEE Communications Magazine, vol. 51, no. 7, pp. 36-43, July 2013.
[2] ONF.SDN Architecture Overview. White Paper. [Online].

https://www.opennetworking.org/images/stories/downloads/sdn-
resources/technicalreports/SDN-architecture-overview-1.0.pdf.
[3] Thomas D. Nadeau, Ken Gray, “SDN: Software Defined Networks”, O’Reilly
Media, 2013
[4] “OpenFlow Architecture Overview”.[Online].

https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-
reports/SDN-architecture-overview-1.0.pdf.
[5]“OpenFlow Controller Model”.[Online].

http://www.virtualnetwork.com/blog/2013/08/centralized-vs-distributed-vs-hybrid-sdn-
which-is-the-best-approach-for-todays-networks/.
[6] Pories Ediansyah, "Desain dan Implementasi Testbed Openflow ITB", Sekolah Teknik
Elektro dan Informatika, Institut Teknologi Bandung, Oktober 2014, Bandung, Indonesia.
[7]”OpenFlow Documentation”.[Online]. http://openflow.stanford.edu.
[8] Ali Al-Shabibi, Mark de Leenheer, Ayaka Koshibe, Matteo Gerola, “OpenVirtex: Make
your virtual SDN programmable”,HotSDN 2014, Chicago USA, August 2014.
[9] Rob Sherwood, Glen Gibb, Kok Kiong Yap, “FlowVisor A Network Virtualization
Layer”, Deutsche Telecom Inc, Stanford University, October 2009, USA.
[10]Rosen, Eric, Arun Viswanathan, and Ross Callon.” Multiprotocol Label Switching
Architecture”.[Online]. http://www.hjp.at/doc/rfc/rfc3031.
84
[11]”Open Virtex Documentation”.[Online]. http://ovx.onlab.us/documentation/.
[12]Randy Zhang, Micah Bartel, “BGP Design and Implementation”, Cisco Press 2004.
[13]Andreas Blenk, Arsany Basta, Martin Reisslein, “Survey on Network Virtualization

Hypervisors for Software Defined Networking”, IEEE Communications Magazine, vol. 51,
no. 7, pp. 36-43, October 2015
[15]R.Doriguzzi-Corin, E.Salvadori, M. Sune, “A Datapath-centric Virtualization for

OpenFlow Network”, Third European Workshop on Software-Defined Networks, 2014.
[16] "Big Switch Network Community: Project Floodlight",

http://www.projectfloodlight.org/floodlight. [Online].
[17]Sdncentral., (2014). “What’s Software Defined Networking (SDN)”.[Online].

www.sdncentral.com/what-the-definitions-of-software-defined-networking-sdn.
[18]”FlowVisor Documentation”. [Online].

https://github.com/OPENNETWORKINGLAB/flowvisor/wiki.
[19]Nick McKeown, Tom Anderson, Hari Balakrishnan, “OpenFlow: Enabling Innovation in

Campus Networks”, ACM SIGCOMM Computer Communication Review, Volume 38 Issue
2, 69-74, 2008
85
86
Lampiran A
Pembuatan Virtualisasi Menggunakan FlowVisor dan OpenVirtex
CLI untuk implementasi Virtualisasi dengan FlowVisor
1. Jalankan flowvisor daemon:

a. Inisiasi konfigurasi flowvisor dalam bentuk json
fvconfig generate /etc/flowvisor/config.json
Masukan password untuk fvadmin:
Berikut adalah konfigurasi dasar dari flowvisor
{
"flowvisor": [
{
"api_webserver_port": 8080,
"db_version": 2,
"host": "localhost",
"log_ident": "flowvisor",
"checkpointing": false,
"listen_port": 6633,
"logging": "DEBUG",
"run_topology_server": false,
"log_facility": "LOG_LOCAL7",
"version": "flowvisor-1.4.0",
"config_name": "default",
"api_jetty_webserver_port": 8081,
"default_flood_perm": "fvadmin",
"track_flows": false,
"stats_desc_hack": false
}
]
}
2. Arahkan controller masing-masing switch ke ip address Hypervisor Flowvisor yaitu 167.205.64.68 port 6633
ovs-vsctl set-controller vmbr0 tcp:167.205.64.68:6633
c. Jalankan
# fvconfig load /etc/flowvisor/config.json
#/etc/init.d/flowvisor start
root@Hypervisor:/home/galih# ps ax | grep flow
2725 pts/0 S 0:00 sudo -u flowvisor /usr/sbin/flowvisor
2726 pts/0 Sl 0:02 java -server -Xms100M -Xmx2000M -XX:OnError=flowvisor-crash-logger -
XX:+UseConcMarkSweepGC -Dorg.flowvisor.config_dir=/etc/flowvisor -
Dorg.flowvisor.install_dir=/usr/libexec/flowvisor -Dderby.system.home=/usr/share/db/flowvisor -
Dfvlog.configuration=/etc/flowvisor/fvlog.config -Dorg.flowvisor.config_dir=/etc/flowvisor -
Dorg.flowvisor.install_dir=/usr/libexec/flowvisor -Dderby.system.home=/usr/share/db/flowvisor -
Dfvlog.configuration=/etc/flowvisor/fvlog.config -Djavax.net.ssl.keyStore=/etc/flowvisor/mySSLKeyStore
-Djavax.net.ssl.keyStorePassword=CHANGEME_PASSWD -cp
/usr/libexec/flowvisor/openflow.jar:/usr/libexec/flowvisor/xmlrpc-client-
3.1.3.jar:/usr/libexec/flowvisor/xmlrpc-common-3.1.3.jar:/usr/libexec/flowvisor/xmlrpc-server-
3.1.3.jar:/usr/libexec/flowvisor/commons-logging-1.1.jar:/usr/libexec/flowvisor/ws-commons-util-
1.0.2.jar:/usr/libexec/flowvisor/jsse.jar:/usr/libexec/flowvisor/asm-3.0.jar:/usr/libexec/flowvisor/cglib-
2.2.jar:/usr/libexec/flowvisor/commons-codec-1.4.jar:/usr/libexec/flowvisor/commons-collections-
3.2.1.jar:/usr/libexec/flowvisor/commons-dbcp-1.4.jar:/usr/libexec/flowvisor/commons-pool-
1.5.6.jar:/usr/libexec/flowvisor/gson-2.0.jar:/usr/libexec/flowvisor/jetty-continuation-
7.0.2.v20100331.jar:/usr/libexec/flowvisor/jetty-http-7.0.2.v20100331.jar:/usr/libexec/flowvisor/jetty-
I
io-7.0.2.v20100331.jar:/usr/libexec/flowvisor/jetty-security-
7.0.2.v20100331.jar:/usr/libexec/flowvisor/jetty-server-7.0.2.v20100331.jar:/usr/libexec/flowvisor/jetty-
util-7.0.2.v20100331.jar:/usr/libexec/flowvisor/servlet-api-
2.5.jar:/usr/libexec/flowvisor/derby.jar:/usr/libexec/flowvisor/derbytools.jar:/usr/libexec/flowvisor/jna.j
ar:/usr/libexec/flowvisor/syslog4j-0.9.46-bin.jar:/usr/libexec/flowvisor/log4j-
1.2.16.jar:/usr/libexec/flowvisor/jsonrpc2-base-1.30.jar:/usr/libexec/flowvisor/jsonrpc2-server-
1.8.jar:/usr/libexec/flowvisor/flowvisor.jar org.flowvisor.FlowVisor
2. Lihat konfigurasi awal
root@Hypervisor:/home/galih# fvctl get-config
Password:
{
"api_jetty_webserver_port": 8081,
"api_webserver_port": 8080,
"checkpointing": false,
"config_name": "default",
"db_version": "2",
"enable-topo-ctrl": true,
"flood-perm": {
"dpid": "all",
"slice-name": "fvadmin"
},
"flow-stats-cache": 30,
"flowmod-limit": {
"fvadmin": {
"00:00:00:00:00:01:01:00": -1,
"00:00:00:00:00:01:02:00": -1,
"00:00:00:00:00:01:03:00": -1,
"00:00:00:00:00:01:04:00": -1,
"00:00:00:00:00:02:01:00": -1,
"00:00:00:00:00:02:02:00": -1,
"any": null
}
},
"host": "localhost",
"log_facility": "LOG_LOCAL7",
"log_ident": "flowvisor",
"logging": "NOTE",
"stats-desc": false,
"track-flows": false,
"version": "flowvisor-1.4.0"
}
3. Lihat konfigurasi secara default
a. slice secara default, hanya ada admin slice
root@Hypervisor:/home/galih# fvctl list-slices
Password:
Configured slices:
fvadmin --> enabled
2. Tidak ada flowspace secara default
root@Hypervisor:/home/galih# fvctl list-flowspace
Password:
None
c. Pastikan semua switch telah terkoneksi
root@Hypervisor:/home/galih# fvctl list-datapaths
II
Password:
Connected switches:
1 : 00:00:00:00:00:01:01:00
2 : 00:00:00:00:00:01:02:00
3 : 00:00:00:00:00:01:03:00
4 : 00:00:00:00:00:01:04:00
5 : 00:00:00:00:00:02:01:00
6 : 00:00:00:00:00:02:02:00
d. Pastikan semua link up
root@Hypervisor:/home/galih# sudo -u flowvisor fvctl list-links
sudo: unable to resolve host Hypervisor
Password:
[
{
"dstDPID": "00:00:00:00:00:01:02:00",
"dstPort": "1",
"srcDPID": "00:00:00:00:00:01:01:00",
"srcPort": "2"
},
{
"dstDPID": "00:00:00:00:00:01:04:00",
"dstPort": "1",
"srcDPID": "00:00:00:00:00:01:02:00",
"srcPort": "2"
},
{
"dstDPID": "00:00:00:00:00:01:02:00",
"dstPort": "2",
"srcDPID": "00:00:00:00:00:01:04:00",
"srcPort": "1"
},
{
"dstDPID": "00:00:00:00:00:02:02:00",
"dstPort": "1",
"srcDPID": "00:00:00:00:00:01:04:00",
"srcPort": "3"
},
{
"dstDPID": "00:00:00:00:00:01:03:00",
"dstPort": "1",
"srcDPID": "00:00:00:00:00:01:01:00",
"srcPort": "3"
},
{
"dstDPID": "00:00:00:00:00:01:01:00",
"dstPort": "2",
"srcDPID": "00:00:00:00:00:01:02:00",
"srcPort": "1"
},
{
"dstDPID": "00:00:00:00:00:01:04:00",
"dstPort": "3",
"srcDPID": "00:00:00:00:00:02:02:00",
"srcPort": "1"
},
{
"dstDPID": "00:00:00:00:00:01:01:00",
III
"dstPort": "3",
"srcDPID": "00:00:00:00:00:01:03:00",
"srcPort": "1"
},
{
"dstDPID": "00:00:00:00:00:01:01:00",
"dstPort": "1",
"srcDPID": "00:00:00:00:00:02:01:00",
"srcPort": "1"
},
{
"dstDPID": "00:00:00:00:00:02:01:00",
"dstPort": "1",
"srcDPID": "00:00:00:00:00:01:01:00",
"srcPort": "1"
}
]
4. Slicing Topologi untuk Tenant 1: PE1, P1, P2, P4, PE2 dan Tenant2: Pe1, P1, P3, P4, PE2, buktikan disini bahwa
slice harus sama dengan graph network fisik.
a. Slicing network tenant1
sudo -u flowvisor fvctl add-slice tenant1 tcp:167.205.64.67:10000 admin_sdn1@itb.ac.id
Atau
#fvctl createSlice tenant1 tcp:167.205.64.67:10000 admin_sdn1@itb.ac.id
2. Slicing network tenant 2
sudo -u flowvisor fvctl add-slice tenant2 tcp:167.205.64.67:20000 admin_sdn2@itb.ac.id
#fvctl createSlice tenant2 tcp:167.205.64.67:20000 admin_sdn2@itb.ac.id
List tenant
root@Hypervisor:/home/galih# sudo -u flowvisor fvctl list-slices
Password:
Configured slices:
fvadmin --> enabled
tenant1 --> enabled
tenant2 --> enabled
5. Pembuatan flowspace, yaitu sebuah aturan yang akan menyalurkan suatu jenis flow dengan kategori tertentu(ip
address/network address, protocol layer4, untuk dimasukan kedalam suatu kategori slice terntentu. Dan akan
dicontroll oleh suatu pengontrol tertentu saja) dalam hal ini akan digunakan slice berdasarkan port.
untuk switch yang lainnya yang memiliki tenant berbeda di setiap port atau ada port yang disharing oleh tenant
yang berbeda untuk mengalirkan traffic, berhubung ada port yang dishare, maka ada identitas tambahan yang
dijadikan sebagai filter yaitu identitas dst dan src network layer, namun karena ada share port antar traffic kedua
tenant, maka dst dan src network layer harus berbeda, karena hal tersebut maka dst dan srcnya harus berbeda,
maka dari itu dalam flowvisor tidak boleh ada identitas layer2,3 dan 4 yang sama. Patokannya tetap pada port
a. Untuk traffic tenant 1: PE1-P1-P2-P4-PE2 dan tenant2: PE1-P1-P3-P4-PE2

#switch-pe1
#port1-tenant 1
in_port=1,nw_src=10.0.0.1,nw_dst 10.0.0.2 tenant1=7
fvctl add-flowspace switch-pe1-port1 00:00:00:02:01:00 1 in_port=1,nw_src=10.0.0.2,nw_dst 10.0.0.1
tenant1=7
#port1-tenant 2
tenant1=7
tenant1=7
#port2-tenant1
IV
fvctl add-flowspace switch-pe1-port2 00:00:00:02:01:00 1 in_port=2 tenant1=7
#port3-tenant2
#switch-pe2
#port1-tenant 1
tenant1=7
tenant1=7
#port1-tenant 2
tenant2=7
tenant2=7
#port2-tenant1
#port3-tenant2
#switch-p1
#port1-tenant 1
fvctl add-flowspace switch-p1-port1 00:00:00:01:01:00 1 in_port=1,nw_src=10.0.0.1,nw_dst 10.0.0.2
tenant1=7
tenant1=7
#port1-tenant 2
tenant2=7
tenant2=7
#port2-tenant1
fvctl add-flowspace switch-p1-port2 00:00:00:01:01:00 1 in_port=2 tenant1=7
#port3-tenant2
#switch-p2
#port1-tenant1
#port2-tenant1
#switch-p3
#port1-tenant2
#port2-tenant2
#switch-p4
#port3-tenant 1
tenant1=7
tenant1=7
#port3-tenant 2
V
tenant2=7
tenant2=7
#port1-tenant1
#port2-tenant2
b. Untuk traffic tenant1 dan tenant2: PE1-P1-P4-PE2
#switch-pe1
#port1-tenant 1
sudo -u flowvisor fvctl add-flowspace switch-pe1-port1 00:00:00:02:01:00 1
in_port=1,nw_src=10.0.0.2,nw_dst=10.0.0.1 tenant1=7
fvctl add-flowspace switch-pe1-port1 00:00:00:02:01:00 1 in_port=1,nw_src=10.0.0.1,nw_dst=10.0.0.2
tenant1=7
#port1-tenant 2
tenant1=7
#port2-tenant1
sudo -u flowvisor fvctl add-flowspace switch-pe1-port2 00:00:00:02:01:00 1 in_port=2 tenant1=7
#port3-tenant2
#switch-pe2
#port1-tenant 1
tenant1=7
in_port=1,nw_src=10.0.0.1,nw_dst 10.0.0.2 tenant1=7
#port1-tenant 2
tenant2=7
#port2-tenant1
#port3-tenant2
#switch-p1
#port1-tenant 1
sudo -u flowvisor fvctl add-flowspace switch-p1-port1 00:00:00:01:01:00 1
fvctl add-flowspace switch-p1-port1 00:00:00:01:01:00 1 in_port=1,nw_src=10.0.0.2,nw_dst=10.0.0.1
tenant1=7
#port1-tenant 2
tenant2=7
#port4-tenant 1
VI
tenant1=7
#port4-tenant 2
tenant2=7
Ssudo -u flowvisor fvctl add-flowspace switch-p1-port4 00:00:00:01:01:00 1
#switch-p4
#port3-tenant 1
tenant1=7
#port3-tenant 2
tenant2=7
#port4-tenant 1
tenant1=7
#port4-tenant 2
tenant2=7
Mac address ce-21: 00:0c:29:56:21:76

Mac address ce-22: 00:0c:29:ed:25:c6
Mac address ce-11: 00:0c:29:19:c5:4e
Mac address ce-12: 00:0c:29:de:79:31
#switch-pe1(ok)
#port1-tenant 1
in_port=1,dl_src=00:0c:29:de:79:31,dl_dst=00:0c:29:19:c5:4e,dl_type=0x0800 tenant1=7
fvctl add-flowspace switch-pe1-port1 00:00:00:02:01:00 1
in_port=1,dl_src=00:0c:29:19:c5:4e,dl_dst=00:0c:29:de:79:31,dl_type=0x0800 tenant1=7
#port1-tenant 2
in_port=1,dl_src=00:0c:29:56:21:76,dl_dst=00:0c:29:ed:25:c6,dl_type=0x0800 tenant2=7
in_port=1,dl_src=00:0c:29:ed:25:c6,dl_dst=00:0c:29:56:21:76,dl_type=0x0800 tenant2=7
#port2-tenant1
#port3-tenant2
VII
#switch-pe2(OK)
#port1-tenant 1
in_port=1,dl_src=00:0c:29:19:c5:4e,dl_dst=00:0c:29:de:79:31 tenant1=7
#port1-tenant 2
#port2-tenant1
#port3-tenant2
#switch-p1
#port1-tenant 1
fvctl add-flowspace switch-p1-port1 00:00:00:01:01:00 1
#port1-tenant 2
#port4-tenant 1
#port4-tenant 2
#tambahan untuk failover: port2-tenant1 dan port3-tenant2

sudo -u flowvisor fvctl add-flowspace switch-p1-port2 00:00:00:01:01:00 1 in_port=2 tenant1=7
#switch-p4(ok)
#port3-tenant 1
#port3-tenant 2
VIII
#port4-tenant 1
#port4-tenant 2
#tambahan untuk failover: port1-tenant1 dan port2-tenant2

#tambahkan untuk mendapatkan backup links
#switch-p2
#port1-tenant1
#port2-tenant1
#switch-p3
#port1-tenant2
#port2-tenant2
Lihat slices
root@Hypervisor:/home/galih# sudo -u flowvisor fvctl list-slices
Password:
Configured slices:
fvadmin --> enabled
tenant1 --> enabled
tenant2 --> enabled
Lihat flowspace
root@Hypervisor:/home/galih# sudo -u flowvisor fvctl list-flowspace

Password:
{"force-enqueue": -1, "name": "switch-pe1-port1", "slice-action": [{"slice-name": "tenant1",
"permission": 7}], "queues": [], "priority": 1, "dpid": "00:00:00:00:00:02:01:00", "id": 1, "match":
{"wildcards": 4194290, "dl_dst": "00:0c:29:19:c5:4e", "dl_src": "00:0c:29:de:79:31", "in_port": 1}}
{"wildcards": 4194290, "dl_dst": "00:0c:29:ed:25:c6", "dl_src": "00:0c:29:56:21:76", "in_port": 1}}
IX
{"wildcards": 4194302, "in_port": 2}}
{"wildcards": 4194290, "dl_dst": "00:0c:29:19:c5:4e", "dl_src": "00:0c:29:de:79:31", "in_port": 1}}
{"wildcards": 4194290, "dl_dst": "00:0c:29:de:79:31", "dl_src": "00:0c:29:19:c5:4e", "in_port": 1}}
{"wildcards": 4194290, "dl_dst": "00:0c:29:ed:25:c6", "dl_src": "00:0c:29:56:21:76", "in_port": 1}}
{"force-enqueue": -1, "name": "switch-p1-port1", "slice-action": [{"slice-name": "tenant1", "permission":
7}], "queues": [], "priority": 1, "dpid": "00:00:00:00:00:01:01:00", "id": 10, "match": {"wildcards":
4194290, "dl_dst": "00:0c:29:de:79:31", "dl_src": "00:0c:29:19:c5:4e", "in_port": 1}}
4194290, "dl_dst": "00:0c:29:ed:25:c6", "dl_src": "00:0c:29:56:21:76", "in_port": 1}}
4194290, "dl_dst": "00:0c:29:56:21:76", "dl_src": "00:0c:29:ed:25:c6", "in_port": 4}}
4194290, "dl_dst": "00:0c:29:56:21:76", "dl_src": "00:0c:29:ed:25:c6", "in_port": 3}}
4194290, "dl_dst": "00:0c:29:de:79:31", "dl_src": "00:0c:29:19:c5:4e", "in_port": 4}}
4194290, "dl_dst": "00:0c:29:ed:25:c6", "dl_src": "00:0c:29:56:21:76", "in_port": 4}}
Flowspace dengan tambahan backup links

{"wildcards": 4194274, "dl_type": 2048, "dl_dst": "00:0c:29:19:c5:4e", "dl_src": "00:0c:29:de:79:31",
"in_port": 1}}
{"wildcards": 4194274, "dl_type": 2048, "dl_dst": "00:0c:29:19:c5:4e", "dl_src": "00:0c:29:de:79:31",
"in_port": 1}}
X
{"wildcards": 4194290, "dl_dst": "00:0c:29:de:79:31", "dl_src": "00:0c:29:19:c5:4e", "in_port": 1}}
4194274, "dl_type": 2048, "dl_dst": "00:0c:29:de:79:31", "dl_src": "00:0c:29:19:c5:4e", "in_port": 1}}
4194274, "dl_type": 2048, "dl_dst": "00:0c:29:19:c5:4e", "dl_src": "00:0c:29:de:79:31", "in_port": 4}}
4194274, "dl_type": 2048, "dl_dst": "00:0c:29:19:c5:4e", "dl_src": "00:0c:29:de:79:31", "in_port": 3}}
4194274, "dl_type": 2048, "dl_dst": "00:0c:29:de:79:31", "dl_src": "00:0c:29:19:c5:4e", "in_port": 4}}
4194302, "in_port": 1}}
4194302, "in_port": 2}}
4194302, "in_port": 2}}
4194302, "in_port": 2}}
4194302, "in_port": 1}}
{"wildcards": 4194274, "dl_type": 2048, "dl_dst": "00:0c:29:ed:25:c6", "dl_src": "00:0c:29:56:21:76",
"in_port": 1}}
{"wildcards": 4194274, "dl_type": 2048, "dl_dst": "00:0c:29:ed:25:c6", "dl_src": "00:0c:29:56:21:76",
"in_port": 1}}
4194274, "dl_type": 2048, "dl_dst": "00:0c:29:ed:25:c6", "dl_src": "00:0c:29:56:21:76", "in_port": 1}}
4194274, "dl_type": 2048, "dl_dst": "00:0c:29:56:21:76", "dl_src": "00:0c:29:ed:25:c6", "in_port": 4}}
XI
4194274, "dl_type": 2048, "dl_dst": "00:0c:29:56:21:76", "dl_src": "00:0c:29:ed:25:c6", "in_port": 3}}
4194274, "dl_type": 2048, "dl_dst": "00:0c:29:ed:25:c6", "dl_src": "00:0c:29:56:21:76", "in_port": 4}}
4194302, "in_port": 1}}
4194302, "in_port": 2}}
4194302, "in_port": 2}}
4194302, "in_port": 3}}
6. Sisi controller:
Ada 4 buah switch untuk masing-masing tenant, dengan dpid yang sama dengan dpid fisik
XII
XIII
10. Lihat route yang terlihat di controller
root@Controller:/home/# curl
http://localhost:20001/wm/topology/route/00:00:00:00:00:02:01:00/3/00:00:00:00:00:02:02:00/3/json
[{"switch":"00:00:00:00:00:02:01:00","port":3},{"switch":"00:00:00:00:00:02:01:00","port":1},{"switch":"00:00:0
0:00:00:01:01:00","port":1},{"switch":"00:00:00:00:00:01:01:00","port":4},{"switch":"00:00:00:00:00:01:04:00",
"port":4},{"switch":"00:00:00:00:00:01:04:00","port":3},{"switch":"00:00:00:00:00:02:02:00","port":1},{"switch"
:"00:00:00:00:00
url http://localhost:10001/wm/topology/route/00:00:00:00:00:02:01:00/2/00:00:00:00:00:02:02:00/2/json
[{"switch":"00:00:00:00:00:02:01:00","port":2},{"switch":"00:00:00:00:00:02:01:00","port":1},{"switch":"00:00:0
0:00:00:01:01:00","port":1},{"switch":"00:00:00:00:00:01:01:00","port":4},{"switch":"00:00:00:00:00:01:04:00",
"port":4},{"switch":"00:00:00:00:00:01:04:00","port":3},{"switch":"00:00:00:00:00:02:02:00","port":1},{"switch"
:"00:00:00:00:00:02:02:00","port":2}]root@Controller:/home/ovx#
XIV
CLI untuk implementasi Virtual network dengan OVX
1. Pindahkan akses controller switch OF yang ada dari controller ke OVX.
ovs-vsctl set-controller vmbr0 tcp:167.205.64.68:6633
2. Implementasi Topologi 2 switch PE1 dan PE2, link virtual menghubungkan PE1 dan PE2
a. Implementasi virtualisasi
#konfigurasi untuk Tenant 1, yang menghubungkan host tenant 1.1 dan host tenant 1.2
#ubah ip address untuk skema ini, seperti berikut:
#host tenant 1.1: 10.0.0.1/16
#host tenant 1.2: 10.0.0.2/16
#1.a jalankan openvirtex
cd /OpenVirteX/scripts
sh ovx.sh
#1.b buat virtual jaringan dengan alamat virtual yang diassign secara dhcp yaitu:
10.0.0.0, alamat ini akan diassign ke pada ip address bridge ip address virtual host, test
apakah opsi ini perlu atau tidak, atau gunakan saja ip address static untuk setiap hosts
python ovxctl.py -n createNetwork tcp:167.205.64.67:10000 10.0.0.0 16
#1.c masukan PE1 dan PE2 kedalam jaringan yang baru kita buat.
#1.d buat virtual port di switch PE1 dan PE2 masing-masing di port pertama dan
kedua(lihat idnya berdasarkan log, ada penambahan 0 di depan)
#port di switch 1
#port di switch 2
XV
#1.e sambungkan antara kedua virtual port antara kedua switch virtual dan antar switch
virtual ke host
#antar switch, gunakan datapath id virtual switch yang di create dari switch1 dan
switch2, hubungkan port virtual, dan definisikan berapa jumlah backup link yang ingin di
kalkulasi(sementara baru 1 yang berhasil, 3 tidak berhasil, nanti coba 2)
python ovxctl.py -n connectLink 1 00:a4:23:05:00:00:00:01 1 00:a4:23:05:00:00:00:02 1

spf 1
#antar switch ke host, host diberi akses ke port 2 di setiap switchnya, identitas yang
digunakan adalah datapath id virtual switch dan mac address host yang dihubungkan
python ovxctl.py -n connectHost 1 00:a4:23:05:00:00:00:01 2 00:0c:29:19:c5:4e
python ovxctl.py -n connectHost 1 00:a4:23:05:00:00:00:02 2 00:0c:29:de:79:31
#1.f jalankan network 1
#screenshoot
XVI
#konfigurasi untuk Tenant 2, yang menghubungkan host tenant 2.1 dan host tenant 2.2
#ubah ip address untuk skema ini, seperti berikut:
#host tenant 2.1: 10.0.0.1/24
#host tenant 2.2: 10.0.0.2/24
#2.a jalankan openvirtex
cd /OpenVirteX/scripts
sh ovx.sh(jika sudah dilakukan dalam langkah berikutnya, maka bagian ini tidak usah dijalankan lagi)
#2.b buat virtual jaringan dengan alamat virtual yang diassign secara dhcp yaitu: 10.0.0.0, alamat ini akan
diassign ke pada ip address bridge ip address virtual host, test apakah opsi ini perlu atau tidak, atau gunakan saja
ip address static untuk setiap hosts
python ovxctl.py -n createNetwork tcp:167.205.64.67:20000 10.0.0.0 16
#2.c masukan PE1 dan PE2 kedalam jaringan yang baru kita buat.
#2.d buat virtual port di switch PE1 dan PE2 masing-masing di port 1 dan 3
XVII
#2.e sambungkan antara kedua virtual port antara kedua switch virtual dan antar switch virtual ke host
#antar switch
#antar switch ke host, host diberi id 1 dan 2
python ovxctl.py -n connectHost 2 00:a4:23:05:00:00:00:01 2 00:0c:29:56:21:76
python ovxctl.py -n connectHost 2 00:a4:23:05:00:00:00:02 2 00:0c:29:ed:25:c6
#2.f jalankan network 2
#screenshoot
#controller
XVIII
2. Konfigurasi di sisi jaringan
#akses diganti dari ip controller ke ip OVX server, caranya sama:
#ovs-vsctl set-controller vmbr0 tcp:"ip address OVX":"port ovx"
c. Selanjutnya jalankan test ping antar host dan amati flow table di setiap switch, seharusnya ada
translasi dari ip address host masing-masing tenant ke ip address internal network yaitu: 1.0.0.0/8 dan
2.0.0.0/8
d. Untuk bisa melakukan hal ini buka file internet2.py dan juga konfigurasi controller di tutorial, duplikasi
konfigurasi kontroller tersebut untuk disesuaikan.
3. Implementasi topologi dengan graph yang sesuai dengan graph network fisik: Tenant1: PE1, P1, P2, P4, PE2
dan Tenant2: PE1, P1, P3, P4, PE2
4. Penambahan fitur QoS di sisi Controller
5. Implementasi big switch
a. Buat konfigurasi sebagai berikut untuk tenant1 dan tenant 2:
{ {
"id": "1", "id": "2",
"jsonrpc": "2.0", "jsonrpc": "2.0",
"method": "createNetwork", "method": "createNetwork",
"params": { "params": {
"network": { "network": {
"controller": { "controller": {
"ctrls": [ "ctrls": [
"tcp:167.205.64.67:10000" "tcp:167.205.64.67:20000"
], ],
"type": "custom" "type": "custom"
}, },
"hosts": [ "hosts": [
XIX
{ {
"dpid": "dpid":
"00:00:00:00:00:02:01:00", "00:00:00:00:00:02:01:00",
"mac": "mac":
"00:0c:29:19:c5:4e", "00:0c:29:56:21:76",
"port": 2 "port": 3
}, },
{ {
"dpid": "dpid":
"00:00:00:00:00:02:02:00", "00:00:00:00:00:02:02:00",
"mac": "mac":
"00:0c:29:de:79:31", "00:0c:29:ed:25:c6",
"port": 2 "port": 3
} }
], ],
"routing": { "routing": {
"algorithm": "spf", "algorithm": "spf",
"backup_num": 1 "backup_num": 1
}, },
"subnet": "192.168.0.0/24", "subnet": "192.168.0.0/24",
"type": "bigswitch" "type": "bigswitch"
} }
} }
} }
2. Jalankan embedder.py untuk json RPC server
#python utils/embedder.py
2015-12-22 08:20:05,780 JSON RPC server starting
2015-12-22 08:22:21,384 Physical network topology received
2015-12-22 08:22:21,431 Network with tenantId 1 has been created
2015-12-22 08:22:21,460 Switch with switchId 00:a4:23:05:00:00:00:01 has been created
2015-12-22 08:22:21,464 Internal routing of switch 00:a4:23:05:00:00:00:01 has been set

to spf
2015-12-22 08:22:21,479 Port on switch 00:a4:23:05:00:00:00:01 with port number 1 has

been created
2015-12-22 08:22:21,494 Host with hostId 1 connected
2015-12-22 08:22:21,499 Port on switch 00:a4:23:05:00:00:00:01 with port number 2 has

been created
XX
2015-12-22 08:22:21,511 Host with hostId 2 connected
2015-12-22 08:22:21,563 Network with tenantId 1 has been started
127.0.0.1 - - [22/Dec/2015 08:22:21] "POST / HTTP/1.1" 200 -
c. Masukan topologi Bigswitch
#curl localhost:8000 -X POST -d @bigswitchtenant1.json
#curl localhost:8000 -X POST -d @bigswitchtenant2.json
{"jsonrpc": "2.0", "result": {"tenantId": 1}, "id": "1"}
{"jsonrpc": "2.0", "result": {"tenantId": 2}, "id": "2"}
d. Lihat hasilnya dan lakukan percobaan
XXI
XXII
Lampiran B
Data mentah Pengukuran Delay, Jitter, Throughput
1. FlowVisor tanpa cache flow
64 bytes from 10.0.0.1: icmp_seq 1 ttl 64 time 17.3 ms

64 bytes from 10.0.0.1: icmp_seq 12 ttl 64 time 1 ms
XXIII
XXIV
2. Pengukuran OpenVirtex dengan cache flow

XXV
XXVI
XXVII
3. Pengukuran OpenVirtex tanpa cache flow

XXVIII
XXIX
4. Pengukuran testbed

XXX
XXXI
5. Pengujian Througput FlowVisor
XXXII
Pengujian
Througput TCP
No pengujian Througput(Mbits/second)
1 931
2 925
3 936
4 937
5 933
6 904
7 930
8 936
9 925
10 867
Pengujian
Througput UDP
No pengujian Througput(Mbits/second)
1 993
2 993
3 994
4 995
5 993
6 995
7 993
8 994
9 993
10 994
6. Pengujian Througput OpenVIrtex
Pengujian Througput TCP

No
pengujian Througput(Mbits/second)
1 904
2 946
3 841
4 830
5 929
6 904
7 938
XXXIII
8 948
9 936
10 948
Pengujian Througput UDP

No
1 992
2 992
3 994
4 993
5 993
6 995
7 993
8 993
9 993
10 994
7. Pengujian Througput testbed
Pengujian Througput TCP

No
1 925
2 941
3 932
4 930
5 929
6 950
7 941
8 952
9 953
10 943
Pengujian Througput UDP

No
1 996
2 998
XXXIV
3 991
4 994
5 997
6 995
7 993
8 993
9 993
10 994
XXXV

Mou Jualan Beras

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Mou Jualan Beras

Diunggah oleh

Hak Cipta:

Format Tersedia

DESAIN DAN IMPLEMENTASI VPN SITE-TO-SITE

BERBASIS SDN MENGGUNAKAN NETWORK HYPERVISOR:

Karya tulis sebagai salah satu syarat

GALIH NUGRAHA NURKAHFI

SEKOLAH TEKNIK ELEKTRO DAN INFORMATIKA

DESAIN DAN IMPLEMENTASI VPN SITE-TO-SITE BERBASIS SDN

GALIH NUGRAHA NURKAHFI

Program Magister Teknik Elektro

Kata Kunci: Software Defined Networking, OpenFlow, Virtualisasi, Network hypervisor,

GALIH NUGRAHA NURKAHFI

Electrical Engineering Master Program

Key Word: Software Defined Networking, OpenFlow, Virtualization, Network hypervisor,

DESAIN DAN IMPLEMENTASI VPN SITE-TO-SITE BERBASIS SDN

Galih Nugraha Nurkahfi

Bandung, 1 Februari 2016

Dr. Ing. Eueung Mulyana, S.T., M.Sc.

Memperbanyak atau menerbitkan sebagian atau seluruh tesis haruslah seizin

Alhamdulillahirabbil'alamin, dengan mengucapkan syukur kehadirat Allah SWT yang

Bandung, 1 Februari 2016

API Application Programming Interface

Gambar II-1 Arsitektur Sederhana SDN………………………………………………………....7

Tabel II-1 Versioning OpenFlow..………………………………………………………………11

I.1 Latar Belakang

I.2 Rumusan Masalah

Permasalahan yang diangkat pada penelitian ini adalah:

Tujuan dari penelitian ini adalah:

I.4 Batasan Masalah

I.5 Metoda Penelitian

Metoda yang dilakukan pada penelitian ini adalah:

Penulisan laporan tesis ini disusun dengan sistematika sebagai berikut:

BAB II : Tinjauan Pustaka

BAB III : Metodologi Penelitian dan Desain Percobaan

BAB IV :Hasil Percobaan dan Analisis

BAB V: Kesimpulan dan Saran

II.1 Jaringan Tradisional Sebelum Adanya SDN

II.2 SDN, OpenFlow dan Cara Kerjanya

II.3 Protokol OpenFlow

Tabel II-1 Versioning OpenFlow

Elemen SDN Perubahan spesifikasi kemampuan Switch OFP Versi OFP

Berikut adalah format header dari protokol OpenFlow.

Switch MAC MAC Eth VLAN IP IP IP Port Port

Gambar II-3 Header OpenFlow

Tabel berikut berisi penjelasan mengenai isi dari Header OpenFLow.

Tabel II-2 Penjelasan Header OpenFlow

Field Bits Diterapkan pada Keterangan

Dst MAC Semua paket yang

Src MAC Semua paket yang

Ethernet Type Semudiaktifkana paket Openflow switch yang membutuhkan standar

Vlan ID Semua paket dengan tipe

Vlan Priority Semua paket dengan tipe VLAN PCP field

Dst IP Semua IP dan Paket ARP Bisa dengan subnet mask

Src IP Semua IP dan Paket ARP Bisa dengan subnet mask

TCP/UDP Src Semua TCP, UDP, ICMP

Rule Action Stats

Packet + Byte Counters

 Forward Paket ke port atau banyak port

Switch MAC MAC Eth VLAN IP IP IP Port Port

Gambar II-4 Cara Kerja OpenFlow

Gambar II-5 Diagram Switch OpenFlow

Gambar II-6 Flow Paket Data Di dalam OpenFlow 1.0[5]

II.6 Reactive dan Proactive Flow

II.6.1 Reactive Flow

Gambar II-7 Mekanisme Reactive Flow[7]