tcptraceroute: Hop no responde

tcptraceroute: Hop no responde

AFAIK tcptraceroutees la mejor herramienta para comprobar si un firewall está bloqueando la conexión TCP a un servicio. (Si conoce una herramienta mejor, deje un comentario)

Algunos saltos no responden. Ver* * *

remotehost:~ # tcptraceroute ftp.example.com ftp
Selected device eth0, address 10.172.19.11, port 40768 for outgoing packets
Tracing the path to ftp.example.com (10.101.7.124) on TCP port 21 (ftp), 30 hops max
 1  * * *
 2  172.18.56.12  0.407 ms  0.222 ms  0.230 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  10.102.1.1  32.017 ms  31.728 ms  31.486 ms
 8  * * *
 9  10.101.7.124 [open]  31.728 ms  32.391 ms  33.549 ms

Hay unatérminopor el comportamiento de estos lúpulos?

¿Cómo llamar a esto si el salto no responde y lo veo * * *en el resultado?

(Desafortunadamente no tengo 300 reputaciones y no puedo crear la nueva etiqueta "tcptraceroute")

Antecedentes: Me gustaría decirle a las personas responsables de la red, que deberían usar enrutadores que hagan AHORA-ESTOY-FALTANDO-EL-TERMINO-MAGICO.

Respuesta1

Realmente no existe una palabra exacta para eso, pero para ayudarlo en su diálogo con quienes administran esa red, puede consultar CoPP (Control Plane Policing).

Vale la pena señalar que es posible que el dispositivo no esté configurado para rechazar estos paquetes, puede que simplemente los esté limitando la velocidad, por lo que si desea respuestas, puede pedirles que excluyan ciertas IP del límite de velocidad o aumenten el límite para todo, si es así. deseado.

Le advertiré que puede resultarle difícil lograr que el equipo de red realice estos cambios, ya que están ahí para proteger el dispositivo de ataques DoS o sobrecargas de uso normal en el plano de control.

Dedocumentos de Cisco, a continuación se detallan algunos de los efectos que se pueden ver si el plano de control está sobrecargado:

  • Reducción de la calidad del servicio (como tráfico deficiente de voz, vídeo o aplicaciones críticas)
  • Alta utilización de CPU del procesador de ruta o del procesador de conmutación
  • Flaps de ruta debido a la pérdida de actualizaciones del protocolo de enrutamiento o keepalive
  • Topología inestable de capa 2
  • Sesiones interactivas lentas o que no responden con la CLI
  • Agotamiento de los recursos del procesador, como la memoria y los buffers.
  • Caídas indiscriminadas de paquetes entrantes

Respuesta2

Como ya se indicó en los comentarios, no hay una respuesta real para esto (por lo que me siento un poco tonto por escribir esto, pero sería demasiado largo para un comentario). Lo que estás viendo es simplemente tcptraceroutedecir que no obtuvo respuesta del salto. No existe un término para esto, es simplemente la forma en que se diseñó traceroute. Cuando el salto no responde a la solicitud ICMP, se obtiene una *respuesta, lo que significa que no se devolvió nada, por lo que no se pudo determinar una respuesta en forma de tiempo de respuesta de ping.

Entonces, para llegar a tus antecedentes:

Me gustaría decirle a las personas responsables de la red que deberían usar enrutadores que cumplan AHORA-ESTOY-FALTANDO-EL-TERMINO-MAGICO.

Simplemente dígales que deben hacer que sus enrutadores bloqueen las solicitudes ICMP y listo, entenderán lo que quiere decir con solo unas pocas palabras. También porque no es tanto una característica, sino una configuración. Por lo tanto, no "usa enrutadores que bloquean las solicitudes ICMP", les indica que lo hagan (puede que sea la configuración predeterminada, pero de todos modos es una configuración). Los responsables de la red deberían saberlo.

información relacionada