Sebelum kita bahas config…kita bahas sejarahnya…
The First (and default) Congestion Management method adalah FIFO (First-in First-Out)
Ini kek antrian kereta api, nonton bioskop, dll…
“yang pertama antri/dateng, dia juga yang pertama kali masuk/keluar“
Jeleknya?!? Ga bisa buat voice, ga bisa menjamin delay, dan ga bisa menjamin bandwidth
Bayangin klo ada packet voice baru nyampe di jaringan (yang ga bole ada delay) disuruh antri paling belakangan…its a BIG NO!!!
**************
Ok…kalo gitu gimana klo kita PRIORITASKAN VOICE
!! HIDUP VOICE *wkwkw*!!! kita buat namanya Priority Queuing
Setelah dikonfig…wissss….voice traffic is verry smooooth
Abis itu ada yang teriak…”woiii….download-an gw putus mulu niiiih, woiii ga bisa browsing nih gw“
Uppss…itu bandwidth kemakan semua ama voice traffic…
Jadi tarolah voice dikasi 20% dari 100mb bandwidth yang ada dijaringan…nah, voice baru make sekitar 15% nih…
Kebetulan ada data stream yang lagi make 5% available traffic bandwidth, DIMANA 5% nya didapat dari traffic voice yang ga dipake
Ketika demand voice naik…data stream yang lagi make 5% dari bandwidth ini akan ditendang “demi kepentingan yang mulia” traffic voice (jadi ga sistem reserve bandwidth)
Well….say “maybe no…” to priority queuing
**************
And when the PQ (Priority Queuing) isn’t enough…here comes the Custom Queuing
“eh…supaya voice ga makan bandwidth, kita reserve aja bandwidth buat dia, begitu pula buat traffic yang lain“
Contoh: 50% bandwidth buat voice, 30% buat video, 20% buat data
Tapiiii tetep voice harus duluan…bagus kan!??! Wah…bagus2
Wokeeh…voice duluan (cakeeep), abis itu video (mantep), abis itu data (sipp)..terussss aja kek gitu
Disaat voice dan video uda selesai ngirim, pas traffic data dikirim…eh…ada packet voice mau masuk nih
“eit…ntar dulu…data belum selese nih“
*Gubrak*…..jelek ni maenannya…round-robin….ganti2an
What…sama aja boong dong…pas voice selesai nganterin packet, video ama data ngirim…itu packet voice nunggu dong
Yup…ini Queuing bisa reserve bandwidth…tapi ga bisa menjamin delay jadi lebih kecil
Baiklah…kita cari lagi metode lain…
**************
“eh gimana klo kita pake metode biasa aja…yang sering ngirim packet (kek voice) kita kasi maju duluan packet nya, tapi begitu ada packet yang jarang dikirm (contoh: telnet) kita kasih prioritas untuk duluan jalan“
Weh…sound great !!! inilah yang dinamakan Weighted Fair Queuing (WFQ)
WFQ adalah metode queuing default untuk slow WAN link (E1/T1)
“Eh…kok gw lagi asik2 nelpon tiba2 putus sih, apalagi pas si admin lagi mo nge-cek device (telnet)…pasti putus nih voice gw“
Ups….kita lupa…Voice ga bole disalip oleh traffic lain, meskipun itu traffic jarang2 muncul di jaringan, voice harus steady dan ga bole diganggu…
*gubrak* salah lagi nih…*emang rese nih voice packet*
**************
“ehm…gimana klo kita bikin voice, video, dan data itu ada reverse bandwidthnya kek Custom Queuing, tapi klo ada packet yang jarang ngirim maka dia akan di prioritaskan (pake metode WFQ), toh dia ga akan bisa ngambil bandwidth dari yang lain kok (uda di reserve)“
Even more great !!!…ini yang dinamakan Class-Based WFQ (CBWFQ)
Jadi kita bikin pake MQC (see link), bikin class-map (metode yang sama dengan Custom Queuing) untuk berbagai tipe traffic yang kita define bandwidth percentage-nya
Nah, class-map terakhir yang bernama class-map default (pasti ada ini) pake metode WFQ (kita liat config-nya nanti dibawah)
Eh..tapi gw lupa…Queuing untuk class-map yang kita bikin/define masi pake ROUND ROBIN
!!!
*Eaaalah gubrak…multiple gubrak facepalm*
**************
Hmm…round-robin ya…satu2nya cara ngilangin round-robin ya pake PQ…priority
“tapi kan rakus…“
Kita limit…bukan kita reserve…limit aja…jadi you bisa pake i punya traffic voice UP TO berapa persen (sambil bayangin gaya ngomong gw kek aristokrat)
“trus klo kita define buat voice…yang laen gimana“
Yang lain…makin ketinggalan *maap iklan*
Hmm…aha
!!…bagaimana klo traffic2 selain dari PQ ini kita pasangin CBWFQ
Kita ensure stream packet voice uninterrupted dan yang lain pake round-robin dengan bandwidth reserve
Cerdasss !!! *alay*
Kita namain ini metode Low Latency Queuing (LLQ)
*bukan gw yah yang namain wkwkw*
LLQ = PQ + CBWFQ (Custom Queuing + WFQ)
===================================
Metode2 diatas adalah metode software queuing *loh?!*
Hardware queuing selalu pake FIFO, KALAUUUU penuh…baru pake software queuing, gituu loh
ini kalo router….klo switch MEMANG Hardware Queuing
hardware queuing di-perform oleh yang namanya ASIC…tapi masalahnya, karena ASIC ini physical bukan logical…tiap tipe switch pasti beda2 ASIC-nya, semakin mahal switch-nya…semakin bagus hardware queuing-nya…(remember 1p4q3t klo di Cat6500?!? ato 3q4t di Cat3560??)
Nah…software queuing yang kita pake apa nih?!? Ya yang LLQ lah…
Jadi inti dari topik kita kali ini adalah Configuring Congestion Management (with LLQ) hahaha
Kenapa LLQ???…karena dengan belajar LLQ, kita juga otomatis belajar CBWFQ dan PQ
Dan…karena thesis gw maenin LLQ, gw lebih suka bahas LLQ hahaha
First…define traffic yang mau dikasi PQ dan define traffic mana yang mau dikasi CBWFQ
Contoh kita ambil traffic HTTP pake CBWFQ dan Voice pake PQ (pastinya)
Create Classification First
Then Marking and Policing
Penjelasan:
- Keyword untuk mengaktifkan PQ adalah priority [value KB atau persentase]
- Disini voice traffic PASTI digaransi dapet 30Kbps, klo mau maenan persen…pake priority percentage [value]
- Mungkin aja voice cuma makan 10kbps…20kbps-nya dimakan data, tapi ketika demand voice traffic mulai meninggi…itu data stream akan di tendang2in…sampe reach 30kbps (limit)
- LLQ ga akan jalan klo ga ada keyword priority (punyanya PQ)
- Keyword bandwidth untuk menyatakan klo kita pake Custom Queuing untuk traffic2 yang kita sudah define
- Nah, class default (yang ga di define) pake WFQ
- Note: gw ngetik class-default…class-default uda ada dari sono-nya tanpa harus gw define dulu (liat, gw masukin class asal-asalan gw ke policy-map wkwkw, tapi ga akan bisa dimasukin ke policy-map klo belum di define sebelumnya)
- Fair-queue adalah metode queuing untuk class-default nya (gw cuma mo nunjukin doang, ga diketik juga gpp)
- Gabungan dari WFQ + Custom Queuing = CBWFQ
- Jadi LLQ itu sendiri ga ada settingan khusus…pure gabungan dari konfig PQ+CBWFQ = LLQ
- Understand ?!?
The last step…apply to interface
Ups…kenape nih?!?
Cisco punya rule…traffic2 yang di define…total ga bole sampe 75% dari total bandwidth yang ada, jadi yang class-default (entah apapun tipe traffic yang ada disana) bisa jalan dengan menggunakan 25% bandwidth sisa
Kenapa bisa begitu?? Udah..percaya aja…Cisco punya divisi R&D yang ga perlu lo tanyain lagi kek apa kerjanya mereka wkwkw
Bisa ga kita rubah?!? Bisa…pake max-reference bandwidth
Baru deh bisa “tabrak” itu policy traffic-nya Cisco…tapi tidak disaran kan rubah2 begini…
Now lets get in-depth about PQ configuration
Priority dalam PQ adalah metode untuk ensure bahwa THE FIRST KILOBIT or THE FIRST PERCENTAGE OF TOTAL BANDWIDTH is go to that classified traffic
Kita bisa define pake % ato langsung dalam kilobit
Sekarang masuk ke CBWFQ configuration
Disini kita bisa pilih…kita bisa reserve bandwidth dengan 2 cara, minta router untuk ngasi “%” dia punya bandwidth (ato mau langsung dalam kilobit)
Ato minta router untuk ngasi “%” dari bandwidth sisa yang ada…
Jadi klo kita ngetik “bandwidth remaining 20” artinya dari sisa bandwidth yang ada, contoh gw punya 1000mbps/1 Gbps…sisa 100 mbps, gw dapet 20mbps buat si class HTTP
Nah karena kita pake nya percent…makanya cisco qos policy-nya nolak (Cisco rule yang 75% tadi)…klo kita pake bandwidth remaining percent…baru bisa
Ini hasil show policy-map LLQ nya
Inget…class-default pasti ada (walaupun ga keliatan di show)…jadi traffic2 yang kaga ke-define…masuk ke sini, defaultnya pake fair-queuing (WFQ)
Nah…ada 1 lagi…mumpung inget
Nah lo…kenapa ini!?
Nah…kita bisa pake QoS bertipe input klo kita mau nge-limit traffic/policing traffic/mark itu traffic untuk di “apa2in” di outbound/egress interface atau di router lain
Sedangkan queuing itu bertugas ngatur SIAPA DULUAN YANG BOLE KELUAR DARI INTERFACE
So..untuk queuing kita pake output aja…
Remember this 2 things
- Kita ngatur berapa banyak packet yang bole masuk kedalam interface untuk menghindari bottleneck dengan cara POLICING the traffic (example: lewat dari threshold…”exceed-action drop”, here’s the link to my previous article),Policy-map input hanya berguna (menurut gw) di MLS (Multilayer Switch)
- Kita ngatur berapa banyak packet yang bole keluar dari interface karena kapasitas hardware queuing juga terbatas…makanya dilempar ke logical queuing/software queuing, thats when Congestion Management takes effect (CBWFQ, LLQ, and PQ) dan supaya itu software queuing ga terlalu banyak yang antri…kita pake Congestion Avoidance (WRED)
Miftah Rahman (Go)-Blog 