- Este debate tiene 31 respuestas, 14 mensajes y ha sido actualizado por última vez el hace 2 años, 4 meses por
.
-
Entradas
-
Hola.
Me surgen dos dudas al respecto:
1. Si la capa IP no fragmenta los paquetes ya que comentas que es «muy raro» que en la vida real nos encontremos con paquetes mayores a 1500 y que en tal caso estos se deberian fragmentar (cosa que no es recomendable)
¿Quien es el encargado entonces de no generar paquetes (headers+datos) mayores de 1500? ¿la aplicación?2.Referente a la imagen de wireshark que has mostrado con el ejemplo de la canción, en la columna ‘length’ aparece el valor 1514. ¿Que es este valor?
Ademas, queria aprovechar este mensaje para felicitarte Alvaro por el gran trabajo realizado, ya que, tu forma de explicar es excelente.
Muchas gracias.Hola José y bienvenido al foro!
En realidad TCP es el que va armando los segmentos de red con la cantidad de datos necesaria para no sobrepasar el MTU de la interface a través de la cual tienen que atravesar los datos; cuando se trabaja con TCP, existe un buffer donde la aplicación va introduciendo los datos, TCP se va a ese buffer y de ahí obtiene la cantidad necesaria para la construcción de 1 segmento.
El MTU lo conforman los datos de aplicación, el header de la capa transporte y el header de la capa de red. Más adelante aprendes un poco más sobre el MTU, la cuestión es que todas las interfaces de red tienen un límite (MTU) sobre la cantidad máxima de datos que pueden ser enviados en las tramas, esto se calcula en base a la mejor eficiencia de transmisión… en Ethernet este límite es de 1500 bytes, entonces las aplicaciones van colocando sus datos a un buffer, TCP se va ese buffer y va crear un segmento que tenga un tamaño no mayor al MSS (Tamaño máximo del segmento), cuando se utiliza Ethernet, este MSS es igual a 1460 bytes, el tamaño de 1460 bytes garantiza que no se sobrepase el valor del MTU de 1500 bytes…esto debido a que 1460 bytes más 20 bytes del header TCP, más 20 bytes del header IP dan como resultado los 1500 bytes de MTU.
Respecto a tu segunda consulta, el valor de 1514 bytes hace referencia al tamaño de la trama Ethernet, 1500 bytes de MTU +14 bytes del header Ethernet, esos 14 bytes consisten en 6 bytes de dirección MAC de origen, 6 bytes de dirección MAC de destino, y 2 bytes del campo «type», recuerda que en el MTU no se toma en cuenta esos bytes extras del header de la trama Ethernet, por lo tanto no se está incumpliendo ninguna regla. En el módulo 2 aprendes sobre la estructura de la trama Ethernet.
Te dejo un enlace del blog donde hablamos un poco más de la fragmentación y el MSS: https://netwgeeks.com/fragmentacion-ipv4/ y https://netwgeeks.com/opciones-tcp-tamano-maximo-del-segmento-mss/
Espero que queden claras tus consultas.
Estoy atento a cualquier otro comentario, y muchas gracias por tu felicitación! =D
Saludos cordiales!
Me ha quedado muy claro con tu explicación.
Me gustaria hacerte una consulta más, (solamente por curiosidad).
Suelo trabajar con equipos Mikrotik en los cuales levantamos tuneles Gre y eoip. Estos tuneles llevan una opción por defecto para habilitar el ‘Clamp TCP MSS’. ¿Que es exactamente eso y que es lo que hace? Por defecto viene marcada pero no se exactamente que es. He buscado algo de info al respecto pero no me queda muy claro.Muchas gracias.
Hola José
Esto lo vemos en curso CCNP ENCOR, pero de manera resumida, lo que ocurre cuando trabajas con túneles GRE/IPSEC/PPPOE entre otros, es que se añaden headers extras de estos protocolos a los datos que generan tus computadoras… por lo tanto cuando tus paquetes salgan por tu router, generaras paquetes más grandes que el MTU de sus interfaces; tu computadora generara 1500 bytes + los bytes extras de estas tecnologías darán como resultado más de 1500 bytes y por ende siempre fragmentaras tus paquetes haciendo tu comunicación ineficiente. TCP Clamping en tus routers lo que hace es que intercepta el establecimiento de sesión TCP, y básicamente les dicen a los dispositivos de origen y destino que realicen la creación de segmentos que no sobrepasen un determinado valor que tu configuras. En Cisco esto se logra con el comando ip tcp adjust-mss, y nosotros tenemos que proporcionar un valor de tamaño del segmento que sumado a los headers extras de TCP e IP, no superen el MTU de la tecnología que utiliza el router.
Por ejemplo, cuando configuras GRE en EL ROUTER, automáticamente el MTU de la interface túnel se reduce a 1476 para que se puedan añadir sin problemas los 24 bytes extras del header GRE dando como resultado los 1500 bytes que salen por tus interfaces físicas Ethernet del router. El problema es que tus host no saben de este cambio, y por ende seguirán enviando paquetes de 1500 bytes; como el MTU de GRE en el router es de 1476 y tus hosts envían 1500 bytes, de todas formas se van a fragmentar los paquetes. Por lo tanto nosotros tendríamos que configurar TCP Clamping en el router con un valor de 1436 bytes; esto significa que cuando tu PC envíe un establecimiento de sesión, ese paquete llega al router, y el router modifica esa sesión TCP e indica que el segmento no debe sobrepasar los 1436 bytes para que no se sobrepase el MTU de 1476 bytes de GRE… el paquete modificado llega al destino… y el destino ya sabe que no debe crear segmentos TCP que sean mayores a 1436. Cuando se envíe el segmento de 1436 bytes, se añaden 20 bytes de TCP y 20 bytes de IP dando como resultado los 1476 bytes de MTU de GRE. Si a esto le sumas tus 24 bytes de GRE, dan como resultado los 1500 bytes que tiene que tener una trama que utiliza una interface física Ethernet por defecto.
En síntesis esa tecnología busca que tus computadoras no generen segmentos TCP que provoquen fragmentación afectando a tu comunicación.
Espero que haya quedado clara la explicación.
Atentos a cualquier otra consulta.
Saludos cordiales.
Hola Jose! =)
Es correcto, TCP Clamping es uno de los mecanismos que trata de evitar la fragmentación, si configuras un valor correcto del tamaño de segmento efectivamente se EVITARA la fragmentación, pero si configuras un valor incorrecto de tamaño del segmento no podrás evitar nada. Se debe analizar los tamaños de los paquetes que viajan de principio a fin en la comunicación de tus hosts y las tecnologías de túneles e interfaces empleadas para que efectivamente configures un valor correcto de MSS/MTU.
Existe otra tecnología que también conjuntamente con TCP Clamping tratan de evitar la fragmentación y se denomina Path MTU Discovery.
Atento a cualquier otra consulta que puedas tener.
Saludos cordiales.
Buenas noches Álvaro, espero te encuentres bien y muy agradecido por todo el contenido, de verdad esta muy bien explicado. En esta ocasión tengo una duda con respecto al time to live (TTL), este valor se empieza a reducir (partiendo desde 255), al momento que sale del dispositivo emisor? Mas especifica mi pregunta, en la topología que colocas al momento de explicar este valor del header TCP lo realizas colocando una PC como emisor y 3 routers antes de llegar al destino, ese valor de 255 se empieza a reducir desde el momento que parte de la PC? O sea, desde el primer router? sin haber llegado al LOOP?, Saludos y espero puedas comprender mi pregunta, ya que en ese punto de la clase tuve dudas. Gracias de antemano.
Hola Jesus, a pesar que el máximo valor que podamos tener es de 255, en la realidad el valor que tengas en el campo TTL depende del sistema operativo de donde origines el paquete; en Windows por ejemplo generalmente tenemos un valor de TTL de 128, esto significa que tu paquete sale de tu dispositivo con un valor de 128, cuando atraviese tu primer router se reduce a 127 y así sucesivamente. En Linux por ejemplo este valor es de 64, y cuando llegue al primer router, se reduce a 63 y así sucesivamente. En el ejemplo efectivamente hacemos parecer como que se comienza a reducir ese valor al encontrar el loop, sin embargo esto no es así, no necesitas experimentar un loop para que ese valor se vaya reduciendo, se reduce apenas te pillas al primer router en tu red.
Atento a cualquier otra consulta/comentario.
Saludos! =)
he visto el video 3 veces, y aun no me queda claro ciertas cosas me parece que esta bastante confuso todo..
Por un lado el hedear IPv4 tiene un tamaño de 2 elevado a la 16 que es 65536, porque se habla entonces de 65535? donde queda el bit restante?
El header IPV4 es de tan solo 32 bits estos 32 bits se completarian con los 4 primeros campos del encabezado (4 bits de VERSION + 4 bits del header lenght + 8 bits del DSCP+ 16 bits de PACKET LEGHT =32) ya ahi estan los 32 bits, que pasa entonces con el resto de los campos del header como lo son TTL, Source Address, Dest, address etc? y eso que dice 20-60 bytes en la imagen abarca el tamaño total del header no del paquete ipv4… No se, no me queda para nada clara esta explicaciòn .
por otro lado de cara al examen de certificacion hay que aprenderse el tamaño de cada campo del header y su funciòn?
Favor aclarar.
Hola Richchri!
En el video se menciona que el tamaño de ese campo es de 16 bits, 16 bits te proporcionan 65536 VALORES diferentes, no te indica que el tamaño sea de 65536. Los 65536 valores van desde el valor binario 00000000 00000000 hasta el valor binario 11111111 11111111 que es equivalente al decimal 65535. Por lo tanto los VALORES decimales que encuentras en ese campo van desde 0 al 65535 (dando un total de 65536 valores diferentes).
Respecto a tu segunda consulta. El header IPv4 NO es de 32 bits, tal vez podrías indicarme a qué parte del video te refieres para poder aclararlo?… el header IPv4 tiene un tamaño mínimo de 20 BYTES.
Respecto a tu última consulta, sí, necesitas conocer las funciones de los diferentes campos del header IPv4 por lo menos de manera básica. En el examen podrían preguntarte por ejemplo cual es la función del campo Time To Live del header IPv4.
Atento a tus comentarios.
Saludos! =)
Hola Alvaro,
Como es que se interpreta que 16 bits = 65536 bytes (Para el campo Packet Length) ? Yo entiendo que 16 bits son 65536 en decimal y dividido entre 8 se obtendra los Bytes que en este caso seria 8192 Bytes.
¡Hola Ángel!
El concepto, es que el valor que obtengas en ese campo se debe interpretar como si fueran bytes… tienes 16 bits disponibles, ¿no es cierto?… supongamos que en ese campo encuentras el valor 00000000 00000010, eso es equivalente al valor decimal 2, entonces el resultado es que el header IP tendría un tamaño de 2 BYTES. Lo que encuentres en ese campo, DEBES asumir que se trata de bytes. Si haces una captura en Wireshark, lo más probable es que veas el valor de 1500, esos son 1500 BYTES. Si no fuera interpretado así, tendríamos que hacer más grande el header IPv4…tendríamos que tener un tamaño del Packet lenght de 19 bits.
La definición formal del RFC (https://datatracker.ietf.org/doc/html/rfc791#page-11), es que «El total lenght, es el tamaño del datagrama MEDIDO en OCTETOS (Bytes), donde se incluye el header de Internet y la información”. Lo mismo, si tienes un valor de 1500, significa 1500 OCTETOS, es decir 1500 bytes.
Espero haberte ayudado con mi respuesta.
Estoy atento a tus comentarios.
Saludos!
Hola Alvaro!
1. Qué hace que en el campo Header Lenght se tenga un valor de 5 o 15? es debido a que no todos los campos del header son utilizadas? tiene que ver con los datos en los otros campos del header? en algún momento se puede tener el valor de 11?
2. Respecto al cambio en el campo ToS por los valores DSCP y ECN, ese cambio se ve reflejado en la
página web de la IANA o de alguna otra entidad que se encarga de realizar esas modificaciones?3. Con el campo Time to Live se puede saber o tener una idea por cuantos routers a tenido que pasar un paquete IP hasta llegar a mi PC? existe algún comando en los SO para saber por cuantos routers un paquete IP ha tenido que pasar hasta llegar a mi PC?
4. Por curiosidad, si se pudiera enviar una trama con datos encapsulados de 65535 bytes, qué pasaría en una red? volvería más lenta la comunicación?
5. El MTU de Ethernet es de 1500 bytes, qué pasa con fibra óptica y con Wifi? También son de 1500 bytes?
Gracias de antemano!
- Debes estar registrado para responder a este debate.