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 una red tendremos que redundar el hardware y también usar protocolos para redundar o recuperar servicios. Junos disponen de una serie de características para incrementar la disponibilidad de la red. Destacamos las siguientes:
- Graceful Restart (GR): permite el envío ininterrumpido de paquetes y la supresión de las actualizaciones de todos los protocolos. Habilita que cuando un router está cambiando de estado, esto se oculte al resto de equipos y la convergencia no sufra cambios.
- Graceful Routing Engine Switchover (GRES): si un equipo tiene 2 REs, esta opción hace que si la RE activa falla, se active la otra sin perder paquetes en el envío. Mantiene la información de interfaces y kernel. GRES no mantiene, sin embargo, el "control plane".
- Nonstop Active Routing (NSR): usa la misma estructura de GRES. También mantiene la información de los protocolos de enrutamiento al correr el proceso rpd en la otra RE. Es una buena opción cuando los otros routers no soprotan GR. NSR y GR no pueden estar activados a la vez, pero para que funcione NSR tiene que estar activado GRES.
- Bidirectional Forwarding Detection: es un mecanismo de "hellos" para detectar fallos en la red enviando paquetes periódicamente. El fallo es detectado cuando no se recibe el "hello". Tiene unos tiempos de detección inferiores a la mayoría de mecanismos de detección.
- Virtual Router Redundancy Protocol: habilita que los host en LAN tengan redundancia de la puerta de enlace por defecto. Un equipo actúa de master y los demás de backup y cuando falla el master, que es el activo, se activa uno de los backups. Actúa como el HSRP de Cisco.
- Unified-In-Service Software Upgrade (ISSU): habilita la opción de actualizar el software de Junos en dos equipos que lo tengan desigual sin interrupción. ISSU es soportado solo en plataformas con Dual Routing Engine. Además GRES y NSR deben estar activados.
GRACEFUL RESTART (GR)
Cuando R1 se reinicia, pide a los vecinos un tiempo de "grace" para que estos no notifiquen las caída al resto de la red.
El Graceful restart ocurre cuando se cumplen las siguientes condiciones:
- La topología de la red es estable
- Los vecinos cooperan
- Que el "router restart" no esté ejecutando ya un GR
- El tiempo del Grace no ha expirado
Protocolos soportados por GR
- BGP
- ES-IS
- IS-IS
- OSPF/OPSFv3
- PIM Sparse Mode
- RIP/RIPng
- MPLS
- LDP
- RSVP
- CCC
- TCC
- VPN (capa 2 y 3)
Requisitos de GR
Tanto el router que cae (restart router) como los vecinos (helper routers) deben tener habilitado GR.
El modo "helper router" viene configurado por defecto. Para el "restart router" lo debemos configurar. Además para este último, el equipo debe soportar operaciones de "nonstop forwarding", que en los equipos con Junos, al tener separadas por la arquitectura, la RE y la PFE lo cumplen perfectamente.
GRACEFUL ROUTING ENGINE SWITCHOVER
GRES habilita a un equipo con dos RE o que esté participando en un plataforma de enrutamiento 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 el rpd, el kernel, las interfaces 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
- Una vez configurado GRES, las RE's se sincronizan e intercambian paquetes "keepalive".
- 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.
- 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".
- 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 ver los roles de las RE:
{master}
user@R1-re0> show chassis routing-engine
Routing Engine status:
Slot 0:
Current state Master
Election priority Master (default)
...
Routing Engine status:
Slot
1:
Current
state Backup
Election priority Backup (default)
|
Se pueden aplicar configuraciones por grupo a las RE:
{master}[edit groups]
user@R1-re0# show
re1 {
system {
host-name R1-re1;
backup-router 172.18.66.1;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 172.18.66.51/24;
}
}
}
}
}
re0 {
system {
host-name R1-re0;
backup-router 172.18.66.1;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 172.18.66.50/24;
}
}
}
}
}
Aplicamos los grupos a nivel raíz de
la configuración:
{master}[edit]
user@R1-re0# set
apply-groups [re0 re1]
|
Con este ejemplo de configuración le damos a cada grupo de RE un nombre y le asignamos una dirección ip de gestión "fuera de banda" (OoB). Una cosa a tener en cuenta es que la RE de backup no está ejecutando el proceso RPD, por lo que no tiene rutas instaladas. Con la opción "backup-router" le instalamos la ruta (en este caso es una ruta por defecto). La dirección que tenemos configurada es la puerta de enlace. Esta opción de "backup-router" puede ser configurada a nivel de "system", lo cual Juniper recomienda.
Una vez hemos configurado GRES, cada vez que modifiquemos la configuración del equipo debemos usar la opción "commit synchronize", para que salve los cambios también en la RE de backup porque si no lo hacemos veremos un mensaje como este:
{master}[edit chassis]
user@R1-re0# commit
warning: graceful-switchover is enabled, commit
synchronize should be used
commit complete
|
Podemos configurar el equipo para que cada vez que hagamos un commit aplique un "commit synchronize". Lo hacemos de esta manera:
{master}[edit system]
user@R1-re0# set commit synchronize
{master}[edit system]
user@R1-re0# commit
re0:
configuration check succeeds
re1:
commit
complete
re0:
commit complete
|
En algunas implementaciones con virtualización, el commit synchronize viene configurado por defecto.
Una vez configurado el commit synchronize, las RE se intercambian "keepalive". Si la RE de backup no recibe keepalives en el tiempo que hayamos configurado (2 segundos por defecto), la RE de backup entiende que la principal está fuera de línea y toma el rol de Master. Cuando hay un cambio de rol de RE, la PFE se desconecta de la RE caída y se conecta a la nueva RE master. La PFE no se reinicia, sigue enviando tráfico basado en las entradas que tienen en la forwarding table. Entonces la nueva RE Master sincroniza su estado con la PFE.Y si la RE detecta que la PFE no está actualizada, le manda la actualización.
Cuando GRES está habilitado, el router altera el flujo de información de la RE a la PFE. Entonces duplica los cambios hechos en la master y los pasa a la de backup, antes de notificarle esos cambios a la PFE. Cuando no está habilitado, directamente se pasa la información de la RE a la PFE.
Si GRES no está habilitado, Juniper recomienda habilitar el "failover protection" en la RE bajo el nivel de configuración "system chassis redundacy". Se puede configurar keepalives (300 ms por defecto) y el rol de las RE:
[edit chassis redundancy]
user@R1# set ?
Possible completions:
+ apply-groups Groups from which to inherit
configuration data
+ apply-groups-except Don't inherit configuration
data from these groups
> failover Failover to other Routing Engine
keepalive-time Time before Routing Engine failover
(2..10000 seconds)
> routing-engine
Redundancy options for Routing Engines
|
Si necesitamos cambiar el rol de las RE manualmente, lo hacemos así:
- request chassis routing-engine master switch
user@R1> request chassis routing-engine master
?
Possible completions:
acquire Attempt to become master Routing Engine
release Request that other Routing Engine become
master
switch Toggle
mastership between Routing Engines
|
Configuración GRES
- set redundancy graceful-switchover
Podemos ver cómo el indicativo que nos da la referencia de la RE cambia.
Monitorización de GRES
Se suceden 3 estados cuando la RE master replica la información en la RE de backup:
- Configuración de la base de datos: se replica con commit syncrhonize. Procesos como el dcd o el chassid necesitan de las base de datos para funcionar correctamente.
- Kernel (núcleo) y entradas relacionadas: cuando habilitamos GRES, Junos inicia un proceso llamado ksyncd. Es el responsable de replicar el estado del kernel a componentes hardware.
- Estado PFE: Junos usa el proceso chassisd para la replicación a la PFE. Cuando hay un cambio de RE, el chassisd hace un pequeño reseteo del inventario del hardware. Cuando estos componentes hardware reponden al reseteo, el sistema los conecta a la RE de backup y los activa.
NONSTOP ACTIVE ROUTING
NSR habilita al equipo con dos RE la capacidad de cambiar de la master al backup sin alertar a los nodos. NSR usa la misma infraestructura de GRES. NSR guarda la información del kernel, de las interfaces y del proceso de routing "rpd" en el backup, manteniendo rutas y protocolos en activo. NSR es independiente, no necesita de "helper router" como GR. En escenarios donde no existe GR es una buena opción. Es importante recordar que GR y NSR no son compatibles, no se pueden configurar ambos en el mismo equipo, nos dará error al hacer "commit".
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. En caso de fallo, los protocolos no soportados actuarán como esté diseñado el protocolo.
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 |
Si queremos entrar a la RE de backup desde la Master:
{master}
user@R1-re0> request
routing-engine login other-routing-engine
|
Y desde la RE de backup vemos las rutas de los protocolos instaladas:
{backup}
user@R1-re1> show ospf neighbor
Address Interface State ID Pri Dead
10.1.1.2 fe-0/0/1.0 Full 192.168.100.2 128 0
10.1.2.2 fe-0/0/2.0 Full 192.168.100.3 128 0
{backup}
user@R1-re1> show bgp summary
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp
State Pending
inet.0 10 10 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
192.168.100.2 64700 55 54 0 0 24:29 5/5/5/0
0/0/0/0
192.168.100.3 64700 54 52 0 0 23:53 5/5/5/0
0/0/0/0
{backup}
user@R1-re1> show route protocol ospf
inet.0: 21 destinations, 34 routes (19 active, 0
holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.100.2/32 *[OSPF/10] 00:39:47, metric 1
> to 10.1.1.2 via fe-0/0/1.0
192.168.100.3/32 *[OSPF/10] 00:39:47, metric 1
> to 10.1.2.2 via fe-0/0/2.0
224.0.0.5/32 *[OSPF/10] 00:44:22, metric 1
MultiRecv
|
También podemos habilitar un "traceoptions" para meter en un archivo los mensajes de log:
{master}[edit protocols ospf]
user@R1-re0# show
traceoptions {
file nsr-trace;
flag nsr-synchronization detail;
}
|
DETECCIÓN DE FALLOS DE RED
Protocolos como OSPF, IS-IS o BGP tienen sus propios caminos de detección de fallos. Sin embargo, los tiempos por defecto que manejan pueden ser muy lentos para una red de producción crítica.
Estos tiempos se pueden modificar para que la detección tenga unos tiempos más pequeños para declarar los enlaces a los vecinos caídos. Podemos configurarlos para que lo detecten al segundo. Sin embargo, esto hace que los "hellos" o "keepalives" se envíen en mayor cantidad, es decir, con un intervalo más pequeño y, esto puede cargar a los equipos, afectar en el rendimiento de este y, consecuentemente, en el propio protocolo.
BIDIRECTIONAL FORWARDING DETECTION (BFD)
El protocolo BFD está diseñado para la detección rápida de fallos de red. Una vez que han negociado por BFD los vecinos, se establece una sesión entre ellos. BFD envía continuamente hellos por ese enlace para monitorizar al vecino. Si deja de recibir los hellos en el intervalo configurado, declara al vecino caído y tira la sesión. BFD puede detectar los fallos en menos de 1 segundo.
Configuración de BFD
BFD se configura bajo el protocolo de enrutamiento o la ruta estática.
Por defecto, cuando configuramos el intervalo de BFD se le aplica un "multiplier 3", es decir, cuando se dejen de recibir 3 intervalos es cuando se declara caído. En este caso serían al final 900 ms. En algunos equipo Junos, BFD lo gestiona el PPM (periodic packets management) en la PFE. Así descagamos a la RE. En los equipos con la posibilidad de usar PPM, este viene configurado por defecto.
No todos los tipos de enlace se benefician claramente de BFD. En enlaces ATM o SONET, los propios mecanismos de detección de fallos son ya óptimos y BFD no supone un mayor beneficio. Sin embargo para enlaces Ethernet sí que lo es. Aunque para enlaces podemos usar Ethernet OAM para detectar los fallos también de una manera muy rápida, pero OAM trabaja en la capa 2. OAM está fuera del estudio del JNCIS-ENT.
Si los vecinos tienen configurados intervalos diferentes, BFD se adapta y elige el intervalo mayor.
Dependiendo del protocolo en donde configuremos BFD nos dará unas opciones u otras:
[edit protocols]
user@R1# set ospf area 0 interface ge-0/0/1.0
bfd-liveness-detection ?
Possible completions:
+ apply-groups Groups from which to inherit
configuration data
+ apply-groups-except Don't inherit configuration
data from these groups
> authentication Authentication options
> detection-time Detection-time options
full-neighbors-only
Setup BFD sessions only to Full neighbors
minimum-interval
Minimum transmit and receive interval (milliseconds)
minimum-receive-interval
Minimum receive interval (1..255000 milliseconds)
multiplier
Detection time multiplier (1..255)
no-adaptation
Disable adaptation
> transmit-interval Transmit-interval options
version
BFD protocol version number
[edit
protocols]
user@R1# set bgp bfd-liveness-detection ?
Possible completions:
+ apply-groups Groups from which to inherit
configuration data
+ apply-groups-except Don't inherit configuration
data from these groups
> authentication Authentication options
> detection-time Detection-time options
holddown-interval
Time to hold the session-UP notification to the client
minimum-interval
Minimum transmit and receive interval (milliseconds)
minimum-receive-interval
Minimum receive interval (1..255000 milliseconds)
multiplier
Detection time multiplier (1..255)
no-adaptation
Disable adaptation
> transmit-interval Transmit-interval options
version BFD protocol version number
|
Podemos configurar BFD bajo el protocolo, el grupo o el vecino.
Monitorización de BFD
Si quisieramos deshabilitar la adaptación de BFD a los intervalos diferentes debemos configurarlo con el comando "no-adaptation".
user@R1> show bgp neighbor 172.18.1.1
Peer: 172.18.1.1+179 AS 65510 Local:
172.18.1.2+49363 AS 64700
Type: External State: Established Flags:
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ adv-aggregates ]
Options:
Options:
Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 10.10.10.10 Local ID: 192.168.1.1 Active
Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: enabled, up
|
Podemos ver en el protocolo que BFD está habilitado
Si vemos que la sesión BFD no se levanta, tendremos que comprobar la configuración en ambos equipos, si son compatibles o si tenemos "firewall Filters" aplicados, etc.
VRRP es un protocolo estándar (RFC 2338) que ofrece redundancia para entornos LAN. Nos elimina la posibilidad de un "único punto de fallo". VRRP selecciona uno de los routers como Master y es el que actúa como puerta de enlace dejando los demás routers como backup. Cumple la misma función que el HSRP de Cisco.
Conceptos de VRRP
El virtual router, desde el punto de vista del usuario LAN, es un router lógico que actúa como puerta de enlace de la LAN. El virtual router se compone de un VRID (virtual router identifier) y una VIP (virtual ip). El VRID es un identificativo para cada router virtual. La VIP es administrada por el router que actúa como Master.
La comunicación VRRP ente routers se hace a través de la dirección multicast 224.0.0.18. Estos paquetes tienen un TTL de 255 y no pueden ser enviados más allá de la LAN. El TTL no se puede modificar y si llega un paquete con otro TTL se descarta. El intervalo de envío de estos mensajes es por defecto de 1 segundo. Se puede configurar este intervalo de 1 a 255. Si necesitamos un intervalo menos de 1 segundo podemos configurar la opción "fast-interval" que nos da un rango de entre 100 y 999 ms. (pero todos los routers participantes deben soportar esta opción).
Algunos campos de configuración de VRRP tienen que coincidir en todos los equipos que participen, como por ejemplo el VRID. Si no, se descartan y no se forma el grupo VRRP.
Cuando un router VRRP envía un paquete VRRP, el router envía una mac virtual como mac de origen. Si un equipo de la LAN hace un ARP de la dirección virtual, el router Master responde con la mac virtual asociada al virtual router (o también le podemos decir el grupo VRRP). La mac virtual es única para cada grupo y de hecho se usa el número del grupo para construirla. VRRP crea la mac virtual de esta manera: 00-00-5E-00-001-VRID
Elección del Master
 |
| Gana la más alta |
Para determinar el rol de los routers, VRRP usa la prioridad. La prioridad puede ir de 1 a 255, siendo la de por defecto 100. Si el router Master falla, el router con la siguiente mayor prioridad tomaría el rol de master. Cuando el Master anterior vuelve a levantarse, si tiene la opción "preempt" configurada volvería a tomar el rol de Master. Si no la tiene, se quedaría como backup.
Nota: Preempt está configurado por defecto
Estados de VRRP
Antes de la elección del master y backup para los grupos VRRP, cada router anuncia capacidades y opciones de configuración como la prioridad. Durante esta fase (initialized) no se envía tráfico. Basándose en la información intercambiada por los routers, se elige un master y los demás routers que participan en el grupo VRRP se quedan como backups. El master asume la responsabilidad del curso del tráfico para la VIP y las respuestas ARP. El master envía periódicamente anuncios a los otros routers VRRP (anuncia su prioridad entre otras cosas). Si no se reciben estos anuncios, el router de backup con mayor prioridad tomará el rol de master.
Ejemplo de Configuración
 |
| R1 tomaría el rol de master gracias a la prioridad más alta |
Ahora imaginemos que tenemos muchos equipos finales en la misma subred. En vez de que todos esos equipos tengan un única VIP para salir de la LAN, podemos configurar balanceo de carga. Lo que hacemos es crear más de un grupo VRRP para el mismo direccionamiento de la subred. Por ejemplo, digamos que tenemos un direccionaiento 192.168.0.0/24 y para balancear la carga de los routers, queremos que la mitad de los usuarios salgan por el R1 y la otra mitad por R2.
R1
[edit interfaces]
ge-0/0/0 {
unit 0 {
family inet {
address 192.168.0.2/24 {
vrrp-group 10 {
virtual-address 192.168.0.1;
priority 150;
advertise-interval 3;
preempt;
}
vrrp-group 11 {
virtual-address 192.168.0.254;
priority 100;
advertise-interval 3;
}
}
}
}
}
------------------------------------------------------
R2
[edit interfaces]
ge-0/0/0 {
unit 0 {
family inet {
address 192.168.0.3/24 {
vrrp-group 10 {
virtual-address 192.168.0.1;
priority 100;
advertise-interval 3;
}
vrrp-group 11 {
virtual-address 192.168.0.254;
priority 150;
advertise-interval 3;
preempt;
}
}
}
}
}
|
Como podemos ver, creamos 2 grupos VRRP para el mismo direccionamiento, pero cada grupo tiene una VIP diferente. La clave es que en los equipos finales tendríamos que configurar la VIP por la queramos que salgan, es decir, manualmente le decimos que puerta de enlace deben elegir para salir fuera de la LAN. Cada router sería el VRRP Master para la mitad de los equipos de la LAN.
Este ejemplo lo podemos hacer con VLANS. Si tenemos muchas VLANS en nuestra LAN, podemos asignar grupos VRRP para cada VLAN y forzar que la mitad de ellas tengan como Master a R1 y la otra mitad a R2.
Opciones de Configuración
 |
| La autenticación puede ser: ninguna, simple o con MD5 |
Existe una opción llamada "vrrp-inherit-from" cuando hay varios grupos VRRP en la misma interface física. Con esto le decimos que herede campos de la configuración del grupo activo. Los campos que hereda son:
- advertise-interval
- authentication-key y authentication-type
- fast-interval
- preempt y no-preempt
- track interface y track route
Cuando usamos esta opción también reducimos el tráfico VRRP que pasa por la interfaces, ya que solo el grupo activo es el que intercambia los mensajes VRRP. Los demás grupos también heredan el estado del grupo activo.
Para monitorizar VRRP:
 |
| show vrrp summary - show vrrp ? |
Cuando tenemos configurado VRRP en Junos, el equipo de tiene el rol de backup no aprende direcciones ip y macs, es decir, no crea la tabla ARP. Es una vez activado, si coge el rol de master, empieza a aprender. Esto lleva un tiempo, así que para hacer todavía más rápida la transición del tráfico, tenemos la opción de configurar para que el equipo de backup lo aprenda. Tenemos que configurar debajo de "system/arp":
[edit system arp]
passive-learning;
Importante recordar configurarlo en todos los equipos que conforman el grupo VRRP, incluido el equipo que esté haciendo de "master", pues este puede caer y coger el rol de "backup" y no aprender direcciones si no lo tiene configurado.
UNIFIED ISSU
Nos da la posibilidad de actualizar dos imágenes de Junos diferentes sin interrupción del tráfico en el plano de control y con una mínima disrupción del tráfico en general. Solo es soportado en Plataformas Dual Routing Engine. Además GRES y NSR deben estar activados. La RE master y la RE de backup deben tener la misma versión de software. Nota importante es que no debemos ni quitar ni poner ninguna PIC durante el proceso.
Proceso para ISSU
- Habilitamos GRES y NSR y comprobamos que las REs y los protocolos están sincronizados
- Verificamos que las RE master y backup tienen la misma versión de software
- Descagamos la versión de software de la web de Juniper y la copiamos en el router
- Escribimos en la RE Master: request system software in-service-upgrade
Para comprobar FPC y PIC:
- show chassis in-service-upgrade
Si queremos cancelar la actualización:
- request system software abort in-service-upgrade
No hay comentarios:
Publicar un comentario