Tuesday, August 05, 2014


El siguiente proceso detalla las diferentes etapas que suceden para que un mensaje de http-get pueda llegar a la frontera de la red local y así iniciar el proceso de obtener la página web de un browser.

Este proceso asume que el dispositivo originario de la petición ya posee los cuatro parámetros fundamentales para la conectividad a Internet: Dirección IP, Máscara de Red, Default Gateway  y Servidor DNS.

Este proceso asume que los dispositivos involucrados en la Red Local (o dominio de Broadcast) están recién encendidos.


1.     La aplicación HTTP construye un comando/mensaje HTTP-GET y se lo pasa a la capa de transporte.

2.     La capa de transporte construye un segmento TCP indicando que el puerto origen es el 49152 -  Tip: http://en.wikipedia.org/wiki/Ephemeral_port , estos son los puertos que se utilizan como origen / source en TCP/UDP/

3.     La capa de transporte sigue construyendo el segmento e indica que el puerto destino es el puerto 80 (porque la aplicación es http)

4.     La capa de transporte agrega el resto de headers necesarios (estos los veremos más adelante en el curso)

5.     La capa de transporte le pasa el segmento que construyó a la capa de Red.

6.     La capa de Red intenta construir el paquete que será enviado a través de Internet, necesita los siguientes datos: Dirección IP origen y Dirección IP destino.  Aquí la capa de Red se topa con el primer problema, tiene la dirección origen (que es la del Host que está queriendo abrir el Website), pero la dirección destino no la tiene, ya que como se acaba de encender el dispositivo, el DNS Cache que tienen la mayoría de dispositivos está vacío (para más detalles de este Cache local: http://www.wikihow.com/Display-the-Contents-of-Your-DNS-Cache)

7.     Como no conoce la dirección IP del destino, entonces tiene que ir a preguntarlo a alguien, es por esta razón que el DNS es uno de los parámetros fundamentales que requiere un Host para conectarse a Internet.  Para este ejemplo, el DNS que utiliza el Host, está en el mismo Broadcast Domain que el Host.

8.     El Host invoca al proceso DNS Resolve, que obtendrá la dirección IP destino que tiene que colocar en el paquete la capa de Red en n.6

9.     Este nuevo proceso DNS Resolve, construye un mensaje en la capa de aplicación, en el cual el dato principal que va es el nombre de host para el cual quiere obtener la dirección IP.

10. Este mensaje del proceso DNS es enviado a la capa de transporte, y como viene del proceso DNS, la capa de transporte construye un segmento UDP, poniendo como puerto de origen el 49153 (otro ephemeral port) y puerto destino el puerto 53 (que es el que corresponde a DNS)

11. La capa de transporte le pasa su segmento a la capa de Red, para que esta construya un paquete IP.  Los datos fundamentales de este paquete son: dirección IP Origen (que es la de nuestro Host) y dirección IP destino (que es la del DNS Server que estamos utilizando), al conocer ambas direcciones IP, la capa de red le pasa el mensaje a la capa de Enlace de Datos.

12. La capa de enlace de datos, comienza a construir el frame que se enviará, los datos fundamentales que necesita para construir este frame son: Dirección física (MAC) origen y Dirección física (MAC) destino.   La MAC origen la tiene porque es la que está en el puerto Ethernet del dispositivo.  La dirección MAC destino tiene dos opciones:

a.     Envía el frame al Default Gateway que tiene configurado, esta opción es la que toma cuando la dirección IP destino está en diferente Broadcast Domain, esto lo sabe al combinar la dirección IP y la máscara que ambas identifican al broadcast domain.   En este caso, en el campo de  MAC destino del frame que construyó, coloca la MAC del default Gateway.

b.     Envía el frame directo a la IP destino, esto se da cuando la IP destino está en el mismo Broadcast Domain que el dispositivo que está enviando el frame.

En nuestro caso,  mencionamos que el DNS está en el mismo Broadcast Domain que el dispositivo, por lo tanto la MAC address que se coloca en el frame es la del servidor DNS que tiene configurado…



13.  Debido a que la capa 2 desconoce la dirección MAC del Servidor DNS (si conoce la dirección IP porque es uno de los parámetros fundamentales que el Host tiene configurados para la conectividad exitosa a Internet), se invoca a un nuevo proceso, el proceso de ARP.

14. El proceso de ARP construye un frame de capa 2 cuya data que encapsula es un “paquete ARP”, que es un tipo de paquete especial que lleva varios datos, de momento el que más nos interesa es que lleva la IP del Host que está originando la petición ARP, la IP del host destino, la MAC originaria.  Lleva estos datos para que cuando el proceso ARP del host que responda por esa IP responda al requerimiento ARP, el mismo guarda en su tabla de ARP la combinación IP-MAC del Host que le preguntó, así se ahorra ejecutar el proceso ARP para frames que vayan destinados a es Host.

15. El frame que construye el proceso ARP tiene como MAC origen la del Host y MAC destino coloca la dirección de Broadcast de capa 2: FF:FF:FF:FF:FF:FF

16. Este frame es enviado por el medio de transmisión que se esté utilizando.

17. Cuando el frame llega al switch, al ser un frame broadcast, este hace un flood a todos sus puertos y por lo tanto todos los dispositivos conectados a este switch reciben el frame.

18. Cuando un dispositivo recibe el frame de Broadcast y ve que es un requerimiento ARP, compara la información que viene en el paquete ARP con la información propia.   Si la IP Address por la que está preguntando el paquete ARP es diferente que la IP Address de dicho dispositivo, entonces descarta el paquete y no hace más nada.  Si existe coincidencia entre la IP que preguntan y la IP del host que recibe, entonces construye un paquete ARP en el cual indica su dirección MAC y lo envía a la dirección MAC origen del paquete original.

19. Cuando al switch le llega este frame ARP de respuesta, ya sabe por qué puerto tiene que enviarlo (porque grabó en su tabla de forwarding el puerto en que recibió la MAC address del ARP original)

20. Cuando este paquete ARP le llega al Host que envió la petición, este ya puede completar la MAC Address en el frame que se estaba construyendo en el n.12.

21. Como ya tiene la MAC address del DNS Server que está en el mismo Broadcast Domain, termina de construir el frame que lleva el “query” DNS. 

22. Este frame se envía nuevamente al Switch, que ya tiene en su tabla el puerto por el cual tiene que enviar el Frame al DNS Server, ya que cuando en el paso 19 el switch recibió el frame que contiene el paquete ARP de respuesta, guardó en su tabla de forwarding el puerto asociado a la MAC address del server DNS.

23. El switch envía el frame únicamente por el puerto que tiene su tabla y este frame llega al Server DNS, que lo procesa, verifica que es dirigido a él en las capas 2 (MAC) y capa 3 (IP), ve que va dirigido al puerto 53 (puerto destino), por lo tanto al pasárselo a la capa de aplicación lo hace invocando al proceso de DNS que está activo en dicho server.  Este proceso revisa que el query cumpla con la sintaxis del protocolo DNS.  Hechas estas verificaciones entre capas, finalmente el proceso de DNS obtiene la dirección IP por la que está siendo preguntado (como obtiene esta dirección está fuera del alcance de esta discusión, veremos detalles de esto más adelante en el curso)




24. La aplicación DNS construye un mensaje de respuesta que contiene la dirección IP correspondiente al query que recibió en n.23 y le pasa este mensaje a la capa de transporte.

25. La capa de transporte del servidor DNS construye un segmento de respuesta con puerto origen 53 y puerto destino 49153, esta combinación de puertos es la inversa a la del n.10.  Este segmento se pasa a la capa de Red.

26. La capa de red del servidor DNS construye un paquete con las direcciones IP origen y destino invertidas a las descritas en n.11.  Este paquete se pasa a la capa de enlace de datos.

27. La capa de enlace de datos del servidor DNS verifica si el paquete a ser enviado está en su mismo dominio de Broadcast, como efectivamente así es, entonces construye el frame con MAC address originen la de si mismo y MAC address destino la del Host que realizó la petición (esta ya la tiene porque obtuvo un frame previamente y guardó la dupla en su ARP-Cache).  Este frame es enviado por el medio físico correspondiente.

28. Cuando el frame de respuesta DNS llega al switch que interconecta a todos los dispositivos de ese dominio de Broadcast, envía el frame por el puerto en el que conoció la MAC address a la que va destinado (esta combinación puerto-MAC ya la tiene en su tabla de Forwarding porque ya recibió el switch varios frames procedentes de esa misma MAC address).

29. Cuando el Host originario recibe el frame de respuesta DNS, va quitando todas las capas (2, 3, 4) hasta llegar a la capa de aplicación , en la cual encuentra la respuesta a la pregunta que hizo en el n. 9

30. Ahora podemos continuar con el proceso interrumpido en n.7, ya la capa de red construye el paquete completo, con dirección IP origen la de si mismo y dirección IP destino la obtenida a través de todo el proceso de DNS.  Este paquete se pasa a la capa 2.

31. La capa 2 discierne si es un paquete a ser enviado dentro del mismo Broadcast domain, en este ejemplo el servidor Web al que el usuario quiere acceder está fuera del dominio de Broadcast en que el mismo esté, en consecuencia, el frame que construye tiene como MAC Origen la de si mismo y como MAC destino coloca la del Default Gateway (que es otro parámetro fundamental para la conectividad a Internet de un Host).   Debido a que no tiene la dirección MAC del Default Gateway, se hacen los pasos 13 al 22 pero para asociar la IP y la MAC del Default Gateway.

32. El frame de http-get se construye y se envía al switch, el cual se envía al Default Gateway.

33. Cuando el Default Gateway recibe el frame de http-get únicamente desencapsula la capa 2 y analiza la capa 3.  Hasta aquí llega este ejercicio, el ruteo detallado por internet es objeto de otro tema que veremos más adelante en la clase.



Monday, May 05, 2014

Una de las frases que más he escuchado es que el líder ha de ir adelante, abriendo camino y no detrás del grupo gritándo y dando instrucciones.  Hasta hace poco pensaba que era la única opción de liderazgo, ir adelante, abriendo camino, observando el panorama y guiando al grupo...


Sin embargo hace unos días leí un discurso del Papa Francisco que le daba a los Obispos, que bien puede aplicarse a cualqueir líder:

Textualmente el Papa les dijo:

La presencia pastoral significa caminar con el pueblo de Dios: delante, señalando el camino; en el medio, para fortalecer en la unidad; detrás, para que nadie quede atrás, pero, sobre todo, para seguir el olfato que tiene el pueblo de Dios para encontrar nuevos caminos"

Traduciendolo un poco a un lenguaje de liderazgo podría decir algo así:

El líder ha de estar presente con su grupo: delante, señalando el camino; en el medio, para fortalecer en la unidad; detrás, para que nadie quede atrás, pero, sobre todo, para seguir el olfato que tiene el grupo para encontrar nuevos caminos"

Entonces mi nueva visión es: el líder no ha de ir siempre adelante, ni siempre atrás, ni siempre en el medio... dependerá de las necesidades del grupo y también de las necesidades particulares de los miembros de ese grupo, el líder ha de estar presente, en donde convenga para el bien del grupo y de sus integrantes.