ข้อผิดพลาดของพอร์ตหรือการใช้งาน CPU สูงไม่ได้พิสูจน์ทันทีว่าฮาร์ดแวร์เสียหาย ตรวจสอบว่ามีการนับอะไร เกิดขึ้นเมื่อใด และค่าตัวนับเปลี่ยนแปลงอย่างไร จากนั้นแยกเฟรมเสียที่รับเข้ามา เฟรมที่ถูกต้องแต่ถูกทิ้งโดยคิวหรือนโยบาย และทราฟฟิกควบคุมที่ CPU จัดการออกจากกัน สาเหตุที่ต่างกันต้องใช้วิธีแก้ไขต่างกัน คำสั่งทั่วไปเพียงคำสั่งเดียวหรือการรีสตาร์ตไม่สามารถทดแทนการวินิจฉัยได้
1. ทำความเข้าใจว่าตัวนับบันทึกอะไร
เฟรม Ethernet คือหน่วยข้อมูลที่มีข้อมูลที่อยู่ฮาร์ดแวร์และข้อมูลตรวจสอบความสมบูรณ์ อินเทอร์เฟซอาจนับการรับ การส่ง ข้อผิดพลาดในการตรวจสอบเฟรม การทิ้งเฟรม อัตรา และการเปลี่ยนแปลงของลิงก์ ช่อง errors มักรวมหมวดย่อยหลายประเภท และขอบเขตการนับแตกต่างกันตามรุ่น โปรดดูคู่มือของอุปกรณ์จริงเพื่อยืนยันพอร์ต ทิศทาง หน่วย และหมวดหมู่ที่รวมอยู่
ยอดสะสมตลอดอายุการทำงานที่สูงไม่ได้ยืนยันว่าขณะนี้มีความขัดข้อง บันทึกช่วงเวลาสังเกต ค่าที่เปลี่ยนแปลง และทราฟฟิกในช่วงเวลาเดียวกัน โดยเปรียบเทียบช่วงปกติกับช่วงผิดปกติ การรีสตาร์ต การล้างตัวนับ หรือการวนกลับของตัวนับเมื่อเกินค่าสูงสุดก็ทำให้ค่าที่อ่านได้เปลี่ยนไป การล้างตัวนับโดยไม่เก็บหลักฐานอาจทำให้ตรวจสอบปัญหาที่เกิดเป็นครั้งคราวได้ยากขึ้น
ข้อผิดพลาดที่เพิ่มขึ้นขณะมีโหลดแสดงถึงความสัมพันธ์ที่เป็นไปได้ แต่ไม่ได้หมายความว่าโหลดเป็นสาเหตุเสมอไป ทราฟฟิกที่มากขึ้นอาจทำให้ปัญหาสายเคเบิลปรากฏชัดขึ้นเช่นกัน จัดบันทึกของปลายทาง สถานะอินเทอร์เฟซ และการตอบสนองของแอปพลิเคชันให้อยู่บนเส้นเวลาเดียวกัน มองหาความสัมพันธ์ที่เกิดซ้ำได้ แทนการเปลี่ยนสวิตช์โดยอาศัยภาพหน้าจอเพียงภาพเดียว
2. ตรวจสอบความล้มเหลวในการตรวจสอบเฟรมตามแนวลิงก์ขาเข้า
FCS หรือ frame check sequence ช่วยให้ฝั่งรับตรวจสอบข้อผิดพลาดในการส่งที่ตรวจจับได้ การตรวจสอบไม่ผ่านยืนยันว่าเฟรมที่รับมาเสีย ไม่ใช่อีกชื่อหนึ่งของคิวขาออกเต็ม สายเคเบิล ขั้วต่อ สัญญาณรบกวน อินเทอร์เฟซฝั่งตรงข้าม หรือการเจรจาค่าการเชื่อมต่ออาจเป็นปัจจัยร่วม ใช้ข้อมูลสถานะอื่นเพื่อลดขอบเขตสาเหตุที่เป็นไปได้
ในช่วงบำรุงรักษาที่ได้รับอนุญาต ให้เปรียบเทียบโดยใช้สายจัมเปอร์สั้นที่ทราบว่าใช้งานได้ดี และตรวจสอบความเร็วกับโหมดดูเพล็กซ์ที่ใช้งานจริงทั้งสองฝั่ง จากนั้นตรวจสอบสายที่ติดตั้งถาวรและจุดเข้าหัว การที่ตัวนำทั้งแปดเส้นต่อเนื่องถึงกันไม่ได้รับรองสมรรถนะการส่งสัญญาณทางไฟฟ้า สำหรับใยแก้วนำแสง ให้ตรวจสอบโมดูล หน้าสัมผัสปลายใยแก้ว และสภาวะการส่ง/รับ แทนการนำวิธีทดสอบสายทองแดงมาใช้กับใยแก้ว
3. ตีความดูเพล็กซ์และขนาดเฟรมตามบริบท
ฟูลดูเพล็กซ์ช่วยให้ทั้งสองฝั่งส่งและรับพร้อมกันได้ ส่วนฮาล์ฟดูเพล็กซ์แบบดั้งเดิมใช้สภาวะการส่งร่วมกันและกลไกที่ต่างออกไป การตั้งค่าปลายทางไม่สอดคล้องกันอาจทำให้ประสิทธิภาพลดลง เริ่มจากการเจรจาอัตโนมัติตามคำแนะนำของผู้ผลิต แทนการบังคับค่าฝั่งหนึ่งแล้วปล่อยให้อีกฝั่งใช้ค่าที่เข้ากันไม่ได้ อย่านำกฎฮาล์ฟดูเพล็กซ์เก่าของ Fast Ethernet ทุกข้อมาใช้กับอินเทอร์เฟซ Gigabit
อินเทอร์เฟซบางประเภทแสดงการชนกัน เฟรมแตกส่วน เฟรมสั้นกว่ากำหนด หรือเฟรมยาวเกินกำหนด ข้อมูลเหล่านี้เป็นเบาะแสในการวินิจฉัย ไม่ใช่ลักษณะเฉพาะที่ชี้ว่าชิ้นส่วนใดเสียหาย แท็ก ขนาดสูงสุดที่อนุญาต และนิยามตัวนับมีผลต่อการตีความความยาว การเกินค่าตัวเลขในบทสอนเก่าไม่ได้พิสูจน์ว่า NIC เสีย และข้อผิดพลาดด้านการจัดแนวไม่ได้หมายถึงกฎที่กำหนดขึ้นเองว่าจำนวนไบต์ต้องเป็นเลขคู่
คำสั่งและช่องข้อมูลที่อ้างในบทความเก่าเป็นของแพลตฟอร์มเฉพาะ รุ่น FCTEL ไม่จำเป็นต้องแสดงชื่อเดียวกัน ค้นหาข้อมูลที่เทียบเท่าผ่าน Web interface, CLI หรือเครื่องมือจัดการของรุ่นปัจจุบัน จุดประสงค์คือการทำความเข้าใจหลักฐาน ไม่ใช่การสร้างสคริปต์คำสั่งชุดเดียวสำหรับทุกยี่ห้อ
4. เหตุใดเฟรมที่ถูกต้องจึงถูกทิ้งได้เช่นกัน
ทราฟฟิกขาเข้าหลายทางที่มารวมกันที่พอร์ตขาออกเดียวอาจส่งเฟรมเข้ามาในช่วงสั้นมากกว่าที่พอร์ตนั้นส่งออกได้ เฟรมจะรอในบัฟเฟอร์ที่มีขนาดจำกัด ความต้องการที่เกินขีดความสามารถอย่างต่อเนื่องอาจทำให้เกิดการทิ้งเฟรม อัตราการใช้งานเฉลี่ยต่ำไม่ได้ตัดความเป็นไปได้ของทราฟฟิกที่พุ่งสูงช่วงสั้น เพราะช่วงเวลาเฉลี่ยที่ยาวจะบดบังจุดสูงสุดชั่วขณะ
การทิ้งเฟรมขาออกอาจเกิดจากข้อจำกัดอัตราที่กำหนดไว้ นโยบายคิว หรือเงื่อนไขอื่นที่เฉพาะกับการออกแบบระบบด้วยเช่นกัน ยืนยันนิยามของตัวนับ บัฟเฟอร์ที่ใหญ่ขึ้นไม่สามารถแก้ความต้องการที่สูงกว่าความจุขาออกอย่างต่อเนื่อง และอาจเพิ่มความหน่วง ประเมินความจุอัปลิงก์ การจัดตารางส่ง และการจัดการทราฟฟิกที่จำเป็น แทนการเปลี่ยนสายเคเบิลเพียงอย่างเดียว
แอปพลิเคชันตอบสนองต่อการสูญหายต่างกัน TCP สามารถส่งซ้ำและปรับพฤติกรรมการส่งได้ ส่วน UDP เองไม่มีกลไกความน่าเชื่อถือแบบเดียวกัน แต่แอปพลิเคชันที่ใช้งานสามารถสร้างกลไกกู้คืนของตนเองได้ UDP ไม่ได้หมายความว่าทุกแอปพลิเคชันไม่มีวิธีชดเชย การตรวจรับต้องพิจารณาการตอบสนองจริงและความครบถ้วนของข้อมูล
5. แยกกิจกรรมของ CPU ออกจากการส่งต่อด้วยฮาร์ดแวร์
สวิตช์แบบจัดการได้จำนวนมากใช้ชิปสวิตชิงเฉพาะสำหรับการส่งต่อทั่วไปส่วนใหญ่ ขณะที่ CPU จัดการงานบริหาร โปรโตคอลควบคุม และเฟรมบางประเภทที่ประมวลผลด้วยซอฟต์แวร์ ระนาบส่งต่อและระนาบควบคุมมีปฏิสัมพันธ์กัน แต่เฟรมจากปลายทางทุกเฟรมไม่จำเป็นต้องผ่าน CPU สถาปัตยกรรมแตกต่างกัน จึงต้องตีความตามรุ่นที่ใช้งานจริง แทนการตั้งเป็นกฎตายตัว
กิจกรรมของ CPU อาจสูงขึ้นจากคำขอจัดการ การเปลี่ยนแปลงของโปรโตคอล เฟรมผิดปกติ หรือปัญหาซอฟต์แวร์ สิ่งนี้อาจกระทบการตอบสนองด้านการจัดการและโปรโตคอล โดยไม่ได้พิสูจน์ว่าการส่งต่อด้วยฮาร์ดแวร์ล้มเหลว ตรวจสอบค่าอ้างอิงปกติ ระยะเวลา กระบวนการหรือประเภทเฟรม และดูว่าแอปพลิเคชันได้รับผลกระทบหรือไม่ ในทางกลับกัน การที่แอปพลิเคชันใช้งานได้ชั่วคราวก็ไม่ใช่เหตุผลที่จะละเลยโหลดผิดปกติที่คงอยู่อย่างต่อเนื่อง
การป้องกันระนาบควบคุมและสถิติข้อยกเว้นบนบางแพลตฟอร์มไม่ได้ยืนยันว่า FCTEL มีเมนูเหมือนกัน อย่าคัดลอกค่าขีดจำกัดจากบุคคลที่สามหรือปิดกฎป้องกันโดยไม่ยืนยันว่ารองรับ การเปลี่ยนแปลงที่ไม่ถูกต้องอาจรบกวนการสื่อสารควบคุมที่จำเป็น งานในระบบใช้งานจริงต้องมีข้อมูลสำรอง การอนุญาต และแนวทางกู้คืน
6. เก็บหลักฐานโดยใช้ความสามารถของผลิตภัณฑ์ที่ระบุไว้ในเอกสาร
หน้าผลิตภัณฑ์สวิตช์อุตสาหกรรมแบบติดราง DIN ที่มีการจัดการระดับพื้นฐานของ FCTEL ที่เกี่ยวข้องระบุชัดเจนว่ามีสถิติทราฟฟิกพอร์ต การมิเรอร์ และการควบคุมสตอร์ม สถิติช่วยสังเกตการเปลี่ยนแปลง การมิเรอร์คัดลอกทราฟฟิกที่เลือกเพื่อวิเคราะห์ ส่วนการระงับจะจำกัดทราฟฟิกตามประเภทที่กำหนดไว้ ไม่มีฟังก์ชันใดซ่อมแซมข้อผิดพลาดของชั้นกายภาพได้ คำอธิบายนี้ครอบคลุมเฉพาะฟังก์ชันที่ยืนยันไว้บนหน้าผลิตภัณฑ์นั้นเท่านั้น
ก่อนจัดซื้อหรือวินิจฉัย ให้ยืนยันตัวนับย่อยของข้อผิดพลาด ความละเอียดด้านเวลา และบันทึกที่จำเป็น หากเอาต์พุตมิเรอร์หรือเครื่องวิเคราะห์ทำงานเกินกำลัง สำเนาอาจสูญหายได้ ดังนั้นจำนวนที่จับได้ต่ำกว่าจึงไม่ได้ยืนยันโดยตรงว่าแอปพลิเคชันมีข้อมูลสูญหาย คิวภายใน CPU ตารางฮาร์ดแวร์ และกลไกป้องกันต้องอาศัยเอกสารรุ่นที่ละเอียดขึ้นหรือการสนับสนุนจากผู้จำหน่าย อย่าอนุมานจากข้อมูลภาพรวม
7. เชื่อมโยงข้อสรุปแต่ละข้อกับหลักฐาน
หากข้อผิดพลาดขาเข้าหยุดเพิ่มหลังเปลี่ยนเป็นสายจัมเปอร์ที่ผ่านการตรวจสอบคุณสมบัติ และทราฟฟิกกลับมาปกติ ให้บันทึกหลักฐานที่เกี่ยวข้องกับลิงก์ หากช่วงสูงสุดของทราฟฟิกที่ถูกต้องสอดคล้องกับการทิ้งเฟรมขาออก ให้ตรวจสอบความจุและนโยบาย หากเฉพาะการจัดการช้าแต่แอปพลิเคชันยังทำงานต่อ ให้ตรวจสอบการจัดการกับการส่งต่อแยกกัน แทนการมองว่าเกิดจากสาเหตุเดียว
หลังแก้ไข ให้ตรวจสอบการทำงานต่อเนื่องของแอปพลิเคชัน ช่วงทราฟฟิกสูงสุดตามปกติ และกรณีการกู้คืนที่ได้รับอนุมัติ เก็บตัวนับและการกำหนดค่าก่อนและหลังแก้ไข แจ้งผู้จำหน่ายเพื่อดำเนินการต่อเมื่อพบข้อผิดพลาดที่คงอยู่โดยอธิบายไม่ได้ การรีสตาร์ต หรือสัญญาณเตือนฮาร์ดแวร์ ระบุว่าข้อสรุปใดได้รับการยืนยันแล้วและข้อใดยังเป็นสมมติฐาน เพื่อให้ผู้ดูแลคนถัดไปทำซ้ำการสังเกตได้ แทนที่จะได้รับเพียงข้อมูลว่ารีสตาร์ตแล้วและตอนนี้ปกติ
เอกสารอ้างอิง: ฟังก์ชันสถิติและการมิเรอร์ของผลิตภัณฑ์ FCTEL;นิยามตัวนับข้อผิดพลาดของอินเทอร์เฟซ;กลไกการเจรจาค่าการเชื่อมต่อ;การวินิจฉัยระนาบควบคุมและ CPU. เอกสารจากบุคคลที่สามยืนยันกลไก ไม่ใช่คำสั่ง FCTEL ที่ใช้ได้กับทุกรุ่น ภาพประกอบเป็นภาพทั่วไป ไม่ใช่ภาพถ่ายผลิตภัณฑ์หรือผลการวัด
แปลจากบทความเทคนิคภาษาจีน เผยแพร่ต้นฉบับครั้งแรก: 2020-03-16 ปรับปรุงต้นฉบับล่าสุด: 2026-10-13T14:51:17+08:00. อ่านต้นฉบับภาษาจีน
