EN ESTA PÁGINA
Descripción de interfaces de estructura de clúster de chasis
Ejemplo: Configurar las interfaces de estructura de clúster de chasis
Verificar interfaces de plano de datos del clúster de chasis
Visualización de estadísticas del plano de datos del clúster de chasis
Borrar estadísticas del plano de datos del clúster de chasis
Interfaces de estructura de clúster de chasis
Los dispositivos de la serie SRX en un clúster de chasis utilizan la interfaz de estructura (fab) para la sincronización de sesión 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 ser del mismo tipo de medio. Para obtener más información, consulte los siguientes temas:
Descripción de 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 de forma posterior (una de cada nodo).
A diferencia del vínculo de control, cuyas interfaces determina el sistema, se especifican 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 debe procesarse en el otro se reenvía a través del vínculo de datos de estructura. De forma similar, el tráfico procesado en un nodo que debe 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 la 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 del plano de datos. La estructura proporciona sincronización de objetos de estado de sesión creados por operaciones como autenticación, traducción de direcciones de red (TDR), puertas de enlace de capa de aplicación (ALG) y 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á para la transmisión de paquetes.
Después de configurar 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) se mueva a un estado deshabilitado. (Restablecer un dispositivo a la configuración predeterminada de fábrica elimina la configuración de estructura y, por lo tanto, hace que el nodo secundario RG0 se mueva a un estado deshabilitado.) Después de confirmar la configuración de estructura, no restablezca ninguno de los dispositivos a la configuración predeterminada de fábrica.
- Tipos de interfaz de estructura compatibles para dispositivos de la serie SRX (serie SRX300, SRX550M, SRX1500, SRX4100/SRX4200, SRX4600 y SERIE SRX5000)
- Soporte de trama Jumbo
- Descripción de interfaces de estructura en dispositivos de línea SRX5000 para IOC2 e IOC3
- Descripción de los rtos 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 la estructura
Tipos de interfaz de estructura compatibles para dispositivos de la serie SRX (serie SRX300, SRX550M, SRX1500, SRX4100/SRX4200, SRX4600 y SERIE SRX5000)
Para los clústeres de chasis serie SRX, el vínculo de estructura puede ser cualquier par de interfaces Ethernet que abarcan el clúster; el vínculo de estructura puede ser cualquier par de interfaz Gigabit Ethernet. Ejemplos:
Para dispositivos SRX300, SRX320, SRX340, SRX550M 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 de 10 Gigabit Ethernet.
Para los clústeres de chasis serie SRX compuestos por dispositivos SRX550M, las interfaces SFP en mini-PIC no se pueden utilizar como vínculo de estructura.
Para SRX1500, el vínculo de estructura puede ser cualquier par de interfaces Ethernet que abarcan el clúster; el vínculo de estructura puede ser cualquier par de interfaz Gigabit Ethernet o cualquier par de interfaz de 10 Gigabit Ethernet.
Los tipos de interfaz de estructura compatibles para dispositivos SRX4100 y SRX4200 son 10 Gigabit Ethernet (xe) (ranuras SFP+ de interfaz de 10 Gigabit Ethernet).
Los tipos de interfaz de estructura compatibles para dispositivos SRX4600 son 40 Gigabit Ethernet (et) (ranuras QSFP de interfaz de 40 Gigabit Ethernet) y 10 Gigabit Ethernet (xe).
Los tipos de interfaz de estructura compatibles compatibles con dispositivos de línea SRX5000 son:
Ethernet rápida
Gigabit Ethernet
Ethernet de 10 Gigabit
Ethernet de 40 Gigabit
Ethernet de 100 Gigabit
A partir de Junos OS versión 12.1X46-D10 y Junos OS versión 17.3R1, la interfaz de 100 Gigabit Ethernet se admite en dispositivos de línea SRX5000.
A partir de Junos OS versión 19.3R1, las SRX5K-IOC4-10G y SRX5K-IOC4-MRAT son compatibles con SRX5K-SPC3 en los dispositivos de la serie 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 la nomenclatura de puertos físicos y interfaces lógicas.
Soporte de trama Jumbo
El vínculo de datos de estructura no admite fragmentación. Para adaptarse a este estado, la compatibilidad de trama 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 dispositivos serie SRX. Para garantizar que el tráfico que transita por el vínculo de datos no supere este tamaño, recomendamos que ninguna otra interfaz supere el tamaño de MTU del vínculo de datos de estructura.
Descripción de interfaces de estructura en dispositivos de línea SRX5000 para IOC2 e IOC3
A partir de Junos OS versión 15.1X49-D10, se introducen las SRX5K-MPC3-100G10G (IOC3) y SRX5K-MPC3-40G10G (IOC3).
El SRX5K-MPC (IOC2) es un concentrador de puerto modular (MPC) compatible con SRX5400, SRX5600 y SRX5800. Esta tarjeta de interfaz acepta tarjetas de interfaz modulares (MIC), que agregan puertos Ethernet a la puerta de enlace de servicios para proporcionar las conexiones físicas a varios tipos de medios de red. Los MPC y MIC admiten vínculos de estructura para clústeres de chasis. La SRX5K-MPC ofrece 10 Gigabit Ethernet (con MIC de 10x10GE), 40 Gigabit Ethernet, 100 Gigabit Ethernet y puertos Ethernet de 20x1GE como puertos de estructura. En los dispositivos SRX5400, solo se admiten las SRX5K-MPCs (IOC2).
Las SRX5K-MPC3-100G10G (IOC3) y SRX5K-MPC3-40G10G (IOC3) son concentradores de puerto modular (MPC) compatibles con SRX5400, SRX5600 y SRX5800. Estas tarjetas de interfaz aceptan tarjetas de interfaz modulares (MIC), que agregan puertos Ethernet a la puerta de enlace de servicios para proporcionar las conexiones físicas a varios tipos de medios de red. Los MPC y MIC admiten vínculos de estructura para clústeres de chasis.
Los dos tipos de concentradores de puerto modular (MPC) IOC3, que tienen diferentes MIC integradas, son los MPC de 24x10GE + 6x40GE y 2x100GE + 4x10GE MPC.
Debido a limitaciones de energía y térmicas, las cuatro PIC del 24x10GE + 6x40GE no se pueden alimentar. Se puede activar un máximo de dos PIC al mismo tiempo.
Utilice el set chassis fpc <slot> pic <pic> power off comando para elegir las PIC que desea activar.
En los dispositivos SRX5400, SRX5600 y SRX5800 en 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, siempre asegúrese de que:
Los vínculos de estructura nuevos se configuran en las nuevas PIC que están 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 los vínculos alternativos se interconexiones en línea.
Si no hay vínculos de estructura alternativos configurados en las PIC que están 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 se copiará, ya que falta el vínculo de estructura. Puede ver el resultado de la CLI para este escenario que indica un estado de clúster de chasis defectuoso mediante el
show chassis cluster interfacescomando.
Descripción de los rtos de sesión
El software del plano de datos, que funciona en modo activo/activo, administra el procesamiento de flujo y la redundancia del estado de la 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 una sesión está activa 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 denominados objetos de tiempo de ejecución (OCR) de un nodo al otro a través del vínculo de datos de estructura. Al transmitir información sobre una sesión entre los nodos, los DIRECTOR garantizan la coherencia y la estabilidad de las sesiones si se produce una conmutación por error, y, por lo tanto, permiten que el sistema continúe procesando el tráfico que pertenece a las sesiones existentes. Para garantizar que la información de la sesión siempre esté sincronizada entre los dos nodos, el software del plano de datos da prioridad a la transmisión de los OCR sobre el tráfico de tránsito.
El software del plano de datos crea rtos para sesiones UDP y TCP y rastrea los cambios de estado. También sincroniza el tráfico para protocolos de paso IPv4, como la encapsulación de enrutamiento genérico (GRE) y IPsec.
Los rtos para sincronizar una sesión incluyen:
RtOs de creación de sesiones en el primer paquete
Eliminación de sesiones y rtos de antigüedad
Los RTs relacionados con el cambio, incluidos los siguientes:
Cambios en el estado tcp
Solicitud de sincronización de tiempo de espera y mensajes de respuesta
RÓT para crear y eliminar aperturas temporales en el firewall (agujeros) y agujeros de sesión secundarios
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 en 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 deben reenviarse una interfaz de salida en el otro nodo
Cuando los paquetes llegan a una interfaz en un nodo, pero se deben procesar en el otro nodo
Si las interfaces de entrada y salida de un paquete se encuentran 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 de medios complejas, como las sesiones de voz sobre IP (VoIP).
Descripción de la recuperación y la falla del vínculo de datos de la estructura
Los servicios de detección y prevención de intrusiones (IDP) no admiten conmutación por error. Por esta razón, los servicios IDP no se aplican a las sesiones que estuvieron 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 verán afectados, lo que puede ocasionar 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 vivos 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 inelegible. Determina que se ha producido un error de estructura si no se recibe un sondeo 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 anteriormente inelegible. Luego, llegan al estado en línea y se unen al clúster.
Si realiza cambios en la configuración mientras el nodo secundario está deshabilitado, ejecute el commit comando para sincronizar la configuración después de reiniciar el nodo. Si no hizo 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 monitoreo 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 llevan a cabo de forma automática.
Cuando los nodos primarios y secundarios están en buen estado (es decir, no hay errores) y el vínculo de estructura se cae, los grupos de redundancia RG1+ del nodo secundario se vuelven inelegibles. Cuando uno de los nodos no está en buen estado (es decir, hay un error), los grupos de redundancia RG1+ de este nodo (ya sea el nodo principal o secundario) se vuelven inelegibles. Cuando ambos nodos no están en buen estado y el vínculo de estructura se cae, los grupos de redundancia RG1+ en el nodo secundario se vuelven inelegibles. Cuando surge el vínculo de estructura, el nodo en el que RG1+ se hizo inelegible realiza una sincronización en frío en todas las unidades de procesamiento de servicios y pasa a la espera activa.
Si RG0 es principal en un nodo en mal estado, RG0 conmutará por error de un nodo en mal estado a un nodo en buen estado. Por ejemplo, si el nodo 0 es principal para RG0+ y el nodo 0 se vuelve insalubre, entonces RG1+ en el nodo 0 pasará a no elegible después de 66 segundos de una falla de vínculo de estructura y RG0+ conmuta por error al nodo 1, que es el nodo en buen estado.
Solo RG1+ pasa a un estado inelegible. RG0 sigue estando en un estado principal o secundario.
Utilice el comando de CLI show chassis cluster interfaces para comprobar el estado del vínculo de estructura.
Consulte también
Ejemplo: Configurar las interfaces de estructura de clúster de chasis
En este ejemplo, se muestra cómo configurar la estructura del clúster del chasis. La estructura es la conexión de datos back-to-back entre los nodos de un clúster. El tráfico de un nodo que debe procesarse en el otro nodo o salir a través de una interfaz en el otro nodo pasa por la estructura. La información de estado de sesión también pasa por la estructura.
Requisitos
Antes de comenzar, establezca el ID de clúster de chasis y el ID de nodo del clúster de chasis. Consulte Ejemplo: Establecer el 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 dispositivos 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 o 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 de trama 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.
Solo 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 está conectando cada uno de los vínculos de estructura a través de un conmutador, debe habilitar la función de trama jumbo en los puertos de conmutador correspondientes. Si ambos vínculos de estructura están conectados a través del mismo conmutador, el par RTO-and-probes debe estar en una LAN virtual (VLAN) y el par de datos debe estar en otra VLAN. Aquí también, la función de trama jumbo debe estar habilitada en los puertos de conmutador 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, luego, 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, escriba el comando para confirmar la show interfaces configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.
Para la brevedad, este show resultado de comando solo incluye la configuración relevante para este ejemplo. Cualquier otra configuración del sistema se ha reemplazado 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
Verificar la estructura del clúster de chasis
Propósito
Verifique 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
Verificar 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, ingrese 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 del plano de datos del clúster de chasis
Propósito
Muestra estadísticas del plano de datos del clúster de chasis.
Acción
Desde la CLI, ingrese 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 del plano de datos del clúster de chasis
Para borrar las estadísticas del plano de datos del clúster de chasis mostrado, 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