Visualização de mais informações no registro de erros

Para visualizar mensagens de erro detalhadas, conecte-se ao host Ubuntu com SSH e use tail ou less para examinar o arquivo /home/vSRX/precheck.log.

root@vsrx:~# tail -f /home/vSRX/precheck.log
br1.         8000.f6fb18672503  no       bond1
virbr0       8000.5254009fc6e7  yes
[2025-08-11 11:10:27.909405] The remote node control link is down
[2025-08-11 11:10:27.909501] Error: the control link of other node is down
=========================
Host: vsrx FAILURE - Return code:1126

Obter detalhes sobre erros de conectividade

Se as informações disponíveis sobre erros de conectividade não forem suficientes, você pode revisar a saída de diagnóstico detalhada gerada nos hipervisores vSRX Ubuntu. O precheck.log arquivo fornece diagnósticos detalhados sobre as verificações de validação de prontidão. Analise essas informações para analisar melhor os erros de conectividade e determinar se são necessárias alterações adicionais na configuração.

1. Faça login no hipervisor Ubuntu mencionado na mensagem de erro da verificação de prontidão. O nome do hipervisor é exibido nos detalhes do erro durante a operação de verificação de prontidão.
2. Acesse o diretório vSRX.

   cd /home/vSRX
   

3. Revise o arquivo de log da verificação precheck.log de prontidão.

   tail -f precheck.log
   

Corrigindo erros de conectividade

Você pode encontrar as duas categorias de erros de conectividade a seguir ao realizar verificações de prontidão:

• Erros de conectividade SSH do host (Ubuntu)
• Erros de conectividade SSH do gateway (vSRX)

Muitos desses erros ocorrem porque as verificações exigem acesso SSH raiz ao endereço IP privado do sistema operacional host ( Ubuntu ) ou do gateway vSRX. Se uma verificação de conectividade SSH falhar, não será possível continuar a ação.

Para obter mais informações sobre como estabelecer uma sessão SSH, consulte “Acessando o dispositivo usando SSH ”. Lembre-se de que, na etapa 3, o exemplo dado é com o usuário admin. Para uma verificação de prontidão, substitua o usuário root para o vSRX e para o hardware (host). Além disso, certifique-se de usar o seu IP privado com este procedimento, não o seu IP público.

Para verificar a conectividade, abra uma sessão SSH no endereço do host Ubuntu ou no IP privado vSRX's, utilizando as credenciais de root listadas na seção “Hardware” (para um host Ubuntu ) ou na vSRX (para o gateway) da página “Gateway Appliance Details ”. Assegure-se de que a sessão SSH possa ser estabelecida.

Se não for possível estabelecer a sessão, verifique os problemas potenciais a seguir.

Para os erros de conectividade SSH do host (Ubuntu):

• O firewall do Ubuntu está bloqueando o acesso SSH ao IP privado? As regras de firewall devem permitir o acesso SSH à sub-rede privada 10.0.0.0/8. Para obter mais informações, consulte Intervalos de IP da IBM Cloud para a rede de serviço.
• A senha raiz listada na página Detalhes do dispositivo de gateway é a correta para o usuário raiz? Caso não seja, clique no link de dispositivo na seção Hardware e navegue até Senhas. Selecione Ações > Editar credenciais e altere a senha para que corresponda à senha root real no host Ubuntu.
• O login raiz está desativado para o servidor SSH?
• O servidor SSH está desativado ou foi interrompido?
• A conta de usuário raiz está desativada no host do Ubuntu?

Para erros de conectividade SSH do gateway (vSRX):

• O firewall do vSRX está bloqueando o acesso SSH ao IP privado? As regras de firewall devem permitir o acesso SSH à sub-rede privada 10.0.0.0/8. Para obter mais informações, consulte Intervalos de IP da IBM Cloud para a rede de serviço.
• A senha raiz listada na página Detalhes do dispositivo de gateway é a correta para o usuário raiz? Se não, clique no ícone Editar ao lado da senha raiz e mude a senha para corresponder à senha raiz real para o vSRX.
• A conta do usuário raiz está desativada para acesso SSH ao vSRX?

Correção do erro 1119

O site vSRX pode ter uma configuração que bloqueia o acesso ao console local por meio de telnet. Verifique se há a seguinte configuração e remova-a antes de tentar novamente a operação de pré-checagem:

set system ports console disable set system ports console insecure

Outros problemas podem incluir uma senha incorreta para vSRX.

Às vezes, o erro 1119 da verificação de prontidão pode ocorrer mesmo quando a configuração vSRX parece válida e as configurações esperadas do console (set system ports console disable ou insecure) não estão configuradas. Esse problema pode ocorrer devido a um arquivo incompleto /etc/hosts ou configurado incorretamente no host Ubuntu, o que pode impedir a resolução bem-sucedida do localhost durante o teste telnet. Certifique-se de que localhost esteja explicitamente mapeado para o endereço IP 127.0.0.1. Um mapeamento ausente ou incorreto pode impedir que o script de preparação se conecte à porta do console vSRX.

Os comandos a seguir ilustram como configurar corretamente o arquivo etc/hosts e mapeá-lo para seu host local.

Antes de mapear o host local, o arquivo /etc/hosts tem a aparência mostrada no comando a seguir, em que o endereço IP 127.0.0.1 é mapeado apenas para o nome do sistema host.

root@test:~# cat /etc/hosts
127.0.0.1 test
127.0.1.1 ubuntu

Depois que você mapear corretamente o localhost, o arquivo /etc/hosts terá a aparência mostrada no comando a seguir e o localhost será mapeado corretamente para o endereço IP 127.0.0.1.

root@test:~# cat /etc/hosts
127.0.0.1 test localhost
127.0.1.1 ubuntu

Quando você atualiza o arquivo /etc/hosts no sistema host com essas alterações e executa o comando telnet localhost (port-number), a conexão telnet com o host local é bem-sucedida e o erro de pré-verificação é resolvido.

Para identificar o número da porta da conexão telnet, execute o comando virsh dumpxml (VM-Instance-Name) | grep service no sistema host e use o valor mostrado para o serviço. Para identificar o nome da instância do VM, use o comando virsh list``.

Corrigindo o erro 1124

O vSRX 18.4R1-S1 introduziu uma incompatibilidade documentada neste relatório de problemas do Juniper. Uma conta do Juniper é necessária para acessar este relatório.

Se uma interface Ethernet redundante (reth) incluir vlan-tagging (que é o padrão), ela também deverá incluir a tag vlan-id. Na 18.4R1-S1, era possível confirmar uma configuração sem a tag vlan-id. Versões mais recentes, como a 19.4R2-S3, não permitem essa configuração.

Uma configuração de exemplo sem o vlan-id:

set interfaces reth2 vlan-tagging
set interfaces reth2 mtu 9000
set interfaces reth2 redundant-ether-options redundancy-group 1
set interfaces reth2 unit 2058 family inet address xx.xx.xxx.1/26
commit check

A saída para esta configuração é:

root@vSRX-Node0# commit check
[edit interfaces reth2]
 ‘unit 2058’
   VLAN-ID must be specified on tagged ethernet interfaces
error: configuration check-out failed

Para lidar com esse erro, inclua a tag vlan-id na configuração e tente realizar novamente a verificação de prontidão:

set interfaces reth2 unit 2058 vlan-id 2058

Corrigindo o erro 1125

A 18.4R1-S1 do vSRX introduziu uma incompatibilidade que permitia que a configuração do syslog contivesse os rótulos structure-data e explicit-priority. Nas versões 19.4R2-S3 e posteriores, esses rótulos não são mais permitidos.

Por exemplo, a configuração de syslog a seguir contém ambos os rótulos (set system syslog file messages structured-data e set system syslog file default-log-messages explicit-priority).

set system syslog file messages any info
set system syslog file messages authorization warning
set system syslog file messages archive size 10m
set system syslog file messages archive files 10
set system syslog file messages archive world-readable
set system syslog file messages structured-data
set system syslog file interactive-commands interactive-commands info
set system syslog file interactive-commands archive size 1m
set system syslog file interactive-commands archive files 10
set system syslog file interactive-commands archive world-readable
set system syslog file interactive-commands structured-data
set system syslog file default-log-messages any warning
set system syslog file default-log-messages authorization info
set system syslog file default-log-messages user info
set system syslog file default-log-messages firewall any
set system syslog file default-log-messages interactive-commands info
set system syslog file default-log-messages explicit-priority
set system syslog file default-log-messages structured-data
set system syslog file kmd-logs daemon info
commit check

A saída para esta configuração é:

[Stage 3 - Build_vSRX][2021-01-11 15:38:00.623323] Commit check failed: CommitError(edit_path: [edit system syslog file default-log-messages], bad_element: explicit-priority, message: error: ‘explicit-priority’ cannot be configured if ‘structured-data’ is configured
error: configuration check-out failed: (statements constraint check failed))

Para corrigir esse problema, remova um dos rótulos de syslog da configuração e tente realizar novamente a verificação de prontidão.

Corrigindo os comandos de configuração não suportados do vSRX

O Juniper vSRX contém comandos CLI não documentados ou ocultos. A configuração do vSRX não suporta alguns desses comandos, embora, em algumas versões, eles possam ser confirmados. Às vezes, o comportamento pode mudar inesperadamente entre versões de liberação. As informações a seguir detalham alguns comandos de configuração conhecidos que não são compatíveis ao realizar a atualização a partir de uma versão mais antiga do vSRX. É fundamental que você remova os comandos não compatíveis ou ocultos da configuração do vSRX antes de atualizar sua versão. Repita esse processo mesmo com comandos que não sejam detectados pela verificação de prontidão.

Corrigindo erro 1145

Remover as políticas e configurações relacionadas ao IDP. Execute os seguintes comandos para reunir todas as dependências.

show security policies | match idp | display set
show system scripts | display set
show security idp | display set

Em seguida, exclua a sub-rotina de configuração para cada uma dessas dependencias

Exemplo:

delete security policies from-zone <$zone1> to-zone <$zone2> policy
<$policy> then permit application-services idp
delete system scripts commit file templates.xsl
delete security idp

Corrigindo o Erro 1147

Semelhante à seção anterior, uma mudança na maneira como o Junos analisa a configuração na seção de segurança pode levar a erros como:

error: Bad url pattern: *.googleapis.com/(*)

Exemplos dessa configuração incluem:

set security utm custom-objects url-pattern AZURE value *.googleapis.com/*
set security utm custom-objects url-pattern website value *services.site.com

O uso de * como o caractere à direita e o prefixo não é mais válido Uma configuração alternativa é:

set security utm custom-objects url-pattern AZURE value *.googleapis.com
set security utm custom-objects url-pattern website value *.services.site.com

Para corrigir esse problema, modifique a configuração vSRX conforme necessário, confirme e tente novamente a verificação de prontidão.

[edit]
root@asloma-vsrx-sa-sng0102-vsrx-vSRX# set interfaces st0 unit 0 family inet tcp-mss 1372
[edit]
root@asloma-vsrx-sa-sng0102-vsrx-vSRX# commit
commit complete
[edit]
.......
...
root@asloma-vsrx-sa-sng0102-vsrx-vSRX> show configuration interfaces st0
unit 0 {
    family inet {
        ##
        ## Warning: statement ignored: unsupported platform (vsrx)
        ##
        tcp-mss 1372;
    }
}

{primary:node0}[edit]
root@asloma-tc1-10g-csb-ha1-vsrx-vSRX# set interfaces st0 unit 0 family inet tcp-mss
                                                                             ^
syntax error.

set security datapath-debug capture-file pcap001
set security datapath-debug capture-file format pcap
set security datapath-debug capture-file size 10m
set security datapath-debug capture-file files 5
set security datapath-debug maximum-capture-size 1500

Corrigindo o aviso 1176

Uma configuração de VPN com establish-tunnels não configurada como immediately foi detectada. Após uma atualização, o IKE pode não ficar ativo imediatamente, dependendo das negociações com o gateway par remoto e se há tráfego de dados em andamento. Sem establish-tunnels immediately, o túnel é estabelecido com on-traffic. Com a instrução establish-tunnels immediately, o túnel é estabelecido imediatamente quando a configuração é confirmada. No entanto, establish-tunnels immediately poderá acionar um resultado indesejável quando configurado em ambas as extremidades do túnel.

Para obter mais informações, consulte o artigo (SRX)O IPsec é ativado quando o SRX-A é o iniciador, mas falha quando o SRX-A passa a ser o respondedor na Base de Conhecimento da Juniper. Consulte VPN(Segurança) para obter mais detalhes sobre essas configurações.

Corrigindo o aviso 1177

Foram detectadas uma ou mais regras de política de zona de segurança com a configuração “ dynamic-application any ”. Se o vSRX não for instalado com a licença Content Security Bundle (CSB) e o banco de dados de assinatura do aplicativo, essa configuração poderá causar a interrupção do tráfego devido a mudanças em liberações mais novas do vSRX, como a 19.4R2-S3.

Por exemplo, a configuração de política de segurança a seguir contém o rótulo dynamic-application any:

set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL match dynamic-application any
set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL match source-address SL8
set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL match destination-address SL8
set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL then permit

Ao usar uma configuração semelhante, recomenda-se instalar a licença CSB e o banco de dados de assinatura do aplicativo ou remover a regra dynamic-application any.

Corrigindo o aviso 1179

A versão do vSRX que é executada no Gateway não está certificada no site IBM Cloud e não tem suporte. Operações como “OS Reload” e “Rebuild Cluster” sobrescrevem a versão atual do “ vSRX ” — que não é suportada — pela versão listada na página “Detalhes do Gateway”. Como a versão vSRX não está certificada no site IBM Cloud, recomenda-se que você entre em contato com o suporte da IBM para migrar para a versão certificada disponível aqui: IBM Cloud Juniper vSRX versões-suportadas.

Corrigindo o aviso 1180

A licença do vSRX encontrada no Gateway não foi adquirida pelo site IBM Cloud e não tem suporte. Operações como “Reinstalação do SO” e “Reconstrução do cluster” substituem a licença atual pela versão listada na página “Detalhes do gateway”. As licenças do vSRX suportadas podem ser localizadas aqui: Visualizando e mudando as licenças do vSRX. Caso a licença tenha sido adquirida fora do site IBM Cloud, entre em contato com a fonte de aquisição em questão para obter suporte. Caso contrário, entre em contato com o suporte IBM para migrar para uma licença vSRX compatível.

Corrigindo o aviso 1181

A licença e a versão do vSRX no Gateway não são suportadas. Consulte Correção de aviso 1179 e Correção de aviso 1180 para obter ajuda para resolver esses avisos.