Catalyst 3850 đưa cổng vào err-disable khi ThinkSystem SR650 dùng module quang SR Lenovo 46C3447
Host ESXi mới lắp vào rack đấu qua một con 3850 của campus. Quản lý qua cổng đồng lên bình thường, nhưng uplink 10G thì không: server vừa boot là cổng switch rơi vào err-disable ngay, host không thấy gì trên vmnic đó.
- Lenovo ThinkSystem SR650, 7X06CTO1WW, dùng card Emulex VFA5.2 2x10GbE SFP+
- Module Lenovo 10GBASE-SR, 46C3447, cắm trên card
- Cisco WS-C3850-24XS-S, dùng Cisco SFP-10G-SR ở phía switch
- Dây nhảy OM3 LC-LC nối giữa hai bên
Te1/0/7: goes err-disabled within seconds of the server powering on
ESXi: the uplink shows DISCONNECTED
Same patch cord, Cisco SFP-10G-SR at both ends switch to switch: link up and stableĐã thử:
- chuyển server sang cổng khác trên cùng switch, vẫn y như vậy
- đổi 46C3447 sang con còn lại từ cổng kia của card
- thay dây nhảy mới, lau sạch và cắm lại cả hai đầu
Sợi quang và module phía switch rõ ràng không có vấn đề gì, nên chắc chắn có gì đó đang từ chối module Lenovo. Bên nào đang từ chối ở đây, server hay switch, và có cách nào để 3850 chấp nhận sống chung với 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 3
Log đó là câu trả lời rồi.
gbic-invalidlà switch từ chối thứ nó đọc ra là module không được xác thực, và cái check này nằm ở phía Cisco, không phải ở SR650 cũng không phải trong ESXi. Nó từ chối module quang SR mang mã Lenovo trên link đó và giết cổng trước khi link kịp được đánh giá, đó cũng là lý do vì sao đổi cổng hay đổi dây chẳng thay đổi được gì.Hai dòng trong global configuration:
Dòng đầu bảo switch cứ tiếp tục hoạt động với module nó không nhận ra, dòng thứ hai chặn err-disable bắn cổng khi cái check CRC đó fail. Không dòng nào có tác dụng hồi tố, nên phải bounce cổng lại sau đó và cắm lại sợi quang trong lúc cổng đang down:
Lưu cấu hình lại khi cổng đã lên. Nếu nó chỉ nằm trong running config, cổng sẽ quay lại err-disable sau lần reload tiếp theo và bạn lại phải debug chuyện này vào một thời điểm tệ hơn nhiều.
Hai điều cần lưu ý. Giờ bạn đang ở ngoài cấu hình được Cisco hỗ trợ: họ coi quang bên thứ ba là chưa được kiểm chứng và TAC có thể từ chối case tương thích liên quan đến nó, điều này quan trọng nếu link này nằm trong hợp đồng. Và
service unsupported-transceiverkhông phải là cách sửa vạn năng. Thông báo bad crc y hệt vẫn xuất hiện khi chính cổng mới là vật cản, ví dụ một khe SFP chỉ chạy 1G mà bị nhét module 10G vào, nên nếu cổng vẫn down sau khi bounce, hãy kiểm tra tốc độ thực tế mỗi đầu đang chạy trước khi lại đổ lỗi cho quang.Trước khi ai đoán mò: switch thực sự log gì khi cổng down? Err-disable lúc nào cũng nêu rõ nguyên nhân, và nguyên nhân đó làm thay đổi hoàn toàn câu trả lời. Một cảnh báo security hay CRC về module là chuyện khác hẳn so với flap hay protocol trip, và cách sửa cho cái này chẳng có tác dụng gì với cái kia.
Lấy
show loggingquanh thời điểm server bật nguồn và đăng các dòng liên quan đến cổng đó lên. Cũng xác nhận luôn thứ gì đang thực sự cắm trong Te1/0/7, bạn nói là Cisco SFP-10G-SR, vậy 46C3447 có phải là linh kiện non-Cisco duy nhất trong toàn bộ đường đó không?Log ngay từ lúc nó rớt, hai dòng cho cổng đó:
Vậy là cái security check bắn lên, không phải flap. Và đúng vậy, đầu switch là Cisco SFP-10G-SR chính hãng lấy từ hộp Cisco, 46C3447 trong server là linh kiện mang mã Lenovo duy nhất trên toàn đường. Đó chính là điều làm mình rối, vì thông báo nêu tên cổng trên switch chứ không phải cái gì ở phía server.