BAB IV PENANGANAN GANGGUAN DAN PERFORMANCE MONITORING PADA LINK EoS
Pada jaringan SDH, penanganan gangguan dilakukan berdasarkan complaint dari pelanggan atau user yang menggunakan jaringan tersebut. Saat melaporkan gangguan jaringannya, user memberikan data port agar dapat dilakukan pengecekan di NMS. Setelah mendapatkan laporan dari user beserta dataportnya, tim operasional akan melakukan pengecekan di NMS.
4.1 Troubleshoot Link EOS Hal yang pertama untuk dilakukan pengecekan kita harus mengeahui darimana sumber gangguan itu berasal. Pada gambar 4.1 terlihat terjadinya alarm yang masih belum di ketahui penyebabnya.
55
56
Gambar 4.1 link alarm
Bisa dibandingkan dengan gambar pada bab sebelumnya, jika link yang terdapat ada alarm maka akan terlihat seperti gambar tersebut. Penulis mencoba untuk menganalisa apakah untuk case tersebut trafik pada link Tuban berjalan dengan baik atau tidak, bisa di lihat dengan performancenya. Dalam performance tersebut bisa terlihat apakah ada trafik yang lewat atau tidak bisa di lihat pada gambar 4.2.
57
Gambar 4.2 Performance Monitoring
Dalam gambar diatas bisa dilihat bahwa tidak ada trafik yang melewati link tersebut, bisa di lihat dari kolom monitoring yang berisi false, jika dalam kondisi ok seharusnya label bertuliskan True. Selain itu bisa di lihat juga dari Kolom Received total Bytes yang menandakan bahwa trafik tidak ada yang lewat sama sekali. Ini sangat berpengaruh untuk QoS pada Pelanggan PT.Indosat Tbk. Cara penanganannya adalah dengan melakukan beberapa pengetesan untuk mengetahui dimana lokasi alarm tersebut muncul.
58
4.2 Ping Ping (sering disebut sebagai singkatan dari Packet Internet Gopher) adalah sebuah program utilitas yang dapat digunakan untuk memeriksa Induktivitas
jaringan
berbasis
teknologi
Transmission
Control
Protocol/Internet Protocol (TCP/IP). Dengan menggunakan utilitas ini, dapat diuji apakah sebuah komputer terhubung dengan komputer lainnya. Hal ini dilakukan dengan mengirim sebuah paket kepada alamat IP yang hendak diujicoba konektivitasnya dan menunggu respon darinya.
Gambar 4.3 Ping Delay
59
Gambar 4.3 menunjukan bahwa terdapat banyak delay yaitu hampir setengah detik. Untuk standart, trafik tersebut tidak normal, untuk normalnya maksimalnya 2 digit untuk time-nya dalam satuan ms (mili second). Untuk lebih memastikan lebih lanjut, penulis melakukan pengetsan kembali dengan boom trafict. Dengan menggunakan software netpersec dan Traffic Generator (tfgen). Software tfgen berfungsi untuk memberikan simulasi trafik berupa paket data sebesar link yang di gunakan. Disini link yang digunakan adalah 20 Mbps maka di setting untuk trafiknya sebesar 20000 Kbps. Dari gambar 4.4 bisa di lihat status trafik yang dilewati link tersebut.
Gambar 4.4 Trafik Error
60
Dalam gambar tersebut bisa terlihat untuk grafik diatas menunjukan proses download, untuk grafik yang dibawahnya menunjukan upload. Hal yang diperhatikan adalah trafik uploadnya dikarenakan kita memberikan trafik, itu sama halnya dengan meng-upload suatu file kedalam link tersebut. Dari 20 Mbps data yang bisa dilewati hanya bisa mendapatkan 13.1 Mbps, itu menandakan bahwa adanya paket error yang terdapat pada link tersebut. Dari hasil pengetestan dengan rumus kecepatan paket data maka :
Gambar 4.5 Rumus Delay
Besar Paket = 100 Mb Bandwidth = 13.1 Mbps Jadi ;
Dari simulasi pengiriman paket tersebut dapat disimpulkan, dengan data 100Mb dan Bandwidth 13.1Mbps, paket tersebut dapat terkirim dalam waktu 7.633 detik.
61
Kesimpulannya delay yang muncul dikarenakan link paket yang ada tidak memenuhi kapasitas yang sebelumnya. Dari 20 Mbps hanya 13.1 Mbps yang bisa melewatkan trafik. Dalam hal ini tidak memasuki standarisasi sebuah link dalam keadaan normal. Qos dari standarisasi perusahaan adalah sebesar 90%, seharusnya link bisa melewati trafik minimal 18,5 Mbps. Untuk selanjutnya penulis melakukan pengetesan kembali untuk memastikan error trafik tersebut berasal dari sisi mana.
4.3 Loopback Loopback adalah proses memutarbalikkan kembali suatu trafik yang dikirimkan oleh suatu perangkat. Jadi trafik yang dikirimkan melalui Tx dikembalikan lagi lewat Rx milik link tersebut. Proses tersebut apabila digambarkan seperti berikut ini:
Gambar 4.6 Loopback
Proses loopback ini sangat berguna dalam penanganan gangguan E1 karena dengan melakukan loopback bisa diketahui dengan pasti segment mana yang bermasalah. Loopback bisa dilakukan dari dropport suatu sirkit E1 atau juga dilakukan dari tengah jalurnya dengan data port yang sudah ada dari hasil trace. Hasil loopback tersebut bisa dilihat dari alarm yang ada disalah satu ujung sirkit E1.
62
Proses loopback ini bisa dilakukaan dengan cara sebagai berikut :
Men-Double klik pada NE yang akan di loopback maka akan muncul tampilan pada gambar 4.4
Kemudian memilih gambar loopback.
Gambar 4.7 Loopback View
Lalu mengklik modify dan sekarang tinggal melakukan Apply pada kiri atas NMS. Bisa di lihat pada gambar 4.7, 4.8 dan 4.9
63
Gambar 4.8 Loopback finish 1
64
Gambar 4.9 Loopback Finish 2
Dalam case tersebut dilihat bahwa alarm dari sisi Babat clear dan dari sisi Tuban tidak clear (terdapat alarm), disini kita bisa lihat di sisi Babat tidak perlu di lakukan penanganan alarm, hanya disisi Tuban yang harus bisa di pastikan kembali alarm berasal dari Port atau trail. Sebelum melakukan langkah selanjutnya, disini harus ada orang disisi site untuk memasang alat ukur untuk memastikan apakah loopback kita bisa di terima alat ukur tersebut atau tidak.
65
Gambar 4.10 Tester View1
Dari hasil pengukuran (koordinasi dengan Rekan di site) ternyata disisi Tuban terdetek adanya loopback namun banyak error paket. Dari hasil pengetestan tersebut terlihat salah satu LED berwarna merah itu bisa menandakan bahwa terdapat banyak error dari hasil pengecekan. Pengecekan tersebut dilakukan beberapa hari untuk link baru untuk memastikan sebelum diberikan kepelanggan link berjalan dengan bagus dan normal, namun untuk penangganan gangguan link yang sudah onside pengerjaan waktu harus dibawah 4 jam sesuai standar dari PT.indosat itu sendiri. Untuk melakukan langkah selanjutnya lakukan loop disisi terdekat dari perangkat Tuban, yaitu NE tuban itu sendiri bisa di lihat pada gambar 4.8. dilakukan dengan cara yang sama, namun sebelumnya harus di lakukan
66
release pada setiap NE yang di loop. Dengan cara klik kanan pada kolom kiri dan end test.
Gambar 4.11 Loopback Tuban
Setelah dilakukan ternyata kondisi tester disana OK (terima Loop). Penulis memastikan bahwa terdapat problem disisi Trail Antara Babat dengan Tuban bisa dilihat pada gambar 4.9.
67
Gambar 4.12 Tester View2
Setelah di monitoring selama satu hari bisa kembali dilihat perbandingannya dari gambar 4.10 dengan gambar 4.12 sirkit bersih dari error, maka asumsi adalah trail yang dilewati mengalami problem. Untuk penanganan gangguannya adalah dengan mengganti dengan trail yang lain (Reroute).
4.4 Reroute Reroute adalah proses mengubah jalur sebuah sirkit ke jalur yang lain. Proses ini bisa dilakukan karena jalur sebelumnya terdapat masalah, misalnya
68
ada kabel putus atau cardnya rusak. Proses reroute ini dilakukan tanpa mengubah port diujungnya, hanya jalur ditengah dan itu juga bisa hanya beberapa segment yang diubah. Berikut ini adalah contoh sirkit yang bermasalah di salah satu jalurnya yang dikarenakan ada card yang rusak.
Gambar 4.13 Sirkit Disable
Pada sirkit diatas, status operational state nya disable yang artinya sirkit tersebut tidak dapat digunakan oleh trafik. Untuk membuatnya menjadi bisa digunakan kembali perlu dilakukan reroute. Pada gambar dibawah ini sirkit tersebut sudah di reroute dan status sirkitnya sudah enable kembali. Jalur yang digunakan sudah berbeda dengan jalur sirkit pada gambar diatas.
69
Gambar 4.14 Sirkit Enable
Setelah dilakukan reroute link kembali clear alarm, untuk memastikannya kita harus melakukan loopback kembali pada trail yang rusak tadi. Setelah dilakukan loop dari sisi Babat tester disisi Tuban menunjukan bahwa link tersebut OK, kemudian link yang sebelumnya ditest dikembalikan kepelanggan untuk di koneksikan kedalam MODEM pelanggan. Dari sisi NMS bisa dilihat bahwa adanya trafik yang melwati link tersebut. Dalam pengetesan tadi terjadi NE Unmanaged bisa dilihat dari gambar 4.11 disisi Babat. Ini terjadi dikarenakan ada problem disisi Site itu sendiri. Problem tersebut bisa solve dengan melihat langsung kondisi site itu, bisa disebabkan mati lampu atau jalur link DCN yang kearah Babat terputus
70
akibat gangguan external, seperti terkena pekerjaan Umum yaitu human error yang memotong kabel fisiknya. Namun dari case ini bisa di cek bahwa trafik tetap berjalan walaupun NE tersebut dalam keadaan Unamanaged. Bisa dilihat di gambar 4.12. Asumsi bahwa link DCN tidak bermasalah secara fisik. Kemungkinan problem site mati listrik, penanganannya biasanya tersedia Genset untuk membackup sementara catudaya yang ada.
Gambar 4.15 Trafik on
Dengan demikian status link sudah kembali berjalan normal, untuk memastikannya kita menggunakan kembali software tfgen dan nps kembali untuk melakukan pengecekan kembali terhadap kapasitasnya. Bisa dilihat pada gambar 4.16.
71
Gambar 4.16 Trafik normal
Dari data yang dilihat dari gambar 4.16 bisa disimpulkan bahwa trafik kembali berjalan normal, dari 20Mbps kapasitas bisa dilewatkan trafik sebesar 19.0 Mbps. Dalam hal ini penulis akan mencoba melakukan penghitungan kembali berapa lama paket yang dikirim sampai kepada penerima dengan kapasitas paket yang sama yaitu 100 Mb.
72
Dalam hal ini bisa dibandingkan dengan kondisi sebelumnya dengan menggunakan kembali rumus pada gambar 4.5. Paket yang dikirim sebesar 100 Mb sebelumnya bisa dikirim dalam waktu 7.633 detik, sedangkan setelah dilakukan perbaikan paket bisa sampai hanya dengan waktu 5.263 detik. Hal ini membuktikan dengan semakin besarnya kapasitas akan semakin cepat paket terkirim. Hal tersebut masih masuk standarisasi dalam sebuah link yaitu sebesar 90%. Setelah trafik kembali normal maka untuk selanjutnya melakukan pengecekan ping kembali kesisi pelanggan. Cara melakukannya sama seperti dilakukan pengecekan saat terjadi gangguan. Bisa dilihat pada gambar 4.17.
Gambar 4.17 Ping by PT.Indosat software
73
Gambar 4.18 Ping by CMD
Dari gambar 4.17 dan 4.18 bisa dilihat perbandingannya dengan menggunakan software dari PT.indosat bisa dilihat kembali delay yang terbaca rata-ratanya adalah 0.500ms, dan dari sisi CMD terbaca 1ms. Ini dikarenakan software dari PT.Indosat mampu membaca hingga 0.001ms dengan secara detail. Dengan menggunakan software asli PC tidak bisa membaca hingga sedetail dari software PT.Indosat. Hal ini bertujuan dari QoS PT.indosat itu sendiri yang maximal 2 digit dalam satuan ms. Semakin kecil ping semakin baik kinerja link tersebut.
4.5 Proteksi Pada dasarnya istilah proteksi merupakan cara pengaturan dalam memindahkan trafik pada kanal utama ke kanal cadangan (back-up) ketika terjadi kegagalan transmisi pada jalur utamanya. Sistem proteksi merupakan
74
cara untuk mengatasi suatu masalah yang terjadi pada jaringan backbone. Pada penanganan gangguan ini sistem proteksi yang digunakan adalah jenis SNCP (Sub Network Connection Protection), sistem SNCP ini merupakan sistem proteksi pada crossconnect sirkit E1. Sistem SNCP ini memudahkan content provider untuk melakukan restorasi terhadap link circuit yang failed. Untuk metode proteksi SNCP tidak ada pembatasan terhadap topologi jaringan (setidaknya tersedia dua macam rute). Tipikal switching time pada proteksi SNCP berkisar 50-200 ms. SNCP memiliki beberapa type aplikasi pada sistem proteksinya : Revertive dan Non-revertive. Pada non-revertive mode, sinyal data akan tetap berada pada link proteksi walaupun kondisi alarm atau fault telah kembali normal. Sebaliknya pada mode revertive, sinyal data dapat kembali ke working line saat alarm atau fault kembali normal, tinggal bergantung pada Wait time to restore. Pada gambar 4.19 dibawah ini merupakan sirkit yang mengalami gangguan pada jalurnya dan belum memiliki jalur proteksi. Sedangkan pada gambar 4.20 sirkit tersebut menjadi enable kembali setelah dibuatkan proteksi dengan jalur yang berbeda.
75
Gambar 4.19 Single Route
Cara untuk memproteksikannya hampir sama dengan membuat crossconnect pada bab sebelumnya, hanya dengan mengklik tombol edit mode dan double klik pada NE yang memiliki 2 jalur atau link. Jika hanya menggunakan 1 jalur, link tidak bisa di proteksi seperti link EoS yang di buat sebelumnya. Jika trailnya terkena impact LOS gangguan akibat pekerjaan umum maka hanya bisa menunggu penyambungan kabel fisik hingga selesai. Namun untuk contoh diatas penulis menggunakan link contoh dari pelanggan Indosat portnya dari Makro menuju Bandung 3. Dengan melewati beberapa site lainnya seperti Purwakarta. Jika dilihat dalam MAP routing link Makro memiliki link lain yang melewati Sadang serang – Bandung 2 kemudian Bandung 3. Penulis akan melakukan proteksi melewati link tersebut.
76
Gambar 4.20 Proteksi
Setelah masuk ke-menu proteksi tanda panah dibuat bercabang. Agar link bisa memilih 2 jalur. Namun jika tidak dicabangkan maka kita mengubah link yang sudah ada. Kemudian mengklik tanda panah hijau yang ada dikotak kolom setelah kita memilih jalur yang melewati Sadang Serang tadi.
77
Gambar 4.21 Port Change
Setelah selesai melakukan proteksi maka jalur akan seperti gambar 4.22. alarm kembali clear.
Gambar 4.22 Proteksi Finish
78
Dari hasil proteksi terlihat ada 2 trail yang bisa di gunakan, namun karena link mainnya dalam keadaan down maka saat ini trafik melewati link proteksi yang di tandai dengan hijaunya garis titik-titik tersebut. Kelemahan dari proteksi ini adalah jika saat link dalam keadaan normal (tidak alarm) dan kita ingin melakukan proteksi, maka resiko dari hal tersebut sirkit akan mati dalam beberapa detik setelah proses apply dilakukan, maksimal 5 detik untuk melakukan pengaturan ulang dari konfigurasi tersebut, bisa disebut juga akan adanya delay. Hal tersebut bisa menyebabkan sebuah kerugian bagi pelanggan, maka dari hal tersebut proteksi dilakukan saat pembuatan sirkit berlangsung pertama kali atau saat terjadi gangguan saja.
