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

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 Japan air around…

FOSSASIA 2017

It's been a while since last time I wrote to this blog. I've been busy with my work and don't have time to make a notes here. However there are some posts I write for openSUSE Indonesia, you can go this link if you will.

On January 12, Douglas DeMaio from openSUSE contact me if I have time to go to FOSSASIA 2017 schedule in Singapore on 17-19 March. I checked my calendar and the date was available for me. So I reply his email and said I will go there to represent openSUSE at booth.

openSUSE become Silver sponsor for FOSSASIA 2017, and also have 2 talks by my colleagues Gary Lin from SUSE Labs Taipei and Zhao Qiang from SUSE Beijing on Day 2. I (only) became a booth-person this time :-)

Doug sent me some stickers to bring to the crowd which consists of:
94 webcam covers
128 Tumbleweed stickers
108 Leap stickers
213 openSUSE stickers
174 OBS stickers
175 Portus stickers
116 Alex the Geeko stickers
56 small black Geeko stickers
78 power by openSUSE stickers
30 openSUSE pamphl…

Heartbeat dan DRBD

Dalam sebuah implementasi saya harus mengganti implementasi vrrpd (virtual router redundancy protocol) dengan heartbeat+drbd disebabkan adanya penambahan database dalam server yang digunakan. Service awal pada mesin ini hanyalah web server statis, named dan dhcpd yang relatif statis dan file-filenya saya sinkronisasi dengan rsync. Tetapi dengan adanya penambahan database (mysql) dibutuhkan sebuah mekanisme dimana data yang disimpan dalam satu mesin primary dapat secara langsung ditulis juga ke mesin backup. Untuk hal yang terakhir ini vrrpd saja tidak mencukupi karenanya saya harus mengganti vrrpd dengan heartbeat (baca hartbit, bukan hertbet :-) )sedangkan untuk menjamin mekanisme clusternya saya menggunakan drbd.

Implementasi heartbeat saja sangatlah mudah. Cukup mendownload, mengkompilasi dan mengkonfigurasi tiga buah file /etc/ha.d/ha.cf, /etc/ha.d/authkeys dan /etc/ha.d/haresources. Untuk drbd bisa download tarball dan jangan lupa untuk membaca dokumentasinya, karena drbd harus d…