Capítulo 7: High Availability Features

Con High Availability (alta disponibilidad) Juniper nos habla de la capacidad para asegurar la continuidad de los servicios.

Para maximizar la disponibilidad de los recursos tendremos que tomar algunas consideraciones a la hora de hacer el diseño de la red:

• ¿Están las funcionalidades básicas del hardware y software protegidas?
• Cuando ocurre un fallo, ¿cómo reacciona la red y qué nivel de recuperación presenta?

Para proteger bien un red tendremos que redundar el hardware y también usar protocolos para redundar o recuperar servicios. Por ejemplo, los switches EX disponen de una serie de características para incrementar la disponibilidad de la red. Destacamos las siguientes:

• Link Aggregation Groups (LAGS) -  Combina múltiples interfaces ethernet en una sola. Está definido en el 802.3ad.
• Redundant Trunk Groups (RTG) - Redundancia de enlaces de capa 2
• Greaceful Routing Engine Switchover (GRES) - Controla la comunicaciones entre las RE master y backup
• Nonstop Active Routing (NSR) - Habilita un cambio de RE sin pérdidas de servicio
• Nonstop Bridging (NSB) - Igual que NSR pero con protocolos de capa 2

LINK AGGREGATION GROUPS - LAGS

Cuando se implementa LAGS se hace en conexiones P2P entre dos dispositivos. Dependiendo del número de interfaces que participen, incrementará proporicionalmente el ancho de banda del LAG y además aumenta también la disponibilidad para transportar tráfico si se cae un interfaz.

Para crear un LAG hay que tener en cuenta que:

• La configuración del Duplex tiene que ser igual en ambos equipos
• Un máximo de 8 interfaces para formar un LAG
• Los miembros no tienen por qué estar conectados por puertos contiguos y pueden ser miembros de diferentes Virtual Chassis.

Consideraciones sobre el procesamiento del tráfico cuando hemos configurado un LAG:

• Todo tráfico generador por la RE que atraviese el LAG usará el miembro más bajo
• El algoritmo de balanceo de "tráfico IP" usa criterios de capa 2, 3 y 4. No se necesita configurar nada para habilitar el balanceo de carga.
• El algoritmo de balanceo de "tráfico NO IP" usa las direcciones mac de origen y destino

El protocolo que usa Junos es LACP - Link Aggregation Control Protocol (802.3ad). Se usa para unir dos o más interfaces físicas en una lógica, para interfaces Tagged (Troncal) o Untagged (de acceso).

El modo de los equipos puede ser activo o pasivo. Siempre tendrá que haber uno activo para formarse. Al equipo local se le llama "actor" y al remoto se le llama "partner". Se intercambian siempre PDU's a través de todos los enlaces físicos para asegurarse de que están funcionando todos los enlaces correctamente.

Para crear un LAG:

#set chassis aggregated-device ethernet device-count X - siendo X el número de LAGS que creamos

Cuando creamos LAGS empieza la númeración con ae0

Y después configuramos las interfaces ethernet:

Configuración de un Aggregated de capa 2

Por defecto, los equipos mandan paquetes LACP cada segundo. Este intervalo se puede modificar:

#set interfaces ae0 aggregated-ether-options lacp periodic fast/slow

Si configuramos fast el intervalo es cada segundo. Slow es cada 30. Se puede incluso configurar a diferente intervalo cada equipo.

Para monitorizar LACP:

También podemos usar: show lacp interfaces o show interfaces lacp statistics

Para monitorizar a través de un traceoption, tenemos que hacerlo desde "protocols lacp".

REDUNDANT TRUNK GROUPS - RTG

Es un simple mecanismo de redundancia de capa 2. Se puede usar en sustitución de STP en enlaces entre switches.

Cuando el activo falla, entra el backup. Tiempo de respuesta de menos de 1 segundo

Junos solo manda tráfico por el activo y descarta los del backup. Estos descartes se pueden ver en las estadísticas del interface. Sin embargo, el tráfico de control sí lo permite, como el LACP o el LLDP. Solo descarta el tráfico de datos. 

Algunas consideraciones:

• RTG se suele configurar en switches de acceso
• RTG y STP no pueden coexistir en el mismo puerto
• RTG descarta las BPDU de STP
• STP se suele configurar en switches de distribución (aggregation)
• Si se configura RTG como TRUNK, deben compartir las mismas vlans
• Máximo de 16 RTG por switch

Un ejemplo de configuración:

Configurar RTG  en el switch 3 y asegurarse de que el tráfico se envía por el ae0.0 siempre que esté operativo.

En el switch 3:

#set ethernet-switching-options redundant-trunk-group group rtg-1 interface ae0.0 primary

#set ethernet-switching-options redundant-trunk-group group rtg-1 interface ge-0/0/10.0

Si no ponemos el "primary", elegirá la interface más alta en número

Para monitorizar el RTG:

show redundant-trunk-group 

GRACEFUL ROUTING ENGINE SWITCHOVER - GRES

GRES habilita a un switch con dos RE o que esté participando en un Virtual Chassis la capacidad de continuar enviando paquetes con la menor interrupción de tráfico posible cuando la RE master ha fallado. GRES mantiene la información de las interfaces y el kernel asegurando que no se interrumpe tráfico. Sin embargo, no conserva el plano de control, por lo que procesos como el de routing (rpd) se deben ejecutar otra vez y aprender las rutas (a no ser que tengamos configurado NSR). Todos los cambios de las RE master se actualizan en la de backup.

Sin GRES, la PFE se reinicia, reiniciaría todos los procesos y descubriría la RE de backup.

Con GRES, la PFE  no se reinicia. Esto reduce considerablemente el tiempo del "switchover".

GRES está deshabilitado por defecto.

Proceso del GRES

1. Una vez configurado GRES,  las RE's se sincronizan e intercambian paquetes "keepalive".
2. Si la RE de backup no recibe un keepalive en 2 segundos (por defecto), determina que la RE principal ha fallado y toma el rol de Master.
3. La PFE se desconecta de la RE principal y se conecta a la de backup. La PFE no se reinicia y sigue enviando tráfico en base a las entradas de la tabla de "forwarding".
4. La nueva RE master y la PFE se sincronizan y la RE manda "updates" a la PFE.

Si quisiéramos hacer un cambio de RE manualmente, tendríamos que usar:

>request chassis routing-engine master switch

Para configurar GRES:

#set chassis redundancy graceful-switchover

Para monitorizar GRES:

show system switchover - solo en la RE de backup

La RE master replica su estado a la RE de backup y a la PFE. Hay 3 estados importantes a copiar:

• Configuration database: se replica cuando hacemos "commit synchronize"
• Kernel y entradas relacionadas: se inicia un proceso llamado "ksyncd" que es el responsable de la replicación de varios de los componentes hardware.
• Estado de la PFE: el proceso "chassisd" hace un reinicio suave para preguntar por el hardware cuando hay un cambio del rol de la RE

NONSTOP ACTIVE ROUTING - NSR

NSR habilita al equipo con dos RE o en Virtual Chassis la capacidad de cambiar del primario al backup sin alertar a los nodos. NSR usa la misma infraestructura de GRES. NSR guarda la información del proceso de routing "rpd" en el backup, manteniendo rutas y protocolos en activo.

Las RE tienen que tener la misma versión de Junos. No soporta todos los protocolos ni se puede configurar en todos los equipos EX.

Para configurar NSR:

#set routing-options nonstop-routing

#commit synchronize

Es importante recordar que para configurar NSR se necesita configurar también GRES.

Para monitorizar NSR:

show task replication - se pueden ver también protocolos

NONSTOP BRIDGING ROUTING - NSB

NSB habilita al equipo con dos RE o en Virtual Chassis la capacidad de cambiar del primario al backup sin alertar a los nodos. NSB usa la misma infraestructura de GRES. también salva la información de capa 2 usando el proceso "eswd" en el equipo de backup. NSB hace lo mismo que NSR pero con los protocolos de capa 2 en vez de los de capa 3.

Las RE tienen que tener la misma versión de Junos. No soporta todos los protocolos de capa 2 ni se puede configurar en todos los equipos EX.


Para configurar NSB:


#set ethernet-switching-options nonstop-bridging

#commit synchronize

Es importante recordar que para configurar NSB se necesita configurar también GRES.

No hay ninguna tabla específica para comprobar si NSB  está funcionando correctamente. Tendremos que ir al equipo de backup y ver que la capa 2 está todo bien.


>show spanning-tree bridge


Si nos apareciera el siguiente mensaje, querría decir que no está configurado en el equipo:

error: the ethernet-switching subsystem is not running

Capítulo 8: Ethernet Ring Protection Switching