BAB III METODOLOGI PENELITIAN
3.2 Integrasi Komponen Penelitian
Tampilan hasil dari konfigurasi Mininet dan integrasinya terhadap controller dapat dilihat pada CLI dari Mininet di Gambar 3.6. Dapat dilihat pada skenario pertama seluruh switch terhubung pada sebuah controller yaitu c1. Pada skenario kedua ada 2 controller yaitu c1 dan c2, dan pada skenario ketiga terdapat tiga controller yaitu c1, c2 dan c3. Pada tampilan tersebut terlihat terhubungnya jaringan dengan jumlah controller
Gambar 3.6. Tampilan Mininet untuk skenario penelitian
ONOS dilengkapi dengan GUI untuk melihat tampilan topologi yang dibentuk.
Gambar hasil konfigurasi jaringan terhadap tiga skenario penelitian dapat dilihat pada Gambar 3.7 dan Gambar 3.8. Dapat dilihat pada GUI, setiap pasangan controller dan switch digambarkan dengan warna yang sama. Pada CLI, terlihat pasangan dari switch dengan controller yang menjadi master terhadapnya.
Gambar 3.7. Tampilan GUI pada ONOS untuk skenario penelitian
Gambar 3.8. Tampilan CLI pada ONOS terhadap skenario penelitian
Pada penelitian ini, penulis menamai container yang dibentuk pada LXC dengan nama instansi-satu, instansi-dua dan instansi-tiga. Untuk veth pada tiap container penulis menamainya veth-satu, veth-dua dan veth-tiga. Hasil konfigurasi tersebut dapat dilihat pada Gambar 3.9. Tiap container diberi alamat IP sesuai alamat pada tiap controller.
Gambar 3.9. Tampilan konfigurasi LXC untuk penelitian
BAB IV
HASIL PENELITIAN DAN PEMBAHASAN
4.1 Hasil Perhitungan Pada Penelitian 4.1.1 Hasil Perhitungan Latency
Pengukuran latency dilakukan terhadap host 1 dan host 6 dengan pengiriman paket ICMP. Untuk tiap skenario penelitian, dilakukan tiga kali percobaan, dimana setiap percobaan dilakukan pengiriman paket ICMP sebanyak 20 sequence/urutan. Hasil pengukuran dapat dilihat pada Tabel 4.1, Tabel 4.2, dan Tabel 4.3. Satuan latency adalah milliseconds (ms).
Tabel 4.1. Nilai latency pada penilitian untuk skenario 1
Urutan Skenario 1
Percobaan 1 Percobaan 2 Percobaan 3
1 57.2 105 62.5
19 0.137 0.155 0.107
20 0.156 0.174 0.167
Tabel 4.2. Nilai latency pada penilitian untuk skenario 2
Urutan Skenario 2
Percobaan 1 Percobaan 2 Percobaan 3
1 91 118 94.1
Tabel 4.3. Nilai latency pada penilitian untuk skenario 3
Urutan Skenario 3
Percobaan 1 Percobaan 2 Percobaan 3
1 105 100 113
2 1.98 1.98 2.44
3 0.136 0.124 0.149
4 0.091 0.129 0.088
5 0.103 0.096 0.14
7 0.098 0.137 0.231
4.1.2 Hasil Perhitungan Throughput
Pengukuran throughput dilakukan dengan aplikasi iperf dengan mengirimkan paket TCP antara host 1 dan host 6. Pengiriman iperf dilakukan sebanyak 10 kali. Hasil pengukuran terlihat pada Tabel 4.4, dimana satuan dari throughput dalam Gigabit tiap detik (Gbit/s).
Tabel 4.4. Nilai throughput pada tiap skenario penelitian Percobaan Skenario 1 Skenario 2 Skenario 3
1 17.7 18.4 19.5
4.2 Analisis Hasil Penelitian
4.2.1 Analisis Hasil Virtualisasi terhadap Container
Dilihat dari output CLI pada ONOS, identitas setiap switch yang berada pada emulasi jaringan ketika berkomunikasi dengan controller dalam control network menggunakan alamat IP dari lxcbr0 namun dengan port komunikasi yang berbeda-beda. Nomor port ini diberi secara acak. Untuk analisis, penulis mengunakan instansi 2 pada skenario penelitian 3. Pada gambar tersebut tampak perangkat pada jaringan yang dilihat oleh instansi 2 dari controller.
Gambar 4.1. Tampilan perangkat yang dilihat oleh instansi 2
Pada Gambar 4.1 juga dapat dilihat bahwa instansi 2 menjadi controller untuk switch 2 dan 5 (sesuai dengan skenario 3) dimana switch 2 terhubung dengan controller melalui port 36234 dan switch 5 melalui port 36243. Sebuah controller dalam jaringan Openflow mengirimkan paket broadcast secara periodik untuk mendeteksi topologi jaringan. Dalam hal ini, controller menggunakan Link Layer Discovery Protocol atau LLDP (Hu, 2014).
Berdasarkan pengamatan penulis, controller ONOS yang digunakan dalam penelitian menggunakan alamat de:ad:be:ef:ba:11 untuk pengiriman paket LLDP. Pada Gambar 4.2 dapat dilihat controller hanya mengirimkan pakett LLDP ke switch yang dikontrolnya.
Gambar 4.2. Paket Link Layer Discovery Protocol (LLDP)
Untuk melihat alur paket komunikasi controller dan switch, dijalankan paket ICMP antara host 1 dan host 6 (yang melewati switch yang dikontrol controller yang berbeda). Pada gambar 4.3, dapat dilihat bahwa instansi 2 hanya menerima packet-in dan packet-out dari switch yang menjadi bawahannya yaitu switch 2 dan 5.
Gambar 4.3. Komunikasi packet-in dan packet-out pada instansi 2
Paket packet-in dan packet-out yang diterima oleh instansi 2 berupa pertanyaan dari switch mengenai proses yang perlu dilakukan seputar paket ICMP yang diterima. Pada Gambar 4.3 tersebut juga tampak jenis paket ICMP tersebut, dimana Type 8 adalah echo request dan 0 adalah echo reply. Dari pengiriman paket ICMP tersebut, dapat dilihat bahwa switch 2 dan 5 berkomunikasi dengan instansi ke 2 dari controller, sehingga virtualisasi dan pemisahan kontrol dapat dikatakan telah berhasil.
4.2.2 Analisis Terhadap Jaringan Data
Berdasarkan hasil pengukuran pada Tabel 4.1, Tabel 4.2 dan Tabel 4.3, dapat dilihat bahwa nilai latency tertinggi terletak pada 2 sequence pertama. Grafik yang menunjukkan hasil pengukuran latency tersebut dapat dilihat pada Gambar 4.4, Gambar 4.5 dan Gambar 4.6.
Gambar 4.4. Grafik perhitungan latency pada percobaan 1
Gambar 4.5. Grafik perhitungan latency pada percobaan 2
Gambar 4.6. Grafik perhitungan latency pada percobaan 3
Berdasarkan grafik pada Gambar 4.4, Gambar 4.5, dan Gambar 4.6 dapat dilihat bahwa latency komunikasi pada jaringan data tidak berbeda jauh. Skenario satu digambarkan dengan warna biru, skenario dua warna merah, dan skenario tiga dengan warna hijau. Adapun latency tertinggi terjadi pada awal komunikasi.
Selain karena delay untuk packet-in dan packet-out yang dijelaskan pada sub bab 4.2.1, paket baru yang terlihat pada Wireshark adalah Address Resoulution Protocol (ARP), dimana host 1 mengirimkan paket broadcast ARP untuk mencari host 6. Dapat dilihat pada Gambar 4.7, yang merupakan daftar paket ARP yang muncul dan ditangkap pada lxcbr0 sejak paket ICMP dijalankan.
Gambar 4.7. Paket ARP pada awal komunikasi jaringan data
Untuk nilai latency terhadap sequence ICMP setelah proses ARP, pada tiap skenario memiliki nilai dibawah 1 ms. Sepanjang pengetahuan penulis, belum ada standarisasi kelayakan nilai latency pada jaringan LAN. Nilai latency terbaik yang diharapkan tentunya adalah 0 ms. Namun hal tersebut tidak memungkinkan dikarenakan ada faktor sumber datangnya latency, mulai dari delay propagasi sinyal, delay antarmuka jaringan untuk serialisasi, delay pemrosesan jaringan, delay di dalam perangkat dan delay antrian (Kay, 2016).
Melihat faktor tersebut dan membandingkan latency pada skenario penelitian mendekati 0 ms, maka penulis melihat trafik cukup baik dan normal.
Grafik pengukuran throughput dapat dilihat pada Gambar 4.8.
Percobaan pengukuran throughput dilakukan sebanyak 10 kali terhadap ketiga skenario penelitian.
Gambar 4.8. Grafik pengukuran throughput
Pada gambar tersebut dapat dilihat throughput yang diperoleh dari ketiga skenario bervariasi dengan percobaan ketiga skenario setelah dilakukan percobaan sebanyak sepuluh kali dari host 1 ke host 6. Ketika penulis mengirimkan paket TCP untuk mengukur throughput melalui iperf dari host 1 ke host 6 , penulis menemukan adanya delay berupa TCP retransmisson dan TCP out of order. Seperti pada Gambar 4.9 dalam skenario 1. TCP retransmission dan TCP out of order terlihat pada komunikasi antara switch dengan controller yang menjadi pusatnya.
0 5 10 15 20 25
1 2 3 4 5 6 7 8 9 10
Throughput (Gb/s)
Nomor Percobaan
Skenario 1 Skenario 2 Skenario 3
Gambar 4.9. Delay terhadap TCP pada skenario 1
Pada skenario tiga, seluruh instansi controller juga menerima TCP retransmission dan TCP out of order lebih sedikit, dikarenakan fungsi controller telah dibagi sehingga tidak seperti skenario 1 dimana controller melakukan kontrol terhadap seluruh switch. Hal ini dapat dilihat pada Gambar 4.10.
Gambar 4.10. Delay terhadap TCP pada instansi 3 dalam skenario 3.
Peringatan retransmission pada Wireshark muncul ketika Wireshark mendeteksi dua paket data dengan urutan/sequence yang sama. Pengirim akan mengirimkan kembali (retransmit) data tersebut ketika dia tidak menerima acknowledgement dari paket yang dikirimkan dalam jangka waktu yang ditentukan. Sementara peringatan out of order mengindikasikan bahwa Wireshark mendeteksi paket yang bergerak melalui jalur yang tidak tepat.
Peringatan ini pada umumnya tidak menjadi masalah, kecuali batas waktu penerima untuk menerima paket out of order tersebut telah lewat (Chappel, 2013). Berdasarkan hasil pengamatan penulis, tidak ditemukan indikasi lain dari komunikasi data melalui ONOS dan switch, yang berpengaruh terhadap throughput. Throughput yang diterima pada ketiga skenario berada pada rentang 17.7 s/d 22.1 dimana rata-rata throughput dalam sepuluh kali percobaan untuk skenario 1, skenario 2 dan skenario 3 masing-masing adalah 194.5, 193.1 dan 194.5. Berdasarkan data tersebut, penulis melihat throughput tetap stabil dalam keadaan dilakukan virtualisasi.
BAB V
KESIMPULAN DAN SARAN
5.1 Kesimpulan
Berdasarkan hasil pengukuran dan analisis yang dilakukan pada penelitian ini, dapat disimpulkan bahwa :
1. Konsep virtualisasi dapat diterapkan dengan baik pada controller dalam jaringan LAN berbasis Openflow yang diemulasikan, dimana komunikasi switch dalam control network dapat dibagi sesuai dengan jumlah instansi yang dibentuk. Trafik data dari switch pada control network tetap berkomunikasi pada instansi controller yang menjadi pusatnya.
2. Virtualisasi pada jaringan umumnya digunakan untuk optimasi/meningkatkan fungsi manajemen maupun keamanan. Dengan nilai latency dan throughput yang tidak berpengaruh terhadap penambahan jumlah instansi dalam jaringan LAN berbasis Openflow, maka berdasarkan hasil emulasi, konsep virtualisasi tepat untuk diterapkan pada implementasi jaringan tersebut.
5.1 Saran
Adapun saran dari penelitian ini yang dapat digunakan untuk penelitian yang akan dating adalah:
1. Dengan virtualisasi controller, switch hanya akan berkordinasi dengan instansi controller yang menjadi pusatnya. Dengan dimungkinkannya pemisahan instansi ini, dapat ditingkatkan kemampuan manajeman jaringan seperti penerapan Quality of Service (QoS) maupun peningkatan keamanan untuk melindungi control network yang terpisah secara logika. Penulis berpendapat perlu diadakan kajian untuk hal tersebut.
2. Penerapan virtualisasi pada jaringan salah satunya adalah untuk mendukung sistem distribusi, dimana sumber daya sebuah sistem dapat diperbantukan
untuk sistem lain. Dengan virtualisasi controller, dapat mendukung konsep tersebut, dimana sumber daya controller dapat diperbantukan ke jaringan lain khususnya yang berbeda lokasi secara fisik (remote area). Penulis berpendapat perlunya kajian lebih lanjut terhadap hal tersebut.
DAFTAR PUSTAKA
Azodolmolky, S. 2013. Software Defined Networking with Openflow. PACKT Publishing: Birmingham.
Benton, K., Camp, L.J., Small, C. 2013. Openflow Vulnerability Assessment.
HotSDN’13 Proceedings of The Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networks. Pp. 151-152.
Chappel, L. 2010. Wireshark Network Analysis. Protocol Analysis Institute:
San Jose.
Chappel, L. 2013. Wireshark 101 Essential Skills for Network Analysis.
Protocol Analysis Institute: San Jose.
Duarte, O.C.M.B., Pujolle, G. 2013. Virtual Networks. ISTE Ltd: London.
Flowgrammable. 2016. (Online). http://flowgrammable.org/sdn/openflow /#tab_switch (28 Juni 2016).
Heller, B., Sherwood, R. & McKeown, N. 2012. The Controller Placement Problem. HotSDN’12 Proceedings of The First Workshop on Hot Topics in Software Defined Networks, pp. 7-12.
Hu, F. 2014. Network Innovation through Openflow and SDN. CRC Press: Boca Raton.
Kay, R. 2016. Pragmatic Network Latency Engineering Fundamental Facts and Analysis. (Online) https://www.cpacket.com/wp-content/uploads/2016 /03/introductiontonetworklatencyengineering.pdf (28 Juni 2016).
Marschke, D., Doyle, J., Moyer, P. 2015. Software Defined Networking:
Anatomy of Openflow. Lulu Publishing Services: Raleigh.
Mininet Overview. (Online) http://mininet.org/overview (17 Agustus 2016).
Nadeau, T.D. & Gray, K. 2013. SDN: Software Defined Networks. O’Reilly Media: Sebastopol.
Open Networking Foundation. 2014. The Benefits of Multiple Flow Tables and TTPs. (Online) https://www.opennetworking.org/images/stories/downl oads/sdn-resources/technical-reports/TR_Multiple_Flow_Tables_and _TTPs.pdf (9 Oktober 2015).
Peterson, L., Davie, B. 2003. Computer Networks a System Approach. Morgan Kauffman Publisher: San Francisco.
The Open Networking Lab. 2014. Introducing ONOS – a SDN Network Operating System for Service Providers. (Online) htp://onosproject.org /wp-content/uploads/2014/11/Whitepaper-ONOS-final.pdf (9 Oktober 2015).
The Open Networking Lab. (Online) https://wiki.onosproject.org/display/ON OS/Guides (9 Oktober 2015).
Turull, D., Hidell, M., Sjödin, P. 2014. Performance Evaluation of Openflow Controllers for Network Virtualization. 2014 IEEE 15th International Conference on High Performance Switching and Routing (HPSR), pp.
50-56.
Ubuntu Documentation. (Online) https://help.ubuntu.com/lts/serverguide/lxc.
html (9 Oktober 2015).
LAMPIRAN PROGRAM MININET
Untuk skenario 1 sebagai berikut :
#!/usr/bin/env python
from mininet.node import RemoteController, OVSKernelSwitch from mininet.log import setLogLevel
#info('***menambahkan switch\n***')
#info('***menjalankan CLI\n***')
Untuk skenario 2 sebagai berikut :
#!/usr/bin/env python
from mininet.node import RemoteController, OVSKernelSwitch from mininet.log import setLogLevel
#info('***menambahkan host\n***')
c2.start()
Untuk skenario 3 sebagai berikut :
#!/usr/bin/env python
from mininet.node import RemoteController, OVSKernelSwitch from mininet.log import setLogLevel
def skenario1():
#info('***menambahkan controller\n***')
net.addLink(s1,s2)
LAMPIRAN KONFIGURASI ONOS DAN LXC
Konfigurasi ONOS untuk 1 instansi : export ONOS_NIC=10.0.3.*
Konfigurasi ONOS untuk 2 instansi : export ONOS_NIC=10.0.3.*
Konfigurasi ONOS untuk 3 instansi : export ONOS_NIC=10.0.3.*
Konfigurasi LXC pada container instansi-satu : lxc.network.type = veth
lxc.network.link = lxcbr0
lxc.network.flags = up
Konfigurasi jaringan untuk LXC pada container instansi-satu : auto eth0
Konfigurasi LXC pada container instansi-dua : lxc.network.type = veth
Konfigurasi jaringan untuk LXC pada container instansi-dua : auto eth0
Konfigurasi LXC pada container instansi-tiga : lxc.network.type = veth
lxc.network.link = lxcbr0 lxc.network.flags = up
lxc.network.hwaddr = 00:16:3e:45:01:89 lxc.start.auto=1
lxc.rootfs = /var/lib/lxc/instansi-tiga/rootfs lxc.utsname = instansi-tiga
lxc.network.veth.pair = veth-tiga
Konfigurasi jaringan untuk LXC pada container instansi-tiga : auto eth0
iface eth0 inet static address 10.0.3.13 netmask 255.255.255.0 gateway 10.0.3.1
dns-nameservers 10.0.3.1