EN ESTA PÁGINA
No se puede administrar el nodo secundario de un clúster de chasis mediante J-Web
No se puede actualizar un clúster de chasis mediante la actualización de software en servicio
Configuración del comando del enrutador de respaldo en el clúster de chasis
No se puede actualizar un clúster de chasis mediante la actualización de software en servicio
Solución de problemas de administración de clústeres de chasis
No se puede administrar un clúster de chasis de la serie SRX mediante el puerto de administración o los puertos de ingresos
Problema
Descripción
No se puede administrar el clúster de chasis de la serie SRX mediante el puerto de administración o los puertos de ingresos.
Ambiente
Clúster de chasis de la serie SRX
Diagnóstico
¿Qué nodo del clúster de chasis está utilizando para administrar el clúster?
Nodo principal: proceda a:
Administre el clúster de chasis mediante J-Web.
Nota:Puede usar J-Web para administrar solo el nodo principal.
Administre el clúster de chasis mediante el puerto de ingresos o el puerto de administración fxp0.
Nota:Puede utilizar el puerto de ingresos o el puerto de administración fxp0 para administrar el nodo principal.
Nodo secundario: proceda a gestionar el clúster de chasis mediante el puerto de administración fxp0
Nota:Sólo puede administrar el nodo secundario mediante el puerto de administración fxp0.
Resolución
- Administrar el clúster de chasis mediante J-Web
- Administrar clúster de chasis mediante el puerto de ingresos o el puerto de administración fxp0
- Administrar el clúster de chasis mediante el puerto de administración fxp0
- ¿Qué sigue?
- Administrar el clúster de chasis mediante J-Web
- Administrar clúster de chasis mediante el puerto de ingresos o el puerto de administración fxp0
- Administrar el clúster de chasis mediante el puerto de administración fxp0
- ¿Qué sigue?
Administrar el clúster de chasis mediante J-Web
Puede usar J-Web para administrar solo el nodo principal.
-
Conecte una consola al nodo principal.
-
Con la CLI, ejecute el
show system services web-managementcomando. -
Compruebe si la interfaz de circuito cerrado (lo0) está configurada en la configuración HTTP/HTTPS de administración web. Consulte Administración web (Servicios del sistema) .
-
Si la interfaz de circuito cerrado (lo0) está configurada en la configuración HTTP/HTTPS de administración web, ejecute el comando para quitar la
delete system services web-management http interface lo.0interfaz de circuito cerrado. -
Confirme el cambio y compruebe si ahora puede administrar el clúster de chasis.
-
Si sigue sin poder administrar el clúster de chasis, vaya a Administrar clúster de chasis mediante el puerto de ingresos o el puerto de administración fxp0.
Administrar clúster de chasis mediante el puerto de ingresos o el puerto de administración fxp0
Puede utilizar el puerto de ingresos o el puerto de administración fxp0 para administrar el nodo principal.
-
Conéctese a una consola utilizando el puerto de ingresos del nodo principal que desea utilizar como interfaz de administración.
-
Compruebe la configuración de la interfaz de administración:
-
Compruebe que los servicios del sistema necesarios (SSH, Telnet, HTTP) estén habilitados en el nivel jerárquico host-inbound-traffic de la zona correspondiente:
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } } -
Compruebe que los servicios del sistema necesarios (SSH, Telnet, HTTP) estén habilitados en el nivel jerárquico system services :
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
-
-
¿Funciona el ping a la interfaz de administración?
-
Yes: Consulte No se puede administrar un clúster de chasis de la serie SRX mediante fxp0 cuando el destino en el enrutador de reserva es 0/0. Si esta solución no funciona, vaya a Qué sigue para abrir un caso con el soporte técnico de Juniper Networks.
-
No: Continúe con el paso 4.
-
-
Con la CLI, ejecute el
show interfaces tersecomando:En la salida, ¿está el estado de
FXP0 interfaceArriba y proporciona una dirección IP?-
Yes: Continúe con el paso 5.
-
No: Compruebe lo siguiente:
-
Con la CLI, compruebe que la interfaz fxp0 esté configurada correctamente: show groups.
Ejemplo de salida:
root@srx# show groups node0 { system { host-name SRX3400-1; backup-router 192.168.1.254 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 192.168.1.1/24; } } } } } node1 { system { host-name SRX3400-2; backup-router 192.168.1.254 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 192.168.1.2/24; } } } } } } apply-groups "${NODE}"; system { services { ftp; ssh; telnet; } } -
Compruebe el estado del cable que está conectado a la fxp0 interfaz. ¿El cable está en buenas condiciones?
-
Yes: Continúe con el siguiente paso.
-
No: Reemplace el cable e intente administrar el clúster del chasis. Si sigue sin poder administrar el clúster de chasis, continúe con el paso siguiente.
-
-
Con la CLI, compruebe si hay contadores de errores incrementales: show interfaces fxp0.0 extensive.
-
-
-
Compruebe si la dirección IP de la interfaz y la dirección IP del dispositivo de administración están en la fxp0 misma subred.
-
Yes: Continúe con el paso 6.
-
No: Con la CLI, compruebe si hay una ruta para la dirección IP del dispositivo de administración: show route <management device IP>:
-
Si no existe una ruta para la dirección IP del dispositivo de administración, agregue una ruta para la subred de administración en la inet.0 tabla con el siguiente salto como dirección IP del enrutador de reserva.
-
-
-
Con la CLI, compruebe si hay una entrada ARP para el dispositivo de administración en la puerta de enlace de servicios: show arp no-resolve | match <ip>.
-
Yes: Compruebe si el clúster de chasis tiene varias rutas al dispositivo de administración: show route <device-ip>.
-
Yes: Podría haber rutas al dispositivo de administración a través de la interfaz fxp0 y otra interfaz que conduzca a un enrutamiento asimétrico. Vaya a Qué sigue para abrir un caso con el soporte técnico de Juniper Networks.
-
No: Proceda a Administrar el clúster de chasis mediante el puerto de administración fxp0.
-
-
No: Vaya a Qué sigue para abrir un caso con el soporte técnico de Juniper Networks.
-
Administrar el clúster de chasis mediante el puerto de administración fxp0
Solo puede usar el puerto de administración fxp0 para administrar el nodo secundario.
-
Compruebe la configuración de la interfaz de administración en el nodo secundario:
-
Compruebe que los servicios del sistema necesarios (SSH, Telnet, HTTP) estén habilitados en el nivel jerárquico host-inbound-traffic :
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } } -
Compruebe que los servicios del sistema necesarios (SSH, Telnet, HTTP) estén habilitados en el nivel jerárquico system services :
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
Consulte No se puede administrar un clúster de chasis de la serie SRX mediante fxp0 cuando el destino en el enrutador de respaldo es 0/0 y Configuración del comando del enrutador de respaldo en el clúster de chasis para obtener más información sobre las instrucciones de configuración.
Si la configuración es correcta y sigue sin poder administrar el clúster de chasis, continúe con el paso 2.
-
-
¿Las direcciones IP de las interfaces fxp0 del nodo principal y del nodo secundario están en la misma subred?
-
Yes: Continúe con lo que sigue.
-
No: Configure las interfaces fxp0 del nodo principal y el nodo secundario en la misma subred. Vaya al paso 1 y verifique la configuración.
-
¿Qué sigue?
-
Si el problema persiste, consulte el artículo KB20795 de KB.
-
Si desea seguir depurando, consulte el artículo KB21164 de KB para comprobar los registros de depuración.
-
Para abrir un caso del JTAC con el equipo de soporte de Juniper Networks, consulte Recopilación de datos para el servicio de atención al cliente para conocer los datos que debe recopilar para ayudar en la resolución de problemas antes de abrir un caso del JTAC.
Administrar el clúster de chasis mediante J-Web
Puede usar J-Web para administrar solo el nodo principal.
Conecte una consola al nodo principal.
Con la CLI, ejecute el
show system services web-managementcomando.Compruebe si la interfaz de circuito cerrado (lo0) está configurada en la configuración HTTP/HTTPS de administración web. Consulte Administración web (Servicios del sistema) .
Si la interfaz de circuito cerrado (lo0) está configurada en la configuración HTTP/HTTPS de administración web, ejecute el comando para quitar la
delete system services web-management http interface lo.0interfaz de circuito cerrado.Confirme el cambio y compruebe si ahora puede administrar el clúster de chasis.
Si sigue sin poder administrar el clúster de chasis, vaya a Administrar clúster de chasis mediante el puerto de ingresos o el puerto de administración fxp0.
Administrar clúster de chasis mediante el puerto de ingresos o el puerto de administración fxp0
Puede utilizar el puerto de ingresos o el puerto de administración fxp0 para administrar el nodo principal.
Conéctese a una consola utilizando el puerto de ingresos del nodo principal que desea utilizar como interfaz de administración.
Compruebe la configuración de la interfaz de administración:
Compruebe que los servicios del sistema necesarios (SSH, Telnet, HTTP) estén habilitados en el nivel jerárquico host-inbound-traffic de la zona correspondiente:
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } }Compruebe que los servicios del sistema necesarios (SSH, Telnet, HTTP) estén habilitados en el nivel jerárquico system services :
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
¿Funciona el ping a la interfaz de administración?
Yes: Consulte No se puede administrar un clúster de chasis de la serie SRX mediante fxp0 cuando el destino en el enrutador de reserva es 0/0. Si esta solución no funciona, vaya a Qué sigue para abrir un caso con el soporte técnico de Juniper Networks.
No: Continúe con el paso 4.
Con la CLI, ejecute el
show interfaces tersecomando:En la salida, ¿está el estado de
FXP0 interfaceArriba y proporciona una dirección IP?Yes: Continúe con el paso 5.
No: Compruebe lo siguiente:
Con la CLI, compruebe que la interfaz fxp0 esté configurada correctamente: show groups.
Ejemplo de salida:
root@srx# show groups node0 { system { host-name SRX3400-1; backup-router 192.168.1.254 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 192.168.1.1/24; } } } } } node1 { system { host-name SRX3400-2; backup-router 192.168.1.254 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 192.168.1.2/24; } } } } } } apply-groups "${NODE}"; system { services { ftp; ssh; telnet; } }Compruebe el estado del cable que está conectado a la fxp0 interfaz. ¿El cable está en buenas condiciones?
Yes: Continúe con el siguiente paso.
No: Reemplace el cable e intente administrar el clúster del chasis. Si sigue sin poder administrar el clúster de chasis, continúe con el paso siguiente.
Con la CLI, compruebe si hay contadores de errores incrementales: show interfaces fxp0.0 extensive.
Compruebe si la dirección IP de la interfaz y la dirección IP del dispositivo de administración están en la fxp0 misma subred.
Yes: Continúe con el paso 6.
No: Con la CLI, compruebe si hay una ruta para la dirección IP del dispositivo de administración: show route <management device IP>:
Si no existe una ruta para la dirección IP del dispositivo de administración, agregue una ruta para la subred de administración en la inet.0 tabla con el siguiente salto como dirección IP del enrutador de reserva.
Con la CLI, compruebe si hay una entrada ARP para el dispositivo de administración en la puerta de enlace de servicios: show arp no-resolve | match <ip>.
Yes: Compruebe si el clúster de chasis tiene varias rutas al dispositivo de administración: show route <device-ip>.
Yes: Podría haber rutas al dispositivo de administración a través de la interfaz fxp0 y otra interfaz que conduzca a un enrutamiento asimétrico. Vaya a Qué sigue para abrir un caso con el soporte técnico de Juniper Networks.
No: Proceda a Administrar el clúster de chasis mediante el puerto de administración fxp0.
No: Vaya a Qué sigue para abrir un caso con el soporte técnico de Juniper Networks.
Administrar el clúster de chasis mediante el puerto de administración fxp0
Solo puede usar el puerto de administración fxp0 para administrar el nodo secundario.
Compruebe la configuración de la interfaz de administración en el nodo secundario:
Compruebe que los servicios del sistema necesarios (SSH, Telnet, HTTP) estén habilitados en el nivel jerárquico host-inbound-traffic :
zones { security-zone trust { host-inbound-traffic { system-services { any-service; } protocols { all; } } interfaces { reth0.0 reth0.1; } }Compruebe que los servicios del sistema necesarios (SSH, Telnet, HTTP) estén habilitados en el nivel jerárquico system services :
{primary:node1}[edit] root# show system services { http; ssh; telnet; }
Consulte No se puede administrar un clúster de chasis de la serie SRX mediante fxp0 cuando el destino en el enrutador de respaldo es 0/0 y Configuración del comando del enrutador de respaldo en el clúster de chasis para obtener más información sobre las instrucciones de configuración.
Si la configuración es correcta y sigue sin poder administrar el clúster de chasis, continúe con el paso 2.
¿Las direcciones IP de las interfaces fxp0 del nodo principal y del nodo secundario están en la misma subred?
Yes: Continúe con lo que sigue.
No: Configure las interfaces fxp0 del nodo principal y el nodo secundario en la misma subred. Vaya al paso 1 y verifique la configuración.
¿Qué sigue?
Si el problema persiste, consulte el artículo KB20795 de KB.
Si desea seguir depurando, consulte el artículo KB21164 de KB para comprobar los registros de depuración.
Para abrir un caso del JTAC con el equipo de soporte de Juniper Networks, consulte Recopilación de datos para el servicio de atención al cliente para conocer los datos que debe recopilar para ayudar en la resolución de problemas antes de abrir un caso del JTAC.
No se puede administrar el nodo secundario de un clúster de chasis mediante J-Web
Problema
Descripción
No se puede administrar el nodo secundario de un clúster de chasis mediante la interfaz J-Web.
Ambiente
Clúster de chasis de la serie SRX
Síntomas
Cuando está en el modo de clúster de chasis del Protocolo de redundancia de servicios de Junos (JSRP), no puede administrar el grupo de redundancia 0 (RG0) en el nodo secundario mediante la interfaz J-Web.
Causa
Puede utilizar la interfaz J-Web para administrar el grupo de redundancia 0 sólo en el nodo principal.
Los procesos a los que hace referencia J-Web no se ejecutan en el nodo secundario.
Ejemplo
En el ejemplo siguiente se muestra la salida de syslog y el proceso del sistema tanto en el nodo 0 como en el nodo 1 después de que se conmutara por error RG0 del nodo 1 al nodo 0.
En el nodo 1, el proceso de administración web (httpd-gk) finalizó (salió).
En el nodo 0, se inició el proceso de administración web (httpd-gk).
Dos procesos relacionados con http (httpd-gk y httpd) se ejecutan solo en el nodo 0, que es el nuevo nodo principal de RG0.
{secondary:node1}
root@SRX210HE-B> show chassis cluster status
Cluster ID: 1
Node Priority Status Preempt Manual failover
Redundancy group: 0 , Failover count: 1
node0 255 primary no yes
node1 1 secondary no yes
Redundancy group: 1 , Failover count: 1
node0 100 primary yes no
node1 1 secondary yes no
{secondary:node1}
root@SRX210HE-B> show log log-any | grep web-management
Jul 5 11:31:52 SRX210HE-B init: web-management (PID 9660) started
Jul 5 12:00:37 SRX210HE-B init: web-management (PID 9660) SIGTERM sent
Jul 5 12:00:37 SRX210HE-B init: web-management (PID 9660) exited with status=0 Normal Exit
{primary:node0}
root@SRX210HE-A> show log log-any | grep web-management
Jul 5 12:00:37 SRX210HE-A init: web-management (PID 9498) started
{primary:node0}
root@SRX210HE-A> show system processes extensive node 0 | grep http
9498 root 1 76 0 12916K 4604K select 0 0:00 0.00% httpd-gk
9535 nobody 1 90 0 8860K 3264K select 0 0:00 0.00% httpd
{primary:node0}
root@SRX210HE-A> show system processes extensive node 1 | grep http
=> No httpd-gk and httpd processes running on node 1 (secondary node)
Esto limita las llamadas a procedimiento remoto (RPC) desde la lógica J-Web y, posteriormente, las páginas que se pueden emitir desde el nodo secundario.
Solución
Puede administrar el nodo secundario de un clúster de chasis mediante la CLI (SSH, telnet y consola). Consulte Administración del clúster de chasis mediante el puerto de administración fxp0
No se puede administrar un clúster de chasis de la serie SRX mediante fxp0 cuando el destino en el enrutador de reserva es 0/0
RESUMEN En este tema se explica, con un ejemplo, cómo administrar un clúster de chasis de la serie SRX configurado mediante la configuración del enrutador de reserva a través de la interfaz fxp0.
Problema
Descripción
El dispositivo de administración no puede administrar el clúster de chasis a través de una interfaz fxp0, pero puede hacer ping a ambas interfaces fxp0.
Topología de ejemplo
La topología, las direcciones IP y la configuración son las siguientes:
Primario fxp0: 192.168.1.1/24
Secundario fxp0: 192.168.1.2/24
Puerta de enlace para fxp0: 192.168.1.254
Dispositivo de gestión: 172.16.1.1/24
groups {
node0 {
system {
host-name SRX5400-1;
backup-router 192.168.1.254 destination 0.0.0.0/0;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
}
}
node1 {
system {
host-name SRX5400-2;
backup-router 192.168.1.254 destination 0.0.0.0/0;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.1.2/24;
}
}
}
}
}
}
apply-groups "${NODE}";
system {
services {
ftp;
ssh;
telnet;
}
}
Ambiente
Clúster de chasis de la serie SRX
Causa
Hay una ruta para 172.16.1.1 a través de las interfaces distintas de la interfaz fxp0 en los dispositivos de clúster. No recomendamos utilizar 0.0.0.0/0 como destino del enrutador de reserva. Ping funciona porque la respuesta de eco para una solicitud de eco entrante a la interfaz fxp0 se envía siguiendo la ruta para 172.16.1.1 a través de interfaces distintas de fxp0, pero Telnet falla.
Solución
Quite la ruta para 172.16.1.1 en la tabla de enrutamiento y establezca un destino de enrutador de respaldo más específico en el grupo node0/node1.
Por ejemplo:
groups {
node0 {
...
backup-router 192.168.1.254 destination 172.16.1.1/32;
...
}
node1 {
...
backup-router 192.168.1.254 destination 172.16.1.1/32;
...
}
No se muestran cambios en la tabla de enrutamiento después de aplicar la configuración, ya que la configuración del enrutador de copia de seguridad está pensada para facilitar el acceso de administración solo en el nodo de copia de seguridad. El acceso al nodo principal se habilita mediante el enrutamiento en el nodo principal.Por lo tanto, cuando se completa la configuración del enrutador de reserva, puede ver que se inyecta una ruta en la tabla de reenvío en el nodo secundario. No puede ver la tabla de enrutamiento en el nodo secundario porque el subsistema de enrutamiento no se ejecuta en el nodo secundario.
Resultado de ejemplo cuando el enrutador de copia de seguridad está configurado con destino 0/0
Tabla de enrutamiento en el nodo principal:
{primary:node0}[edit] root@SRX5400-1# run show route inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.0/24 *[Direct/0] 00:00:54 > via fxp0.0 192.168.1.1/32 *[Local/0] 00:00:54 Local via fxp0.0Tabla de reenvío en nodo secundario con destino 0/0:
root@SRX3400-2# run show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default user 0 28:c0:da:a0:88:0 ucst 345 2 fxp0.0 default perm 0 rjct 36 1 0.0.0.0/32 perm 0 dscd 34 1 192.168.1.0/24 intf 0 rslv 344 1 fxp0.0 192.168.1.0/32 dest 0 192.168.1.0 recv 342 1 fxp0.0 192.168.1.2/32 intf 0 192.168.1.2 locl 343 2 192.168.1.2/32 dest 0 192.168.1.2 locl 343 2 192.168.1.254/32 dest 0 28:c0:da:a0:88:0 ucst 345 2 fxp0.0 192.168.1.255/32 dest 0 192.168.1.255 bcst 336 1 fxp0.0 224.0.0.0/4 perm 0 mdsc 35 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 31 1 255.255.255.255/32 perm 0 bcst 32 1 Routing table: __master.anon__.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 526 1 0.0.0.0/32 perm 0 dscd 524 1 224.0.0.0/4 perm 0 mdsc 525 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 521 1 255.255.255.255/32 perm 0 bcst 522 1
Resultado de ejemplo cuando el enrutador de copia de seguridad está configurado con el destino 172.16.1.1/32
Tabla de enrutamiento en el nodo principal:
{primary:node0}[edit] root@SRX5400-1# run show route inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.0/24 *[Direct/0] 00:17:51 > via fxp0.0 192.168.1.1/32 *[Local/0] 00:55:50 Local via fxp0.0Tabla de reenvío en el nodo principal:
Nota:En el nodo principal, la ruta 172.16.1.1/32 del enrutador de reserva no se muestra en la salida de muestra.
{primary:node0}[edit] root@SRX5400-1# run show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 36 1 0.0.0.0/32 perm 0 dscd 34 1 192.168.1.0/24 intf 0 rslv 334 1 fxp0.0 192.168.1.0/32 dest 0 192.168.1.0 recv 331 1 fxp0.0 192.168.1.1/32 intf 0 192.168.1.1 locl 332 2 192.168.1.1/32 dest 0 192.168.1.1 locl 332 2 192.168.1.3/32 dest 0 5c:5e:ab:16:e3:81 ucst 339 1 fxp0.0 192.168.1.6/32 dest 0 0:26:88:4f:c8:8 ucst 340 1 fxp0.0 192.168.1.11/32 dest 0 0:30:48:bc:9f:45 ucst 342 1 fxp0.0 192.168.1.254/32 dest 0 28:c0:da:a0:88:0 ucst 343 1 fxp0.0 192.168.1.255/32 dest 0 192.168.1.255 bcst 329 1 fxp0.0 224.0.0.0/4 perm 0 mdsc 35 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 31 1 255.255.255.255/32 perm 0 bcst 32 1 Routing table: __master.anon__.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 526 1 0.0.0.0/32 perm 0 dscd 524 1 224.0.0.0/4 perm 0 mdsc 525 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 521 1 255.255.255.255/32 perm 0 bcst 522 1Tabla de reenvío en el nodo secundario:
Nota:En el nodo secundario, la ruta 172.16.1.1/32 del enrutador de respaldo se muestra en la salida de muestra. Esto facilita el acceso al nodo secundario a través de la interfaz fxp0.
{secondary:node1}[edit] root@SRX5400-2# run show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 36 1 0.0.0.0/32 perm 0 dscd 34 1 172.16.1.1/32 user 0 192.168.1.254 ucst 345 2 fxp0.0 192.168.1.0/24 intf 0 rslv 344 1 fxp0.0 192.168.1.0/32 dest 0 192.168.1.0 recv 342 1 fxp0.0 192.168.1.2/32 intf 0 192.168.1.2 locl 343 2 192.168.1.2/32 dest 0 192.168.1.2 locl 343 2 192.168.1.254/32 dest 0 28:c0:da:a0:88:0 ucst 345 2 fxp0.0 192.168.1.255/32 dest 0 192.168.1.255 bcst 336 1 fxp0.0 224.0.0.0/4 perm 0 mdsc 35 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 31 1 255.255.255.255/32 perm 0 bcst 32 1 Routing table: __master.anon__.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 526 1 0.0.0.0/32 perm 0 dscd 524 1 224.0.0.0/4 perm 0 mdsc 525 1 224.0.0.1/32 perm 0 224.0.0.1 mcst 521 1 255.255.255.255/32 perm 0 bcst 522 1
Si una subred en particular tiene una ruta configurada a través del enrutador de respaldo y una ruta estática en opciones de enrutamiento, podría haber problemas para acceder a la interfaz fxp0. En el ejemplo anterior, el problema con el acceso a la interfaz fxp0 desde el dispositivo de administración se produce cuando:
La misma ruta existe como ruta estática y a través del enrutador de reserva.
Hay una ruta estática que es más específica que la ruta a través del enrutador de reserva.
En los ejemplos, cuando las rutas del nodo principal se sincronizan con la tabla de reenvío del nodo secundario, la ruta configurada en ruta estática tiene prioridad sobre la ruta bajo enrutador de reserva. Si 0/0 está configurado en el enrutador de respaldo, las posibilidades de una mejor ruta coincidente en la ruta estática son mayores. Por lo tanto, recomendamos evitar 0/0 en el enrutador de respaldo.
Si desea configurar rutas al mismo destino utilizando el enrutador de respaldo, así como la ruta estática, divida las rutas cuando configure en enrutador de respaldo. Esto hace que las rutas configuradas en el enrutador de reserva sean las rutas preferidas y garantiza que la interfaz fxp0 sea accesible.
[edit routing-options static route] 0.0.0.0/0 next-hop 100.200.200.254; [edit groups node0 ] backup-router 192.168.1.254 destination [0.0.0.0/1 128.0.0.0/1];
No se puede actualizar un clúster de chasis mediante la actualización de software en servicio
Problema
Descripción
No se puede actualizar un clúster de chasis mediante el método de actualización de tiempo de inactividad mínimo.
Ambiente
SRX5400 clúster de chasis.
Síntomas
-
El clúster se atasca en el nodo 0 RG1 con el indicador IF y no se puede proteger.
-
El error de confirmación de configuración se muestra en la CLI.
Causa
La configuración tiene el mismo prefijo en los destinos del enrutador de respaldo (en el RE/nodo de respaldo) y en la dirección de la interfaz de usuario.
regress@R1_re# show interfaces ge-0/0/0
unit 0 {
family inet {
address 192.1.1.1/24;
}
}
regress@R1_re# show groups re1 system backup-router
10.204.63.254 destination 192.1.1.1/18;
regress@R1_re# commit
re0: configuration check succeeds re1: error: Cannot have same prefix for backup-router destination and interface address. ge-0/0/0.0 inet 192.1.1 error: configuration check-out failed re0: error: remote commit-configuration failed on re1
Solución
En el modo de clúster de chasis, la dirección de destino del enrutador de reserva para los enrutadores IPv4 e IPv6 que utilizan los comandos y no debe ser la misma que la dirección de interfaz configurada para IPv4 e IPv6 mediante los comandos edit system backup-router address destination destination-address edit interfaces interface-name unit logical-unit-number family inet address ipv4-address y edit system inet6-backup-router address destination destination-address edit interfaces interface-name unit logical-unit-number family inet6 address ipv6-address.Configuración del comando del enrutador de respaldo en el clúster de chasis
RESUMEN Cómo hacer una copia de seguridad de un enrutador en un clúster de chasis de la serie SRX mediante el comando de backup-router configuración.
Problema
Descripción
Problemas intermitentes de conectividad con NSM y otros hosts de administración desde el nodo secundario.
Ambiente
Clúster de chasis de la serie SRX
Causa
No se admite establecer un destino de en el enrutador de 0.0.0.0/0 reserva (sin configuración).
Ejemplo de una configuración incorrecta:
set groups node0 system backup-router 10.10.10.1 destination 0.0.0.0/0
Solución
Consulte Configuración de un enrutador de reserva para conocer la forma recomendada de configurar un enrutador de reserva mediante un prefijo distinto de cero.
Ejemplo de una configuración de enrutador de respaldo de subred distinta de cero:
set groups node0 system backup-router 10.10.10.1 destination 10.100.0.0/16
Como alternativa al destino del enrutador de respaldo 0/0, aquí hay otro ejemplo en el que 0/0 se divide en dos prefijos:
set groups node0 system backup-router 10.10.10.1 destination 0.0.0.0/1 set groups node0 system backup-router 10.10.10.1 destination 128.0.0.0/1
Si es necesario acceder a varias redes a través del enrutador de reserva, puede agregar varias entradas de destino a la configuración. La configuración del enrutador de respaldo solo la utiliza el nodo secundario RG0. El nodo principal sigue utilizando la tabla de enrutamiento inet.0.
No se puede actualizar un clúster de chasis mediante la actualización de software en servicio
Problema
Descripción
No se puede actualizar un clúster de chasis mediante el método de actualización de tiempo de inactividad mínimo.
Ambiente
SRX5400 clúster de chasis.
Síntomas
-
El clúster se atasca en el nodo 0 RG1 con el indicador IF y no se puede proteger.
-
El error de confirmación de configuración se muestra en la CLI.
Causa
La configuración tiene el mismo prefijo en los destinos del enrutador de respaldo (en el RE/nodo de respaldo) y en la dirección de la interfaz de usuario.
regress@R1_re# show interfaces ge-0/0/0
unit 0 {
family inet {
address 192.1.1.1/24;
}
}
regress@R1_re# show groups re1 system backup-router
10.204.63.254 destination 192.1.1.1/18;
regress@R1_re# commit
re0: configuration check succeeds re1: error: Cannot have same prefix for backup-router destination and interface address. ge-0/0/0.0 inet 192.1.1 error: configuration check-out failed re0: error: remote commit-configuration failed on re1