เมทริกซ์ความเข้ากันได้ บันทึกประจำรุ่น และการเปลี่ยนแปลงเฟิร์มแวร์

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

ผู้ผลิตแต่ละรายเผยแพร่ข้อมูลสนับสนุนที่ไหน

ผู้ผลิต	แหล่งข้อมูล	สิ่งที่ระบุไว้
Cisco	Transceiver Module Group (TMG) Compatibility Matrix; ดาต้าชีตแยกตามแพลตฟอร์ม	PN ↔ แพลตฟอร์ม ↔ ซอฟต์แวร์ขั้นต่ำ; ข้อจำกัดของพอร์ต
Juniper	Hardware Compatibility Tool (HCT)	PN ของออปติก ↔ แพลตฟอร์ม ↔ รุ่น Junos, ความเร็ว, การรองรับ DDM
Arista	Transceiver and Cable Guide (PDF/ออนไลน์)	PN, PMD, ระยะส่ง, แพลตฟอร์มที่รองรับแยกตามรุ่น EOS
Huawei	Hardware Center / รายการความเข้ากันได้ของผลิตภัณฑ์	รหัสโมดูลออปติกแยกตามรุ่นสวิตช์
H3C	Transceiver Module Compatibility Matrix	แยกตามตระกูลผลิตภัณฑ์
HPE Aruba	Transceiver Guide, QuickSpecs	หมายเลข J/R แยกตามตระกูลสวิตช์และเฟิร์มแวร์
Dell	Networking Optics/Cables support matrix	SKU ↔ แพลตฟอร์ม ↔ รุ่น OS10
Nvidia/Mellanox	หน้าผลิตภัณฑ์ LinkX, บันทึกประจำรุ่นของ Cumulus/Onyx, บันทึกเฟิร์มแวร์ InfiniBand	PN ของสาย/ทรานซีฟเวอร์ ↔ สวิตช์/HCA ↔ เฟิร์มแวร์
Extreme, Ruckus	คู่มือความเข้ากันได้ของทรานซีฟเวอร์	แยกตามแพลตฟอร์ม
Brocade (SAN)	บันทึกประจำรุ่นของ FOS, รายการออปติกที่รองรับ	PN ของ SFP ตราสินค้าแยกตามเวอร์ชัน FOS
SONiC / ไวท์บ็อกซ์	รายการความเข้ากันได้ของฮาร์ดแวร์จากผู้ผลิตแพลตฟอร์ม, วิกิของคอมมูนิตี้	ออปติกที่ผ่านการทดสอบแยกตามแพลตฟอร์ม; ส่วนใหญ่ดูแลโดยคอมมูนิตี้
ผู้ผลิต NIC	รายการความเข้ากันได้ของอแดปเตอร์ Intel/Broadcom/Mellanox	โมดูลที่รองรับและเวอร์ชันไดรเวอร์

อ่านบันทึกประจำรุ่นของ NOS เวอร์ชันที่ใช้งานด้วย การเปลี่ยนแปลงด้านออปติกมักซ่อนอยู่ใต้หัวข้อ “resolved issues”, “behaviour changes” และ “new hardware support”

การอ่านรายการในตาราง

คอลัมน์	ความหมาย	สิ่งที่ต้องระวัง
หมายเลขชิ้นส่วน	สตริงที่สวิตช์คาดหวังจากโมดูลเป๊ะ ๆ (การกำหนดหมายเลขชิ้นส่วน)	ส่วนต่อท้ายที่บ่งชี้เกรด (`-S`, `-I`, ตัวอักษรระบุรุ่นย่อย) ถูกนับเป็น PN คนละตัวกัน
แพลตฟอร์ม/พอร์ต	แชสซี, ไลน์การ์ด หรือช่วงพอร์ตใด	เฉพาะอัปลิงก์เท่านั้น, “ports 49–52 only”, ไม่ใช้กับพอร์ตที่เบรกเอาต์แล้ว
ซอฟต์แวร์ขั้นต่ำ	รุ่นแรกที่เริ่มรองรับ	PN รุ่นใหม่บนซอฟต์แวร์รุ่นเก่า = unsupported แม้จะเป็นของตราสินค้าเดียวกันก็ตาม
ความเร็ว/โหมด	PN รองรับอัตราและการเบรกเอาต์แบบใดบนพอร์ตนั้น	เบรกเอาต์ 4×25G รองรับเฉพาะบางแพลตฟอร์มเท่านั้น
DDM / DOM	เปิดให้เห็นข้อมูลวินิจฉัยหรือไม่	“DOM not supported” ในบางชุดค่าผสม
หมายเหตุ	อุณหภูมิ, ระยะส่ง, ข้อกำหนด FEC, EOL	วันที่เลิกจำหน่ายและ PN รุ่นที่มาแทน

สิ่งที่เปลี่ยนไปตามซอฟต์แวร์

การเปลี่ยนแปลง	ผลต่อออปติก	ปรากฏเป็น
การตรวจสอบข้อมูลระบุตัวตนใหม่หรือเข้มงวดขึ้น	โมดูลของบุคคลที่สามหรือที่เขียนโค้ดไว้ซึ่งเคยผ่านได้ ถูกปฏิเสธ	พอร์ตเข้าสถานะ errdisable หลังอัปเกรด (แต่ละ NOS ตรวจสอบโมดูลอย่างไร)
คำสั่งโอเวอร์ไรด์ที่ซ่อนไว้ถูกลบหรือเปลี่ยนชื่อ	`service unsupported-transceiver` ไม่ถูกยอมรับอีกต่อไป	คอนฟิกโหลดไม่สำเร็จ พอร์ตดับ
การจัดการ CMIS ดีขึ้นหรือเปลี่ยนไป	โมดูล 400G+ ที่เคยต้องใช้ทางแก้เฉพาะหน้าใช้งานได้แล้ว หรือกลับกัน	โมดูลค้างอยู่ที่ LowPwr (ปัญหา CMIS)
ค่าเริ่มต้นของ FEC/AN เปลี่ยนไป	ลิงก์ที่พึ่งพาค่าเริ่มต้นเดิมล้มเหลว	ลิงก์ดับทั้งที่ระดับสัญญาณดี (FEC และ AN)
การโพลล์ DDM หรือการจัดการค่าเกณฑ์เปลี่ยนไป	อะลาร์มปรากฏขึ้นหรือหายไป	syslog มีข้อความใหม่เพิ่มขึ้นหรือเงียบไป
PN ของออปติกถึงจุดสิ้นสุดการสนับสนุน	ยังใช้งานได้ แต่ไม่อยู่ในรายการอีกต่อไป	ตั๋วงานในอนาคตถูกปิดในสถานะ “unsupported”
มีการรวมอัปเดตเฟิร์มแวร์ของโมดูลมาด้วย	โมดูลตราสินค้าของผู้ผลิตได้เฟิร์มแวร์ใหม่	พฤติกรรมฝั่งโมดูลเปลี่ยนไป (ไมโครคอนโทรลเลอร์และเฟิร์มแวร์)

แนวปฏิบัติกับฟลีตที่ช่วยเลี่ยงเรื่องไม่คาดฝัน

ทำบัญชี — บันทึกผู้ผลิต, PN, ซีเรียล, รุ่นย่อย และเฟิร์มแวร์ของทุกโมดูลแยกตามพอร์ต (จากสวิตช์หรือจากโต๊ะทดสอบ) ลงใน CMDB
ตรึงรุ่นซอฟต์แวร์ — ถือว่าเวอร์ชันของ NOS เป็นส่วนหนึ่งของสามสิ่งที่ต้องเข้ากันได้ อย่าอัปเกรดชั้นแอ็กเซสและคอร์ในวันเดียวกัน
อ่านบันทึกประจำรุ่น ในส่วนที่เกี่ยวกับออปติกก่อนอัปเกรดทุกครั้ง
ทดสอบบนสวิตช์แล็บหรือสวิตช์คานารี ด้วยออปติกแต่ละชนิดที่ใช้งานอยู่ชนิดละหนึ่งตัว — เริ่มจากโมดูลของบุคคลที่สามและโมดูลที่เขียนโค้ดไว้ก่อน
เก็บอิมเมจรุ่นก่อนหน้าไว้ พร้อมแผนย้อนกลับ; รู้ไว้ว่าพอร์ตใดมีแนวโน้มเข้าสถานะ errdisable ได้ง่าย
ตั้งค่าฐาน DDM ทั้งก่อนและหลัง เพื่อให้เห็นการเปลี่ยนแปลงพฤติกรรมในการตรวจติดตาม (การตรวจติดตาม)
ติดตาม EOL ของ PN ออปติกและรุ่นที่มาแทน เพื่อให้ของที่เปลี่ยนตรงกับตาราง

ออปติกของบุคคลที่สามและที่เขียนโค้ดในภาพรวมนี้

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

ฝั่ง NIC และเซิร์ฟเวอร์

อแดปเตอร์ของเซิร์ฟเวอร์มีตารางความเข้ากันได้และนโยบายเป็นของตัวเอง (อแดปเตอร์ ↔ โมดูล ↔ ไดรเวอร์/เฟิร์มแวร์) — อแดปเตอร์ตระกูล Intel บางรุ่นปฏิเสธ SFP ที่ไม่อยู่ในรายการ เว้นแต่พารามิเตอร์ของไดรเวอร์จะอนุญาต; อแดปเตอร์ Mellanox/Nvidia ตรวจสอบสายสำหรับ InfiniBand การอัปเดตไดรเวอร์และเฟิร์มแวร์เปลี่ยนกฎเหล่านี้ได้เช่นเดียวกับการอัปเกรด NOS (สูตรการตั้งค่าพอร์ต)

ใน CodingBox

ฝั่งโต๊ะทดสอบของแนวปฏิบัติกับฟลีตนี้คือ อ่านข้อมูลระบุตัวตนและเวอร์ชันเฟิร์มแวร์ของทุกโมดูลเข้า code database ตอนตรวจรับของเข้า เทียบไบต์ของโมดูลที่น่าสงสัยกับรายการในตารางบน Check transceiver และเก็บบันทึกแยกความแตกต่างระหว่างของที่เขียนโค้ดกับของแท้ไว้ในฐานข้อมูล เพื่อให้การถูกปฏิเสธในวันอัปเกรดสืบย้อนไปถึงโมดูลนั้นได้ในไม่กี่วินาที

นโยบายไดรเวอร์และเฟิร์มแวร์ของ NIC โดยละเอียด แยกตามผู้ผลิตและระบบปฏิบัติการ: ความเข้ากันได้ของทรานซีฟเวอร์บน NIC

แนวปฏิบัติกับฟลีตในรูปแบบรายการตรวจสอบการติดตั้งใช้งาน — อัปเกรดก่อนตั้งค่า, ทดสอบแบบคานารี, ตั้งค่าฐาน DDM, การทดสอบตรวจรับ: การเลือกและการติดตั้งใช้งาน

หากพบข้อมูลที่ไม่ถูกต้องหรือข้อผิดพลาดในบทความนี้ ให้เลือกข้อความส่วนนั้นแล้วกด Ctrl+Enter เพื่อ