Hola Diego!

Buenas noches, como mencionamos a partir del minuto 33, los campos «Source Address» y «Destination Address» del HEADER IPv4 tienen un tamaño de 32 bits… dentro de estos campos se almacenan las direcciones IP de origen y destino que tienen los paquetes cuando salen de un dispositivo en particular… no te preocupes que en esta siguiente clase: https://netwgeeks.com/topic/1-8-estructura-direccion-ipv4-parte-1-conversion-binario-decimal/ ya explicamos el porqué de 32 bits… dale una mirada y esta duda debería quedar totalmente disipada!

Atento a tus comentarios.

Saludos cordiales!

Hola Daniel!

Buena pregunta, en realidad tienes que entender que este tema de «cómo se conoce la dirección de destino» se da a nivel aplicativo. Es decir cuando alguien desarrolla un determinado programa, en el código de la aplicación ya viene detallado a que dirección IP se debe comunicar un dispositivo. En algunos casos se debe configurar este dato en la aplicación de tu computadora (no aplica a servicios web).

Por ejemplo, cuando tu abres Spotify, automáticamente recibes desde Internet las canciones y sugerencias de artistas entre muchas otras cosas no?… tu en ningún momento definiste la IP para solicitar esas canciones, esto es porque la aplicación ya está programada para comunicarse con la IP del servidor de Spotify para obtener todos los datos que te muestra el aplicativo.

Respecto a tu consulta sobre el correo electrónico, en el caso de aplicaciones como Outlook, Zimbra o alguna similar, tu NO estas recibiendo el correo electrónico directamente en TU computadora, tu aplicativo de tu computadora es el que se está comunicando con el servidor de correo de manera interna… el aplicativo es el que ya está programado o configurado para comunicarse con la IP del servidor de correo de manera que pueda «obtener» los correos electrónicos que están destinados a tu cuenta y así tú los puedas ver en tu computadora. Si tu aplicas algún tipo de restricción entre la comunicación de tu IP con la IP del servidor de correo, NO vas a poder recibir los correos electrónicos aunque tengas comunicación con las otras PCs de tu red interna que te están enviando correos electrónicos. Y esto ocurre en la gran mayoría de las aplicaciones.

En el caso de la navegación WEB se utiliza el protocolo DNS para obtener la dirección IP del servidor web que aloja la página web.

Espero que ahora quede clara la idea!

Atento a tus comentarios! =)

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

Hola Oscar!

El campo Header Lenght tiene un tamaño de 4 bits, con esos 4 bits tú puedes expresar el tamaño de TODO el header IPv4 en palabras de 4 bytes o 32 bits (8 bits = 1 byte).

Podrías tener todas estas combinaciones con 4 bits

Binario Decimal
0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
0101 = 5
0110 = 6
0111 = 7
1000 = 8
1001 = 9
1010 = 10
1011 = 11
1100 = 12
1101 = 13
1110 = 14
1111 = 15

Esto quiere decir que el número (decimal) que tengas almacenado en ese campo header lenght debes multiplicarlo por 4 para obtener el tamaño real del header IPv4 en bytes. El término «palabra» se usa en arquitecturas de computadoras, no te compliques con ese término… de manera simple, la «palabra» significa una agrupación de bits que pueden ser manejados por un procesador.

Para hacerlo más sencillo, podríamos expresarnos de la siguiente manera… «el campo header lenght almacena el tamaño del header IPv4 dividido entre 4».

Entonces, el mínimo valor permitido que puedes tener en ese campo es 5, ese valor lo multiplicas por 4… y te da 20 bytes que llegaría a ser el tamaño real del header IPv4.

Espero que ahora quede claro el panorama.

Atentos a tus comentarios!

Saludos cordiales.

Hola Edgar bienvenido al foro! =)

Recuerda que el curso está orientado a obtener la certificación CCNA. Se tocan los capítulos necesarios que te pide la certificación y se toca la parte práctica que te pide la certificación. De hecho toda la teoría que se aprende NO la vas a ver en la parte práctica, la mayoría sí pero no toda, por ejemplo de QoS vemos un poco de teoría pero no se ve la parte práctica, de VSS y Stacking vemos un poco de teoría pero no se ve la parte práctica, de 802.1X se ve teoría pero no parte práctica y así… para bien o para mal, así ha estructurado el material Cisco.

Por otro lado, consideramos que estos temas iniciales son vitales para la parte práctica, sin conocer la conversión binario a decimal/VLSM/Subnetting sería imposible definir las IPs a utilizar en nuestros dispositivos… creemos que NO tiene mucho sentido ver práctica en este punto sin tener las bases necesarias para entender lo que se hace, podríamos enseñar a configurar una computadora, podríamos enseñar a configurar una IP en un dispositivo, pero eso no tiene mucho sentido si no se sabe que es lo que se está configurando.

Para finalizar, no te preocupes que tienes mucha práctica por delante, e inclusive un curso entero de Packet tracer donde SOLAMENTE tienes prácticas.

Estoy atento a tus comentarios.

SAludos cordiales!

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

Hola Xopo!

Bueno, en primera instancia tienes que tener en cuenta que la comunicación de TCP es entre el dispositivo que inicia la comunicación y el dispositivo al cual están destinado los datos ¿no es cierto? … por lo tanto, entre esos 2 dispositivos pueden existir decenas de routers, switches, firewalls, etc. Esto quiere decir que tus segmentos TCP transportados, van a viajar a través de diferentes enlaces de capa 2 que pueden tener diferentes MTUs, lo ideal sería que tus segmentos viajen a través de redes Ethernet que mantengan su MTU de 1500 bytes, en este caso no haría falta la fragmentación… sin embargo en la vida real puede no ser así, puede ser que en el primer salto desde tu computadora hacia un router utilices la tecnología Ethernet (1500 bytes), y que después tengas un enlace de capa 2 donde el MTU es menor… entonces que pasa en esos casos?… ¿cómo transportar una trama de 1500 bytes a través de un enlace que solo te permite transportar supongamos …600 bytes?… en estos casos lo único posible a realizar es la fragmentación. IP va agarrar todo el paquete y lo va dividir en partes más pequeñas de manera que puedan ser transportados por el segundo enlace.

El MSS que define el tamaño el segmento TCP en el dispositivo inicial, solamente toma en cuenta el MTU de la interface de capa 2 LOCAL, es decir solamente te sirve para tu primer salto hacia el primer dispositivo en el camino al destino final, TCP no toma en cuenta los otros dispositivos que puedan existir en el camino al dispositivo final y que puedan tener otros tamaños de MTU.
En la vida real, se trata de evitar la fragmentación a toda costa, ya que es un proceso que consume bastantes recursos. En la actualidad existen tecnologías como PMTU que se encargan de analizar cuál es el MTU más pequeño en todo el trayecto al destino final, y de acuerdo a ese MTU se crea el segmento TCP de manera que no pueda existir fragmentación en ningún punto de la red.

Si gustas acá tenemos una entrada de un blog donde hablamos más a detalle sobre este tema: https://netwgeeks.com/fragmentacion-ipv4/

Espero haberte ayudado con mi respuesta.

Estoy atento a tus comentarios.

Saludos cordiales.

Hola Jhon

Tienes alguan consulta en particular?

Estamos atentos a tus comentarios.

Hola Javier!

No nos confundamos entre el tamaño del paquete con el tamaño del HEADER del paquete, son cosas diferentes. El tamaño máximo del HEADER del paquete IP efectivamente llega hasta 60 bytes, pero el tamaño del PAQUETE IP hace referencia al tamaño del header del paquete IP + header de capa de transporte + datos de aplicación. El tamaño del CAMPO «PACKET LENGHT» del HEADER IP tiene 16 bits… en esos 16 bits tu expresas el tamaño del PAQUETE IP en BYTES… con 16 bits el valor máximo que puedes tener es de 65535, por lo tanto el tamaño máximo de paquete que puedes tener es de 65535 bytes.

Espero que ahora quede claro, de todas formas esto se explica en el minuto 23:26.

Atento a tus comentarios.

Saludos cordiales.