1.7. Introducción a la Capa de Red y al protocolo IPv4

De nada Javier! Saludos! =)

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!

• Esta respuesta fue modificada hace 4 años, 1 mes por AlvaroM.

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.

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! =)

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! =)

• Esta respuesta fue modificada hace 3 años, 2 meses por AlvaroM.

¡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!