Jaringan kantor tiba-tiba tidak stabil padahal kabel masih terpasang dan tidak ada perubahan konfigurasi. Beberapa komputer bisa saling ping, yang lain tidak — pola yang tampak acak. Akses internet putus-putus. Tim IT sudah cek ISP normal, server normal, listrik normal. Tapi masalah tetap ada. Salah satu penyebab yang sering luput dalam skenario ini: ARP table di switch sudah penuh. Masalah layer 2 ini tidak terlihat dari tools monitoring traffic biasa, tapi dampaknya menyebar ke seluruh pengguna jaringan. Artikel ini menjelaskan cara mengenali gejalanya, perintah diagnosa untuk multi-vendor switch (termasuk Ruijie RG yang umum di kampus Indonesia), dan solusi permanen agar tidak berulang.
Apa Itu ARP Table
ARP (Address Resolution Protocol) adalah mekanisme yang dipakai jaringan untuk menghubungkan IP address ke MAC address perangkat di jaringan lokal yang sama. Setiap kali komputer A ingin komunikasi dengan komputer B di subnet yang sama, A mengirim broadcast "Siapa yang punya IP 192.168.1.50?" — B menjawab dengan MAC address-nya — informasi ini disimpan di ARP cache untuk dipakai berikutnya tanpa broadcast ulang.
Switch managed (yang punya routing layer 3 atau bertindak sebagai gateway) menyimpan ARP table di memori hardware-nya yang terbatas. Kapasitas bervariasi menurut grade dan model switch. Saat jumlah perangkat aktif di jaringan melebihi kapasitas ini, switch tidak bisa lagi memetakan IP ke MAC dengan benar — dampaknya: traffic ke perangkat yang tidak tertampung akan gagal di-route, alias blackholed.
Visualisasi: Bagaimana ARP Overflow Memengaruhi Traffic
Diagram berikut menunjukkan apa yang terjadi saat ARP table belum penuh (kondisi normal) vs sudah overflow:
KONDISI NORMAL — ARP Table 60% terisi
══════════════════════════════════════
PC-A (192.168.1.10) PC-B (192.168.1.50)
│ │
│ "Siapa pemilik 192.168.1.50?" │
├─────────► Switch ──── broadcast ─►
│ │ │
│ │ ARP Table: │
│ │ 192.168.1.50 = aa:bb:cc:dd:ee:ff
│ │ ✅ Diingat │
│ │ │
│ ◄─────── route langsung ───────►│
→ Latency: <1ms, no broadcast lagi untuk session ini
KONDISI OVERFLOW — ARP Table 100% terisi
══════════════════════════════════════
PC-A (192.168.1.10) PC-B (192.168.1.50)
│ │
│ "Siapa pemilik 192.168.1.50?" │
├─────────► Switch ──── broadcast ─►
│ │ │
│ │ ARP Table: PENUH ❌
│ │ Reply diterima TAPI
│ │ tidak bisa di-cache
│ │ │
│ ◄─── flooding ke SEMUA port ────►│
│ ◄─── flooding ke SEMUA port ────►│
│ ◄─── flooding ke SEMUA port ────►│
→ Setiap paket ke 192.168.1.50 broadcast ulang
→ Switch CPU 100%, semua user terdampakYang dirasakan user: koneksi terasa kadang-kadang berhasil, kadang-kadang tidak. Itu karena saat ARP overflow, switch berhasil reply untuk beberapa request (yang kebetulan masuk window cache turnover) tapi gagal untuk yang lain. Pola "intermittent" inilah yang sering bikin tim IT kira ada masalah kabel atau perangkat user.
Gejala ARP Table Penuh
| Gejala | ARP Table Penuh | Masalah Lain |
|---|---|---|
| Ping ke IP lokal (gateway/NAS) | Timeout intermittent ❌ | Biasanya konsisten timeout / OK |
| Pola perangkat yang terdampak | Acak — beberapa OK, beberapa tidak | Cluster — satu segmen kabel/AP saja |
| Restart switch | Langsung normal selama beberapa jam ✅ | Tidak membantu |
| Restart router/modem | Tidak membantu ❌ | Membantu kalau masalah di router |
| Konfirmasi ISP | Normal di sisi ISP | Mungkin ada gangguan |
| Speed test (yang berhasil connect) | Normal ✅ | Sering turun |
| Akses internet langsung dari router | Normal ✅ (bypass switch) | Tergantung sumber |
Tanda paling kuat yang membedakan ARP table penuh dari masalah lain: masalah hilang seketika setelah switch direstart, lalu kembali muncul beberapa jam kemudian. Pola siklik ini hampir patognomonik (sangat khas) untuk ARP overflow.
Tabel Kapasitas ARP Table per Model Switch (Indonesia)
Kapasitas ARP table di model switch yang umum dipakai di Indonesia. Angka ini per switch — kalau ada multiple switch di-stack atau di-cascade, masing-masing punya batasnya sendiri.
| Vendor / Model | Tipe | Kapasitas ARP | Cocok untuk |
|---|---|---|---|
| Ruijie RG-CS85 series | Enterprise L3 | 32.768 entries | Kampus besar, datacenter mini ✅ |
| Ruijie RG-NBS series | SMB L2/L3 | 4.096–8.192 | Kantor 100–300 user ✅ |
| Cisco SG350/SG500 | SMB L3 | 4.000–8.000 | Kantor 100–300 user ✅ |
| Cisco Catalyst 9200/9300 | Enterprise L3 | 32.000–64.000 | Kampus, gedung perkantoran ✅ |
| HP 1820 series | SMB L2 (web-managed) | ~512 | Kantor kecil <50 user ⚠️ |
| HP Aruba 2530 series | SMB L2/L3 | 8.000 | Kantor 100–200 user ✅ |
| TP-Link TL-SG3428 | SMB L2/L3 | ~4.000 | Kantor 80–200 user ✅ |
| TP-Link TL-SG2210 | SMB L2 (smart) | ~256 | Kantor kecil <30 user ⚠️ |
show platform resources atau equivalent untuk dapat angka real-time.Rule of thumb cepat: jumlah perangkat aktif × 1.3 = estimasi ARP entries yang dibutuhkan (×1.3 untuk margin perangkat IoT, multi-VLAN, dan perangkat yang baru ON/OFF). Jaringan dengan 200 user produktif + 50 perangkat IoT = ~325 entries. Switch berkapasitas 512 entries sudah marginal, 1024 entries aman, 4096+ punya headroom untuk growth.
Kenapa ARP Table Bisa Penuh
Diagnosa: Konfirmasi ARP Table Penuh per Vendor
Cisco IOS / Catalyst
Switch# show arp summary
Switch# show ip arp | count
Switch# show platform resources
# Cisco IOS-XE (Catalyst 9000):
Switch# show platform hardware fed switch active fwd-asic resource tcam utilizationCari baris yang menunjukkan ARP table usage mendekati atau melebihi kapasitas maksimum. Output show platform resources di Catalyst 9000 menampilkan resource utilization per ASIC.
Ruijie RG Series (Umum di Kampus Indonesia)
Ruijie banyak terpasang di kampus Indonesia karena harga kompetitif dengan fitur enterprise. Perintah show ARP-nya:
Ruijie# show arp
Ruijie# show arp statistics
Ruijie# show arp dynamic count
# Untuk lihat ARP per VLAN:
Ruijie# show arp vlan [vlan-id]
# Cek kapasitas hardware:
Ruijie# show resource arpOutput show arp dynamic count akan tampilkan total ARP dynamic entries (yang dipelajari otomatis, di luar yang static). Bandingkan dengan kapasitas dari datasheet model kamu (lihat tabel kapasitas di atas).
HP / Aruba
switch# show arp
switch# show arp statistics
# Aruba CX:
switch# show ip route summaryMikroTik (sebagai L3 switch atau gateway)
/ip arp print count-only
/ip arp print stats
# Per interface:
/ip arp print where interface=ether1Solusi Darurat — Clear ARP Table
Solusi paling cepat saat incident sedang berlangsung. Jangan langsung restart switch (downtime besar) — coba clear ARP cache dulu yang downtime-nya hampir nol.
| Vendor | Perintah Clear ARP | Downtime |
|---|---|---|
| Cisco IOS | clear arp-cache atau clear ip arp |
< 1 detik ✅ |
| Ruijie RG | clear arp-cache |
< 1 detik ✅ |
| HP / Aruba | clear arp |
< 1 detik ✅ |
| MikroTik | /ip arp flush |
< 1 detik ✅ |
| Restart switch (last resort) | Hard reboot atau power cycle | 2–5 menit ⚠️ |
Solusi Permanen — 4 Pendekatan
1. Turunkan ARP Aging Time
Percepat penghapusan ARP entries yang sudah tidak aktif. Trade-off: kalau terlalu pendek, perangkat yang aktif harus re-resolve sering, latency naik sedikit.
# Cisco — turunkan ke 5 menit (default 4 jam)
Switch(config)# interface vlan [id]
Switch(config-if)# arp timeout 300
# Ruijie — 10 menit
Ruijie(config)# arp timeout 600
# MikroTik — 5 menit
/ip settings set arp-timeout=5m2. Aktifkan Dynamic ARP Inspection (DAI)
Cegah ARP storm sebelum mengisi table. DAI akan rate-limit ARP request dan drop packet yang dianggap suspicious.
# Cisco
Switch(config)# ip arp inspection vlan [vlan-id]
Switch(config)# interface [port]
Switch(config-if)# ip arp inspection limit rate 100
# Ruijie (mirip syntax Cisco)
Ruijie(config)# ip arp inspection vlan [vlan-id]3. Distribusi Routing — Jangan Konsolidasi di 1 Switch
Kalau punya multi-VLAN, jangan paksa semua inter-VLAN routing lewat 1 core switch. Distribusikan routing ke beberapa device (mis. router terpisah, atau core switch + distribution switch). Setiap device punya ARP table sendiri = total kapasitas naik.
4. Upgrade Switch (Last Resort)
Kalau jumlah perangkat memang sudah melebihi kapasitas hardware, tidak ada konfigurasi yang bisa mengatasi batasan fisik. Pilihan: upgrade ke switch dengan kapasitas lebih besar (lihat tabel kapasitas di atas), atau split jaringan jadi beberapa segmen yang lebih kecil dengan switch terpisah.
Hubungan dengan Masalah Jaringan Lain
ARP table penuh sering muncul bersamaan dengan masalah jaringan lain — kadang sebagai gejala, kadang sebagai akar. Pola yang sering ditemui di insiden besar:
- IP publik masuk blacklist — bisa indikasi ada perangkat terinfeksi yang juga melakukan ARP flooding sebagai bagian dari aktivitas malicious.
- DNS tidak bisa resolve — bisa terjadi kalau DNS server di subnet yang ARP entry-nya kena flush. Solusi: flush DNS cache MikroTik setelah ARP cache dibersihkan.
- Telegram/API timeout — bukan karena ARP langsung, tapi kalau routing ke gateway bermasalah (karena ARP gateway hilang dari cache), semua koneksi keluar akan timeout.
- Loop / broadcast storm — kalau lampu switch berkedip sangat cepat bersamaan di banyak port, kemungkinan ada loop fisik di kabel + STP belum aktif. ARP storm bisa jadi gejala bukan penyebab.
FAQ — Pertanyaan yang Sering Ditanyakan
Kesimpulan
ARP table penuh adalah masalah layer 2 yang sering jadi blind spot dalam troubleshooting jaringan. Karena tidak terlihat dari monitoring traffic biasa dan gejalanya mirip banyak masalah lain (gangguan ISP, masalah DNS, virus), waktu diagnosa bisa lama kalau tim IT tidak tahu mau cek ke mana. Sidik jari paling kuat: masalah muncul tiba-tiba, restart switch langsung memperbaiki, dan tidak ada perubahan konfigurasi sebelumnya. Solusi cepatnya satu baris perintah (clear arp-cache di Cisco/Ruijie, /ip arp flush di MikroTik), tapi ini hanya membeli waktu. Untuk solusi permanen, pilih dari tiga opsi: turunkan ip arp timeout ke 5 menit, aktifkan ARP inspection untuk hentikan ARP storm, atau upgrade switch kalau jumlah perangkat memang sudah melebihi kapasitas hardware. Yang sering luput: ARP table penuh sering muncul bersamaan dengan IP blacklist atau DNS cache stale — kalau kamu lagi diagnosa incident jaringan besar, cek checklist diagnosa lengkap untuk pendekatan systematic.