Traceroute, y su hermano pequeño, ping, es una de las herramientas más utilizadas en la red. la solución de problemasAunque esta herramienta es muy útil, existen algunos desafíos críticos al usarla para abordar los problemas mucho más complejos de la actualidad. Recuerde que traceroute se creó a finales de la década de 1980, cuando las redes eran mucho más simples.
Todo era físico, el punto a punto estaba de moda y había menos protocolos con los que lidiar. Los switches se conocían comúnmente como puentes, con enrutadores LAN a WAN que conectaban edificios. (¡Recuerden, esto fue seis años antes de que existiera Internet!). ¿Y quién recuerda las "líneas T1 arrendadas"? De los buenos tiempos, por así decirlo.
Entonces, ¿cómo se mantienen herramientas antiguas como esta en el mundo virtualizado y definido por software actual? Seguramente debe haber una forma más moderna de ayudar a solucionar problemas en las redes actuales. Sí, la hay, así que siga leyendo.
Para comenzar, aprendamos más sobre el comando traceroute. Luego, analizaremos sus errores, limitaciones y más.
La máquina de origen (SRC) suele enviar tres paquetes de sondeo a la dirección IP de destino, comenzando con un tiempo de vida (TTL) establecido en 1. Se suele pensar erróneamente que el tipo de paquete de sondeo siempre es ICMP. En realidad, depende del dispositivo que origina el traceroute. Los sistemas operativos Windows suelen usar ICMP, mientras que Unix y los dispositivos de enrutamiento suelen usar mensajes UDP a puertos efímeros (puertos mayores de 1024 que no son servicios conocidos como DNS, SMTP, WEB, etc.).
A medida que cada dispositivo de Capa 3 recibe el paquete de sonda, disminuye el TTL. Cuando el TTL llega a 0, el dispositivo receptor envía un mensaje ICMP desde la interfaz receptora: "TTL expirado". Así es como traceroute conoce cada salto del camino.
En la imagen a continuación, 172.16.2.1 y 10.3.2.2 serían las direcciones devueltas en los resultados de traceroute.
El valor predeterminado de un traceroute es informar la ruta entre los puntos A y B. La ruta opuesta requiere un segundo traceroute. Analicemos por qué esto puede ser una limitación.
El enrutamiento asimétrico es común en las redes modernas. Aquí intervienen numerosos protocolos de enrutamiento, entre ellos:
Dependiendo del algoritmo utilizado para el hash, es probable que el tráfico siga una ruta diferente en cada dirección. Estas rutas diferentes son difíciles de detectar con una sola ejecución del comando traceroute. Por lo tanto, es difícil determinar el origen del retraso.
Como se puede ver arriba, el valor del retraso aumenta significativamente en este salto en particular. ¿Dónde está el retraso? ¿En la ruta de ida o de vuelta?
Si volvemos a mirar el traceroute anterior, la única información proporcionada es:
Para investigar el salto seis, necesitaríamos establecer una conexión Telnet o SSH con el enrutador y determinar qué interfaz está conectada a esta dirección IP en particular. Mi método favorito era "Mostrar ruta IP 129.259.2.41". Sin embargo, se podría mostrar la interfaz IP y canalizar la salida a un... parser…“Mostrar resumen de interfaz IP | en 129.150.2.41”. Necesitaría una búsqueda posterior para identificar la interfaz de salida. Por ejemplo, “mostrar ruta IP 192.41.37.40”.
Los mensajes ICMP a veces informan un retraso más significativo que el experimentado por el tráfico, principalmente porque utiliza un procesamiento de ruta lenta en lugar de una ruta rápida.
¿Qué es una ruta lenta? Es cuando el enrutador necesita procesar el contenido del paquete. Prácticamente cualquier paquete destinado a un dispositivo se gestiona de esta manera. Los mecanismos internos de los enrutadores más nuevos priorizan los paquetes que procesan.
Primero procesan las actualizaciones del protocolo de enrutamiento y luego los mensajes ICMP, lo que agrava el problema. Muchos sistemas utilizan mensajes UDP. Sin embargo, generar el mensaje ICMP TTL expirado tiene menor prioridad. En ese caso, la ruta de retorno será un mensaje ICMP. Por lo tanto, las métricas de retardo proporcionadas en los resultados son difíciles de aceptar como problemas reales.
CONSEJO: Cuando un traceroute salta en un paso específico y los resultados subsiguientes son bajos, suele indicar que el enrutador "lento" experimenta un retraso en el procesamiento. Si la ruta salta y los pasos subsiguientes se incrementan, esto suele indicar algún tipo de cola debido a la congestión.
Ahora conocemos la ruta hacia un destino específico, pero ¿qué pasa si queremos investigar más a fondo los saltos adicionales a lo largo de la ruta? Si un usuario usa la consola Telnet o SSH, deberá iniciar sesión en cada dispositivo. La respuesta de traceroute solo proporciona la dirección IP de la interfaz. En muchas redes, esto presenta dificultades.
Las políticas de seguridad requieren que los usuarios usen Telnet o SSH para acceder a la dirección IP de administración. Las interfaces específicas reportadas en el traceroute podrían bloquear Telnet, lo que requeriría una búsqueda manual para determinar la interfaz de administración del dispositivo con esa dirección. Si no puede usar la resolución DNS, esto podría ser prácticamente imposible. En caso de interrupción, cada segundo puede jugar en su contra.
Como se mencionó anteriormente, las rutas multitrayecto con costo igual o desigual son comunes en la mayoría de las redes actuales. Traceroute solo informa sobre la ruta específica que formó parte de los mensajes de sondeo de consulta. Las implementaciones más comunes de traceroute envían tres paquetes de sondeo con diferentes puertos de destino UDP. Por lo tanto, es posible que, en un entorno ECMP, cada salto tenga hasta tres direcciones IP diferentes informadas. Registrar qué respuesta forma parte de qué ruta puede resultar engorroso.
Como ya sabemos, traceroute reduce el valor TTL en un paquete IP y genera mensajes ICMP con TTL vencido. Solo los dispositivos de capa 3 reducen el TTL. Por lo tanto, no hay visibilidad integrada ni una función para determinar fácilmente la ruta de capa 2 tomada a partir del resultado. La mayoría de los entornos empresariales y de centros de datos cuentan con un conmutador de acceso de capa 2 para la agregación de estaciones finales.
Algunos diseños incluyen una capa de distribución de Capa 2 antes de llegar a un enrutador central. El enrutador realiza la primera función de enrutamiento de Capa 3, que puede reportar una solicitud de traceroute.
Si se presenta pérdida de paquetes en la salida de traceroute, podría deberse a:
Solo se pueden detectar algunos problemas inspeccionando los elementos de la Capa 2 a lo largo de la ruta. Para encontrar esta información se requiere:
Este proceso puede llevar mucho tiempo, especialmente si CDP/LLDP no está habilitado en la red o la documentación no está actualizada.
Los resultados que se ven con un traceroute corresponden al estado actual. No es posible determinar qué ruta se utilizó cuando el tráfico tuvo éxito (por ejemplo, ayer). Considere el traceroute a continuación. Sería útil comprender qué era el salto cuatro antes de que las cosas cambiaran para ayudar a identificar el posible problema.
Nota: Según nuestra experiencia, basándose en el resultado del comando traceroute anterior, los ingenieros asumirán que el salto tres es el problema. Esto no suele ser así. El usuario debe iniciar sesión primero en el dispositivo en el salto tres y comprobar si tiene una entrada de enrutamiento al destino. De ser así, el dispositivo con problemas suele ser el siguiente salto en la entrada de enrutamiento. Para ser exhaustivos, es útil comprobar la interfaz de salida hacia el siguiente salto de enrutamiento para verificar el rendimiento a nivel de interfaz y la configuración de la ACL.
Cuando me encuentro con un problema con el comando traceroute, de vez en cuando, aparece un carácter en la salida que me sorprende. La tabla a continuación proviene de la implementación de traceroute de Cisco. Una de las limitaciones de traceroute es que puede parecer sencillo, pero comprender lo que sucede generalmente requiere investigación adicional.
Por ejemplo, supongamos que recibo la letra A en la respuesta de traceroute. Entiendo que una lista de acceso está bloqueando el traceroute, pero ¿cuál es? Para determinarlo, necesito:
Este proceso puede ser largo, y siempre nos preocupa el tiempo que lleva solucionar problemas. Por lo tanto, sería invaluable contar con una mejor manera de acceder a esta información.
NOTA: Según nuestra experiencia, estos mensajes de error de traceroute solo se proporcionan según la interfaz de entrada. Una vez que se recibe un paquete y se reenvía al siguiente salto de la ruta, si hay una ACL en el puerto de salida, simplemente se obtiene un *** para el siguiente salto. Esto implica tomar medidas adicionales para garantizar que se conozca la interfaz de salida y que también se validen las ACL en ese puerto.
NetBrain Incluye numerosas funciones de automatización y visualización necesarias para el mantenimiento de redes modernas. Comprende redes definidas por software, virtualizadas e incluso en la nube. Se comunica continuamente con todos los dispositivos de la red de extremo a extremo y crea un gemelo digital de la red en tiempo real, que es una réplica exacta de los detalles de cada dispositivo.
Puede visualizar redes en tiempo real e incluye un reemplazo moderno para traceroute, el Calculadora de rutas A/BEsta herramienta ayuda a los ingenieros a trabajar dinámicamente. mapear una ruta de red detallada entre dos puntos cualesquiera de la red.
Admite mapeo a través de capas subyacentes, superposiciones y tecnologías modernas, que incluyen:
Simultáneamente, considera protocolos avanzados como:
Una vez implementada, la estructura visualizada es la plataforma perfecta para automatización sin código de cada tarea, grande y pequeña!
Permita que sus equipos solucionen problemas y diagnostiquen el rendimiento de las aplicaciones a nivel de flujo de tráfico con NetBrain, Garantía de aplicación (AAM). Eso:
Evite la degradación del rendimiento de las aplicaciones con NetBrainAutomatización basada en intenciones y sin código. NetBrain AAM protege la experiencia del usuario al: