Üçüncü taraf DWDM SFP+, EOS 4.10.6'lı bir Arista 7050T'de down kalıyor - image'i patchlemek dışında bir yol var mı

Biri seni image'e yönlendirmeden önce iki şey.

O 7050T'de gerçekte hangi EOS hattına bağlısın? 4.10.6'da kalmak zorundaysa build'e özgü bir hack en azından kendi içinde tutarlı. Taşıyabiliyorsan, transceiver işlemenin sonraki release'lerde yeniden düzenlendiğini ve 4.10.6 için yazılmış hiçbir tarifin aktarılmadığını bil.

Ve o tedarikçi gerçekte modüllere ne yazabiliyor? Programlayıcılarının hiç Arista profili taşıyıp taşımadığını, yoksa çoğunun elinde tuttuğu platform başına Cisco kodlamasını mı sorgulamakta fayda var - mesela ASR9K parçaları kendi profillerini gerektiriyor ve optik vendor'ları bunu gerçekten sürdürüyor. Partiyi yeniden kodlatmak, modifiye bir image ile yaşamaktan çok daha ucuz. Ayrıca: account team'inden unsupported-transceiver anahtarını istedin mi, yoksa bu ticari nedenlerle masada değil mi?

Image patch'i tam olarak bu build'de çalışıyor, ve fazla iş de değil - ama bunu bir lab ya da yedek kutuda yap, trafik taşıyan hiçbir şeyde asla.

Şekli şöyle: EOS-4.10.6.swi'yi unzip et ve üyelerini tut, bunlar boot0, initrd-i386, linux-i386, rootfs-i386.sqsh ve version. Root dosya sistemini root olarak aç, agent'ı düzenle, tekrar paketle:

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

Düzenlemenin kendisi squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py içinde: presence durumunu assert eden ve sonra transceiver authentication'ı çalıştıran, 172. satır civarındaki dört satırı yorum satırına al. zip'teki -Z store opsiyonel değil, swi sıkıştırılmamış kalmak zorunda yoksa kutu boot etmez.

Ondan sonra portlar ne takarsan tak ayağa kalkıyor, çünkü artık hiçbir şey doğrulamıyor. İki bedeli var: modifiye bir image'de vendor desteğin yok, ve patch bu build'e bağlı, o yüzden bir şeyler ters gittiğinde geri boot edebilmek için stok .swi'yi flash'ta tut.

Yukarıdaki soruları yanıtlamak gerekirse: kutu üzerinde support sözleşmesi olmayan bir yedek, ve tedarikçinin programlayıcısında hiç Arista profili yok - Cisco platformları için kodluyorlar ve liste orada bitiyor, yani bu partiyi yeniden kodlatmak masada değil. Account team yolu masadan kalkmadı, sadece bu hafta bana yardımcı olmuyor.

4.10.6'yı tarif edildiği gibi yeniden derledim, patch'lenmiş image'i boot ettim, ve her iki DWDM portu da ilk denemede ayağa kalktı. Stok image hâlâ flash'ta duruyor. O zamandan beri link sabit, ve karşı uç olağandışı hiçbir şey görmüyor.

İşe yaramasına sevindim, ama o patch'in raf ömrü konusunda kendine karşı dürüst ol, çünkü yukarıdaki thread bunu olduğundan daha genel gösteriyor.

Bu sadece 4.10.6 için yazılmış, başka hiçbir şey için değil. İnsanlar bunu 4.14.5F, 4.14.7M ve 4.23.8M'de nasıl tekrarlayacaklarını sordu ve kimse hiç çalışan bir cevap paylaşmadı, çünkü transceiver manager sonraki release'lerde yeniden düzenlendi ve o dört satır orada seni bekliyor olmayacak. Her upgrade ayrıca image'i değiştiriyor, yani patch gidiyor ve biri rutin bakım yaptığı an portlar düşüyor.

Bir upgrade'den sağ çıkan yollar, account team'in verdiği müşteriye özel service unsupported-transceiver anahtarı, ve eski platformlarda enable3px marker dosyası. Patch'lenmiş image'i eski bir kutuyu kullanışlı tutmak için kullan, ağ için bir standart olarak değil.

Cisco tarafında da aynı mücadele, taşınmaya değer bir detayla. Üçüncü taraf 80 km DWDM SFP+ (Pro10Optix, SFP-10G-DWDM-192 etiketli) Catalyst 6500 switch'lerinde sorunsuz çalışıyordu. Bir ASR 9001'in IOS XR 5.3.3 çalıştıran dahili SFP+ portlarına taşındığında şunu verdiler:

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

Kırmızı port LED'i, interface down, durum loopback olmadan link loss ya da low light olarak raporlanıyor, dalga boyu 0 nm olarak okunuyor ve lazer hiç ateşlenmiyor. Arayüzdeki transceiver permit pid all tek başına hiçbir şeyi değiştirmedi, üstüne global service unsupported-transceiver da o partiyi kurtarmadı. Platform kendi optik matrisinden DWDM-SFP10G-xx.yy şeklinde bir parça numarası bekliyor, ve generic bir PID hiçbir desteklenen optiğe eşlenmiyor, yani override'ın gevşetecek hiçbir şeyi yok.

Aynı release'de başka biri bir 9001'de Skylane SPDTU080100D139 80 km modüllerini çalıştırmayı başardı - ama sadece her iki komut da konfigüre edilmişken, aksi halde arayüz bir link bounce'dan sonra kendini toparlamıyordu. Başarısız olan parti sonunda düzgün kodlanmış modüllerle değiştirildi.

Tedarikçiye geri döndüğünde bir gidiş-geliş kazandıran bir şey ekleyeyim: markaya göre değil, platforma göre kodlamalarını iste. Bu thread'lerin büyük bir kısmı doğru vendor olarak tanımlanan ama platformun matrisinin hiç duymadığı bir parça numarası taşıyan modüller, ve permit tarzı override'lar sadece kutuya zaten doğru görünen modüller için kontrolü gevşetiyor.

Modüller tezgahtayken, EEPROM'un kesinlikle SFF-8472 uyumlu olduğunu doğrulatın. Özensiz A2h verisi anlamsız okunuyor - yukarıda bahsedilen 0 nm dalga boyu tam olarak bu tarz - ve okuma temiz olduğunda ve platform parçayı yine de reddettiğinde, üçüncü taraf optikler hakkında genel bir tartışma yerine vendor desteği için elinde somut bir şey oluyor.