SFP+ DWDM bên thứ ba không lên link trên Arista 7050T với EOS 4.10.6 - có cách nào ngoài việc patch image không

Trước khi ai đó chỉ bạn đi patch image, hai điều đã.

Con 7050T đó thực sự đang bị buộc vào train EOS nào? Nếu bắt buộc phải giữ ở 4.10.6 thì một hack riêng cho build đó ít ra còn nhất quán với chính nó. Nếu có thể đổi bản, thì nên hiểu là phần xử lý transceiver đã được tổ chức lại ở các bản sau, và không công thức nào viết cho 4.10.6 còn dùng được ở đó.

Và nhà cung cấp đó thực sự burn được gì vào module? Đáng hỏi xem programmer của họ có mang profile Arista hay không, hay chỉ có coding Cisco theo từng platform như phần lớn bọn họ vẫn giữ - ví dụ linh kiện ASR9K cần profile riêng, và các vendor optic vẫn duy trì một bản. Recode lại cả lô rẻ hơn nhiều so với sống chung với một image đã sửa. Tách riêng ra: đã hỏi account team về unsupported-transceiver key chưa, hay lý do thương mại khiến việc đó không được đặt lên bàn?

Patch image này thực sự chạy được trên đúng build đó, và cũng không mất nhiều công - nhưng làm trên máy lab hay máy dự phòng thôi, đừng bao giờ làm trên thứ đang mang traffic thật.

Hình dung sơ qua: unzip EOS-4.10.6.swi và giữ lại các thành phần bên trong, gồm boot0, initrd-i386, linux-i386, rootfs-i386.sqsh và version. Giải nén root filesystem với quyền root, sửa agent, rồi đóng gói lại:

unsquashfs rootfs-i386.sqsh
mksquashfs squashfs-root/ rootfs-i386.sqsh
zip -Z store EOS-4.10.6a.swi boot0 initrd-i386 linux-i386 rootfs-i386.sqsh version

Chỗ sửa nằm trong squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py: comment bốn dòng gần line 172, những dòng assert trạng thái presence rồi chạy authentication cho transceiver. Cờ -Z store trong lệnh zip không phải tùy chọn, swi bắt buộc phải giữ ở dạng không nén thì máy mới boot được.

Sau đó cổng sẽ lên với bất kỳ thứ gì cắm vào, vì chẳng còn gì validate nữa. Đánh đổi hai thứ: không còn vendor support trên image đã sửa, và patch này chỉ gắn với đúng build này, nên giữ lại .swi gốc trên flash để boot ngược lại khi có gì đó trục trặc.

Trả lời mấy câu hỏi ở trên: đây là một hộp dự phòng không có support contract, và nhà cung cấp không hề có profile Arista trong programmer của họ - họ chỉ code cho platform Cisco, hết danh sách, nên recode lại lô này không phải là lựa chọn được chào. Hướng account team thì không phải đóng hẳn, chỉ là không giúp được gì cho tuần này.

Đã build lại 4.10.6 theo đúng mô tả, boot image đã patch, và cả hai cổng DWDM lên ngay lần thử đầu tiên. Image gốc vẫn nằm trên flash. Link ổn định từ đó tới giờ, và đầu xa không thấy gì bất thường.

Mừng là chạy được, nhưng phải thẳng thắn với chính mình về tuổi thọ của patch đó, vì cả thread ở trên nghe có vẻ tổng quát hơn thực tế.

Nó được viết riêng cho 4.10.6 và không gì khác. Có người từng hỏi cách lặp lại trên 4.14.5F, 4.14.7M và 4.23.8M mà chẳng ai đăng được câu trả lời chạy được, vì transceiver manager đã được tổ chức lại ở các bản sau và bốn dòng đó không còn nằm sẵn đó chờ bạn nữa. Mỗi lần upgrade cũng thay luôn image, nên patch biến mất và cổng rớt ngay lần bảo trì định kỳ tiếp theo.

Những hướng sống sót qua một lần upgrade là key service unsupported-transceiver riêng cho từng khách hàng do account team cấp, và trên các platform đời cũ hơn là file marker enable3px. Dùng image đã patch để giữ một hộp cũ còn hữu dụng, chứ đừng biến nó thành chuẩn cho cả mạng.

Cùng một cuộc chiến ở phía Cisco, có thêm chi tiết đáng mang qua đây. SFP+ DWDM 80 km bên thứ ba (Pro10Optix, dán nhãn SFP-10G-DWDM-192) từng chạy trong switch Catalyst 6500 không vấn đề gì. Chuyển sang cổng SFP+ tích hợp sẵn của một ASR 9001 trên IOS XR 5.3.3 thì nhận được:

%PLATFORM-SFP-3-DEV_SFP_SUPPORTED_ERROR: SFP Module is not supported
%PLATFORM-SFP-3-DEV_SFP_PID_NOT_SUPPORTED: Not supported Product ID

LED port đỏ, interface down, trạng thái báo mất link hoặc low light mà không có loopback nào, bước sóng đọc về là 0 nm và laser không bao giờ phát. transceiver permit pid all trên interface tự nó không đổi được gì, và service unsupported-transceiver ở mức global thêm vào cũng không cứu được lô đó. Platform này đòi part number theo khuôn DWDM-SFP10G-xx.yy từ ma trận optic riêng của nó, còn một PID generic thì không map vào bất kỳ optic được hỗ trợ nào cả, nên chẳng còn gì để override nới lỏng.

Có người khác trên cùng bản đó lại chạy được module Skylane SPDTU080100D139 80 km trên một con 9001 - nhưng chỉ khi cấu hình cả hai lệnh cùng lúc, nếu không interface sẽ không tự phục hồi sau một lần link bounce. Lô bị lỗi cuối cùng được đổi lấy module được code đúng chuẩn.

Thêm một điều giúp đỡ mất một vòng đi lại khi quay lại hỏi nhà cung cấp: yêu cầu họ code theo platform, chứ không phải theo brand. Phần lớn các thread kiểu này là module tự nhận đúng vendor nhưng mang part number mà ma trận của platform chưa từng biết tới, và các override kiểu permit chỉ nới lỏng kiểm tra cho những module vốn dĩ đã trông đúng trong mắt thiết bị.

Trong lúc họ còn đang giữ module trên bàn thử, yêu cầu họ xác nhận EEPROM tuân thủ nghiêm ngặt SFF-8472. Dữ liệu A2h cẩu thả sẽ đọc ra toàn thứ vô nghĩa - bước sóng 0 nm nhắc ở trên chính xác là kiểu đó - và một khi dữ liệu đọc ra đã sạch mà platform vẫn từ chối linh kiện, bạn sẽ có thứ cụ thể để đưa cho vendor support thay vì một lập luận chung chung về optic bên thứ ba.