Skip to main content

Traffic Shaping - Bagian 1

Pertanyaan paling mendasar adalah mengapa perlu pengaturan trafik atau traffic shaping?
  1. Anda pakai speedy office di rumah anda untuk 3 komputer. Anda tidak butuh traffic shapping.
  2. Anda pakai fastnet 384 kbps di rumah untuk 3 komputer. Anda tidak butuh traffic shapping.
  3. Kalau user anda sedikit dan bandwidth anda besar, katakan user anda 100, bandwidth anda 8 Mbps symmetris, anda sepertinya gak butuh traffic shaping (debatable juga sih apalagi kalau dipakai voip atau video conference).
  4. Kalau user anda hanya 1 sampai 5 orang bisa dikatakan anda tidak perlu traffic shaping, karena bandwidth anda masih memadai untuk melayani user anda. Tapi bagaimana kalau user anda lebih dari 15 orang dan masing-masing melakukan koneksi remote ssh, selain tentunya browsing dan download. Bisa dikatakan anda akan mengalami masalah, kalau anda tidak men-shape trafik upload dan membuat policy untuk downlink anda. Saya mengalaminya sendiri dengan sekitar 60 user yang haus bandwidth.
  5. Menjaga low latency untuk trafik interaktif. Artinya proses download dan upload harus tidak mengganggu SSH, telnet dan sejenisnya. Hal ini yang paling penting. Dengan latency 200ms cukup membuat bekerja dengan SSH sangat tidak nyaman.
  6. Menjaga agar user dapat tetap membrowse internet dengan kecepatan yang nyaman sementara melakukan proses upload atau download.
  7. Memastikan bahwa proses upload tidak mengorbankan proses download dan sebaliknya. Perlu dipahami bahwa adanya queue yang besar di device seperti modem ADSL atau kabel modem akan membuat upload, download dan trafik interaktif akan saling bertanding satu sama lain.
Di bawah ini adalah script yang dapat digunakan untuk melakukan traffic shaping di openSUSE (well, juga untuk distribusi linux lain). Sekarang saya akan menjelaskan apa maksud dari script tersebut. Ketika dulu pertama kali mempelajari tc, ip, dan HTB saya menyadari bahwa hal inilah yang paling susah.

#!/bin/sh

#
#
# /etc/init.d/mebwshaper_eth1
#
### BEGIN INIT INFO
# Provides:          mebwshaper_eth1
# Required-Start:    $network
# Should-Start:
# Required-Stop:
# Should-Stop:
# Default-Start:     3 5
# Default-Stop:      0 1 2 6
# Short-Description: Custom bandwidth shaping by medwinz@gmail.com
# Description:       Custom bandwidth shaping by medwinz@gmail.com
### END INIT INFO
#

test -s /etc/rc.status && . /etc/rc.status && rc_reset

case "$1" in
start )
# script bandwidth shaping for openSUSE by medwinz@gmail.com
# silakan dicopy atau diubah-ubah
#

echo -n "Starting bandwidth shaping HTB qdiscs in eth1"

DOWNLINK=968
UPLINK=110

# hapus existing downlink and uplink qdiscs, umpetin errors
tc qdisc del dev eth1 root    2> /dev/null > /dev/null
sleep 2
tc qdisc del dev eth1 ingress 2> /dev/null > /dev/null
sleep 1

# ngebuat qdisc
tc qdisc add dev eth1 root handle 1: htb default 15
tc class add dev eth1 parent 1: classid 1:1 htb rate ${UPLINK}kbit ceil ${UPLINK}kbit
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 36kbit ceil 36kbit prio 0
tc class add dev eth1 parent 1:1 classid 1:11 htb rate 36kbit ceil ${UPLINK}kbit prio 1
tc class add dev eth1 parent 1:1 classid 1:12 htb rate 9kbit ceil ${UPLINK}kbit prio 2
tc class add dev eth1 parent 1:1 classid 1:13 htb rate 9kbit ceil ${UPLINK}kbit prio 2
tc class add dev eth1 parent 1:1 classid 1:14 htb rate 11kbit ceil ${UPLINK}kbit prio 3
tc class add dev eth1 parent 1:1 classid 1:15 htb rate 9kbit ceil ${UPLINK}kbit prio 3
tc qdisc add dev eth1 parent 1:12 handle 120: sfq perturb 10
tc qdisc add dev eth1 parent 1:13 handle 130: sfq perturb 10
tc qdisc add dev eth1 parent 1:14 handle 140: sfq perturb 10
tc qdisc add dev eth1 parent 1:15 handle 150: sfq perturb 10

tc filter add dev eth1 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10
tc filter add dev eth1 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:11
tc filter add dev eth1 parent 1:0 protocol ip prio 3 handle 3 fw classid 1:12
tc filter add dev eth1 parent 1:0 protocol ip prio 4 handle 4 fw classid 1:13
tc filter add dev eth1 parent 1:0 protocol ip prio 5 handle 5 fw classid 1:14
tc filter add dev eth1 parent 1:0 protocol ip prio 6 handle 6 fw classid 1:15

# attach ingress policer;
# ngelambatin download sedikit
tc qdisc add dev eth1 handle ffff: ingress

# lambatin semua paket yang datang terlalu cepat
tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match ip src \
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

rc_status -v
;;

stop)
# hapus existing downlink and uplink qdiscs, umpetin errors

echo -n "Delete all HTB qdiscs on eth1"

tc qdisc del dev eth1 root    2> /dev/null > /dev/null
sleep 3
tc qdisc del dev eth1 ingress 2> /dev/null > /dev/null
sleep 2
rc_status -v
;;

restart)
## Berhentiin service dan tanpa perduli dia jalan atau nggak
## Start lagi.
$0 stop
$0 start

# inget status dan tenang aja
rc_status
;;

*)
echo "Usage: $0 {start|stop|restart}"
exit 1
;;

esac
rc_exit

Penjelasan

DOWNLINK=968
Ini adalah kecepatan download. ISP mengatakan 1024 kbps, tapi saya kecilkan menjadi sekitar 94% saja. Hal ini perlu agar tidak terjadi kongesti.

UPLINK=110
Demikian pula dengan upload. ISP menyatakan sebesar 128 kbps, tapi  hanya 86% yang saya alokasikan.

Anda harus mencari dengan trial and error sampai didapatkan angka maksimum untuk DOWNLINK dan UPLINK dimana traffic tidak menyebabkan kongesti pada sambungan ADSL anda. Perlu untuk diketahui bahwa ISP menerapkan queueing pada banyak sekali server mereka, kita tidak dapat mengkontrol queueing di sisi ISP. Karena itu tujuan utama dari traffic shapping ini adalah memindahkan queueing pada server kita agar kita bisa mengaturnya. Sehingga traffic yang mencapai ISP tidak di queuing lagi oleh ISP (idealnya seperti itu). Pada setting di tempat saya, saya menggunakan angka UPLINK 110 kbit/s. Angka ini adalah angka maksimum sebelum latency mulai meningkat (walaupun Speedy mengatakan uploadnya 128 kbit/s) yang disebabkan mulai penuhnya buffer pada router atau modem (whatever..) antara server saya dengan remote host.

tc qdisc del dev eth1 root    2> /dev/null > /dev/null
sleep 2

Baris di atas merupakan perintah tc untuk menghapus semua root qdisc downlink yang mungkin ada sebelumnya di device eth1, selanjutnya menunggu selama 2 detik.

tc qdisc del dev eth1 ingress 2> /dev/null > /dev/null
sleep 1

Baris ini merupakan perintah tc untuk menghapus semua ingress qdisc uplink yang mungkin ada sebelumnya di device eth1, selanjutnya menunggu selama 1 detik. Baris-baris berikutnya adalah inti dari script ini yaitu membuat beberapa qdisc baru untuk mengatur trafik upload,

tc qdisc add dev eth1 root handle 1: htb default 15
tc class add dev eth1 parent 1: classid 1:1 htb rate ${UPLINK}kbit ceil ${UPLINK}kbit
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 36kbit ceil 36kbit prio 0
tc class add dev eth1 parent 1:1 classid 1:11 htb rate 36kbit ceil ${UPLINK}kbit prio 1
tc class add dev eth1 parent 1:1 classid 1:12 htb rate 9kbit ceil ${UPLINK}kbit prio 2
tc class add dev eth1 parent 1:1 classid 1:13 htb rate 9kbit ceil ${UPLINK}kbit prio 2
tc class add dev eth1 parent 1:1 classid 1:14 htb rate 11kbit ceil ${UPLINK}kbit prio 3
tc class add dev eth1 parent 1:1 classid 1:15 htb rate 9kbit ceil ${UPLINK}kbit prio 3

Hal di atas adalah membuat beberapa qdisc dimana trafik akan diklasifikasikan. ada 6 htb qdisc yang dibuat dengan prioritas tertinggi pada class 1:10 dan terendah pada class 1:15. Secara default semua trafik akan masuk ke class 1:15 ( tc qdisc add dev eth1 root handle 1: htb default 15). Maksud dari baris-baris di atas adalah membagi root class 1: upload menjadi 6 class 1:10, 1:11, 1:12, 1:13, 1:14 dan 1:15 dengan rate minimal masing-masing 36 kbit, 36 kbit, 9 kbit, 9 kbit, 11 kbit dan 9 kbit. Setiap class dapat menggunakan bandwidth yang tidak terpakai oleh class lainnya. Class dengan priority yang lebih tinggi (prio 1 prioritasnya lebih tinggi dari prio 3) akan mendapatkan alokasi bandwidth lebih dulu.


classid 1:10 htb rate 36kbit ceil 36kbit prio 0
Ini adalah class dengan prioritas tertinggi. Paket dalam class ini akan memiliki delay terkecil dan akan mendapatkan excess bandwidth pertama kali, sehingga saya membatasinya sampai angka 36 kbit/s. Paket yang akan dikirimkan melalui class ini adalah paket yang membutuhkan delay yang kecil, seperti trafik interaktif yaitu: ssh, telnet, dns, irc, dan paket dengan SYN flag.
classid 1:11 htb rate 36kbit ceil ${UPLINK}kbit prio 1
Kelas ini adalah kelas pertama dimana sebagian besar trafik (bulk traffic) akan diletakkan. Trafik di sini sebagian besar adalah web trafik dari lokal web server (web server di mesin lokal) serta trafik web keluar: source port 80 dan destination port 80.
classid 1:12 htb rate 9kbit ceil ${UPLINK}kbit prio 2
Dalam kelas ini saya letakkan trafik dengan nilai bit TOS Maximize-Throughput dan trafik lain yang berasal dari proses lokal (trafik yang sumbernya dari server) ke internet. Class ini hanya akan berisi trafik yang di-route melalui server (tempat script ini di jalankan).
classid 1:13 htb rate 9kbit ceil ${UPLINK}kbit prio 2
Class ini diperuntukkan bagi trafik untuk mesin-mesin yang di- NAT, yang membutuhkan prioritas bagi trafik bulk-nya.
classid 1:14 htb rate 11kbit ceil ${UPLINK}kbit prio 3
Class ini untuk trafik email (SMTP, POP3, IMAP, dll) serta paket dengan nilai bit TOS Minimize-Cost.
classid 1:15 htb rate 9kbit ceil ${UPLINK}kbit prio 3
Class terakhir ini adalah class default dimana bulk traffic dari mesin-mesin yang di NAT akan dimasukkan. Trafik yang masuk di sini seperti kazaa, edonkey, dan yang sejenisnya.
Penjelasan singkat ini silakan dicerna dulu. Dibaca, dimengerti dan dibawa mimpi. Saya akan lanjutkan pada tulisan berikutnya bagaimana menghubungkan script ini dengan iptables.

Comments

Popular posts from this blog

Prejudice and Privilege

Notes : It is not about Linux or other geeky stuff nor it is a political writing.  It was a day in the end of March 2007. I was just landed at the Franz Josef Strauss Munich Airport  around 10 AM in the morning. I had 5 days free time from my work in Astrium. At that time I was contracted by EADS Astrium  (now become Airbus Defense and Space) to work with them in Toulouse . I worked for one of their project. I flew from Toulouse where I worked to visit my brother family in Munich. Just after I picked up my luggage from the conveyor, three guys without uniform approaching me and asked me in English what i'm doing in Munich. I asked them if I did anything wrong. One of them told me that it was a random checked.     "Who are you guys? Sorry sir if it is a random check, why do you choose me instead of other?" I reply to their answer.  One of them said they're from the Munich immigration, and at the same time showing a gun behind his jacket. For my itinerar...

openSUSE.Asia Summit 2017

openSUSE.Asia Summit 2017 was held at University of Electro Communication (UEC) Chofu Tokyo on October 20-22, 2017. Japan is an advance developed country. Tokyo is a big city that can be compared with other major big cities in the world. While it is not the first time for me to go to Tokyo, I was so excited when the committee approved my talk, and openSUSE, as always, give me TSP to come to the event. During the preparation we have  online meeting every week since February 15, 2017. I was so happy to help the preparation of this yearly openSUSE Summit for Asia Region. Indonesia community also contribute to provide the online voting for the logo contest this year through the voting site . On the midnight on October 17, 2017 together with my friend Estu Fardani , I went to Tokyo. It was 7 hours long flight. While almost half of the flight was so bumpy because the initiation of Lan Cyclone , in the morning of October 18, 2017 I enjoyed the clear sky with the golden hour in Ja...

Asterisk 1.6.1 on openSUSE 11.1 (Part 1)

In several articles from this one, I will share some of my experience in preparing emergency operation center for disaster management in Indonesia. One of the software we implement in this project is Asterisk. I use Asterisk 1.6.1.5 from openSUSE repository. Actually I built a custom 64 bit appliance using KDE 4.3 from factory repositories through SUSE Studio and took Asterisk from openSUSE Build Service repositories. Well, it was a couple years ago (by the time I submit this post), but I believe it still useful for anyone learning Asterisk :-) I also used DAHDI (Digium Asterisk Hardware Device Interface), but during the implementation I have a problem with Indonesia PSTN telephone signaling so I should download dahdi trunk version from digium subversion server to make the digium card works. Here are the hardware I use: 2 HP tower based server with 8 GB memory (it is overkill actually, but the owner insist it) running in high availability. See the pictures here and here . 10 PS...