เรามีระบบที่ประสบปัญหาขัดข้องในการสื่อสารบนเครือข่ายกิกะบิตอีเทอร์เน็ต ปริมาณการรับส่งข้อมูลบนเครือข่ายนั้นทำให้เครือข่าย 100Mb เครียดเล็กน้อย แต่มีสวิตช์กิกะบิตและ NIC และสายเคเบิลอยู่ทั่ว - หรือดังนั้นฉันจึงได้รับคำบอกจากลูกค้าที่สร้างเครือข่ายที่เรากำลังเชื่อมต่ออยู่
เราเสียบแล็ปท็อปที่ใช้ Wireshark ผ่านฮับ 100baseT และพบว่ามีรายงานแพ็กเก็ต "Ethernet II" จำนวนมาก โดยที่ข้อมูลดิบเมื่อแสดงเป็น ASCII โดยทั่วไปจะมีลักษณะดังนี้:
ปู้วววววววววววววว
แน่นอนฉันตั้งชื่อปัญหานี้ทันทีว่า "เครือข่าย PUU" และหัวเราะคิกคักมากมายตามมาเราทุกคนอายุประมาณสี่สิบเศษ แต่ฉันเดาว่าพวกเราบางคนไม่เคยเติบโต (รู้สึกผิด!)
อย่างไรก็ตาม ที่จริงจังกว่านั้นคือแพ็กเก็ตอื่นๆ ที่ถูกต้องสมบูรณ์ถูกข้อมูลนี้เสียหาย ส่วนหัว IPv4 ถูกแทนที่ด้วยไบต์ ยู ไบต์รวมทั้งมีข้อมูลเสียหายซึ่งจะทำให้ซอฟต์แวร์ปฏิเสธข้อมูลแม้ว่าการตรวจสอบ IP จะไม่ล้มเหลวก็ตาม เราค่อนข้างแน่ใจว่าข้อมูลนี้ที่แพร่กระจายไปยังเครือข่ายทำให้การสื่อสารขัดข้อง สิ่งที่เราไม่รู้ว่ามันอาจจะมาจากไหน
มีใครเคยเห็นสิ่งนี้เกิดขึ้นมาก่อนหรือไม่? คุณแก้มันหรือยัง? คุณรู้หรือไม่ว่ามันมาจากไหน?
====แก้ไข====
เพิ่มการกล่าวถึงฮับในคำอธิบายดั้งเดิม เนื่องจากพิจารณาจากความคิดเห็นด้านล่าง มันเป็นแหล่งที่น่าจะเกิดความเสียหายมากที่สุด! เครื่องมือที่เราใช้ในการค้นหาปัญหาเครือข่ายดูเหมือนจะเพิ่มปัญหาเครือข่ายใหม่ที่แย่กว่าเดิม
อย่างไรก็ตาม ที่จริงจังกว่านั้นคือแพ็กเก็ตอื่นๆ ที่ถูกต้องสมบูรณ์ถูกข้อมูลนี้เสียหาย ส่วนหัวของ IPv4 ถูกแทนที่ด้วยไบต์ U รวมถึงข้อมูลเสียหายซึ่งจะทำให้ซอฟต์แวร์ปฏิเสธข้อมูล แม้ว่าการตรวจสอบ IP จะไม่ล้มเหลวก็ตาม
น่าแปลกใจที่เพียงแค่สลับบิต (ยู เป็น ASCII 0x55 หรือ 01010101b) จริง ๆ แล้วประกอบด้วยเฟรมอีเธอร์เน็ตที่ถูกต้องหรือแม้แต่แพ็กเก็ต IP ที่ถูกต้องหากความเสียหายนี้คืบคลานเข้าสู่เฟรม/แพ็กเก็ตส่วนใหญ่ที่ไม่บุบสลายเช่นกัน อาจเกิดจาก - เป็นไปได้มากว่า - สวิตช์ผิดพลาด (หน่วยความจำบัฟเฟอร์ไม่ดี) หรือโฮสต์ผิดพลาด (NIC หรือ RAM)
หากข้อมูลเฟรมเสียหายในการขนส่งบนสายเคเบิล FCS มีโอกาสอย่างมากที่จะล้มเหลวในการตรวจสอบ ทำให้สวิตช์ถัดไปทิ้งเฟรมนั้น อย่างไรก็ตาม หากเฟรมดังกล่าวถูกส่งผ่านเครือข่ายด้วย FCS ที่ถูกต้อง เฟรมนั้นจะต้องเสียหาย ก่อน มีการคำนวณ FCS ซึ่งกำหนดสวิตช์หรือโฮสต์ที่มีข้อบกพร่อง
คุณจะต้องตรวจสอบย้อนกลับการเข้าชมนั้น หากที่อยู่ MAC ต้นทางไม่ถูกต้องหรือไม่สามารถตรวจสอบได้บนสวิตช์ระดับกลาง (ไม่มีการจัดการ) คุณจะต้องติดตามเส้นทางของคุณกลับไปตามสายเคเบิล
ฟังดูเหมือนคุณมีอุปกรณ์ (อาจเป็นสวิตช์ความเร็ว 100 Mb/s) อยู่ที่ไหนสักแห่งที่ไม่สามารถจัดการกับทราฟฟิกโฟลว์ได้ และเริ่มสร้างความเสียหายให้กับแพ็กเก็ตเมื่อบัฟเฟอร์ภายในล้น
(หรือเพียงแค่มี RAM ที่ไม่ดี)
ไม่สังเกตว่ามีแพ็กเก็ตที่เสียหายและยินดีที่จะส่งข้อมูลใหม่อีกครั้งด้วยเช็คซัมใหม่ที่คำนวณใหม่ดังนั้นแพ็กเก็ตที่ไม่ถูกต้องจึงได้รับการยอมรับจากสวิตช์อื่นๆ (การตรวจสอบผลรวมนั้นดี สวิตช์ไม่สนใจว่าเนื้อหานั้นไม่มีเหตุผล) และส่งต่อผ่านเครือข่ายทั้งหมด
มันแย่กว่านั้นจริง ๆ :
พิจารณาวิธีที่สวิตช์เรียนรู้ว่าอุปกรณ์ใด (ที่อยู่ mac) อยู่หลังพอร์ตใด แพ็คเก็ตใด ๆ ที่กำหนดไว้สำหรับที่อยู่ mac ซึ่งสวิตช์ยังไม่เรียนรู้จะถูกน้ำท่วมไปยังพอร์ตสวิตช์ทั้งหมด (ยกเว้นพอร์ตที่มาจาก) สิ่งนี้จะเปลี่ยนแพ็กเก็ตสำหรับที่อยู่ mac ที่ไม่ได้เรียนรู้อย่างมีประสิทธิภาพเป็นการออกอากาศชั่วคราว
เนื่องจากสวิตช์ของคุณจะไม่มีวันเรียนรู้ที่อยู่ mac เหล่านี้ (ท้ายที่สุดแล้วพวกมันเสียหาย ไม่ใช่ที่อยู่ mac จริง) พวกมันทั้งหมดจะถูกปฏิบัติเหมือนการออกอากาศ...
สิ่งนี้จะทำให้เครือข่ายทั้งหมดท่วมท้นไปด้วยแพ็กเก็ตที่ไม่สามารถส่งมอบได้
(และโปรดทราบว่าการบรรเทาผลกระทบของ Broadcast-storm ตามปกติใช้ไม่ได้ในกรณีนี้ การดำเนินการนี้จะกระทำกับแพ็กเก็ตการแพร่ภาพ REAL เท่านั้น ไม่ใช่กับการเรียนรู้ที่ท่วมท้นเหล่านี้)
วิธีเดียวที่จะแก้ไขปัญหานี้คือปิดสวิตช์ทีละ 1 ตัวและดูว่าปัญหานั้นหมดไปหรือไม่ หากคุณสามารถจำกัดให้แคบลงได้ถึง 1 สวิตช์ มันจะเป็นสวิตช์ตัวนั้นหรืออุปกรณ์ที่เชื่อมต่ออยู่ด้านหลังสวิตช์นั้น
ความแตกต่างระหว่างฮับและสวิตช์คือเมื่อสวิตช์เกิดการชนกัน มันจะโยนแพ็กเก็ตที่สองออกไป หรือจัดเก็บแล้วส่งต่อเมื่อแพ็กเก็ตแรกทำงานเสร็จ โดยที่ฮับจะยอมให้การชนเกิดขึ้นอย่างสนุกสนานและเพียงแค่แทนที่เนื้อหาของแพ็กเก็ตด้วย 10101... เพื่อระบุว่าเป็นการชนกันและส่งต่อไปจนกว่าแพ็กเก็ตทั้งสองจะเสร็จสิ้น
วิธีแก้ไขที่นี่คือการกำจัดฮับเนื่องจากล้าสมัย พวกเขาหยุดสร้างฮับก่อนที่จะมี 1G ดังนั้นฮับจะต้องมีขนาด 100M หรือช้ากว่านั้น มาตรฐานเครือข่าย 1G ไม่รองรับฮับ
สำหรับประวัติเล็กน้อย ก่อนที่จะมีฮับ มีผู้ทำซ้ำ ข้อแตกต่างระหว่าง repeater และฮับคือ repeater จะรับสัญญาณอะนาล็อก ทำความสะอาดกลับเป็นคลื่นสี่เหลี่ยมเล็กน้อย จากนั้นส่งสัญญาณใหม่ โดยที่ฮับจะดูสิ่งที่อยู่ในแพ็กเก็ตเล็กน้อยและพยายาม ตรวจสอบให้แน่ใจว่าแพ็คเก็ตมีรูปแบบที่ดี อย่างไรก็ตาม ไม่มีใครทำอะไรเพื่อแก้ไขการชนกัน พวกเขาแค่ปล่อยให้มันเกิดขึ้น ตัวทำซ้ำและฮับมาจากด้านหลังเมื่ออีเธอร์เน็ตได้รับการพิจารณาว่าเป็นบัสที่ไม่มีบัฟเฟอร์และมีเพียงอุปกรณ์เดียวในเครือข่ายเท่านั้นที่สามารถพูดได้ในแต่ละครั้ง เมื่ออีเธอร์เน็ตเป็นทรูบัส (10base2 และ 10base5) ในการเริ่มแพ็กเก็ต คุณต้องส่งบิตเริ่มต้น (10101...) จนกระทั่งบิตแรกไปถึงปลายสุดของเครือข่าย และหากไม่มีใครรบกวนคุณในระหว่างนั้น จากนั้นคุณดำเนินการต่อแพ็กเก็ตของคุณ หากคุณถูกขัดจังหวะ คุณจะเกิดการปะทะกันและทั้งสองฝ่ายถอยกลับและพยายามอีกครั้งในเวลาสุ่มในภายหลัง หากฝ่ายใดฝ่ายหนึ่งไม่เลิกรากัน ฮับของคุณกำลังเปลี่ยนการชนกันในช่วงท้ายของคุณให้เป็นบิตเริ่มต้นทั้งหมด อาจมีบางอย่างในเส้นทางที่ไม่รู้จักแพ็กเก็ตเป็นการชนกันในช่วงหลัง และแทนที่จะปล่อยให้มันกลับเป็นแพ็กเก็ตที่ถูกต้อง หรือผู้ดมกลิ่นแพ็คเก็ตที่สำส่อนของคุณเห็นแพ็คเก็ตที่ไม่ถูกต้องรวมถึงแพ็คเก็ตที่ถูกต้อง
เปรียบเทียบสิ่งนี้กับสวิตช์ ซึ่งไม่เพียงแต่แก้ไขการชนกันเท่านั้น แต่ยังสามารถรองรับฟูลดูเพล็กซ์ ซึ่งแพ็กเก็ตจะถูกส่งในขณะที่รับแพ็กเก็ตอื่น มาตรฐาน 100M รองรับสวิตช์ที่ทั้งรองรับและไม่รองรับฟูลดูเพล็กซ์ และนี่คือการเจรจาระหว่างอุปกรณ์เมื่อเสียบสายเคเบิล มาตรฐานอีเธอร์เน็ต 1G กำหนดให้อุปกรณ์ทั้งหมดรองรับฟูลดูเพล็กซ์ ดังนั้นจึงไม่อนุญาตให้ใช้ฮับในการเชื่อมต่อ 1G ดังนั้นจึงไม่มีฮับ 1G
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
