Corrección de errores y avisos de preparación

Los errores y avisos de preparación pueden inhibir la capacidad de completar satisfactoriamente una comprobación de preparación. En este tema se proporciona información sobre cómo corregir distintos tipos de errores y avisos.

Ver más información en el registro de errores

Para ver mensajes de error detallados, conéctese a su host Ubuntu con SSH y utilice tail o less para examinar el archivo /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

Obtener detalles sobre errores de conectividad

Si la información disponible sobre los errores de conectividad no es suficiente, puede revisar el informe de diagnóstico detallado que se genera en los hipervisores vSRX Ubuntu. El precheck.log archivo proporciona diagnósticos detallados sobre las comprobaciones de validación de la preparación. Revise esta información para analizar más a fondo los errores de conectividad y determinar si se requieren cambios adicionales en la configuración.

  1. Inicie sesión en el hipervisor Ubuntu al que se hace referencia en el mensaje de error de la comprobación de preparación. El nombre del hipervisor se muestra en los detalles del error durante la operación de comprobación de disponibilidad.
  2. Accede al directorio vSRX.
    cd /home/vSRX
  3. Revise el archivo de registro de precheck.log comprobación de preparación.
    tail -f precheck.log

Corrección de errores de conectividad

Es posible que se encuentre con las dos categorías siguientes de errores de conectividad al realizar comprobaciones de disponibilidad:

  • Errores de conectividad SSH de host (Ubuntu)
  • Errores de conectividad SSH de pasarela (vSRX)

Muchos de estos errores ocurren porque las comprobaciones requieren acceso root SSH a la dirección IP privada para el SO anfitrión ( Ubuntu ), o la pasarela vSRX. Si falla una comprobación de conectividad SSH, la acción no puede continuar.

Para obtener más información sobre cómo establecer una sesión SSH, consulta Acceder al dispositivo mediante SSH. Tenga en cuenta que para el paso 3, el ejemplo que se da es con el usuario admin. Para una comprobación de preparación, sustituya el usuario root por el vSRX y el Hardware (host). Además, debe usar la IP privada con este procedimiento, no la pública.

Para comprobar la conectividad, abre una sesión SSH en la IP pública del host Ubuntu o en la IP privada vSRX's utilizando las credenciales de root que figuran en la sección Hardware (para un host Ubuntu ) o en la sección vSRX (para la pasarela) de la página de detalles Gateway Appliance. Asegúrese de que se puede establecer la sesión SSH.

Si no se puede establecer la sesión, compruebe los posibles problemas siguientes.

Para errores de conectividad SSH de host (Ubuntu):

  • ¿El cortafuegos de Ubuntu bloquea el acceso SSH a la IP privada? Las reglas de cortafuegos deben permitir el acceso SSH a la subred privada 10.0.0.0/8. Para obtener más información, consulte Rangos de IP de IBM Cloud para la red de servicio.
  • La contraseña de root que se indica en la página Detalles de dispositivo pasarela, ¿es la contraseña correcta para el usuario root? Si no lo es, pulse el enlace del dispositivo situado en la sección Hardware y vaya a Contraseñas. Selecciona Acciones > Editar credenciales y cambia la contraseña para que coincida con la contraseña de root real del host Ubuntu.
  • ¿Está inhabilitado el inicio de sesión root para el servidor SSH?
  • ¿Está inhabilitado o detenido el servidor SSH?
  • ¿Está inhabilitada la cuenta de usuario root en el host de Ubuntu?

Para errores de conectividad SSH de pasarela (vSRX):

  • ¿El cortafuegos de vSRX bloquea el acceso SSH a la IP privada? Las reglas de cortafuegos deben permitir el acceso SSH a la subred privada 10.0.0.0/8. Para obtener más información, consulte Rangos de IP de IBM Cloud para la red de servicio.
  • La contraseña de root que se indica en la página Detalles de dispositivo pasarela, ¿es la contraseña correcta para el usuario root? Si no es así, pulse el icono Editar Icono de edición situado junto a la contraseña de root y cambie la contraseña para que coincida con la contraseña de root real para vSRX.
  • ¿Está inhabilitada la cuenta de usuario root para el acceso SSH a vSRX?

Corrección del error 1119

El vSRX podría tener una configuración que bloquea el acceso a la consola local a través de telnet. Compruebe si existe la siguiente configuración y elimínela antes de volver a intentar la operación de comprobación previa:

set system ports console disable set system ports console insecure

Otros problemas pueden ser una contraseña incorrecta en vSRX.

En ocasiones, el error 1119 de comprobación de disponibilidad puede producirse incluso cuando la configuración vSRX parece válida y no se han configurado los ajustes esperados de la consola (establecer los puertos del sistema como consola desactivada o insegura). Este problema puede surgir debido a un archivo incompleto o /etc/hosts mal configurado en el host Ubuntu, lo que puede impedir la resolución correcta de localhost durante la prueba de telnet. Asegúrese de que localhost se asigna explícitamente a la dirección IP 127.0.0.1. Una asignación incorrecta o que falte puede impedir que el script de preparación se conecte al puerto de la consola vSRX.

Los siguientes comandos ilustran cómo configurar correctamente el archivo etc/hosts y asignarlo a su localhost.

Antes de mapear el localhost, el archivo /etc/hosts se ve como se muestra en el siguiente comando, donde la dirección IP 127.0.0.1 se mapea sólo al nombre del sistema host.

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

Después de mapear correctamente el localhost, el archivo /etc/hosts se ve como se muestra en el siguiente comando y el localhost está mapeado correctamente a la dirección IP 127.0.0.1.

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

Cuando actualice el archivo /etc/hosts en el sistema anfitrión con estos cambios y ejecute el comando telnet localhost (port-number), la conexión telnet a su host local tendrá éxito y se resolverá el error de comprobación previa.

Para identificar el número de puerto para la conexión telnet, ejecute el comando virsh dumpxml (VM-Instance-Name) | grep service en el sistema host y utilice el valor que se muestra para el servicio. Para identificar el nombre de la instancia de VM, utiliza el comando virsh list.

Corrección del error 1124

vSRX 18.4R1-S1 ha introducido una incompatibilidad que se documenta en este informe de problemas de Juniper. Necesita una cuenta de Juniper para acceder a este informe.

Si una interfaz de Ethernet (reth) redundante incluye vlan-tagging (que es el valor predeterminado), la interfaz también debe incluir la etiqueta vlan-id. En 18.4R1-S1, se ha podido confirmar una configuración sin la etiqueta vlan-id. Las versiones más recientes, como por ejemplo 19.4R2-S3, no permiten esta configuración.

Una configuración de ejemplo sin 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

La salida de esta configuración es:

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 solucionar este error, añada la etiqueta vlan-ida la configuración y vuelva a intentar la comprobación de preparación:

set interfaces reth2 unit 2058 vlan-id 2058

Corrección del error 1125

vSRX 18.4R1-S1 ha introducido una incompatibilidad que ha permitido que la configuración de syslog contenga las etiquetas structure-data y explicit-priority. En las versiones 19.4R2-S3 y posteriores, estas etiquetas ya no están permitidas.

Por ejemplo, la siguiente configuración de syslog contiene ambas etiquetas (set system syslog file messages structured-data y 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

La salida de esta configuración es:

[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 solucionar este problema, elimine una de las etiquetas de syslog de la configuración y vuelva a intentar la comprobación de preparación.

Corrección de comandos de configuración vSRX no soportados

Juniper vSRX contiene mandatos de CLI no documentados u ocultos. La configuración de vSRX no admite algunos de estos comandos, aunque en algunas versiones sí se puedan aplicar. A veces, el comportamiento puede cambiar inesperadamente entre versiones de release. La siguiente información detalla algunos comandos de configuración no compatibles conocidos al actualizar desde una versión anterior de vSRX. Es fundamental que elimines comandos no compatibles u ocultos de la configuración de vSRX antes de actualizar tu versión. Realiza este proceso incluso con comandos que no detecta la comprobación de preparación.

Corrección del error 1145

Para eliminar las políticas y configuraciones relacionadas con IDP. Ejecute los mandatos siguientes para recopilar todas las dependencias.

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

A continuación, suprima la stanza de configuración para cada una de estas dependencias.

Ejemplo:

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

Corrección del error 1147

Al igual que en la sección anterior, un cambio en la forma en que Junos analiza la configuración en la sección de seguridad puede provocar errores como:

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

Algunos ejemplos de esta configuración son:

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

El uso de * como carácter final y el prefijo ya no son válidos. Una configuración alternativa es:

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

Para solucionar este problema, modifique la configuración de vSRX según sea necesario, confirme y vuelva a intentar la comprobación de preparación.

Mandato set interfaces.. con tcp-mss

Es posible que la siguiente configuración no documentada se haya implementado en versiones anteriores a 20.4R2-S2, pero falla en 20.4R2-S2. Observe la salida de unsupported platform de show configuration en 19.4R3-S2.

[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;
    }
}

En 20.4R2-S2, la misma configuración no está permitida y falla con el error de sintaxis siguiente:

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

Esta situación provoca problemas al actualizar de una versión de pre-20.4R2-S2 a 20.4R2-S2, ya que falla la aplicación de la configuración anterior a la nueva versión, lo que hace que la actualización también falle.

Mandato set security datapath-debug..

set security datapath-debug se sabe que los comandos de configuración causan errores al actualizar. Elimine todos los mandatos datapath-debug de config y vuelva a intentar la comprobación de preparación. Por ejemplo, elimine mandatos como los siguientes:

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

Corrección de la advertencia 1176

Se ha detectado una configuración de VPN con establish-tunnels no establecida en immediately. Tras una actualización, es posible que el IKE no se active de inmediato, dependiendo de las negociaciones con la pasarela homóloga remota y de si hay tráfico de datos en curso. Sin establish-tunnels immediately, el túnel se establece con on-traffic. Con la sentencia establish-tunnels immediately, el túnel se establece inmediatamente cuando se confirma la configuración. Sin embargo, establish-tunnels immediately puede desencadenar un resultado no deseado cuando se configura en ambos extremos del túnel.

Para obtener más información, consulte (SRX)IPsec se activa cuando SRX-A es el iniciador, pero falla cuando SRX-A pasa a ser el respondedor en la base de conocimientos de Juniper. Consulte VPN(Seguridad) para obtener más información sobre estos ajustes.

Corrección de la advertencia 1177

Se han detectado una o más reglas de política de zona de seguridad con la configuración dynamic-application any indicada. Si el vSRX no está instalado con la licencia de Content Security Bundle (CSB) y la base de datos de la firma de la aplicación, esta configuración podría provocar una interrupción del tráfico debido a cambios en releases más recientes de vSRX, como por ejemplo 19.4R2-S3.

Por ejemplo, la siguiente configuración de política de seguridad contiene la etiqueta 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

Si está utilizando una configuración similar, se recomienda que instale la licencia de CSB y la base de datos de la firma de la aplicación o elimine la regla dynamic-application any.

Corrección del aviso 1179

La versión de vSRX que se ejecuta en Gateway no está certificada en IBM Cloud y no cuenta con soporte técnico. Operaciones como OS Reload y Rebuild Cluster sobrescriben la versión actual de vSRX, que no es compatible, con la versión que aparece en la página Detalles de la pasarela. Dado que la versión vSRX no está certificada en IBM Cloud, se recomienda ponerse en contacto con el servicio de asistencia de IBM para migrar a la versión certificada que se encuentra aquí: IBM Cloud Juniper vSRX supported versions.

Corrección del aviso 1180

La licencia de vSRX que se encuentra en Gateway no se ha adquirido a través de IBM Cloud y no cuenta con soporte técnico. Operaciones como OS Reload y Rebuild Cluster sobrescriben la licencia actual con la versión que aparece en la página Detalles de la puerta de enlace. Las licencias de vSRX soportadas se pueden encontrar aquí: Visualización y cambio de licencias de vSRX. Si la licencia se adquirió fuera de IBM Cloud, ponte en contacto con esa fuente de adquisición para obtener asistencia. En caso contrario, póngase en contacto con el servicio de asistencia de IBM para migrar a una licencia compatible de vSRX.

Corrección del aviso 1181

La licencia y la versión de vSRX en la pasarela no están soportadas. Consulte Corrección del aviso 1179 y Corrección del aviso 1180 para obtener ayuda para resolver estos avisos.