PA-3220: interface SFP+ nunca sobe link, sys.s1.p13.state mostra board_port_sfp_invalid_0
Estou subindo um uplink de 10G de um PA-3220 para um core switch novo. O módulo entrou num cage livre do firewall, o lado do switch está configurado e esperando, e a interface simplesmente se recusa a subir. O LED da porta pisca, o que me fez achar que o módulo pelo menos estava sendo alimentado.
- Palo Alto PA-3220, módulo na porta 13
- óptica SFP+ de 10G genérica, LC duplex
- o mesmo tipo de óptica linka em 10G entre dois switches no outro par dessa rota de fibra
- par HA, e essa é a unidade ativa
O que a state tree diz sobre a porta:
show system state filter-pretty sys.s1.p13.state
board_port_sfp_invalid_0sys.s1.p13.status reporta o link caído. Nada nos logs, a interface está simplesmente morta.
Já tentei:
- reencaixei o módulo e limpei os conectores
- troquei por uma segunda óptica do mesmo tipo
- provei a fibra com o par switch a switch, que linka em 10G
- conferi a config da interface, é uma interface layer 3 simples na zona certa
O que board_port_sfp_invalid_0 realmente significa aqui, e isso é o módulo ou o firewall?
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
Essa condição é o firewall recusando o módulo naquele cage, e a causa é mecânica muito mais vezes do que elétrica. Os cages parecem idênticos por fora e a óptica encaixa perfeitamente, mas um slot que nunca foi cabeado para 10G não vai subir uma óptica de 10G por mais saudável que ela esteja.
Então comece pelo mapa de portas, não pelo módulo.
show system infofixa a plataforma exata, depois a referência de hardware desse modelo diz quais cages são realmente SFP+. Num PA-3220 esse bloco é as portas 17-20, então a porta 13 nunca foi candidata. Mova a óptica para lá primeiro.Uma vez que ela esteja num cage SFP+ de verdade, percorra a state tree nessa ordem (as linhas abaixo usam a porta 17 como exemplo, troque pela porta para onde você moveu):
.phydiz se a mídia chegou a ser lida: uma óptica de 10G num cage funcional deve voltar como SFP-Plus-Fiber..statusé o estado do link..stateé onde a condição de módulo inválido que você já tem aparece, e ela deve sumir assim que o módulo estiver no bloco certo.Uma ressalva com um par: confira a porta na unidade ativa. Na passiva a interface fica down por design, a menos que o passive link state esteja configurado como up.
Era isso. Movi a óptica para a porta 17,
.phyagora volta como SFP-Plus-Fiber e o link subiu em 10G na hora, sem nenhuma mudança do lado do switch.Eu tinha assumido que os cages eram intercambiáveis porque parecem idênticos por fora. A referência de hardware deixa claro 17-20 para esse modelo, eu só nunca tinha aberto ela antes de perder uma noite inteira com módulos e patch cords.
Bom resultado, e a lição geral vale guardar: um buraco no formato de SFP+ não é promessa nenhuma sobre o que está por trás dele.
Mesma classe de armadilha em outro lugar. Um QLogic QLE2562 aparece no
lspcicomo uma HBA Fibre Channel de 8Gb e os cages dele aceitam módulos que parecem exatamente ópticas Ethernet, mas nenhuma interface aparece noifconfig, porque a placa fala FC e mais nada. Em Dell S4048-ON e S6010-ON sob OPX, um adaptador QSA 407-BBRO carregando um SFP+ 407-BBOU fica em Operational State: DOWN com Operating Speed: 0 enquanto a velocidade configurada mostra 10000, porque a config da plataforma nunca carregou o modo 10G para aquela porta QSFP.E quando o cage está certo e a porta continua down, olhe para o tipo do módulo em si. Um HPE 5940 (JH390A) em Comware mantém as portas DOWN com módulos SFP+ 10GBASE-T 813874-B21 genuínos e loga IF_LOCAL_FAULT, enquanto SFPs de cobre de 1G funcionam nas mesmas portas. O workaround ali foi
port up-modena interface, com o efeito colateral de que a porta passa a ser reportada up permanentemente e uma queda de cabo real para de ser sinalizada.