บทที่ 14

อีเทอร์เน็ต (Ethernet)

บทนี้ตอบ 3 คำถาม — Data Link Layer แตกเป็น LLC กับ MAC ทำไม, เฟรม IEEE 802.3 มีฟิลด์อะไรบ้างและยาวเท่าไร, และบริดจ์ "เรียนรู้" ว่าเครื่องไหนอยู่พอร์ตไหนได้อย่างไรโดยไม่มีใครบอก

อ่าน ~16 นาที ฐานของ ข้อสอบ Q13 + Q10 ต่อจาก บทที่ 13 (CSMA/CD) ไปต่อ บทที่ 15 (STP)

ข้อสอบออกแบบไหน

บทนี้ไม่ค่อยออกเป็น "ข้อของตัวเอง" แต่เป็นฐานของข้ออื่น — กฎ เฟรมต่ำสุด 64 ไบต์ คือเหตุผลเบื้องหลัง Q13 (CSMA/CD collision window) · การเรียนรู้ของบริดจ์คือสิ่งที่ STP ใน Q10 ป้องกันไม่ให้วนลูป · และ Length/Type กับ MAC address คือสิ่งที่ต้องชี้ให้ถูกใน Q3 (Wireshark) · ถ้าถูกถามตรง ๆ มักเป็น "วาดเฟรม IEEE 802.3 พร้อมระบุขนาดแต่ละฟิลด์"

14.0อ่านชื่อมาตรฐาน IEEE 802.3 ให้ออก

ช่วงปี ค.ศ. 1980–1990 อีเทอร์เน็ตถูกใช้อย่างแพร่หลายและมีมาตรฐานใหม่ ๆ เกิดขึ้นมากมาย จึงต้องมีวิธีตั้งชื่อให้เป็นมาตรฐานเดียวกัน รวมไปถึงระบุคุณลักษณะ การทำงาน และความเร็ว ชื่อจึงประกอบด้วย 3 ส่วน เช่น 10BASE5 หรือ 100BASE-TX

ผังต้นไม้: กล่องบนสุดคือ IEEE 802.3 CSMA/CD แตกลงมาเป็นสามกิ่ง — Ethernet at 10 Mbps (10BASE5, 10BASE2, 10BASE-T, 10BASE-F, 10BASE-FP, 10BASE-FB, 10BASE-FL, 10BROAD36), Fast Ethernet หรือ 100BASE-T at 100 Mbps (100BASE-X, 100BASE-TX, 100BASE-FX, 100BASE-T4) และ Gigabit Ethernet หรือ 1000BASE-X และ -T at 1000 Mbps (1000BASE-X, 1000BASE-SX, 1000BASE-LX, 1000BASE-CX, 1000BASE-T) — รูปที่ 14.1 จากตำรา — มาตรฐานของตระกูล IEEE 802.3 (จุดที่ต้องสังเกต: ทุกกิ่งแตกออกมาจาก**รากเดียวกันคือ CSMA/CD** และในผังทั้งหมดมี**ชื่อเดียวที่ลงท้ายด้วย BROAD คือ 10BROAD36** — ที่เหลือเป็น BASE ทั้งหมด ซึ่งตรงกับที่ตำราบอกว่าบรอดแบนด์ "ไม่เป็นที่นิยมเท่าที่ควร")

ส่วนที่ 1 — ตัวเลขนำหน้า

ความเร็วเป็น Mbps ของข้อมูลที่ส่งในสายสัญญาณ เช่น 10, 100, 1000

ส่วนที่ 2 — BASE / BROAD

BASE = เบสแบนด์ (baseband) ส่งสัญญาณดิจิทัลเข้าช่องสัญญาณโดยตรง สเปกตรัมเริ่มจาก 0 ถึงค่าสูงสุดของแบนด์วิดท์ · BROAD = บรอดแบนด์ ใช้สัญญาณแอนะล็อกเป็นคลื่นพาหะ — ไม่เป็นที่นิยม

ส่วนที่ 3 — ตัวเลขหรือตัวอักษร

ถ้าเป็นตัวเลข = ระยะทางสูงสุดที่ส่งได้โดยสัญญาณไม่ลดทอน เช่น 10BASE5 = 10 Mbps ระยะ 500 เมตร · ถ้าเป็นตัวอักษร = ชนิดของสายสัญญาณ เช่น 10BASE-F = 10 Mbps บนใยแก้วนำแสง

กิ่งในรูปที่ 14.1	ความเร็ว	สมาชิกในตระกูล (ตามที่พิมพ์ในรูป)
Ethernet	10 Mbps	`10BASE5` · `10BASE2` · `10BASE-T` · `10BASE-F` · `10BASE-FP` · `10BASE-FB` · `10BASE-FL` · `10BROAD36`
Fast Ethernet (100BASE-T)	100 Mbps	`100BASE-X` · `100BASE-TX` · `100BASE-FX` · `100BASE-T4`
Gigabit Ethernet (1000BASE-X และ -T)	1000 Mbps	`1000BASE-X` · `1000BASE-SX` · `1000BASE-LX` · `1000BASE-CX` · `1000BASE-T`

แปลงจากรูปที่ 14.1 ให้อ่านเป็นตาราง — จำแค่ "10 / 100 / 1000 แล้วต่อด้วยตัวย่อสาย" ก็พอ

Symbol	Definition
`T`	Unshielded twisted pair
`F`	Optical fiber
`FP`	Optical fiber passive star
`FS`	Optical fiber backbone
`FL`	Optical fiber link
`X`	Two physical links between nodes
`TX`	Two pairs of STP or Cat-5 UTP
`FX`	Two optical fibers
`T4`	Four pairs of Cat-3 UTP
`SX`	Short-wavelength duplex optical fiber link
`LX`	Long-wavelength duplex optical fiber link
`CX`	One pair of short-UTP wire

ตารางที่ 14.1 — ข้อกำหนดตัวย่อบนมาตรฐาน IEEE 802.3

อ่านตัวอย่างจริง

100BASE-TX = 100 Mbps · เบสแบนด์ · สาย STP หรือ Cat-5 UTP สองคู่ · 1000BASE-LX = 1000 Mbps · เบสแบนด์ · ใยแก้วนำแสงคลื่นยาว · 10BASE5 = 10 Mbps · เบสแบนด์ · 500 เมตร (ตัวเลข ไม่ใช่ตัวอักษร จึงเป็นระยะทาง)

14.1ความสัมพันธ์ของโมเดล OSI และอีเทอร์เน็ตมาตรฐาน

อีเทอร์เน็ตกินพื้นที่ 2 เลเยอร์ล่างสุดของ OSI และในแต่ละเลเยอร์ยังถูกซอยย่อยลงไปอีก:

Data Link Layer ประกอบด้วยเลเยอร์ย่อย LLC Sublayer และ MAC Sublayer
Physical Layer ประกอบด้วย physical signalling sublayer (PLS) และ attachment unit interface (AUI) เพื่อเป็นช่องสัญญาณระหว่าง MAC กับ medium attachment unit (MAU)

ส่วนย่อย	อยู่ตรงไหน	ทำหน้าที่อะไร
LLC	Data Link (บน)	กำหนดแอดเดรส (SAP) และควบคุมการแลกเปลี่ยนข้อมูลระหว่างผู้ใช้กับส่วนควบคุม — ใช้ร่วมกันในทุกโพรโตคอลของ LAN
MAC	Data Link (ล่าง)	รับ/ส่งข้อมูลจาก LLC · ซิงโครไนเซชัน · ควบคุมการถ่ายเทข้อมูล · ควบคุมข้อผิดพลาด · แอดเดรสเครื่อง
PLS	Physical	จัดการการเข้าใช้ช่องสัญญาณด้วยการตรวจสอบสถานะของตัวกลางที่เชื่อมต่ออยู่
AUI	Physical	ช่องสัญญาณระหว่าง PLS กับ MAU — อาจเป็นเคเบิลภายนอก หรือถูกรวมเข้าไปในวงจรรวม (IC) ก็ได้
MAU	Physical	เชื่อมสัญญาณระหว่างตัวเครื่องกับสายสัญญาณ (ใยแก้วนำแสง / โคแอกเชียล) แบ่งเป็น PMA และ MDI
`└ PMA`	ใน MAU	transceiver — กำหนดสัญญาณไฟฟ้า/แสง, สภาวะของสาย, สัญญาณนาฬิกา, การเข้ารหัสสัญญาณ และวงจรรับส่งข้อมูล
`└ MDI`	ใน MAU	Medium-Dependent Interface — ส่วนเชื่อมต่อระหว่าง transceiver กับสายสัญญาณ

ในเครื่องจริงมันอยู่ตรงไหน

ในปัจจุบันวงจรของ MAC + PLS ถูกใส่รวมเข้าไปใน network interface card (NIC) ทั้งก้อน — นี่คือกรณีปกติทุกวันนี้ · แปลว่า "การ์ดแลน" หนึ่งใบ = MAC sublayer + ครึ่งบนของ Physical Layer นั่นเอง

ผังเทียบเลเยอร์ OSI ทางซ้ายกับส่วนประกอบของอีเทอร์เน็ต 10 Mbps ทางขวา: Data link layer ถูกซอยเป็น LLC และ MAC ส่วน Physical layer ถูกซอยเป็น PLS, AUI และ MAU ซึ่ง MAU ยังแยกย่อยเป็น PMA และ MDI ก่อนต่อลงสายสัญญาณ — รูปที่ 14.2 จากตำรา — ความสัมพันธ์ของโมเดล OSI และอีเทอร์เน็ตมาตรฐาน (10 Mbps)

14.1.1Logical Link Control (LLC)

LLC เป็นส่วนหนึ่งใน Data Link Layer เป็นเลเยอร์ย่อยที่ถูกใช้ร่วมกันในทุกโพรโตคอลของ LAN (802.3 Ethernet, 802.5 Token Ring, 802.11 Wireless LAN และ LAN อื่น ๆ ใช้ LLC ตัวเดียวกัน) หน้าที่เบื้องต้นคือกำหนดแอดเดรส และทำให้การแลกเปลี่ยนข้อมูลระหว่างผู้ใช้กับส่วนควบคุมเป็นไปได้

ผังชั้นของมาตรฐาน IEEE-802: แถวบนคือเลเยอร์ถัดขึ้นไป · Data link layer แบ่งเป็นแถบ LLC (Logical Link Control) ที่พาดยาวตลอดความกว้าง และแถบ MAC ที่ซอยเป็นสี่ช่อง คือ 802.3 Ethernet, 802.5 Token Ring, 802.11 Wireless LAN และ LAN อื่นๆ · แถวล่างสุดคือ Physical layers ต่างๆ เช่น UTP ใยแก้วนำแสง สัญญาณวิทยุ — รูปที่ 14.3 จากตำรา — มาตรฐานของ IEEE-802 (จุดที่ต้องสังเกต: แถบ **LLC พาดยาวช่องเดียวตลอดความกว้าง** ในขณะที่แถบ **MAC ถูกซอยเป็นหลายช่องตามชนิดของ LAN** — นี่คือภาพที่อธิบายประโยค "LLC ถูกใช้ร่วมกันในทุกโพรโตคอลของ LAN" ได้ในรูปเดียว)

อ่านรูปที่ 14.3 ให้ได้ใจความ

ที่ต้องเห็นคือ "ท่อนบนเหมือนกันหมด ท่อนล่างต่างกัน" — โปรแกรมชั้นบนคุยกับ LLC ด้วยหน้าตาเดียวกันเสมอ ไม่ว่าข้างล่างจะเป็นสายทองแดง 802.3 หรือคลื่นวิทยุ 802.11 · ส่วนที่รู้เรื่องตัวกลางจริง ๆ (จะชนกันไหม ต้องรอ token ไหม) ถูกยัดไว้ใน MAC ทั้งหมด · นี่คือเหตุผลที่ตำราแยก Data Link ออกเป็นสองเลเยอร์ย่อยตั้งแต่แรก

การทำงานของ LLC ขึ้นกับโพรโตคอล High-Level Data Link Control (HDLC) ที่ใช้อย่างแพร่หลายบน Data Link Layer เพื่อให้บริการพื้นฐาน 3 แบบ:

① Unacknowledged connectionless

ส่งเฟรมที่ไม่มีหมายเลข ไม่จำเป็นต้องมีลำดับ · ไม่มี overhead ในการสร้างการเชื่อมต่อแบบตรรกะ · เหมาะกับงานที่ต้องการ interactive traffic ค่อนข้างมาก

② Reliable connection-oriented

ต้องสร้างและยกเลิกการเชื่อมต่อ มีการควบคุมความผิดพลาด ลำดับ และการไหล (flow) · เหมาะกับการส่งข้อมูลที่ไม่ใช้ Transport Layer

③ Acknowledged connectionless

การให้บริการส่งและตอบรับ (ACK) แต่ไม่ต้องสร้างการเชื่อมต่อก่อน

บริการทั้งสามแบบเป็นตัวเลือกให้ผู้ใช้ตอนซื้ออุปกรณ์ — จะซื้อรุ่นที่ให้บริการสองแบบหรือทั้งหมดก็ได้ ขึ้นกับแอปพลิเคชัน

จุดที่คนพลาดบ่อย — IEEE 802.3 ใช้แบบไหน

LLC ใน IEEE 802.3 ใช้แบบ ① Unacknowledged connectionless เท่านั้น คือส่งแบบ Best-effort และ Connectionless ⇒ ถ้าไม่เกิดการชนกันของสัญญาณ จะไม่มีการส่งใหม่ แม้ข้อมูลจะสูญหายหรือผิดพลาดบนสายก็ตาม · หน้าที่ตรวจสอบและส่งใหม่จึงตกไปที่เลเยอร์ถัดไป (เช่น TCP) · คำตอบผิดที่เจอบ่อยคือ "อีเทอร์เน็ตส่งซ้ำเองเมื่อเฟรมเสีย" — ผิด อีเทอร์เน็ตทิ้งเฟรมที่เสียเฉย ๆ

แล้ว LLC ยังใช้จริงไหมทุกวันนี้ (ตามหนังสือ)

หนังสือระบุว่า ในกรณีที่ LAN ไม่ได้เชื่อมโยงกับโครงข่ายอื่น LLC จะถูกใช้ควบคุมการไหลและความผิดพลาดให้ Application Layer · แต่ในกรณีที่เชื่อมกับอินเทอร์เน็ต ซึ่งมี IP อยู่ในเลเยอร์ถัดไป การทำงานของ LLC จะไม่ได้ใช้งาน — นี่คือเหตุผลที่เฟรมที่คุณเห็นใน Wireshark ส่วนใหญ่เป็น "Ethernet II" ที่ข้าม LLC ไปเลย

14.1.2โพรโตคอล LLC

ข้อมูลพื้นฐานที่ LLC ส่งเรียกว่า protocol data unit (PDU) ประกอบด้วย 4 ฟิลด์:

ฟิลด์	ขนาด	ความหมาย
DSAP (destination service access point)	แอดเดรส 7 บิต	ระบุเครื่อง/บริการปลายทาง · บิตแรกบอกว่าเป็นผู้ใช้เดียว (Individual) หรือกลุ่มผู้ใช้ (Group)
SSAP (source service access point)	แอดเดรส 7 บิต	ระบุเครื่อง/บริการต้นทาง · บิตแรกบอกว่าเป็นเฟรมคำสั่ง (Command) หรือเฟรมตอบสนอง (Response)
Control	8 หรือ 16 บิต	บ่งชนิดของ PDU — I-frame / S-frame / U-frame
Information	ปรับขนาดได้	ข้อมูลจริง · รวมทั้ง PDU มีขนาด 46–1500 ไบต์

บิตที่	ชื่อ	ค่า 0 แปลว่า	ค่า 1 แปลว่า
1 (บิตแรกของ DSAP)	`I/G`	individual DSAP — ผู้ใช้เดียว	group DSAP — กลุ่มผู้ใช้
9 (บิตแรกของ SSAP)	`C/R`	command — เฟรมคำสั่ง	response — เฟรมตอบสนอง

ค่าตัวเลขของธงสองตัวนี้พิมพ์กำกับไว้ใต้รูปที่ 14.4 (ดูรูปท้ายหัวข้อ) — ที่เหลือคือบิตที่ 2–8 = DSAP value และบิตที่ 10–16 = SSAP value

ฟิลด์ Control บ่งชนิดของ PDU 3 แบบ ดูจากบิตแรกสองบิต:

ชนิด	เงื่อนไขบิต	ใช้ทำอะไร
I-frame (Information)	`bit 0 = 0`	ส่งข้อมูลผู้ใช้รวมถึงข้อมูลควบคุมที่เกี่ยวข้อง · มี 3 บิตหรือ 7 บิต สำหรับควบคุมการไหลและความผิดพลาด เรียกว่า `N(S)` = จำนวนเฟรมที่ส่ง และ `N(R)` = จำนวนเฟรมที่คาดว่าจะได้รับ (ใช้ตอบกลับ)
S-frame (Supervisory)	`bit 0 = 1, bit 1 = 0`	ควบคุมการส่งข้อมูลเกี่ยวกับการควบคุม เช่น flow control และความผิดพลาดใน Data Link Layer โดยใช้บิต S บ่งถึงโค้ดที่ใช้
U-frame (Unnumbered)	`bit 0 = 1, bit 1 = 1`	ใช้สำหรับการจัดการระบบ โดยใช้บิต M บ่งชนิดของ U-frame และการทำงานที่เกี่ยวข้อง

รูปที่ 14.5 ในตำราวางบิตของ Control ทั้งสามแบบเรียงให้เทียบกันได้ตรง ๆ ถอดออกมาเป็นตารางได้ดังนี้ (เลขบิตนับ 1–16 ตามที่พิมพ์ไว้ใต้รูป):

ชนิด	บิต 1–2	บิต 3–8	บิต 9	บิต 10–16
Information (I)	`0` …	`N(S)` — หมายเลขเฟรมที่ส่ง	`P/F`	`N(R)` — หมายเลขเฟรมที่คาดว่าจะได้รับ
Supervisory (S)	`1 0`	`S S 0 0 0 0` — บิต S คือโค้ดควบคุม	`P/F`	`N(R)`
Unnumbered (U)	`1 1`	`M M` · `P/F` · `M M M` — ยาว 8 บิตเท่านั้น ไม่มี N(R)

อ่านตารางนี้ยังไงให้จำได้

ไล่จากซ้ายทีละบิต: บิตแรกเป็น 0 ⇒ I-frame จบ · ถ้าเป็น 1 ค่อยดูบิตที่สอง — 0 ⇒ S-frame, 1 ⇒ U-frame · และสังเกตความยาว: I และ S ใช้ 16 บิต (เพราะต้องพก N(R) ไปด้วย) ส่วน U ใช้แค่ 8 บิต — นี่คือที่มาของคำว่า "Control ขนาด 8 หรือ 16 บิต" ในตำรา · ชื่อ Unnumbered ก็บอกอยู่แล้วว่าไม่มีหมายเลขลำดับ จึงไม่ต้องมีช่อง N(S)/N(R)

บิต P/F มีอยู่ในเฟรมทั้งสามแบบ

ทุกแบบ (I, S, U) มีบิต P/F หรือ poll/final — ถ้าส่วนแอดเดรสเป็นหมายเลขของเครื่องรับ จะหมายถึงการส่ง poll · ถ้าแอดเดรสเป็นหมายเลขของเครื่องส่ง จะหมายถึง final

จุดที่คนพลาดบ่อย — LLC ไม่มี FCS และไม่มี MAC address

ใน LLC PDU ไม่มีการตรวจสอบความผิดพลาด และไม่มีแอดเดรสของเครื่อง — ทั้งสองอย่างนี้ใช้จาก MAC Layer · ดังนั้นถ้าโจทย์ถามว่า "CRC อยู่ตรงไหน" คำตอบคือ MAC frame (ฟิลด์ FCS) ไม่ใช่ LLC · และ SAP ≠ MAC address — SAP คือบริการปลายทาง ส่วน MAC address คือเครื่องปลายทาง

ทีนี้เทียบกับรูปจริงในตำราสองรูป — animation ด้านบนไล่ทีละฟิลด์เพื่อให้เห็นหน้าที่ ส่วน รูปที่ 14.4 ให้เห็นว่าสองไบต์แรกถูกซอยเป็นบิตยังไง และ รูปที่ 14.5 ให้เห็นเฟรมทั้งสามแบบวางเทียบกันในหน้าเดียว:

โครงสร้าง LLC PDU: แถบบนมีสี่ช่องคือ DSAP 8 บิต, SSAP 8 บิต, Control 8 หรือ 16 บิต และ Information ที่ปรับเปลี่ยนได้ · ด้านล่างขยายสองไบต์แรกออกมาเป็นบิตที่ 1 ถึง 16 โดยบิตที่ 1 คือ I/G ตามด้วย DSAP value บิตที่ 2 ถึง 8 และบิตที่ 9 คือ C/R ตามด้วย SSAP value บิตที่ 10 ถึง 16 · ใต้รูปเขียนว่า I/G : 0 = individual DSAP, 1 = group DSAP และ C/R : 0 = command, 1 = response — รูปที่ 14.4 จากตำรา — โครงสร้าง LLC PDU (จุดที่ต้องสังเกต: ช่อง DSAP และ SSAP **กว้างช่องละ 8 บิต** แต่ที่เป็น "แอดเดรส" จริง ๆ มีแค่ **7 บิต** เพราะบิตแรกถูกยืมไปเป็นธง I/G และ C/R)

รูปแบบของ LLC PDU: แถบ DSAP SSAP Control Information อยู่ด้านบน แล้วขยายช่อง Control ลงมาเป็นสามแถวเทียบกัน — แถว Information ขึ้นต้นด้วยบิต 0 ตามด้วย N(S) แล้ว P/F แล้ว N(R) · แถว Supervisory ขึ้นต้นด้วย 1 0 ตามด้วย S S 0 0 0 0 แล้ว P/F แล้ว N(R) · แถว Unnumbered ขึ้นต้นด้วย 1 1 ตามด้วย M M แล้ว P/F แล้ว MMM และสั้นกว่าสองแถวบนอย่างชัดเจน · มีแถบเลขบิต 1 ถึง 16 กำกับไว้ — รูปที่ 14.5 จากตำรา — รูปแบบของ LLC PDU (จุดที่ต้องสังเกต: แถว **Unnumbered สั้นกว่าอีกสองแถวชัดเจน** เพราะจบที่บิต 8 — เป็นภาพยืนยันว่า Control เป็นได้ทั้ง 8 และ 16 บิต)

14.2MAC Frame

MAC Sublayer รับผิดชอบการส่งและรับข้อมูลจากเลเยอร์ LLC ให้มีประสิทธิภาพ ประกอบด้วยการทำซิงโครไนเซชัน, ควบคุมการถ่ายเทข้อมูล, ควบคุมข้อผิดพลาด จากผู้ใช้คนหนึ่งไปยังอีกคน และมีแอดเดรสเครื่องเพื่อใช้รับส่งข้อมูลต่อไป

ฟิลด์	ขนาด	เนื้อหา / หน้าที่
Preamble	7 ไบต์	แต่ละไบต์เป็น `10101010` ส่งซ้ำ ๆ กันเพื่อให้ภาครับทราบว่าจะมีข้อมูลตามมา และให้ภาครับซิงโครไนซ์สัญญาณนาฬิกากับภาคส่ง
SFD (Start Frame Delimiter)	1 ไบต์	`10101011` — บิต 1 ที่ติดกันสองตัวท้ายคือตัวบอกจุดเริ่มต้นของเฟรม ทำให้ภาครับเริ่มตรวจจับเฟรมที่จะตามมา
DA (Destination Address)	6 ไบต์	แอดเดรสของภาครับ · บิตแรกของ DA บอกว่าเป็นแบบ ยูนิคาสต์ (0) หรือ มัลติคาสต์ (1)
SA (Source Address)	6 ไบต์	แอดเดรสของภาคส่ง อาจเป็นเครื่องต้นทางหรือเร้าเตอร์ล่าสุดที่รับข้อมูลนี้เข้ามาแล้วส่งต่อ
Length/Type	2 ไบต์	ค่า ≤ 1500 ⇒ เป็น ความยาวของข้อมูลใน PDU (ข้อมูลใน LLC) · ค่า ≥ 1536 ⇒ เป็น Type (ประเภทของเฟรม)
Data	46–1500 ไบต์	ส่วนของข้อมูลที่มาจาก LLC
Pad	0–46 ไบต์	เติมเข้าไปเพื่อทำให้เฟรมมีขนาดอย่างต่ำ 64 ไบต์ เพื่อให้การตรวจสอบการชนกันของข้อมูลทำงานได้อย่างเหมาะสม
FCS (Frame Check Sequence)	4 ไบต์	ตรวจสอบความผิดพลาดของเฟรมด้วย CRC ขนาด 32 บิต · ตรวจสอบทั้งหมด ยกเว้น Preamble, SFD และตัว FCS เอง

Type ที่ต้องจำ — 0x0800 กับ 0x0806

เมื่อค่าในฟิลด์ Length/Type ≥ 1536 (คือ 0x0600 ขึ้นไป) ฟิลด์นี้จะไม่ได้แปลว่าความยาว แต่แปลว่า "ข้างในเป็นอะไร" — ค่าที่พบเห็นทั่วไป:

ค่า Type	เลขฐานสิบ	ข้างในคืออะไร	เจอที่ไหน
`0x0800`	2048	IPv4	เกือบทุกแพ็กเก็ตในเน็ตเวิร์กทั่วไป
`0x0806`	2054	ARP	ตอนถาม MAC address จาก IP (บทที่ 17)
`0x86dd`	34525	IPv6	เน็ตเวิร์กที่เปิด IPv6

จุดที่คนพลาดบ่อย — Length หรือ Type ดูตรงไหน

อย่าจำว่า "ฟิลด์นี้คือ Type" หรือ "ฟิลด์นี้คือ Length" — มันเป็นได้ทั้งสองอย่าง และตัวตัดสินคือค่าตัวเลขในฟิลด์นั้นเอง: ≤ 1500 ⇒ Length, ≥ 1536 ⇒ Type · เหตุผลที่แบ่งตรงนี้ได้เพราะข้อมูลยาวสุดคือ 1500 ไบต์อยู่แล้ว ค่าที่มากกว่านั้นจึงเอาไปใช้เป็นรหัสประเภทได้โดยไม่ชนกัน · (ตำราเขียนกำกับไว้ว่าขนาดที่ยาวที่สุดที่ส่งได้เป็น 1528 ไบต์ ซึ่งเป็นเลขเดียวกับที่พิมพ์ในรูปที่ 14.7 — ดูกล่องส้ม "1518 หรือ 1528 กันแน่" ท้ายหัวข้อนี้ประกอบ แต่ตัวเลขที่ใช้ตัดสิน Length vs Type คือ 1500 กับ 1536)

เฟรมยาวได้เท่าไร และทำไมต้องอย่างน้อย 64 ไบต์

เอาขนาดของฟิลด์ที่ FCS ตรวจสอบ มาบวกกัน (คือทุกฟิลด์ยกเว้น Preamble กับ SFD):

เฟรมต่ำสุด = DA 6 + SA 6 + Len/Type 2 + Data 46 + FCS 4 = 64 ไบต์
เฟรมสูงสุด = DA 6 + SA 6 + Len/Type 2 + Data 1500 + FCS 4 = 1518 ไบต์ Preamble 7 + SFD 1 ไบต์ ไม่ถูกนับ เพราะ FCS ไม่ครอบคลุมและมันคือส่วนซิงโครไนซ์ ไม่ใช่เนื้อเฟรม

ตัวเลข 46 ในฟิลด์ Data จึงไม่ได้มาลอย ๆ — มันคือ 64 − 6 − 6 − 2 − 4 = 46 พอดี ถ้าข้อมูลจริงสั้นกว่านี้ Pad จะเข้ามาเติมให้ครบ

แล้วทำไมต้อง 64 ไบต์? เพราะ CSMA/CD (บทที่ 13) ต้องการให้ผู้ส่งยังส่งอยู่ตอนที่สัญญาณชนกลับมาถึงตัวเอง ไม่งั้นจะไม่มีทางรู้ว่าเฟรมของตัวเองชน:

t_x ≥ 2 × t_prop เวลาที่ใช้ยิงเฟรมขึ้นสาย ต้องนานกว่าเวลาที่สัญญาณเดินทางไป-กลับสุดปลายสาย

ส่วนขยาย (ไม่ได้อยู่ในหนังสือ แต่ควรรู้)

64 ไบต์ = 512 บิต ที่ 10 Mbps ใช้เวลา 512 / 10×10⁶ = 51.2 µs ซึ่งเรียกว่า slot time ของ Ethernet — เป็นค่าเดียวกับ T_slot ที่ใช้ในสูตร backoff ของ Q12 · จาก t_x ≥ 2t_prop จะได้ระยะทางสูงสุดตามทฤษฎี d ≤ 4·v·L / R ⇒ ที่ 10 Mbps กับ v = 2×10⁸ m/s ได้ 5,120 เมตร (ของจริงตั้งไว้ 2,500 เมตร เผื่อ delay ของ repeater)

ทีนี้เทียบกับรูปในตำราสองรูปที่วางคู่กัน — รูปที่ 14.6 แสดงเฟรมเต็มตั้งแต่ Preamble (พร้อมวงเล็บบอกว่าสองฟิลด์แรกคือเฮดเดอร์ของ Physical Layer) ส่วน รูปที่ 14.7 ตัดสองฟิลด์นั้นออก เหลือเฉพาะช่วงที่ FCS ตรวจ แล้วใส่ตัวเลขความยาวรวมกำกับไว้ · ทั้งสองรูปวาด Pad รวมอยู่ในช่อง Data ไม่ได้แยกกล่องออกมา แต่เนื้อความในตำราแยก Pad เป็นฟิลด์ของตัวเอง เวลาวาดตอบข้อสอบให้แยกกล่อง Pad ออกมาตามเนื้อความ

แถบเฟรม IEEE 802.3 เรียงเป็นเจ็ดช่องจากซ้ายไปขวา: Preamble 7 ไบต์, SFD 1 ไบต์, Source Address 6 ไบต์, Destination Address 6 ไบต์, Length/Type 2 ไบต์, Data (ไม่มีตัวเลขกำกับ) และ CRC 4 ไบต์ · ใต้สองช่องแรกมีวงเล็บกำกับเขียนว่า เฮดเดอร์ของ Physical Layer — รูปที่ 14.6 จากตำรา — รูปแบบของ IEEE 802.3 เฟรม (จุดที่ต้องสังเกต: วงเล็บใต้ **Preamble + SFD เขียนว่า "เฮดเดอร์ของ Physical Layer"** — นี่คือเหตุผลที่ FCS ไม่ตรวจสองฟิลด์นี้ เพราะมันไม่ใช่เนื้อเฟรมของ Data Link Layer)

แถบเฟรมห้าช่อง: Source Address 6 ไบต์, Destination Address 6 ไบต์, Length/Type 2 ไบต์, Data ต่ำสุด 46 ไบต์และสูงสุดไม่เกิน 1500 ไบต์ และ CRC 4 ไบต์ · ด้านล่างมีลูกศรสองหัวพาดตลอดความกว้างเขียนว่า ความยาวต่ำสุด 64 ไบต์ และสูงสุดไม่เกิน 1528 ไบต์ — รูปที่ 14.7 จากตำรา — ความยาวต่ำสุด–สูงสุดของเฟรม (จุดที่ต้องสังเกต: รูปนี้**ตัด Preamble กับ SFD ออก** เหลือเฉพาะช่วงที่ FCS ตรวจ แล้ว**ลูกศรล่างเขียนกำกับว่า 64–1528 ไบต์** — อ่านกล่องส้มถัดไปก่อนจำตัวเลขนี้)

จุดที่คนพลาดบ่อย — 1518 หรือ 1528 กันแน่

ลองบวกตามฟิลด์ในรูปที่ 14.7 เอง:

6 (SA) + 6 (DA) + 2 (Len/Type) + 1500 (Data) + 4 (CRC) = 1518 ไบต์ ส่วนขอบล่าง: 6 + 6 + 2 + 46 + 4 = 64 ไบต์ ✓ ตรงกับที่รูปเขียนไว้

ขอบล่าง 64 ไบต์ตรงกันพอดี แต่ขอบบนบวกได้ 1518 ไม่ใช่ 1528 ตามที่พิมพ์ในรูปและในเนื้อความหัวข้อ Length/Type · เวลาสอบให้ทำแบบนี้: เขียนวิธีบวกให้ครบทุกฟิลด์แล้วสรุปเลขของตัวเอง แล้วเติมวงเล็บกำกับว่า "(ตำราหน้า 121 เขียนไว้ 1528)" — ได้คะแนนขั้นตอนแน่นอนไม่ว่าอาจารย์ยึดเลขไหน

อีกจุดที่ต้องระวังคือลำดับฟิลด์ — รูปที่ 14.6 และ 14.7 วาด Source Address ไว้ก่อน Destination Address ทั้งคู่ แต่เนื้อความในหัวข้อ 14.2 ของตำราเองไล่ฟิลด์เรียงว่า Preamble → SFD → Destination Address → Source Address → Length/Type → Data → Pad → FCS ซึ่งตรงกับมาตรฐาน IEEE 802.3 จริง (บนสายส่ง DA ออกไปก่อน เพื่อให้ผู้รับตัดสินใจได้เร็วที่สุดว่าเฟรมนี้เป็นของตนหรือไม่ โดยไม่ต้องรออ่านทั้งเฟรม) · ถ้าข้อสอบให้วาดเฟรม ให้ยึดลำดับ DA มาก่อน SA ตามเนื้อความ

สองกรณีที่ "ส่งแล้วไม่สำเร็จ" ซึ่งข้อสอบชอบถาม

ที่ผ่านมาเราไล่แต่กรณีที่เฟรมเดินทางถึงปลายทางเรียบร้อย — แต่ตำราอธิบายกรณีที่ผิดพลาดไว้ด้วย และนั่นคือจุดที่คนตอบพลาดกันมากกว่า ลองไล่เป็นตัวเลขจริงทีละกรณี

กรณีที่ 1 — FCS จับได้ว่าเฟรมผิดพลาด (บิตพลิกระหว่างทาง)

ผู้ส่งคำนวณ CRC-32 จากช่วง DA … Pad ได้ค่าหนึ่ง แล้วใส่ลงฟิลด์ FCS 4 ไบต์ ท้ายเฟรม
ระหว่างทางมีสัญญาณรบกวนทำให้บิตหนึ่งในฟิลด์ Data พลิกจาก 0 เป็น 1
ปลายทางรับเฟรมมา แล้วคำนวณ CRC-32 จาก DA … Pad ใหม่ → ได้ค่าไม่ตรงกับ FCS ที่แนบมา
เฟรมที่รับได้จะถูกกำจัดออก และจะไม่ส่งผ่านไปยัง Network Layer (ประโยคนี้คือคำตอบที่ข้อสอบต้องการเป๊ะ ๆ)
LLC ของ IEEE 802.3 เป็นแบบ unacknowledged connectionless ⇒ ไม่มีการส่งใหม่ ไม่มีการแจ้งกลับไปหาผู้ส่ง — ผู้ส่ง "เข้าใจว่าส่งสำเร็จ" ทั้งที่เฟรมหายไปแล้ว การกู้คืนเป็นหน้าที่ของเลเยอร์ถัดไป (เช่น TCP timeout)

สังเกตว่าถ้าบิตที่พลิกไปอยู่ใน Preamble หรือ SFD FCS จะจับไม่ได้เลย เพราะสองฟิลด์นี้ไม่ได้ถูกตรวจ — ผลที่ได้คือปลายทางหาจุดเริ่มเฟรมไม่เจอ แล้วทิ้งทั้งเฟรมไปเงียบ ๆ เช่นกัน

กรณีที่ 2 — เฟรมสั้นกว่า 64 ไบต์ แล้ว "ชนโดยไม่รู้ตัว"

สมมติเราส่งข้อมูลสั้น ๆ แค่ 10 ไบต์ บนอีเทอร์เน็ต 10 Mbps สายยาว 2,500 เมตร (v = 2×10⁸ m/s)

	ถ้าไม่เติม Pad (ผิด)	ถ้าเติม Pad ตามมาตรฐาน (ถูก)
ขนาดเฟรม	6+6+2+10+4 = 28 ไบต์ = 224 บิต	6+6+2+10+36 (Pad)+4 = 64 ไบต์ = 512 บิต
t_x = L·8 / R	224 / 10×10⁶ = 22.4 µs	512 / 10×10⁶ = 51.2 µs
2·t_prop = 2·(d/v)	2 × (2500 / 2×10⁸) = 2 × 12.5 µs = 25 µs
เทียบ t_x กับ 2·t_prop	22.4 < 25 ✕	51.2 ≥ 25 ✓
ผลลัพธ์	ผู้ส่งส่งจบไปแล้ว 2.6 µs ก่อนที่สัญญาณชนจะกลับมาถึง → ไม่มีทางรู้ว่าเฟรมของตัวเองชน เฟรมหายเงียบ ๆ โดยไม่มีการส่งซ้ำ	ผู้ส่งยังส่งอยู่ตอนสัญญาณชนกลับมาถึง → หยุดส่ง ยิง jam signal แล้วเข้ากระบวนการ backoff ได้ถูกต้อง

นี่คือเหตุผลทั้งหมดที่ตำราเขียนว่า Pad มีไว้ "เพื่อให้การทำงานของการตรวจสอบการชนกันของข้อมูลเป็นไปอย่างเหมาะสม" — Pad ไม่ได้มีไว้ให้เฟรมสวย แต่มีไว้ซื้อเวลาให้ CSMA/CD ตรวจจับการชนทัน

ถ้าข้อสอบสั่ง "วาดเฟรม IEEE 802.3"

วาดกล่องเรียงกัน 8 กล่อง แล้วเขียนตัวเลขขนาดใต้ทุกกล่อง — 7 · 1 · 6 · 6 · 2 · 46–1500 · 0–46 · 4 · แล้วขีดวงเล็บใต้กล่อง DA…FCS เขียนว่า 64–1518 ไบต์ (ช่วงที่ FCS ตรวจ) · การไม่เขียนขนาดใต้กล่อง = เสียคะแนนครึ่งหนึ่งของข้อ

14.3บริดจ์ (Bridge)

บริดจ์ถูกใช้แพร่หลายช่วงปี ค.ศ. 1980–1990 เพื่อเชื่อมต่อระหว่าง LAN เข้าด้วยกัน ปัจจุบันสวิตช์ได้รับความนิยมมากกว่า เพราะประสิทธิภาพดีกว่า พอร์ตมากกว่า ราคาต่อพอร์ตต่ำกว่า และใช้งานง่ายกว่า — แต่ฟังก์ชันส่วนใหญ่ของสวิตช์พัฒนามาจากบริดจ์ จึงต้องเข้าใจบริดจ์ก่อน

บริดจ์ทำงานใน Data Link Layer เพื่อควบคุมการถ่ายโอนข้อมูล ตรวจสอบข้อผิดพลาด กำหนดแอดเดรสของอุปกรณ์ และส่งข้อมูลลงตัวกลาง โดยพื้นฐานมี 3 หน้าที่:

① การเรียนรู้ (Learning)

เมื่อได้รับเฟรม บริดจ์อ่าน MAC address ของต้นทาง แล้วเทียบกับ Port address table · ถ้าไม่มี → เพิ่มแอดเดรส + หมายเลขพอร์ตลงตาราง · ถ้ามีแล้ว → ตั้งเวลาใหม่ · ข้อมูลจะอยู่ตราบเท่าที่พอร์ตนั้นยังถูกใช้งาน ถ้าเก็บนานเกินไปอาจถูกแทนที่ด้วยข้อมูลใหม่

② การส่งผ่าน (Forwarding)

ตรวจ MAC address ปลายทาง แล้วตัดสินใจจากตารางของบริดจ์ (bridge table) ที่สร้างจากการเรียนรู้ · ถ้าพบว่าปลายทางอยู่พอร์ตเดียวกับต้นทาง → ไม่ส่งต่อ · ถ้าไม่พบปลายทางในตาราง → ส่งออกทุกพอร์ต (flooding)

③ การกรอง (Filtering)

กำจัดเฟรมที่ไม่จำเป็นออกไป ตั้งเงื่อนไขได้จากส่วนหัวของเฟรมที่ส่งเข้ามา · ช่วยกำจัดบรอดคาสท์และมัลติคาสต์ที่ไม่จำเป็นต้องส่งต่อไปยังบางกลุ่มผู้ใช้

14.3.1Transparent Bridges

Transparent bridge เป็นบริดจ์ที่ง่ายที่สุดเพื่อใช้เชื่อม LAN เข้าด้วยกัน หลักการคือเริ่มจากอ่านแอดเดรสต้นทางจากเฟรมที่ถูกส่งเข้ามา

ส่วน learning logic สร้าง forwarding table จากเน็ตเวิร์ก โดยบันทึกคู่ของ MAC address + พอร์ต
ตารางนี้บันทึกการจับคู่ได้จำนวนมาก เพื่อรองรับการเชื่อมต่อ LAN จำนวนมาก และยังเก็บแอดเดรสของฮอปถัดไปได้
ส่วน forwarding logic อ่านแอดเดรสปลายทาง แล้วพิจารณาว่าบริดจ์ที่จะส่งไปเป็นบริดจ์บนตัวเดียวกัน (local) หรืออยู่ระยะไกล (remote)

เนื่องจากข้อมูลใน forwarding table มีขนาดใหญ่และมีโอกาสเปลี่ยนแปลงตลอดเวลา บริดจ์จะสร้างตารางขึ้นโดยอัตโนมัติ — เรียกกระบวนการนี้ว่า backward learning คือเรียนรู้จาก "ผู้ส่ง" ของทุกเฟรมที่ผ่านเข้ามา ขั้นตอนเต็ม ๆ ของทุกเฟรมมีดังนี้:

อ่าน MAC address ต้นทาง แล้วเทียบกับตาราง — ถ้าไม่พบ ให้เพิ่มแอดเดรสต้นทาง + หมายเลขพอร์ตที่รับเฟรมเข้ามา
ตรวจ MAC address ปลายทาง ในตาราง
พบ → ส่งผ่านเฟรมไปยังพอร์ตที่ระบุไว้ในตาราง
พบว่าพอร์ตต้นทางกับปลายทางเป็นพอร์ตเดียวกัน → กำจัดเฟรมทิ้ง ไม่ส่งต่อ (เพราะทั้งสองอยู่ LAN เดียวกัน คุยกันเองได้อยู่แล้ว)
ไม่พบปลายทาง → ส่งออกไปทุกพอร์ต ยกเว้นพอร์ตที่รับเฟรมเข้ามา (flooding)

ตำรามีสองรูปที่มองบริดจ์คนละมุมกับ animation ด้านบน — รูปที่ 14.8 ผ่าฝาบริดจ์ออกมาดูว่าข้างในมีบล็อกอะไรบ้าง ส่วน รูปที่ 14.9 เป็นผังการตัดสินใจ (flowchart) ของเฟรมหนึ่งเฟรมตั้งแต่เข้าจนออก ซึ่งตรงกับลิสต์ 5 ข้อด้านบนทีละกล่อง:

ผังภายในของ Transparent Bridge: กลางบนคือกล่อง ตารางตรวจสอบเพื่อทำการส่งต่อ (Forwarding table) ที่มีสองคอลัมน์ MAC address และ Port · สองข้างมีกล่องสีเขียว ส่วนการเรียนรู้ (learning logic) ที่มีลูกศรชี้เข้าตาราง · ล่างซ้ายและล่างขวาเป็นกล่อง รับ-ส่งเฟรม ที่ต่อออกไปนอกบริดจ์ทั้งสองด้าน · ตรงกลางล่างเป็นกล่องสีเหลือง Forwarding lookup logic ที่มีลูกศรชี้ขึ้นไปอ่านตารางและมีลูกศรสองทางเชื่อมกับกล่องรับ-ส่งเฟรมทั้งสองข้าง — รูปที่ 14.8 จากตำรา — โครงสร้างการทำงานภายในของ Transparent Bridge (จุดที่ต้องสังเกต: **learning logic กับ forwarding lookup logic เป็นคนละบล็อกกัน** ทั้งคู่คุยกับ forwarding table ตัวเดียวกัน — learning เป็นฝ่าย*เขียน* ส่วน lookup เป็นฝ่าย*อ่าน*)

ผังการตัดสินใจของบริดจ์: เฟรมเข้าที่พอร์ตขาเข้า แตกลูกศรไปกล่อง บันทึกแอดเดรสของต้นทางและพอร์ตขาเข้า ซึ่งเขียนลงตาราง MAC Address กับ Port · เส้นหลักลงมาที่สี่เหลี่ยมข้าวหลามตัด MAC ปลายทางอยู่ในพอร์ตขาเข้าเดียวกัน? ถ้า Yes ออกซ้ายไป กำจัดออกไป ถ้า No ลงมาที่ข้าวหลามตัดที่สอง มีพอร์ตขาออกของ MAC ปลายทาง? ถ้า No ออกซ้ายไป ส่งออกไปทุกพอร์ต ถ้า Yes ลงมาที่กล่อง ส่งต่อไปยังพอร์ตขาออก แล้วออกที่พอร์ตขาออก และจบด้วยข้อความ ทำการส่งเฟรมออกไป หากทำได้ — รูปที่ 14.9 จากตำรา — การทำงานของบริดจ์ (จุดที่ต้องสังเกต: กล่อง "บันทึกแอดเดรสของต้นทาง" อยู่**ก่อน**ข้าวหลามตัดทุกอัน — บริดจ์**เรียนรู้ก่อนเสมอ** แล้วค่อยตัดสินใจว่าจะทิ้ง จะ flood หรือจะส่งต่อ)

แปลผังรูปที่ 14.9 เป็นภาษาคน

มีทางออกอยู่ 3 ทางเท่านั้น จากผังนี้ — ① กำจัดออกไป (ปลายทางอยู่พอร์ตขาเข้าเดียวกัน) · ② ส่งออกไปทุกพอร์ต (ไม่รู้จักปลายทาง = flooding) · ③ ส่งต่อไปยังพอร์ตขาออก ที่ระบุในตาราง · ถ้าข้อสอบถามว่า "บริดจ์ทำอะไรได้บ้างเมื่อรับเฟรม" ให้ตอบสามข้อนี้ พร้อมบอกเงื่อนไขของแต่ละข้อ

Aging — ทำไมตารางไม่โตไม่หยุด

เพื่อลดขนาดตารางที่ต้องค้นหา บริดจ์จำกัดเวลาของ MAC address ในตารางได้ โดยเพิ่มตัวจับเวลาให้แต่ละแอดเดรส เมื่อเพิ่มแอดเดรสลงตารางจะกำหนดระยะเวลาจัดเก็บไว้ด้วย ซึ่งประมาณ 300 วินาที (ปรับเปลี่ยนได้) · เมื่อค่าเวลานี้เป็นศูนย์ แอดเดรสนั้นจะถูกลบออกจากตาราง

จุดที่คนพลาดบ่อย — ข้อจำกัดที่นำไปสู่ STP

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

สามกรณีที่บริดจ์ "ไม่ได้ส่งต่อแบบสวย ๆ"

ผังในรูปที่ 14.9 มีทางออกสามทาง ซึ่งมีอยู่ทางเดียวเท่านั้นที่เป็นการส่งต่อแบบตรงเป้า อีกสองทางคือกรณีที่ระบบ "ไม่รู้" หรือ "ไม่ต้องส่ง" — ตำราอธิบายไว้ครบทั้งสามทาง ลองไล่ทีละกรณีด้วยโทโพโลยีเดิม (A พอร์ต 1 · B พอร์ต 2 · C พอร์ต 3 · D พอร์ต 4)

กรณี	เกิดเมื่อไร	บริดจ์ทำอะไร	ผลที่ผู้ส่งเห็น
① ทิ้งเฟรม (filtering)	ต้นทางและปลายทางอยู่พอร์ตเดียวกัน เช่น A กับอีกเครื่องที่ต่อฮับเดียวกันบนพอร์ต 1	กำจัดเฟรมทิ้ง ไม่ส่งต่อ เพราะทั้งคู่อยู่ LAN เดียวกัน ได้ยินกันเองอยู่แล้ว	สำเร็จปกติ — ปลายทางได้รับเฟรมโดยตรงบนสายเส้นเดิม
② Flooding	ไม่พบปลายทางในตาราง เช่น เพิ่งเปิดเครื่อง หรือแอดเดรสเพิ่งหมดอายุ (aging 300 วินาที)	ส่งออกทุกพอร์ต ยกเว้นพอร์ตที่รับเข้ามา — เปลืองแบนด์วิดท์ทุกพอร์ตเพื่อหาเครื่องเดียว	สำเร็จ แต่ทุกเครื่องในเครือข่ายถูกกวน · เครื่องที่ไม่ใช่ปลายทางจะทิ้งเฟรมนั้นเอง
③ Broadcast storm	เฟรมมีแอดเดรสไม่สมบูรณ์ หรือปลายทางไม่ปรากฏ และ เครือข่ายมีเส้นทางซ้ำ (redundant paths)	ส่งต่อไปอย่างไม่หยุด จนกระทั่งถูกส่งไปยังบริดจ์ที่ต่ออยู่ทั้งหมด	ล้มเหลว — ประสิทธิภาพของระบบลดลงจนใช้งานไม่ได้

การ์ตูนลายมือเต็มหน้าจากตำรา: ช่องแรกเครื่อง 192.168.1.1 สั่งส่งของไปให้ 192.168.1.2 แต่ไม่รู้ว่ามันอยู่ตรงไหน · ช่องถัดมาข้อมูลถูกห่อในกล่องที่เขียนว่า ENCAPSULATION แล้วส่ง ARP ออกไป · ช่องกลางวาดกล่อง SWITCH ที่ยิงลูกศรกระจายออกทุกทิศทางพร้อมข้อความว่าไปทุกทางเลยลงกัน · ครึ่งล่างตัวละคร ARP ถือกล่องเดินไล่ถามทีละเครื่องว่ารู้ไหมว่า 192.168.1.2 ไหนครับ เครื่องที่ไม่ใช่บอกว่าไม่ใช่แล้วเฟรมถูก DROP ทิ้ง จนเจอเครื่องที่ใช่ซึ่งส่ง MAC Address กลับมา แล้วของถูกส่งถึงปลายทางในช่องสุดท้าย — รูปที่ 14.11 จากตำรา — flooding (การ์ตูนลายมือในตำราเล่าเส้นทางเดียวกับกรณี ② ข้างบน: ไม่รู้จักปลายทาง → สวิตช์กระจายเฟรมออกทุกพอร์ต → เครื่องที่ไม่ใช่ปลายทาง **DROP** ทิ้ง → เครื่องที่ใช่ตอบ **MAC Address** กลับมา แล้วข้อมูลจึงถูกส่งถึง)

ไล่ตัวเลขกรณีที่ ③ — ทำไม "เส้นทางซ้ำ" ถึงทำให้เครือข่ายล่ม

สมมติมี บริดจ์ 2 ตัว (BR1, BR2) เชื่อม LAN สองวงเข้าด้วยกัน ด้วยสายสองเส้น เพื่อความ redundant แล้ว A ส่งเฟรมที่บริดจ์หาปลายทางไม่เจอ ออกมา 1 เฟรม

รอบ	เกิดอะไรขึ้น	จำนวนสำเนาที่วิ่งอยู่
0	A ส่งเฟรม 1 เฟรมเข้า LAN วงซ้าย	1
1	BR1 หาปลายทางไม่เจอ → flood ข้ามไปวงขวา · BR2 ก็หาไม่เจอ → flood ข้ามไปเช่นกัน	2
2	สำเนาของ BR1 ที่โผล่ในวงขวา ถูก BR2 มองว่าเป็นเฟรมใหม่ → flood กลับมาวงซ้าย · และกลับกัน	4
3	ทำซ้ำอีกรอบ	8
n	ไม่มีอะไรหยุดมันได้ เพราะเฟรมเลเยอร์ 2 ไม่มีฟิลด์ TTL / Hop count ให้ลดลง	2ⁿ → ∞

ผลที่ตามมามีสามอย่างพร้อมกัน — แบนด์วิดท์เต็ม · ปลายทางได้เฟรมซ้ำหลายสำเนา · และ ตาราง MAC ของบริดจ์ถูกเขียนทับกลับไปกลับมา เพราะ MAC ต้นทางเดิมโผล่มาจากคนละพอร์ตสลับกันไปเรื่อย ๆ ⇒ ตารางใช้ตัดสินใจ forward ไม่ได้อีกต่อไป

จุดที่คนพลาดบ่อย — "redundant path ดีไม่ใช่เหรอ"

ในเลเยอร์ 3 (IP) การมีหลายเส้นทางเป็นเรื่องดี เพราะแพ็กเก็ต IP มี TTL คอยฆ่าตัวเองเมื่อวนนานเกินไป · แต่ในเลเยอร์ 2 เฟรมไม่มี TTL ⇒ เส้นทางซ้ำกลายเป็นกับดักทันที นี่คือเหตุผลที่ตำราสรุปว่า "โดยทั่วไปแล้วบริดจ์ไม่สามารถที่จะใช้ใน LAN ที่มีเส้นทางซ้ำ ๆ กันได้" · เราอยากได้ทั้งสองอย่าง (สายสำรอง + ไม่มีลูป) จึงต้องมีคนคอยปิดพอร์ตส่วนเกินไว้ก่อน แล้วเปิดเมื่อสายหลักพัง — คนคนนั้นคือ Spanning Tree Protocol ในบทที่ 15

ตัวอย่าง 14.1 — ไล่ตารางบริดจ์ด้วยมือ

โจทย์ — ที่เวลาเริ่มต้น ตารางของบริดจ์ว่างเปล่า จากนั้น (1) สเตชัน A (ต่อพอร์ต 1) ส่งข้อมูลไปหา C (2) สเตชัน C (ต่อพอร์ต 3) ตอบกลับไปหา A · จงแสดงตารางของบริดจ์ในแต่ละขั้น

ลองไล่เองก่อน แล้วค่อยกดดูเฉลย

(a) เริ่มต้น — ตารางว่าง ไม่รู้จักใครเลย

(b) A ส่งเฟรม — บริดจ์อ่าน SA = A แล้วเก็บคู่ A → พอร์ต 1 ลงตาราง

(c) หาปลายทาง C ไม่เจอ — เพราะยังไม่เคยเห็น C ส่งอะไรเลย ⇒ flooding ออกทุกพอร์ต (ยกเว้นพอร์ต 1 ที่รับเข้ามา)

(d) C ตอบกลับ A — C ได้รับเฟรมและพบว่า MAC ตรงกับของตน จึงตอบกลับ ⇒ บริดจ์บันทึก C → พอร์ต 3 · และคราวนี้หา A เจอในตารางแล้ว จึงส่งออกเฉพาะพอร์ต 1 ไม่ flood

ขั้น	MAC Address	พอร์ต
(a) เริ่มต้น	— ว่าง —
(b) A ส่ง	`A`	1
(d) C ตอบ	`A`	1
(d) C ตอบ	`C`	3

บทเรียนสำคัญ: บริดจ์เรียนรู้จาก SA (ต้นทาง) เสมอ ไม่เคยเรียนรู้จาก DA — เพราะ SA คือหลักฐานที่พิสูจน์แล้วว่า "เครื่องนี้อยู่ทางพอร์ตนี้จริง" ส่วน DA เป็นแค่ความตั้งใจของผู้ส่ง ยังไม่ใช่ข้อเท็จจริง

สี่ภาพย่อย (a) ถึง (d) ของบริดจ์ที่มีสามพอร์ต ต่อกับ A ที่พอร์ต 1, B ที่พอร์ต 2 และ C ที่พอร์ต 3 พร้อมตาราง MAC Address / Interface / TTL ใต้ภาพ · (a) เฟรมจาก A ระบุ Source 00:02:37:17:0D:50 และ Dest 00:13:00:E1:11:11 ตารางยังว่าง · (b) เฟรมเข้าถึงบริดจ์แล้ว ตารางมีบรรทัดเดียวคือ 00:02:37:17:0D:50 อินเทอร์เฟซ 1 TTL 60 · (c) ลูกศรประสีส้มยิงออกทั้งพอร์ต 2 และพอร์ต 3 พร้อมกัน คือ flooding และตารางยังมีบรรทัดเดียว · (d) C ตอบกลับ เฟรมสลับ Source กับ Destination ตารางมีสองบรรทัดคือ 00:02:37:17:0D:50 อินเทอร์เฟซ 1 และ 00:13:00:E1:11:11 อินเทอร์เฟซ 3 TTL 60 ทั้งคู่ — รูปที่ 14.10 จากตำรา — แสดงขั้นตอนการทำงานของ Transparent Bridge (จุดที่ต้องสังเกต: ในภาพ (c) ลูกศรออก**สองพอร์ตพร้อมกัน** คือ flooding และในภาพ (d) ตารางมีคอลัมน์ **TTL = 60** ซึ่งคือตัวจับเวลา aging ของแต่ละแอดเดรส)

ในเฉลยเราเรียกว่า	ค่าจริงที่พิมพ์ในรูปที่ 14.10	พอร์ต (Interface)	TTL ในรูป
สเตชัน A	`00:02:37:17:0D:50`	1	60
สเตชัน C	`00:13:00:E1:11:11`	3	60

คอลัมน์ TTL ในรูปคือตัวจับเวลา aging ที่พูดถึงในกล่องด้านบน — ตำราระบุค่าทั่วไปไว้ที่ ประมาณ 300 วินาที (ปรับเปลี่ยนได้) ส่วนเลข 60 ในรูปเป็นค่าที่ตั้งไว้ในตัวอย่างนั้น

ต่อจากตัวอย่าง 14.1 — ลองคิดกรณีที่ "ไม่สำเร็จ" ต่ออีกสองอัน

(e) B ส่งหา A ทันทีหลังจาก (d) — บริดจ์เรียนรู้ B → พอร์ต 2 จาก SA ก่อน แล้วหา A เจอในตาราง ⇒ ส่งออกพอร์ต 1 พอร์ตเดียว · C ไม่ได้รับเฟรมนี้เลย ซึ่งเป็นสิ่งที่ถูกต้อง (ฮับจะส่งให้ทุกคน แต่บริดจ์ไม่)
(f) เงียบไป 300 วินาทีแล้ว A ส่งหา C ใหม่ — แอดเดรสของ C หมดอายุแล้ว ⇒ บริดจ์หา C ไม่เจออีกครั้ง ⇒ กลับไป flooding ใหม่ ทั้งที่เพิ่งเรียนรู้ไปเมื่อกี้ · นี่คือราคาที่ต้องจ่ายของ aging — ตารางไม่โตไม่หยุดก็จริง แต่แลกมาด้วยการ flood ซ้ำเป็นระยะ

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

เฟรมอีเทอร์เน็ตมีค่าในฟิลด์ Length/Type เป็น 0x0806 แปลว่าอะไร

0x0806 = 2054 ฐานสิบ ซึ่ง ≥ 1536 จึงถูกตีความเป็น Type ไม่ใช่ Length · และ Type 0x0806 คือ ARP (0x0800 = IPv4, 0x86dd = IPv6) · ถ้าตอบข้อแรกแปลว่าลืมกฎ 1500/1536 — ข้อมูลใน Data ยาวได้สูงสุดแค่ 1500 ไบต์อยู่แล้ว

FCS ของอีเทอร์เน็ตใช้อะไร และตรวจสอบส่วนไหนของเฟรม

อีเทอร์เน็ตใช้ CRC ขนาด 32 บิต (4 ไบต์) และตรวจทั้งหมดยกเว้น Preamble, SFD และ FCS เอง · เหตุผลที่ไม่ตรวจ Preamble/SFD เพราะทั้งคู่เป็นแค่ส่วนซิงโครไนซ์นาฬิกา ไม่ใช่เนื้อข้อมูล · เมื่อปลายทางตรวจแล้วพบความผิดพลาด เฟรมจะถูกกำจัดออก และไม่ส่งผ่านไปยัง Network Layer

บริดจ์ได้รับเฟรมที่พอร์ต 2 โดยที่ปลายทางของเฟรมไม่มีอยู่ในตาราง บริดจ์จะทำอย่างไร

Flooding — ส่งออกทุกพอร์ตยกเว้นพอร์ตที่รับเฟรมเข้ามา เพราะปลายทางแน่นอนว่าไม่ได้อยู่ทางพอร์ตนั้น (ไม่งั้นเฟรมจะไม่ต้องผ่านบริดจ์) · การส่งกลับออกพอร์ตเดิมคือสิ่งที่ทำให้เกิดลูปและ broadcast storm

ทำไมอีเทอร์เน็ตจึงกำหนดขนาดเฟรมต่ำสุดไว้ที่ 64 ไบต์

Pad มีไว้ "ทำให้ข้อมูลมีขนาดอย่างต่ำ 64 ไบต์ เพื่อให้การทำงานของการตรวจสอบการชนกันของข้อมูลเป็นไปอย่างเหมาะสม" · ในเชิงสูตรคือต้องได้ t_x ≥ 2t_prop — ถ้าเฟรมสั้นกว่านี้ ผู้ส่งอาจส่งจบไปแล้วก่อนที่สัญญาณชนจะเดินทางกลับมาถึง ทำให้ ไม่มีทางรู้ว่าเฟรมของตัวเองชน

เฟรมอีเทอร์เน็ตถูกรบกวนจนบิตหนึ่งใน Data พลิก ปลายทางคำนวณ CRC แล้วไม่ตรงกับ FCS จะเกิดอะไรขึ้นต่อ

CRC-32 เป็นการ ตรวจจับ (detect) ไม่ใช่การ แก้ไข (correct) · ตำราเขียนไว้ตรง ๆ ว่า "หากมีการตรวจสอบว่ามีความผิดพลาดขึ้น เฟรมที่รับได้จะถูกกำจัดออก และจะไม่ส่งผ่านไปยัง Network Layer" · และเพราะ LLC ของ 802.3 เป็นแบบ unacknowledged connectionless จึงไม่มีทั้ง ACK และ NAK ⇒ ไม่มีการส่งใหม่ในเลเยอร์นี้ ผู้ส่งไม่รู้ตัวเลยว่าเฟรมหาย ต้องให้เลเยอร์บน (เช่น TCP) เป็นคนจับได้เอง

การ์ดแลนตัวหนึ่งถูกดัดแปลงให้ "ไม่เติม Pad" แล้วยิงเฟรมขนาด 28 ไบต์ออกบนสาย 10 Mbps ยาว 2,500 เมตร (v = 2×10⁸ m/s) ผลเสียที่ตรงกับเหตุผลของกฎ 64 ไบต์คืออะไร

28 ไบต์ = 224 บิต ⇒ t_x = 224 / 10×10⁶ = 22.4 µs · t_prop = 2500 / 2×10⁸ = 12.5 µs ⇒ 2·t_prop = 25 µs · เนื่องจาก 22.4 < 25 ผู้ส่งจึงส่งจบไปก่อน 2.6 µs แล้วเลิกฟังสาย ⇒ ไม่รู้ว่าเฟรมของตัวเองชน และเฟรมหายไปเงียบ ๆ · ถ้าเติม Pad ให้ครบ 64 ไบต์ จะได้ t_x = 51.2 µs ≥ 25 µs ⇒ ตรวจจับได้ · นี่คือประโยคในตำราที่ว่า Pad มีไว้ "เพื่อให้การตรวจสอบการชนกันของข้อมูลเป็นไปอย่างเหมาะสม"

เก็บก่อนออกจากบทนี้

เฟรม 802.3 = 8 ฟิลด์ · 7 · 1 · 6 · 6 · 2 · 46–1500 · 0–46 · 4 ไบต์ · ช่วงที่ FCS ตรวจ = 64–1518 ไบต์
Length/Type: ≤1500 = Length · ≥1536 = Type · 0x0800=IPv4, 0x0806=ARP, 0x86dd=IPv6
FCS = CRC-32 ตรวจทุกอย่างยกเว้น Preamble, SFD, FCS · เสียแล้วทิ้ง ไม่ส่งใหม่
64 ไบต์ต่ำสุด ⟵ t_x ≥ 2t_prop ⟵ CSMA/CD ต้องตรวจจับการชนได้
Data Link แยกเป็น LLC (แชร์ทุก LAN, ให้บริการ 3 แบบ, 802.3 ใช้แบบ unacknowledged connectionless) และ MAC (แอดเดรส + FCS)
บริดจ์: Learning จาก SA · Forwarding จาก DA · ไม่รู้จักปลายทางก็ Flooding · พอร์ตเดียวกันก็ทิ้ง · aging ~300 วินาที · เส้นทางซ้ำ ⇒ broadcast storm ⇒ ต้องใช้ STP
กรณีที่ผิดพลาดที่ต้องตอบให้ได้: ① CRC ไม่ตรง ⇒ ทิ้งเฟรม ไม่ส่งขึ้น Network Layer และไม่ส่งใหม่ · ② เฟรมสั้นกว่า 64 ไบต์ ⇒ t_x < 2t_prop ⇒ ตรวจจับการชนไม่ได้ · ③ ปลายทางไม่ปรากฏ + เส้นทางซ้ำ ⇒ broadcast storm (สำเนา 2ⁿ)
ทางออกของบริดจ์มี 3 ทางเท่านั้น ตามผังรูปที่ 14.9: กำจัดทิ้ง / ส่งออกทุกพอร์ต / ส่งต่อพอร์ตที่ระบุในตาราง