Por lo tanto, con HSRP, abreviatura de Protocolo de Enrutador en espera Caliente, vamos a tener dos enrutadores: uno activo y uno en espera. Ahora podríamos tener más enrutadores participando en el grupo HSRP general que estamos creando, pero tendrían que esperar al margen. Así que nuestro enfoque principal aquí es solo el activo y el de espera. Ahora vemos aquí al grupo HSRP. ¿Qué entendemos por grupo cuando se trata de HSRP?
Bueno, en una subred, normalmente tenemos un grupo de enrutadores y el grupo de enrutadores está configurado para reenviar la dirección IP virtual y la dirección MAC virtual que se combina con eso. En términos generales, cada subred obtiene un grupo. Y tienen que participar, de lo contrario están inconexos. Necesitan compartir el mismo número de grupo para participar. Así que el enrutador activo estaría reenviando. El enrutador de espera espera en las alas y lo entiende porque dice: «hola, soy el siguiente mejor de este grupo». Ahora bien, las complejidades de cómo se llevan a cabo la actividad y la espera son bastante intrigantes, son realmente geniales, pero al final tenemos que entender los valores predeterminados aquí. Hay un número de prioridad que está asociado con cada uno de estos enrutadores que participan en el grupo, y es un centenar (100). Ahora, a diferencia de otras tecnologías que hemos visto en este curso, se prefiere más alto, ¿de acuerdo? Así que tenemos que ser conscientes de ello.
Por lo que el dispositivo que tiene la prioridad más alta se convierte en el promotor activo para nuestro grupo. Si desea muchos detalles sobre cómo nuestro enrutador está participando en HSRP, podríamos hacer este comando, mostrar en espera. Seré honesto. Me gusta el comando breve de espera del espectáculo, porque muestra lo que me importa. Pero para mí, voy a mirar aquí y voy a ver cómo está participando este enrutador en referencia a su interfaz.
R1 # show standbyEthernet0 / 0-Grupo 1El estado está activo2 cambios de estado, último cambio de estado 00:01:37La dirección IP virtual es 10.1.1.100La dirección MAC virtual activa es 0000. 0c07.ac01La dirección MAC virtual local es 0000.0c07.ac01 (predeterminado de v1)Tiempo de hola 3 segundos, tiempo de espera 10 segundosSiguiente hola enviado en 1.680 segundosActivado por adelantadoEl enrutador activo es localEl enrutador en espera es 10.1.1.2, prioridad 100 (caduca en 10.320 segundos)Prioridad 200 (configurada 200)El nombre del grupo es «hsrp-Et0/0-1» (predeterminado)
R1 # mostrar resumen en esperaP indica que está configurado para anticiparse.|Interfaz Grp Pri Estado P IP Virtual en espera activaEt0/0 1 200 P Local activo 10.1.1.2 10.1.1.100
Estado activo, por lo que si se le pregunta, ¿es este el enrutador de reenvío? La respuesta sería, absolutamente. Puede ver la dirección IP del enrutador virtual, que es a lo que su cliente debe apuntar. Por cierto, debe asegurarse de ajustar la configuración de DHCP. Porque si creas esta dirección IP virtual pero no apuntas a los clientes a ella, eso no es bueno.
Puede ver la dirección MAC virtual, que es muy interesante. En una discusión más profunda, te enseñaríamos sobre esto y, oye, te voy a dar el vuelo ahora mismo. Los primeros seis caracteres hexadecimales son consistentes, luego vemos 07.ac, que dice, esto es HSRP. Puede ver que 01 al final de la dirección MAC virtual, es decir, el número de grupo en hexadecimal. Así que si alguna vez tuvieras como grupo 10, si tuvieras grupo 10 tal vez para VLAN 10, diría 0a, porque eso es hexadecimal.
Podemos ver los temporizadores, 3 segundos hola, 10 segundos pulsados, lo que significa que, en su configuración predeterminada fuera de la caja, tiene un tiempo de convergencia de 10 segundos. ¿Y recuerdan a los administradores, a los que les gusta establecer una segunda puerta de enlace predeterminada, y luego la criticamos basada en la caché ARP? Bueno, esto es muy superior. Podemos ver, también de nuevo, que el enrutador activo es local. El enrutador en espera es 10.1.1.2 y necesitamos poder leerlo. La prioridad es 200, y esto es una gran cantidad de grandes resultados. Vale la pena leerlo de arriba a abajo.
Seguimiento de interfaz HSRP
¿Recuerda el valor de prioridad? ¿Qué era? ¿Cuál era el valor predeterminado?
De acuerdo. Son 100. Así que la prioridad predeterminada es 100.
Segunda pregunta. ¿Más alto o más bajo es mejor para HSRP?
Más alto es mejor.
Por lo tanto, quiero un mecanismo que ajuste dinámicamente mi prioridad en función de un estado de salud, por así decirlo. Quiero tener una prioridad menor si no estoy sano, y vamos a medir la salud basándose en la observación de interfaces locales. Esto se denomina seguimiento de interfaz HSRP. Así que lo que hago es esto. Disminuyo mi prioridad, lo que significa que le resto algunas cosas. Podría empezar con 100. Pierdo una interfaz. Voy a dejarlo a las 10. Ese es, de hecho, el valor de decremento predeterminado. Así que si ato múltiples interfaces a esto, y estas podrían ser las interfaces al núcleo de mi red, pierdo una, decremento en 10. Ahora tengo una prioridad de 90. Pierde otra prioridad de 80 e incluso hay formas de personalizar esto. Pero, ¿qué acabo de hacer? Miro el estado de mis puertos, un puerto cae y es un juego completamente nuevo. El enrutador en espera se puede configurar para que se haga cargo cuando vea que el enrutador activo tiene una prioridad menor. Necesitamos otra característica más allá del seguimiento de la interfaz: necesitamos preempt. Necesitamos que el enrutador de reserva sea lo suficientemente cómodo para tomar las riendas. A eso lo llamamos preempt en espera, de hecho es el comando. Por lo tanto, hacemos que el HSRP sea preventivo, lo que significa que lo ajustamos sobre la marcha. No preventivo dice que las elecciones solo se llevan a cabo al principio.
Por lo tanto, activamos el seguimiento de interfaces para disminuir nuestra prioridad en función de interfaces específicas, lo vinculamos al protocolo, luego le damos al enrutador en espera los medios para hacerse cargo con preferencia. Cuando hacemos eso, estamos enviando una configuración HSRP bastante robusta que nos permitirá tener chasis redundantes de capa tres a los que nuestros clientes están apuntados indirectamente. Y luego, podría ocurrir un fallo cuando falla un chasis o incluso si cosas más pequeñas, como las interfaces no afectan al grupo HSRP de forma directa, sino que lo afectan indirectamente en función del cambio de prioridades. Podemos hacer que el HSRP sea controlado y redundante de tal manera que maneje estos y nos brinde una disponibilidad tremendamente alta. E incluso puede llegar a ajustar los temporizadores para que sean mucho más agresivos que los predeterminados. Esas son cosas para otro día, pero ahora has visto una gran implementación de HSRP.
Equilibrio de carga HSRP
Piense en nuestra discusión sobre grupos. Dijimos, uno activo, uno en espera para un grupo. Por lo tanto, todo el tráfico para el grupo va a usar el mismo reenviador. Entonces, ¿podemos equilibrar la carga? No para un grupo específico, pero podríamos crear varios grupos y proporcionar equilibrio de carga. Piense en ello desde una base VLAN por VLAN. Tenemos VLAN 10 y VLAN 20 en nuestra organización. Podríamos usar un enrutador como reenvío activo para todo el tráfico que forma parte de VLAN 10 y podríamos usar otro enrutador como reenvío activo para VLAN 20 y luego, ¿qué podemos hacer? Podemos tenerlos el uno para el otro. Así que si uno falla, entonces el otro puede asumir la carga de todas las VLAN. Así que sí, podemos hacer el equilibrio de carga, pero tiene que ser grupo por grupo, subred por subred. Y es solo cuestión de crear los diferentes grupos basados en las direcciones IP virtuales y asegurarnos de que los clientes de cada una de esas subredes tengan la puerta de enlace predeterminada correcta asignada, y el tráfico pueda fluir como lo necesitamos. Así podemos aprovechar todos los enlaces dentro de nuestra organización y no solo tener un enlace 100% saturado.