traceroute: a veces los enrutadores no responden y el usuario ve tiempos de espera

Question

Soy administrador de una red pequeña y estoy investigando un problema del que se quejan mis usuarios. La raíz de sus quejas es traceroute: a veces los enrutadores a lo largo del camino simplemente no responden a traceroutelas sondas y los usuarios ven tiempos de espera (esos *mensajes en lugar de RTT).

La red consta de algunos enrutadores Linux conectados por Ethernet/inalámbrico. Enrutadores Linux 99 % inactivos, utilización del enlace 20 mbit/s, 2000 paquetes/s. La conexión inalámbrica es sólida como una roca. El PING a todos los enrutadores a lo largo de la ruta es de 10 ms, con algunas variaciones, por supuesto. El PING inundado a cualquiera de esos hosts se ejecuta durante minutos sin pérdida de paquetes (y me refiero a 0 paquetes perdidos). Descarga de algunos archivos enormes a través de la red: 10,2 MB/s de media.

El ejemplocorrecto tracerouteSe ve como esto:

# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.919 ms  3.866 ms  4.117 ms
 2  10.41.13.1  4.149 ms  6.714 ms  6.707 ms
 3  10.41.1.11  8.475 ms  8.468 ms  8.705 ms
 4  10.0.0.2  8.697 ms  9.428 ms  9.707 ms

Elproblemático traceroutese ve así:

# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.190 ms  3.140 ms  3.128 ms
 2  10.41.13.1  3.119 ms  3.113 ms *
 3  10.41.1.11  3.697 ms *  3.683 ms
 4  10.0.0.2  4.531 ms  4.524 ms  5.171 ms
# traceroute -nI 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  192.168.0.1  3.471 ms  3.405 ms  3.388 ms
 2  10.41.13.1  3.372 ms  3.359 ms  3.350 ms
 3  10.41.1.11  5.039 ms * *
 4  10.0.0.2  5.105 ms  5.484 ms  5.473 ms

Investigué un poco tcpdumpy descubrí que traceroutefunciona así:

1. Al principio envía un montón de solicitudes ICMP con TTL de 1, 2, 3, 4, 5, 6. Cada TTL se envía 3 veces. Son 18 paquetes :)
2. Espera algún tiempo por todas las respuestas ( Time Exceeded).
3. Cuando regresen todas las respuestas, muestre los resultados.
4. ..o espere el tiempo de espera y muestre los resultados con respuestas faltantes marcadas con asteriscos.

Y la causa de los tiempos de espera es que los enrutadores reciben las 3 solicitudes respectivas pero a veces no responden, no envían el tiempo ICMP excedido.

Sospecho que hay algunas configuraciones que configuran este comportamiento en el enrutador. A sabericmp_ratelimit,máscara_icmp_rate,icmp_msgs_per_secyicmp_msgs_burst. Todo descrito de alguna maneraen documentos de kernel.org. Y aquí está el punto en el que fallé. No vine con ningún valor de esas variables para que el traceroutetrabajo funcione todo el tiempo.

Intenté configurar esto en todos los enrutadores:

• icmp_ratelimitestablecido en 0(no limitar nada)
• icmp_msgs_per_secestablecido en 10000(debe ser lo suficientemente alto)
• icmp_msgs_burstestablecido en 5000(alta altura)

No me ayudó, veo el mismo comportamiento, tiempos de espera aleatorios. No me metí con icmp_ratemask, porque no entiendo completamente cómo excluir Time Exceededde la limitación.

Finalmente, preguntas:

1. Si estás familiarizado con este tipo de tracerouteproblemas, ¿cómo lo resolviste?
2. Si está familiarizado con las configuraciones del kernel mencionadas anteriormente, ¿cuáles son los valores "suficientemente buenos"?
3. ¿Cuál es la forma correcta de modificar icmp_ratemaskpara no limitar Time Exceededlos mensajes y que traceroutefuncionen sin fallas?
4. Y además, ¿existen violaciones de seguridad al cambiar esta configuración (o alguna relacionada)? No quiero que me hagan DoS ni ser una fuente de ataque DDoS para nadie.

Answer 1

Como parte de las políticas del plano de control sobre saltos, las sondas ICMP en su mayoría se ignoran. Sugeriría una instancia dedicada al tabaquismo local si desea tener datos históricos más completos, en términos de métricas y tendencias.