ในการจัดการสวิตช์อีเทอร์เน็ตอุตสาหกรรมเลเยอร์ 3 ควรแยกระหว่าง “สามารถจัดการอุปกรณ์ได้หรือไม่” กับ “บริการได้รับการส่งต่ออย่างถูกต้องหรือไม่” การเข้าสู่ระบบผ่านหน้าเว็บได้หมายความเพียงว่าเส้นทางจัดการนี้เข้าถึงได้ ไม่สามารถพิสูจน์ได้ว่า VLAN เส้นทาง เน็กซ์ฮอป และกฎการเข้าถึงทั้งหมดเป็นปกติ การแก้ไขปัญหาควรรวบรวมหลักฐานตามเส้นทางจริงของบริการ แล้วจึงเปลี่ยนแปลงในขอบเขตจำกัดและสามารถย้อนกลับได้ แทนที่จะเริ่มระบบอุปกรณ์ใหม่ทุกครั้งที่เชื่อมต่อไม่ได้
1. การเข้าถึงเพื่อจัดการและข้อมูลบริการใช้เส้นทางต่างกัน
เมื่อคอมพิวเตอร์จัดการเข้าถึงที่อยู่จัดการของสวิตช์ จุดปลายทางของข้อมูลคือบริการจัดการของอุปกรณ์เอง แต่เมื่อเทอร์มินัลภาคสนามเข้าถึงเซิร์ฟเวอร์ในซับเน็ตอื่น อุปกรณ์ต้องส่งต่อข้อมูลออกไป ทั้งสองกรณีอาจผ่าน VLAN กฎ และอินเทอร์เฟซที่ต่างกัน การที่ CPU ตอบสนองคำขอจัดการได้ไม่ได้หมายความว่าขาออกของบริการเป็นปกติ และการเข้าถึงเพื่อจัดการหยุดชะงักก็ไม่ได้หมายความว่าการส่งต่อด้วยฮาร์ดแวร์ทั้งหมดหยุดลงพร้อมกันเสมอไป
ขั้นแรกให้ยืนยันว่าข้อขัดข้องเกิดกับบริการใดบริการหนึ่ง ซับเน็ตใดซับเน็ตหนึ่ง หรือทั้งไซต์ พร้อมบันทึกต้นทาง ปลายทาง เวลาที่เกิด และเกิดอย่างต่อเนื่องหรือไม่ อย่าสรุปอาการเพียงว่า “เครือข่ายล่ม” ให้แบ่งสิทธิ์ของบัญชีจัดการเพื่อหลีกเลี่ยงหลายคนแก้ไขการตั้งค่าเดียวกันในเวลาเดียวกัน เลือกใช้วิธีจัดการที่ปลอดภัยซึ่งรุ่นที่ส่งมอบรองรับเป็นอันดับแรก และอย่าเปิดให้เครือข่ายที่ไม่น่าเชื่อถือเข้าถึงระยะไกลแบบข้อความล้วน
2. หากการสื่อสารข้ามซับเน็ตล้มเหลว ให้ตรวจสอบสถานะการเข้าถึงก่อน
เทอร์มินัลต้องมีที่อยู่ มาสก์ และเกตเวย์ที่ถูกต้อง และพอร์ตเชื่อมต่อต้องนำทราฟฟิกเข้าสู่ขอบเขตเลเยอร์ 2 ที่ถูกต้อง อินเทอร์เฟซเลเยอร์ 3 ที่เกี่ยวข้องต้องอยู่ในสถานะใช้งานได้ และอุปกรณ์ต้องมีเส้นทางที่ตรงกับปลายทางด้วย หากไม่เป็นไปตามเงื่อนไขพื้นฐานเหล่านี้ การเปลี่ยนลำดับความสำคัญของคิวหรือเปิดฟังก์ชันจัดการเพิ่มเติมจะไม่แก้ปัญหา
หลังจากตารางเส้นทางมีเส้นทางไปยังปลายทางแล้ว ยังต้องตรวจสอบการแก้ไขข้อมูลเน็กซ์ฮอปและขาออกด้วย เน็กซ์ฮอปคืออุปกรณ์เพื่อนบ้านที่ควรรับแพ็กเก็ตต่อในขณะนั้น ไม่จำเป็นต้องเป็นเซิร์ฟเวอร์ปลายทางเสมอไป โดย IPv4 มักใช้ ARP เพื่อสร้างความสัมพันธ์ระหว่าง IP กับ MAC ของเพื่อนบ้าน เมื่อการแก้ไขข้อมูลล้มเหลว อาจต้องตรวจสอบลิงก์ภายในและการตั้งค่า และไม่ควรเพิ่มเส้นทางเริ่มต้นอีกเส้นทันที เพราะจะบดบังอาการให้กลายเป็นปัญหาเส้นทางที่ซับซ้อนขึ้น
เทียบขาเข้า เส้นทางไปยังปลายทาง เน็กซ์ฮอป กฎการเข้าถึง และสถานะขาออกให้อยู่ในช่วงเวลาเดียวกัน จากนั้นตรวจสอบเส้นทางขากลับของเซิร์ฟเวอร์ กฎควบคุมการเข้าถึงทั่วไปอาจอนุญาตเพียงทิศทางเดียว และระบบป้องกันของเทอร์มินัลหรือเซิร์ฟเวอร์เองก็อาจปฏิเสธคำขอได้เช่นกัน การสงสัยว่าสวิตช์ขัดข้องต้องมีหลักฐานสนับสนุน อย่าสรุปจากการหมดเวลารอของแอปพลิเคชันเพียงครั้งเดียว
3. ดูการเปลี่ยนแปลงของตัวนับ ไม่ใช่เพียงยอดสะสม
สถิติพอร์ตมักเก็บจำนวนไบต์ แพ็กเก็ต และจำนวนข้อผิดพลาดหรือการทิ้งข้อมูลประเภทต่าง ๆ แบบสะสม การเปรียบเทียบการเปลี่ยนแปลงระหว่างเวลาสุ่มตัวอย่างสองจุดช่วยอธิบายสิ่งที่เกิดขึ้นระหว่างข้อขัดข้องได้ดีกว่า จำนวนข้อผิดพลาดสะสมที่มากอาจเกิดขึ้นเมื่อนานมาแล้ว ขณะที่ข้อผิดพลาดจำนวนน้อยซึ่งยังเพิ่มขึ้นในปัจจุบันอาจควรได้รับความสนใจมากกว่า ต้องเทียบดัชนีอินเทอร์เฟซ พอร์ตจริง และทิศทางการวัดให้ตรงกันก่อน อย่าเปรียบเทียบค่าจากคนละพอร์ต
ในตัวอย่างเพื่อการเรียนรู้ จำนวนไบต์ของขาออกเดียวกันเพิ่มขึ้น 125,000,000 ไบต์ภายใน 10 วินาที นำผลต่างคูณด้วย 8 แล้วหารด้วย 10 จะได้อัตราเฉลี่ยประมาณ 100 Mbit/s ค่านี้เป็นค่าเฉลี่ยตลอดช่วงเวลาดังกล่าว ไม่ใช่ค่าสูงสุด และไม่เท่ากับอัตรารับส่งข้อมูลที่ใช้งานได้จริงของแอปพลิเคชัน หากอุปกรณ์เริ่มระบบใหม่ มีการล้างตัวนับ หรือเกิดความไม่ต่อเนื่องของตัวนับ จะนำผลต่างนี้มาใช้เป็นอัตราจริงโดยตรงไม่ได้ สำหรับพอร์ตความเร็วสูง ควรตรวจสอบความกว้างบิตของตัวนับและวิธีจัดการของเครื่องมือด้วย
4. แยกแยะข้อผิดพลาด การทิ้งข้อมูล และการหมดเวลารอของแอปพลิเคชัน
สาเหตุของข้อผิดพลาดในการรับข้อมูลของลิงก์กับการทิ้งข้อมูลขาออกไม่เหมือนกัน อย่างแรกอาจเกี่ยวข้องกับการส่งสัญญาณทางกายภาพ อินเทอร์เฟซ หรือเฟรม ส่วนอย่างหลังอาจเกี่ยวข้องกับความแออัด กฎ ทรัพยากร หรือนิยามสถิติเฉพาะรุ่นด้วย ให้อ่านนิยามของตัวนับแต่ละรายการก่อน แล้วจึงวิเคราะห์ร่วมกับข้อมูลโมดูลออปติคัล อัตราของพอร์ต คิว และบันทึกเหตุการณ์ ไม่สามารถตัดสินโดยอัตโนมัติว่าสายเสียเพียงเพราะเห็น “การทิ้งข้อมูล” หนึ่งครั้ง
อัตราการใช้งานพอร์ตเฉลี่ยที่ต่ำก็ไม่สามารถพิสูจน์ได้ว่าไม่มีการเข้าคิวจากทราฟฟิกพุ่งสูง เมื่อจำเป็นและได้รับอนุญาต ให้เพิ่มความถี่การสุ่มตัวอย่างหรือใช้การจับแพ็กเก็ตที่เหมาะสม แต่ทราฟฟิกที่คัดลอกผ่านการทำพอร์ตมิเรอร์เพื่อสังเกตการณ์ก็มีข้อจำกัดด้านความจุและขอบเขตการเลือกเช่นกัน หากพอร์ตมิเรอร์จับแพ็กเก็ตไม่ได้ อาจเป็นเพราะการทำมิเรอร์เองเก็บข้อมูลไม่ครบ หากไม่มีการตรวจสอบไขว้ จะยืนยันไม่ได้ว่าบริการเดิมไม่ได้ส่งข้อมูลใด ๆ
5. ฟังก์ชันจัดการของ Feichang Technology กลายเป็นหลักฐานการบำรุงรักษาได้อย่างไร
เฟยช่าง เทคโนโลยี สวิตช์อุตสาหกรรมแบบจัดการได้ชนิดติดราง 10G พอร์ตไฟเบอร์ 4 พอร์ตและพอร์ตทองแดง 8 พอร์ต เลเยอร์ 3 รายละเอียดระบุการเข้าถึงเพื่อจัดการ สถิติพอร์ต บันทึกเหตุการณ์ ข้อมูลโมดูลออปติคัล และฟังก์ชันเลเยอร์ 3 ที่เกี่ยวข้อง ซึ่งสามารถใช้จัดทำบันทึกการบำรุงรักษาเกี่ยวกับสถานะอุปกรณ์และเส้นทางบริการได้ ฟิลด์ที่อ่านได้จริง รอบการอัปเดต และวิธีแจ้งเตือนต้องอ้างอิงรุ่นที่ส่งมอบ เฟิร์มแวร์ และคู่มือ นิยาม MIB ของบุคคลที่สามไม่สามารถพิสูจน์ได้ว่ารองรับทุกรายการ
จัดเก็บข้อมูลสำรองการตั้งค่า สถานะการซิงโครไนซ์เวลา ตัวระบุพอร์ต และเวอร์ชันเฟิร์มแวร์ไว้ด้วยกัน เพื่อให้บุคคลต่าง ๆ เปรียบเทียบข้อขัดข้องเดียวกันได้ เมื่อเวลาในบันทึกเหตุการณ์กับเวลาจับแพ็กเก็ตไม่ตรงกัน ให้ปรับเทียบความสัมพันธ์ด้านเวลาของหลักฐานก่อน เพื่อหลีกเลี่ยงการนำเหตุการณ์ต่างกันมาปะติดปะต่อเป็นสาเหตุเดียวกัน อย่าล้างบันทึกข้อผิดพลาดเดิมตามอำเภอใจเพียงเพื่อให้ตัวเลขบนแดชบอร์ดดูดีขึ้น
6. การปรับปรุงประสิทธิภาพควรเป็นการเปลี่ยนแปลงที่ผ่านการตรวจสอบ
หลังจากตั้งสมมติฐานที่ชัดเจนแล้ว ให้เปลี่ยนการตั้งค่าที่มีเหตุผลรองรับครั้งละหนึ่งรายการ และบันทึกประสิทธิภาพบริการกับสถานะอุปกรณ์ก่อนและหลังแก้ไข เมื่อเกี่ยวข้องกับเส้นทาง VLAN หรือกฎการเข้าถึง ให้กำหนดช่วงเวลาดำเนินการที่ได้รับอนุมัติและแผนย้อนกลับ อย่าปิดโปรโตคอลหรือขยายสิทธิ์การเข้าถึงตามอำเภอใจในเครือข่ายควบคุมที่กำลังทำงาน การเริ่มระบบใหม่อาจเปลี่ยนอาการได้ชั่วคราว แต่จะทำให้สูญเสียหลักฐานสำคัญ ณ จุดเกิดเหตุ
การตรวจรับไม่ควรดูเพียงหน้าเว็บจัดการ แต่ต้องดูด้วยว่าบริการที่ขัดข้องเดิมกลับมาทำงานแล้วหรือไม่ บริการที่เดิมถูกจำกัดยังคงถูกจำกัดอยู่หรือไม่ และเส้นทางขากลับกับช่องทางจัดการยังคงสมบูรณ์หรือไม่ การอธิบายได้ว่าสถานะของส่วนใดผิดปกติ ตรวจสอบอย่างไร แก้ไขอย่างไร และทดสอบให้ได้ผลซ้ำอย่างไร น่าเชื่อถือกว่าการกล่าวอย่างคลุมเครือว่าเครือข่ายได้รับการปรับปรุงอย่างชาญฉลาดแล้ว
หมายเหตุอ้างอิง: ตัวนับอินเทอร์เฟซและการจัดการความไม่ต่อเนื่องอ้างอิง RFC 2863 แผนภาพแสดงหลักการทั่วไป ตัวอย่างไม่ใช่ผลการวัดของรุ่นใด และควรตรวจสอบนิยามตัวนับเฉพาะกับเอกสารของอุปกรณ์
แปลจากบทความทางเทคนิคภาษาจีน ต้นฉบับเผยแพร่ครั้งแรก: 2024-03-06 ต้นฉบับแก้ไขล่าสุด: 2026-10-13T11:20:43+08:00 อ่านต้นฉบับภาษาจีน
