Case-Based Scenario Assessment
10 skenario kasus nyata teknisi jaringan — multi-step decision tree ala Cisco Certified online assessment. Setiap skenario diangkat dari kasus yang sudah didokumentasikan di artikel cekipsaya.com.
Email Klinik Pak Budi Selalu Masuk Spam Folder
[email protected]. Server email pakai cPanel hosting,
IP publik mail server 103.10.x.x. Kamu sebagai teknisi diminta diagnosa
via remote (Pak Budi tidak teknis, hanya bisa screen-share).
Pilih tool diagnosa pertama
Apa yang kamu cek pertama dari 4 opsi ini?
Hasil cek: IP 103.10.x.x kena Spamhaus PBL
PBL artinya apa, dan apa yang sebaiknya dilakukan?
Pak Budi tidak bisa ganti IP (kontrak hosting 1 tahun)
Rekomendasi paling tepat untuk Pak Budi?
📋 Debrief Skenario S01
Lesson umum: Email deliverability adalah masalah multi-faktor:
IP reputation, DNS records (SPF/DKIM/DMARC), content scoring. Tool /blacklist-check/
menyelesaikan tahap pertama (reputation). Untuk SMK TKJ: skenario ini realistis,
sering ditemui di klien UKM di Indonesia karena mayoritas hosting shared pakai IP
yang historic-nya pernah dipakai banyak klien — bisa kena PBL kolektif.
Artikel referensi cekipsaya: /artikel/kenapa-ip-masuk-blacklist/ · cara-cegah-ip-kampus-masuk-blacklist/
"Internet Lemot Padahal Bayar 100 Mbps"
Speedtest sudah OK, kenapa pengalaman tetap lambat?
Hipotesis paling masuk akal:
Tool selanjutnya untuk validasi hipotesis?
Pilih tool yang paling tepat:
Hasil traceroute ke server game Singapore
Hop 1 (gateway warnet) RTT 1ms. Hop 2 (BNG ISP) RTT 5ms. Hop 3 (CGNAT NAT) RTT 12ms. Hop 4 (peering ISP→transit) RTT 180ms. Hop 5–9 (transit AS) RTT 180–195ms. Server tujuan 200ms. Diagnosis:
Rekomendasi ke klien?
Apa langkah paling tepat?
📋 Debrief Skenario S02
Lesson umum: "Internet lemot padahal bayar mahal" adalah salah satu komplain paling umum di Indonesia. 80% kasus = bandwidth OK tapi latency/jitter buruk. Skill untuk membedakan ini = pembeda teknisi competent vs teknisi yang hanya "restart router".
Artikel referensi cekipsaya: threshold-normal-mtr-stdev-wrst-jitter/ · apa-itu-traceroute-cara-membacanya/
VPN ke Singapura Lebih Cepat dari Direct?
Hipotesis awal
Penjelasan paling masuk akal:
Cara validate hipotesis
Tool dan metodologi paling tepat:
Hasil traceroute komparatif
Direct: 14 hop, lewat AS65000 (transit kampus) → AS20485 (transit IIX) → AS6939 (HE) → AS destination, total RTT 380ms. Via VPN-SG: 7 hop, lewat AS Singapore IX langsung ke AS destination, total RTT 95ms. Konklusi yang tepat?
📋 Debrief Skenario S03
Lesson umum: "MTR Paradox" — VPN kadang lebih cepat dari direct karena perbedaan AS path/peering, bukan karena VPN punya kemampuan magis. Untuk SMK TKJ tingkat lanjut: paham konsep ini = bisa explain ke klien tanpa jatuh ke "ya pakai VPN saja" yang tidak menyelesaikan root cause untuk organisasi besar.
Artikel referensi cekipsaya: /artikel/apa-itu-asn/ · kenapa-ping-ke-as-number-loss/
CCTV Klien Tidak Bisa Diakses dari Luar (Port Forward Gagal)
/port-checker//cek-ip-saya/ Tamu Bypass Hotspot Login MikroTik dengan Trik VPN
/dns-lookup//port-checker/ Setelah Migrasi Server, DNS Tidak Update di Sebagian PC
/dns-lookup/ Desain Subnetting Kantor Multi-Lantai 250 Device
/subnet-calculator/ ARP Table MikroTik Penuh Device Asing — Network Bocor?
/mac-vendor-lookup/ Domain Baru Tidak Resolve — "Server Not Found"
/dns-lookup/ WireGuard Tunnel UP Tapi Traffic Tidak Lewat
/ping-test//traceroute/