Traceroute salta en la misma subred

¿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 más o menos 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 Router2 hay 2 interfaces en la misma subred, ¿cuál no debería ser posible?

¿Qué tipo de configuración podría ser? Tal vez Frame Relay?

cada interfaz de 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 eso es cierto en los entornos SOHO y de mediana empresa comunes, no es el único modo posible de implementación disponible. Los ingenieros de red pueden tener razones para adoptar otro enfoque, o por suerte y cambio de configuración, pueden hacer que uno sea adoptado accidentalmente.

Hay varios escenarios en los que un enrutador puede recibir paquetes que posteriormente se enrutan a la misma red en la que se recibieron. 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 que se encuentran 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.xa 10.0.2.x tendrían que atravesar uno o más enrutadores, pero el enrutador lo sabe mejor. Este fenómeno de trombonización de red se 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.

Otra ocurrencia común ocurre cuando se ejecuta una ruta de seguimiento desde un dispositivo conectado a un concentrador VPN, que canaliza su tráfico a través de la VPN hacia el dispositivo remoto. Si suponemos que esta fue la causa de su salida de traceroute, el .14dispositivo probablemente sería 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 enrutarse hacia su destino. Esto no tiene nada de malo 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.

Traceroute funciona mediante el envío efectivo de un ping con un TTl (tiempo de vida) de 1. Golpea el primer enrutador que responde con un mensaje ICMP Time Exceeded. Repite esto, en su 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 hacia el 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 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