BAB 4 ANALISA DAN EVALUASI
4.1 Data Implementasi Sistem Berikut ini adalah hasil dump dari routing rule yang diimplementasikan pada sistem # jan/24/2013 22:20:59 by RouterOS 5.21 # perangkat lunak id = V5L2-FEHH Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 0 A S ;;; POLICY-BASED ROUTING GATEWAY1 FAILOVER dst-address=0.0.0.0/0 gateway=202.146.4.100 gateway-status=202.146.4.100 rekursif via 192.168.20.254 ether1 check-gateway=ping distance=1 scope=30 target-scope=10 routing-mark=gw1.r 1 S dst-address=0.0.0.0/0 gateway=202.146.4.201 gateway-status=202.146.4.201 rekursif via 192.168.21.254 ether2 check-gateway=ping distance=2 scope=30 target-scope=10 routing-mark=gw1.r 2 S dst-address=0.0.0.0/0 gateway=202.146.4.250 gateway-status=202.146.4.250 rekursif via 192.168.22.254 ether3 check-gateway=ping distance=3 scope=30 target-scope=10 routing-mark=gw1.r 3 A S ;;; POLICY-BASED ROUTING GATEWAY2 FAILOVER dst-address=0.0.0.0/0 gateway=202.146.4.201
34
35
gateway-status=202.146.4.201 rekursif via 192.168.21.254 ether2 check-gateway=ping distance=1 scope=30 target-scope=10 routing-mark=gw2.r 4 S dst-address=0.0.0.0/0 gateway=202.146.4.250 gateway-status=202.146.4.250 rekursif via 192.168.22.254 ether3 check-gateway=ping distance=2 scope=30 target-scope=10 routing-mark=gw2.r 5 S dst-address=0.0.0.0/0 gateway=202.146.4.100 gateway-status=202.146.4.100 rekursif via 192.168.20.254 ether1 check-gateway=ping distance=3 scope=30 target-scope=10 routing-mark=gw2.r 6 A S ;;; POLICY-BASED ROUTING GATEWAY3 FAILOVER dst-address=0.0.0.0/0 gateway=202.146.4.250 gateway-status=202.146.4.250 rekursif via 192.168.22.254 ether3 check-gateway=ping distance=1 scope=30 target-scope=10 routing-mark=gw3.r 7 S dst-address=0.0.0.0/0 gateway=202.146.4.100 gateway-status=202.146.4.100 rekursif via 192.168.20.254 ether1 check-gateway=ping distance=2 scope=30 target-scope=10 routing-mark=gw3.r 8 S dst-address=0.0.0.0/0 gateway=202.146.4.201 gateway-status=202.146.4.201 rekursif via 192.168.21.254 ether2 check-gateway=ping distance=3 scope=30 target-scope=10 routing-mark=gw3.r
36
9 A S ;;; INBOUND dst-address=0.0.0.0/0 gateway=192.168.20.254 gateway-status=192.168.20.254 reachable via ether1 check-gateway=ping distance=1 scope=30 target-scope=10 routing-mark=line1.r 10 A S dst-address=0.0.0.0/0 gateway=192.168.21.254 gateway-status=192.168.21.254 reachable via ether2 check-gateway=ping distance=1 scope=30 target-scope=10 routing-mark=line2.r 11 A S dst-address=0.0.0.0/0 gateway=192.168.22.254 gateway-status=192.168.22.254 reachable via ether3 check-gateway=ping distance=1 scope=30 target-scope=10 routing-mark=line3.r 12 ADC dst-address=192.168.18.0/29 pref-src=192.168.18.1 gateway=ether5 gateway-status=ether5 reachable distance=0 scope=10 13 ADC dst-address=192.168.20.0/24 pref-src=192.168.20.4 gateway=ether1 gateway-status=ether1 reachable distance=0 scope=10 14 ADC dst-address=192.168.21.0/24 pref-src=192.168.21.4 gateway=ether2 gateway-status=ether2 reachable distance=0 scope=10 15 ADC dst-address=192.168.22.0/24 pref-src=192.168.22.4 gateway=ether3 gateway-status=ether3 reachable distance=0 scope=10
37
16 A S dst-address=192.168.23.0/24 gateway=192.168.18.2 gateway-status=192.168.18.2 reachable via ether5 distance=1 scope=30 target-scope=10 17 A S dst-address=192.168.142.0/24 gateway=192.168.18.2 gateway-status=192.168.18.2 reachable via ether5 distance=1 scope=30 target-scope=10 18 A S ;;; NEXTHOP CHECKING dst-address=202.146.4.100/32 gateway=192.168.20.254 gateway-status=192.168.20.254 reachable via ether1 check-gateway=ping distance=1 scope=10 target-scope=10 19 A S dst-address=202.146.4.201/32 gateway=192.168.21.254 gateway-status=192.168.21.254 reachable via ether2 check-gateway=ping distance=1 scope=10 target-scope=10 20 A S dst-address=202.146.4.250/32 gateway=192.168.22.254 gateway-status=192.168.22.254 reachable via ether3 check-gateway=ping distance=1 scope=10 target-scope=10
Pemeriksaan jalur pada masing-masing interface yang mengarah ke ISP dilakukan melalui parameter check-gateway pada rule yang berkaitan (baris 18-20) dengan melakukan ICMP echo request ke alamat yang didefinisikan pada parameter gateway pada rule tersebut. ICMP echo reply kemudian menentukan aktif atau tidaknya rule tersebut. Kemudian rule tersebut diberikan prioritas dengan memberikan nilai scope yang sesuai[mikrotik]. Dari pengaturan diatas, apabila nilai dari parameter dst-address pada rule tersebut digunakan kembali pada rule yang lain, misalnya sebagai parameter
38
gateway, maka router akan melakukan proses nexthop resolve dan menentukan immediate nexthop dari rule yang baru, yaitu gateway dari rule pada baris 18-20. Kemudian proses tersebut memberikan keterangan bahwa gateway untuk rule baru tersebut adalah gateway rekursif. Hal ini dimanfaatkan penulis untuk memperoleh efek failover untuk masing-masing routing-mark pada penelitian ini. Memanfaatkan efek yang dihasilkan dari algoritma tersebut, penulis menerapkan rule redundan dengan distance yang lebih besar dari rule yang digunakan untuk memberikan default gateway, sehingga apabila hasil dari proses check-gateway adalah tidak aktif, maka rule dengan distance lebih tinggi di bawahnya akan menjadi aktif dan proses routing untuk koneksi dengan routing-mark yang bersangkutan akan menggunakan rule yang baru saja menjadi aktif tersebut. Berikut ini adalah tampilan dari hasil mark-connection pada sistem yang diterapkan penulis:
39
Gambar 9 Screenshot Connection Tracking
Pada gambar di atas, setiap entry yang tampil adalah hasil dari penandaan koneksi dengan algoritma PCC yang diterapkan penulis pada sistem, dengan parameter klasifikasi berdasarkan source address, destination address, source port dan destination port. Efek dari konfigurasi tersebut akan menghasilkan penandaan yang cenderung tidak berpola, dengan contoh dari pengambilan data di atas, koneksi dari host 192.168.18.2 (merupakan host dari LAN) ke 31.13.79.23, diketahui
40
merupakan salah satu alamat IP dari www.facebook.com, memiliki beberapa connection-mark yang berbeda (baris 2 sampai baris 8), perbedaan tersebut terjadi karena beberapa koneksi tersebut memiliki source port yang berbeda. Penandaan tersebut akan memberikan efek pembagian beban, mengingat connection-mark tersebut akan diproses dengan rule routing yang berbeda pula. Kemudian berikut ini ditampilkan hasil traceroute dari salah satu perangkat yang terpasang pada jaringan lokal dari sistem yang diterapkan penulis :
Gambar 10 Hasil Traceroute
Traceroute dilakukan dari router yang terkoneksi pada interface LAN pada sistem yang diterapkan penulis pada tanggal 20 Januari 2013 pukul 17:02, traceroute dilakukan dengan menggunakan perintah trace melalui telnet ke router warnet
41
DFS.net dengan selang waktu 5 detik untuk setiap eksekusi perintah. Perbedaan jalur (pembagian beban) mulai terlihat dari hop kedua pada output perintah traceroute tersebut, perbedaan jalur yang ditempuh tersebut merupakan akibat dari penerapan algoritma penandaan PCC yang dikombinasikan dengan penerapan routing rule yang berbeda-beda, seperti dipaparkan pada bagian penandaan koneksi di atas.
4.2 Data hasil pembebanan
Gambar 11 Grafik Pembebanan Jalur ISP
Gambar 9 merupakan pembebanan jalur tersebut diambil pada tanggal 15 Desember 2012 pukul 18:15, data tersebut menggambarkan kondisi pemakaian jalur pada tiga buah interface yang mengarah ke ISP. Grafik tersebut merupakan penggambaran dampak pembebanan setelah penerapan load balancing dengan algoritma PCC, yang menunjukkan efektifitas maksimal pembagian beban pada jamjam sibuk. Ketidakseimbangan pembagian beban pada jam-jam tidak sibuk merupakan dampak penggunaan algoritma penandaan PCC yang tidak melakukan pemecahan paket, algoritma yang menyebabkan ketidakseimbangan tersebut
42
dikarenakan pada saat jam tersebut ada salah satu user yang membuat connection dengan transaksi data yang besar, sedangkan user yang lain membuat connection dengan transaksi data yang tidak sebesar user yang pertama. Sebagai informasi tambahan, pihak ISP 2 dan ISP 3 sedang melakukan perbaikan (maintenance) pada pukul 04.00 - 08.00. Pada saat itu, sistem failover yang diterapkan penulis telah bekerja dan dapat menyesuaikan dengan kondisi gangguan dari pihak ISP tersebut.
4.3
Analisa Fail-Over Implementasi fail-over yang dapat dilihat pada hasil dump dari routing rule
menunjukkan bahwa untuk mark-routing gw1.r urutan gateway yang digunakan adalah 192.168.20.254, kemudian 192.168.21.254 sebagai gateway kedua dan 192.168.22.254 sebagai gateway ketiga. Untuk mark-routing gw2.r urutan gateway yang digunakan adalah 192.168.21.254, kemudian 192.168.22.254 sebagai gateway kedua dan 192.168.20.254 sebagai gateway ketiga. Dan untuk mark-routing gw3.r urutan gateway yang digunakan adalah 192.168.22.254, kemudian 192.168.20.254 sebagai gateway kedua dan 192.168.21.254 sebagai gateway ketiga. Pemilihan secara rekursif ini dilakukan secara berkesinambungan bersamaan dengan pemeriksaan kondisi gateway yang dilakukan dengan melakukan pengiriman ICMP echo request secara berkelanjutan [kutip check-gateway]. Seandainya terjadi kegagalan pada pemeriksaan salah satu gateway, yaitu hasil echo reply merupakan request timed out, maka router akan mendeklarasikan bahwa gateway tersebut tidak aktif dan routing policy akan berubah dan mengganti routing dengan gateway yang tidak aktif secara rekursif.
43
Tabel di bawah memberikan data performa yang diberikan sistem ketika dilakukan simulasi pemutusan hop, sebagai representasi dari gangguan yang terjadi pada jaringan. Simulasi dilakukan dengan cara melakukan drop untuk semua paket data yang berasal dari interface router sistem pada masing-masing gateway ISP, perlakuan tersebut mencerminkan kondisi asli dimana gangguan jaringan yang terjadi memiliki karateristik gagalnya koneksi pada hop ke-sekian, tidak hanya disebabkan karena kegagalan interface, misalnya kegagalan di layer physical.
waktu rule waktu ISP yang
Kondisi
digunakan
ISP
Waktu berpindah
terjadinya
response secara
fault
failover otomatis
ON >> OFF
13:56:29
13:57:03
00:00:34
OFF >> ON
13:57:07
13:57:13
00:00:06
ON >> OFF
13:57:22
13:58:05
00:00:43
OFF >> ON
13:58:17
13:58:22
00:00:05
ON >> OFF
13:58:37
13:59:03
00:00:26
OFF >> ON
13:59:13
13:59:22
00:00:09
C
B
A
Tabel 1 Waktu Respon failover
44
Perbedaan signifikan yang terjadi pada dua jenis perlakuan kondisi, yaitu kondisi pada saat ISP dinyalakan, dan pada saat ISP dimatikan pada sistem failover ini disebabkan karena pengecekan sebuah jalur menggunakan protokol ICMP, yang menghasilkan pesan ketika balasan dari perintah ping tidak dapat diterima setelah waktu yang ditentukan sesuai dengan standar RFC2925 halaman 12. Adapun batas waktu tersebut memiliki nilai yang jauh lebih besar dari waktu yang dibutuhkan untuk didapatkannya echo reply dari paket echo request yang bersangkutan, menyebabkan rentang waktu adaptasi sistem failover yang diterapkan penulis memiliki perbandingan waktu yang berbeda signifikan.
