IBM Flex System EN4093 đưa port trunk SFP+ vào ERRDISABLE lúc boot và cả khi đang chạy
Hai enclosure Flex System, mỗi cái dùng một EN4093R 10Gb Scalable Switch (option 49Y4270) làm network module. Port quay về error-disabled sau sự cố nguồn của chassis, và ít gặp hơn là rơi vào đúng trạng thái đó ngay cả khi mọi thứ vẫn đang chạy bình thường. Không phải lúc nào cũng là những port giống nhau, và chính điều đó khiến việc truy ra nguyên nhân mệt mỏi.
Cấu hình:
- IBM Flex System EN4093 10Gb Scalable Switch, option 49Y4270
- uplink trunk bốn port lên core, optic IBM cộng thêm một DAC được thêm vào sau
- port QSFP+ được breakout sang enclosure thứ hai
- bên mình chạy MSTP, core là vendor khác
Danh sách port sau khi boot cho thấy:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilitiesĐã thử:
- shutdown / no shutdown trên các port bị ảnh hưởng đưa phần lớn chúng trở lại cho đến sự cố tiếp theo
- lau sạch và cắm lại từng sợi fibre trong trunk, không thay đổi gì so với hiện tượng cũ
- so sánh cấu hình port ở đầu xa, tốc độ khớp nhau trên giấy tờ
Cái gì thực sự đẩy các port này vào errdisable, và có cách nào chặn việc này xảy ra ở mỗi lần boot thay vì phải tự tay clear mỗi lần 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 5
Con switch này có bảy trạng thái được ghi nhận chính thức khiến một port bị disable, và chúng gần như chẳng liên quan gì đến nhau:
Trường hợp của bạn là cái thứ tư, và đó cũng là cái nhiều người gặp nhất, vì nó là cái do chính mình tạo ra: trộn tốc độ hoặc loại module trong cùng một trunk là switch phản đối ngay. Một DAC nằm cạnh ba module quang là đủ để gây chuyện. Bỏ DAC ra khỏi đó và lắp vào một module cùng loại với ba cái còn lại.
Với port bị flap detector bắt, bounce port vẫn là cách khắc phục được ghi nhận chính thức:
Sau đó, đọc lại cấu hình spanning tree trên link đó và tự tay kiểm tra lại cả dây đồng lẫn fibre. Sau bất kỳ thay đổi cấu hình nào cũng nên reload, nếu không running state sẽ âm thầm không còn khớp với những gì bạn nghĩ mình đã set.
Hai điều đừng kỳ vọng. Hai trong bảy trạng thái đó giữ port down ngay cả sau khi timeout hết hạn và cần tay người can thiệp vào port. Và không firmware nào sửa được chuyện này - quan điểm của vendor là bạn tự cấu hình để né nó, nên module giống hệt nhau trên mọi thành viên trunk cộng với fibre sạch là giới hạn cao nhất của việc phòng ngừa.
Tôi sẽ bắt đầu từ chỗ có hai lý do khác nhau trong cùng một đoạn log. Một port cụ thể có luôn quay về disable vì cùng một lý do không, hay cái lần này rớt vì mismatched capabilities thì lần sau lại trip flap detector? Một lý do cố định theo từng port và một lý do thay đổi lung tung là hai hướng điều tra khác nhau, và chỉ một trong hai hướng đó kết thúc bằng việc bạn phải mua thêm hardware.
Điều thứ hai đáng làm rõ là core đang chạy spanning tree kiểu gì. Bạn đang dùng MSTP; nếu phía bên kia đẩy BPDU kiểu PVST của Cisco lên các uplink đó, con switch này có cơ chế bảo vệ phản ứng đúng với việc đó và đánh sập port, và nhìn từ ngoài vào thì y hệt lỗi mà bạn đang truy tìm. Bạn có xác định được có lần rớt nào trùng với một thay đổi topology trên core, thay vì trùng với lần boot của chính mình không?
Theo từng port thì nhất quán, nhưng trên toàn bộ switch thì không. Các thành viên trunk bị rớt luôn quay về với mismatched link capabilities, còn access port trên port 5 thì chỉ trip flap detector, theo chu kỳ mà tôi không tìm ra quy luật nào. Nên có vẻ đây là hai lỗi khác nhau đội chung một cái áo.
Spanning tree ở phía bên kia thì tôi chưa trả lời được - core thuộc về team khác và tôi đã hỏi họ thực sự đang phát ra gì trên các uplink đó. Cho tới giờ log của tôi chưa thấy lần rớt nào gắn với thay đổi topology bên đó, nhưng tôi đọc log để tìm link event chứ không phải để tìm cái đó, nên tôi sẽ không nói là đã loại trừ được.
Vendor khác nhưng hình dạng giống hệt. Bên tôi có một FortiGate 201F treo vào FortiSwitch 548D qua SFP+, dùng DAC chính hãng Fortinet giữa hai đầu, và link 10Gbps đơn giản là không chịu đứng yên - nó rớt bất kể tôi chỉnh speed và duplex thế nào, và hạ cả hai đầu từ FortiOS 7.4 về 7.2.5 cũng chẳng thay đổi gì.
Cuối cùng thứ giữ được link là một sợi DAC Fortinet ngắn hơn với STP tắt trên riêng link đó, và từ đó đến giờ nó chạy ổn định. Phần đáng nhớ nhất là lý do rút ra sau đó: đoạn đồng passive càng dài thì tín hiệu càng suy hao nhiều hơn khi đến nơi, nên ở 10G bất kỳ DAC dài hay cận biên nào cũng nên nằm trong danh sách nghi vấn, bất kể nhãn in trên nó là gì. Với ba optic và một DAC trong cùng một trunk bị errdisable, tôi sẽ soi kỹ cái khác biệt đó trước tiên.
Một việc nên làm trước khi động vào bất kỳ hardware nào: ghi lại chính xác nhịp độ của các lần flap theo timestamp trong log.
Trên một switch hoàn toàn không liên quan, một con TL-SG3452X, mọi port SFP+ có cắm module đều down rồi lên lại mỗi mười đến mười lăm phút, kèm STP message trong log ở mỗi lần flap, và kết luận hiển nhiên là optic hỏng - cho đến khi một sợi DAC TL-SM5220-1M chính hãng cũng flap đúng theo nhịp đó. Việc đó giết chết giả thuyết optic chỉ trong một lần test và chỉ thẳng sang một regression của firmware; cách duy nhất hiệu quả ở đó là giữ nguyên bản build cũ.
Một chu kỳ đều đặn nghĩa là có gì đó timeout theo lịch. Một chu kỳ ngẫu nhiên nghĩa là có gì đó vật lý. Test này rẻ, và nó giúp bạn khỏi mua những module không cần thiết. Cũng nên giữ lại image firmware cũ để lựa chọn downgrade luôn sẵn đó.