EX4200 báo EEPROM SFP+ bị mis-programmed sau khi upgrade Junos, trong khi MX960 vẫn hiện DOM
Chúng tôi chạy một số đường DWDM 80 km trên EX4200 với optic bên thứ ba ở cả hai đầu, vì hàng DWDM mang thương hiệu vendor thì ngân sách không bao giờ kham nổi. Chuyện đó ổn suốt nhiều năm. Sau khi các máy EX được chuyển lên Junos 12.3, optic vẫn nằm nguyên ở cùng port, các đường DWDM vẫn tồn tại, nhưng switch đã thôi không chịu công nhận đó là optic nữa.
- EX4200, Junos 12.3 (DOM chạy tốt trên 11.4 trong cùng chassis)
- Integra SFPP-C51-80-10GD, DWDM 80 km SFP+
- MX960 ở đầu xa của cùng đường DWDM, cùng part number, DOM vẫn đầy đủ
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableLog messages in đúng một dòng khi module được cắm vào: SFP+ of type 0 EEPROM is Mis Programmed.
Những gì đã loại trừ:
- tháo lắp lại optic và chuyển sang port khác trên cùng chassis, không thay đổi;
- thử một EX3300 dự phòng và một QFX5100 trong lab, cả hai hành xử y hệt nhau, nên đây không phải lỗi một máy đơn lẻ;
- kiểm tra lại đầu xa, MX960 cho ra đầy đủ diagnostics cho cùng part từ cùng đơn hàng.
Vậy driver của EX đang áp đặt điều gì đó trong EEPROM mà bản cũ đơn giản là bỏ qua? Và nếu đúng vậy, có thể làm gì với chính optic đó không, hay đây là chuyện cần nói chuyện với nhà cung cấp?
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
Dòng log đó không phải một câu càu nhàu chung chung, đó là driver đang nói cho bạn biết check nào fail.
Byte 3 đến 10 của page A0 chứa các compliance code của transceiver được mô tả trong SFF-8472 - các bit nói lên 10GBASE-SR, LR, ER, các mã SONET, các mã Fibre Channel và tương tự. Trên loại optic này cả tám byte đều bằng 0, đó là lý do thông báo gọi nó là type 0. Spec kỳ vọng ít nhất một bit nào đó trong field này phải được set; một compliance field toàn số 0 không phải là một mô tả module hợp lệ. Code EX cũ chưa bao giờ kiểm tra và đi thẳng vào parse trang diagnostics, driver mới hơn validate field này trước rồi mới từ chối coi module là một optic 10G đã biết. Đó là lý do có unknown cable và mất DOM. Dòng MX không chạy check đó trên cùng path, và đó chính xác là lý do vì sao cùng một part vẫn hoạt động ở đó.
Chứng minh điều này trước khi tranh luận với ai: vào shell và xcvrpeek page A0 trên port đó, rồi xem offset 3 đến 10. Toàn số 0 là chốt được vấn đề.
Sửa tại chỗ là chỗ chuyện này thường đổ vỡ. Về lý thuyết xcvrpoke ghi lại đúng những byte đó. Trên thực tế nhiều vendor khóa trang A0 và việc ghi trả về EIO, và không có gì bạn có thể làm được về chuyện đó từ phía switch. Thứ còn lại là nhà cung cấp: hoặc họ ship optic đã được lập trình với compliance code thật, hoặc họ ship với A0 mở khóa để bạn tự set bit. Nếu họ không làm được cả hai, thì đó là vấn đề của nhà cung cấp đội lốt Junos.
Có hai điều đáng chốt lại trước khi ai đó bắt đầu đoán mò.
Thứ nhất, đúng bản release trên từng máy. Bạn nói EX lên 12.3, vậy MX960 đang chạy gì? Nếu nó vẫn ở một nhánh cũ hơn thì hai máy không thực sự so sánh được với nhau, và sự khác biệt đó chưa nói lên điều gì cả.
Thứ hai, part ở phía MX có đúng là cùng một SFPP-C51-80-10GD từ cùng lô hàng không, hay là cùng model nhưng từ một đơn hàng khác? Các lô hàng khác nhau nhiều hơn người ta muốn.
Đăng
show interfaces diagnostics opticstừ cả hai đầu, cộng với mọi thứ messages log in ra khi bạn rút rồi cắm lại optic, không chỉ một dòng bạn đã trích.Cùng part ở cả hai đầu, SFPP-C51-80-10GD, cùng đơn hàng, serial liên tiếp nhau.
Trên MX960
show interfaces diagnostics opticscho ra đầy đủ: temperature, laser bias current, TX power, RX power. Trên EX4200 cùng lệnh đó chỉ in ra header của interface rồi tới dòng unknown cable, không gì khác. Cắm lại optic tạo raSFP+ of type 0 EEPROM is Mis Programmedtrong log và không gì thêm, bất kể tôi dùng port nào.Điều làm tôi khó chịu là trước khi upgrade, đúng cái optic này trong đúng chassis và port này báo DOM mà không một lời phàn nàn.
Đáng nói thêm là nửa read-only của chuyện này cũng tồn tại ở phía bên kia hàng rào. Trên Cisco,
show idprom interface <if> detaildump ra các byte định danh mà không cần xoay xở gì trong shell cả, khá tiện để kiểm tra một lô hàng trên một switch dự phòng trước khi mấy module đó đến gần một máy Juniper nào.Đọc thì ở đâu cũng vô hại. Ghi từ phía host lại là chuyện khác: xcvrpoke là một tool nội bộ, không được hỗ trợ như một cách để sửa module, và như đã nói nó bị vendor lock chặn khoảng phân nửa số lần dù sao đi nữa. Dùng nó để chứng minh EEPROM sai ở đâu, rồi đưa bằng chứng đó cho bên đã bán optic cho bạn.
Cùng loại vấn đề, triệu chứng hoàn toàn khác, phòng khi có ai lạc tới đây từ một lượt tìm kiếm.
Chúng tôi cắm một SFP WDM BiDi 1G không tên vào ge-0/0/1 của một EX4600 và interface đơn giản là không tồn tại. Thiếu trong
show interfaces terse, và bất kỳ lệnh nào nhắm vào nó đều trả vềerror: device ge-0/0/1 not found. Log ghiOPTIC State changed for port: 0/0/1rồi tớiFibre channel transceiver plugged in without Fibre channel configuration!!. EEPROM được code sao cho Junos phân loại module này là transceiver Fibre Channel thay vì Gigabit Ethernet, nên chẳng bao giờ có interface Ethernet nào được tạo cho nó cả. Không cấu hình nào sửa được chuyện đó; chỉ một module được code đúng mới làm được.Và không chỉ hàng rẻ tiền mới dính. Từng có một lô SFP+ 10G mang thương hiệu Citrix khiến các appliance NetScaler MPX và SDX ghi log
*** Unsupported SFP+/SFP type !lúc boot ngay trên hàng chính hãng của vendor. Những chiếc tốt mang nhãn revision A2 trên label, những chiếc lỗi bị trả về RMA. Code sai xảy ra ở mọi phân khúc giá.Xác nhận đúng, và cảm ơn vì các offset chính xác.
xcvrpeek trên page A0 cho thấy offset 3 đến 10 toàn số 0 trên từng cái SFPP-C51-80-10GD tôi kiểm tra, kể cả những cái còn nguyên hộp. xcvrpoke trả về ngay EIO, nên A0 bị khóa và không có gì để cứu vãn từ phía chúng tôi.
Đã quay lại nhà cung cấp với các byte offset và dòng log đã trích. Họ chấp nhận và đang re-code lại lô hàng với compliance code thật; những cái đang nằm trong MX960 thì cứ để nguyên đó, vì platform đó chẳng phàn nàn gì cả. Đánh dấu giải thích ở trên là câu trả lời.