การวินิจฉัยพอร์ต FC: ตัวนับ, slow drain และการตรวจสอบ SFP

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

ตัวนับ

ตัวนับ (Brocade `porterrshow`)	ค่าเทียบเท่าใน Cisco MDS (`show interface fc… counters`)	ความหมาย	ชี้ไปที่
enc_out — ข้อผิดพลาดการเข้ารหัสนอกเฟรม	invalid transmission words	สัญลักษณ์ผิดพลาดระหว่างเฟรม	ออปติกส์, สาย, คอนเนกเตอร์, อัตราส่งไม่ตรงกัน — ตัวนับระดับฟิสิคัลเลเยอร์คลาสสิก
enc_in — ข้อผิดพลาดการเข้ารหัสภายในเฟรม	invalid transmission words / CRC	สัญลักษณ์เสียหายภายในเฟรม	สาเหตุเดียวกัน แต่รุนแรงกว่า
crc_err	CRC errors	เฟรมตรวจ CRC ไม่ผ่าน	ลิงก์อยู่ในระดับก้ำกึ่ง: หน้าตัดปลายสกปรก, Rx ต่ำ, SFP กำลังเสีย; บน ISL ให้ตรวจสอบทั้งสองปลาย
crc_g_eof	CRC with good EOF	ข้อผิดพลาด CRC แต่เฟรมจบอย่างถูกต้อง — เกิดขึ้น ต้นทาง ก่อนพอร์ตนี้	ดูที่ฮอปก่อนหน้า
too_shrt / too_long / bad_eof	frame too short / too long / bad EOF	เฟรมผิดรูปแบบ	มักเป็นผลจาก enc_in หรืออุปกรณ์ที่บกพร่อง
link_fail	link failures	ลิงก์ดับ	สายถูกดึง, SFP เสีย, ไฟเลี้ยง, ปลายไกลรีเซ็ต
loss_sync / loss_sig	sync loss / signal loss	สัญญาณหรือการซิงค์เวิร์ดหายไป	Rx ต่ำ, LOS, ลิงก์กระพริบ — ลิงก์กระพริบ
frjt / fbsy	F_RJT / F_BSY	ฟาบริกปฏิเสธ/ตอบกลับแบบไม่ว่างต่อเฟรม	ปัญหาฟาบริกหรือโซนนิ่ง ไม่ใช่ออปติกส์
disc_c3 — การทิ้งเฟรมของ class 3	timeout discards	เฟรมถูกทิ้งหลังจากหมดเวลาในสวิตช์	การระบายช้า / ความแออัด
c3timeout tx/rx	—	ทิศทางของการหมดเวลา	tx timeout: อุปกรณ์ที่เชื่อมต่ออยู่ช้า; rx: ปัญหาที่ต้นทาง
pcs_err (16G ขึ้นไป)	—	ข้อผิดพลาดบล็อก PCS แบบ 64B/66B	ฟิสิคัลเลเยอร์ที่ 16/32GFC
uncor_err (16G ขึ้นไปที่มี FEC)	FEC uncorrected	FEC แก้ไขบล็อกนี้ไม่ได้	ลิงก์อยู่ในระดับก้ำกึ่ง — ค่าตรวจวัด VDM และ FEC
credit loss (`portstatsshow`: tim_txcrd_z)	credit loss / tx credit not available	เวลาที่ใช้ไปโดยไม่มีเครดิตส่งเหลือเลย	ความแออัดหรือ R_RDY สูญหายบนลิงก์ที่สกปรก

กฎง่าย ๆ: enc_out, crc_err, loss_sync, pcs_err เพิ่มขึ้นเมื่อมีปัญหาทางกายภาพ; disc_c3, c3timeout, tim_txcrd_z เพิ่มขึ้นเมื่อมีปัญหาความแออัด; frjt/fbsy เพิ่มขึ้นเมื่อมีปัญหาฟาบริก ล้างตัวนับ รอสักครู่ แล้วดูที่อัตราการเพิ่มขึ้น ไม่ใช่ยอดรวม

การระบายช้า

อุปกรณ์ปลายทางที่คืนเครดิตช้า (โฮสต์ที่โอเวอร์โหลด, HBA ที่กำลังเสีย, อัตราส่งที่ไม่ตรงกันตลอดเส้นทาง) จะทำให้เฟรมค้างอยู่ในบัฟเฟอร์ของสวิตช์; เฟรมเหล่านั้นหมดเวลาและถูกทิ้งไป และความแออัดจะแผ่ย้อนกลับผ่าน ISL ไปยังอุปกรณ์อื่นที่ไม่เกี่ยวข้อง มันคือปัญหาที่สร้างความเสียหายมากที่สุดใน SAN และในตอนแรกจะดูเหมือนปัญหาประสิทธิภาพแบบสุ่ม ๆ

สัญญาณ	ตำแหน่ง
tim_txcrd_z ไต่สูงขึ้นบน F_Port	อุปกรณ์บนพอร์ตนั้นคืนเครดิตช้า
disc_c3 / c3timeout tx บนพอร์ตเดียวกัน	เฟรมที่ส่งไปยังอุปกรณ์นั้นหมดเวลา
disc_c3 บน ISL และ F_Port อื่น ๆ	ความแออัดได้แผ่กระจายไปแล้ว
การแจ้งเตือน “latency” ของ Bottleneck/MAPS (Brocade), `show logging onboard flow-control request-timeout`, การตรวจจับ congestion-drop / slow-drain (Cisco)	เครื่องมือของแพลตฟอร์ม

การบรรเทา: แก้ไขหรือแยกอุปกรณ์ที่ช้าออกไป (การกันพอร์ต, กักไว้ในช่องสัญญาณเสมือนที่มีลำดับความสำคัญต่ำ), ลดเวลาหมดอายุของ congestion-drop บนพอร์ตขอบ, หลีกเลี่ยงการเปลี่ยนอัตราส่งหลายขั้นตลอดเส้นทาง, รักษาระดับโอเวอร์ซับสคริปชันของ ISL ให้อยู่ในเกณฑ์สมเหตุสมผล (การออกแบบ SAN) ออปติกส์แทบไม่เคยเป็นสาเหตุของการระบายช้าเลย — แต่ลิงก์ที่อยู่ในระดับก้ำกึ่งพร้อม R_RDY สูญหายอาจเลียนแบบอาการนี้ได้ ดังนั้นให้ตรวจสอบ enc_out/crc ก่อน

การตรวจ SFP จากสวิตช์

งาน	Brocade FOS	Cisco MDS / NX-OS
ข้อมูลระบุตัวตนและ DDM ของ SFP	`sfpshow <port>`	`show interface fc1/1 transceiver details`
สถานะและอัตราส่งของพอร์ต	`portshow <port>`, `switchshow`	`show interface fc1/1`, `show interface brief`
ตัวนับข้อผิดพลาด	`porterrshow`, `portstatsshow <port>`	`show interface fc1/1 counters [detailed]`
ล้างตัวนับ	`portstatsclear` / `statsclear`	`clear counters interface fc1/1`
ทดสอบลิงก์	`portloopbacktest`, การวินิจฉัยแบบ D_Port (`portcfgdport`, `portdporttest`)	`show interface fc1/1 transceiver details` + ลูปแบ็กผ่านเครื่องมือวินิจฉัย
นโยบายสุขภาพ	MAPS (ค่าเกณฑ์บน CRC, ITW, credit loss, กำลัง/อุณหภูมิของ SFP)	นโยบาย port-monitor (กำลัง RX/TX, CRC, ITW, credit loss)

sfpshow และรายละเอียดทรานซีฟเวอร์แสดงผู้ผลิต หมายเลขชิ้นส่วน ซีเรียล อัตราส่ง และค่า DDM พร้อมค่าเกณฑ์ — ไบต์ชุดเดียวกับที่ CodingBox อ่านบนโต๊ะทดสอบ ทั้งสองแพลตฟอร์มตั้งค่าสถานะออปติกส์ที่ ไม่รองรับ; พอร์ตที่ค้างอยู่ที่ Mod_Inv, No_Module หรือ “unsupported transceiver” คือการปฏิเสธตามนโยบาย ไม่ใช่ความผิดพลาด (การล็อกผู้ผลิต, ออปติกส์ของ FC)

ลำดับการวินิจฉัยสำหรับพอร์ต FC ที่มีปัญหา

porterrshow / ตัวนับ: ทางกายภาพ (enc_out, crc, sync) เทียบกับความแออัด (disc_c3, credits) เทียบกับฟาบริก (rjt/bsy)
DDM ของ SFP: กำลัง Rx ที่ปลายทั้งสองข้างเทียบกับช่วงของคลาส (ค่า DDM ทั่วไปตามชนิดโมดูล); แนวโน้มไบอัส Tx เพื่อดูความเสื่อมตามอายุ
ทำความสะอาดและตรวจสอบคอนเนกเตอร์; เปลี่ยนสายแพตช์คอร์ด; ตรวจสอบตัวนับอีกครั้งที่อัตราการเพิ่มขึ้น
อัตราส่ง: บังคับอัตราส่งที่เจรจาให้ลงไปที่รุ่นต่ำกว่า เพื่อดูว่าข้อผิดพลาดหยุดหรือไม่ (ลิงก์ 32G ที่อยู่ในระดับก้ำกึ่งอาจสะอาดดีที่ 16G) — ความเร็วและอัตราเร็ว
การทดสอบ D_Port / ลูปแบ็ก เพื่อแยกปัญหาระหว่างสวิตช์ SFP และสาย
หากเป็นความแออัด: หาอุปกรณ์ที่ช้าด้วย tim_txcrd_z ไม่ใช่จากพอร์ตที่ร้องเรียน

ใน CodingBox

SFP ของ FC ที่ต้องสงสัยเมื่อถอดออกจากสวิตช์ สามารถอ่านได้บนโต๊ะทดสอบ: ข้อมูลระบุตัวตน รหัสอัตราส่ง/สื่อกลางของ FC เช็กซัม และ DDM แบบสดที่ Check transceiver และ DDM โมดูลที่ปกติดีบนโต๊ะทดสอบแต่มีข้อผิดพลาดในพอร์ตจริง ทำให้ต้องสงสัยไปที่สาย คอนเนกเตอร์ หรือปลายไกลแทน

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