Interfaces de estructura de clúster de chasis
Los dispositivos de la serie SRX en un clúster de chasis usan la interfaz de estructura (fab) para la sincronización de sesiones y el tráfico de reenvío entre los dos chasis. El vínculo de estructura es una conexión física entre dos interfaces Ethernet en la misma LAN. Ambas interfaces deben tener el mismo tipo de medio. Para obtener más información, consulte los temas siguientes:
Descripción de las interfaces de estructura de clúster de chasis
La estructura es una conexión física entre dos nodos de un clúster y se forma mediante la conexión de un par de interfaces Ethernet consecutivas (una de cada nodo).
A diferencia del vínculo de control, cuyas interfaces determina el sistema, especifique las interfaces físicas que se utilizarán para el vínculo de datos de estructura en la configuración.
La estructura es el vínculo de datos entre los nodos y se utiliza para reenviar el tráfico entre el chasis. El tráfico que llega a un nodo que necesita ser procesado en el otro se reenvía a través del vínculo de datos de estructura. Del mismo modo, el tráfico procesado en un nodo que necesita salir a través de una interfaz en el otro nodo se reenvía a través de la estructura.
El vínculo de datos se conoce como interfaz de estructura. Los motores de reenvío de paquetes del clúster lo utilizan para transmitir tráfico de tránsito y sincronizar el estado de tiempo de ejecución dinámico del software de plano de datos. La estructura proporciona la sincronización de objetos de estado de sesión creados por operaciones como la autenticación, la traducción de direcciones de red (NAT), las puertas de enlace de capa de aplicación (ALG) y las sesiones de seguridad IP (IPsec).
Cuando el sistema crea la interfaz de estructura, el software le asigna una dirección IP derivada internamente que se utilizará en la transmisión de paquetes.
Después de configurar las interfaces de estructura en un clúster de chasis, la eliminación de la configuración de estructura en cualquiera de los nodos hará que el nodo secundario del grupo de redundancia 0 (RG0) pase a un estado deshabilitado. (Al restablecer un dispositivo a la configuración predeterminada de fábrica, se elimina la configuración de la estructura y, por lo tanto, el nodo secundario RG0 se mueve a un estado deshabilitado). Una vez confirmada la configuración de la estructura, no restablezca ninguno de los dispositivos a la configuración predeterminada de fábrica.
- Tipos de interfaz de estructura admitidos para firewalls serie SRX (serie SRX300, SRX1500, SRX1600, SRX4100/SRX4200, SRX4600 y línea SRX5000)
- Soporte de Jumbo Frame
- Descripción de las interfaces de estructura en dispositivos de línea de SRX5000 para IOC2 e IOC3
- Descripción de los RTO de sesión
- Descripción del reenvío de datos
- Descripción de la recuperación y la falla del vínculo de datos de estructura
Tipos de interfaz de estructura admitidos para firewalls serie SRX (serie SRX300, SRX1500, SRX1600, SRX4100/SRX4200, SRX4600 y línea SRX5000)
Para los clústeres de chasis de la serie SRX, el vínculo de estructura puede ser cualquier par de interfaces Ethernet que abarquen el clúster; el vínculo de estructura puede ser cualquier par de interfaz Gigabit Ethernet. Ejemplos:
-
Para dispositivos SRX300, SRX320, SRX340 y SRX345, el vínculo de estructura puede ser cualquier par de interfaces Gigabit Ethernet. Para dispositivos SRX380, el vínculo de estructura puede ser cualquier par de interfaces Gigabit Ethernet o cualquier par de interfaces 10 Gigabit Ethernet.
-
Para SRX1500 y SRX1600, el vínculo de estructura puede ser cualquier par de interfaces Ethernet que abarquen el clúster; el vínculo de estructura puede ser cualquier par de interfaz Gigabit Ethernet o cualquier par de interfaz 10-Gigabit Ethernet. Por SRX1600, el vínculo de estructura también puede ser cualquier par de interfaz de 25 Gigabit Ethernet.
-
Los tipos de interfaz de estructura admitidos para dispositivos SRX4100 y SRX4200 son Ethernet de 10 Gigabit (xe) (ranuras SFP+ de interfaz de 10 Gigabit Ethernet).
-
Los tipos de interfaz de estructura admitidos para dispositivos SRX4600 son 40 Gigabit Ethernet (et) (ranuras QSFP de interfaz 40 Gigabit Ethernet) y 10 Gigabit Ethernet (xe).
-
Los tipos de interfaz de estructura admitidos para dispositivos de línea de SRX5000 son:
-
Ethernet rápida
-
Gigabit Ethernet
-
Ethernet de 10 gigabits
-
Ethernet de 40 gigabits
-
Ethernet de 100 gigabits
A partir de Junos OS versión 12.1X46-D10 y Junos OS versión 17.3R1, la interfaz 100-Gigabit Ethernet es compatible con dispositivos de línea SRX5000.
A partir de Junos OS versión 19.3R1, SRX5K-IOC4-10G y SRX5K-IOC4-MRAT son compatibles junto con SRX5K-SPC3 en los dispositivos de línea SRX5000. SRX5K-IOC4-10G MPIC admite MACsec.
-
Para obtener más información sobre el uso de puertos e interfaces para vínculos de administración, control y estructura, consulte Descripción de la numeración de ranuras de clúster de chasis serie SRX y Nomenclatura de puertos físicos e interfaces lógicas.
Soporte de Jumbo Frame
El vínculo de datos de estructura no admite la fragmentación. Para adaptarse a este estado, la compatibilidad con tramas jumbo está habilitada de forma predeterminada en el vínculo con un tamaño de unidad de transmisión máxima (MTU) de 9014 bytes (9000 bytes de carga + 14 bytes para el encabezado Ethernet) en los firewalls de la serie SRX. Para asegurarse de que el tráfico que transita por el vínculo de datos no supere este tamaño, se recomienda que ninguna otra interfaz supere el tamaño de MTU del vínculo de datos de estructura.
Descripción de las interfaces de estructura en dispositivos de línea de SRX5000 para IOC2 e IOC3
A partir de Junos OS versión 15.1X49-D10, se presentan el SRX5K-MPC3-100G10G (IOC3) y el SRX5K-MPC3-40G10G (IOC3).
El SRX5K-MPC (IOC2) es un concentrador de puerto modular (MPC) compatible con la SRX5400, la SRX5600 y la SRX5800. Esta tarjeta de interfaz acepta tarjetas de interfaz modular (MIC), que agregan puertos Ethernet a la puerta de enlace de servicios para proporcionar conexiones físicas a varios tipos de medios de red. Las MPC y MIC admiten vínculos de estructura para clústeres de chasis. El SRX5K-MPC proporciona puertos 10 Gigabit Ethernet (con MIC 10x10GE), 40 Gigabit Ethernet, 100 Gigabit Ethernet y 20x1GE Ethernet como puertos de estructura. En SRX5400 dispositivos, solo se admiten SRX5K-MPC (IOC2).
El SRX5K-MPC3-100G10G (IOC3) y el SRX5K-MPC3-40G10G (IOC3) son concentradores de puertos modulares (MPC) compatibles con los SRX5400, SRX5600 y SRX5800. Estas tarjetas de interfaz aceptan tarjetas de interfaz modular (MIC), que agregan puertos Ethernet a la puerta de enlace de servicios para proporcionar conexiones físicas a varios tipos de medios de red. Las MPC y MIC admiten vínculos de estructura para clústeres de chasis.
Los dos tipos de concentradores de puertos modulares (MPC) IOC3, que tienen diferentes MIC incorporadas, son el MPC 24x10GE + 6x40GE y el MPC 2x100GE + 4x10GE.
Debido a limitaciones térmicas y de alimentación, los cuatro PIC del 24x10GE + 6x40GE no se pueden encender. Se puede encender un máximo de dos PIC al mismo tiempo.
Use el set chassis fpc <slot> pic <pic> power off comando para elegir las PIC que desea encender.
En dispositivos SRX5400, SRX5600 y SRX5800 de un clúster de chasis, cuando las PIC que contienen vínculos de estructura en el SRX5K-MPC3-40G10G (IOC3) estén apagadas para activar PIC alternativas, asegúrese siempre de que:
-
Los nuevos vínculos de estructura se configuran en las nuevas PIC activadas. Al menos un vínculo de estructura debe estar presente y en línea para garantizar una pérdida mínima de RTO.
-
El clúster de chasis está en modo activo-pasivo para garantizar una pérdida mínima de RTO, una vez que se ponen en línea los vínculos alternativos.
-
Si no se configura ningún vínculo de estructura alternativo en las PIC activadas, la comunicación sincrónica de RTO entre los dos nodos se detiene y el estado de sesión del clúster de chasis no realizará una copia de seguridad, porque falta el vínculo de estructura. Puede ver el resultado de la CLI para este escenario indicando un estado de clúster de chasis incorrecto mediante el
show chassis cluster interfacescomando.
Descripción de los RTO de sesión
El software del plano de datos, que funciona en modo activo/activo, gestiona el procesamiento de flujo y la redundancia del estado de sesión y procesa el tráfico de tránsito. Todos los paquetes que pertenecen a una sesión determinada se procesan en el mismo nodo para garantizar que se les aplique el mismo tratamiento de seguridad. El sistema identifica el nodo en el que está activa una sesión y reenvía sus paquetes a ese nodo para su procesamiento. (Después de procesar un paquete, el motor de reenvío de paquetes transmite el paquete al nodo en el que existe su interfaz de salida si ese nodo no es el local).
Para proporcionar redundancia de sesión (o flujo), el software del plano de datos sincroniza su estado mediante el envío de paquetes de carga especiales llamados objetos en tiempo de ejecución (RTO) de un nodo a otro a través del vínculo de datos de la estructura. Al transmitir información sobre una sesión entre los nodos, los RTO garantizan la consistencia y estabilidad de las sesiones en caso de que se produjera una conmutación por error y, por lo tanto, permiten que el sistema continúe procesando el tráfico perteneciente a las sesiones existentes. Para garantizar que la información de sesión esté siempre sincronizada entre los dos nodos, el software de plano de datos da prioridad de transmisión de RTO sobre el tráfico de tránsito.
El software de plano de datos crea RTO para sesiones UDP y TCP y realiza un seguimiento de los cambios de estado. También sincroniza el tráfico para los protocolos de paso a través de IPv4, como la encapsulación de enrutamiento genérico (GRE) e IPsec.
Los RTO para sincronizar una sesión incluyen:
-
RTO de creación de sesión en el primer paquete
-
Eliminación de sesiones y RTO de antigüedad
-
RTO relacionados con el cambio, incluidos:
-
Cambios de estado TCP
-
Mensajes de solicitud y respuesta de sincronización de tiempo de espera
-
RTO para crear y eliminar aberturas temporales en el firewall (agujeros de alfiler) y agujeros de sesión secundaria
-
Descripción del reenvío de datos
Para Junos OS, el procesamiento de flujo se produce en un único nodo en el que se estableció la sesión para ese flujo y está activa. Este enfoque garantiza que se apliquen las mismas medidas de seguridad a todos los paquetes que pertenecen a una sesión.
Un clúster de chasis puede recibir tráfico en una interfaz de un nodo y enviarlo a una interfaz del otro nodo. (En el modo activo/activo, la interfaz de entrada para el tráfico puede existir en un nodo y su interfaz de salida en el otro).
Este recorrido es necesario en las siguientes situaciones:
-
Cuando los paquetes se procesan en un nodo, pero necesitan ser reenviados por una interfaz de salida en el otro nodo
-
Cuando los paquetes llegan a una interfaz en un nodo, pero deben procesarse en el otro nodo
Si las interfaces de entrada y salida de un paquete están en un nodo, pero el paquete debe procesarse en el otro nodo porque su sesión se estableció allí, debe atravesar el vínculo de datos dos veces. Este puede ser el caso de algunas sesiones multimedia complejas, como las sesiones de voz sobre IP (VoIP).
Descripción de la recuperación y la falla del vínculo de datos de estructura
Los servicios de detección y prevención de intrusiones (IDP) no admiten la conmutación por error. Por este motivo, los servicios de IDP no se aplican a las sesiones que estaban presentes antes de la conmutación por error. Los servicios IDP se aplican a las nuevas sesiones creadas en el nuevo nodo principal.
El vínculo de datos de estructura es vital para el clúster de chasis. Si el vínculo no está disponible, el reenvío de tráfico y la sincronización de RTO se ven afectados, lo que puede provocar la pérdida de tráfico y un comportamiento impredecible del sistema.
Para eliminar esta posibilidad, Junos OS utiliza la supervisión de estructura para comprobar si el vínculo de estructura, o los dos vínculos de estructura en el caso de una configuración de vínculo de estructura dual, están activos mediante la transmisión periódica de sondeos a través de los vínculos de estructura. Si Junos OS detecta errores de estructura, el estado RG1+ del nodo secundario cambia a no apto. Determina que se ha producido un error de estructura si no se recibe una sonda de estructura pero la interfaz de estructura está activa. Para recuperarse de este estado, ambos vínculos de estructura deben volver al estado en línea y deben comenzar a intercambiar sondeos. Tan pronto como esto suceda, se restablecerán todas las FPC del nodo que antes no era elegible. Luego llegan al estado en línea y se vuelven a unir al grupo.
Si realiza algún cambio en la configuración mientras el nodo secundario está deshabilitado, ejecute el comando para sincronizar la configuración después de reiniciar el commit nodo. Si no realizó cambios en la configuración, el archivo de configuración permanece sincronizado con el del nodo principal.
A partir de Junos OS versión 12.1X47-D10 y Junos OS versión 17.3R1, la función de supervisión de estructura está habilitada de forma predeterminada en dispositivos SRX5800, SRX5600 y SRX5400.
A partir de Junos OS versión 12.1X47-D10 y Junos OS versión 17.3R1, la recuperación del vínculo de estructura y la sincronización se realizan automáticamente.
Cuando los nodos primario y secundario están en buen estado (es decir, no hay errores) y el vínculo de estructura deja de funcionar, los grupos de redundancia RG1+ en el nodo secundario dejan de ser elegibles. Cuando uno de los nodos no está en buen estado (es decir, hay un error), los grupos de redundancia RG1+ en este nodo (ya sea el nodo principal o secundario) dejan de ser elegibles. Cuando ambos nodos no están en buen estado y el vínculo de estructura deja de funcionar, los grupos de redundancia RG1+ en el nodo secundario dejan de ser elegibles. Cuando aparece el vínculo de estructura, el nodo en el que RG1+ dejó de ser elegible realiza una sincronización en frío en todas las unidades de procesamiento de servicios y pasa al modo de espera activo.
-
Si RG0 es primario en un nodo en mal estado, RG0 conmutará por error de un nodo en mal estado a uno en buen estado. Por ejemplo, si el nodo 0 es primario para RG0+ y el nodo 0 deja de estar en buen estado, entonces RG1+ en el nodo 0 pasará a no elegible después de 66 segundos de un error de vínculo de estructura y RG0+ conmuta por error al nodo 1, que es el nodo en buen estado.
-
Solo RG1+ hace la transición a un estado no elegible. RG0 continúa estando en estado primario o secundario.
Utilice el comando de la show chassis cluster interfaces CLI para comprobar el estado del vínculo de estructura.
Ver también
Ejemplo: configuración de las interfaces de estructura de clúster de chasis
En este ejemplo, se muestra cómo configurar la estructura del clúster de chasis. La estructura es la conexión de datos consecutiva entre los nodos de un clúster. El tráfico en un nodo que necesita ser procesado en el otro nodo o salir a través de una interfaz en el otro nodo pasa por la estructura. La información del estado de la sesión también pasa por la estructura.
Requisitos
Antes de comenzar, establezca el ID del clúster de chasis y el ID de nodo del clúster de chasis. Consulte Ejemplo: Configuración del ID de nodo y el ID de clúster para dispositivos de seguridad en un clúster de chasis .
Visión general
En la mayoría de los firewalls de la serie SRX en un clúster de chasis, puede configurar cualquier par de interfaces Gigabit Ethernet o cualquier par de interfaces de 10 Gigabit para que sirvan como estructura entre nodos.
No puede configurar filtros, políticas ni servicios en la interfaz de estructura. La fragmentación no se admite en el vínculo de estructura. El tamaño máximo de MTU para interfaces de estructura es de 9014 bytes y el tamaño máximo de MTU para otras interfaces es de 8900 bytes. La compatibilidad con tramas Jumbo en los vínculos de miembro está habilitada de forma predeterminada.
En este ejemplo se muestra cómo configurar el vínculo de estructura.
Sólo se puede configurar el mismo tipo de interfaces como elementos secundarios de estructura y debe configurar un número igual de vínculos secundarios para fab0 y fab1.
Si va a conectar cada uno de los vínculos de estructura a través de un conmutador, debe activar la función de trama jumbo en los puertos de conmutación correspondientes. Si ambos vínculos de estructura están conectados a través del mismo conmutador, el par de RTO y sondeos debe estar en una LAN virtual (VLAN) y el par de datos debe estar en otra VLAN. También en este caso, la función de trama jumbo debe estar habilitada en los puertos de conmutación correspondientes.
Configuración
Procedimiento
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía y, a continuación, ingrese commit desde el [edit] modo de configuración.
{primary:node0}[edit]
set interfaces fab0 fabric-options member-interfaces ge-0/0/1
set interfaces fab1 fabric-options member-interfaces ge-7/0/1
Procedimiento paso a paso
Para configurar la estructura del clúster de chasis:
Especifique las interfaces de estructura.
{primary:node0}[edit] user@host# set interfaces fab0 fabric-options member-interfaces ge-0/0/1 {primary:node0}[edit] user@host# set interfaces fab1 fabric-options member-interfaces ge-7/0/1
Resultados
Desde el modo de configuración, confirme la configuración introduciendo el show interfaces comando. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.
Para abreviar, este resultado del comando solo incluye la configuración relevante para este show ejemplo. Cualquier otra configuración en el sistema ha sido reemplazada por puntos suspensivos (...).
{primary:node0}[edit]
user@host# show interfaces
...
fab0 {
fabric-options {
member-interfaces {
ge-0/0/1;
}
}
}
fab1 {
fabric-options {
member-interfaces {
ge-7/0/1;
}
}
}
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Verificación
Verificación de la estructura del clúster de chasis
Propósito
Compruebe la estructura del clúster de chasis.
Acción
Desde el modo operativo, ingrese el show interfaces terse | match fab comando.
{primary:node0}
user@host> show interfaces terse | match fab
ge-0/0/1.0 up up aenet --> fab0.0
ge-7/0/1.0 up up aenet --> fab1.0
fab0 up up
fab0.0 up up inet 30.17.0.200/24
fab1 up up
fab1.0 up up inet 30.18.0.200/24
Comprobación de interfaces de plano de datos del clúster de chasis
Propósito
Muestra el estado de la interfaz del plano de datos del clúster del chasis.
Acción
Desde la CLI, escriba el show chassis cluster data-plane interfaces comando:
{primary:node1}
user@host> show chassis cluster data-plane interfaces
fab0:
Name Status
ge-2/1/9 up
ge-2/2/5 up
fab1:
Name Status
ge-8/1/9 up
ge-8/2/5 up
Visualización de estadísticas de plano de datos del clúster de chasis
Propósito
Muestra estadísticas del plano de datos del clúster del chasis.
Acción
Desde la CLI, escriba el show chassis cluster data-plane statistics comando:
{primary:node1}
user@host> show chassis cluster data-plane statistics
Services Synchronized:
Service name RTOs sent RTOs received
Translation context 0 0
Incoming NAT 0 0
Resource manager 0 0
Session create 0 0
Session close 0 0
Session change 0 0
Gate create 0 0
Session ageout refresh requests 0 0
Session ageout refresh replies 0 0
IPSec VPN 0 0
Firewall user authentication 0 0
MGCP ALG 0 0
H323 ALG 0 0
SIP ALG 0 0
SCCP ALG 0 0
PPTP ALG 0 0
RTSP ALG 0 0
Borrar estadísticas de plano de datos del clúster de chasis
Para borrar las estadísticas del plano de datos del clúster de chasis mostradas, ingrese el clear chassis cluster data-plane statistics comando desde la CLI:
{primary:node1}
user@host> clear chassis cluster data-plane statistics
Cleared data-plane statistics