Supermicro E300-9A chạy pfSense Plus 22.05: ix2 và ix3 cứ no carrier với DAC vẫn lên link bình thường trên USW-Aggregation
Firewall của tôi là một Supermicro E300-9A chạy pfSense Plus 22.05, và cả hai port 10G SFP+ đều không chịu lên. Cả ix2 lẫn ix3 không bao giờ báo carrier, dù tôi cắm gì vào cage.
Hardware:
- Supermicro E300-9A, pfSense Plus 22.05
- Ubiquiti DAC-SFP10-0.5M và một cáp passive twinax 10Gtek
- Module quang Supermicro AXS85-192-M3 làm phương án thay thế
- Ubiquiti USW-Aggregation ở phía switch
# ifconfig ix2
ix2:
media: Ethernet autoselect
status: no carrierix3 cũng y hệt.
Đã thử:
- cả hai cáp đều chạy tốt trên USW-Aggregation giữa các thiết bị khác, nên chúng không hỏng
- đổi đồng sang module quang AXS85-192-M3, vẫn no carrier trên cả hai port
- khởi động lại appliance nhiều lần, kể cả cắm module trong lúc nó đang chạy
Có thứ gì trong cái hộp này cần phải đá một cái trước khi cage chịu chạy, hay tôi đang nhìn vào hai port chết?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Khởi động lại kiểu warm reboot sẽ chẳng đi tới đâu - mấy port đó chốt lại trạng thái media và không bao giờ re-probe khi restart. Tắt hẳn appliance đúng cách, rút phích nguồn ra vài phút, rồi bật lại với module đã cắm sẵn. Đó là thứ đưa cả hai port trở lại ở đây, và có người khác mô tả đúng hành vi y hệt trên một port Intel X552, nên tôi nghĩ đây là trạng thái media bị kẹt cũ chứ không phải lỗi pfSense.
Nếu bạn cắm module trong lúc hệ thống đang chạy, hãy bounce interface thay vì reboot:
Cái đó khiến driver nhìn lại cage một lần nữa. Nó không phải là fix vĩnh viễn cho bất cứ thứ gì, nhưng nó tiết kiệm được một lần reboot khi bạn đang đổi module trên bench. Kiểm tra kết quả bằng
ifconfig -athay vì nhìn panel phía trước.Làm full power removal trước, xác nhận cả hai cage bằng một DAC trước khi đụng vào phía switch. Debug từng thứ một quan trọng ở đây, vì "no carrier với mọi module" và "link lên nhưng sai tốc độ" thường là hai lỗi tách biệt chỉ tình cờ nằm trên cùng một đường cáp.
Full power removal ăn luôn. Tắt máy, rút adapter, đợi vài phút, bật lại - cả hai port lên ngay. Đấu vòng một DAC giữa ix2 và ix3 thì được link 10G sạch, và cặp AXS85-192-M3 cũng chạy 10G giữa hai port, nên cage và module đều ổn.
Phía switch lại là chuyện khác. Hướng về USW-Aggregation link chỉ negotiate ở 1G, và nếu tôi ép 10G ở đầu nào đó thì nó down và nằm im luôn. Vậy nửa vấn đề đã hết, còn nửa khó chịu thì vẫn ở đây.
Cái nửa fallback về 1G nghe rất quen. Tôi từng đuổi theo đúng triệu chứng này trên một TL-SG3428X và một TL-SX3008F: restart một server treo trên một trong các port SFP+ đó là nó quay lại negotiate ở 1G bất kể port switch được cấu hình thế nào. Adapter Intel X520-DA2, Mellanox và HP, optic Intel E10GSFPSR và 10GTek, cập nhật firmware, nhiều phiên bản driver trên Linux và Windows, port profile - chẳng cái nào đổi được gì. Reboot switch, hoặc chuyển tốc độ port ra khỏi 10G rồi quay lại, khôi phục link 10G cho tới lần reset host tiếp theo.
Thứ thực sự sửa được là đổi optic chứ không phải gì trên host: module TP-Link SM5110-SR ở đầu switch và link quay lại 10G mỗi lần. Có người khác xác nhận điều tương tự trên một SG3428XMPP. Cách hiểu là switch negotiate sai với một số module bên thứ ba sau khi link bị reset từ phía host.
Vendor khác bên phía bạn, nhưng dáng vẻ thì khớp. Trước khi mua nguyên bộ bất cứ thứ gì, mượn một module chính hãng Ubiquiti và test một port trên switch aggregation.
Về việc ép 10G: làm điều đó chỉ ở một đầu chỉ khiến mọi thứ tệ hơn, không tốt hơn. Đầu kia vẫn đang cố negotiate, còn một setting cố định thì chẳng cho nó gì để negotiate cùng, nên link đơn giản là nằm im ở down - đúng y hành vi bạn mô tả. Cố định speed và duplex ở cả hai đầu, hoặc không đầu nào cả.
Hai case liên quan từ thế giới MikroTik, phòng khi nó gợi lại gì đó. Trên một RB4011 một Finisar FTLF8524P2BNV-BR được phát hiện với cả sfp-rx-loss lẫn sfp-tx-fault đều báo no, mà interface vẫn nói no-link, vì một SFP 1G trong cage SFP+ phải được ghim cứng thay vì negotiate:
và, một lần nữa, ở cả hai đầu. Case thứ hai là một CCR1072 nơi auto-negotiation cứ đứng ở DONE sau khi mất link và driver không bao giờ restart lại nó; tắt autoneg và cố định speed đưa link trở lại, đổi lấy cái giá là mất khả năng phát hiện link-down đúng cách.