¿Cuál es el máximo de saltos que puede llevar un paquete?

Deseo discutir con Phillip Remaker,

Su afirmación “El valor predeterminado recomendado es 64, que sigue siendo alto” es simplemente inexacto en la medida en que cada proveedor de SO crea su propio valor predeterminado recomendado. El valor predeterminado en las versiones actuales de Windows 10 y Linux 2.4 son 128 y 255, respectivamente. De hecho, Red Hat tiene 64 años y el Mac OS actual es 64.

De hecho, como alguien que ha existido en el mundo de las rutas desde 1983, todos estos valores son algo tontos para mí.

Por ejemplo, la utilidad de red ICMP Traceroute permite solo 30 saltos. Sería una situación extremadamente extraña cuando el conteo de saltos caduque antes de que llegue al otro extremo. De hecho, desde que Border Gateway Protocol 4 se implementó en 1994 en los enrutadores Cisco, nunca ha sucedido … a menos que haya un problema de enrutamiento como un bucle o una delegación débil o “aleteo” en las tablas BGP4.

Los conmutadores LAN, a menos que funcionen como enrutadores, no agregan saltos. Los dispositivos de seguridad, como la familia de dispositivos ASA de Cisco, lo hacen, pero incluso entonces sería difícil crear un escenario en el que superaría los 40 saltos. De esa manera sospecho que Phillip Remaker y yo podríamos estar de acuerdo.

El valor de 255 como máximo permitido es un artefacto de matemáticas de base 8 y no un valor de ningún significado real en cuanto a necesidad.

De hecho, cuanto mayor sea el valor, más tiempo antes de que su paquete caduque cuando encuentre un bucle de enrutador en algún lugar de la red. Los bucles ocurren por una variedad de razones. Por lo tanto, aumentar el valor puede ralentizar las cosas en su escritorio.

El valor máximo del campo de tiempo de vida es 255, pero la distancia entre dispositivos de red tiende a ser mucho menor. El valor predeterminado recomendado es 64, que sigue siendo alto.

Si su red está diseñada tan mal que necesita más de 64 saltos, puede modificar el sistema operativo para usar un TTL más grande. Si el diseño de su red necesita 255 saltos, TTL será la menor de sus preocupaciones.

Si tiene un TTL de 64 y su destino está a 65 saltos de distancia, el dispositivo será inalcanzable a menos que cambie el TTL máximo en los sistemas operativos en ambos lados de la conexión.

En el caso extraordinario de TTL extremos, se puede establecer un proxy en el medio de la conexión, puede terminar una conexión e iniciar una nueva.

Una vez tuve un dispositivo que con un error que simultáneamente puenteaba y enrutaba el primer paquete de hack de vuelta al medio de transmisión. El TTL disminuyó obedientemente, pero cada paquete se duplicó, uno con un TTL reducido y otro con un TTL idéntico. El colapso del anillo FDDI resultante fue realmente entretenido de ver en el analizador.

Puede ir la cantidad de saltos que hay en el paquete cuando sale del host. Esto se define en gran medida por el sistema operativo en el host. Si el destino está en el salto N + 1 y su paquete tiene un TTL de N, entonces simplemente no va a llegar allí.

Originalmente, los sistemas generaban paquetes con un TTL de 16. Fueron bastantes años, pero comenzamos a recibir informes extraños que decían ~ No puedo llegar desde aquí, pero puedo desde este otro sistema ~. Entonces TTL realmente funciona.

Use traceroute / tracert en la línea de comando para otra demostración.

Depende de su definición de “lúpulo”.

Como explicaron los estimados Phillip Remaker y Tony Li, no se puede superar el TTL. Pero, ¿qué pasaría si hubiera una forma de atravesar los “saltos”, por algún valor de “saltos”, sin disminuir el TTL?

Cada red troncal principal utiliza MPLS ( https://en.m.wikipedia.org/wiki/ …) en sus núcleos hoy. Esto convierte a los enrutadores en “conmutadores”. Un poco

La parte importante es que un paquete que atraviesa un equipo puede o no tener su TTL disminuido dependiendo de si está siguiendo una ruta MPLS “etiqueta-conmutada” o una ruta “capa 3 enrutada”. En realidad, es posible que dos paquetes pasen por el mismo equipo yendo al mismo destino, y uno tiene su TTL disminuido, el otro no.

Por supuesto, si el TTL no se reduce, el “salto” no aparecerá en el rastro, etc.

Entonces, si cuenta los enrutadores que pasan paquetes sin modificación TTL y que no muestran “saltos” intraceroutes, entonces puede superar fácilmente 255.

Pero como dijo Philip, ¡no querrás hacerlo!

Todos los demás han respondido la pregunta, así que incluiré esta historia:

El caso del correo electrónico de 500 millas

de un caso en el que el envío de paquetes estaba sujeto a un tiempo de espera de retraso, no a un tiempo de espera de conteo de saltos, y no al tipo esperado de tiempo de espera de retraso.