¿En qué caso hay dos saltos vecinos en la misma subred en una salida de traceroute? Como sé, ¿deberían ser solo direcciones de origen y cada interfaz de enrutador debería estar en una subred diferente?
P.ej:
1 * * * Request timed out.
2 2 ms 3 ms <3 ms 10.10.0.14
3 5 ms 4 ms 3 ms 10.10.0.15
4 21 ms 22 ms 25 ms 194.221.100.49
Debería verse así.
(PC) 192.168.1.2 --- 192.168.1.1 (Router1) 10.10.0.X --- 10.10.0.14 (Router2) 10.10.0.x --- 10.10.0.15 (Router3) 192.221.100.X --- 192.221.100.49 (Router4) X.X.X.X
Pero en el Router2 hay 2 interfaces en la misma subred, ¿lo cual no debería ser posible?
¿Qué tipo de configuración podría ser? ¿Quizás Frame Relay?
Respuesta1
¿Cada interfaz del enrutador debe estar en una subred diferente?
El error en su lógica radica en la suposición de que las topologías de red siempre involucran enrutadores que pasan estrictamente los paquetes recibidos en una interfaz en una subred a través de una interfaz definida en una subred diferente. Si bien esto es cierto en entornos SOHO y de mediana empresa comunes, no es el caso.soloposible modo de implementación disponible. Los ingenieros de redes pueden tener motivos para adoptar otro enfoque o, por suerte y cambios en la configuración, pueden provocar que se adopte uno accidentalmente.
Hay varios escenarios en los que un enrutador puede recibir paquetes que posteriormente se enrutan de regreso a la misma red en la que fueron recibidos. Importa cómo y con referencia a qué dispositivo definimos nuestras subredes. Por ejemplo, es completamente legal que un enrutador tenga una interfaz de 10.0.0.1/16, mientras que los dispositivos detrás de él usan direcciones en la subred 10.0.x.y/24. Desde la perspectiva del dispositivo, los paquetes de 10.0.1.x a 10.0.2.x necesitarían atravesar uno o más enrutadores, pero el enrutador lo sabe mejor. Este fenómeno detrombón de redSe encuentra comúnmente en el núcleo de las redes empresariales. Si bien no es necesariamente eficiente, funciona y el enrutador está haciendo su trabajo correctamente.
Otro hecho común ocurre cuando se ejecuta un traceroute desde un dispositivo conectado a un concentrador VPN, que canaliza su tráfico a través de la VPN hasta el dispositivo remoto. Si suponemos que esta fue la causa de la salida de traceroute, el .14dispositivo probablemente sea el concentrador conectado a la LAN corporativa en el extremo remoto. El .15dispositivo es el enrutador de la red a la que está conectado el concentrador. Los paquetes se reciben (tunelizados) en la .14interfaz y se devuelven a la misma interfaz para ser enrutados a su destino. No hay nada de malo en esto y traceroutele muestra legítimamente las identidades de todos los dispositivos responsables de tocar los paquetes en la capa IP.
Sin un conocimiento más preciso de la topología de la red y, en particular, de la configuración de los enrutadores intermedios, es imposible comprender con precisión lo que ocurre en su caso.
Respuesta2
Traceroute funciona enviando efectivamente un ping con un TTl (tiempo de vida) de 1. Llega al primer enrutador que responde con un mensaje ICMP de tiempo excedido. Esto lo repite, en tu caso un total de 3 veces.
Luego envía 3 pings con un TTL de 2, luego 3, etc. Muestra la respuesta de cada enrutador como una ruta al host.
https://en.wikipedia.org/wiki/Traceroute
Mi primera suposición es que si su sistema está configurado correctamente, entonces su primer enrutador (que está configurado para no enviar el mensaje de tiempo excedido) tiene una ruta predeterminada a 10.10.0.14 que tiene una ruta estática declarada a la subred 194.221.100.49.