Üçüncü parti SFP+ optikleri ikinci el bir DCS-7150S-24'te down kalıyor: enable3px flash dosyası hâlâ bir seçenek mi?
Lab için birkaç ikinci el Arista switch aldım ve doğrudan optik kapısına çarptım. Arista kodlu modüller link veriyor, pasif DAC kabloları link veriyor, ve üçüncü parti olan her şey portu down bırakıyor.
Lab tarafı:
- DCS-7150S-24, kullanılmış alındı, arkamda ne bir destek sözleşmesi ne de bir hesap ekibi var
- çeşitli üçüncü parti SFP+ modülleri
- rack içindeki kısa hatlar için pasif DAC kabloları
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes upŞimdiye kadar çözebildiklerim:
- DAC gelirken optiklerin gelmemesi bana bunun kablolama ya da ölü bir kafes değil, bir kodlama kontrolü olduğunu söylüyor
service unsupported-transceiver CUSTOMERNAME LICENSEKEYbiçiminde bir yapılandırma komutu var, ve bu açıkça elde etmenin hiçbir yolu olmayan bir anahtar istiyor- daha eski yazılar bir anahtar yerine flash üzerinde bir işaret dosyasından bahsediyor, ama bunun hangi nesle uygulandığını anlayamıyorum
Bu yaştaki bir kutu için iki mekanizmadan hangisi geçerli, ve flash dosyası bir 7150S'te hâlâ bir seçenek mi, yoksa geriye kalan tek yol anahtar mı?
Comments 6
O nesilde dosya geçerli, ve kulağa geldiği kadar kaba. EOS CLI'dan:
Boş bir dosya, içinde hiçbir şey yok - sadece var olması reload'dan sonra üçüncü parti optikleri açıyor. Bunun işe yaradığı platformların listesi uzun: DCS-7120T-4S, DCS-7050 ailesi ve tüm DCS-7150S serisi diğerlerinin yanında, ve her modelin dosyayı hâlâ dikkate alan en yeni bir EOS sürümü var, kabaca en eski kutularda 4.13.16M'den 7150S'te 4.23 train'ine kadar uzanıyor. Daha yeni switch'ler dosyayı tamamen görmezden geliyor.
Yani bir 7150S-24, modelin desteklediğinin ötesine geçmediğin sürece, o çizginin iyi tarafında. Anahtar yoluna hiç yaklaşmadan önce bunu dene.
O 7150S-24'te hangi EOS train'i var, ve satın aldıktan sonra yükselttin mi? Bu önemli, çünkü kesim noktası aile başına değil platform başına. Flag dosyasının 7048T, 7120T-4S, 7140T-8S, 7124 ve 7148 SFP+ varyantları, 7050 ve 7150S serisi ve 7548S-LC line card'larında çalıştığı belgelenmiş, ama onu hâlâ dikkate alan son EOS sürümü her biri için farklı.
Kullanılmış bir kutuda EOS'u zaten yükselttiysen, kendini numaranın dışına yükseltmiş olma ihtimalin epey yüksek, ve o zaman ucuz düzeltme bir anahtar aramak değil bir train aşağı inmek.
Kutu geldiğinden beri EOS'a hiç dokunmadım, yani hâlâ satıcının bıraktığı hangi train'deyse onda - ki bu şanslı çıktı. touch'ı, write memory'yi, reload'ı yaptım - ve daha önce ölü olan üçüncü parti SFP+ modülleri şimdi sıradan portlar olarak geldi. Ne anahtar, ne hesap ekibi, başka hiçbir şey gerekmedi. DAC'lar beklendiği gibi baştan sona çalışmaya devam etti.
Buraya daha yeni bir kutuyla düşen olursa: dosya orada gerçekten görmezden geliniyor, ve tek yol running configuration'da şöyle yaşayan müşteri başına kriptografik bir anahtar:
Anahtar destekten değil hesap ya da satış ekibinden geliyor - TAC unlock anahtarı vermeye yetkili değil ve seni hesap yönetimine geri gönderecek, ki switch ikinci el piyasadan geldiğinde bu bir çıkmaz sokak.
Lab kurulumları için tekrarlamaya değer: pasif DAC kabloları unlock durumu ne olursa olsun varsayılan olarak kabul ediliyor. Hatlar yeterince kısaysa, DAC ile kablolayıp optikleri gerçekten ihtiyaç duyan linkler için saklayarak tüm soruyu atlayabilirsin.
"Running configuration'da yaşıyor"a küçük bir düzeltme: birlikte çalıştığım daha eski kodda aynı komutun belgelenmemiş bir varyantı da vardı, yani yukarıdaki sözdizimiyle eşleşmeyen bir referansla karşılaşırsan, bu birinin yanlış yazmasından değil oradan geliyor.
Benim deneyimimde anahtar reboot olmadan da etkili oluyordu - komut girildikten hemen sonra çoğu üçüncü parti optik çalışmaya başladı, yine de birkaç modül ne olursa olsun reddetmeye devam etti. Bu, artık sahip olmadığım bir donanımda bir süre önceydi, o yüzden etrafında bir bakım penceresi planlamadan önce kendi kutunda kontrol et.
Bu karşılaştırma konu her açıldığında çıktığından: Cisco IOS-XE ve IOS XR'de eşdeğeri bir değil iki adım. Global komut tek başına yetmiyor, modülü alması gereken her fiziksel portta arayüz başına olanına da ihtiyacın var:
Product-ID kontrolünü atlayan arayüz başına satır, yani port en azından optiği yakmayı dener - modülün sonra çalışacağının bir sözü yok, sadece platformun onu reddetmeyi bıraktığının. Bunu IOS XR 5.3.3'te ve IOS-XE kutularında yaptım.
Çekince her iki üreticide de aynı, ve insanların bu konuda tartışmaya devam etmesinin nedeni de bu: bir arıza müşterinin kurduğu üçüncü parti bir transceiver'a izlenirse, garanti ya da sözleşme kapsamındaki destek esirgenebilir. Bir lab için sorun değil, production'da bilinçli olarak alınmaya değer bir karar.