## Penyebab Switch Menolak Paket DHCP
Kalau lagi setup jaringan dan tiba-tiba klien nggak dapet IP, sering banget biangnya ada di switch yang “nolak” paket DHCP. Kedengarannya ribet, tapi tenang—sebenarnya ini cuma kombinasi fitur keamanan dan setting yang nggak nyambung. Di artikel ini, kita bahas dengan bahasa santai kenapa switch bisa nge-drop paket DHCP, plus gimana cara ngecek dan beresinnya biar semua device auto dapat IP tanpa drama.
## Sekilas: DHCP itu ngapain sih?
DHCP (Dynamic Host Configuration Protocol) itu yang ngasih IP address otomatis ke perangkat. Flow dasarnya sering disebut DORA:
– Discover: klien “teriak” nyari server DHCP.
– Offer: server nawarin IP.
– Request: klien minta IP yang ditawarin.
– Acknowledge: server konfirmasi, “Oke, itu IP buat kamu.”
Semua langkah awalnya pakai broadcast (UDP 67/68). Nah, di sinilah switch kadang ikut campur demi keamanan—dan kalau setting-nya nggak pas, paketnya malah dibuang.
## Kenapa Switch Bisa “Nolak” Paket DHCP?
### 1) DHCP Snooping/Guard salah konfigurasi
Ini fitur keamanan yang ngeblok DHCP server liar. Efek sampingnya: kalau port uplink ke DHCP server nggak ditandai sebagai trusted, semua balasan DHCP dari server bakal di-drop.
Ciri-ciri:
– Klien kirim Discover, tapi nggak pernah dapat Offer.
– Log switch ada tulisan mirip “DHCP-SNOOPING drop” atau “untrusted port”.
Solusi:
– Tandai port ke server/DHCP relay sebagai trusted.
– Aktifkan DHCP snooping hanya di VLAN yang benar.
– Cek juga rate-limit DHCP di port; kalau terlalu ketat, paket bisa ke-throttle.
### 2) VLAN mismatch atau salah tagging
DHCP itu main di VLAN yang spesifik. Kalau klien di VLAN 20 tapi trunk ke server/relay nggak mengizinkan VLAN 20, ya paketnya nggak akan sampai.
Cek:
– Access port klien: VLAN-nya bener nggak?
– Trunk: VLAN yang dibutuhkan masuk daftar “allowed”?
– Native VLAN antar trunk sama?
Solusi:
– Samakan VLAN di access port, trunk, dan SVI/relay.
– Pastikan “allowed VLANs” di trunk termasuk VLAN klien.
### 3) ACL di switch Layer 3 ngeblok UDP 67/68
Kalau pakai switch L3, bisa jadi ada ACL (Access Control List) yang nggak sengaja memblok traffic DHCP (UDP 67 server, 68 client), atau memblok broadcast.
Solusi:
– Tambah rule permit untuk UDP 67/68 (both directions) di VLAN terkait.
– Pastikan broadcast internal VLAN tidak diblokir.
### 4) Storm-control atau broadcast suppression terlalu ketat
Beberapa admin ngebatesin broadcast biar jaringan nggak banjir. Masalahnya, DHCP Discover itu broadcast. Kalau limit terlalu rendah, paket DHCP ikut ke-sweep.
Solusi:
– Naikkan threshold storm-control di access port.
– Monitor apakah drop count naik setiap ada banyak klien booting bareng.
### 5) Port security nge-kick paket
Port security bisa membatasi jumlah MAC address. Saat device baru join, paket DHCP bisa di-drop karena dianggap “kelebihan” MAC atau nggak masuk daftar.
Solusi:
– Naikkan limit MAC atau pakai sticky MAC kalau perlu.
– Cek apakah port jadi err-disable akibat violation.
### 6) DHCP Relay belum diaktifkan (buat jaringan routed)
Kalau server DHCP beda VLAN, harus ada relay/agent (misalnya ip helper-address) di SVI VLAN tersebut. Tanpa relay, Discover (broadcast) nggak pernah menyeberang VLAN.
Solusi:
– Aktifkan DHCP relay di interface VLAN klien.
– Kalau switch menambahkan Option 82, pastikan server menerima/kenal Option 82 itu.
### 7) Option 82 (Relay Information) bikin server “geli”
Switch/relay bisa nambahin info Option 82. Beberapa server DHCP di-set ketat—kalau Option 82 tidak valid atau tidak dikenali, tawarannya ditolak.
Solusi:
– Sesuaikan policy Option 82 di switch (insert/keep/replace).
– Atur server untuk mengizinkan atau memproses Option 82 dari device tersebut.
– Kalau nggak butuh, matikan insertion Option 82.
### 8) Dynamic ARP Inspection (DAI) tanpa DHCP snooping binding
DAI pakai tabel binding dari DHCP snooping. Kalau DAI aktif tapi tabel binding kosong/invalid, traffic klien bisa di-drop setelah dapat IP—terlihat seperti masalah DHCP, padahal diterusannya yang keganjal.
Solusi:
– Pastikan DHCP snooping aktif dan binding terisi.
– Tandai port yang tepat sebagai trusted.
– Sinkronkan VLAN untuk snooping dan DAI.
### 9) Spanning Tree belum konvergen atau port belum “siap”
Saat port baru up, STP bisa menahan traffic beberapa detik. Kalau klien sudah kirim Discover pas port belum forwarding, paketnya nyangkut.
Solusi:
– Aktifkan fitur edge/portfast di access port.
– Hindari loop; cek apakah port kena blocking/err-disable.
### 10) Fitur DHCP server-blocking lain (DHCP Guard)
Beberapa OS switch punya “DHCP Guard” atau kebijakan serupa yang spesifik menghalangi server dari port yang salah. Ini mirip snooping, tapi kebijakan bisa lebih granular.
Solusi:
– Audit policy DHCP Guard dan pastikan hanya memblok port yang tidak seharusnya jadi server.
## Checklist Troubleshooting Cepat
– Cek VLAN:
– Access port klien di VLAN yang benar?
– Trunk mengizinkan VLAN itu?
– Native VLAN konsisten?
– Cek DHCP Snooping/Guard:
– Port uplink ke server/relay diset trusted?
– VLAN DHCP snooping sesuai?
– Ada log drop terkait snooping?
– Cek Relay:
– Di SVI VLAN klien, ada helper-address ke server?
– Option 82 sesuai kebijakan server?
– Cek ACL dan broadcast:
– UDP 67/68 diizinkan?
– Broadcast internal VLAN tidak diblok?
– Cek proteksi lainnya:
– Storm-control nggak terlalu ketat?
– Port security nggak nge-limit MAC berlebihan?
– DAI selaras dengan snooping binding?
– Portfast aktif di access port?
– Cek fisik dan STP:
– Link stabil, nggak flapping?
– Port nggak err-disable?
Tip tambahan: saat debugging, pantau paket dengan mirrored port/SPAN ke analyzer. Lihat apakah Discover keluar dari klien, apakah Offer balik, dan di mana paketnya mandek.
## Best Practice Biar Nggak Keulang
– Tandai uplink ke DHCP server atau ke router/relay sebagai trusted sejak awal.
– Dokumentasikan VLAN-to-Server mapping, termasuk allowed VLAN di semua trunk.
– Terapkan portfast di semua access port, terutama yang ke end user/endpoint.
– Gunakan storm-control dengan angka realistis, lalu pantau ketika banyak device boot bareng.
– Sinkronkan kebijakan Option 82 antara switch/relay dan server DHCP.
– Simpan template konfigurasi standar untuk access port, trunk, snooping, relay, dan ACL—biar konsisten.
– Logging yang jelas: aktifkan log drop untuk fitur-fitur keamanan supaya cepat ketahuan salahnya di mana.
## Penutup
Switch bukan “jahat,” dia cuma protektif. Kalau paket DHCP ditolak, biasanya karena fitur keamanan yang niatnya baik tapi setting-nya kurang pas: VLAN nggak nyambung, uplink belum trusted, ACL terlalu ketat, atau relay belum diaktifkan. Dengan checklist dan best practice di atas, kamu bisa cepat nemuin biang keroknya dan bikin semua device otomatis dapat IP lagi—tanpa perlu reboot massal atau drama tengah malam.