Jawaban Latihan UAS Jarkom

Hai teman-teman kali ini saya akan membagikan sedikit ilmu, karena ilmu saya masih dikit makanya share ilmunya juga dikit. mohon di maklumi yah teman-teman, langung saja. Bismillahirohmanirrohim. Ingat yah jawaban ini belum tentu benar semua, mohon di cek lagi yah. kalo ada yang salah silahkan comment untuk update jawabannya. :

Terimakasih, bagi teman-teman yang bersedia mampir di blog saya ini.

Read more ...

DNS & Transport Layer

Hai teman-teman kali ini saya akan sharing catatan kuliah Jarkom saya. kali ini akan membahas apa sih yang di sebut dengan DNS dan transport layer dan bagaimana cara kerjanya langsung saja,
Bismillahhiromanirrohim :

Read more ...

Class-Map and NBAR for QoS

Class-map punya 2 behavior…match-all (default) dan match any (cukup 1 parameter aja yang match)
Tapi kita bisa bikin kek gini:

Artinya disini class-map dengan nama contoh-classmap harus match dengan semua parameter yang ada KECUALI yang masuk filter ACLforQoS
Ini mirip kek analogi passive-interface default, contoh:

Semua interface tidak boleh jalanin OSPF KECUALI fa0/0
========================
NBAR (Network-Based Application Recognition)

Ini adalah cara device cisco (router & switch) untuk bisa ngenalin paket berdasarkan aplikasi
Caranya? We’ll see in class-map:

Nah…inilah aplikasi2 yang dikenali oleh Cisco…
Tapi gimana klo ada aplikasi baru yang ga dikenali oleh Cisco?? Updatenya gimana??
Cara pertama…update IOS (REJECTED…pasti pada males kan…wkwk)
Cara kedua…download PDLM (Packet Description Language Module)
Go to cisco.com pdlm download (must have CCO login)
Trus taro di flash router…integrasikan pdlm-nya dengan IOS

ups..maap, ga ada pdlm buat aplikasi bernama “cacad” wkwk
Nah..sekarang pertanyaannya adalah…cara liat trafficnya gimana??

Kok ga ada?? Kita harus aktifkan dulu NBAR protocol-discovery di interface

Untuk show ip nbar ini bisa sangat panjang…contoh gw mo liat top-5 aplikasi yang jalan di network gw berdasarkan bit-rate

Ketikan full command-nya “show ip nbar protocol-discovery stats bit-rate top-n 5“
Lumayan panjang kan (daripada lu-manyun)
Nah…kita bisa ketik alias

Alias exec [nama command yang baru] [show bla bla bla]

secara default…router akan ngecek traffic setiap 5menit interval…klo kita mo rubah untuk nge-cek tiap 1 enit (60 detik)…caranya dengan modifikasi load-interval di interface subconfig

Catetan gw masih acak2…nanti de gw rapihin

Configuring Bridge

October 9, 2013

Miftah Rahman Config Router bridge, bvi, frame relay bridging, irb, source-route bridging, SR/TLB bridging, translational bridging, transparent bridging Leave a comment

Berawal dari penasaran gw tentang frame-relay bridging…
Akhirnya inilah catetan gw (WOI REN…JALAN JUGA NIH KONFIG GW, DUDUL)
Nah….kita pake topologi kek gini…gimana cara konekin R1 dan R2 ip loopback?

Wih…mudah lah…tinggal pilih…pake static apa dynamic route

Tapi klo kasusnya kek gini gimana?!?

gimana caranya R1 dan R2 bisa saling ngomong dengan IP yang satu subnet tapi kepisah oleh WAN (misalkan)

Oleh karena itu kita perlu teknologi yang namanya BRIDGE/BRIDGING

Let’s see the initial configuration


And now…R3 & R4


Penjelasan:

• Topologi diatas disebut transparent bridging, nah..konfigurasinya harus pake integrated routing and bridging (irb) technology (sebelum IOS 11.2 blum ada ini)
• Kita define bridge nomor 1 mo pake protocol apa (ieee, dec, ibm, ato vlan-bridge)
• Trus kita define ini bridge nomor 1 bisa “nganterin” paket apa (ip, decnet, ipx, ato apple talk)
• Trus kita asosiasikan masing2 interface fisik dari R3 dan R4 ke bridge-group 1 (jangan di kasi IP yah)
• Nah…kasi ip nya di interface bvi (bridge virtual interface) dengan IP yang satu subnet dengan R1 dan R2

Let’s ping this BVI (bridge virtual interface) from each other

Done…
Let’s take a look on R1 (and R2)

Wuuuusss….OSPF Adjacency…cek ip routing table

Ip 2.2.2.2-nya R2 dapet…

Bahkan ketika kita trace route…ga nampilin ip R3 dan R4 (soalnya pake interface virtual)
Klo kek gini gimana???

Ya bikin aja 2 bridge-group, 1 untuk 10.X.X.X, 1 lagi untuk 20.X.X.X
Trus klo kek gini?!?

Bisa looping…tapi tenang, dimana ada looping…disitu juga akan muncul “makhluk gaib” yang namanya STP (spanning-tree) hahaha
Karena bridging bikin seakan2 bikin 2 buah router ato lebih jadi 1 LAN…
————–
Nah…tipe dari bridge itu ada 4, dilihat dari tipe media yang digunakan
…yang pertama uda dibahas disini
Yang kedua adalah Source-Route Bridging (SRB), biasanya ada di Token Ring
Here’s the link configuration
Yang ketiga adalah Translational Bridging, untuk nge-bridge Ethernet dengan Token Ring ato media yang lain
Terakhir adalah Source-Route Translational Bridging (SR/TLB), gabungan dari yang kedua dan ketiga, in mixed environment
Here’s the link configuration

Read more ...

Configuring Congestion Management (Queuing)

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

1. 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)
2. 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)

Read more ...

Congestion Avoidance, Fragmentation, Interleaving, and Header Compression Configuration

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

Read more ...