Fortinet 25G DAC lên link giữa các FortiSwitch giống nhau nhưng không lên giữa FS2048 và FS648
Đang gộp hai hàng aggregation vào FortiSwitch, và phần cuối cùng là một liên kết 25G giữa FS2048 và FS648 ở hai rack cạnh nhau. Mọi thứ khác trong thiết kế đều lên ngay lần đầu; chỉ mỗi link này là không chịu lên.
- FortiSwitch 2048, cổng mặt trước 25G
- FortiSwitch 648, cổng mặt trước 25G
- Fortinet FN-CABLE-SFP28-5 DAC passive, cáp chính hãng, không phải bên thứ ba
- Cả hai cổng không đụng vào gì khác ngoài cấu hình VLAN
Kết quả:
FS2048 port: down, no rx/tx counters moving
FS648 port: down, no rx/tx counters moving
same FN-CABLE-SFP28-5 between two FS648 units: up at 25G, stableĐã thử:
- đổi sang sợi FN-CABLE-SFP28-5 thứ hai từ cùng hộp, không thay đổi
- chuyển cả hai đầu sang các cổng 25G khác trên mỗi chassis, không thay đổi
- chứng minh cáp tốt bằng cách đấu nó giữa hai FS648 giống hệt nhau, nơi nó lên ngay lập tức
Vậy là cáp ổn, cổng cũng ổn, nhưng sự kết hợp thì không. Có gì đó trên cổng 25G cần khớp giữa hai model trước khi link train được không?
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 6
Chính xác là vậy. Hai chassis này dùng thế hệ ASIC và PHY khác nhau, và cơ chế sửa lỗi mà mỗi bên tự chọn ở 25G không giống nhau giữa hai đầu, nên link không bao giờ train xong. Kết quả là down/down sạch sẽ và chẳng có gì trong log để mà soi.
Ghim cùng một chế độ FEC bằng tay trên cả hai cổng:
Làm trên cả FS2048 lẫn FS648, dùng đúng tên cổng của từng bên. CL91 là biến thể Reed-Solomon và dọn lỗi sạch hơn hẳn so với tùy chọn CL74 firecode, nhưng chọn cái nào trong hai cái đó không quan trọng bằng việc chọn cùng một cái ở cả hai đầu: cả hai PHY phải encode và decode theo đúng một scheme, nếu không training không bao giờ hoàn tất, và "auto" trên hai họ PHY khác nhau không phải là cùng một scheme.
Cổng sẽ lên ngay khi bên thứ hai được commit. Nếu sau này thêm model thứ ba vào, cũng phải set rõ ràng ở đó thay vì tin rằng default sẽ giống nhau.
Cáp lên link giữa các unit giống hệt nhau nhưng chết giữa hai model khác nhau nghĩa là physical layer đang không thống nhất được về điều gì đó, và trên đồng 25G thì gần như luôn luôn là FEC.
Trước tiên, đăng lên fec-state hiện đang cấu hình trên cả hai cổng là gì. Default không giống nhau giữa các thế hệ FortiSwitch, và hai model đang nối với nhau không cùng họ ASIC/PHY, nên "cả hai đầu để factory settings" không có nghĩa là "cả hai đầu cùng một setting".
Nếu hai cổng cho ra giá trị khác nhau ở đó, coi như có câu trả lời trước khi đụng vào bất cứ thứ gì khác.
Không đụng gì vào cả hai bên, nên cả hai cổng đang chạy đúng những gì image đặt mặc định. Bên FS2048 trống trơn:
Bên FS648 cũng vậy. Speed và auto-negotiation cũng không đụng tới, tôi chỉ đưa cổng vào đúng VLAN. Nếu default khác nhau tùy model, thì đó là lý do vì sao cùng một sợi cáp lại hoàn toàn ổn giữa hai máy giống hệt nhau.
Cùng loại vấn đề này, ngoài phạm vi Fortinet, nói thêm cho ai cần. Tôi từng có một DAC passive SFP28 25G lên link ngon lành giữa UniFi USW-Pro-Aggregation và một server dùng card Intel SFP28, nhưng lại không cho gì hết trên sfp28-2 của MikroTik CCR2004-1G-12S+2XS - không lỗi ở đầu nào, chỉ đơn giản là không có link. Thử qua Ubiquiti UACC-DAC-SFP28-3M rồi Lenovo 7Z57A03558, kết quả như nhau. Có lúc cổng lên thật rồi rớt lại sau khoảng hai giây, đó là dấu hiệu cho thấy có gì đó đang fail khi train chứ không phải cáp chết.
Lại là FEC: bên Ubiquiti giữ FEC bật mà không có cách nào được hỗ trợ để đổi, còn RouterOS thì chuyển default từ fec91 sang không FEC kể từ bản 6.49. Cách có tác dụng ở đây là lên RouterOS 7.4, nơi các tùy chọn FEC được phơi ra, chạy
rồi đặt cổng về fec74 với auto-negotiation tắt, flow control tắt cả hai chiều, 25 Gbps full duplex, cộng thêm một port profile override bên UniFi ghim cứng 25G FDX. Đó là phần cứng và firmware của tôi, nên coi công thức này như điểm khởi đầu rồi tự kiểm chứng trên máy của bạn.
Nói thêm là cùng một tùy chọn lại mang tên khác nhau tùy đang đứng trong CLI của hãng nào, và đó là thứ khiến chuyện này khó chịu một khi rack có nhiều hơn một vendor. Trên link 25G của Cisco giữa một stack Catalyst 9300 và một cặp Catalyst 9500, fec cl108 ở cả hai đầu là thứ đưa chúng lên; trên 100G giữa cặp 9500 đó và một Nexus 9000, cái có tác dụng lại là fec off ở cả hai bên. Cùng một quyết định, khác từ khóa.
Và FEC không phải lúc nào cũng là thứ cần bật lên. Trên một Nexus 93180YC-EX dùng SFP-H25GB-SR cắm vào adapter Cavium 25G, cổng switch để FEC auto và chờ FEC vì con optic yêu cầu, trong khi NIC báo hoàn toàn không có khả năng FEC, nên hai đầu không bao giờ thống nhất được và interface vẫn down dù module vẫn được nhận diện. Ở đó, fec off trên interface switch là cách sửa, và show interface xác nhận mode chuyển từ Auto sang Off.
Vậy nên quy tắc không phải là "dùng cl91", mà là "quyết định mode, rồi set rõ ràng ở cả hai đầu".
Xác nhận đúng. set fec-state cl91 trên cổng FS2048 một mình nó chẳng thay đổi gì, sau đó làm y vậy trên cổng FS648 thì link lên trong vòng vài giây. Counter chạy ở cả hai bên, và sống sót qua reboot của từng chassis.
Từ giờ setting này sẽ luôn được set rõ ràng trên mọi cổng 25G của cặp này thay vì tin vào default. Hai buổi tối đổi qua đổi lại những sợi cáp hoàn toàn tốt, chỉ vì một dòng config.