Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Descripción general del clúster de chasis

Un clúster de chasis proporciona alta disponibilidad en firewalls de la serie SRX, donde dos dispositivos funcionan como un solo dispositivo. El clúster de chasis incluye la sincronización de los archivos de configuración y los estados de sesión de tiempo de ejecución dinámico entre los firewalls de la serie SRX, que forman parte de la configuración del clúster de chasis.

Descripción general del clúster de chasis

Junos OS proporciona alta disponibilidad en el firewall de la serie SRX mediante clústeres de chasis. Los firewalls de la serie SRX se pueden configurar para funcionar en modo de clúster, donde se pueden conectar un par de dispositivos y configurarse para funcionar como un solo nodo, lo que proporciona redundancia de nivel de servicio, interfaz y dispositivo.

Para los firewalls de la serie SRX, que actúan como firewalls con estado, es importante conservar el estado del tráfico entre dos dispositivos. En una configuración de clúster de chasis, en caso de error, se requiere persistencia de sesión para que las sesiones establecidas no se interrumpan incluso si el dispositivo con errores estaba reenviando tráfico.

Cuando se configura como un clúster de chasis, los dos nodos se respaldan entre sí, con un nodo que actúa como dispositivo principal y el otro como dispositivo secundario, lo que garantiza la conmutación por error con estado de los procesos y servicios en caso de fallo del sistema o del hardware. Si se produce un error en el dispositivo primario, el dispositivo secundario se encarga del procesamiento del tráfico. Los nodos del clúster están conectados entre sí con dos vínculos denominados vínculo de control y vínculo de estructura, y los dispositivos de un clúster de chasis sincronizan los estados de configuración, kernel y sesión de PFE en todo el clúster para facilitar la alta disponibilidad, la conmutación por error de los servicios con estado y el equilibrio de carga.

No se requiere ninguna licencia independiente para habilitar el clúster de chasis. Sin embargo, algunas funciones del software Junos OS requieren una licencia para activarla. Para obtener más información, consulte Descripción de los requisitos de licencia del clúster de chasis, Instalación de licencias en los dispositivos de la serie SRX en un clúster de chasis y Comprobación de licencias en un dispositivo de la serie SRX en un clúster de chasis. Consulte la Guía de licencias de Juniper para obtener información general sobre la administración de licencias. Consulte las hojas de datos del producto en Puertas de enlace de servicios de la serie SRX para obtener más información, o comuníquese con su equipo de cuentas de Juniper o con su socio de Juniper.

Ventajas del clúster de chasis

  • Evita fallas en un solo dispositivo que provoquen una pérdida de conectividad.

  • Proporciona alta disponibilidad entre dispositivos al conectar enlaces de sucursales y sitios remotos a oficinas corporativas más grandes. Al aprovechar la función de clúster de chasis, las empresas pueden garantizar la conectividad en caso de falla del dispositivo o del vínculo.

Funcionalidad del clúster de chasis

La funcionalidad del clúster de chasis incluye:

  • Arquitectura de sistema resistente, con un único plano de control activo para todo el clúster y múltiples motores de reenvío de paquetes. Esta arquitectura presenta una vista de dispositivo único del clúster.

  • Sincronización de la configuración y estados de tiempo de ejecución dinámicos entre nodos dentro de un clúster.

  • Supervisión de interfaces físicas y conmutación por error si los parámetros de error cruzan un umbral configurado.

Modos de clúster de chasis

Un clúster de chasis se puede configurar en modo activo/activo o activo/pasivo.

  • Active/passive mode: en el modo activo/pasivo, el tráfico de tránsito pasa por el nodo principal, mientras que el nodo de reserva solo se utiliza en caso de fallo. Cuando se produce un error, el dispositivo de copia de seguridad se convierte en el principal y se hace cargo de todas las tareas de reenvío.

  • Active/active mode: en modo activo/activo, tiene tráfico de tránsito que pasa por ambos nodos del clúster todo el tiempo.

¿Cómo funciona la agrupación en clústeres de chasis?

Los puertos de control en los respectivos nodos están conectados para formar un plano de control que sincroniza la configuración y el estado del kernel para facilitar la alta disponibilidad de interfaces y servicios.

El plano de datos en los nodos respectivos se conecta a través de los puertos de estructura para formar un plano de datos unificado.

Al crear un clúster de chasis, los puertos de control en los nodos respectivos se conectan para formar un plano de control que sincroniza la configuración y el estado del kernel para facilitar la alta disponibilidad de interfaces y servicios.

De manera similar, el plano de datos en los nodos respectivos se conecta a través de los puertos de estructura para formar un plano de datos unificado.

El vínculo de estructura permite la gestión del procesamiento de flujo entre nodos y la gestión de la redundancia de sesión.

El software del plano de control funciona en modo activo o de respaldo. Cuando se configura como un clúster de chasis, los dos nodos se respaldan entre sí, con un nodo que actúa como dispositivo principal y el otro como dispositivo secundario, lo que garantiza la conmutación por error con estado de los procesos y servicios en caso de fallo del sistema o del hardware. Si se produce un error en el dispositivo primario, el dispositivo secundario se encarga del procesamiento del tráfico.

El software del plano de datos funciona en modo activo/activo. En un clúster de chasis, la información de sesión se actualiza a medida que el tráfico atraviesa cualquiera de los dispositivos, y esta información se transmite entre los nodos a través del vínculo de estructura para garantizar que las sesiones establecidas no se interrumpan cuando se produce una conmutación por error. En el modo activo/activo, es posible que el tráfico entre en el clúster en un nodo y salga del otro nodo. Cuando un dispositivo se une a un clúster, se convierte en un nodo de ese clúster. Con la excepción de la configuración de nodo único y las direcciones IP de administración, los nodos de un clúster comparten la misma configuración.

En cualquier momento dado, un clúster puede estar en uno de los siguientes estados: retención, primaria, secundaria en espera, secundaria, no elegible y deshabilitada. Se puede desencadenar una transición de estado debido a cualquier evento, como supervisión de interfaz, supervisión de SPU, errores y conmutaciones por error manuales.

Compatibilidad con clústeres IPv6

Los firewalls de la serie SRX que ejecutan IP versión 6 (IPv6) se pueden implementar en configuraciones de clúster de chasis activo/activo (conmutación por error), además de la compatibilidad existente con configuraciones de clúster de chasis activo/pasivo (conmutación por error). Se puede configurar una interfaz con una dirección IPv4, una dirección IPv6 o ambas. Las entradas de la libreta de direcciones pueden incluir cualquier combinación de direcciones IPv4, direcciones IPv6 y nombres del Sistema de nombres de dominio (DNS).

El clúster de chasis admite túneles de encapsulación de enrutamiento genérico (GRE) que se usan para enrutar el tráfico IPv4/IPv6 encapsulado mediante una interfaz interna, gr-0/0/0. Junos OS crea esta interfaz al arrancar el sistema y solo se utiliza para procesar túneles GRE. Consulte la Guía del usuario de interfaces para dispositivos de seguridad.

Limitaciones del clúster de chasis

Los firewalls de la serie SRX tienen las siguientes limitaciones de clúster de chasis:

Chassis Cluster

  • No se admite VPN de grupo.

  • En todos los firewalls de la serie SRX de un clúster de chasis, se admite la supervisión de flujo para las versiones 5 y 8. Sin embargo, no se admite la supervisión de flujo para la versión 9.

  • Cuando un firewall de la serie SRX funciona en modo de clúster de chasis y encuentra algún problema de acceso al chip IA en una SPC o una tarjeta de E/S (IOC), se activa una alarma FPC menor para activar la conmutación por error del grupo de redundancia.

  • En los dispositivos SRX5400, SRX5600 y SRX5800, los datos de estadísticas de pantalla solo se pueden recopilar en el dispositivo principal.

  • En dispositivos SRX4600, SRX5400, SRX5600 y SRX5800, en configuraciones de clúster de chasis grandes, si se utilizan más de 1000 interfaces lógicas, se recomienda aumentar los temporizadores de latidos del clúster con respecto al tiempo de espera predeterminado antes de activar la conmutación por error. En una implementación de capacidad completa, se recomienda aumentar la espera a 8 segundos modificando heartbeat-threshold y heartbeat-interval los valores en la [edit chassis cluster] jerarquía.

    El producto de los valores y heartbeat-interval define el tiempo transcurrido antes de la heartbeat-threshold conmutación por error. Los valores predeterminados (heartbeat-thresholdde 3 pulsaciones y heartbeat-interval de 1000 milisegundos) producen un tiempo de espera de 3 segundos.

    Para cambiar el tiempo de espera, modifique los valores de las opciones para que el producto sea igual a la configuración deseada. Por ejemplo, establecer el valor en 8 y mantener el valor predeterminado para el heartbeat-threshold heartbeat-interval (1000 milisegundos) produce un tiempo de espera de 8 segundos. Del mismo modo, establecer el en 4 y el heartbeat-threshold heartbeat-interval en 2000 milisegundos también produce un tiempo de espera de 8 segundos.

  • En los dispositivos SRX5400, SRX5600 y SRX5800, las configuraciones de ocho colas no se reflejan en la interfaz del clúster de chasis.

Flow and Processing

  • Si utiliza la captura de paquetes en interfaces reth, se crean dos archivos, uno para los paquetes de entrada y el otro para los paquetes de salida según el nombre de la interfaz reth. Estos archivos se pueden combinar fuera del dispositivo utilizando herramientas como Wireshark o Mergecap.

  • Si utiliza la creación de reflejo de puertos en interfaces reth, la interfaz reth no se puede configurar como interfaz de salida. Debe utilizar una interfaz física como interfaz de salida. Si configura la interfaz reth como una interfaz de salida mediante el comando, se muestra el set forwarding-options port-mirroring family inet output siguiente mensaje de error.

    Port-mirroring configuration error. Interface type in reth1.0 is not valid for port-mirroring or next-hop-group config

  • Cuando un firewall de la serie SRX funciona en modo de clúster de chasis y encuentra cualquier chip IA (el chip IA forma parte de Juniper SPC1 e IOC1. Tiene un impacto directo en el plano de control SPC1/IOC1) problema de acceso en una SPC o una tarjeta de E/S (IOC), se activa una alarma FPC menor para activar la conmutación por error del grupo de redundancia.

  • En los firewalls de la serie SRX en un clúster de chasis, cuando se configuran dos sistemas lógicos, el límite de escala cruza 13.000, que está muy cerca del límite de escala estándar de 15.000, y se obtiene un tiempo de convergencia de 5 minutos. Este problema se produce porque el aprendizaje de rutas de multidifusión tarda más tiempo cuando se aumenta el número de rutas.

  • En los dispositivos SRX4600, SRX5400, SRX5600 y SRX5800 de un clúster de chasis, si el nodo principal que ejecuta el proceso LACP (lacpd) se reinicia correctamente o sin gracia, el lacpd del nuevo nodo principal puede tardar unos segundos en iniciarse o restablecer las interfaces y las máquinas de estado para recuperar resultados sincrónicos inesperados. Además, durante la conmutación por error, cuando el sistema procesa paquetes de tráfico o paquetes internos de alta prioridad (eliminando sesiones o restableciendo tareas), los paquetes LACP de prioridad media del par (conmutador) se desvían en las colas de espera, lo que provoca más retrasos.

La supervisión por flujo se admite en dispositivos SRX300, SRX320, SRX340, SRX345, SRX380, SRX1500, SRX1600 y SRX2300.

Installation and Upgrade

  • Para los dispositivos SRX300, SRX320, SRX340, SRX345 y SRX380, el reboot parámetro no está disponible, ya que los dispositivos de un clúster se reinician automáticamente después de una actualización de clúster en banda (ICU).

Interfaces

  • En la interfaz lsq-0/0/0, no se admiten los servicios de vínculo MLPPP, MLFR y CRTP.

  • En la interfaz lt-0/0/0, no se admite CoS para RPM.

  • La interfaz del marcador 3G no es compatible.

  • No se admite hacer cola en la interfaz ae.

Layer 2 Switching

  • En la conmutación por error del firewall de la serie SRX, los puntos de acceso del conmutador de capa 2 se reinician y todos los clientes inalámbricos pierden conectividad durante 4 a 6 minutos.

MIBs

  • No se admite la MIB del clúster de chasis.

Monitoring

  • El número máximo de direcciones IP de supervisión que se pueden configurar por clúster es 64 para dispositivos SRX300, SRX320, SRX340, SRX345, SRX380, SRX1500, SRX1600 y SRX2300.

  • En los dispositivos SRX300, SRX320, SRX340, SRX345, SRX380, SRX1500, SRX1600 y SRX2300, los registros no se pueden enviar a NSM cuando el registro está configurado en el modo de transmisión. No se pueden enviar registros porque el registro de seguridad no admite la configuración de la dirección IP de origen para la interfaz fxp0 y el destino del registro de seguridad en modo de secuencia no se puede enrutar a través de la interfaz fxp0. Esto implica que no puede configurar el servidor de registro de seguridad en la misma subred que la interfaz fxp0 y enrutar el servidor de registro a través de la interfaz fxp0.

IPv6

  • La supervisión de direcciones IP del grupo de redundancia no se admite para destinos IPv6.

GPRS

  • En dispositivos SRX5400, SRX5600 y SRX5800, un filtro APN o IMSI debe limitarse a 600 para cada perfil GTP. El número de filtros es directamente proporcional al número de entradas del prefijo IMSI. Por ejemplo, si un APN está configurado con dos entradas de prefijo IMSI, el número de filtros es dos.

MIBs

  • No se admite la MIB del clúster de chasis.

Nonstop Active Routing (NSR)

  • NSR puede conservar la información de la interfaz y del kernel, y guarda la información del protocolo de enrutamiento ejecutando el proceso de protocolo de enrutamiento (RPD) en el motor de enrutamiento de reserva. Sin embargo, la mayoría de las plataformas SRX aún no admiten NSR. Entonces, en el nodo secundario, no hay ningún demonio RPD existente. Después de que ocurra la conmutación por error de RG0, el nuevo maestro de RG0 tendrá un nuevo RPD y tendrá que volver a negociar con el dispositivo par. Solo las plataformas SRX5000 con la versión 17.4R2 o superior pueden admitir NSR.

A partir de Junos OS versión 12.1X45-D10 y posteriores, las funciones de muestreo, como la supervisión de flujo, la captura de paquetes y la duplicación de puertos, se admiten en las interfaces reth.

Tabla de historial de versiones
Lanzamiento
Descripción
12,1 X 45
A partir de Junos OS versión 12.1X45-D10 y posteriores, las funciones de muestreo, como la supervisión de flujo, la captura de paquetes y la duplicación de puertos, se admiten en las interfaces reth.