troubleshooting speedy


sudah hampir satu setengah minggu ini speedy mendadak melambat. yang paling terlihat adalah tidak bisa membuka gmail, google, blogspot, dan facebook. tiga situs yang saya sebut pertama memang masih keluarga google, namun facebook? keanehan yang lain adalah wordpress bisa saya akses dengan lancar, begitu juga beberapa situs lainnya.
tadinya saya pikir ini masalah koneksi internasional, namun ternyata situs detik pun tidak bisa saya akses dengan lancar. bukan tidak bisa dibuka sama sekali, tapi ketika membuka situs detik, butuh waktu bermenit-menit sampai satu halaman selesai ditampilkan. jadi ada beberapa situs yang lancar, dan ada beberapa yang tidak lancar atau bahkan tidak bisa dibuka sama sekali.
solusi cepat dan sementara yang saya pakai adalah dengan tunneling ke kantor. cara ini memang langsung cespleng, namun itu tidak menjawab masalah kenapa koneksi speedy menjadi lambat. akhirnya setelah diskusi singkat di plurk dengan mantan blogger™ priyadi, saya coba melakukan trouble shooting yang sedikit serius.
waktu awal mula saya pakai speedy (sekitar setahun yang lalu), koneksi juga cenderung tidak lancar, sehingga setelah google ke sana ke mari, menemukan hint bahwa MTU diset di angka 1412, dan ternyata memang jadi berjalan lancar… sampai satu setengah minggu yang lalu. jadi kecurigaan pertama adalah ada setting MTU yang berubah di speedy.
cara untuk mencari tahu MTU yang dibutuhkan adalah dengan mengirim paket TCP/IP yang tidak boleh difragmentasi, ini bisa dicapai dengan menggunakan perintah ping. di windows, ini berarti mengetikkan perintah di command prompt: ping -f -l 1500 www.yahoo.com misalnya. tapi karena saya pakai ubuntu, maka perintahnya adalah: ping -M do -s 1500 www.yahoo.com.
angka 1500 adalah angka MTU yang normal untuk koneksi ethernet 100 Mbps. dan begitu dipaksa paket tidak bisa difragmentasi, terlihat bahwa angka 1500 pasti tidak akan bisa tembus. nah untuk mencari MTU yang optimum, pertama saya harus mengembalikan konfigurasi speedy ke kondisi standar. karena saya menggunakan ubuntu sebagai router dan modem ADSL sebagai bridge, saya mengubah parameter MTU di /etc/ppp/peers/dsl-provider dengan menambahkan tanda # (komentar) di depannya, memutuskan koneksi speedy, lalu menyambungkannya kembali.
berikutnya adalah mencoba cara trial dan error, diturunkan dari 1500 sampai akhirnya ditemukan besar MTU terbesar yang masih bisa tembus keluar. dan akhirnya ketemu angka MTU yang optimal (untuk speedy saya, belum tentu optimal untuk speedy di lokasi yang lain) adalah 1462:
$ ping -M do -s 1436 www.yahoo.com
PING www-real.wa1.b.yahoo.com (209.131.36.158) 1436(1464) bytes of data.
1444 bytes from f1.www.vip.sp1.yahoo.com (209.131.36.158): icmp_seq=1 ttl=52 time=300 ms

jadi saya menemukan di angka 1436, dan karena ada header sebesar 28 bytes, maka angka MTU optimal yang didapat adalah 1464. sunting kembali /etc/ppp/peers/dsl-provider, lalu masukkan parameter MTU 1464. sebenarnya saya juga mengubah konfigurasi dhcp server di router agar menggunakan DNS speedy (selain openDNS dan googleDNS), namun tampaknya walaupun masih menggunakan openDNS, koneksi speedy saya sudah kembali normal.

,

34 responses to “troubleshooting speedy”

  1. Enaknya di Windows ada DrTCP tuh, auto tune, doi ngetest sendiri sampe MTU mana yang pas.
    Kayaknya ini berarti DSLAM sampeyan ke ISP induknya lewat another conversion stack, mangkane MTU sampeyan tambah menciut. Curigane PPPoE over MPLS

  2. Thx untuk tipsnya.
    Apakah latar belakang dari Telkom untuk menggunakan MTU yang tidak “standar”? Beberapa teman saya juga mengeluhkan layanan speedy yang merosot dalam bulan2 terakhir ini. Kalau telep ke 147 dan tehnisi datang, wah alasannya bisa aneh2… telepon paralel sampe dijadikan alasan, padahal paralel setelah split… heheheh
    Mungkinkah ini sabotase dari orang internal Speedy? Maklum, persaingan ISP untuk harga kelas bawah khan sangat2 kompetitif. 😀

    • Saya juga merasa telkom speedy expres luncuran produk baru dari telkom sejenis produk gagal.
      Masalahnya :
      Setelah saya memakai speedy paket yang executive , sering sekali mengalami gangguan. sampai-sampai didalam 10 hari saya sudah mengalami 3x gangguan ditambah lagi pelayanan yg kurang cepat/lambat menyebabkan saya hanya bisa memakai 3 hari full dalam 10 hari.
      sekarang ini pun data rate dispeedy saya hanya 1024/126kbps setelah dua hari tidak bisa koneksi
      kesan:
      saya merasa sangat kecewa dengan speedy sekarang ini
      pesan:
      tolong produknya dipelajari kembali untuk hasil yg lebih maksimal
      selain itu pelayanan juga tolong ditingkatkan /dipercepat bos demi kepuasan customer

  3. Kalau di slackware, option default untuk CLAMPSS yg paling safe 1412. Ini ada di file /etc/ppp/pppoe.conf. Dari dulu sampai sekarang pakai setting ini koneksi ke spidi via modem bridge lancar2 saja.

    • dari awal punya speedy saya juga set di 1412. setelah 2 minggu problem dengan angka ini, akhirnya ketemu angka 1464 yang membuat problem lelet browsing hilang.

  4. Ini masalah klasik kalo pakai modem spidi, entah modem spidi yang modelnya kurang bagus, atau jaringan adslnya atau seting mtu/mru yang kurang sesuai. Apa itu ?
    Coba tes download file yang besar, saat download lagi kencang2nya, upload file besar ke server lain. Pasti trafik downloadnya akan naik turun kayak ular tangga. Kalau uploadnya sih tetap stabil.

    • wah, itu sih bukan masalah speedy, tapi masalah semua koneksi asimetrik dan upstream-nya kecil. yang namanya transfer file itu butuh signaling, buat memberitahukan apakah paket sudah diterima dengan benar, atau untuk meminta ulang paket yang dianggap rusak. ketika trafik upstream mengalami kongesti, signaling ini akan terhambat, dan membuat proses download jadi terbata-bata.
      tapi ini ada solusinya, yaitu dengan membatasi trafik upstream. di ubuntu bisa pakai wondershaper, lalu dicoba-coba angka batas upstream yang optimal, dalam artian upload lancar, download tidak terganggu. saya biasanya pakai setting upstream dibatasi di 128 Kbps.

  5. Makasih infonya. Barusan saya coba juga di koneksi IM2 yang belakangan sering timeout kalo dipakai di komputer, dialup via bluetooh. Padahal kalau digunakan di hape lancar-lancar saja. Setelah dicek ping, dapat MTU 1420. Sekarang sudah lancar juga di komputer.

  6. Makasih banyak infonya. Hal yang sama juga terjadi pada FastNet. Ternyata koneksi FastNet (512kbps) saya juga hanya memiliki MTU di 1480.
    Cuma pertanyaannya, gimana cara ngubah MTU di OS X ya?
    Selama ini sih koneksi belum ada masalah yang disadari. Apa optimisasi ini bisa lebih meningkatkan kualitas jaringan?
    Thanks a bunch!

    • mengubah MTU kalau di snow leopard tinggal jalankan system preferences – network – pilih interface network yang mau diubah MTU-nya – advanced – ethernet – configure manually.

  7. Om ryo, saya sudah coba ubah MTU di OS X ke 1480 (hasil ping, max 1472, tapi +header 1480, bener kan?).
    Nah setelah diubah, sekarang saya coba ping -D -s 1460 google.com. Tapi masalahnya yang keluar malah seperti ini:
    PING google.com (64.233.189.104): 1460 data bytes
    ping: sendto: Message too long
    ping: sendto: Message too long
    Request timeout for icmp_seq 0
    Mengapa begitu ya? Bukannya MTU max seharusnya 1480?
    TQ

    • saya sudah coba ubah MTU di OS X ke 1480 (hasil ping, max 1472, tapi +header 1480, bener kan?).

      ini anda dapat angka 8 bytes header dari mana ya? 1480-1472=8.
      lalu, kalau ternyata 1460 saja tidak bisa, kemungkinan besar anda memang salah hitung. coba dicari tahu lagi header yang dipakai, saya tahu 28 bytes karena baris ini:
      PING www-real.wa1.b.yahoo.com (209.131.36.158) 1436(1464) bytes of data
      1464-1436=28.

      • Dari sini om:
        ~ tituswiguno$ ping -D -s 1472 google.com
        PING google.com (64.233.189.99): 1472 data bytes
        1480 bytes from 64.233.189.99: icmp_seq=0 ttl=244 time=75.124 ms
        1480 bytes from 64.233.189.99: icmp_seq=1 ttl=244 time=73.805 ms
        1480 bytes from 64.233.189.99: icmp_seq=2 ttl=244 time=90.458 ms
        Asumsi saya benar tidak?

        • hehe kayaknya salah tuh. coba lihat lagi contoh saya:
          $ ping -M do -s 1436 http://www.yahoo.com
          PING www-real.wa1.b.yahoo.com (209.131.36.158) 1436(1464) bytes of data.
          1444 bytes from f1.www.vip.sp1.yahoo.com (209.131.36.158): icmp_seq=1 ttl=52 time=300 ms
          lihat yang saya tebalkan, saya tidak menghitungnya dari sana, karena itu besar paket dari yahoo yang datang ke speedy saya. jadi saya mengirim paket sebesar 1436 (yang menjadi 1464 karena ketambahan header), yang dibalas dengan paket sebesar 1444 dari yahoo.
          kalau anda ketik man ping di terminal, ada info seperti ini:
          ICMP PACKET DETAILS
          An IP header without options is 20 bytes. An ICMP ECHO_REQUEST packet contains an additional 8 bytes worth of ICMP header followed by an arbitrary amount of data. When a packetsize is given, this indicated the size of this extra piece of data (the default is 56). Thus the amount of data received inside of an IP packet of type ICMP ECHO_REPLY will always be 8 bytes more than the requested data space (the ICMP header).
          jadi, selisih besar paket data bisa dipastikan 28 bytes. kalau anda melakukan testing dan ternyata anda mendapatkan angka 1472, bisa dipastikan besar paket yang tembus adalah 1472+28 = 1500 = besar default paket ethernet. ketika anda setting MTU ke 1480, maka jelas besar paket 1460 tidak akan bisa tembus, karena 1460+28 = 1488 > 1480.
          dari data yang anda ungkapkan, sepertinya aman-aman saja memakai MTU standar sepertinya aslinya di 1500.

  8. om ryo,
    di pppoe freebsd kok gak bisa ya di set mtu nya, udah di set mtu 1462 di ppp.conf kalo di ifconfig tun0 :
    tun0: flags=8151 metric 0 mtu 1492
    nilainya masih tetep 1492,
    setnya di mana ya di

  9. Om Ryo, mau tanya lagi, berhubung FastNet baru upgrade speed, dan rasanya speed saya drop banget, tadi saya coba tes ping lagi dengan:
    ping -D -s 1472 google.com
    Tapi responnya seperti ini:
    PING google.com (66.102.7.99): 1472 data bytes
    72 bytes from 66.102.7.99: icmp_seq=0 ttl=48 time=291.344 ms
    wrong total length 92 instead of 1500
    7
    Jadi bingung, kok malah cuma 92 ya angkanya?
    Mohon pencerahan.
    Thanks.

    • itu tidak masalah. itu hanya si google.com cuma mau membalas dengan paket sebesar 92 bytes, tidak mau membalas sebesar 1500, karena setting mesin google.com memang begitu.

  10. Bro ryo.. Apa persamaan parameter -M dan -s di Windows / DOS ?
    -s di windows itu “Timestamps for count hops” dan rangenya adalah 1 sampai 4

  11. terima kasih mas.. mwaaaaaaacchh.. hore koneksi speedy aku setelah 2 minggu sekarang lancar jaya kembali ^_^
    aku dapat maksimal nilai MTU speedy aku di 996
    terima kasih mas ^_^

  12. Komputer saya kalau pake modem d-link 526b gak bisa akses e-mail melalui mail client ( POP3), padahal kalau modemnya aztech saya bisa akses. kenapa ya ?

  13. buat mengetahui besarnya packet header di windows gimana yak ? saya dapat MTU yg sesuai adalah 1472, tapi harus di tambahkan brp untuk packet header ?

  14. om, kalo setelah di ping pada SO windows itu terdapat tulisan seperti ini :
    pinging any-fp.wa1.b.yahoo.com [98.137.149.56] with 1500 bytes of data :
    packet needs to be fragmented but DF set.
    packet needs to be fragmented but DF set.
    packet needs to be fragmented but DF set.
    apa maksudnya om??
    terimakasih sebelumnya

  15. Mas saya sudah coba cara ping diatas dengan speedy, hslnya pd saat kita tentukan mtu di modem 1492 maka paket yg tidak terfragment 1464 jika ditambah header 28 hslnya MTU 1492, jika kita menentukan mtu 1480 paketyg tdk 1452 jika ditambah header 28 haslnya MTu 1480 dan seterusnya jika kita tentukan MTU 1400 paket yg tidak terfragment 1372 jika ditambah header 28 hslnya MTU 1400, lantas yg jadi mslh berapakah nilai MTU yang terbaik karena pengalaman saya menyimpulkan berapapun nilai MTU yang kita tentukan (mulai 1492 kebawah) maka hasil ping yg tdk terfragment pasti jika ditambah header 28 = nilai MTU yg tlh diset tersebut, jd mhn pencerahannya mana nilai MTU terbaik, krn sampai skrg saya msh bingung utk memilihnya sebeumya terimakasih.

Leave a Reply

Your email address will not be published. Required fields are marked *