Cluster de SRX1500 sobre fibra escura: porta HA CONTROL fica apagada com SFP-LH 740-011612
Dois SRX1500 ficam em data centers separados, a poucos quilômetros de distância, ligados por pares de fibra escura que são nossos ponta a ponta. Eles precisam subir como chassis cluster, o que significa que o link de controle tem que atravessar essa fibra em vez de um cordão óptico dentro de um único rack.
A montagem:
- dois Juniper SRX1500, com a mesma configuração de hardware
- Juniper SFP-LH 740-011612 na porta HA CONTROL de cada nó
- um par de fibra escura dedicado para o link de controle, com patch direto
- o módulo de cobre SFP-T que veio com o chassi, usado antes num teste back to back
Com o SFP-LH no lugar não acontece absolutamente nada. Nenhum LED na cage, nenhum link, e o cluster nunca se forma:
> show chassis cluster interfaces
Control link status: Down
Control interfaces:
Index Interface Status
0 em0 DownO que eu já fiz:
- movi o link de controle para o segundo par de fibra, nenhuma mudança em nenhum dos nós
- troquei os módulos entre os dois nós, mesmo resultado nos dois
- botei o SFP-T de volta como teste de sanidade, e ele ficou down até um restart completo do chassi, depois do qual subiu direto
Esse último ponto me incomoda mais do que a óptica morta. A porta HA CONTROL de um SRX1500 aceita o SFP-LH 740-011612 ou o SFP-SX 740-011613, seja lá o que for, ou só o SFP-T que vem de fábrica? E alguém já rodou um DWDM SFP nessa porta e funcionou?
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 4
Antes de culpar a óptica, o que o equipamento realmente vê naquela cage? Roda
show chassis hardwarecom o SFP-LH inserido e confere se aparece uma linha de Xcvr para o slot, nos dois nós. Se o módulo nem sequer é inventariado, isso não é um problema de fibra ou de comprimento de onda, e nenhuma troca de par vai mudar isso.Segunda coisa, dez minutos de trabalho: bota um desses módulos SFP-LH numa porta revenue contra um peer conhecido e bom. Se linkar lá e continuar apagado na cage HA, você separou o módulo da porta e pode parar de discutir sobre a planta de fibra.
Na metade da pergunta sobre DWDM, existe pelo menos um dado concreto: alguém rodando ópticas DWDM Champion ONE na série SRX1500 conseguiu fazer funcionar. Antes de seguir por esse caminho, confirme o comprimento de onda exato com o fabricante da óptica ou do DWDM primeiro, porque a Juniper não necessariamente vende um módulo para isso, e aí você está em óptica de terceiros com tudo que isso implica no momento em que abre um chamado.
A porta HA control é um animal diferente, e eu não assumiria que ela se comporta como uma porta revenue. Não existe lista de ópticas publicada para ela além do SFP-T que vem com o chassi, e o seu próprio teste diz que a cage não é relida em runtime: o módulo de cobre só voltou depois de um restart do chassi. Isso dá a entender que a porta é inventariada no boot e nada volta a escaneá-la depois.
Se o cluster precisa estar de pé logo, deixe o transporte fora do firewall. Termine o enlace longo em equipamento que vive de óptica, entregue a cada SRX um link curto no módulo que ele é conhecido por aceitar, e deixe o transporte ser dono do comprimento de onda. Menos elegante, bem mais rápido de entregar. Abra um chamado de qualquer forma, porque o fato de não existir uma lista de ópticas suportadas para essa porta já merece uma resposta por escrito.
Reforçando a parte de não confiar no estado da porta nessas caixas. A gente tem um cluster de dois SRX380-POE-AC no Junos 21.4R3-S4.9 onde a falha vai pro lado contrário: xe-0/0/17 e xe-0/0/18 reportam link UP com LEDs acesos e nenhuma fibra conectada a elas. Juniper SFP-SX 740-011613 como Xcvr 16-17, SFP+-10G-SR 740-021308 como Xcvr 18-19, os dois nós mostrando inventário idêntico em
show chassis hardware, eshow interfaces terseinsistindo que as interfaces estão up.Reencaixar os módulos não mudou absolutamente nada. Essas portas eram para um reth que acabamos construindo em ge-0/0/14-15, então ninguém saiu prejudicado, e eu nunca tive resposta se existe um PR por trás disso. Entre isso e a sua porta de controle apagada, eu não trataria o estado das ópticas num SRX em cluster como evidência de nada físico.
Duas observações extras para quando você avançar mais nesse caminho.
Se uma óptica DWDM acabar entrando na jogada, confira o grid antes de pedir: um tunable de 50 GHz contra uma óptica fixa de 100 GHz na outra ponta é uma forma bem conhecida de perder a noite, e no Junos o canal vem da opção de comprimento de onda, não de nada que você configure na interface. Também não entre em pânico se o equipamento reportar um número de canal que não bate com o que você configurou enquanto a luz está no comprimento de onda certo. Isso já apareceu bastante em tunables Cisco a ponto de a leitura da CLI não ser algo em que confiar.
No tema geral de documentação rala para essas cages: na mesma plataforma, um módulo de cobre SRX-SFP-1GE-T linka numa boa a 1 Gbps e se recusa a subir a 100 Mbps, com o guia de hardware chamando as portas SFP de 100/1000 enquanto o datasheet do módulo diz 10/100/1000. Ninguém conseguiu me dizer qual dos dois é verdade também.