Understanding ARP Flow in a Layer 2
Understanding ARP Flow in a Layer 2 (Data Link Layer)
Today, I revisited one of the most fundamental processes in networking — the ARP (Address Resolution Protocol) flow inside a Layer 2 environment. The diagram clearly illustrates how devices resolve MAC addresses to enable successful communication within the same subnet.
🔹 How the ARP Process Works
1. Device A needs to communicate with Device B but only knows its IP address.
2. To discover the MAC address, Device A sends an ARP Request (broadcast) across the Layer 2 switch.
3. Every device in the LAN receives the broadcast, but only the device with the matching IP — Device B — responds with an ARP Reply (unicast).
4. Device A updates its ARP cache with the newly learned MAC address.
5. With both IP and MAC now known, end-to-end communication is successfully established.
6. Meanwhile, the switch updates its MAC address table to efficiently forward future traffic.
🔹 Why This Matters
A solid understanding of ARP flow is essential for diagnosing and troubleshooting enterprise networks. It helps in identifying:
✔️ ARP-related connectivity issues
✔️ Incorrect or stale MAC table entries
✔️ Duplicate IP problems
✔️ Broadcast behavior inside Layer 2 domains
Mastering these basics forms the foundation for working with VLANs, switching, routing, and advanced network architectures.
ถ้าเพิ่งเริ่มอ่านเรื่อง ARP แล้วงงว่า “ARP คืออะไร” เอาแบบที่ผมใช้อธิบายกับตัวเองคือ ARP เป็นกลไกที่ช่วยแปลง IP Address (Layer 3) ให้เป็น MAC Address (Layer 2) เพื่อให้ส่งเฟรมกันได้ในเครือข่ายเดียวกัน (subnet เดียวกัน) เพราะในโลกของสวิตช์/อีเธอร์เน็ต การส่งจริง ๆ ต้องอาศัย MAC เป็นหลัก สิ่งที่ควรรู้เพิ่ม (ช่วยให้ตอบคำถาม arp layer / arp layer 2 ได้ชัดขึ้น) 1) ARP ทำงานในขอบเขต Layer 2 Domain - ARP Request จะเป็น broadcast ภายใน LAN/VLAN เดียวกันเท่านั้น (มันจะไม่ถูกส่งข้ามเราเตอร์ไปอีก subnet) - เพราะฉะนั้นถ้าปลายทางอยู่ “คนละ subnet” เครื่องเราไม่ได้ ARP หา MAC ของปลายทางจริง ๆ แต่จะ ARP หา MAC ของ Default Gateway แล้วส่งเฟรมไปให้เราเตอร์แทน 2) ARP Request/Reply หน้าตาโดยพฤติกรรม - ARP Request: broadcast ไปทุกเครื่องใน VLAN เดียวกัน เพื่อถามว่า “ใครเป็นเจ้าของ IP นี้?” - ARP Reply: unicast กลับมาที่คนถาม พร้อมบอก MAC ของตัวเอง - หลังจากนั้นเครื่องต้นทางจะเก็บคู่ IP↔MAC ไว้ใน ARP Cache เพื่อไม่ต้อง broadcast ซ้ำทุกครั้ง 3) ARP Cache คืออะไร และทำไมถึงเป็นต้นเหตุปัญหาได้ จากประสบการณ์เวลาแก้เน็ตในออฟฟิศ/แลบ ปัญหาที่เจอบ่อยคือ ARP Cache ค้างหรือผิด (stale entry) เช่น เคยเป็น IP เดิมแต่เครื่องเปลี่ยนการ์ด/เปลี่ยน VM แล้ว MAC เปลี่ยน ทำให้ส่งไปผิดเครื่องชั่วคราว วิธีเช็คที่ทำบ่อย: - Windows: ใช้คำสั่ง arp -a - Linux/macOS: ใช้ ip neigh หรือ arp -n ถ้าสงสัยว่า cache เพี้ยน ลองเคลียร์ (flush) แล้วทดสอบ ping ใหม่ จะเห็น ARP Flow เกิดขึ้นอีกรอบ 4) MAC Address Table ของสวิตช์เกี่ยวข้องยังไง หลายคนสับสนระหว่าง ARP Cache (อยู่ที่โฮสต์/เราเตอร์) กับ MAC Address Table/CAM Table (อยู่ที่สวิตช์) - ARP Cache: เก็บ “IP ↔ MAC” - MAC Table: เก็บ “MAC ↔ พอร์ตสวิตช์” เพื่อส่งเฟรมไปถูกพอร์ต เวลามี ARP Request แบบ broadcast สวิตช์จะ flood ออกทุกพอร์ตใน VLAN (ยกเว้นพอร์ตที่รับเข้า) แล้วสวิตช์ก็เรียนรู้ MAC ต้นทางไปพร้อมกัน 5) อาการยอดฮิตที่ผูกกับ ARP (เอาไว้ไล่เหตุเวลามีปัญหา) - IP ชนกัน (Duplicate IP): มักเห็น ARP ตอบกลับแปลก ๆ หรือสลับไปมาระหว่าง MAC สองตัว - Broadcast เยอะผิดปกติใน Layer 2: ARP Request ถี่ ๆ อาจบ่งชี้ว่าเครื่องหาเพื่อนบ้านไม่เจอ/ตารางถูกล้างบ่อย - สื่อสารกันไม่ได้เฉพาะบางเครื่องใน VLAN เดียว: เช็ค ARP Cache และ MAC Table ร่วมกัน (รวมถึง VLAN/port configuration) สรุปสั้น ๆ: ถ้าจำภาพรวมให้ได้ว่า “Device A ส่ง ARP Request (broadcast) ผ่าน Layer 2 switch → Device B ตอบ ARP Reply (unicast) → A อัปเดต ARP cache และสวิตช์อัปเดต MAC table” คุณจะไล่ปัญหาใน LAN/VLAN ได้เร็วขึ้นมาก โดยเฉพาะเคส ARP-related connectivity, MAC table ผิด, และ Duplicate IP
