High Availability Series - Parte 3

En el artículo anterior he descrito como la agregación de enlaces nos puede ayudar tanto para obtener anchos de banda superiores a las de una única interfaz pública como para aumentar aún más los mecanismos de alta disponibilidad en el acceso a los servicios de Megaport.

by German S.
Solutions Architect @ Megaport | Multi-Cloud Evangelist, MTB Rider

Combinando la agregación con las Diversity Zones podemos incrementar la resiliencia de la solución un punto más. Estas funcionalidades nos vienen como anillo al dedo cuando lo que buscamos es HA en enlaces de nivel 2, pero qué pasa cuando queremos también tener alta disponibilidad en soluciones de nivel 3? Vamos a verlo.

MCRs

En la serie de artículos sobre el Megaport Cloud Router (MCR) doy un vistazo bastante detallado de que es un MCR, como se despliega, configura y conecta a nuestra red por lo que en esta sección de este articulo repetiré los temas tratados pero os dejo aquí enlaces a los cuatro primeros artículos de esa serie.

https://www.megaport.com/es/blog/megaport-cloud-router-parte-1/

https://www.megaport.com/es/blog/megaport-cloud-router-parte-2/

https://www.megaport.com/es/blog/megaport-cloud-router-parte-3/

https://www.megaport.com/es/blog/megaport-cloud-router-parte-4/

Los MCRs se pueden desplegar en pares para ofrecer redundancia a nuestra solución de conectividad de nivel 3.

La forma adecuada de hacerlo es desplegar un MCR en una Diversity Zone en un PoP y otro en otra Diversity Zone en otro PoP dentro de la misma Metro.

Esta solución permite mantener los enlaces (VXCs) con una latencia mínima pero con la ventaja de que si un PoP se ve afectado el otro MCR podrá seguir cursando el tráfico sin ningún problema evidente o latencia extra.

Despliegue de MCRs redundados

Para realizar un despliegue de una pareja de MCRs dentro de una misma Metro procederemos a desplegar el primer MCR en un PoP de la metro y el segundo en otro PoP.

En este ejemplo desplegaremos uno en el PoP que tiene Megaport en Digital Realty en Madrid y el Segundo en el PoP de Equinix Madrid.

A la hora de crear el primer MCR pondremos el nombre de la Metro en el campo “Select MCR Location” y seleccionaremos la “Diversity Zone” Blue y podremos ver como por defecto nos aparece el PoP de Digital Realty, hacemos click sobre él y luego en “Next”.

Seleccionamos la velocidad necesaria de Forwarding que tendrá el MCR y finalmente le otorgamos un nombre descriptivo, por último hacemos click en “Next” para que se nos muestre el resumen de lo que queremos desplegar. Para proceder hacemos click en “Add MCR”, luego en “Order” y confirmamos haciendo click en “Order Now”.

Ahora toca desplegar el segundo MCR para ello vamos a repetir el procedimiento pero esta vez seleccionaremos “Red” en el apartado de “Diversity Zone” y veremos como el PoP que aparece es el de Equinix. Hacemos click en “Next” para seguir adelante.

Repetimos la elección de velocidad y la asignación de nombre, también los pasos necesarios para ordenar el despliegue del segundo MCR.

Como se puede ver el resultado son dos MCRs desplegados dentro de la metro de Madrid, uno de ellos en el PoP de Digital Realty identificado dentro de la zona de diversidad azul y otro en el PoP de Equinix identificado como la zona de diversidad roja.

Nota: Para este ejemplo he conectado ambos MCRs a la región de Madrid de AWS, para ver los detalles de cómo realizar una conexión con AWS, estos se desarrollan en la Parte 5 de mis artículos de MCR Series.

Convergencia en BGP

Cuando tenemos más de un camino posible entre dos routers para intercambiar las mismas rutas llamaos a caminos redundados y hacemos uso de los protocolos de enrolamiento dinámico, como BGP, para que se encarguen, según nuestra configuración, de que camino elegimos para que el tráfico fluya.

La principal ventaja de esta aproximación es que si por algún problema un camino falla siempre tendremos caminos alternativos para que ambos routers puedan seguir en contacto e intercambiando rutas y cursando el tráfico.

Al tiempo que transcurre entre que el fallo es detectado por los routers involucrados hasta que estos reaccionan para resolver el problema y volver a un estado de red estable se lo conoce como convergencia.

Por defecto los temporizadores de los protocolos de enrolamiento dinámico son muy conservadores para evitar falsos positivos en la re convergencia de una red por micro cortes o pérdidas de paquetes, para que os hagáis una idea, la configuración por defecto de BGP establece unos valores para sus timbres realmente conservadores:

• El “Keep Alive” es de 60 segundos es decir que para que un router se dé cuenta que su contraparte no es alcanzable puede tardar, en el peor de los casos, 59 segundos.
• En el momento en que el router no recibe el Keep Alive de su vecino comienza una cuenta atrás conocida como “Hold Time” que por defecto es de 180 segundos, vencido este times se considera al vecino como no alcanzable y se comienza con el proceso de convergencia del protocolo de enrutamiento.
• El tiempo de “Convergence” depende de muchos factores entre los que se encuentra la velocidad de la CPU del Router, el tamaño de las tablas, etc. pero puedo durar varios segundos en algunos casos.

Como podemos ver estos tiempos (casi 3 minutos) para que se vuelva a establecer un camino válido para las subredes anunciadas a día de hoy nos puede parecer una eternidad…y con razón. Por lo que se necesitan nuevas características para hacer de este proceso más ágil.

Es cierto que podemos reconfigurar los timers de BGP, pero esto no siempre es posible ya que las configuraciones se deben hacer de la misma manera en ambos extremos y no siempre los routers a enlazar se encuentran bajo nuestro dominio de gestión. Por otro lado, como mencione antes unos timers muy cortos pueden ser contraproducentes.

BFD al rescate

BFP o Bidirectional Forwarding Detection es un protocolo muy ligero diseñado para detectar rápidamente fallos en las conexiones entre dos dispositivos de red, como routers, switches o firewalls, independientemente de la capa de transporte o del protocolo de enrutamiento. Es particularmente útil en entornos de alta disponibilidad donde se requiere una detección de fallos muy rápida.

Su principal característica es una rápida detección de fallos ya que permite detectar fallos en milisegundos, lo que es significativamente más rápido que los temporizadores predeterminados de los protocolos de enrutamiento. Por otro lado hablándonoslas de los protocolos de enrutamiento BFD es independiente de estos ya que opera de manera genérica en la capa de red, por lo que puede integrarse con múltiples protocolos (BGP, OSPF, IS-IS, etc.) para informar rápidamente sobre fallos.

BFD en los VXC de los MCRs

Y cómo se implementa BFD en Megaport? Se implementa a nivel de VXC de nivel 3, es decir, los VXC utilizados para interconectar Routers, en este ejemplo el MCR y el Direct Connect Gateway de AWS.

Los requisitos previos para la implementación son realmente simples:

• Tienes una conexión activa entre tu MCR y el dispositivo remoto.
• BGP está configurado correctamente en el MCR.
• El dispositivo remoto también debe ser compatible y tener BFD habilitado.

Sobre el VXC que conecta nuestro MCR con el Cloud Service Provider hacemos click en el botón con forma de engranaje, e que permite ver y editar los detalles del VXC en cuestión.

En el apartado “A-End” podremos revisar la configuración de la sesiones BGP configuradas en el MCR para este VXC, podemos ver como el BFP se encuentra desactivado. Por defecto, al crear una nueva configuración de sesión BGP el BFD se encontrará desactivado para evitar configuraciones no coherentes por lo que su activación se debe hacer a mano.

Para activar el BFD debemos hacer click en el botón “Edit” sobre la sesión BGP que queremos que soporte BFD y se abrirá una ventana emergente donde dentro de la pestaña “Advanced” encontraremos una sección “BFP - Bidirectional Forwarding Detection” y deberemos hacer click en “On” dentro del apartado “Use BFD” para proceder a su activación. Para confirmar los cambios haremos click en el botón “Update”.

Inmediatamente podremos ver como ahora BFD se encuentra activo para esa sesión BGP sobre el VXC que interconecta el MCR con el Direct Connect Gateway de AWS.

Por último haremos click en el botón “Save” y luego “Close” para volver a la vista de servicios.

En el caso de AWS Direct Connect, Azure Express Route la activación de BFD es realmente ya que se encuentra activo por defecto en los Gateways por lo que para comenzar a utilizarlos solo es necesario activarlos desde Megaport y no es necesaria ninguna configuración extra sobre la consola del CSP.

Conclusión

Con el despliegue de MCR en diferentes PoPs dentro de una misma metro podemos tener una solución de Alta Disponibilidad en lo que a Routing se refiere sin penalizaciones en lo referente a latencias y gracias a poder implementar mecanismos como BFD sobre las sesiones BGP que se crean entre los MCRs y los Gateways de los Cloud Service Providers disponemos de unos tiempos de convergencia ante fallos por debajo del segundo haciendo la dupla MCR+BFD ideal para entornos productivos de nube hibrida o multicloud.

En el próximo artículo abordaré cómo podemos implementar la redundancia también en nuestra solución de NFV a la que llamamos MVE: Megaport Virtua Edge.

Hasta la próxima!!!