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


El contenido completo solo está disponible para miembros. Suscríbete y continúa tu aprendizaje sin interrupciones.
Suscribirme
CCNA 200-301 1. Fundamentos de Redes Introducción a la capa de red y al protocolo IPv4

Introducción a la capa de red y al protocolo IPv4

Cuando abrimos una página web alojada en un servidor en otro continente, los datos que pedimos y los que recibimos atraviesan decenas de dispositivos intermedios antes de llegar a nuestra pantalla. Detrás de ese viaje hay una capa del modelo de red que se encarga de que cada paquete sepa hacia dónde ir, sin importar cuántas redes o dispositivos tenga que atravesar en el camino. Esa es la capa de Red con el protocolo IPv4.

¿Qué lograrás con esta clase?

  • Comprender el rol de la capa de Red en el modelo TCP/IP y cómo se apoya en las capas adyacentes.
  • Identificar las funciones que la capa de Red ejecuta para que los datos lleguen a destino.
  • Interpretar la estructura del header IPv4 campo por campo.
  • Reconocer conceptos como MTU, fragmentación, Time To Live y número de protocolo dentro del header.
  • Analizar tráfico IPv4 real sobre Wireshark aplicando filtros para aislar la comunicación entre dos dispositivos.
  • Diferenciar las características de IPv4 que definen su comportamiento: connectionless, best-effort y medio-independiente.

Las funciones de la capa de red

La capa de Red tiene una misión clara: llevar los datos desde un dispositivo de origen hasta su destino final, sin importar cuántos routers y dispositivos intermedios existan en el trayecto. Para lograrlo se apoya en varias funciones que trabajan en conjunto, y en la clase desarrollaremos cada una con ejemplos concretos para que entiendan por qué se necesitan todas y qué pasaría si alguna fallara.

Entre esas funciones aparecen la encapsulación y desencapsulación, que enlazan la capa de Red con sus capas vecinas, el direccionamiento lógico, que permite identificar de forma única a cada host de la red, y el enrutamiento, que actúa como mapa de navegación para los paquetes. Cómo opera cada una sobre dispositivos reales y cómo se relacionan entre sí es algo que abordaremos durante la clase.

El protocolo IPv4 y su header

Estudiaremos el protocolo IPv4 a partir de su header, analizando su tamaño mínimo y máximo y revisando qué función cumple cada uno de sus campos. Veremos conceptos como el MTU y el tamaño del paquete, los mecanismos de fragmentación, el Time To Live que evita los bucles infinitos en la red, y los números de protocolo que indican qué tipo de tráfico transporta cada paquete.

Pero la teoría sola no alcanza para fijar los conceptos. Por eso utilizaremos Wireshark para capturar tráfico real (Tráfico de Spotify) y aplicaremos filtros que nos permitan aislar la conversación entre dos dispositivos específicos, observando el header IPv4 campo por campo en una comunicación real. Verán cómo se traduce cada concepto teórico en bits concretos viajando por la red en ese mismo momento.

Las tres características que definen a IPv4

Para cerrar la clase analizaremos tres características que explican por qué IPv4 se diseñó como se diseñó y por qué sigue siendo el protocolo más utilizado en Internet. Estas características tienen consecuencias directas en cómo se comporta el tráfico que viaja por la red y en qué tareas quedan delegadas a otras capas o a otros protocolos.

Hablamos del comportamiento connectionless, del paradigma best-effort y de la independencia respecto al medio físico. Cada una de estas características tiene una razón de diseño que vale la pena entender, sobre todo porque marca diferencias claves con otros protocolos que analizaremos como IPv6.



Si quieres entender de raíz cómo los datos viajan de un punto a otro en una red de computadoras, accede a la clase de Introducción a la capa de Red y al protocolo IPv4 donde combinamos la teoría del header IPv4 con captura real de tráfico en Wireshark para que veas el protocolo en acción. ¿Qué esperas? ¡Suscríbete!

❓ Preguntas Frecuentes

¿Cuál es la función principal de la capa de Red?

La capa de Red se encarga de que los datos lleguen desde su origen hasta su destino atravesando todos los dispositivos intermedios necesarios. Para lograrlo combina varias funciones como el direccionamiento lógico y el enrutamiento. Cómo trabajan estas funciones en conjunto y qué rol cumple cada una lo desarrollamos a detalle durante la lección.

¿Qué información transporta el header IPv4?

El header IPv4 transporta toda la información que los routers necesitan para tomar decisiones sobre cada paquete: direcciones de origen y destino, control de fragmentación, Time To Live, número de protocolo, entre otros. Qué representa cada campo y cómo se ve sobre tráfico real en Wireshark es lo que analizamos paso a paso en la clase.

¿Qué significa que IPv4 sea un protocolo connectionless y best-effort?

Significa que IPv4 no establece una conexión previa entre los dispositivos antes de enviar datos, y que tampoco garantiza que esos datos lleguen a destino: hace el mejor intento posible pero no se compromete con la entrega. Por qué se diseñó así y qué consecuencias tiene esta decisión sobre el resto de la pila TCP/IP lo discutimos durante la sesión.

 
logo
SI QUIERES DISFRUTAR DE ESTE CONTENIDO, TE INVITAMOS A QUE TE SUSCRIBAS.

PREGUNTAS

Las preguntas que encontraras en esta sección, son similares a las que te encontraras en el examen de certificación.

Paso 1 de 2

¡PARTICIPEMOS!

Si te quedaron dudas de la lección, escríbela a continuación y así todos podemos participar y ayudarte.
¿Quieres participar en los debates?… por favor suscríbete

NUESTROS CURSOS Foros Introducción a la Capa de Red y al protocolo IPv4

Viendo 15 entradas - de la 16 a la 30 (de un total de 32)
  • Autor
    Entradas
  • #24103
    Javier Madrigal
    Participante

    Hola Alvaro! Muchas gracias por evacuar mi duda. Me quedó claro. Saludos.

    #24111
    AlvaroM
    Superadministrador

    De nada Javier! Saludos! =)

    #27004
    Jose Bernabe Garcia
    Participante

    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.

    #27009
    AlvaroM
    Superadministrador

    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, 7 meses por AlvaroM.
    #27073
    Jose Bernabe Garcia
    Participante

    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.

    #27082
    AlvaroM
    Superadministrador

    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.

    #27122
    Jose Bernabe Garcia
    Participante

    Gracias por tu aclaración, Alvaro. Pero una pregunta.. entonces TCP CLAMPING evita la fragmentación? o la fragmentación con tuneles GRE se seguirá produciendo?

    Muchas gracias.

    Un saludo.

    #27131
    AlvaroM
    Superadministrador

    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.

    #30723

    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.

    #30728
    AlvaroM
    Superadministrador

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

    #32742
    richchri
    Participante

    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.

    #32743
    AlvaroM
    Superadministrador

    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, 8 meses por AlvaroM.
    #36430
    mdelta70908
    Participante

    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.

    #36431
    AlvaroM
    Superadministrador

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

    #38421
    Mauricio MV
    Participante

    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!

Viendo 15 entradas - de la 16 a la 30 (de un total de 32)
  • Debes estar registrado para responder a este debate.