We’ll gonna configure WRED (Weighted Early Random Detection) now
But…before we configure that WRED thing…what is WRED…even more…what is Congestion Avoidance??
Congestion Avoidance is a method for keeping the software queue from becoming full (here’s the link if you want to check the difference of hardware queuing and software queuing)
How? By dropping packet…literally
Specifically, by dropping the packet before it reach the maximum threshold configured
—————
Ok…back to bahasa Indonesia
Congestion Avoidance HANYA BEKERJA EFEKTIF pada TCP connection
Kenapa? Ada apa dengan UDP?
TCP behavior itu klo uda reach maximum bandwidth…dia akan ngurangin windows size jadi setengah…
(gw juga rada nyesel ga ngedalemin TCP/UDP…)
Masi inget windows size?!?
Gini…”A kirim 30 sapi ke si B…melalui negosiasi alot (TCP 3-Way Handshake)…akhirnya diputuskan untuk kirim 6 sapi sekali angkut (windows size)…kebetulan itu truk mampu ngangkat 6 sapi, ternyata usaha si A sukses tiap kali ngirim sapi, nah sekarang si A pake kontainer yang bisa 10 sapi, sukses lagi…kirim yang bisa angkut 20 sapi (increasing windows size)…terusss aja seperti itu, tapi tiap kali ngirim sapi pake truk, bikin jalanan agak macet (high payload), ganti container malah makin parah…sekali waktu, beneran macet parah (reach max. bandwidth)…akhirnya si A memutuskan jangan pake truk…pake truk lagi aja aja, masi bisa ngangkut 6 sapi sekali jalan”
That’s the analogy of TCP windows size retransmits, tiap kali interface full…windows size di-cut jadi setengah
Masalahnya disini adalah di TCP ada fitur yang bernama TCP Synchronization
“begitu si A memutuskan untuk ganti dari truk yang bisa angkut 6 sapi jadi mobil losbak yang cuma bisa 3 sapi gara2 macet, pengusaha2 lain juga akan mikir yang sama…pasti macet klo gw pake container…pasti macet klo gw pake limosin…akhirnya semuanya pada ganti kendaraannya yang kualitasnya setengah dari yang dipake tadi”
Hasilnya akan seperti grafis dibawah ini:
Nah, traffic A nih yang bikin penuh…dia nge-drop windows size nya jadi setengah, nah ketika si A nge-reduce windows size…yang laen juga
Efeknya ada di sini:
Under-utilization network…gimana caranya untuk supaya ga begitu (ga ada gap)?!?
Caranya adalah dengan men-define maksimum angkutan yang bisa jalan di jalan tol dalam satu waktu (maximum threshold) dan…
Begitu batas angkutan yang bisa masuk ke jalan tol terpenuhi maka pihak jalan tol akan “nge-lobangin” jalan tol-nya nya (Mark Probability Denominator – MPD)…hahaha, jadi dari 10 truk container…ada 1-2 yang ga nyampe (kecebur got…hahaha EXTREME)
Beda dengan UDP….dia mah tipikal protocol yang “kirim aja….bodo amat nyampe apa kaga, kaga ngaru di gw…wkwkkw”
========================
Now to config…
Keyword random-detect inilah yang mengaktifkan WRED (dari yang defaultnya tail drop)
Dah…itu doang…
Bused !!! penjelasan panjang2 keyword nya cuma ini…hahaha
WRED hanya bisa diaktifkan di class traffic yang ga didefine priority queuing didalamnya, dan minimal harus di configure dulu bandwidth nya
Nah…random-detect itu defaultnya nge-liat (ato nge-drop) packet berdasarkan IP Precedence
Loh…bukannya IP Presedence uda kuno ya…ya memang, tapi untuk jaga2 klo ada device2 yang belum ngerti “maenin” DSCP…Cisco masi pake IP Precedence, toh DSCP backward compatible dengan IP Precedence
Kita bisa bikin dia nge-drop berdasarkan DSCP…
Ketika kita ketik random-detect dscp-based…kita configure WRED dengan minimum dan maximum threshold serta MPD nya berdasarkan rekomendasi Cisco
Ato kita mau bikin sendiri (tweak) minimum threshold, maximum threshold, dan MPD nya…(gw ga rekomendasiin…pusing ah hahaha)
Random-detect dscp [nomor dscp] [min threshold] [max threshold] [mpd]
Jadi disini untuk packet2 dengan tipe AF31…kita define minimum 10 packet untuk kena “drop flag” dan maksimum 100 packet, dan ketika parameter 100 packet itu terpenuhi, 1 dari 10 packet akan di drop (MPD)
Annnnnnddd…to enhance the WRED….kita bisa tambahin ECN (link ke article gw yang bahas ECN)
Caranya…
Trus…cara nge-liatnya gimana?!?
Show policy-map interface [nomor]
Jangan lupa policy-map nya di implementasikan di interface output ya
WRED ??kok yang RED-nya sendiri ga dibahas…??
Jadi gini…ketika kita aktifkan random-detect…kita bukan aktifin RED…tapi WRED (min-max threshold dan MPD uda di atur otomatis ama Cisco)
Nah…ketika ada beberapa traffic yang di marking oleh WRED dengan DSCP/IP Precedence yang sama…maka untuk menentukan siapa yang kena drop ya pake RED itu sendiri (random)
Tapi gambar diatas kok ga ada yang di drop?? Karena gw lagi ga ngirim apa2 dasar duduuuul
hahaha
======================================
Fragmentation and Interleaving
Fragmentation itu kek gini:
“gw mo nganterin 4 orang ke desa pake mobil sedan (packet analogy)…tapi karena jalan didesa sempit2 (low bandwidth)…klo gw maksa untuk masuk sih bisa…cuma kasian yang lain antri dibelakang (bottleneck), oleh karena itu gw memutuskan mending itu 4 orang gw bagi 2 kelompok (fragmentation)…masing2 pake motor…lebih cepet…lebih ga bikin orang ngantri…”
Interleaving itu kek gini:
“karena itu jalan desa hanya sanggup dilalui motor…maka itu jalan penuh dengan motor pastinya…cuma kan ada motor yang bisa lari cepet yang klo bawanya lambat2 tuh pasti boros bensin jadi mending ngebut sekalian (voice packet) dan ada motor yang lambat (data packet)…klo itu jalan desa penuh dengan motor lambat…kasian yang motor cepet…akhirnya yang punya jalan memutuskan,silahkan ini jalan ke desa dipakai motor lambat…tapi klo ada motor cepet…tolong pada minggir yah (interleaving) biar bisa di salip”
Biasanya ini 2 fitur dipake di slow WAN connection kek frame-relay dan PPP
Nah…dari sini pula ada kelemahan dari LFI (Link Fragmentation and Interleaving)
Gw cuma bilang…daripada penuh itu jalan ke desa pake mobil (anggeplah mo nemuin Kades – Kepala Desa untuk urusan bisnis)…mending pada pake motor, nah…klo ketemu Kades untuk bisnis pasti ada surat keterangan untuk bisnis kan (packet header)?!?…berarti klo kita pecah jadi motor…klo motornya 2, artinya kita harus buat 2x surat keterangan pengajuan proposal bisnis (biar Kades tau itu 2 motor berada dalam perusahaan yang sama)…bener ga?!?…dan itu baru 2 motor….klo motornya rame?!?! Surat proposalnya juga harus dibikin banyak
Jadi LFI itu jgn digunain klo Bandwidth lo lumayan bagus (lo mecah jadi kecil2 itu packet malah membebani router lo, bikin packet yang mau dikirim dipecah2 untuk makan CPU…belum lagi tiap pecahan dikasi header…biar ga bolang alias bocah ilang)
How to apply these?!? In the interface
Lets see the example configuration below (int s0/0 with PPP multilink encapsulation):
Disini kita bilang…tolong ini packet di fragment sampe delay-nya mencapai 10milisecond
Jadi ini router kita suruh mikir…packet2 ini di pecah2 berapa bagian…sampe perintah delay <= 10 terpenuhi
Nah…command diatas HANYA mecah packet…jadi klo ada voice dateng ke interface ini…ya tetep DIBELAKANG (ga dikasi maju duluan/interleave)
So?!?..jadi?!?…how?!? ya configure interleave nya
Ini kan PPP…klo frame-relay gimana??
nah, ini dia yang bikin ribet…pertama dia ga bisa kaya PPP yang bisa ngatur sendiri fragmentasinya, yang kedua adalah gw sendiri KAGA PERNAH megang frame-relay kecuali NGE-LAB
Jadi mohon dimaapkan…
Penjelasan:
- Kita harus buat dulu map-class (untuk mapping traffic dari FR/ATM/dialer…wah, uda mulai masuk lagi ke protocol jaman kakek gua nih…wkwkw)
- Ketika kita define fragment size, kita harus “ngira2” sendiri…contoh gw punya koneksi 256 kbps, kira2 enaknya berapa yah fragment nya
- Delay yang di rekomendasikan oleh ITU-T (terutama delay untuk voice) adalah 10 sampai 15 milisecond…
- Nah, gw punya table dibawah…kira2 untuk link 256kbps…untuk bisa delay kurang dari 10milisecond…gw harus fragment tiap berapa byte yah
Table 1. source from QoS CBT Nugget (Jeremy Ciohara)
Dari table diatas kita bisa ambil kesimpulan…kita fragment 256 byte sampe “kira2″400 byte-lah
Kita ambil tengahnya aja…300 byte
========================================
Ada lagi yang disebut Header Compression
Contoh…lo punya IP header yang besarnya 40byte…ini bisa di compress sampe 2-4 byte aja
Pertanyaannya adalah…kok bisa??apa aja yang dikompress??pasti ada yang ilang/dibuang dong makanya bisa kecil banget gitu kompresinya?? Masa iya ip source & destination dibuang?? itu IP source/destination di compress juga gimana cara??emang bisa kebaca pas dikompress??
Nah looo….
Jadi begini…ketika session berlangsung (contoh: HTTP download ato RTP-nya voice)…ip source dan destination selalu sama kan?!? beda dengan mac-address yang selalu ganti2 per-hop
So…be my guest…klo sama tiap kali sesi berlangsung trus ngapain dibikin panjang2 headernya??…ganti aja pake sequence number buat jaga (track) itu packet, lagian pake TCP ini, kurang tinggal minta lagi (ACK)…
*AHA !! pencerahan*
jadi ip source dan destinationnya di “cache” dan ga dimasukin ke header lagi
cara konfig-nya kek gini:
Penjelasan:
- Kita mo compress RTP header jadi cRTP (compress RTP) dengan keyword compress (didalam subkonfig policy-map dan class nya)
- Yang harus diingat adalah…ini kita compress di R1 interface…otomatis itu paket uda ga bisa dibaca dengan “normal” lagi
- So…klo ada R2 yang konek ke R1…R2 ga akan bisa baca itu paket (jelas lah…ini paket apaan?!? Gada ip header-nya)
- Kesimpulannya…di masing2 router HARUS DIKONFIG COMPRESSION JUGA
Untuk nge-liat compression-nya (ato berapa banyak packet yang uda di compress), kita bisa pake show ip rtp header-compress [nomor interface]
Contoh lain yang lagi jalan voice session nya (serial 0/0)
4796 packet…4794 yang kena compress…yang di kompres adalah ip header compression (IPHC) dari RTP
Dan kita bisa liat efisiensi improvement sebesar 2,60 (gw ga ngerti ni….dalam percent ato dalam apa)
Dan juga kita bisa liat dari policy-map nya, seberapa banyak byte yang kita save dari penggunaan cRTP
Miftah Rahman (Go)-Blog 