PA-3220: SFP+ interface hiç link vermiyor, sys.s1.p13.state board_port_sfp_invalid_0 gösteriyor
Bir PA-3220'den yeni bir core switch'e 10G uplink kaldırıyorum. Modül firewall'daki boş bir kafese takıldı, switch tarafı konfigüre edilmiş ve bekliyor, ve interface basitçe up gelmeyi reddediyor. Port LED'i yanıp sönüyor, bu da bana en azından modülün güç aldığını varsaydırdı.
- Palo Alto PA-3220, port 13'te modül
- jenerik 10G SFP+ optik, duplex LC
- o fiber hattındaki diğer çift üzerinden aynı optik tipi iki switch arasında 10G'de link veriyor
- HA çifti, ve bu active birim
State tree'nin o port hakkında söylediği:
show system state filter-pretty sys.s1.p13.state
board_port_sfp_invalid_0sys.s1.p13.status linkin down olduğunu raporluyor. Loglarda hiçbir şey yok, interface sadece ölü.
Şimdiye kadar denenenler:
- modülü yeniden oturttum ve konnektörleri temizledim
- aynı tipten ikinci bir optik taktım
- switch'ten switch'e çiftle fiberi kanıtladım, ki 10G'de link veriyor
- interface config'ini kontrol ettim, doğru zone'da sade bir layer 3 interface
board_port_sfp_invalid_0 burada gerçekte ne anlama geliyor, ve bu modül mü yoksa firewall mı?
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 3
O durum firewall'ın o kafesteki modülü reddetmesi, ve sebep elektriksel olmaktan çok daha sık mekanik. Kafesler önden bakınca birbirinin aynı görünüyor ve optik kusursuzca oturuyor, ama hiç 10G için kablolanmamış bir slot, ne kadar sağlıklı olursa olsun bir 10G optiği up getirmez.
O yüzden modülle değil port haritasıyla başla.
show system infotam platformu netleştirir, sonra o model için donanım referansı hangi kafeslerin gerçekten SFP+ olduğunu söyler. Bir PA-3220'de o blok 17-20 portları, yani port 13 hiçbir zaman aday olmadı. Önce optiği oraya taşı.Gerçek bir SFP+ kafesine girdikten sonra state tree'yi şu sırayla gez (aşağıdaki satırlar örnek olarak port 17'yi kullanıyor, taşıdığın hangi port ise onunla değiştir):
.phy, medyanın hiç okunup okunmadığını söyler: çalışan bir kafesteki bir 10G optik SFP-Plus-Fiber olarak dönmeli..statuslink durumu..state, zaten sahip olduğun invalid-module durumunun ortaya çıktığı yer, ve modül doğru bloğa oturunca kaybolmalı.Bir çiftle ilgili bir uyarı: portu active birimde kontrol et. Passive olanda, passive link state up olarak konfigüre edilmedikçe interface tasarım gereği down'dır.
Mesele buymuş. Optiği port 17'ye taşıdım,
.phyartık SFP-Plus-Fiber olarak dönüyor ve link hemen 10G'de up geldi, switch tarafında hiçbir değişiklik olmadan.Kafeslerin önden bakınca birbirinin aynı göründüğü için değiştirilebilir olduğunu varsaymıştım. Donanım referansı bu model için 17-20'yi gerçekten açıkça yazıyor, modüller ve patch kordonlarla bir akşamı harcamadan önce onu hiç açmamışım.
İyi sonuç, ve genel ders akılda tutmaya değer: SFP+ şeklinde bir delik, arkasında ne oturduğuna dair bir söz vermez.
Başka yerde aynı sınıftan bir tuzak. Bir QLogic QLE2562,
lspci'de 8Gb Fibre Channel HBA olarak görünür ve kafesleri tam olarak Ethernet optikleri gibi görünen modülleri alır, amaifconfig'te asla bir interface görünmez, çünkü kart sadece FC konuşur, başka hiçbir şey konuşmaz. OPX altındaki Dell S4048-ON ve S6010-ON'da, 407-BBOU SFP+ taşıyan bir 407-BBRO QSA adaptörü, yapılandırılmış hız 10000 okurken Operational State: DOWN ve Operating Speed: 0'da oturur, çünkü platform config'i o QSFP portu için 10G modunu hiçbir zaman taşımadı.Ve kafes doğruyken port hâlâ down kalıyorsa modül tipinin kendisine bak. Comware üzerindeki bir HPE 5940 (JH390A), gerçek 813874-B21 10GBASE-T SFP+ modülleriyle portları DOWN tutar ve IF_LOCAL_FAULT loglar, aynı portlarda 1G bakır SFP'ler ise çalışır. Oradaki çözüm interface'te
port up-modeidi, yan etkisiyle birlikte: port o zaman kalıcı olarak up raporlanır ve gerçek bir kablo kaybı artık sinyallenmez.