VRRP: Cuando el router principal falla, pero nadie se entera
- jogofus
- 3 feb
- 4 Min. de lectura
Actualizado: 4 feb
En este blog siempre hacemos mucho hincapié en tratar de tener alta disponibilidad en la medida de lo posible.
Imaginemos que tenemos un único router, que es el principal con el que los usuarios finales salen a Intenet y, de repente, este decide dejar de funcionar. ¿Qué pasaría? ¿Tienes plan de contingencia?
Para evitar este problema, solemos recurrir a distintas tecnologías de alta disponibilidad que garantizan la continuidad del servicio. Es muy común recurrir a crear stacks en Fortigate o Watchguard, pero este escenario no siempre es el necesario.
En el caso de Fortigate, no es necesaria ninguna licencia adicional, pero por ejemplo, en Watchguard, sí. Y posiblemente en otras marcas también sea necesario.
Además, el stack se crea en la capa 2 del modelo OSI. Ambos dispositivos actúan como uno solo, y esto presenta una desventaja: si quieres actualizar un dispositivo y requiere reinicio, se reiniciarán los dos, dejando sin servicio temporalmente. Actualizo: no pasa con todos los dispositivos, hay algunas marcas are la actualización es escalonada
Pero tenemos una alternativa: VRRP.

VRRP: ¿qué es y por qué lo necesitamos?
Se trata de un protocolo tolerante a fallos, que opera en la capa 3 del modelo OSI.
Si disponemos de dos o más dispositivos podemos establecer un router primario, que será el encargado de enrutar todo el tráfico y, en caso de fallo del mismo, el router de backup asumirá su rol.
¿Cómo funciona?
Creamos una ip virtual flotante, que se compartirá entre los dispositivos pertenecientes al grupo VRRP. El equipo que esté como master será el que responderá a esa IP, y cuando falle, pasará a responder el siguiente dispositivo (según las prioridades que se hayan establecido a la hora de realizarse).
Además de la IP virtual, se crea una MAC virtual. Un router virtual tiene que utilizar la siguiente dirección MAC: 00-00-5E-00-01-XX. El último byte de la dirección es el identificador de router virtual (Virtual Router IDentifier o VRID), que es diferente para cada router virtual en la red.
¿Cuál es su ventaja frente al stack?
Como he dicho antes, el stack realiza los cambios en ambos dispositivos al mismo tiempo, haciendo que, si se tiene que reiniciar, se reinicien ambos dispositivos.
Con VRRP tenemos dos dispositivos independientes, con configuraciones independientes.
Esto supone tener que mantener dos equipos y tener la misma configuración en ambos (en caso de que ese sea nuestro requerimiento), y en el momento de aplicar parches o hacer un reinicio por motivos técnicos, no dejaremos sin servicio a la empresa.
Ventajas y desventajas de VRRP
Una de ellas ya ha sido comentada, que es la independencia de los dispositivos.
Tiene un número de grupos VRRP limitado a 255 (aunque en mi experiencia no he visto necesidad de tantos grupos VRRP, quizá en algún ISP...).
La convergencia es de unos 2-3 segundos (unos 7 paquetes de ICMP, para ser más exactos). Durante esta convergencia si que habrá pérdida de servicio, pero casi imperceptible para el usuario.
Con VRRP solo se puede tener un router en modo master (activo) a la vez, mientras que el resto permanecen a la espera sin uso.
A diferencia de su competencia, propietaria de Cisco, HSRP, VRRP es compatible entre diferentes marcas, definido en el RFC 3768. Con HSRP, solo se podría implementar entre dispositivos Cisco.
Se genera tráfico adicional para poder hacer un keepalive del dispositivo master. Esto se traduce en tráfico multicast con la IP 224.0.0.18 y el protocolo 112 en IPv4.
Laboratorio
Como es costumbre, siempre intento poner en práctica lo que aquí se explica.
Se ha creado un laboratorio sencillo, compuesto por dos Cisco como routers que harán la función de VRRP, conectados a dos switches, con dos redes distintas.
Red 1: 192.168.100.0/24
Red 2: 192.168.200.0/24
Linux1: 192.168.100.100
Linux2: 192.168.200.100
vIP 1: 192.168.100.1
vIP 2: 192.168.200.1
VRRP group: 100
VRRP group: 200

Router1:
enable
configure terminal
!
hostname router1
!
interface e0/0
ip address 192.168.100.2 255.255.255.0
vrrp 100 ip 192.168.100.1
vrrp 100 priority 110
vrrp 100 authentication md5 key-string Test123
no shut
!
interface e0/1
ip address 192.168.200.2 255.255.255.0
vrrp 200 ip 192.168.200.1
vrrp 200 priority 110
vrrp 200 authentication md5 key-string Test123
no shut
!Router2:
enable
configure terminal
!
hostname router1
!
interface e0/0
ip address 192.168.100.3 255.255.255.0
vrrp 100 ip 192.168.100.1
vrrp 100 priority 120
vrrp 100 authentication md5 key-string Test123
no shut
!
interface e0/1
ip address 192.168.200.3 255.255.255.0
vrrp 200 ip 192.168.200.1
vrrp 200 priority 120
vrrp 200 authentication md5 key-string Test123
no shut
!En los aruba, lo único que he hecho ha sido poner los puertos en modo capa 2 (no routing) y encenderlos. Por ese motivo no está puesto aqui.
Aquí vemos el estado de los dos router:
Router1:

Como vemos, el router1 es el de backup.
Router2:

Procedemos a hacer un ping desde Linux2 a Linux1 y vemos que pasa por Router2.

Si apagamos el router2, vemos que perdemos unos paquetes e inmediatamente router1 adopta el rol de master.

Como podemos ver, se han perdido 8 paquetes.

Si encendemos de nuevo router2, volveremos a ver la convergencia hacia router2.

En cuanto a lo comentado del keepalive, aqui dejo una muestra del tráfico generado para comprobar que el master sigue "vivo":






Comentarios