Chẩn đoán cổng FC: bộ đếm, slow drain, kiểm tra SFP

Một switch SAN đếm mọi thứ sai sót xảy ra trên một cổng, và các bộ đếm ánh xạ rõ ràng tới nguyên nhân vật lý — miễn là bạn biết bộ đếm nào nghĩa là “đầu nối bẩn” và bộ đếm nào nghĩa là “host không rút hết bộ đệm của nó”. Trang này liệt kê các bộ đếm trên hai nền tảng thống trị, mỗi bộ đếm trỏ tới điều gì, tắc nghẽn slow-drain lộ ra như thế nào, và cách đọc chính SFP đó từ switch.

Các bộ đếm

Bộ đếm (Brocade `porterrshow`)	Tương đương trên Cisco MDS (`show interface fc… counters`)	Ý nghĩa	Trỏ tới
enc_out — lỗi mã hóa ngoài khung	từ truyền dẫn không hợp lệ	symbol lỗi giữa các khung	quang học, cáp, đầu nối, lệch tốc độ — bộ đếm lớp vật lý kinh điển
enc_in — lỗi mã hóa bên trong khung	từ truyền dẫn không hợp lệ / CRC	symbol bị hỏng bên trong khung	cùng nguyên nhân, nghiêm trọng hơn
crc_err	lỗi CRC	khung không qua được CRC	liên kết cận biên: mặt đầu nối bẩn, Rx thấp, SFP đang hỏng; trên ISL hãy kiểm tra cả hai đầu
crc_g_eof	CRC kèm EOF tốt	lỗi CRC nhưng khung vẫn kết thúc đúng cách — phát sinh ở phía trước cổng này	hãy xem chặng trước đó
too_shrt / too_long / bad_eof	khung quá ngắn / quá dài / EOF sai	khung dị dạng	thường là hệ quả của enc_in, hoặc một thiết bị lỗi
link_fail	lỗi liên kết	liên kết bị down	rút cáp, lỗi SFP, nguồn điện, đầu xa reset
loss_sync / loss_sig	mất đồng bộ / mất tín hiệu	mất tín hiệu hoặc mất đồng bộ từ	Rx thấp, LOS, chập chờn — Liên kết chập chờn
frjt / fbsy	F_RJT / F_BSY	fabric từ chối/báo bận khung	do fabric hoặc phân vùng, không phải quang học
disc_c3 — loại bỏ class 3	loại bỏ do timeout	khung bị loại bỏ sau khi hết giờ trong switch	slow drain / tắc nghẽn
c3timeout tx/rx	—	hướng của các timeout	timeout tx: thiết bị gắn vào đang chậm; rx: sự cố ở phía trước
pcs_err (16G trở lên)	—	lỗi khối PCS 64B/66B	lớp vật lý ở 16/32GFC
uncor_err (16G trở lên có FEC)	FEC không sửa được	FEC không thể sửa khối đó	liên kết ở mức cận biên — Chỉ số VDM và FEC
mất credit (`portstatsshow`: tim_txcrd_z)	mất credit / hết credit tx	thời gian ở trạng thái không còn credit truyền	tắc nghẽn hoặc mất R_RDY trên một liên kết bẩn

Quy tắc chung: enc_out, crc_err, loss_sync, pcs_err tăng lên khi có sự cố vật lý; disc_c3, c3timeout, tim_txcrd_z tăng lên khi có sự cố tắc nghẽn; frjt/fbsy tăng lên khi có sự cố fabric. Hãy xóa bộ đếm, chờ một lúc, rồi nhìn vào tốc độ tăng, không phải tổng số.

Slow drain

Một thiết bị đầu cuối trả credit chậm (host quá tải, HBA đang hỏng, lệch tốc độ dọc theo một đường) sẽ giữ khung lại trong bộ đệm của switch; những khung đó hết giờ và bị loại bỏ, còn tắc nghẽn thì lan ngược qua các ISL tới những thiết bị không liên quan. Đây là sự cố gây thiệt hại nặng nhất trong SAN, và thoạt nhìn nó giống như một vấn đề hiệu năng ngẫu nhiên.

Dấu hiệu	Ở đâu
tim_txcrd_z tăng dần trên một F_Port	thiết bị trên cổng đó trả credit chậm
disc_c3 / c3timeout tx trên cùng cổng đó	khung gửi tới thiết bị đó đang hết giờ
disc_c3 trên các ISL và F_Port khác	tắc nghẽn đã lan rộng
Cảnh báo “độ trễ” của Bottleneck/MAPS (Brocade), `show logging onboard flow-control request-timeout`, tính năng phát hiện congestion-drop / slow-drain (Cisco)	công cụ của nền tảng

Cách khắc phục: sửa hoặc cô lập thiết bị chậm (port fencing, đưa vào cách ly ở một kênh ảo ưu tiên thấp), rút ngắn thời gian chờ congestion-drop trên các cổng biên, tránh chênh lệch tốc độ dọc theo một đường, giữ mức oversubscription của ISL ở mức hợp lý (Thiết kế SAN). Quang học hầu như không bao giờ là nguyên nhân của slow drain — nhưng một liên kết cận biên bị mất R_RDY có thể giả dạng nó, vì vậy hãy kiểm tra enc_out/crc trước.

Kiểm tra SFP từ switch

Việc cần làm	Brocade FOS	Cisco MDS / NX-OS
Thông tin nhận dạng SFP và DDM	`sfpshow <port>`	`show interface fc1/1 transceiver details`
Trạng thái và tốc độ cổng	`portshow <port>`, `switchshow`	`show interface fc1/1`, `show interface brief`
Bộ đếm lỗi	`porterrshow`, `portstatsshow <port>`	`show interface fc1/1 counters [detailed]`
Xóa bộ đếm	`portstatsclear` / `statsclear`	`clear counters interface fc1/1`
Kiểm tra liên kết	`portloopbacktest`, chẩn đoán D_Port (`portcfgdport`, `portdporttest`)	`show interface fc1/1 transceiver details` + loopback qua công cụ chẩn đoán
Chính sách sức khỏe	MAPS (ngưỡng cho CRC, ITW, mất credit, công suất/nhiệt độ SFP)	chính sách port-monitor (công suất RX/TX, CRC, ITW, mất credit)

sfpshow và phần chi tiết transceiver hiển thị nhà sản xuất, mã sản phẩm, số sê-ri, tốc độ và các giá trị DDM kèm ngưỡng — cùng những byte mà CodingBox đọc trên bàn thử. Cả hai nền tảng đều gắn cờ quang học không được hỗ trợ; một cổng kẹt ở trạng thái Mod_Inv, No_Module hoặc “unsupported transceiver” là một sự từ chối theo chính sách, không phải một lỗi (Khóa nhà sản xuất, Quang học FC).

Trình tự chẩn đoán cho một cổng FC lỗi

porterrshow / bộ đếm: vật lý (enc_out, crc, sync) so với tắc nghẽn (disc_c3, credit) so với fabric (rjt/bsy).
DDM của SFP: công suất Rx ở cả hai đầu, đối chiếu với khoảng giá trị theo loại module (Giá trị điển hình); xu hướng dòng phân cực Tx để xem lão hóa.
Vệ sinh và soi kiểm tra đầu nối; đổi dây nhảy quang; kiểm tra lại tốc độ tăng của bộ đếm.
Tốc độ: ép tốc độ đàm phán xuống thế hệ thấp hơn để xem lỗi có ngừng hay không (một liên kết 32G cận biên có thể sạch ở 16G) — Tốc độ & tốc độ truyền.
Kiểm tra D_Port / loopback để tách riêng switch, SFP và cáp.
Nếu là tắc nghẽn: tìm thiết bị chậm bằng tim_txcrd_z, không phải bằng cổng đang than phiền.

Trong CodingBox

Một SFP FC bị nghi ngờ, được rút ra từ switch, có thể đọc được ngay trên bàn thử: thông tin nhận dạng, mã tốc độ/môi trường FC, checksum và DDM trực tiếp trên Check transceiver và DDM. Một module bình thường trên bàn thử nhưng lỗi khi cắm vào cổng sẽ chuyển nghi vấn sang cáp, đầu nối hoặc đầu xa.

Nếu bạn phát hiện thông tin chưa chính xác hoặc lỗi trong bài viết này, hãy chọn đoạn liên quan và nhấn Ctrl+Enter để .