บทที่ 17 · บทสุดท้ายที่ออกสอบ

Address Resolution Protocol (ARP)

รู้ IP แล้ว แต่ Data Link Layer ส่งไม่ได้ถ้าไม่รู้ MAC — ARP คือตัวถามหา MAC จาก IP ถามด้วย broadcast ตอบด้วย unicast แล้วจำใส่ ARP cache ไว้ ส่วน RARP ทำกลับทาง คือรู้ MAC แล้วหา IP

อ่าน ~15 นาที คุ้ม — ตอบสั้นได้คะแนน เชื่อมกับ ข้อสอบ Q3 · Lab 1, 2 หน้าหนังสือ 141–148
ข้อสอบออกแบบไหน
  • Q3 (ข้อคุ้มที่สุดในฉบับ) — «ให้ใช้โปรแกรม Wireshark ตรวจจับ packet ที่เกิดขึ้น ยกตัวอย่าง 1 packet และระบุประเภทของแอดเดรสที่ปรากฏใน packet ดังกล่าว อย่างน้อย 3 ประเภท ที่แต่ละ layer ให้ถูกต้อง» → ต้องตอบ MAC address (L2, Physical address) ให้ได้ ซึ่ง ARP คือกลไกที่ทำให้ได้ MAC นั้นมา
  • ข้อสอบแลป — Lab 1/2 ให้ Start Capture บนลิงก์แล้ว ping · Wireshark filter ที่ต้องพิมพ์เป็นคือ arp (หรือ eth.type == 0x0806 อย่างที่หนังสือใช้ในรูปที่ 17.4) และ Lab 2 ข้อ 14 สั่ง arp -a แล้ว «อธิบายสิ่งที่เกิดขึ้น»
  • คำถามคอนเซ็ปต์ — ARP อยู่เลเยอร์ไหน · ทำไม request ต้อง broadcast แต่ reply เป็น unicast · Target HA ของ request มีค่าเท่าไร

ทำไมต้องมี ARP — ปัญหาที่มันแก้

การสื่อสารใน Data Link layer โนดภาคส่งจำเป็นต้องทราบฮาร์ดแวร์แอดเดรสของโนดปลายทางเพื่อให้การสื่อสารสำเร็จ ในทำนองเดียวกัน หากโนดทราบเพียงฮาร์ดแวร์แอดเดรสของตน แต่ต้องการสื่อสารโดยอาศัย IP address โนดจะกำหนดแอดเดรสของตนเองได้อย่างไร

บทนี้จึงกล่าวถึงสองโพรโตคอลสำคัญใน Data Link Layer

ARP — Address Resolution Protocol

ทำให้โนดหรือโฮสต์ ทราบฮาร์ดแวร์แอดเดรสของเครื่องที่ต้องการติดต่อ เมื่อทราบ IP address ของโนดนั้น

RARP — Reverse ARP

ช่วยกำหนด IP address ให้แก่โฮสต์ ในกรณีที่ทราบฮาร์ดแวร์แอดเดรสของตนเอง

ARP อยู่เลเยอร์ไหน — ตอบตามหนังสือเล่มนี้

หนังสือเปิดบทนี้ด้วยประโยค «สองโพรโตคอลที่สำคัญใน Data Link Layer» และย้ำอีกครั้งในหัวข้อ RARP ว่า «การทำงานของ RARP ทำงานอยู่บน Data Link Layer ทำให้ไม่สามารถส่งข้ามเน็ตเวิร์กได้» — หลักฐานที่ชัดที่สุดคือ ARP ถูกส่งในแพ็กเก็ตของอีเทอร์เน็ตโดยตรง โดยกำหนดให้ Type = 0x0806 ไม่ได้ห่ออยู่ใน IP เหมือน ICMP หรือ UDP ดังนั้นถ้าโจทย์ถาม ให้ตอบว่า Data Link Layer (เลเยอร์ 2) และเสริมว่ามันคือตัวเชื่อมระหว่างเลเยอร์ 3 กับเลเยอร์ 2 (ทราบแอดเดรสของเลเยอร์ 2 จากแอดเดรสในเลเยอร์ 3)

17.1Address Resolution Protocol (ARP)

การสื่อสารโดยทั่วไป เรามักอ้างถึงชื่อของเซิร์ฟเวอร์ที่ต้องการติดต่อด้วย การใช้ DNS ทำให้ทราบ IP Address เพื่อการสื่อสาร อย่างไรก็ตามเรายังไม่สามารถสื่อสารโดย IP Address เท่านั้น การทราบถึงฮาร์ดแวร์แอดเดรสเป็นสิ่งที่เลี่ยงไม่ได้ในการสื่อสารของ Data Link Layer

ดังนั้น ARP เป็นโพรโตคอลเพื่อใช้ในการหาฮาร์ดแวร์แอดเดรส เมื่อทราบ IP address ของโนดนั้น ๆ หรือในภาพรวมก็คือ เราจะทราบแอดเดรสของเลเยอร์ 2 จากแอดเดรสในเลเยอร์ 3 ได้โดยการใช้ ARP

การทำงานของ ARP ประกอบด้วย สองเมสเสจหลัก

  1. ARP query — จะถูกส่งแบบบรอดคาสท์ออกไป เพื่อสอบถามแอดเดรสของโนดที่ต้องการ

  2. ARP response — เป็นเมสเสจที่ถูกส่งเพื่อตอบ ARP query โดยโนดที่ถูกสอบถามจะใช้แพ็กเก็ตแบบยูนิคาสต์ส่งไปหาต้นทางโดยตรง

จุดที่คนพลาดบ่อย — ทำไม request ต้อง broadcast แต่ reply เป็น unicast

ตอนถาม ต้นทางยังไม่รู้ว่าใครคือเจ้าของ IP นั้น จึงไม่มีทางระบุ MAC ปลายทางได้ ต้องตะโกนถามทั้งวง LAN → ใส่ Destination MAC ของเฟรมอีเทอร์เน็ตเป็น FF:FF:FF:FF:FF:FF (บรอดคาสท์)
ตอนตอบ เครื่องปลายทางรู้แล้วว่าใครถาม เพราะ ARP request แนบ Sender Hardware Address กับ Sender Protocol Address มาให้ครบ จึงตอบกลับตรง ๆ แบบยูนิคาสต์ได้ทันที — ถ้า reply เป็นบรอดคาสท์อีก จะรบกวนเครื่องที่ไม่เกี่ยวข้องทั้งวงโดยไม่จำเป็น

17.1.1รูปแบบ ARP Message

ARP ได้รับการกำหนดใน RFC 826 เพื่อให้มีการทำงานในลักษณะ autoconfiguration โดยที่ ARP จะถูกส่งในแพ็กเก็ตของอีเทอร์เน็ตโดยตรง กำหนดให้ Type = 0x0806

ภาพเคลื่อนไหวข้างบนกางเฟรมออกเป็นแถวยาวเพื่อให้เห็นลำดับก่อนหลังของฟิลด์ · ส่วนตำราวาดรูปที่ 17.1 เป็นบล็อกกว้าง 32 บิต ซึ่งเหมาะกับการดูว่าฟิลด์ไหนกินกี่ไบต์และวางซ้อนกันอย่างไร — ถ้าข้อสอบให้ “วาดรูปแบบ ARP message” ให้วาดตามผังนี้

บิต 0–7บิต 8–15บิต 16–23บิต 24–31
Hardware Type (2 ไบต์ · อีเทอร์เน็ต = 1) Protocol Type (2 ไบต์ · IPv4 = 0x0800)
Hardware Length (1 ไบต์ = 6) Protocol Length (1 ไบต์ = 4) Operation (2 ไบต์ · Request 1, Reply 2)
Sender Hardware Address (อีเทอร์เน็ต = 6 ไบต์)
Sender Protocol Address (IP = 4 ไบต์)
Target Hardware Address (อีเทอร์เน็ต = 6 ไบต์ · ใน request เป็น 0 หมด)
Target Protocol Address (IP = 4 ไบต์)
รูปที่ 17.1 จากตำรา — ARP Packet · ในตำราวาดเป็นผังฟิลด์ (ไม่ใช่ภาพถ่าย) จึงทำเป็นตารางแทนให้อ่านง่ายกว่า โดยคงตำแหน่งบิตเดิมไว้ทุกช่อง (ตำรากำกับเลขบิตไว้ที่ 0 · 7 · 15 · 31) · จุดที่ต้องสังเกต: สองแถวแรกกว้าง 32 บิตพอดี ส่วนสี่แถวล่างเป็นแอดเดรสที่ยืดหดตามค่า HLEN/PLEN จึงไม่ได้ยาว 32 บิตเสมอไป (อีเทอร์เน็ต+IPv4 ⇒ 6, 4, 6, 4 ไบต์ ⇒ ตัว ARP รวมเป็น 28 ไบต์)
ฟิลด์ขนาดหนังสือระบุว่าค่าตัวอย่าง
Hardware Type16 บิต แสดงถึงประเภทของฮาร์ดแวร์ที่ใช้ โดย LAN กำหนดเลขจำนวนเต็มให้แก่ฮาร์ดแวร์แต่ละประเภท เช่น อีเทอร์เน็ตกำหนด Type = 1 0x0001
Protocol Type16 บิต แสดงถึงโปรโตคอลที่ใช้ เช่น ใน IPv4 หมายเลขนี้จะเป็น 0x0800 การทำงาน ARP สามารถใช้กับโปรโตคอลอื่นได้ 0x0800
Hardware Length (HLEN)8 บิต แสดงถึงความยาวของแอดเดรสของฮาร์ดแวร์ หน่วยเป็นไบต์ เช่น ในอีเทอร์เน็ตเป็น 6 0x06
Protocol Length (PLEN)8 บิต แสดงถึงความยาวแอดเดรสของโปรโตคอล หน่วยเป็นไบต์ เช่น IPv4 มีค่าเป็น 4 0x04
Operation16 บิต แสดงถึงประเภทแพ็กเก็ตใน ARP กำหนดไว้สองประเภทคือ ARP request เป็น 1 และ ARP reply เป็น 2 0x0001 / 0x0002
Sender Hardware Addressปรับได้ (อีเทอร์เน็ต = 6 ไบต์) กำหนดค่าของฮาร์ดแวร์แอดเดรสด้านส่ง สามารถปรับเปลี่ยนความยาวได้ 0x345123A1B2C1
Sender Protocol Addressปรับได้ (IP = 4 ไบต์) กำหนดค่าของโปรโตคอลแอดเดรสด้านส่ง สามารถปรับเปลี่ยนความยาวได้ 223.93.168.10
Target Hardware Addressปรับได้ (อีเทอร์เน็ต = 6 ไบต์) กำหนดค่าของฮาร์ดแวร์แอดเดรสด้านรับ — ในกรณีของ ARP request ค่านี้จะเป็น 0 หมด เนื่องจากยังไม่ทราบแอดเดรสของด้านรับ request: 0x000000000000
Target Protocol Addressปรับได้ (IP = 4 ไบต์) กำหนดค่าของโปรโตคอลแอดเดรสด้านรับ สามารถปรับเปลี่ยนความยาวได้ 223.93.168.254

ค่าตัวอย่างมาจากรูปที่ 17.2 และ 17.3 ของหนังสือ (หน้า 143)

เคล็ดจำ 4 ฟิลด์แรกให้ครบ

«ฮาร์ดแวร์อะไร โปรโตคอลอะไร ยาวเท่าไร ทำอะไร» → Hardware Type · Protocol Type · (HLEN, PLEN) · Operation ตามด้วยแอดเดรส 4 ตัวที่เรียงเป็นคู่ ผู้ส่ง(MAC, IP) แล้วค่อย ผู้รับ(MAC, IP) — เรียงแบบนี้เสมอ ทั้งใน request และ reply

17.1.2การทำงานของ ARP

ในการส่ง ARP query เนื่องจากภาคส่งยังไม่ทราบ MAC address ของภาครับ ทำให้ใส่ค่าเป็นศูนย์ทั้งหมด เมื่อปลายทางได้รับเมสเสจดังกล่าว จะตอบกลับด้วย MAC address ของตน ซึ่งการสื่อสารต่อไปจะใช้ MAC address นี้เพื่อระบุถึงโนดดังกล่าว

จากการทำงานข้างต้น เมื่อโฮสต์ได้รับ ARP Response โฮสต์จะสร้างเอ็นทรี (entry) <IP address, MAC address> เพื่อจัดเก็บใน ARP cache

บรอดคาสท์ของ ARP query — เฟรมและค่าในแต่ละฟิลด์
รูปที่ 17.2 จากตำรา — บรอดคาสท์ของ ARP query (สังเกต Destination MAC ของเฟรมอีเทอร์เน็ตเป็น 0xFFFFFFFFFFFF และ Target Hardware Address ในตัว ARP เป็น 0x000000000000 ทั้งสองช่องถูกเน้นสีเทาไว้)
ยูนิคาสต์ของ ARP Response
รูปที่ 17.3 จากตำรา — ยูนิคาสต์ของ ARP Response (Operation เปลี่ยนเป็น 0x0002 และ Sender Hardware Address ถูกเติมด้วย MAC ของเครื่องที่ถูกถาม แล้วส่งกลับหาผู้ถามโดยตรง)

ตัวอย่าง 17.1 — ping แล้วดู ARP ทำงานจริง

สมมติให้เครื่องคอมพิวเตอร์ที่ IP Address 192.168.1.3 ต้องการ ping ไปยังเครื่อง 192.168.1.33 เบื้องต้นตรวจสอบ arp table ของเครื่อง 192.168.1.3 จะมีเพียง 192.168.1.1 เท่านั้น ซึ่งในที่นี้เป็น default gateway

ก่อน ping — ตารางมีแต่ default gateway 
C:\Users\chatchai>arp -a
Interface: 192.168.1.3 --- 0xc
  Internet Address       Physical Address        Type
  192.168.1.1            c8-d5-fe-00-f3-86       dynamic
ping ไปยังเครื่องที่ยังไม่รู้จัก 
C:\Users\chatchai>ping 192.168.1.33
Pinging 192.168.1.33 with 32 bytes of data:
Reply from 192.168.1.33: bytes=32 time=1ms TTL=128
Reply from 192.168.1.33: bytes=32 time<1ms TTL=128
Reply from 192.168.1.33: bytes=32 time<1ms TTL=128
Reply from 192.168.1.33: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.33:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

เมื่อ ping ไปยัง 192.168.1.33 และใช้โปรแกรม Wireshark ตรวจจับเฉพาะ arp จะเห็น arp request (หรือ arp query) จากเครื่อง 192.168.1.3 เป็นการส่งแบบบรอดคาสท์ เพื่อตรวจสอบหา MAC Address ของเครื่อง 192.168.1.33 โดยที่ Target MAC address เป็น 00:00:00:00:00:00 ก่อนที่จะได้ arp reply จาก 192.168.1.33 ซึ่งจะเห็นว่ามีการกำหนดค่าของ Sender MAC address ภายใน arp reply ซึ่งก็คือ MAC address ของเครื่อง 192.168.1.33

Wireshark แสดง ARP request แบบบรอดคาสท์
รูปที่ 17.4 จากตำรา — บรอดคาสท์ของ ARP request ใน Wireshark · filter ที่ใช้คือ eth.type == 0x0806 · แถวบนคือ request “Who has 192.168.1.33? Tell 192.168.1.3” ส่ง Broadcast · แถวล่างคือ reply “192.168.1.33 is at 00:24:1d:1c:3f:f9” ส่งกลับหา SamsungE_2c:03:1a โดยตรง

และนี่คือ arp reply ที่วิ่งกลับมา — เป็นยูนิคาสต์ส่งตรงถึงผู้ถาม ไม่ใช่บรอดคาสท์อีกต่อไป

หน้าต่าง Wireshark แสดงเฟรมที่ 5 เป็น ARP reply จาก Giga-Byt_1c:3f:f9 ไปยัง SamsungE_2c:03:1a ขนาด 60 ไบต์ กางรายละเอียด Address Resolution Protocol (reply) ให้เห็น Opcode: reply (2) และวงกลมสีแดงล้อมบรรทัด Sender MAC address: Giga-Byt_1c:3f:f9 (00:24:1d:1c:3f:f9)
รูปที่ 17.5 จากตำรา — ยูนิคาสต์ของ ARP reply · Opcode: reply (2) · วงกลมแดงในรูปคือบรรทัด Sender MAC address = 00:24:1d:1c:3f:f9 ซึ่งเป็น MAC ของเครื่อง 192.168.1.33 — คือคำตอบที่เราอุตส่าห์ถามหา · สังเกตบรรทัด Ethernet II: Dst ไม่ใช่ Broadcast แล้ว แต่เป็น SamsungE_2c:03:1a คือส่งกลับหาผู้ถามโดยตรง

วางสองรูปนี้ข้างกันแล้วอ่านทีละฟิลด์ — นี่คือสิ่งที่ควรตอบได้ทันทีถ้าข้อสอบเอาภาพ Wireshark มาให้ชี้

ฟิลด์ที่ Wireshark แสดงARP request (รูปที่ 17.4)ARP reply (รูปที่ 17.5)
ขนาดเฟรม42 bytes on wire (336 bits)60 bytes on wire (480 bits)
Ethernet II · SrcSamsungE_2c:03:1a (e8:11:32:2c:03:1a)Giga-Byt_1c:3f:f9 (00:24:1d:1c:3f:f9)
Ethernet II · DstBroadcast (ff:ff:ff:ff:ff:ff)SamsungE_2c:03:1a — ยูนิคาสต์
Hardware typeEthernet (1) — เหมือนกันทั้งคู่
Protocol typeIP (0x0800) — เหมือนกันทั้งคู่
Hardware size / Protocol size6 / 4 — เหมือนกันทั้งคู่
Opcoderequest (1)reply (2)
Sender MAC addresse8:11:32:2c:03:1a00:24:1d:1c:3f:f9 ← คำตอบอยู่ตรงนี้
Sender IP address192.168.1.3192.168.1.33
Target MAC address00:00:00:00:00:00 — ยังไม่รู้e8:11:32:2c:03:1a
Target IP address192.168.1.33192.168.1.3
บรรทัด Infowho has 192.168.1.33? Tell 192.168.1.3192.168.1.33 is at 00:24:1d:1c:3f:f9
สลับที่กันพอดี — เคล็ดจำที่ใช้ตอบได้ทุกข้อ

คู่ Sender กับ Target ใน reply คือการสลับที่ของ request แบบตรงไปตรงมา: ผู้ที่เคยเป็น Target (192.168.1.33) กลายเป็น Sender ของ reply แล้วเติม MAC ของตัวเองลงในช่องที่เคยเป็นศูนย์ · ส่วนผู้ถามเดิม (192.168.1.3) กลายเป็น Target · ฟิลด์ที่ไม่เปลี่ยนเลยคือ Hardware type, Protocol type, HLEN, PLEN — เปลี่ยนแค่ Opcode กับแอดเดรสสี่ช่อง

ไบต์จริงของ ARP request จากช่อง hex ในรูปที่ 17.4 — ลองไล่ดูทีละฟิลด์ 
0000  ff ff ff ff ff ff  <- Destination MAC = บรอดคาสท์ (6 ไบต์)
      e8 11 32 2c 03 1a  <- Source MAC ของผู้ถาม (6 ไบต์)
      08 06              <- EtherType = 0x0806 แปลว่าข้างในเป็น ARP
      00 01              <- Hardware Type = 1 (อีเทอร์เน็ต)
0010  08 00              <- Protocol Type = 0x0800 (IPv4)
      06 04              <- HLEN = 6 ไบต์ · PLEN = 4 ไบต์
      00 01              <- Operation = 1 (request)
      e8 11 32 2c 03 1a  <- Sender Hardware Address
      c0 a8 01 03        <- Sender Protocol Address = 192.168.1.3
0020  00 00 00 00 00 00  <- Target Hardware Address = ศูนย์หมด (ยังไม่รู้)
      c0 a8 01 21        <- Target Protocol Address = 192.168.1.33 (0x21 = 33)
ส่วนขยาย — ทำไม request 42 ไบต์ แต่ reply 60 ไบต์

นับตามฟิลด์: เฮดเดอร์อีเทอร์เน็ต 14 ไบต์ (dst 6 + src 6 + type 2) + ตัว ARP อีก 28 ไบต์ (2+2+1+1+2 + 6+4+6+4) = 42 ไบต์พอดี ตรงกับที่ Wireshark เขียนว่า 42 bytes on wire (336 bits) — ลองคูณดู 42 × 8 = 336 บิต ✓ · ส่วน reply ที่ขึ้นว่า 60 ไบต์ เพราะเฟรมอีเทอร์เน็ตมีขนาดต่ำสุดที่ต้องส่ง (ดู บทที่ 14) การ์ดฝั่งที่ตอบจึงเติม padding ให้ครบ — ตัวข้อมูล ARP ยังเป็น 28 ไบต์เท่าเดิม · รายละเอียดเรื่อง padding ไม่ได้อยู่ในบทที่ 17 ใส่ไว้กันงงตอนเห็นตัวเลขไม่เท่ากันในรูป

กับดักของ Q3 — อย่าหยิบแพ็กเก็ต ARP มาตอบ

Q3 สั่งให้ “ยกตัวอย่าง 1 packet แล้วระบุประเภทของแอดเดรสที่ปรากฏ อย่างน้อย 3 ประเภท ที่แต่ละ layer” — ถ้าหยิบแพ็กเก็ต ARP มาตอบจะได้แค่ 2 เลเยอร์ คือ MAC address (L2) กับ IP address (L3) เพราะ ARP ไม่ได้ห่ออยู่ใน IP และไม่มี transport layer ⇒ ไม่มีหมายเลขพอร์ตให้ชี้ · ทางที่ปลอดภัยคือหยิบแพ็กเก็ต TCP/HTTPS มาตอบ (จะได้ครบ MAC → IP → Port) แล้วใช้ ARP เป็นคำอธิบายเสริมว่า MAC ปลายทางในเฟรมนั้นได้มาจากไหน — พูดได้ทันทีว่ามาจาก ARP reply ที่เห็นในรูปที่ 17.5 นี่แหละ · ถ้าปลายทางอยู่คนละซับเน็ต MAC ตัวนั้นก็คือของเร้าเตอร์/default gateway ตามที่เฉลย Q3 เขียนไว้

เมื่อสิ้นสุด ping ตรวจสอบค่า arp ของเครื่อง 192.168.1.3 อีกครั้ง จะพบว่าปรากฏ MAC address ของเครื่อง 192.168.1.33 บันทึกไว้ใน arp table เรียบร้อย

หลัง ping — มีเอ็นทรีใหม่เพิ่มเข้ามา 
C:\Users\chatchai>arp -a
Interface: 192.168.1.3 --- 0xc
  Internet Address       Physical Address        Type
  192.168.1.1            c8-d5-fe-00-f3-86       dynamic
  192.168.1.33           00-24-1d-1c-3f-f9       dynamic   <-- ARP เพิ่งเรียนรู้มา
เชื่อมกับ Lab
  • Lab 2 ข้อ 14 — «เลือก PC ตัวใดตัวหนึ่งและใช้คำสั่ง arp -a พร้อมทั้งอธิบายสิ่งที่เกิดขึ้น» → คำตอบคือสิ่งที่เห็นข้างบนเป๊ะ ๆ: ตารางจะมีเอ็นทรี <IP, MAC> ของเครื่องที่เพิ่ง ping ไป เพราะโฮสต์สร้าง entry เก็บใน ARP cache หลังได้รับ ARP Response · ถ้าอยู่คนละซับเน็ต จะเห็น MAC ของเร้าเตอร์แทน ไม่ใช่ของปลายทาง
  • Lab 1 / Lab 2 — «คลิกขวาที่ link ใดก็ได้ เลือก Start Capture เพื่อเปิด Wireshark แล้ว ping อีกครั้ง» → พิมพ์ arp ในช่อง filter (หรือ eth.type == 0x0806) จะเห็นสองแถวเสมอ: request → Broadcast ตามด้วย reply → unicast
  • บนอุปกรณ์ Cisco (สวิตช์/เร้าเตอร์) คำสั่งเทียบเท่าคือ show arp หรือ show ip arp · บน macOS/Linux ใช้ arp -a ได้เหมือนกัน
ส่วนขยาย — ทำไมต้องมี ARP cache

ถ้าไม่เก็บผลลัพธ์ไว้ ทุกแพ็กเก็ตที่จะส่งออกก็ต้องบรอดคาสท์ถามใหม่ ซึ่งจะทำให้ทั้งวง LAN เต็มไปด้วย ARP request หนังสือจึงระบุว่าเมื่อได้รับ ARP Response โฮสต์จะสร้างเอ็นทรี <IP address, MAC address> เก็บใน ARP cache คำว่า dynamic ในผลลัพธ์ของ arp -a หมายถึงเอ็นทรีที่ได้มาจาก ARP อัตโนมัติ (ต่างจาก static ที่ผู้ดูแลตั้งเอง) — รายละเอียดเรื่องอายุของเอ็นทรีไม่ได้อยู่ในหนังสือบทนี้

ARP เมื่อวิ่งผ่านสวิตช์ — flood ตอนถาม แต่ไม่ flood ตอนตอบ

รูปที่ 17.6 และ 17.7 ในตำราเป็นคู่กัน เล่าเหตุการณ์เดียวกันแต่คนละครึ่ง โดยเอา ARP ไปวางบนสวิตช์จริงที่มี MAC Address Table (ตารางเดียวกับที่เรียนใน บทที่ 13) · ฉากคือ VLAN 101 มีเครื่องสามตัวที่พอร์ต e0/11, e0/12, e0/13 และมีเร้าเตอร์อยู่ที่ e0/14

  1. ตอนเริ่ม MAC Address Table ว่าง (ในรูปเขียนว่า empty) — เครื่องที่ e0/11 (MAC 0101.0101.0101) ส่ง ARP ถามว่า “Who has IP address 10.1.1.3?”

  2. สวิตช์เรียนรู้ก่อนส่ง — พอเฟรมเข้ามา สวิตช์จดทันทีว่า 0101.0101.0101 → Ethernet 0/11 (ในรูปชี้ลูกศรกำกับว่า Learned MAC Address)

  3. ปลายทางเป็นบรอดคาสท์ ⇒ ตารางช่วยอะไรไม่ได้ ต้อง flood — สวิตช์ส่งเฟรม ARP ออกทุกพอร์ตที่เหลือ (e0/12, e0/13, e0/14)

  4. ทุกเครื่องเปิดอ่าน Target Protocol Address — ไม่ใช่ IP ตัวเองก็ทิ้ง (ในรูปพูดว่า “Not Me…” ทั้งเครื่อง 0202.0202.0202 และเร้าเตอร์) เหลือเครื่องเดียวที่ตอบว่า “I do! I will reply that my MAC address is 0303.0303.0303”

สวิตช์ VLAN 101 สองภาพต่อเนื่องกัน: ภาพแรก MAC Address Table ว่าง เครื่องที่พอร์ต e0/11 ส่งเฟรม ARP ถามว่า Who has IP address 10.1.1.3 ภาพที่สองสวิตช์จดค่า 0101.0101.0101 คู่กับ Ethernet 0/11 แล้ว flood เฟรม ARP ออกพอร์ต e0/12 e0/13 และ e0/14 โดยเครื่อง 0202 กับเร้าเตอร์ตอบว่า Not Me ส่วนเครื่อง 0303 ตอบว่า I do
รูปที่ 17.6 จากตำรา — ARP Request · สวิตช์เรียนรู้ MAC ต้นทางใส่ MAC Address Table (จาก empty เป็น 0101.0101.0101 / Ethernet 0/11) แล้ว flood ARP ออกทุกพอร์ตที่เหลือ · ทุกเครื่องที่ไม่ใช่เจ้าของ IP เงียบ (ในรูปวาดความคิดไว้ว่า “Not Me…” — ไม่ได้ส่งแพ็กเก็ตอะไรกลับจริง) ยกเว้นเครื่องที่เป็นเจ้าของ IP 10.1.1.3 ซึ่งตอบว่า “I do! I will reply that my MAC address is 0303.0303.0303”

ครึ่งหลังคือรูปที่ 17.7 — ขากลับต่างจากขาไปคนละเรื่อง เพราะคราวนี้สวิตช์ รู้จักปลายทางแล้ว

  1. เครื่อง 0303.0303.0303 ที่ e0/13 ตอบกลับว่า “I am 10.1.1.3. Here is my MAC address.” ส่งแบบ Unicast (ในรูปเขียนกำกับข้างกล่องเฟรมเลย)

  2. สวิตช์เรียนรู้เพิ่มอีกหนึ่งแถว — ตารางกลายเป็น 0101.0101.0101 → Ethernet 0/11 และ 0303.0303.0303 → Ethernet 0/13

  3. พอจะส่งต่อ สวิตช์เปิดตารางแล้วเจอปลายทางพอดี จึงบอกว่า “I do know this destination! I will not flood this frame.” ⇒ ส่งออกเฉพาะพอร์ต e0/11 พอร์ตเดียว เครื่องอื่นไม่ถูกรบกวนเลย

สวิตช์ VLAN 101 สองภาพต่อเนื่อง: ภาพแรกเครื่องที่พอร์ต e0/13 ส่งเฟรมยูนิคาสต์ตอบว่า I am 10.1.1.3 Here is my MAC address และ MAC Address Table เพิ่มแถว 0303.0303.0303 คู่กับ Ethernet 0/13 ภาพที่สองสวิตช์บอกว่า I do know this destination I will not flood this frame แล้วส่งเฟรมออกเฉพาะพอร์ต e0/11
รูปที่ 17.7 จากตำรา — ARP Response · เครื่อง 0303.0303.0303 ตอบแบบ Unicast ว่า “I am 10.1.1.3. Here is my MAC address.” · สวิตช์เรียนรู้แถวที่สอง (0303.0303.0303 → Ethernet 0/13) และเพราะปลายทาง 0101.0101.0101 มีอยู่ในตารางแล้ว จึงประกาศว่า “I do know this destination! I will not flood this frame.” ⇒ ส่งออกพอร์ต e0/11 พอร์ตเดียว ไม่ flood
จุดที่คนพลาดบ่อย — “flood” กับ “broadcast” ไม่ใช่คำเดียวกัน
  • Broadcast คือเจตนาของผู้ส่ง — ใส่ปลายทางเป็น FF:FF:FF:FF:FF:FF มาเองตั้งแต่ต้นทาง (ARP request เป็นแบบนี้)
  • Flood คือพฤติกรรมของสวิตช์เมื่อไม่มีข้อมูลในตาราง — ส่งออกทุกพอร์ตยกเว้นพอร์ตที่รับเข้ามา · เกิดกับทั้งเฟรมบรอดคาสท์ และ เฟรมยูนิคาสต์ที่ปลายทางยังไม่อยู่ในตาราง (unknown unicast)
  • ในรูปที่ 17.7 เฟรมเป็นยูนิคาสต์ และตารางมีข้อมูลแล้ว ⇒ ไม่ flood · ถ้าตารางยังว่างอยู่ สวิตช์ก็จะ flood เฟรมยูนิคาสต์ตัวนี้เหมือนกัน — ต่างกันแค่ “ตารางมีข้อมูลหรือยัง”
  • คำถามที่ชอบออก: “สวิตช์เรียนรู้ MAC จากฟิลด์ไหน” → จาก MAC ต้นทาง (Source) ของเฟรมที่วิ่งเข้ามา ไม่ใช่ปลายทาง · นี่คือเหตุผลที่ ARP request หนึ่งใบทำให้สวิตช์รู้จักผู้ถามทันที ทั้งที่ยังไม่มีใครตอบเลยสักคน

กรณีปลายทางอยู่คนละซับเน็ต — ARP หา MAC ของ default gateway

ส่วนขยาย (นอกเนื้อหาบทที่ 17)

หนังสือบทนี้อธิบายเฉพาะกรณีที่ต้นทางกับปลายทางอยู่ในวง LAN เดียวกัน แต่บอกใบ้ไว้แล้วในตัวอย่าง 17.1 ว่าเอ็นทรีแรกในตาราง (192.168.1.1) คือ default gateway หัวข้อนี้ขยายจากตรงนั้น เพราะเป็นจุดที่คนพลาดบ่อยที่สุดเวลาสอบและเวลาทำแลป

จุดที่คนพลาดบ่อย — ARP ข้ามซับเน็ตไม่ได้
  • ARP เป็นโพรโตคอลของ Data Link Layer และถามด้วยบรอดคาสท์ ซึ่งเร้าเตอร์ไม่ส่งต่อบรอดคาสท์ข้ามซับเน็ต ดังนั้นถ้าปลายทางอยู่คนละซับเน็ต การถามหา MAC ของปลายทางตรง ๆ จะไม่มีวันได้คำตอบ
  • สิ่งที่เกิดขึ้นจริงคือ ต้นทางเอา IP ปลายทาง AND กับ subnet mask ของตัวเอง แล้วพบว่าไม่อยู่ในเน็ตเวิร์กเดียวกัน → จึงส่งไปที่ default gateway และ ARP ถามหา MAC ของ gateway แทน
  • ผลคือในเฟรมที่ออกจากต้นทาง Destination MAC = MAC ของเร้าเตอร์ แต่ Destination IP = IP ของปลายทางจริง — สองอย่างนี้ชี้คนละที่ และนี่ไม่ใช่ความผิดพลาด
  • ทุก hop MAC ต้นทาง/ปลายทางเปลี่ยนใหม่หมด แต่ IP ต้นทาง/ปลายทางคงเดิมตลอดทาง (จำประโยคนี้ไปตอบข้อสอบ Q3 ได้เลย)
  • เวลาสั่ง arp -a บนเครื่องที่เพิ่ง ping ข้ามเน็ตเวิร์กไป คุณจะไม่เห็น MAC ของปลายทาง เห็นแต่ของ gateway — ไม่ได้แปลว่าแลปพัง

กรณีที่ ARP “ไม่สำเร็จ” — ถามแล้วไม่มีใครตอบ

ส่วนขยาย (ตำราเล่าเฉพาะตอนที่สำเร็จ)

ตัวอย่าง 17.1 ในตำราจบสวย: ping ผ่านครบ 4 แพ็กเก็ต Lost = 0 (0% loss) แล้ว arp -a ก็ได้เอ็นทรีใหม่ · แต่ข้อสอบกับแลปชอบถามฝั่งที่ล้มเหลว หัวข้อนี้จึงไล่ให้ครบว่า ถ้า ARP ไม่ได้คำตอบ จะเห็นอาการอะไรบ้าง — ตรรกะทุกข้อยังอิงจากกฎในตำราทั้งหมด คือ “ถามด้วยบรอดคาสท์ · ตอบด้วยยูนิคาสต์ · ได้ตอบแล้วค่อยสร้างเอ็นทรีใน ARP cache”

สถานการณ์ARP ทำอะไรผลที่เห็นหน้าจอ
ไม่มีเครื่องไหนเป็นเจ้าของ IP นั้น (พิมพ์ IP ผิด / เครื่องปิดอยู่) บรอดคาสท์ถามออกไป ทุกเครื่องอ่าน Target Protocol Address แล้วไม่ตรงสักเครื่อง จึงทิ้งทั้งหมด ⇒ ไม่มี ARP response กลับมา ไม่มีเอ็นทรีใหม่ใน arp -a · ping ขึ้น Request timed out หรือ Destination host unreachable
ปลายทางอยู่คนละซับเน็ต ไม่ได้ถามหา MAC ของปลายทาง — เพราะบรอดคาสท์ข้ามเร้าเตอร์ไม่ได้ · เปลี่ยนไปถามหา MAC ของ default gateway แทน ping ผ่านได้ตามปกติ แต่ arp -a เห็นแต่ MAC ของเร้าเตอร์ ไม่เห็นของปลายทาง (นี่ไม่ใช่ความผิดพลาด)
ไม่ได้ตั้ง default gateway หรือตั้งผิดวง เครื่องหา “ประตูออก” ไม่เจอ · ถ้าตั้งเป็น IP ที่ไม่มีอยู่จริง ARP จะถามหา MAC ของ gateway แล้วไม่มีใครตอบ ping ข้ามเน็ตเวิร์กไม่ออกเลย ทั้งที่ ping เครื่องในวงเดียวกันได้ปกติ — อาการคลาสสิกของแลป
ปลายทางอยู่คนละ VLAN (ต่อเนื่องจาก บทที่ 16) ARP request ถูก flood เฉพาะภายใน VLAN ของตัวเอง ⇒ เครื่องต่าง VLAN ไม่มีวันได้ยินคำถาม ping ข้าม VLAN ไม่ผ่าน จนกว่าจะมีเร้าเตอร์มาเชื่อม — แล้วมันก็กลับไปเป็นเคส “ถาม gateway” ข้างบน
จุดที่คนพลาดบ่อย — ARP ไม่มี “ข้อความตอบว่าไม่มี”

ARP มี Operation อยู่แค่ request (1) กับ reply (2) เท่านั้น ไม่มีเมสเสจชนิด “ไม่พบ” — เครื่องที่ไม่ใช่เจ้าของ IP จะเงียบ ไม่ตอบอะไรกลับมาเลย (ในรูปที่ 17.6 คำว่า “Not Me…” คือความคิดในหัวของเครื่องนั้น ไม่ใช่แพ็กเก็ตที่ส่งจริง) · ดังนั้นความล้มเหลวของ ARP จึงแสดงออกมาเป็นความเงียบ + การหมดเวลา ไม่ใช่ error message ⇒ ถ้าข้อสอบถามว่า “ถ้าไม่มีเครื่องไหนเป็นเจ้าของ IP นั้นจะเกิดอะไรขึ้น” คำตอบคือ ไม่มี reply · ไม่เกิดเอ็นทรีใน ARP cache · เฟรมที่รออยู่ถูกทิ้ง

17.2Reverse Address Resolution Protocol (RARP)

การทำงานของ RARP จะตรงข้ามกับการทำงานของ ARP ซึ่งสังเกตได้จากชื่อที่ตั้งขึ้น โดยเป็นการจับคู่จากฮาร์ดแวร์แอดเดรสที่ทราบ เพื่อให้ได้ IP Address

การพัฒนาของ RARP เกิดจากความต้องการสื่อสารโดยการใช้ IP Address ของสเตชันที่ไม่มีอุปกรณ์สำรองข้อมูล (diskless workstation) ทำให้หากสเตชันต้องการสื่อสารโดยใช้ IP Address สามารถทำได้โดยการบรอดคาสท์ฮาร์ดแวร์แอดเดรสของตน เพื่อร้องขอ (request) IP Address

รูปแบบเมสเสจ

รูปแบบของเมสเสจของ RARP เหมือนกับ ARP ทุกประการ แต่ฟิลด์ Operation ของ RARP จะมีค่าเป็น 3 หากเป็น RARP request และเป็น 4 หากเป็น RARP reply

Operationเมสเสจโพรโตคอล
1ARP requestARP — รู้ IP หา MAC
2ARP reply
3RARP requestRARP — รู้ MAC หา IP
4RARP reply

ข้อจำกัดของ RARP (และเหตุผลที่มันถูกแทนที่)

ส่งข้ามเน็ตเวิร์กไม่ได้

เนื่องจากการทำงานของ RARP ทำงานอยู่บน Data Link Layer ทำให้ไม่สามารถส่งข้ามเน็ตเวิร์กได้ ดังนั้นหากในระบบหนึ่งประกอบไปด้วยหลายเน็ตเวิร์กหรือหลายซับเน็ต จะทำให้ต้องมี RARP server จำนวนมาก เพื่อรองรับการร้องขอ IP address

ไม่ใช่ autoconfiguration

การทำงานของ RARP ไม่จัดว่าเป็นแบบ autoconfiguration เนื่องจากจะต้องมีผู้ดูแลระบบจับคู่ระหว่างฮาร์ดแวร์แอดเดรสกับ IP address ทำให้ไม่สะดวกเท่าใดนัก จึงมีการพัฒนา DHCP เพื่อรองรับการกำหนด IP address

ข้อสังเกตที่ควรเก็บ

ARP ถูกออกแบบมาให้เป็น autoconfiguration (หนังสือระบุไว้ในหัวข้อ 17.1.1) เพราะไม่มีใครต้องมานั่งกรอกตารางให้ ระบบถาม-ตอบกันเองได้ ในทางกลับกัน RARP ไม่ใช่ เพราะต้องมีคนไปจับคู่ MAC↔IP ไว้ที่เซิร์ฟเวอร์ก่อน — ความต่างข้อนี้แหละที่ทำให้ RARP ตายและ BOOTP/DHCP มาแทน (หนังสือระบุเฉพาะ DHCP; BOOTP เป็นความรู้เสริม)

17.3สรุป

อ่านบทสรุปของหนังสือให้ระวัง

หัวข้อ 17.3 “สรุป” ในหนังสือไม่ได้สรุปเรื่อง ARP แต่เป็นบทสรุปที่กวาดเนื้อหาบทที่ 13–16 มารวมกัน (การใช้งานช่องสัญญาณ, STP, VLAN) เช่นเดียวกับคำถามท้ายบทในหัวข้อ 17.4 ข้างล่าง ดังนั้นถ้าอ่านแล้วงงว่าทำไมพูดถึง ALOHA กับ VLAN ในบท ARP — ไม่ได้อ่านผิด ให้ยกเนื้อหาส่วนนี้ไปทบทวนคู่กับบทที่ 13–16

บทสรุปตามที่หนังสือเขียนไว้

แม้ว่าปัจจุบันการพัฒนาของอุปกรณ์เน็ตเวิร์ก ไม่ว่าจะเป็นสวิตช์ เร้าเตอร์ รวมถึงช่องสัญญาณ จะทำให้ระบบมีแบนด์วิดท์ที่สูงขึ้น แต่อุปกรณ์ยังคงมีความจำเป็นต้องใช้อุปกรณ์ร่วมกัน จึงมีความจำเป็นที่จะต้องมีระบบควบคุมที่ดี เพื่อให้การใช้งานของเน็ตเวิร์กเป็นไปอย่างมีประสิทธิภาพ

ในบทนี้ได้นำเสนอวิธีการต่าง ๆ ที่ได้พัฒนาขึ้น สามารถแบ่งออกเป็นสองประเภทได้แก่ Deterministic Access Method เช่น FDMA, TDMA และการเข้าใช้ช่องสัญญาณแบบสุ่ม เช่น Pure ALOHA, CSMA รวมถึง CSMA/CD

นอกจากนี้ยังได้กล่าวถึงการทำงานของโพรโตคอลต่าง ๆ ที่เกี่ยวข้อง เพื่อใช้ในการแก้ปัญหาและปรับปรุงการทำงานที่อาจเกิดขึ้นในระบบ เช่น Spanning Tree Protocol (STP) เพื่อช่วยแก้ปัญหาการเกิดลูปเนื่องจากความผิดพลาดของการติดตั้งระบบ และ VLAN เพื่อขยายการเชื่อมผู้ใช้ที่อยู่ต่างสถานที่กันเสมือนทำงานร่วมกัน และยังช่วยในการแบ่งลดทราฟฟิกบน LAN ลง

สรุปเรื่อง ARP/RARP (ของบทนี้จริง ๆ)

  • ARP = หาฮาร์ดแวร์แอดเดรส (เลเยอร์ 2) เมื่อทราบ IP address (เลเยอร์ 3) ทำงานใน Data Link Layer ห่อในเฟรมอีเทอร์เน็ตโดยตรงด้วย Type = 0x0806 · RFC 826 · เป็น autoconfiguration
  • สองเมสเสจ — ARP query ส่งบรอดคาสท์ (Target HA = 0 ทั้งหมด) · ARP response ส่งยูนิคาสต์กลับหาต้นทางโดยตรง
  • ARP cache — ได้ response แล้วเก็บเอ็นทรี <IP address, MAC address> ไว้ ตรวจได้ด้วย arp -a
  • RARP = ตรงข้ามกับ ARP · รู้ MAC หา IP · เกิดมาเพื่อ diskless workstation · Operation = 3/4 · รูปแบบเมสเสจเหมือน ARP
  • ข้อจำกัด RARP — อยู่บน Data Link Layer จึงข้ามเน็ตเวิร์กไม่ได้ (ต้องมีเซิร์ฟเวอร์ทุกซับเน็ต) และไม่ใช่ autoconfiguration (ผู้ดูแลต้องจับคู่เอง) → DHCP มาแทน

17.4คำถามท้ายบท พร้อมเฉลย

คำถามชุดนี้ในหนังสือครอบคลุมเนื้อหาบทที่ 13–16 (การใช้งานช่องสัญญาณ · อีเทอร์เน็ต · STP · VLAN) เฉลยด้านล่างอ้างอิงจากบทเหล่านั้นทั้งหมด

ข้อ 1. จงบอกข้อดี/ข้อเสียของ FDMA เมื่อเทียบกับ TDMA
FDMA — แบ่งช่องความถี่TDMA — แบ่งช่วงเวลา (สล็อต)
ข้อดี
  • ไม่จำเป็นต้องมีอุปกรณ์เพื่อใช้เป็นส่วนควบคุมกลาง (coordinator)
  • รองรับการทำงานในระบบแอนะล็อกได้
  • พัฒนาค่อนข้างง่าย ผู้ใช้ใช้เพียง bandpass filter เพื่อแยกสัญญาณที่ต้องการ
  • ปรับค่าบิตเรทได้ โดยใช้หลายสล็อตพร้อมกันเพื่อให้ส่งเร็วขึ้น
  • ใช้แบนด์วิดท์ได้อย่างมีประสิทธิภาพ เพราะไม่จำเป็นต้องมี Guard band
ข้อเสีย
  • ใช้ช่องสัญญาณอย่างไม่มีประสิทธิภาพ — ถ้าช่องไหนไม่มีการใช้งาน ช่องนั้นถูกทิ้งไป ไม่ได้นำมาเพิ่มความจุของระบบ
  • ต้องมี Guard band (กันครอสทอล์ก) ทำให้สูญเสียแบนด์วิดท์บางส่วน
  • ต้องทำซิงโครไนเซชันเพื่อป้องกันการชนของสัญญาณ
ข้อ 2. จงอธิบายการทำงานของ Random Access Method พร้อมทั้งบอกข้อดีและข้อเสีย

การทำงาน — ผู้ใช้ร้องขอช่องสัญญาณเมื่อมีข้อมูลที่ต้องการส่ง ไม่จำเป็นต้องมีการจองการใช้ล่วงหน้า (ตรงข้ามกับ Deterministic Access ที่ต้องจองไว้ก่อน เช่น FDMA/TDMA)

ข้อดี

  • ส่งข้อความขนาดเล็กได้มีประสิทธิภาพมากขึ้น เพราะไม่ต้องเสียเวลาจองช่องสัญญาณก่อน
  • ไม่ต้องจองล่วงหน้า → ช่องสัญญาณที่ว่างไม่ถูกทิ้งเปล่าเหมือน FDMA

ข้อเสีย

  • เกิดปัญหาการชนกันของการใช้ช่องสัญญาณ เมื่อมีเครื่องเข้าใช้ ณ เวลาพร้อมกันมากกว่าหนึ่งเครื่อง
  • เมื่อชนแล้วต้องส่งข้อมูลใหม่อีกครั้ง → เมื่อโหลดสูง ทรูพุตจะตกลง

ตัวอย่างวิธีการที่นิยมใช้: Pure ALOHA, Slotted ALOHA, CSMA, CSMA/CD

ข้อ 3. เหตุใดการทำงานของ Slotted ALOHA จึงสามารถเพิ่มประสิทธิภาพของ Pure ALOHA ได้

Slotted ALOHA แบ่งเวลาการส่งออกเป็นสล็อตเท่า ๆ กัน และบังคับให้ผู้ใช้ทุกคนเริ่มส่งได้เฉพาะที่จุดเริ่มต้นของสล็อตเท่านั้น ถ้ามีแพ็กเก็ตพร้อมส่งกลางสล็อต จะต้องรอไปส่งในสล็อตถัดไป

ผลคือ ช่วงเวลาที่แพ็กเก็ตจะชนกัน (vulnerable period) ลดลงครึ่งหนึ่ง เมื่อเทียบกับ Pure ALOHA เพราะใน Pure ALOHA แพ็กเก็ตจะชนได้ทั้งกรณีที่คนอื่นเริ่มส่ง “ก่อนหน้า” หนึ่งช่วงเวลาเฟรม และ “ระหว่าง” ที่เรากำลังส่ง แต่ Slotted ALOHA เหลือเพียงกรณีเดียวคือเริ่มพร้อมกันในสล็อตเดียวกัน

Pure ALOHA (สมการ 13.4)S = G e−2Gสูงสุด S = 1/2e = 0.184 (18.4%) ที่ G = 0.5
Slotted ALOHA (สมการ 13.5)S = G e−Gสูงสุด S = 1/e ≈ 0.368 (36.8%) ที่ G = 1

คือ เป็นสองเท่าของ Pure ALOHA พอดี ราคาที่จ่ายคือทุกสเตชันต้องซิงโครไนซ์นาฬิกาให้ตรงกันเพื่อรู้ว่าสล็อตเริ่มเมื่อไร

ข้อ 4. จงอธิบายพื้นฐานการทำงานของ ALOHA, Slotted ALOHA, CSMA และ CSMA/CD และเปรียบเทียบประสิทธิภาพของแต่ละ protocol
Protocolพื้นฐานการทำงานทรูพุต
Pure ALOHA ส่งได้ทันทีที่มีข้อมูล ไม่ตรวจสอบอะไรเลย จากนั้นรอ Round-trip delay เพื่อรอ ACK ถ้าไม่ได้ ACK ถือว่าแพ็กเก็ตเสียหายจากการชน แล้วสุ่มเวลาส่งใหม่ S = Ge−2G
สูงสุด 18.4%
Slotted ALOHA เหมือน Pure ALOHA แต่แบ่งเวลาเป็นสล็อต และเริ่มส่งได้เฉพาะต้นสล็อต → ช่วงชนลดครึ่งหนึ่ง S = Ge−G
สูงสุด 36.8%
CSMA ตรวจสอบ (Sense) ว่าช่องสัญญาณมีการใช้งานอยู่ (busy) หรือไม่ ก่อนที่จะส่ง ทำให้ลดปัญหาการชนกันของเฟรม มี 3 แบบคือ nonpersistent, p-persistent, 1-persistent สูงกว่า ALOHA มาก แต่ยังชนได้ (ดูข้อ 11)
CSMA/CD ต่อยอดจาก CSMA โดยเพิ่มการตรวจจับการชน (Collision Detection) → พบชนแล้วหยุดส่งส่วนที่เหลือทันที ส่ง jamming signal แจ้งทุกสเตชัน แล้วส่งซ้ำโดยใช้ Exponential Backoff สูงที่สุดในสี่แบบ — ตำราระบุว่าการเพิ่ม collision detection ทำให้ทรูพุตของระบบสูงขึ้น (รูปที่ 13.13)

ลำดับประสิทธิภาพ: CSMA/CD > CSMA > Slotted ALOHA (36.8%) > Pure ALOHA (18.4%)

กราฟ Throughput S เทียบกับ Offered traffic load G ในสเกลลอการิทึม กำหนด a เท่ากับ 0.01 และ b เท่ากับ a มีเส้นโค้งห้าเส้น Pure ALOHA ต่ำสุด ตามด้วย Slotted ALOHA, 1-persistent CSMA, Nonpersistent CSMA และ Nonpersistent CSMA/CD ที่สูงที่สุด
รูปที่ 13.13 จากตำรา — เทียบทรูพุต S กับโหลด G ของแต่ละโพรโตคอล (a = 0.01, b = a) · เรียงจากล่างขึ้นบน: Pure ALOHA (ยอดต่ำสุด ราว 0.18 ที่ G ≈ 0.5) → Slotted ALOHA (ราว 0.37 ที่ G = 1) → 1-persistent CSMA (ราว 0.5) → Nonpersistent CSMA (ราว 0.8) → Nonpersistent CSMA/CD สูงที่สุด · จุดที่ต้องสังเกต: ยอดของ ALOHA อยู่แถว G = 1 แล้วดิ่งลงเร็วมาก ส่วนกลุ่ม CSMA ทนโหลดได้ถึง G เป็นสิบเป็นร้อย
ข้อ 5. การทำงานของ CSMA สามารถลดการชนกันของข้อมูลได้อย่างไร

เพราะ CSMA กำหนดให้สเตชัน “ฟังก่อนพูด” — ก่อนจะส่งข้อมูลลงในช่องสัญญาณ สเตชันจะตรวจสอบ (Sense) ว่าช่องสัญญาณมีการใช้งานอยู่ (busy) หรือไม่ ถ้าพบว่ามีคนอื่นกำลังส่งอยู่ ก็จะไม่ส่งทับลงไป ต่างจาก ALOHA ที่ส่งทันทีโดยไม่สนใจว่าใครกำลังใช้อยู่หรือเปล่า จึงตัดการชนแบบ “ส่งทับของที่กำลังวิ่งอยู่บนสาย” ออกไปได้เกือบทั้งหมด เหลือเพียงกรณีที่เกิดจาก propagation delay (ดูข้อ 11)

ข้อ 6. การพัฒนาของ CSMA/CD เป็นการต่อยอดจาก CSMA สามารถทำให้ระบบทำงานดีขึ้นได้อย่างไร

ปัญหาของ CSMA เดิมคือ เฟรมจะถูกส่งจนสิ้นสุดความยาวทั้งหมด แม้ว่าสเตชันต้นทางจะพบว่าเฟรมนั้นเกิดการชนกันแล้ว → เสียเวลาช่องสัญญาณไปกับข้อมูลที่ยังไงก็ใช้ไม่ได้

CSMA/CD เพิ่ม Collision Detection เข้าไป ทำให้:

  1. สเตชันหยุดส่งส่วนที่เหลือของเฟรมทันทีเมื่อพบว่ามีการชนกัน → คืนช่องสัญญาณให้ระบบเร็วขึ้น

  2. ส่งสัญญาณขนาดเล็กเรียกว่า jamming signal ลงในช่องสัญญาณ เพื่อแจ้งให้ทุกสเตชันทราบว่าเกิดการชนกันขึ้น

  3. เข้าสู่กระบวนการส่งซ้ำ (re-transmission) โดยใช้ Exponential Backoff Algorithm เพื่อลดโอกาสที่จะชนซ้ำ

ผลลัพธ์ตามที่หนังสือระบุ: “การเพิ่มเติมการทำงานส่วนการตรวจจับการชนกัน ทำให้ทรูพุตของระบบสูงขึ้น”

ข้อ 7. CSMA/CD ใช้ Binary Exponential Backoff เพื่ออะไร อธิบายหลักการ

เพื่ออะไร — เพื่อหลีกเลี่ยงการชนกันอีกครั้งของสเตชันที่ต้องการส่งเฟรมใหม่ ถ้าทุกสเตชันที่เพิ่งชนกันรีบส่งใหม่พร้อมกันทันที ก็จะชนซ้ำไปเรื่อย ๆ ไม่จบ

หลักการ — สเตชันที่ส่งไม่สำเร็จ ถ้าต้องการส่งใหม่จะต้องสุ่มเวลาหน่วงเป็น C เท่าของเวลาหน่วงของการแพร่กระจาย (tprop) หรือค่าเฉลี่ยเวลาหน่วงการส่งเฟรม

0 ≤ C ≤ 2K C เป็นค่าสุ่ม · K = จำนวนรอบที่สเตชันพยายามส่ง

ทุกครั้งที่ชนซ้ำ K เพิ่มขึ้น 1 → ช่วงของการสุ่มขยายเป็นสองเท่า (นี่คือที่มาของคำว่า Binary Exponential) ทำให้โอกาสที่สองเครื่องจะสุ่มได้เลขเดียวกันลดลงเรื่อย ๆ

รอบที่ชน (K)ช่วงสุ่ม Cจำนวนค่าที่เป็นไปได้
10 – 23
20 – 45
30 – 89
40 – 1617

ตัวเลขที่ต้องจำ — ในอีเทอร์เน็ต สเตชันจะพยายามส่งเป็นจำนวน 16 ครั้ง หากไม่สามารถส่งได้ เฟรมนั้นจะถูกกำจัดทิ้งไป (discard) และแจ้งความผิดพลาด (error) ที่เกิดขึ้น

ข้อ 8. ทำไม CSMA/CD จึงไม่เหมาะแก่การใช้ใน Wireless LAN

หนังสือระบุ สาเหตุหลักสองประการ

  1. ต้นทุนสูง — การจะตรวจสอบการชนกันของเฟรมในแบบไร้สาย จำเป็นต้องสามารถตรวจสอบการใช้ช่องสัญญาณได้ (คือรับไปพร้อมกับส่งไปด้วย) ซึ่งการที่จะทำเช่นนั้นจะทำให้เพิ่มค่าใช้จ่ายอย่างมาก

  2. ไม่รับประกันว่าทุกโนดจะได้ยินกันหมด — ในเครือข่ายไร้สายไม่สามารถรับประกันได้ว่าทุกโนดจะรับทราบถึงการใช้ช่องสัญญาณของโนดทุกโนด ในความเป็นจริง แม้ว่าจะพบว่าช่องสัญญาณในด้านส่งว่างอยู่พร้อมที่จะส่ง แต่มิได้หมายความว่าช่องสัญญาณในทางด้านรับจะว่างเสมอ

พูดง่าย ๆ คือ “การชน” เกิดที่ฝั่งรับ แต่ CD ตรวจได้เฉพาะที่ฝั่งส่ง — ในสายทองแดงสองอย่างนี้เห็นตรงกัน แต่ในอากาศไม่ตรงกัน WLAN จึงใช้ CSMA/CA (หลีกเลี่ยงการชนแทนที่จะตรวจจับ) — ชื่อ CSMA/CA เป็นความรู้เสริม ไม่ได้อยู่ในย่อหน้านี้ของหนังสือ

ข้อ 9. Ethernet 100BASE-T สื่อความหมายใดในการสื่อสาร

ชื่อมาตรฐานตระกูล IEEE 802.3 ประกอบด้วย 3 ส่วน อ่านจากซ้ายไปขวา

ส่วนในชื่อ 100BASE-Tความหมายตามหนังสือ
1. ความเร็ว100ความเร็วเป็นเมกะบิตต่อวินาที (Mbps) ของข้อมูลที่ส่งในสายสัญญาณ → ที่นี่คือ 100 Mbps
2. วิธีการส่งBASEเบสแบนด์ (baseband) คือการส่งแบบดิจิทัล โดยสัญญาณดิจิทัลถูกส่งเข้าไปในช่องสัญญาณโดยตรง ทำให้สเปกตรัมเริ่มตั้งแต่ความถี่ศูนย์ (0) จนถึงค่าสูงสุดของแบนด์วิดท์ช่องสัญญาณ · (ถ้าเป็น BROAD จะหมายถึงบรอดแบนด์ที่ใช้สัญญาณแอนะล็อกเป็นคลื่นพาหะ ซึ่งไม่นิยม)
3. สายสัญญาณ / ระยะTถ้าเป็นตัวเลขหมายถึงระยะทางสูงสุดที่ส่งได้โดยสัญญาณไม่ลดทอน (เช่น 10BASE5 = 500 เมตร) แต่ถ้าเป็นตัวอักษรจะระบุชนิดของสายสัญญาณ — ตามตารางที่ 14.1 T = Unshielded twisted pair (UTP)

สรุปคำตอบ: 100BASE-T = อีเทอร์เน็ตความเร็ว 100 Mbps ส่งแบบ เบสแบนด์ (ดิจิทัล) บน สาย UTP · เทียบเคียง: 10BASE-F = 10 Mbps บนสายใยแก้วนำแสง, TX = สอง pair ของ STP หรือ Cat-5 UTP, T4 = สี่ pair ของ Cat-3 UTP

ข้อ 10. การใช้ Trunk ใน VLAN มีประโยชน์อย่างไร

Trunking คือการเพิ่ม tag ลงบนเฟรมที่ส่ง ทำให้สามารถส่งเฟรมของมากกว่าหนึ่ง VLAN พร้อมกันผ่านพอร์ตเดียวกันได้ โดยสวิตช์หรือเร้าเตอร์จะส่งต่อ (forward) เฟรมไปยังแต่ละ VLAN โดยอาศัยข้อมูลของ tag

  • ประหยัดพอร์ตบนสวิตช์และเร้าเตอร์ — นี่คือประโยชน์ที่หนังสือระบุตรง ๆ
  • ประหยัดสาย — ถ้าต้องการเชื่อมสวิตช์สองตัวที่แต่ละตัวมี 4 VLAN โดยไม่ใช้ trunk จะต้องเดินสาย 4 เส้น (เส้นละ VLAN) แต่ถ้าใช้ Trunk ใช้เพียงเส้นเดียว
  • ทำให้ขยาย VLAN ข้ามสวิตช์หลายตัว / ต่างสถานที่ ได้ โดยยังแยกบรอดคาสท์โดเมนกันอยู่
  • ตัวเลขที่ยกไปตอบได้เลย (ดูรูปประกอบใน บทที่ 16) — เชื่อม 3 VLAN ผ่านเร้าเตอร์แบบไม่มี trunk = 3 เส้น พอใช้ trunk เหลือเส้นเดียว · เชื่อมสวิตช์สองตัวที่มีตัวละ 4 VLAN = 4 เส้น พอใช้ trunk เหลือเส้นเดียว

โพรโตคอลที่ใช้ — บนสวิตช์ CISCO ทำได้สองวิธีคือ Inter-Switch Link (ISL) ซึ่งเป็นของ CISCO เอง และ IEEE 802.1Q ซึ่งทำงานได้กับสวิตช์หลายผู้ผลิต · 802.1Q กำหนดฟิลด์ Type/Length ของเฟรมให้เป็น 0x8100 (ค่ามากกว่า 1500 อีเทอร์เน็ตจึงเข้าใจว่าเป็น Type ไม่ใช่ Length) แล้วเพิ่มสองไบต์ถัดมาเป็นข้อมูล tag — ข้อดีคือสวิตช์รุ่นเก่าที่ไม่รองรับก็ยังส่งต่อเฟรมได้ เพราะ 802.1Q เพียงเพิ่มข้อมูล VLAN tag ในเฟรมเท่านั้น

ข้อ 11. จากการทำงานของ CSMA ทำไมจึงยังมีการชนกันของข้อมูลเกิดขึ้น

สาเหตุคือ propagation delay — สัญญาณใช้เวลาเดินทางบนสาย ไม่ได้ถึงทุกจุดพร้อมกัน

ตามตัวอย่างในหนังสือ (รูปที่ 13.12): สเตชัน B เริ่มส่งหลังจากสเตชัน A ส่งข้อมูลออกไปเพียงเล็กน้อย (Δt) ซึ่งเป็นช่วงที่เฟรมของ A ยังเดินทางมาไม่ถึง B ดังนั้นแม้ว่า B จะตรวจสอบ (sense) ตามกติกาของ CSMA อย่างถูกต้อง B ก็จะพบว่าช่องสัญญาณยังว่างอยู่ เพราะสัญญาณของ A ยังมาไม่ถึงจุดที่ B ตรวจสอบ

B จึงเข้าใจว่าสามารถเริ่มส่งเฟรมได้ แต่เมื่อเฟรมของ A มาถึง B ก็จะพบว่าเกิดการชนกันของเฟรมขึ้น (ถ้าเป็น CSMA/CD สเตชัน B จะหยุดส่งส่วนที่เหลือพร้อมทั้งส่ง jamming signal) → นี่คือเหตุผลที่ CSMA “ลด” การชนได้ แต่ “กำจัด” ไม่ได้

สี่ขั้นเรียงลงมา: (1) สเตชัน A ส่งข้อมูลออกไปสองทางบนสายร่วม (2) สเตชัน B ตรวจสายแล้วพบว่าว่าง จึงเริ่มส่งของตัวเองด้วย (3) สัญญาณสองฝั่งมาเจอกันกลางสาย มีวงกลมแดงกำกับว่าเกิดการชนกันของเฟรม (4) ทั้งสองฝั่งส่ง Jamming signal เป็นเส้นสีแดงเต็มสาย
รูปที่ 13.12 จากตำรา — การชนกันของข้อมูลใน CSMA · ไล่จากบนลงล่าง: A ส่งก่อน → B ตรวจสายแล้วพบว่า “ว่าง” จึงส่งด้วย (เพราะสัญญาณของ A ยังมาไม่ถึง) → เกิดการชนกันของเฟรมกลางสาย → ทั้งคู่ส่ง Jamming signal · จุดที่ต้องสังเกต: B ไม่ได้ทำผิดกติกาเลย แต่ก็ยังชนอยู่ดี เพราะ propagation delay
ข้อ 12. ข้อดีของ VLAN คืออะไร ทำไมจึงต้องมีการใช้ VLAN
  • ไม่ผูกกับสถานที่ติดตั้ง — VLAN ทำให้อุปกรณ์ที่เชื่อมต่อใน LAN สามารถสื่อสารกันได้โดยไม่เกี่ยวข้องกับสถานที่ติดตั้งอุปกรณ์นั้น ๆ เมื่ออุปกรณ์เชื่อมต่อเข้ายัง VLAN เดียวกัน จะเสมือนว่าอยู่บนสวิตช์ของ LAN เดียวกัน
  • แยกกลุ่มได้แม้อยู่บนสวิตช์เดียวกัน — ในทางตรงข้าม แม้อุปกรณ์จะอยู่บนสวิตช์เดียวกัน หากอยู่ต่าง VLAN ก็ไม่สามารถสื่อสารกันได้ (อยู่คนละบรอดคาสท์โดเมน) จึงใช้เป็นกลไกความปลอดภัย/แบ่งแผนกได้
  • ทำเชิงตรรกะ ไม่ต้องแตะฮาร์ดแวร์ — เราสามารถแยกเครื่องใดเครื่องหนึ่งออกจากระบบได้ โดยไม่จำเป็นต้องยุ่งเกี่ยวกับการติดตั้งสายเชื่อมต่อ เพราะเป็นการทำโดยซอฟต์แวร์
  • ลดทราฟฟิกบน LAN — ตามบทสรุปของหนังสือ VLAN «ช่วยในการแบ่งลดทราฟฟิกบน LAN ลง» เพราะบรอดคาสท์ไม่กระจายข้าม VLAN

ข้อควรรู้ — สวิตช์นั้น ๆ ต้องรองรับการทำงาน VLAN ด้วย · กำหนดได้ 2 วิธีคือ static (ผูกกับพอร์ตของสวิตช์ — บน Cisco VLAN 1 เป็นค่าปริยาย) และ dynamic (อาศัย MAC address) · ถ้าต้องการให้ต่าง VLAN คุยกันได้ ต้องมีเร้าเตอร์มาช่วยเชื่อม

ข้อ 13. พื้นฐานการทำงานของ Bridge มีอะไรบ้าง อธิบาย

บริดจ์ (โดยเฉพาะ Transparent Bridge ซึ่งเป็นแบบที่ง่ายที่สุดเพื่อใช้เชื่อม LAN เข้าด้วยกัน) ทำงานด้วยสองส่วนหลัก

  1. Learning logic — สร้าง forwarding table

    บริดจ์อ่านค่า MAC address ต้นทางของเฟรมทุกเฟรมที่ส่งมา แล้วเปรียบเทียบกับตารางที่มีอยู่ หากไม่พบ จะเพิ่มค่า MAC address ต้นทางพร้อมหมายเลขพอร์ตที่รับข้อมูลเข้ามา ตารางนี้จึงสร้างขึ้นโดยอัตโนมัติ

  2. Forwarding logic — ตัดสินใจส่งต่อ โดยอ่าน MAC address ปลายทาง แล้วเทียบกับตาราง มี 3 กรณี

    • พบในตาราง → ส่งผ่านเฟรมไปยังพอร์ตที่ระบุไว้ในตาราง (forward)
    • พบว่าพอร์ตของต้นทางและปลายทางเป็นพอร์ตเดียวกัน → กำจัดเฟรมทิ้ง โดยไม่มีการส่งต่อข้อมูล (filter) เพราะทั้งคู่อยู่ฝั่งเดียวกันอยู่แล้ว
    • ไม่พบปลายทาง → ส่งเฟรมออกไปทุกพอร์ต ยกเว้นพอร์ตที่รับเฟรมเข้ามา (flood)

  3. Aging — จำกัดอายุของเอ็นทรี เพื่อลดขนาดของตารางที่ต้องค้นหา บริดจ์เพิ่มตัวจับเวลาให้แต่ละแอดเดรส ช่วงเวลาประมาณ 300 วินาที (ปรับเปลี่ยนได้) เมื่อค่าเวลาเป็นศูนย์ แอดเดรสนั้นจะถูกลบออกจากตาราง

ข้อจำกัด — หากเฟรมมีค่าแอดเดรสไม่สมบูรณ์หรือปลายทางไม่ปรากฏ เฟรมจะถูกส่งต่อไปอย่างไม่หยุด เกิดเป็น broadcast storm · และโดยทั่วไปบริดจ์ไม่สามารถใช้ใน LAN ที่มีเส้นทางซ้ำ ๆ กัน (redundant paths) ได้ เพราะอาจทำให้เกิด broadcast storm — ซึ่งเป็นเหตุผลที่ต้องมี STP

ข้อ 14. จงอธิบายการเกิด Broadcast Storm

นิยามตามหนังสือ (บทที่ 14) — «หากเฟรมที่มีค่าของแอดเดรสที่ไม่สมบูรณ์ หรือค่าของปลายทางไม่ปรากฏ จะทำให้เฟรมถูกส่งต่อไปอย่างไม่หยุด จนกระทั่งถูกส่งไปยังบริดจ์ที่ต่ออยู่ทั้งหมด การเกิดกรณีนี้เรียกว่า broadcast storm ทำให้ประสิทธิภาพของระบบลดลง»

กลไกที่ทำให้มันไม่จบ — เมื่อบริดจ์/สวิตช์ไม่รู้ว่าปลายทางอยู่พอร์ตไหน มันจะ flood เฟรมออกทุกพอร์ต ถ้าโครงสร้างเน็ตเวิร์กมี เส้นทางซ้ำ (redundant paths) จนเกิดลูป เฟรมที่ถูก flood จะวนกลับมาเข้าอีกพอร์ตหนึ่งของสวิตช์ตัวเดิม แล้วถูก flood ออกไปอีก วนไม่รู้จบ — และเนื่องจากเฟรมในเลเยอร์ 2 ไม่มีฟิลด์ TTL ให้ลดค่าเหมือน IP จึงไม่มีอะไรมาหยุดมันเอง (ประเด็น TTL เป็นความรู้เสริม)

หนังสือบทที่ 15 อธิบายภาพเดียวกันไว้ว่า การเชื่อมสวิตช์หลายตัวเข้าด้วยกัน อาจทำให้เกิดลูป (loop) ขึ้น ทำให้มีโอกาสเกิดการส่งต่อเฟรมจากสวิตช์หนึ่งไปยังอีกสวิตช์หนึ่งอย่างไม่สิ้นสุด ส่งผลให้ประสิทธิภาพของเน็ตเวิร์กลดลง → คำตอบข้อนี้กับข้อ 15 จึงต่อกันพอดี

ข้อ 15. ข้อดีของ Spanning Tree Protocol (STP) คืออะไร
  • กำจัดลูป — STP เป็นโปรโตคอลที่พัฒนาขึ้นเพื่อกำจัดลูป (loop) ที่เกิดขึ้นจากการเชื่อมสวิตช์หลายตัวเข้าด้วยกัน จึงตัดปัญหาการส่งต่อเฟรมอย่างไม่สิ้นสุด (broadcast storm) ที่ทำให้ประสิทธิภาพเน็ตเวิร์กลดลง
  • ติดตั้งสวิตช์จำนวนมากได้อย่างสบายใจ — ตามที่หนังสือระบุในบทที่ 16: «การทำงานของ STP ช่วยให้เราสามารถติดตั้งสวิตช์จำนวนมากได้ โดยไม่ต้องกังวลการเกิด broadcast storm»
  • ยังคงมีเส้นทางสำรองไว้ใช้ — STP ไม่ได้ตัดสายทิ้ง แต่บล็อกพอร์ตไว้เฉย ๆ ถ้าเส้นทางหลักล่ม พอร์ตที่ถูกบล็อกจะถูกเปิดกลับมาใช้แทน จึงได้ทั้งความปลอดภัยจากลูปและความทนทาน (redundancy)
  • เป็นมาตรฐานกลาง — พัฒนาโดย Digital Equipment Corporation (DEC) ภายหลังได้รับการปรับปรุงโดย IEEE ให้เป็นมาตรฐาน IEEE 802.1d · ข้อควรระวังตามหนังสือ: ผู้ผลิตสวิตช์ทุกรายมิได้ใช้มาตรฐาน IEEE 802.1d ทั้งหมด ดังนั้นการใช้สวิตช์หลายผู้ผลิตในเครือข่ายเดียวกันต้องระวัง

รายละเอียดของ BPDU, Root Bridge, RP/DP/BP และ Port States อยู่ในบทที่ 15 (ออกสอบข้อ Q10)

เช็คความเข้าใจ

ในเฟรมของ ARP request ค่าของ Target Hardware Address คืออะไร?
หนังสือระบุชัดว่า «ในกรณีของ ARP request ค่านี้จะเป็น 0 หมด เนื่องจากยังไม่ทราบแอดเดรสของด้านรับ» — ระวังอย่าสับสนกับ FF:FF:FF:FF:FF:FF ซึ่งเป็น Destination MAC ของเฟรมอีเทอร์เน็ต (ชั้นนอก) ไม่ใช่ฟิลด์ Target HA ในตัว ARP message
PC ที่ IP 192.168.1.3 (mask /24) จะ ping ไปยัง 10.0.0.9 โดยมี default gateway อยู่ที่ 192.168.1.1 — PC จะส่ง ARP request ถามหา MAC ของ IP ใด?
ปลายทางอยู่คนละซับเน็ต และ ARP request เป็นบรอดคาสท์ซึ่งเร้าเตอร์ไม่ส่งต่อข้ามซับเน็ต ดังนั้นการถามหา MAC ของ 10.0.0.9 จะไม่มีวันได้คำตอบ PC จึง ARP หา MAC ของ default gateway แล้วส่งเฟรมไปให้เร้าเตอร์ โดยยังใส่ Destination IP เป็น 10.0.0.9 ตามเดิม — นี่คือเหตุผลที่ arp -a จะเห็นแต่ MAC ของเร้าเตอร์
ค่าฟิลด์ Operation ของ RARP reply คือเท่าไร?
ARP request = 1, ARP reply = 2, RARP request = 3, RARP reply = 4 · ส่วน 0x0806 คือค่าฟิลด์ Type ของเฟรมอีเทอร์เน็ต ที่บอกว่าข้างในเป็น ARP ไม่ใช่ค่า Operation
ข้อใดคือเหตุผลที่หนังสือระบุว่า RARP ไม่จัดว่าเป็น autoconfiguration?
การที่ RARP อยู่บน Data Link Layer เป็นเหตุผลของข้อจำกัดอีกข้อหนึ่ง (ส่งข้ามเน็ตเวิร์กไม่ได้ ต้องมี RARP server หลายตัว) ส่วนเหตุผลที่ไม่ใช่ autoconfiguration คือ «จะต้องมีผู้ดูแลระบบจับคู่ระหว่างฮาร์ดแวร์แอดเดรสกับ IP address» — จึงมีการพัฒนา DHCP มาแทน
PC-A บรอดคาสท์ ARP request ถามหา MAC ของ 192.168.1.77 แต่ไม่มีเครื่องไหนในวง LAN ใช้ IP นี้ · จะเกิดอะไรขึ้น
ARP มีแค่ request (1) กับ reply (2) — ไม่มีเมสเสจ “ไม่พบ” เครื่องที่ Target Protocol Address ไม่ตรงจะเงียบ · สวิตช์เป็นอุปกรณ์ Layer 2 ไม่ได้อ่าน IP จึงตอบแทนไม่ได้ · และเร้าเตอร์ไม่ส่งต่อบรอดคาสท์ข้ามซับเน็ต ⇒ ผลคือความเงียบและการหมดเวลา แล้ว ping จะขึ้น Request timed out
จากรูปที่ 17.7 · ตอนที่ ARP reply แบบยูนิคาสต์วิ่งกลับมา ทำไมสวิตช์จึงไม่ flood เฟรมนี้ออกทุกพอร์ต
ตอนรับ ARP request เข้ามาทาง e0/11 สวิตช์เรียนรู้ MAC ต้นทางไปแล้วว่า 0101.0101.0101 → Ethernet 0/11 · พอ reply วิ่งกลับมาโดยมีปลายทางเป็น MAC นั้น สวิตช์เปิดตารางแล้วเจอ จึงบอกว่า “I do know this destination! I will not flood this frame.” แล้วส่งออกพอร์ตเดียว · หลักการคือ flood เกิดเมื่อ “ตารางไม่มีข้อมูล” หรือเป็นเฟรมบรอดคาสท์เท่านั้น
การ์ตูนอธิบาย ARP
รูปที่ 17.8 จากตำรา — “arp” สรุปทั้งบทในห้าช่อง: อยากคุยกับ ‘A’ → ตะโกนถามทั้งห้อง “WHO IS ‘A’” → มีคนเดียวยกมือ “I’m ‘A’” → จับคู่กันได้ → คุยกันได้
เก็บก่อนออกจากบทนี้
  • ARP = รู้ IP (L3) → หา MAC (L2) · RARP = รู้ MAC → หา IP · ทั้งคู่ทำงานใน Data Link Layer
  • ARP ห่อในเฟรมอีเทอร์เน็ตโดยตรง Type = 0x0806 (จำเลขนี้ให้ได้ ใช้เป็น Wireshark filter eth.type == 0x0806 หรือพิมพ์ arp เฉย ๆ ก็ได้) · RFC 826 · เป็น autoconfiguration
  • request = broadcast (dst MAC = FF:FF:FF:FF:FF:FF, Target HA = 0 ทั้งหมด) · reply = unicast
  • Operation: ARP req = 1, ARP reply = 2, RARP req = 3, RARP reply = 4
  • ฟิลด์ 9 ช่องเรียงตามนี้: Hardware Type (อีเทอร์เน็ต = 1) · Protocol Type (IPv4 = 0x0800) · HLEN (= 6) · PLEN (= 4) · Operation · Sender HA · Sender IP · Target HA · Target IP
  • ได้ reply แล้วเก็บ <IP, MAC> ใน ARP cache · ตรวจด้วย arp -a (Windows/macOS/Linux) หรือ show arp (Cisco)
  • ข้ามซับเน็ต → ARP หา MAC ของ default gateway ไม่ใช่ของปลายทาง · ทุก hop MAC เปลี่ยน แต่ IP คงเดิม
  • บนสวิตช์: request เป็นบรอดคาสท์ ⇒ flood ทุกพอร์ต · reply เป็นยูนิคาสต์และปลายทางอยู่ใน MAC Address Table แล้ว ⇒ ส่งพอร์ตเดียว ไม่ flood · สวิตช์เรียนรู้จาก MAC ต้นทางของเฟรมที่วิ่งเข้ามา
  • เมื่อไม่มีใครเป็นเจ้าของ IP นั้น — ไม่มีใครตอบ (ARP ไม่มีเมสเสจ “ไม่พบ”) ⇒ ไม่เกิดเอ็นทรีใน cache · เฟรมถูกทิ้ง · ping timeout
  • RARP ตายเพราะ ข้ามเน็ตเวิร์กไม่ได้ (ต้องมีเซิร์ฟเวอร์ทุกซับเน็ต) + ต้องให้คนจับคู่ MAC↔IP เอง → DHCP มาแทน