Bienvenido a La tormenta perfecta!
En esta serie, veremos la No tan obvio escenarios donde sucedió la combinación "correcta" de cosas "incorrectas" y el resultado produce una pérdida de accesibilidad, conectividad, etc. Después de discutir la falla, regresaremos y determinaremos qué sucedió (¿Por qué falló?). También veremos cómo se pudo haber evitado o minimizado la falla usando NetBrain.
¡¡Empecemos!!
En este escenario, encontramos que una sección de la red no puede comunicarse con un recurso basado en la nube durante las pruebas de aceptación.
Este es el entorno de red con el que estamos trabajando:
Figura 1: Conectividad del centro de datos a la nube de AWS
RT1 y RT2 cada uno se empareja en un entorno de AWS a través de BGP, y cada uno tiene un diferente Físico ruta a AWS. Estos dos enrutadores tienen una relación iBGP entre sí a través de la red 172.16.110.0. Además, RT1 y RT2 ejecutan OSPF en dos redes separadas: la red 172.16.110.0 y la red 10.70.28.0. El tráfico en la red 10.70.28.0 (desde RT1 y RT2) pasa a través de un firewall para llegar a un tercer vecino OSPF, RT3, que maneja el enrutamiento/tráfico de capa 3 para las subredes del centro de datos.
Durante las últimas dos tardes a las 11 p. m., una estación de administración de red en la red 10.17.1.0 ejecuta pruebas de rendimiento en un host de AWS en la red 10.192.16.0. Las pruebas normalmente tardan entre 10 y 15 minutos en completarse. En la tercera y última noche de pruebas, las pruebas se retrasan hasta las 2 a. m., en medio de la ventana de mantenimiento del proveedor de AWS Circuit (donde se realiza el mantenimiento en Ruta física A). Aunque no se informaron problemas relacionados con la conectividad de ninguno de los hosts en el centro de datos, las pruebas de rendimiento ejecutadas desde la estación de administración de red fallaron. ¿Por qué falló?
METODOLOGÍA DE RESOLUCIÓN DE PROBLEMAS
Echemos un vistazo más de cerca al medio ambiente, veamos qué cambió y determinemos cómo esos cambios influyeron en el medio ambiente. Entonces, ¿qué pasó en la primera y segunda noche de prueba? Vamos a ver:
¡¡AHORA, mira específicamente lo que pasó en la Tercera Noche!! Primero, podemos comenzar identificando lo que sabemos: la conexión principal del ISP fue eliminada.
Figura 2: Mostrar el problema, es decir, desconectar la conexión principal del ISP
A continuación, hablemos de cómo la interrupción del circuito afectó las tablas de enrutamiento... específicamente en RT1. Antes de la ventana de mantenimiento del ISP, RT1 tenía una ruta eBGP en su tabla desde el par eBGP de la VPC F.
RT1#ruta de envío 10.192.16.0
Entrada de enrutamiento para 10.192.16.0/24
Conocido a través de "bgp 65535", distancia 20, métrica 0
Etiqueta 7224, tipo externo
Redistribución a través de ospf 1
Anunciado por ospf 1 mapa de ruta de subredes DENY-SUMM
Última actualización de 192.168.8.6 00:04:10 hace
Bloques de descriptores de enrutamiento:
* 192.168.8.6, desde 192.168.8.6, 00:04:10 hace
La métrica de ruta es 0, el recuento de tráfico compartido es 1
AS Lúpulo 1
Etiqueta de ruta 7224
Etiqueta MPLS: ninguna
RT1 #
Sin embargo, después de la interrupción del circuito, la tabla de enrutamiento de RT1 se ve muy diferente. La tabla RT1 ahora tiene two entradas para la red 10.192.16.0, una hacia RT2 en su interfaz GigabitEthernet 0/3 y otra hacia RT2 en su interfaz GigabitEthernet 0/1.
RT1#ruta de envío 10.192.16.0
Entrada de enrutamiento para 10.192.16.0/24
Conocido a través de "ospf 1", distancia 110, métrica 400
Etiqueta 7224, tipo externo 2, métrica directa 1
Redistribuyendo a través de bgp 65535
Última actualización de 10.170.28.12 en GigabitEthernet0/1, hace 00:00:37
Bloques de descriptores de enrutamiento:
* 172.16.110.12, desde 10.70.28.12, 00:00:41, a través de GigabitEthernet0/3
La métrica de ruta es 400, el recuento de tráfico compartido es 1
Etiqueta de ruta 7224
10.70.28.12, desde 10.70.28.12, hace 00:00:37, a través de GigabitEthernet0/1
La métrica de ruta es 400, el recuento de tráfico compartido es 1
Etiqueta de ruta 7224
VIRL-PHX-AWS-RT1#
Pero, ¿cómo podría esto causar una falla? como seria un extra IMPORTANTE ruta causa que falle la conexión de la estación de administración a la VPC F? Para comprender esto, observe cómo fluye el tráfico entre la VPC F y la subred de administración. El tráfico entrante fluye desde la VPC F hacia R2 (la única ruta disponible) y luego hacia la subred de administración.
Figura 3: Comprensión de los flujos de tráfico entrante
El tráfico saliente toma una ruta diferente. Esta ruta de salida la dicta inicialmente el miembro activo de HSRP para la subred 10.17.1.0. Todavía está configurado en RT1. Aunque el tráfico ahora fluye hacia el exterior a través de RT2, RT1 sigue siendo el enrutador activo (puerta de enlace predeterminada) para la subred 10.17.1.0. Con esto en mente, siga el flujo de salida a continuación:
Figura 4: Comprensión de los flujos de tráfico saliente
Podemos ver la primera ruta que va a la puerta de enlace predeterminada (representada por RT1), pero hay dos saltos iguales representado en el segundo camino! Uno a RT2 a través de la red 172.16.110.0 y otro a RT2 a través de la red 10.70.28.0. Con dos rutas Layer3 iguales a RT2 disponible, RT1 equilibrará la carga y enviará parte del tráfico a través de la ruta del Firewall (2B). El cortafuegos verá una conversación incompleta y llamará "Enrutamiento asimétrico" y lo romperá.
ANÁLISIS DE RAÍZ DE LA CAUSA
Ahora que tenemos una mejor comprensión de lo que sucedió, puede ser un buen momento para preguntarse: “¿Cómo pude haberlo visto venir??” ¿Qué preguntas debo hacerme para prepararme mejor para situaciones como esta y qué herramientas proporcionarán una mayor visibilidad de mi infraestructura de red subyacente/superpuesta? ¿Cómo me convierto en un mejor?solucionador de problemas de red” y no solo un “tirador”?
En el ejemplo anterior, el problema se identificó cuando mapeamos el traffic path. A continuación usé NetBrain para representar gráficamente un traffic path preguntando a los enrutadores cómo llegar desde la fuente (en este caso, usé RT1…) al destino:
Figura 5: Crear el traffic path usando NetBrain
A continuación, NetBrain nos presenta los datos reales previos y posteriores al mantenimiento de las tablas de enrutamiento de RT1, que representan los datos reales de "toma de decisiones" para el traffic paths que vimos arriba.
Figura 6: La tabla de enrutamiento del enrutador 1 utilizada para determinar el traffic paths
Y finalmente, vemos (usando NetBrain para comparar los estados de vecino BGP antes y después del mantenimiento de RT1) BGP un estado de igual que es la raíz de todos los eventos en este escenario... Inactivo (o cualquier otro estado no establecido) frente a estados establecidos entre vecinos BGP de RT1.
Figura 7: Comparación de las configuraciones "antes" y "después"
Gracias a NetBrain Junto con VIRL en paquete es una combinación imbatible para simular y monitorear/registrar el rendimiento y las características de la red en tiempo real, utilizando construcciones reales "similares a la producción", de una manera que se puede documentar y transferir fácilmente (configuraciones, monitoreo, etc.) a un entorno de producción.
Para obtener más información sobre NetBrain, visita https://www.netbraintech.com/plataforma/