Port RJ45/SFP chia sẻ 17-20 trên FortiGate 101F tắt hẳn sau khi nâng cấp FortiOS
Chúng tôi chạy một cặp FortiGate 101F cho văn phòng 40 người, không có gì lạ. port17 mang uplink SFP tới core switch, port19 là đường RJ45 xuống phòng server, cả hai đều nằm trong khối RJ45/SFP chia sẻ (port 17-20). Trong cửa sổ bảo trì tháng trước chúng tôi nâng cặp này lên FortiOS 7.4.4, và từ đó khối đó chết hẳn.
- FortiGate 101F, và một FortiGate 100F ở site thứ hai cũng có hành vi y hệt
- port17: module SFP 1G tới một access switch dạng stack
- port19: RJ45 tới một port switch 1G
- FortiOS 7.4.4, nâng cấp từ bản 7.2
Port 1-16 vẫn ổn, chỉ các port chia sẻ là bị down. Điều đập vào mắt tôi là các tuỳ chọn speed trong GUI không còn giống như trước khi nâng cấp nữa, và running config giờ có đoạn này:
config system interface
edit "port17"
set speed 1000full
next
endKhông ai ở đây gõ cái đó cả. Mọi port trên hộp này đều để auto trước khi nâng cấp.
Đã thử:
- cắm lại SFP và đổi sang một cái chắc chắn còn tốt, không đổi
- chuyển đầu xa sang một port switch khác
- cold reboot firewall, config vẫn còn y như trên
Khối RJ45/SFP chia sẻ trên 100F/101F có phải là chuyện bình thường khi mất auto trong lúc nâng cấp không, hay config của chúng tôi bị hỏng ở đâu đó? Và cách đúng để đưa nó về là gì?
Comments 5
Config của bạn không bị ai trong văn phòng làm hỏng, chính bản nâng cấp gây ra. Trên 100F và 101F, bản nâng cấp âm thầm gán cứng 1000full lên các port RJ45/SFP chia sẻ ở chỗ trước đó là auto, mà không hỏi xem đầu kia có chịu được tốc độ đó không. Tuỳ vào đầu xa, bạn sẽ được một port lên link sai tốc độ, hoặc một port không bao giờ lên link, đó chính xác là lý do vì sao 17-20 tối thui trong khi các port riêng thì không bị đụng tới. Fortinet có ghi nhận cái này thành known issue 989629, viết trong release notes của 7.2.9; các nhánh bị ảnh hưởng là v7.2.8 trở lên, v7.4.2 trở lên, và v7.6.0 trở lên.
Đặt lại speed bằng tay, từng port một:
Trên v7.2.8 và từ v7.4.2 tới v7.4.4 thì auto thường không có trong danh sách, đó chính xác là lý do vì sao GUI trông khác với bạn, nên dùng 1000auto ở đó. Trên v7.2.9, v7.4.5, v7.6.0 trở lên thì tuỳ chọn bình thường đã quay lại và bạn cần:
Lặp lại cho port18 tới port20 nếu chúng đang được dùng. Và cho lần bảo trì tiếp theo: kiểm tra trước xem có gì trong đường quản trị của bạn nằm trên port 17-20 không, nếu không thì cái hộp sẽ quay lại với access port của bạn bị ép cứng 1000full và bạn phải lái xe tới site để sửa từ console.
Bạn thực sự đi lên từ bản nào? "một bản 7.2" bao trùm cả một khoảng rộng, và thứ bạn phải gõ để sửa cái này khác nhau giữa các nhánh. Điều đáng biết khác là liệu đầu xa có hỗ trợ autonegotiation hay tự nó cũng bị ghim cứng: một peer chỉ biết autonegotiate sẽ ngồi im không làm gì trước một port bị giữ ở tốc độ cố định.
Một việc cần làm rõ trước khi đổi bất cứ thứ gì: đường quản trị của bạn có chạy qua port nào trong 17-20 không? Nếu có, hãy thực hiện thay đổi tiếp theo từ console thay vì qua mạng.
Đáng nói thêm phần tổng quát cho ai lạc tới đây với một port chia sẻ chạy sai: trên phần lớn các hộp thì cặp đó thực sự loại trừ nhau. NETGEAR gọi đó là dual personality trên GS716T-200, nơi mỗi cage SFP trong hai cái được ghép với một trong các port đồng cuối cùng, và chỉ một nửa của cặp đó sống được tại một thời điểm, nên cắm một module vào là âm thầm đưa RJ-45 tương ứng ra khỏi hoạt động. Mọi port trên model đó dù sao cũng là gigabit, nên uplink quang chỉ mua cho bạn một tuyến cáp, không phải băng thông.
Ý tưởng tương tự trên khối FortiGate, nên xác nhận bạn đang thực sự nhìn vào nửa nào của port17. Một module trong cage cộng một dây patch cắm ở nửa đồng của cùng port đó là một pha tự đá phản lưới nhà kinh điển, và nó trông rất giống vấn đề tốc độ khi nhìn từ CLI.
Vendor khác, cùng kiểu đau khổ. EX4200 với một module uplink EX-UM-2X4SFP: xe-0/1/0 chạy 10G ngon lành, xe-0/1/1 thì thậm chí không thêm vào VLAN được và không truyền traffic nào cả. Cả hai port đều chạy được ở 1G, SFP+ hiện đầy đủ trong show chassis hardware, tôi đổi module, thử một EX-UM-2X4SFP dự phòng và factory reset trước khi có người nói cho tôi biết cái module đó thực chất là gì.
Chẳng có gì hỏng cả. Module đó chỉ nhận SFP+ ở hai trong số các cage của nó, những cái được đánh số 0 và 2 trên phần cứng; cặp còn lại chỉ mang được optic 1G chứ không nhanh hơn. Nên các interface 10G bạn có được cuối cùng là xe-0/1/0 cộng xe-0/1/2, còn xe-0/1/1, cái tôi đã vật lộn suốt, chưa bao giờ có khả năng chạy 10G dù tôi cắm gì vào đó. Chuyển optic sang cage bên cạnh, cấu hình xe-0/1/2, xong. Với cage kiểu mixed-mode, đọc kỹ khối đó hỗ trợ gì trước khi RMA bất cứ thứ gì.
Cẩn thận với hướng combo-exclusivity, nó không giải thích được case này. Các port vẫn chạy tốt trước khi nâng cấp, chỉ có khối chia sẻ hỏng sau đó, và có một dòng speed trong config mà không ai gõ. Đó là bị ghi đè, không phải chuyện ưu tiên cage.
Nhưng cái sai ngược lại cũng hại người không kém. Tôi từng mất cả tuần với switch D-Link DES-1210-52 uplink qua sợi quang tới một OSNOVO NS-SW-8GX2G: đèn báo link ở các port quang, nhưng không có LAN, không internet gì cả, trong khi cùng các switch đó chạy tốt khi nối chuỗi qua đồng, và cập nhật firmware chẳng đổi được gì. Combo port là nghi phạm số một suốt mấy ngày. Lỗi thật sự nằm ở đầu xa: các port OSNOVO mang những module SFP đó đã chết bên trong, cháy rồi, trong khi optic cắm trong đó vẫn hoàn toàn khoẻ mạnh.
Nên một khi config cục bộ đã đúng, hãy cắm một module chắc chắn tốt vào một port chắc chắn tốt ở đầu bên kia trước khi kết luận bất cứ điều gì về hộp của chính bạn.