คู่มือออกหน้างาน รวม 7 สาเหตุที่ทำให้ LAN ช้า ตั้งแต่ broadcast storm, duplex mismatch, ไปจนถึง uplink เต็ม พร้อมคำสั่ง diagnosis

1. แยกก่อนว่า ช้าที่ network หรือ ช้าที่ server#

ก่อนจะไปงัด switch ออกมาดู ต้องแยกอาการให้ออกก่อน เพราะคำว่า เน็ตช้า จากปาก user มันรวมทุกอย่าง ตั้งแต่ DNS เพี้ยน ยัน database lock

อาการที่บ่งชี้ว่าเป็น network จริง มักจะมีลักษณะดังนี้

ping ภายในวงเดียวกัน latency สูงผิดปกติ (ปกติ LAN ควร < 1 ms) หรือมี packet loss เป็นระยะ
ping ไปหลาย host พร้อมกัน ช้าทุกตัว ไม่ใช่ตัวเดียว
โหลดไฟล์จาก file server ช้า แต่ระบบบนเครื่อง server เองยัง responsive
copy ไฟล์ใหญ่ throughput ต่ำกว่า speed link ที่เจรจาไว้มาก (เช่น link 1 Gbps แต่ copy ได้แค่ 5 MB/s)

ถ้า ping ดี แต่เปิดเว็บ/แอปช้าตัวเดียว ส่วนใหญ่เป็นปัญหา application หรือ DNS ไม่ใช่ LAN

2. 7 สาเหตุหลักที่เจอบ่อย พร้อมวิธี diagnose#

สาเหตุที่ 1 — Broadcast storm#

เกิดตอนมี broadcast/multicast packet วิ่งวนใน VLAN เดียวกันเยอะผิดปกติ ทั้ง switch CPU และ NIC ของทุกเครื่องในวงต้องมาประมวลผลแฟรมพวกนี้ทิ้ง ผลคือทั้ง VLAN ช้าพร้อมกัน

ที่เจอบ่อยคือ switch loop เพราะไม่ได้เปิด STP, NIC เสียแล้วยิง broadcast ออกมารัว ๆ หรือไม่ก็ broadcast domain ใหญ่เกินไป (เช่นจัด /16 รวมพันเครื่องในวงเดียว)

วิธี diagnose บน Cisco

show interfaces counters broadcast
show processes cpu sorted | exclude 0.00
show interfaces | include rate|broadcasts

ดูว่า port ไหน broadcast pps พุ่ง ถ้าเกิน ~5-10% ของ traffic ทั้งหมดถือว่าน่าสงสัย แก้โดยเปิด storm-control broadcast level 1.00 ที่ access port แล้วเปิด STP + BPDU Guard ไว้ด้วย

สาเหตุที่ 2 — Duplex mismatch#

อาการคลาสสิกคือ ping ปกติ แต่ throughput เน่ามาก พอ copy ไฟล์ใหญ่ความเร็วตกฮวบ และ interface counter จะเห็น late collision กับ runts เพิ่มขึ้นเรื่อย ๆ

ต้นเหตุคือฝั่งหนึ่งตั้ง auto-negotiate แต่อีกฝั่ง hard-code full duplex ไว้ ฝั่ง auto เลย fallback ลงไป half duplex เอง

show interface GigabitEthernet0/1 | include duplex|collision|runts
ethtool eth0          # ฝั่ง Linux

วิธีแก้ที่ถูกคือ ตั้งให้ทั้งสองฝั่งเป็น auto-negotiate อย่าไป hard-code ทั้งคู่ เพราะ Gigabit ขึ้นไป auto-negotiate ถือเป็น mandatory ตาม IEEE 802.3 อยู่แล้ว

สาเหตุที่ 3 — Switch loop (ไม่มี STP)#

เคสคลาสสิกคือ user หา switch ตัวเล็กมาเสียบเอง แล้วเผลอเสียบสาย 2 หัวเข้า switch กลางพร้อมกัน เกิด loop layer-2 broadcast วิ่งวนจน link เต็ม

อาการคือ ทุก port ของ switch ตัวนั้นไฟกระพริบรัวพร้อมกัน CPU พุ่ง 90%+ และ MAC address table จะเห็น host ตัวเดียวกระโดดไปมาระหว่างหลาย port

show spanning-tree summary
show mac address-table count
debug spanning-tree events    # ใช้ระวัง CPU

วิธีแก้ระยะยาวคือเปิด STP/RSTP บน switch ทุกตัว แล้วเปิด BPDU Guard ที่ access port port ไหนรับ BPDU จาก switch แปลกปลอม (ที่ user แอบเอามาเสียบ) จะ shutdown ตัวเองทันที

สาเหตุที่ 4 — สาย/หัว RJ-45/CAT ไม่ได้คุณภาพ#

สายเก่า งอหัก โดนหนูแทะ หรือลาก CAT5 (ไม่ใช่ 5e) บน link Gigabit จะเจอ CRC error กับ retransmission แล้ว TCP จะลดความเร็วเองอัตโนมัติ

อาการคือ link up ที่ความเร็วต่ำกว่าที่ควรจะเป็น (เช่นได้แค่ 100 Mbps ทั้งที่อุปกรณ์รองรับ Gig) หรือ counter input errors และ CRC ค่อย ๆ ไต่ขึ้นเรื่อย ๆ

show interfaces GigabitEthernet0/5 | include error|CRC|input

วิธีตรวจหน้างาน หยิบ cable tester วัด wire map กับ length หรือไม่ก็เปลี่ยนสายใหม่แล้ว reset counter (clear counters) รอดู 5-10 นาทีว่า error กลับมาไหม

สาเหตุที่ 5 — MTU mismatch / Path MTU Discovery พัง#

เจอบ่อยในวงที่มี VPN, GRE tunnel หรือเซ็ต jumbo frame ไม่ครบทุก hop ผลคือ TCP handshake ผ่าน (ping เล็ก ๆ ก็ผ่าน) แต่พอส่ง payload ใหญ่ packet โดน drop เงียบ ๆ

อาการคลาสสิกคือเปิดเว็บได้บางเว็บ บางเว็บค้าง โดยเฉพาะเว็บที่มีรูปใหญ่ หรือ SSH ก็พิมพ์ได้ปกติ พอ scp กลับค้างกลางทาง

ping -M do -s 1472 8.8.8.8       # Linux, ทดสอบ MTU 1500
ping -f -l 1472 8.8.8.8          # Windows
tracepath 8.8.8.8                # หา MTU แต่ละ hop

ถ้า ping size 1472 (header 28) แล้วได้ fragment needed แปลว่า path MTU < 1500 ต้องไป clamp MSS ที่ router หรือ firewall (ip tcp adjust-mss 1360)

สาเหตุที่ 6 — Uplink oversubscribed#

Access switch 48 port Gigabit แต่ uplink ขึ้น core เหลือเส้นเดียว 1 Gbps ตอนคนน้อยไม่มีปัญหา พอ user เพิ่ม backup software วิ่งพร้อมกับ CCTV NVR ดูดข้อมูลขึ้น uplink เส้นเดียวเต็ม ทุกคนช้าพร้อมกัน

วิธี diagnose คือไปดู utilization ของ uplink port เทียบรายช่วงเวลา

show interfaces GigabitEthernet0/49 | include rate
show interfaces summary

ถ้า 5-minute input/output rate เกิน 70-80% ของ link speed ต่อเนื่อง คือ uplink ตัน ทางออกคือ upgrade เป็น 10G, bundle หลายเส้นด้วย LACP หรือทำ QoS กั้น traffic สำคัญไว้ก่อน

สาเหตุที่ 7 — Malware / DDoS ภายในวง#

เครื่อง user ติด worm หรือ crypto-miner ที่เที่ยว scan ทั้ง subnet หาเหยื่อ จะเปิด connection มหาศาลจน switch CPU พุ่ง firewall session table เต็ม อาการเหมือน network ช้าทั้งวง แต่จริง ๆ ต้นเหตุคือเครื่องเดียว

ตรวจจาก firewall log หรือ NetFlow ว่า host ไหนเปิด connection ผิดปกติ เช่นยิงไปหลายร้อย IP ปลายทางภายในนาทีเดียว

show ip cache flow                       # Cisco NetFlow
nload eth0                                # ดู realtime bandwidth
ss -s                                     # นับ socket รวม

วิธีแก้คือตัด port นั้นทันที แล้วยกเครื่องไปสแกน ถ้าสงสัยว่าเป็น incident อย่าเพิ่งรีบ reformat เก็บ evidence ไว้ก่อน

3. ลำดับการตรวจ: top-down vs bottom-up#

มี 2 แนวคิด เลือกตามอาการ

Top-down (เริ่มจาก application) — เหมาะเมื่อ user บอกว่าแอปเดียวช้า เริ่มจาก ping → traceroute → DNS lookup → ทดสอบ application protocol โดยตรง (เช่น curl -v, mtr)

Bottom-up (เริ่มจาก physical) — เหมาะเมื่อช้าทั้งวง เริ่มจากดูไฟ port, interface counter, duplex, error → ไล่ขึ้นไป STP → broadcast → uplink utilization → ถึงค่อยขึ้นไปดู L3 และ application

ส่วนตัวเวลาออกหน้างานจริง ถ้าปัญหากระทบทั้งสำนักงานผมชอบ bottom-up เพราะ root cause มักจะอยู่ที่ layer 1-2 ส่วนกรณีที่ user คนเดียวรายงาน ค่อยใช้ top-down

⚠️ ข้อควรระวัง

อย่ารีบ reboot switch ตอนสงสัย loop เพราะพอ reboot ปุ๊บ MAC address table, ARP table, STP topology จะหายหมด หลักฐานว่า port ไหนคือต้นทาง loop ก็หายไปด้วย ทำให้กลับมา loop อีกใน 30 วินาที โดยที่หาสาเหตุไม่เจอ ทางที่ถูกคือ shutdown port ที่สงสัยทีละตัว (binary search) แล้วดูว่า broadcast rate ลดเมื่อปิด port ไหน — ตัวนั้นคือผู้ต้องสงสัย

✓ Tip

เก็บ baseline ตอน network healthy ไว้เสมอ ทั้ง interface utilization, CPU ของ switch, จำนวน MAC ต่อ port, latency เฉลี่ย เก็บผ่าน SNMP หรือ tool monitor (LibreNMS, Zabbix, PRTG) เมื่อเกิดเหตุจะเทียบได้ทันทีว่าอะไรผิดปกติ ไม่ต้องมานั่งเดา และหลายครั้ง graph จะบอก root cause ก่อนที่ user จะโทรมาแจ้งด้วยซ้ำ

สรุป + checklist 7 ข้อ ก่อนยอมแพ้#

เวลา LAN ช้า ไล่ตามนี้ก่อนแจ้ง vendor

ping/throughput test — แยกว่าเป็น network หรือ application
interface error counter — CRC, runt, late collision = layer 1-2
duplex check — ทั้งสองฝั่งต้อง auto หรือ full ตรงกัน
STP + broadcast rate — มี loop หรือ broadcast พุ่งหรือเปล่า
uplink utilization — เส้นขึ้น core ตันไหม
MTU test — ping -M do หา PMTU
NetFlow / firewall log — มีเครื่องไหน traffic ผิดปกติ

ถ้าครบ 7 ข้อแล้วยังไม่เจอ ค่อยขยับไปดู L3 routing, QoS policy หรือเรียก vendor มาช่วย แต่จากที่เจอมา เคส LAN ช้ากว่า 90% จบที่ 7 ข้อนี้

LAN ช้า แก้ยังไง — 7 สาเหตุหลัก พร้อมวิธีตรวจ