Optic SFP+ bên thứ ba không lên trên DCS-7150S-24 hàng cũ: file flash enable3px còn dùng được không?
Tôi tậu được vài switch Arista hàng cũ cho lab và đâm thẳng vào rào chắn optic. Module mã hóa kiểu Arista thì lên link, cáp DAC passive thì lên link, còn bất cứ thứ gì bên thứ ba đều khiến port ở trạng thái down.
Phía lab:
- DCS-7150S-24, mua hàng đã qua sử dụng, không có support contract và cũng không có account team đứng sau
- một mớ module SFP+ bên thứ ba đủ loại
- cáp DAC passive cho các đoạn ngắn trong rack
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes upNhững gì đã tìm ra được đến giờ:
- DAC lên link trong khi optic thì không cho thấy đây là kiểm tra mã hóa, không phải do dây cáp, cũng không phải cage chết
- có một lệnh cấu hình dạng
service unsupported-transceiver CUSTOMERNAME LICENSEKEY, rõ ràng là cần một key mà tôi không có cách nào lấy được - các bài viết cũ hơn nhắc đến một file đánh dấu trên flash thay vì cần key, nhưng tôi không biết điều đó áp dụng cho thế hệ nào
Trong hai cơ chế đó, cái nào áp dụng cho một con máy đời này, và file flash đó có còn dùng được trên 7150S không, hay key là con đường duy nhất còn lại?
Comments 6
Ở thế hệ đó là file, và nó thô sơ đúng như nghe qua. Từ EOS CLI:
Một file rỗng, không có gì bên trong - chỉ riêng sự tồn tại của nó đã bật optic bên thứ ba sau khi reload. Danh sách các platform hoạt động theo cách này khá dài: DCS-7120T-4S, cả dòng DCS-7050 và toàn bộ dòng DCS-7150S trong số đó, và mỗi model có một bản EOS mới nhất còn tôn trọng file này, dao động khoảng từ 4.13.16M trên các máy đời cũ nhất đến train 4.23 trên 7150S. Switch đời mới hơn thì bỏ qua file này hoàn toàn.
Vậy một 7150S-24 đang nằm ở phía tốt của ranh giới đó, miễn là bạn chưa lên đời vượt quá những gì model này hỗ trợ. Thử cách này trước khi tính đến hướng dùng key.
Con 7150S-24 đó đang chạy train EOS nào, và bạn có nâng cấp nó sau khi mua không? Điều này quan trọng, vì ranh giới cắt được tính theo từng platform chứ không theo cả họ máy. File cờ này được ghi nhận là hoạt động trên 7048T, 7120T-4S, 7140T-8S, các biến thể SFP+ 7124 và 7148, dòng 7050 và 7150S, cùng line card 7548S-LC, nhưng bản EOS cuối cùng còn tôn trọng nó lại khác nhau ở từng model.
Nếu bạn đã nâng cấp EOS trên một máy hàng cũ, rất có khả năng bạn đã tự nâng cấp mình ra khỏi mẹo này, và khi đó cách rẻ nhất là hạ xuống train cũ hơn thay vì đi săn key.
Chưa hề đụng vào EOS từ lúc máy về tay, nên nó vẫn ở đúng train mà người bán để lại, hóa ra lại may mắn. Làm đúng touch, write memory, reload - và các module SFP+ bên thứ ba trước đây chết nay lên như port bình thường. Không cần key, không cần account team, không cần gì thêm. DAC thì vẫn chạy bình thường suốt, đúng như dự đoán.
Với ai lạc vào đây với một con máy đời mới hơn: file đó thực sự bị bỏ qua, và con đường duy nhất là một key mã hóa riêng cho từng khách hàng, nằm trong running configuration dưới dạng
Key này đến từ account team hoặc sales team, không phải từ support - TAC không có thẩm quyền cấp key mở khóa và sẽ đẩy bạn quay lại account management, một ngõ cụt khi switch đến từ thị trường đồ cũ.
Đáng nhắc lại cho các lab: cáp DAC passive mặc định luôn được chấp nhận bất kể trạng thái mở khóa thế nào. Nếu đoạn cáp đủ ngắn, bạn có thể né hẳn cả câu hỏi này bằng cách đi DAC và chỉ giữ optic cho những link thực sự cần đến nó.
Đính chính nhỏ cho “nằm trong running configuration”: trên bản code cũ hơn tôi từng làm việc cùng còn có một biến thể không có tài liệu của cùng lệnh đó, nên nếu bạn gặp một tham chiếu không khớp cú pháp ở trên, đó là do biến thể này chứ không phải ai đó gõ sai.
Theo kinh nghiệm của tôi thì key có hiệu lực mà không cần reboot - phần lớn optic bên thứ ba bắt đầu chạy ngay sau khi gõ lệnh, dù có vài module vẫn từ chối dù làm gì đi nữa. Đó là chuyện từ khá lâu rồi trên phần cứng tôi không còn giữ nữa, nên hãy tự kiểm tra trên máy của bạn trước khi lên kế hoạch cho một cửa sổ bảo trì xoay quanh nó.
Vì sự so sánh này cứ lặp lại mỗi khi chủ đề này được nhắc tới: trên Cisco IOS-XE và IOS XR, cơ chế tương đương là hai bước chứ không phải một. Lệnh global một mình là chưa đủ, còn cần thêm lệnh theo từng interface trên mỗi port vật lý cần nhận module:
Dòng theo interface mới là thứ bỏ qua kiểm tra product-ID, nên port ít nhất sẽ thử bật sáng optic - không đảm bảo module sau đó hoạt động, chỉ đảm bảo platform ngừng từ chối nó. Tôi đã làm việc này trên IOS XR 5.3.3 và trên các máy IOS-XE.
Lưu ý giống nhau ở cả hai vendor, và đó là lý do người ta cứ tranh cãi mãi về chuyện này: nếu một lỗi bị truy ra là do transceiver bên thứ ba do khách tự lắp, support theo warranty hay theo hợp đồng có thể bị từ chối. Ổn cho lab, nhưng là quyết định cần cân nhắc có ý thức khi dùng ở production.