Traceroute incluye IP no enrutable (?)

Ejecuté el siguiente traceroute una vez, mientras trataba de ignorar un problema de red.

c:\>tracert linode.com -d

Tracing route to linode.com [67.18.186.61]
over a maximum of 30 hops:

  1    <1 ms     *       <1 ms  10.43.51.252
  2     1 ms    <1 ms    <1 ms  10.45.253.33
  3    <1 ms    <1 ms    <1 ms  10.62.254.251
  4    20 ms    23 ms    45 ms  192.118.32.52
  5    47 ms    20 ms    85 ms  207.232.60.250
  6    54 ms    24 ms    79 ms  212.143.8.69
  7     7 ms    79 ms    11 ms  212.143.8.209
  8    89 ms   110 ms   108 ms  212.143.12.75
  9   143 ms   240 ms    94 ms  212.143.14.154
 10   244 ms   179 ms    95 ms  10.50.1.1
 11   176 ms    80 ms   190 ms  195.66.225.105
 12   174 ms   164 ms   157 ms  70.87.255.217
 13   187 ms   185 ms   186 ms  70.87.253.189
 14   189 ms   194 ms   195 ms  70.87.253.18
 15   187 ms   188 ms   190 ms  70.87.253.126
 16   187 ms   185 ms   185 ms  70.87.254.78
 17   186 ms   184 ms   187 ms  67.18.186.61

Trace complete.

Los primeros tres sitios son enrutadores / puertas de enlace locales; ignora esos.

Sin embargo, no estoy seguro de cómo el paso 10 podría darme 10.50.1.1 como objetivo. ¿No es una IP enrutable que no debería encontrarse en ningún lugar desde un enrutador público?

Las direcciones RFC1918 (10/8, 172.16 / 12 y 192.168 / 16) no deberían aparecer en las tablas de enrutamiento global, ya que están diseñadas para usarse dentro de "una sola empresa". Sin embargo, tiene sentido, hasta cierto punto, usar direcciones RFC1918 para sus enlaces punto a punto dentro de su núcleo, incluso si el tráfico que atraviesa esos enlaces es para rangos de direcciones IP "globalmente enrutables", ya que esto conserva un recurso ligeramente escaso .

La razón por la que aparece en la ruta de seguimiento es que el TTL de una trama IP expiró en una interfaz con esa como su IP de interfaz. La desventaja de hacer esto es que se hace más difícil hacer ping a la interfaz y resolver el problema, pero no hay garantía de que pueda hacerlo de todos modos.

Entonces, diría que puede ser un poco inusual, pero ciertamente no es inaudito.

Eso me parece extraño. Está perfectamente bien también ver IP privadas en el medio de una ruta, porque una sola organización puede usar una IP privada dentro de su red. Pero según whois, 212.143.14.154 y 195.66.225.105 son propiedad de dos organizaciones diferentes. Pero tal vez estas dos organizaciones tengan un punto a punto entre sí, en cuyo caso podrían usar una IP privada para ello.

El término no enrutable no es del todo exacto, ya que pueden enrutarse. Sin embargo, solo debe ser utilizado por una sola 'empresa', el término RFC1918 utiliza. Por eso me parece un poco extraño.

Lo vi en algunos enrutadores de enebro. Tenían asignadas las direcciones IP públicas adecuadas, pero el enrutador estaba enviando respuestas icmp con IP privada que estaba vinculada a la interfaz de administración (no accesible desde Internet pública).

Es posible que esté pasando a través de la red interna de alguien, a través de MPLS o algo similar, donde están usando IP internas.

Estoy de acuerdo con Cian. A veces, estos saltos WAN tienen una dirección IP privada de bucle invertido. Por alguna razón, esto se devuelve en el tracert. Un programa llamado Wireshark (realmente buen freeware) podría darle más información sobre su problema de red.

Manni