Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Prácticas recomendadas para administrar un clúster de chasis

A continuación, se presentan algunas prácticas recomendadas para los clústeres de chasis para dispositivos de la serie SRX.

Uso de vínculos de control dual

En los vínculos de control dual, se conectan dos pares de interfaces de vínculo de control entre cada dispositivo de un clúster. Los vínculos de control dual son compatibles en las líneas SRX5000 y SRX3000. Tener dos vínculos de control ayuda a evitar un posible punto único de falla. Para la línea SRX5000, esta funcionalidad requiere un segundo motor de enrutamiento, así como una segunda tarjeta de control de conmutador (SCB) para alojar el motor de enrutamiento, que se instalará en cada dispositivo del clúster. El propósito del segundo motor de enrutamiento es solo inicializar el conmutador en la SCB. El segundo motor de enrutamiento, que se instalará solo en dispositivos de línea SRX5000, no proporciona funcionalidad de copia de seguridad. Para el Línea SRX3000, esta funcionalidad requiere que se instale un módulo de clústeres (SCM) SRX en cada dispositivo del clúster. Aunque el SCM cabe en la ranura del motor de enrutamiento, no es un motor de enrutamiento. Línea SRX3000 dispositivos no admiten un segundo motor de enrutamiento. El propósito de SCM es inicializar el segundo vínculo de control. Los dispositivos de sucursal de la serie SRX no admiten vínculos de control dual.

Uso de vínculos de datos duales

Puede conectar dos vínculos de estructura entre cada dispositivo de un clúster, lo que proporciona un vínculo de estructura redundante entre los miembros de un clúster. Tener dos vínculos de estructura ayuda a evitar un posible punto único de falla. Cuando se utilizan vínculos de estructura dual, los objetos en tiempo de ejecución (RTO) y los sondeos se envían en un vínculo, y los paquetes reenviados y de flujo de estructura se envían en el otro vínculo. Si se produce un error en un vínculo de estructura, el otro vínculo de estructura controla los RTO y los sondeos, así como el reenvío de datos. El sistema selecciona la interfaz física con la ranura, PIC o número de puerto más bajo en cada nodo para los RTO y las sondas.

Uso de BFD

El protocolo de detección de reenvío bidireccional (BFD) es un mecanismo de saludo simple que detecta fallas en una red. Los paquetes Hello se envían en un intervalo regular especificado. Una falla de vecino se detecta cuando el enrutador deja de recibir una respuesta después de un intervalo especificado. BFD trabaja con una amplia variedad de entornos y topologías de red. Los tiempos de detección de fallas de BFD son más cortos que los tiempos de detección de RIP, lo que proporciona tiempos de reacción más rápidos a varios tipos de fallas en la red. Estos temporizadores también son adaptables. Por ejemplo, un temporizador puede adaptarse a un valor mayor si falla la adyacencia, o un vecino puede negociar un valor más alto para un temporizador que el configurado. Por lo tanto, la vivacidad BFD se puede configurar entre los dos nodos de un clúster de chasis de la serie SRX utilizando las interfaces locales y no las direcciones IP fxp0 en cada nodo. De esta manera, BFD puede seguir monitoreando el estado entre los dos nodos del clúster. Cuando hay algún problema de red entre los nodos, se envían las capturas SNMP de sesión inactiva BFD, lo que indica un problema entre los nodos.

Uso de la supervisión de IP

La supervisión de IP es un script de automatización que le permite utilizar esta función crítica en las plataformas de la serie SRX. Permite la validación de rutas y próximos saltos a través de la infraestructura de red existente mediante el Protocolo de mensajes de control de Internet (ICMP). Tras la detección de un error, el script ejecuta una conmutación por error al otro nodo en un intento de evitar el tiempo de inactividad.

Uso de la supervisión de interfaz

La otra característica del clúster de chasis de la serie SRX implementada se denomina supervisión de interfaz. Para que un grupo de redundancia conmute automáticamente por error a otro nodo, sus interfaces deben ser monitoreadas. Al configurar un grupo de redundancia, puede especificar un conjunto de interfaces que el grupo de redundancia debe supervisar para el estado o el estado para determinar si la interfaz está activa o inactiva. Una interfaz supervisada puede ser una interfaz secundaria de cualquiera de sus interfaces Ethernet redundantes (reth). Cuando se configura una interfaz para que supervise un grupo de redundancia, se le asigna un peso. Cada grupo de redundancia tiene un valor de tolerancia umbral establecido inicialmente en 255. Cuando una interfaz supervisada por un grupo de redundancia deja de estar disponible, su peso se resta del umbral del grupo de redundancia. Cuando el umbral de un grupo de redundancia alcanza el 0, conmuta por error al otro nodo. Por ejemplo, si el grupo de redundancia 1 era primario en el nodo 0, en el evento de cruce de umbral, el grupo de redundancia 1 se convierte en primario en el nodo 1. En este caso, todas las interfaces secundarias de las interfaces reth del grupo de redundancia 1 comienzan a controlar el tráfico. Se produce una conmutación por error de grupo de redundancia porque el peso acumulado de las interfaces supervisadas del grupo de redundancia ha llevado su valor de umbral a 0. Cuando las interfaces supervisadas de un grupo de redundancia en ambos nodos alcanzan sus umbrales al mismo tiempo, el grupo de redundancia es primario en el nodo con el ID de nodo inferior, en este caso, nodo 0.

Nota:

No se recomienda la supervisión de interfaz para el grupo de redundancia 0.

Uso de un reinicio correcto

Con los protocolos de enrutamiento, cualquier interrupción del servicio requiere que un enrutador afectado recalcule las adyacencias con enrutadores vecinos, restaure las entradas de la tabla de enrutamiento y actualice otra información específica del protocolo. Un reinicio desprotegido de un enrutador puede provocar retrasos en el reenvío, aleteo de rutas, tiempos de espera derivados de la reconvergencia del protocolo e incluso paquetes perdidos. Los principales beneficios de un reinicio correcto son el reenvío ininterrumpido de paquetes y la supresión temporal de todas las actualizaciones del protocolo de enrutamiento. El reinicio correcto permite que un enrutador pase a través de estados de convergencia intermedios que están ocultos para el resto de la red.

Hay tres tipos principales de reinicio correcto disponibles en las plataformas de enrutamiento de Juniper Networks:

  • Reinicio correcto para rutas agregadas y estáticas y para protocolos de enrutamiento: proporciona protección para rutas agregadas y estáticas y para BGP, sistema final a sistema intermedio (ES-IS), IS-IS, OSPF, RIP, RIP de próxima generación (RIPng) y protocolos de enrutamiento en modo disperso de multidifusión independiente de protocolo (PIM).

  • Reinicio correcto para protocolos relacionados con MPLS: proporciona protección para LDP, RSVP, conexión cruzada de circuitos (CCC) y conexión cruzada de traslación (TCC).

  • Reinicio correcto para redes privadas virtuales (VPN): proporciona protección para VPN de capa 2 y capa 3.