Protocolo TCP/IP

05

En esta Unidad aprenders a:

1

Conocer la estructura de la pila de protocolos TCP/IP. Analizar el funcionamiento de las redes basadas en el protocolo TCP/IP. Resolver problemas mediante los comandos y las utilidades de diagnstico ms conocidas. Configurar los parmetros y servicios bsicos en distintos routers. Comprender el funcionamiento de los elementos implicados en las tcnicas de enrutamiento.

5. Protocolo TCP/IP
5.2 Arquitectura del protocolo TCP/IP

5.1 Introduccin al protocolo TCP/IP

Las siglas TCP/IP se refieren a un conjunto de protocolos para comunicaciones de datos. Este conjunto toma su nombre de dos de sus protocolos ms importantes, el protocolo TCP (Transmission Control Protocol) y el protocolo IP (Internet Protocol). La evolucin del protocolo TCP/IP siempre ha estado muy ligada a la de Internet. En 1969 la agencia de proyectos de investigacin avanzada, ARPA (Advanced Research Projects Agency) desarroll un proyecto experimental de red conmutada de paquetes al que denomin ARPAnet. ARPAnet comenz a ser operativa en 1975, pasando entonces a ser administrada por el ejrcito de los EEUU. En estas circunstancias se desarrolla el primer conjunto bsico de protocolos TCP/IP. Posteriormente, y ya entrados en la dcada de los ochenta, todos los equipos militares conectados a la red adoptan el protocolo TCP/IP y se comienza a implementar tambin en los sistemas Unix. Poco a poco ARPAnet deja de tener un uso exclusivamente militar, y se permite que centros de investigacin, universidades y empresas se conecten a esta red. Se habla cada vez con ms fuerza de Internet y en 1990 ARPAnet deja de existir oficialmente. En los aos sucesivos y hasta nuestros das las redes troncales y los nodos de interconexin han aumentado de forma imparable. La red Internet parece expandirse sin lmite, aunque manteniendo siempre una constante: el protocolo TCP/IP. En efecto, el gran crecimiento de Internet ha logrado que el protocolo TCP/IP sea el estndar en todo tipo de aplicaciones telemticas, incluidas las redes locales y corporativas. Y es precisamente en este mbito, conocido como Intranet, donde TCP/IP adquiere cada da un mayor protagonismo. La popularidad del protocolo TCP/IP no se debe tanto a Internet como a una serie de caractersticas que responden a las necesidades actuales de transmisin de datos en todo el mundo, entre las cuales destacan las siguientes: Los estndares del protocolo TCP/IP son abiertos y ampliamente soportados por todo tipo de sistemas, es decir, se puede disponer libremente de ellos y son desarrollados independientemente del hardware de los ordenadores o de los sistemas operativos. TCP/IP funciona prcticamente sobre cualquier tipo de medio, no importa si es una red Ethernet, una conexin ADSL o una fibra ptica. TCP/IP emplea un esquema de direccionamiento que asigna a cada equipo conectado una direccin nica en toda la red, aunque la red sea tan extensa como Internet.

Pueden consultarse ms de tres mil RFCs en la pgina web www.rfc-editor.org. El RFC Editor es un grupo fundado por la Sociedad Internet (www.isoc.org/esp). Por fortuna los estndares RFC pueden ser ledos en espaol gracias al trabajo desinteresado del Grupo de Traduccin al castellano de RFC (www.rfc-es.org).

La naturaleza abierta del conjunto de protocolos TCP/IP requiere de estndares de referencia disponibles en documentos de acceso pblico. Actualmente todos los estndares descritos para los protocolos TCP/IP son publicados como RFC (Requests for Comments) que detallan lo relacionado con la tecnologa de la que se sirve Internet: protocolos, recomendaciones, comunicaciones, etctera.

5.2 Arquitectura del protocolo TCP/IP

El protocolo TCP/IP fue creado antes que el modelo de capas OSI, as que los niveles del protocolo TCP/IP no coinciden exactamente con los siete que establece el OSI. Existen descripciones del protocolo TCP/IP que definen de tres a cinco niveles. La Figura 5.1 representa un modelo de cuatro capas TCP/IP y su correspondencia con el modelo de referencia OSI. Los datos que son enviados a la red recorren la pila del protocolo TCP/IP desde la capa ms alta de aplicacin hasta la ms baja de acceso a red. Cuando son recibidos, recorren la pila de protocolo en el sentido contrario. Durante estos recorridos, cada capa aade o sustrae cierta informacin de control a los datos para garantizar su correcta transmisin, como ya hemos visto en la Unidad 4.
7 6 5 4 3 2 1 Modelo de referencia OSI Aplicacin Presentacin Sesin Transporte Red Enlace Fsica Transporte Internet Acceso a red 3 2 Permite el envo de datos de extremo a extremo Define datagramas y maneja rutas Rutinas que permiten el acceso fsico a la red Aplicacin 4 Procesos y aplicaciones de red Arquitectura TCP/IP

Fig. 5.1. Correspondencia del modelo OSI con TCP/IP.

93 05

5. Protocolo TCP/IP
5.2 Arquitectura del protocolo TCP/IP

Capa de aplicacin

4 DATOS 3

Capa de transporte

Existe otra recomendacin: la RFC 894 es el estndar para la transmisin de datagramas IP sobre redes Ethernet. Especifica cmo se encapsulan datagramas del protocolo IP para que puedan transmitirse en una red Ethernet.

HEADER

DATOS 2

B. Capa de red: Internet

La capa Internet se encuentra justo encima de la capa de acceso a red. En este nivel el protocolo IP es el gran protagonista. Existen varias versiones del protocolo IP: IPv4 es en la actualidad la ms empleada, aunque el crecimiento exponencial en el tamao de las redes compromete cada vez ms su operatividad. El nmero de equipos que IPv4 puede direccionar comienza a quedarse corto. Para poner remedio a esta situacin se ha desarrollado la versin IPv6, con una capacidad de direccionamiento muy superior a IPv4, pero totalmente incompatible. El protocolo IP se ha diseado para redes de paquetes conmutados no orientadas a conexin, lo cual quiere decir que cuando dos equipos quieren conectarse entre s no intercambian informacin para establecer la sesin. IP tampoco se encarga de comprobar si se han producido errores de transmisin, confa esta funcin a las capas superiores. Todo ello se traduce en que los paquetes de datos contienen informacin suficiente como para propagarse a travs de la red sin que haga falta establecer conexiones permanentes. Para el protocolo IP un datagrama es el formato que debe tener un paquete de datos en la capa de red. La Figura 5.3 representa la estructura de un datagrama: muestra las seis primeras palabras de la cabecera y el punto desde el que se comienzan a transmitir los datos. Las cinco (o seis) primeras palabras de 32 bits contienen la informacin necesaria para que el datagrama se propague por la red, y a continuacin se adjuntan los datos. La lgica de funcionamiento del protocolo IP es simple: para cada datagrama consulta la direccin origen (palabra 4) y la compara con la direccin destino (palabra 5). Si resulta que origen y destino se corresponden con equipos (hosts) de la misma red, el datagrama se enva directamente de un equipo a otro. Si, por el contrario, los equipos pertenecen a redes distintas, se hace necesaria la intervencin de una puerta de enlace o gateway que facilite el envo a redes diferentes. El paso de datos de una red a otra a travs de una puerta de enlace es conocido como salto (hop). Un datagrama puede realizar varios saltos a travs de diversas redes hasta alcanzar su destino. El camino que siguen los datos enviados por un equipo a otro no tiene por qu ser siempre el mismo. La bsqueda del camino ms adecuado a cada momento se denomina enrutamiento. De hecho, a las puertas de enlace se les denomina enrutadores (routers).

Capa de red

HEADER

HEADER

DATOS 1

Capa de acceso a red

HEADER

HEADER

HEADER

DATOS

Datos enviados Fig. 5.2. Encapsulado de datos por los niveles TCP/IP.

Datos recibidos

Como esta informacin de control se sita antes de los datos que se transmiten, se llama cabecera (header). En la Figura 5.2 se puede ver cmo cada capa aade una cabecera a los datos que se envan a la red. Este proceso se conoce como encapsulado. Si en vez de transmitir datos se trata de recibirlos, el proceso sucede al revs. Cada capa elimina su cabecera correspondiente hasta que quedan slo los datos. En teora cada capa maneja una estructura de datos propia, independiente de las dems, aunque en la prctica estas estructuras de datos se disean para que sean compatibles con las de las capas adyacentes. Se mejora as la eficiencia global en la transmisin de datos.

A. Capa de acceso a red

Dentro de la jerarqua del protocolo TCP/IP la capa de acceso a red se encuentra en el nivel ms bajo. Es en esta capa donde se define cmo encapsular un datagrama IP en una trama que pueda ser transmitida por la red, siendo en una inmensa mayora de redes LAN una trama Ethernet. Otra funcin importante de esta capa es la de asociar las direcciones lgicas IP a direcciones fsicas de los dispositivos adaptadores de red (NIC). Por ejemplo: la direccin IP 192.168.1.5 de un ordenador se asocia a la direccin Ethernet 00-0C-6E-2B-49-65. La primera es elegida por el usuario (e, incluso, un mismo ordenador puede trabajar con diferentes direcciones IP). Sin embargo la segunda no puede cambiarse e identifica inequvocamente al adaptador NIC dentro de la red Ethernet. Dentro de la capa de acceso a red opera el protocolo ARP (Address Resolution Protocol), que se encarga precisamente de asociar direcciones IP con direcciones fsicas Ethernet. El estndar RFC 826 describe su funcionamiento.

94 05

5. Protocolo TCP/IP
5.2 Arquitectura del protocolo TCP/IP

En la Figura 5.4 vemos un ejemplo elemental de dos redes unidas por un router. En una el equipo A1 enva un datagrama Z al equipo A2. Como ambos pertenecen a la misma red 192.168.10.0, el datagrama Z es enviado directamente. Cuando el equipo A1 pretende enviar otro datagrama Y al equipo B2 que se encuentra en otra red, resulta imprescindible la ayuda del router. Veamos esto con ms detalle: como la direccin destino del datagrama Y no se encuentra en la red de origen, se enva directamente a la direccin de la puerta de enlace 192.168.10.3, que es uno de los interfaces del router. Es ahora este dispositivo quien decide qu camino debe seguir el datagrama Y. Para ello consulta sus tablas internas, y comprueba que la direccin destino coincide con la red en la que tiene conectado su interfaz con direccin 192.168.1.20. Una vez realizada esta consulta ya puede enviar el datagrama Y desde este puerto directamente al equipo B2 (192.168.1.22). El datagrama Y ha llegado a su destino realizando un salto entre redes.

Bits 0 1 2 Palabras 3 4 5 6 Versin 4 IHL 8 12 16 20 24 28 31

Tipo de servicio Flags

Longitud total Offset de fragmentacin Cabecera Checksum de cabecera

Identificacin Tiempo de vida Protocolo

Direccin origen Direccin destino Opciones Los datos comienzan a partir de aqu... Padding

Fig. 5.3. Representacin de la cabecera de una datagrama IP.

A1 192.168.10.3

Router 192.168.1.20

B1

Protocolo ICMP
192.168.10.1 192.168.1.21
Datagrama Y Datagrama Y

En la misma capa de red en la que opera el protocolo IP tenemos tambin el importante protocolo ICMP (Internet Control Message Protocol), definido por la RFC 792. ICMP enva mensajes en forma de datagramas que permiten al conjunto del protocolo TCP/IP realizar entre otras las siguientes funciones: Control de flujo. Si los datagramas llegan muy deprisa al host destino y ste se encuentra con dificultades para procesarlos, el host destino enva al host origen un mensaje ICMP solicitando que de forma temporal detenga su emisin. Deteccin de destinos inalcanzables. Cuando la direccin destino de un datagrama no logra ser asociada a ningn equipo, el host que la ha enviado recibe un mensaje ICMP indicando que el destino indicado es inalcanzable. Redireccionamiento de rutas. Una puerta de enlace puede enviar un mensaje ICMP a un host para hacerle saber que existe otra puerta de enlace dentro de la misma red, y que en ese momento resulta una mejor opcin para encaminar sus datagramas hacia otras redes. Pruebas de conectividad. Esta funcionalidad es la ms conocida ya que es la que emplea el comando ping (Packet Internet Groper). Desde un equipo se puede enviar a otro un mensaje ICMP con eco. Qu significa con eco? Pues quiere decir que cuando el host destino recibe el mensaje lo devuelve inmediatamente al host origen.

Datagrama Y Datagrama Z

Datagrama Y

Datagrama Y Datagrama Z Datagrama Z Datagrama Y

B2

192.168.10.2 A2 Fig. 5.4. Dos formas diferentes de enviar datagramas.

192.168.1.22

Aunque el comando ping fue creado para sistemas Unix, casi cualquier sistema proporciona el software adecuado para su ejecucin. Ping se sirve normalmente de dos mensajes especficos: ECHO_REQUEST y ECHO_REPLY. La conectividad IP entre equipos queda contrastada cuando se completa el camino de ida y vuelta de los mensajes ICMP. Adems el comando ping ofrece informacin acerca del tiempo que tardan el ir y volver los paquetes de datos.

Pruebas de conectividad con ping

El comando ping puede presentar ligeras diferencias y distintas opciones segn el sistema o equipo desde el que se ejecute. La versin de ping que viene con los sistemas operativos Windows enva por defecto cuatro paquetes ICMP de 32 bytes, y si el host de la direccin destino se encuentra activo y recibe los mensajes, responde a cada uno. La forma correcta de ejecutar el programa ping ser desde la una ventana que permita teclear comandos. En

95 05

5. Protocolo TCP/IP
5.2 Arquitectura del protocolo TCP/IP

Cada vez que se enva un paquete ECHO_REQUEST se guarda en el mismo paquete el instante exacto de su salida, y el host destino copia esta informacin en el paquete ECHO_REPLY que devuelve al host origen. Al recibir la respuesta se calcula el tiempo empleado, comparando la hora guardada en el paquete con la hora a la que ha sido recibido. Qu tiempo de ida y vuelta es el ms adecuado? La respuesta depender del tipo de redes por las que viajen los paquetes. Para una LAN los valores que superan tiempos de 100 ms se consideran un error de funcionamiento, aunque ya desde los 10 ms se interpreta que la red LAN es lenta o est congestionada. Si las pruebas ping se hacen a travs de Internet, los tiempos se incrementan notablemente de tal manera que 200 ms es considerado un buen valor, siendo aceptables tiempos de hasta 500 ms. Ping tambin se puede utilizar para medir la tasa de transferencia de datos entre dos equipos. Supongamos que deseamos conocerla para una conexin a Internet. En primer lugar enviaremos un paquete con un tamao de 100 bytes al equipo remoto y seguidamente otro de 1 100 bytes. Utilizaremos los parmetros n para enviar un solo paquete y l para modificar su longitud:
C:\> ping n 1 l 100 www.mcgraw-hill.com C:\> ping n 1 l 1100 www.mcgraw-hill.com

Fig. 5.5. Respuesta correcta a los mensajes ICMP de ping.

El primer ping ofrece un tiempo de ida y vuelta de 180 ms y el segundo de 443 ms: por tanto, para enviar 1 000 bytes adicionales (o, lo que es lo mismo, 8 000 bits) se emplean 263 ms en ida y vuelta, o bien 131,5 ms para uno de los trayectos. La tasa de transferencia medida para esta conexin es de aproximadamente 60,8 Kbps (8 000 bits/131,5 ms).
Fig. 5.6. El host destino no est activo o conectado.

A veces resulta interesante testear una conexin de forma continua. Al aadir t a ping, se envan paquetes de datos hasta que se ordene lo contrario pulsando Control-C.
C:\> ping t 192.168.0.50

Windows XP se abre la ventana Smbolo del sistema siguiendo esta secuencia de seleccin con el cursor: Inicio > Programas > Accesorios > Smbolo de sistema Una variante de ping es fping (www.fping.com), un programa que permite especificar en la lnea de comandos ms de un host destino o un bien fichero con una lista de todos los hosts destino. En el ejemplo de la Figura 5.5 el host destino responde a los cuatro mensajes ICMP recibidos desde el host origen. A continuacin de ping se suele teclear la direccin IP del host destino, aunque tambin puede escribirse su nombre. Por ejemplo: C:\> ping www.mcgraw-hill.com Cuando el host destino no responde a los mensajes ICMP la pantalla muestra un mensaje como el de la Figura 5.6.

Pero la utilizacin de ping no se encuentra exenta de problemas, ya que ping depende del protocolo ARP que convierte la direccin IP en una direccin MAC y de los servidores DNS que convierten un nombre de dominio en una direccin IP. Si estos fallan, ping tambin falla. Adems, por razones de seguridad, muchos administradores bloquean en los servidores la respuesta a mensajes ICMP en general o a ECHO_REQUEST en particular. Se debe a que a veces el comando ping es utilizado por usuarios malintencionados para perpetrar sobre los servidores ataques DoS (Denial of Service) consistentes en envos masivos de mensajes ICMP que degradan el rendimiento de la red.

96 05

5. Protocolo TCP/IP
5.2 Arquitectura del protocolo TCP/IP

Caso prctico 1
En este Caso prctico veremos distintas formas de emplear el comando ping y tambin cmo interpretar los resultados obtenidos al ejecutarlo. Las pruebas se realizarn sobre una pequea red de rea local conectada a Internet, cuyo esquema se representa en la Figura 5.7. En nuestra red de ejemplo aparecen tecnologas tanto cableadas (Ethernet 100BaseT) como inalmbricas (802.11). Todos los equipos de la red LAN tienen instalado Windows XP. La red cableada est compuesta por los ordenadores E1 y E2, el punto de acceso AP (Access Point) y el router. Bajo la cobertura del AP dos ordenadores porttiles P1 y P2 se integran en la red. Las direcciones IP de todos los equipos mencionados pertenecen a la red 192.168.135.0, si bien en el caso del router tambin se indica la direccin IP asignada al interfaz el que se conecta a la red Internet.
P1 Servidor web

198.45.24.246

Internet

192.168.135.100

80.103.12.163 Router AP 802.11 192.168.135.50 100BaseT 192.168.135.0 192.168.135.254

P2

192.168.135.101 E1 E2

192.168.135.10 Fig. 5.7. Esquema de la red propuesta.

192.168.135.11

Para probar si funciona bien la conexin a Internet, se ha buscado un servidor remoto que permita procesar solicitudes de eco entrante ICMP (ECHO_REQUEST). Es importante pues cada vez ms equipos conectados a Internet establecen mecanismos de proteccin (cortafuegos) para evitar ataques externos. Las comprobaciones se harn dentro de la capa de red. Su objetivo fundamental ser el de establecer la conectividad entre equipos dentro de esta capa, as como la calidad de la misma.
ECHO REPLY ECHO REQUEST

Comenzaremos con la red cableada. Para ello lo ms adecuado ser hacer un ping desde E1 y E2 al router. La Figura 5.8 muestra el resultado obtenido al ejecutar el comando desde el ordenador E1. Como se puede apreciar el router responde correctamente a todas las peticiones hechas desde E1, y adems lo hace en un tiempo razonable, siendo la media de menos de 1 ms. Una vez que sabemos que la conexin est dentro de los valores adecuados ejecutamos de nuevo el comando ping desde E1; en esta ocasin se trata de comprobar que el router puede enviar los mensajes ICMP a un equipo perteneciente a otra red. La Figura 5.9 muestra los resultados obtenidos.

Router E1 192.168.135.10 Fig. 5.8. Prueba de conectividad entre E1 y el router. 192.168.135.254

97 05

5. Protocolo TCP/IP
5.2 Arquitectura del protocolo TCP/IP

Caso prctico 1 (cont.)

ECHO REPLY ECHO REQUEST

ECHO REPLY ECHO REQUEST

Servidor web E1 192.168.135.10 E1 192.168.135.10

P1 192.168.135.100

198.45.24.246

Fig. 5.9. Resultados desde E1 a un servidor web externo.

Fig. 5.10. Prueba desde la red inalmbrica a la cableada.

De nuevo se obtiene una respuesta positiva para los cuatro paquetes de datos enviados, si bien en esta ocasin los tiempos de ida y vuelta son muy superiores a los del caso anterior. Esto no indica ninguna anomala. Un tiempo medio de respuesta de 214 ms para un equipo

remoto entra dentro de lo normal. Tngase en cuenta que para ello los paquetes de datos han realizado varios saltos de una red a otra hasta alcanzar su objetivo y luego deben volver al origen. Las dos comprobaciones anteriores se deben repetir desde el ordenador E2. Con ello tendremos la certeza de que los equipos conectados a la red cableada funcionan en la capa de red. An resta por comprobar si el punto de acceso inalmbrico responde correctamente a las pruebas ping, pero esto queda indirectamente resuelto si enviamos un ping desde uno de los porttiles al ordenador E1 (vase la Fig. 5.10). Para que los paquetes de datos enviados por P1 puedan llegar al E1 deben pasar a travs del AP (192.168.135.50). Por tanto, si E1 recibe datos y los devuelve a P1, hemos constatado al mismo tiempo que el AP funciona en la capa de red. No obstante el tiempo medio de respuesta que se observa no es el ptimo, pues 6 ms es un valor un poco alto. Para despejar dudas hacemos otra prueba, esta vez entre los dos equipos de la red inalmbrica (vase la Fig. 5.11). El valor medio de respuesta entre P1 y P2 sigue siendo un poco elevado (9 ms). Con todo lo visto se puede afirmar sin duda que la conectividad en red entre todos los equipos es la adecuada, pero que los tiempos de respuesta cuando est implicado P1 son un poco lentos. Esto podra obedecer a una mala configuracin de la red inalmbrica, aunque esta hiptesis queda descartada porque al hacer un ping desde P2 al router (o a cualquiera de los ordenadores E1 o E2) los tiempos medios de respuesta que se obtienen son de 2 ms.

Mensajes ICMP ECHO REPLY ECHO REQUEST 192.168.135.100

P2 192.168.135.101 Fig. 5.11. Prueba entre equipos de la red inalmbrica. P1

98 05

5. Protocolo TCP/IP
5.2 Arquitectura del protocolo TCP/IP

Caso prctico 1 (cont.)

Parece claro que el problema se localiza en el porttil P1, ya que tanto la electrnica de red cableada como la inalmbrica funcionan correctamente. Pero si P1 devuelve y enva los mensajes ICMP, por qu los tiempos de ida y vuelta son tan lentos? Antes de responder volvamos e ejecutar el comando ping, esta vez desde P2 a P1 (vase la Fig. 5.12). Ahora ya no hay dudas: si los mensajes enviados por P2 tardan una media de 234 ms en regresar a P1, hay algo en P1 que no funciona bien. Debemos comprobar la configuracin del adaptador de red inalmbrico. No estamos hablando del canal de radio empleado o de la clave WEP elegida; como ya sabemos, si estos valores no son los mismos en P1 y en el AP, no habra siquiera conectividad. Pero s es cierto que muchos porttiles trabajan con rendimientos mnimos para ahorrar energa, y que hay puntos de acceso que no se llevan bien con esta tctica. En nuestro caso P1 tiene un procesador Intel Centrino, que por defecto funciona con valores mnimos de rendimiento para ahorrar batera. Abrimos el cuadro de Estado de conexiones de red inalmbricas de Windows XP y hacemos la siguiente seleccin: Propiedades > Configurar > Avanzadas > Gestin de alimentacin Desmarcamos el valor predeterminado (Mnimo) y movemos el cursor hasta la posicin Mximo. El problema desaparecer.

Mensajes ICMP ECHO REPLY ECHO REQUEST 192.168.135.100

P2 192.168.135.101 Fig. 5.12. Tiempos de ida y vuelta excesivamente lentos. P1

C. Capa de transporte
0 4 8 12

Bits 16 20 24 28 31

En esta capa se encuentran definidos el protocolo TCP y el protocolo UDP (User Datagram Protocol). TCP permite enviar los datos de un extremo a otro de la conexin con la posibilidad de detectar errores y corregirlos. UDP, por el contrario, reduce al mximo la cantidad de informacin incluida en la cabecera de cada datagrama, ganando con ello rapidez a costa de sacrificar la fiabilidad en la transmisin de datos. La Figura 5.13 muestra el formato de un mensaje UDP. Ciertas aplicaciones prefieren utilizar en la capa de transporte el protocolo UDP aunque ste no haga correccin ni deteccin de errores. Como estas aplicaciones necesitan transmitir pequeas cantidades de datos, resulta ms eficaz reenviar los datagramas defectuosos que no sobrecargar cada uno con informacin de control en la cabecera. Si se requiere ms fiabilidad en los datos transmitidos las aplicaciones recurren en la capa de transporte al protocolo TCP. Al revs que UDP, es un protocolo orientado a conexin, y el formato de los datos que maneja es muy distinto al de los datagramas. Para TCP los datos son una secuencia o trama continua de bytes, cada comunicacin es seleccionada en la trama mediante segmentos. En la Figura 5.14 (vase la pg. 100) vemos el formato de un segmento TCP.

Palabras

1 2

Puerto origen Longitud

Puerto destino Cabecera Checksum

Los datos comienzan a partir de aqu...

Fig. 5.13. Representacin del formato de mensaje UDP.

El protocolo TCP necesita que se establezca una conexin entre los equipos situados en ambos extremos de la misma. Antes de iniciar la transferencia de datos TCP efecta una negociacin entre los dos equipos basada en el intercambio de tres segmentos de datos. Precisamente por esta razn se la conoce como negociacin de tres vas. La Figura 5.15 (vase la pg. 100) representa las fases de una negociacin de tres vas entre dos equipos a los que llamaremos host A y host B. La primera iniciativa la tiene el host A, quien enva al host B un segmento de sincronizacin (SYN) que contiene un identificador numrico. Al recibir esta informacin, el host B tiene constancia de la intencin de iniciar una comunicacin por parte del

99 05

5. Protocolo TCP/IP
5.2 Arquitectura del protocolo TCP/IP

12

16

20

24

28

31

ten. Esta operacin se conoce como multiplexacin. En apartados posteriores se estudiar con ms detalle la multiplexacin de datos.

Puerto origen Nmero de secuencia

Puerto destino

D. Capa de aplicacin
sta es la capa ms alta dentro de la estructura jerrquica del protocolo TCP/IP (vase la Fig. 5.1), e incluye las aplicaciones y procesos con los que intercambia datos la capa de transporte. TCP/IP tiene en esta capa protocolos que soportan servicios de conexin remota, correo electrnico y transferencia de archivos. De todos los protocolos de aplicacin los ms conocidos son: Telnet (Network Terminal Protocol). Es un protocolo que permite establecer conexiones con terminales remotos, de tal manera que se puedan ejecutar en ellos comandos de configuracin y control. FTP (File Transfer Protocol). Protocolo orientado a conexin dedicado a la transferencia de archivos. FTP ofrece una gran fiabilidad con este servicio, en gran parte debido a que se basa en el protocolo TCP dentro de la capa de transporte. TFTP (Trivial File Transfer Protocol) es una versin de FTP que funciona ms rpido, pero es menos fiable porque se sirve de mensajes UDP en la capa de transporte. SMTP (Simple Mail Transfer Protocol). Posibilita el funcionamiento del correo electrnico en las redes de ordenadores. SMTP recurre al protocolo de oficina postal POP (Post Office Protocol) para almacenar mensajes en los servidores de correo electrnico. Existen dos versiones: POP2, que necesita la intervencin de SMTP para enviar mensajes; y POP3, que funciona de forma independiente. HTTP (Hipertext Transfer Protocol). Es un estndar de Internet que permite la transmisin de gran variedad de archivos de texto, grficos, sonidos e imgenes. HTTP regula el proceso mediante el cual navegadores como Netscape, Mozilla o Internet Explorer solicitan informacin a los servidores web. DNS (Domain Name Service). Esta aplicacin convierte nombres de dispositivos y de nodos de red en direcciones IP. Por ejemplo, el nombre www.mcgraw-hill.es, se convierte en la direccin 198.45.24.91.
Cabecera

Nmero de reconocimiento (ACK) Offset Reservado Flags Direccin origen Puntero de urgencia Opciones Los datos comienzan a partir de aqu... Padding

Fig. 5.14. Campos de cabecera para un segmento TCP.

Host A Fig. 5.15. Negociacin de tres vas en el protocolo TCP.

Host B

SYN
SYN, ACK ACK, dato

host A y, adems, gracias al identificador numrico recibido, conoce el punto exacto en el que el host A seala el inicio de su transmisin de datos. En segundo lugar el host B responde al host A con un segmento de confirmacin (ACK) y lo acompaa del identificador que l emplear en la conexin. La negociacin finaliza con xito cuando el host A recibe esta confirmacin y responde con otra, que ya va acompaada de los primeros datos. Los identificadores numricos de secuencia son fundamentales para que TCP pueda determinar dentro del flujo continuo de bytes el segmento correspondiente a la comunicacin entre los equipos A y B. Al margen de estas negociaciones, la capa de transporte es responsable de hacer llegar los datos a las aplicaciones que los requieren en las capas superiores. Para ello se asocia cada aplicacin a un nmero de 16 bits al que se denomina nmero de puerto. Tanto TCP como UDP hacen que la primera palabra de sus cabeceras contenga el puerto origen y destino de los datos que se transmi

Los servidores de red proporcionan servicios esenciales para las comunicaciones entre ordenadores. A diferencia de lo que ocurre con muchos programas de aplicacin, estos servicios no facilitan el acceso al usuario final. Para ms informacin se aconseja consultar el estndar RFC 1122.

100 05

5. Protocolo TCP/IP
5.3 Direccionamiento IP

5.3 Direccionamiento IP
Hasta el momento nos hemos referido con frecuencia a las direcciones IP, que son nmeros de 32 bits que constituyen la direccin unvoca de todo dispositivo conectado a una red que funcione con el protocolo TCP/IP. Las direcciones IP se escriben mediante la denominada notacin punto decimal, o de cuatro octetos. Con el fin de facilitar el manejo de las direcciones IP, los 32 bits se dividen en cuatro grupos de 8 bits cada uno, y cada uno de estos bytes se traduce a su equivalente en decimal. De cada conversin resulta un nmero comprendido entre 0 y 255. Estos cuatro nmeros se escriben separados entre s por un punto (vase la Fig. 5.16). Las direcciones IP proporcionan dos datos: el nmero de red y el nmero de host. Para que un sistema pueda transmitir datos debe determinar con claridad la direccin destino de red y host, adems de poder informar al resto de sistemas de cul es su propia direccin de red y host. Los sistemas de red se pueden direccionar de tres formas:
8bits 8bits 01000001 8bits 01011110 8bits 01110000

que la direccin de red es 198.16.23 y la direccin de host 102. Como la cifra 0 en el campo de host est reservada para identificar la red, la direccin de red tambin se escribe: 198.16.23.0 Como el prefijo determina la parte de la direccin IP destinada a identificar la red, los bits disponibles para direcciones de hosts se obtienen restando a 32 la longitud del prefijo. Un ejemplo: la direccin 192.168.10.0/20 destina 12 bits para direccionar hosts (32 20 = 12). Por tanto, la red 192.168.0 dispondr de un bloque de 12 bits de direcciones (212 = 4 096), de la direccin 0.1 a la 15.254, estando reservadas las direcciones 0.0 y 15.255 a red y difusin respectivamente.
32 bits

11000000010000010101111001110000

Unicast. Los paquetes de datos tienen como destino la direccin de un nico host. Multicast. Los datos se pueden enviar de forma simultnea a un determinado conjunto de hosts. Broadcast. Direccin de difusin que permite enviar datos a todos los sistemas que forman parte de una red. Este tipo de direccionamiento est siempre supeditado a las capacidades fsicas de los dispositivos conectados en la red.

11000000

192

65 192.65.94.112

94

112

Fig. 5.16. Distintas formas de representar una direccin IP.

El nmero de bits empleado para definir la red y el nmero de bits que identifican al host pueden variar entre unos casos y otros. Cada direccin IP tiene un prefijo cuya longitud indica qu bits corresponden al identificador de red y cules al host. La longitud de este prefijo la establecen los bits de la direccin de mscara. ste es el funcionamiento de los bits de mscara: si un bit de la mscara es 1, su bit equivalente en la direccin IP corresponde a la direccin de red. Si un bit de la mscara es 0, el bit equivalente en la direccin IP pertenece a la direccin de host. Tal como se puede ver en la Figura 5.17 la direccin IP 198.16.23.102 tiene asociada la mscara 255.255.255.0, o lo que es lo mismo, tiene un prefijo de 24 bits, por lo que la direccin de host utiliza los 8 bits restantes. La forma abreviada para la direccin y prefijo sera: 198.16.23.102/24. Aplicando la mscara de red (es decir realizando la operacin lgica AND entre ambas), resulta

32 bits

11000110

198 AND

00010000

16

00010111

23

01100110

102

AND

AND

AND

11111111

255

11111111

255

11111111

255

00000000

198

16 198.16.23

23

0 102

24 bits Direccin de red Fig. 5.17. Solucin de direcciones de red y host.

8 bits Direccin de host

101 05

5. Protocolo TCP/IP
5.3 Direccionamiento IP

Clases de direcciones IP
Aunque existen cinco, son tres las principales clases de direcciones IP: A, B y C. El protocolo IP distingue la clase a la que pertenece una direccin analizando el valor de sus bits de mayor peso. El concepto de clase est asociado al de mscara por defecto. Para determinar la clase de una direccin IP se siguen las siguientes reglas: Clase A. Si el bit de mayor peso es 0 la mscara por defecto tendr un prefijo de 8 bits. Se tienen por tanto 8 bits para direcciones de red y 24 bits hosts. Clase B. Si los dos primeros bits son 1 0, la mscara por defecto tendr una longitud de 16 bits (prefijo 16). Con ello los primeros 16 bits son para identificar la red; los 16 ltimos, para identificar los hosts. Clase C. Si los tres primeros bits son 1 1 0 la mscara por defecto tiene un prefijo de 24 bits. Para esta clase se contempla la existencia de una gran cantidad de redes, en concreto 224. En cada una de ellas el nmero de equipos es como mximo 253, una vez restadas las direcciones de red y difusin. Clase D. Si los cuatro primeros bits de la direccin son 1 1 1 0 nos encontramos frente a una direccin multicast. Entonces, no se habla de una direccin de red, sino de un grupo de equipos a los

que se desea enviar datos simultneamente. Todos los bits de una direccin multicast son significativos, as que la mscara por defecto es de 32 bits (prefijo 32). Clase E. Si los cuatro primeros bits de la direccin son unos lgicos, la direccin IP pertenece a un rango que se ha reservado para experimentacin. Dentro de esta clase aparece la direccin IP de difusin 255.255.255.255.

Las reglas descritas se refieren al anlisis de direcciones IP representadas en binario. Pero como siempre se trabaja con direcciones IP escritas en notacin punto decimal, se emplea con mayor frecuencia otra tcnica consistente en analizar la primera cifra segn estas reglas: Si el primer octeto es menor de 128, la mscara por defecto es de 8 bits (clase A, 255.0.0.0). La excepcin a esta regla la tenemos en la red 127.0.0.0, que se ha reservado al completo para la direccin especial 127.0.0.1. sta es la direccin de reenvo o bucle cerrado (loopback), y sirve para que un host compruebe si su NIC funciona correctamente en el protocolo IP. Si la primera cifra decimal est comprendida entre 128 y 191, la mscara por defecto tendr un prefijo de 16 bits (clase B, 255.255.0.0).

Caso prctico 2
S1 192.168.15.80

Estudiaremos un caso real de segmentacin IP de una red mediante la creacin de subredes. En la Figura 5.18 se muestra una red de clase C con direccin 192.168.15.0/24 que est compuesta por varios equipos con conexiones cableadas e inalmbricas. El trfico de red detectado es el siguiente: los equipos desde E1 a E4 utilizan con frecuencia el equipo multifuncin MF1 y leen y escriben archivos en el servidor S1, quien adems almacena copias de seguridad de ellos. Los porttiles que acceden a la red a travs del punto de acceso AP1 utilizan exclusivamente un servicio FTP configurado en el servidor S2.

MF1 192.168.15.25

S2 192.168.15.150

AP1 192.168.15.135 192.168.15.0/24

E1 192.168.15.10 E2 192.168.15.11 E3 192.168.15.12

P2 192.168.15.140

P1 192.168.15.141

E4 192.168.15.14

Fig. 5.18. Esquema de la red propuesta para el Caso prctico.

102 05

5. Protocolo TCP/IP
5.3 Direccionamiento IP

Caso prctico 2 (cont.)

Subred 2 192.168.15.128/25

De este comportamiento del trfico de red se deduce que a pesar de que todos los equipos estn concentrados con la misma electrnica de red, resulta viable dividir la red en dos subredes independientes respecto del protocolo IP. Para obtener dos subredes basta con ampliar el prefijo en un bit, razn por la que en todos los equipos se cambiar la mscara de subred a 255.255.255.128 (vase Fig. 5.19). Las subredes creadas admiten cada una de ellas 126 direcciones de host, que son: Subred 1 (192.168.15.0). Comprende todos los hosts con direcciones entre 1 y 126. Esto incluye el servidor S1, el equipo multifuncin MF1 y los ordenadores E1 a E4. La direccin de difusin de la subred 1 ser 192.168.15.127. Subred 2 (192.168.15.128). A ella pertenecen todos los hosts con direcciones entre 129 y 254. Lo cual afecta al punto de acceso AP1, a los equipos porttiles y al servidor S2. La direccin de difusin es 192.168.15.255.

Subred 1 192.168.15.0/25 MF1 S1 S2

AP1

P1 P2 E1 E2 E3 E4

Fig. 5.19. Direcciones y prefijos para crear dos subredes.

Verificamos la segmentacin de redes realizando pruebas de conectividad. La respuesta entre equipos de la misma subred ser la correcta (vase la Fig. 5.5). La Figura 5.20 muestra el mensaje que debe visualizarse en cualquier equipo de la subred 1 cuando lanza un mensaje ICMP a otro equipo de la subred 2, en este caso a P2. Lo mismo suceder si un equipo de la subred 2 ejecuta el comando ping hacia otro de la subred 1 (vase la Fig. 5.21). Hay que tener en cuenta que ping da como respuesta Host de destino inaccesible, porque el equipo desde el que se ejecuta no tiene configurada una puerta de acceso.

Fig. 5.20. Ping desde la subred 1 a la subred 2.

Fig. 5.21. Ping desde la subred 2 a la subred 1.

103 05

5. Protocolo TCP/IP
5.3 Direccionamiento IP

Desde 192 a 223 la mscara por defecto tiene un prefijo de 24 bits (clase C, 255.255.255.0). Desde 224 a 239 la direccin IP es multicast, y la mscara por defecto tendr una longitud de 32 bits (clase D, 255.255.255.255).
De 240 a 255 las direcciones IP son de uso experimental. No se asignan a ningn sistema o red concreto.

Dependiendo de la clase de red y del nmero de veces que se pretenda segmentar, se obtienen una serie de direcciones vlidas. La directiva RFC 1878 contiene una lista con todas las posibles combinaciones y direcciones vlidas. En la Figura 5.18 se han utilizado dos bits del bloque de direcciones de red para definir subredes. De ello se desprende que los seis bits restantes sirven para definir un bloque de 64 direcciones (2 (8 2) = 64) de hosts, del que, como ya se sabe, la primera y la ltima estn reservadas para identificar la subred y la direccin de difusin. De la operacin AND entre la direccin 192.168.12.102 de ejemplo, y la mscara de subred 255.255.255.192, se obtiene que pertenece a la subred 1 (01) con direcciones vlidas que oscilan entre 192.168.12.65 y 192.168.12.126. El equipo con esta direccin slo es capaz de resolver las direcciones que se encuentran dentro de este rango. Se podran plantear otros nmeros de host como ejemplo: 192.168.12.10 AND 255.255.255.192 da como resultado que pertenece a la subred 0 (00) con direcciones posibles entre 192.168.12.1 y 192.168.12.62. 192.168.12.204 AND 255.255.255.192 resulta que pertenece a la subred 3 (11) con direcciones comprendidas entre 192.168.12.193 y 192.168.12.254, ambas inclusive.

Subredes
La estructura de una direccin IP puede ser localmente modificada al destinar parte de los bits de direccin de host para bits de red adicionales o de subred. La creacin de subredes reduce el nmero posible de hosts que pueden existir en una de ellas. Los bits de subred definen un nuevo bloque de direcciones dentro del bloque de direcciones de red. En el ejemplo de la Figura 5.22 podemos apreciar cmo dentro de la red de 192.168.12.0/C se crean cuatro subredes. Para conseguirlo se aumenta en dos bits la longitud del prefijo, haciendo que pase de 24 a 26 bits. Si lo vemos desde el punto de vista de la mscara de red tendremos que pasa de ser 255.255.255.0 a 255.255.255.192. Con estas cuatro subredes se puede mejorar la eficiencia de la red, pues queda restringido el trfico de datos al mbito local, y cada una de ellas tendr adems una direccin nica.

La eficiencia referida consiste en que cuando un equipo de la subred 1 enva un paquete de datos, ste es atendido slo por los dems equipos de la subred 1. Los de las otras subredes ignoran este trfico de datos y se concentran en el suyo propio. Esto se traduce en un mejor aprovechamiento del ancho de banda de la red.
192
11000000

Red 192.168.12 192.168.12.255 Subred 3 192.168.12.192 192.168.12.192 192.168.12.191 Subred 2 192.168.12.128 192.168.12.128 192.168.12.127 Subred 1 192.168.12.64 192.168.12.64 Fig. 5.22. Cuatro subredes dentro de una red de clase C. 192.168.12.63 Subred 0 192.168.12.0 192.168.12.0 Mscara de subred: 255.255.255.192 192.168.12.102 Subred 1 Host 102 26 Bits 11000000 10101000 00001100 6 Bits 01 000000 168
10101000

12
00001100

102
01100110

AND

AND

111111111

11111111

AND

11111111

11

104 05

AND

000000

5. Protocolo TCP/IP
5.4 Tablas de enrutamiento

5.4 Tablas de enrutamiento

Como ya se ha dicho en otras ocasiones la puerta de enlace de una LAN permite enviar datos a otras redes distintas a la de origen. Encaminar o enrutar (ambos trminos son vlidos) los datos es el principal cometido de estos dispositivos. La decisin de a quin se envan los datos no es patrimonio exclusivo de los routers. En la prctica, un host est continuamente tomando decisiones sobre adnde enva los datos. La lgica de decisin se resume en dos puntos: Si se constata que el host destino se encuentra en la misma red que el host origen, los datos son enviados directamente, de host a host, sin intermediarios. La otra posibilidad es que la direccin del host destino no pertenezca al mismo bloque de direcciones IP que el host origen. En este caso los datos se envan a la puerta de enlace de la red local, y ser este router quien los encamina a partir de que los recibe en uno de sus puertos.
Fig. 5.23. Tabla de rutas mostrada por el comando netstat.

Tal como se mostraba en el Caso prctico 2, cuando no se introduce en la configuracin de un equipo la direccin de la puerta de enlace, la direccin destino de otras redes resulta inaccesible para el sistema y los datos no se envan. Los hosts consultan una tabla interna de enrutamiento cuyo estado puede mostrarse con el comando netstat. La Figura 5.23 ofrece un ejemplo tpico de tabla de rutas. En este caso netstat se ha ejecutado desde un equipo con el sistema operativo Windows XP. En otros sistemas la tabla puede tener otro aspecto, pero en esencia ofrecer la misma informacin. Netstat -nr garantiza que las direcciones se vean con la notacin punto decimal. La tabla de rutas de la Figura 5.23 muestra en primer lugar una lista con los adaptadores de red detectados en el equipo. En este caso slo hay uno con MAC 00-0c-6e2b-49-66 y otro virtual para pruebas de reenvo a la direccin de bucle cerrado 127.0.0.0; a continuacin aparecen las rutas activas clasificadas en cinco columnas cuyos valores son consultados cada vez que se quiere enviar un dato: Destino de red. El destino puede ser un host o una red completa. Para buscar la ruta adecuada se trabaja con el dato de la siguiente columna de mscara de red. La bsqueda se realiza priorizando las rutas nicas sobre las genricas. Por ejemplo: 192.168.135.0 es una direccin de subred, 224.0.0.0 es multicast y 192.168.135.10 una direccin cuyo nico destino es un host.

Mscara de red. Permite diferenciar la parte de la direccin destino que se refiere a red de la de host. En el caso particular 255.255.255.255 las direcciones destino de red y host son coincidentes. Por ejemplo: si el destino de un paquete de datos es la direccin del propio host que los enva (192.168.135.10) o la direccin de difusin de la red a la que pertenece (192.168.135.255). Puerta de acceso. Aqu se especifica la direccin IP del dispositivo al que se debe enviar el paquete de datos despus de detectar una coincidencia con los valores anteriores. Por ejemplo: si el destino est en la propia red (192.168.135.0) del host (192.168.135.10) su propia interfaz es la puerta de acceso al medio; si el destino es la direccin del host (192.168.135.10) la interfaz a la que se recurre es la de bucle cerrado (127.0.0.0); y si no hay coincidencias de destino (0.0.0.0) la puerta de acceso designada es la de la puerta de enlace predeterminada (192.168.135.254). Interfaz. Direccin IP del adaptador de red encargado de enviar el paquete de datos en la ruta designada. Mtrica. Nmero mximo de saltos hasta alcanzar el destino. Por ejemplo: cuando la ruta es la de bucle cerrado la mtrica es 1; para el resto aparece asignado el valor 20 por defecto.

105 05

5. Las comunicaciones urgentes

5.4 Tablas de enrutamiento

Caso prctico 3
Vamos a estudiar las tablas de rutas de los sistemas ya vistos en el Caso prctico 2, si bien en esta ocasin entra en juego un router que realiza la interconexin a Internet de la red. Se da por supuesto que en todos los ordenadores el sistema operativo instalado es Windows XP. Al seguir manteniendo la segmentacin en dos subredes, cabe preguntarse qu direccin IP se debe asignar al router. La respuesta depende de qu equipos se pretenda que tengan acceso a Internet. Si como parece ms lgico se facilita el acceso a todos los equipos, la direccin IP del router no puede circunscribirse a una de las subredes. La Figura 5.24 muestra una posible solucin: La direccin IP 192.168.135.254/24 otorga al router la capacidad de resolver la direccin de cualquier host comprendido entre 1 y 254, lo cual le sita tanto en el dominio de enrutamiento de la subred 1 como en el de la subred 2. En cuanto a los equipos dentro de las subredes, tenemos que en todos ellos se ha tenido que especificar la direccin IP del router como puerta de enlace predeterminada. Esto se traduce en que las tablas de rutas en cada uno de ellos se ven modificadas de forma automtica con la aparicin de nuevas entradas. En un equipo de la subred 1, por ejemplo E1 (192.168.15.10), tecleamos en la ventana de smbolo de sistema el comando: route print. La tabla de rutas que aparecer se muestra en la Figura 5.25. La primera entrada nos informa de que los paquetes de datos para los que no exista coincidencia son enviados al router a travs el nico adaptador de red disponible con mtrica 30. La tercera entrada de la tabla determina que cuando la red destino sea la subred 1, los datos son enviados directamente, sin que salgan de la subred (no emplea al router como puerta de enlace). Es interesante fijarse en que no aparece ninguna ruta que haga referencia a la subred 2: si un equipo de la subred 1 intenta enviar datos a la subred 2, no sucede que el destino sea inalcanzable. Ahora estos datos se envan al router y l se encarga de resolver la direccin destino. As la eficiencia en el trfico de red se mantiene, pues los mensajes para equipos de una misma subred no son encaminados o replicados a la otra. La Figura 5.26 corresponde con la tabla de rutas que presenta el equipo P2 (192.168.15.140) en la subred 2. Se aprecia que P2 tiene dos adaptadores de red, y que el Ethernet no ha sido configurado en el protocolo IP. El resto de explicaciones es similar al de la Figura 5.25.

Internet

192.168.15.254/24 S1 R1 S2

MF1

AP1 P1 P2 E1 E2 E3 Subred 1 E4 192.168.15.0/25 Subred 2 192.168.15.128/25

Fig. 5.24. Conexin a Internet de dos subredes.

Fig. 5.25. Tablas de ruta de un equipo en la subred 1.

Fig. 5.26. Tablas de ruta de un equipo en la subred 2.

106 05

5. Las comunicaciones urgentes

5.4 Tablas de enrutamiento

Tambin se puede obtener la tabla de rutas con el comando route: basta con teclear a continuacin del smbolo de sistema: route print. La informacin visualizada ser la misma que con netstat r. No obstante, la verdadera utilidad de route se encuentra en su capacidad de aadir o eliminar entradas en la tabla de rutas de un sistema. Estas entradas no persisten al reiniciar el sistema.
Fig. 5.27. Tabla ARP con una sola entrada.

Resolucin de direcciones
El resultado de combinar las direcciones IP y la informacin contenida en las tablas de rutas consiste en que los datos pueden recorrer distintas redes hasta llegar al destino especfico. Sin embargo, las capas inferiores de la red no procesan ni entienden esta informacin. En la capa fsica no se distingue entre redes y equipos. Para este nivel la nica informacin vlida es la de la direccin fsica de cada adaptador de red, conocida como direccin MAC, y que se analiz en la Unidad 4. Cuando los datos llegan a la capa ms baja, hay que encargarse de asociar las direcciones IP con las direcciones MAC. sta es la principal labor del protocolo ARP. Cada host mantiene en la memoria cach de su adaptador de red una tabla de equivalencias entre direcciones IP y direcciones IP. El contenido de esta tabla se puede ver al introducir en lnea de comandos la orden: arp a. La Figura 5.27 muestra un ejemplo bsico de tabla ARP. Del cual se debe deducir que cuando el host 192.168.135.10 quiere enviar sus paquetes de datos a travs de su adaptador de red al host 192.168.135.254, traduce la direccin destino de su formato IP al formato MAC 00-a0-f9-02-a794. Y es ste el que se enva en las tramas Ethernet. Cuando no se encuentra la equivalencia del host destino en la tabla ARP, el host origen enva a todos los equipos de su red una peticin ARP. A esta peticin responde el propio equipo aludido o un equipo capaz de resolver direcciones IP en direcciones MAC, por ejemplo la puerta de enlace de la red. La respuesta a la consulta es almacenada de forma automtica en la tabla ARP del host origen. Cuando una entrada es creada de esta forma es clasificada como dinmica y todo este proceso sucede sin que las capas superiores del protocolo TCP/IP tengan que estar pendientes de l. Tambin es posible crear manualmente una entrada en estas tablas mediante el comando arp. Por ejemplo:
C: \> arp s 192.168.135.100 00-0c-f1-03-c9-4d

Fig. 5.28. Proceso de registro de una entrada dinmica.

nar. Se puede obtener ms informacin sobre el comando arp tecleando en lnea de comandos arp /?. La Figura 5.28 representa en dos pasos cmo se aade una entrada dinmica a una tabla ARP. En primer lugar se enva un paquete de 32 bytes con el comando ping, para conseguir que el host destino se identifique y notifique su direccin MAC. Al visualizar en el segundo paso la tabla ARP se aprecia que esta respuesta ha sido registrada como una entrada dinmica. Los comandos arp y ping pueden utilizarse conjuntamente para solucionar problemas en la red. La Figura 5.29 muestra que al enviar un mensaje ICMP al host 192.168.135.60, no se obtiene respuesta a la solicitud de eco. Lo ms lgico sera pensar que el equipo no se encuentra conectado a la red. Sin embargo, para asegurarnos de que esto es as visualizamos la tabla ARP. Es entonces cuando vemos que la direccin del host destino ha sido asociada a su direccin MAC generando una entrada dinmica. Por tanto, podemos concluir que el equipo 192.168.135.60 s est conectado a la red, y que probablemente su administrador ha instalado un filtro para no responder a mensajes ICMP.

Para borrar entradas la orden sera arp d seguida de la direccin o grupo de direcciones que se pretendan elimi-

107 05

5. Las comunicaciones urgentes

5.4 Tablas de enrutamiento

Determinar la traza de una ruta

La conexin de redes con enrutadores tal como se hace en Internet, trae consigo que las conexiones entre equipos locales y remotos involucren a gran cantidad de sistemas. Hasta ahora hemos estudiado el funcionamiento de comandos que realizan pruebas de conectividad, imprimen tablas de enrutamiento o resuelven direcciones IP. El comando tracert engloba todas estas funcionalidaFig. 5.29. Solucin de problemas de red con ping y arp.

des y adems nos informa del camino exacto que siguen los paquetes de datos desde el host local al host remoto. Un ejemplo tpico lo encontramos cuando un ordenador se conecta a una pgina web (p. ej.: www.mcgraw-hill.com). Qu camino recorren realmente los paquetes de datos? En la representacin grfica de la Figura 5.30 se observa con detalle la respuesta a esta pregunta. Tracert enva paquetes de datos UDP desde el host local al host remoto, muestra el nombre de cada puerta de enlace (siempre que se haya configurado) y su direccin IP. Mientras se determina la traza, cada vez que es detectada una puerta de enlace activa, se numera y se registran sus datos en una entrada denominada salto. Por defecto se imprimen trazas con un mximo de 30 saltos. En cada salto se indica el tiempo que ha empleado cada paquete en ir y volver desde el host local a la puerta de enlace. La ejecucin de tracert puede finalizar bien por completarse la traza hasta el host destino o porque se haya superado el nmero mximo de saltos. Una traza incompleta proporciona informacin muy valiosa a la hora de resolver problemas de enrutamiento entre redes. Cuando se agotan los tiempos de espera para un paquete de datos, la localizacin del salto en el que se produce este retardo nos permite plantear una hiptesis ms acertada del problema. Por ejemplo:

192.168.1.254 62.36.196.21

192.168.1.0

net.uni2.es

62.36.196.234 opentransit.net

193.251.251.33 144.223.246.21 alter.net sprintlink.net 198.45.19.20 204.255.168.13 Fig. 5.30. Traza completa obtenida con el comando tracert.

108 05

5. Protocolo TCP/IP
5.5 Multiplexacin de datos

Si ya no hay respuesta en el salto 1, el problema lo tenemos en la puerta de enlace de nuestra propia red. Si la respuesta se pierde entre los saltos 2 y 4, quien est interrumpiendo la conexin es nuestro proveedor de acceso a Internet (en nuestro ejemplo, Uni2). En los saltos intermedios intervienen otras redes de trnsito de diferentes operadores. A veces se deja de tener respuesta porque estn congestionadas de

trfico. En estos casos es recomendable repetir la orden tracert pasado un tiempo. Si, por ltimo, el tiempo de respuesta se excede en el salto 21, es el servidor de la pgina web a la que pretendemos acceder quien se encuentra con problemas.

Tracert simboliza los tiempos de espera agotados imprimiendo el carcter * (asterisco) en lugar del tiempo en milisegundos.

5.5 Multiplexacin de datos

Cuando los datos pasan de la capa de transporte a la capa de aplicacin, resulta imprescindible indicar con exactitud a qu servicio de red estn destinados dichos datos. Esto es posible, entre otras cosas, por la coordinacin que realiza la autoridad de asignacin de nmeros en Internet IANA (Internet Assigned Numbers Authority), que mantiene un registro actualizado con los nmeros de puerto asignados a cada servicio de red. Para una informacin ms exhaustiva al respecto, se recomienda consultar el informe RFC 1700, en el cual se describe con todo detalle el proceso de asignacin de puertos para el protocolo TCP/IP. El nmero de puerto tiene un tamao de 16 bits y siempre se trabaja con dos nmeros: el primero es el nmero de puerto origen, que identifica al proceso que enva los datos; y el segundo es el nmero de puerto destino que identifica al puerto que los recibe. Ambos nmeros se sitan en la primera palabra de la cabecera tanto de los datagramas UDP como de los segmentos TCP. En la Figura 5.31 el host, al que se ha denominado pegasus, (192.168.1.100) est utilizando dos servicios de red. Por un lado mantiene una sesin telnet para configurar el router que acta como puerta de enlace de la red, y al mismo tiempo con su navegador ha accedido a una pgina web. Para conocer el estado de ambas conexiones se puede emplear el comando netstat de varias formas. La Figura 5.32 muestra dos de las ms empleadas. Ambos servicios trabajan con el protocolo TCP. El comando netstat ha sido ejecutado desde el host pegasus, por ello su direccin IP aparece siempre en la columna de direccin local. En la Figura 5.32 vemos que los puertos 23 (telnet) y 80 (http) son asociados a las direcciones de los host remotos, es decir, son puertos destino. Es necesario que exista tambin un puerto origen. En el host local se utiliza el puerto 1048 para la sesin telnet, y los puertos 1051 y 1052 para el servicio http. Segn la numeracin de los puertos se hace la siguiente clasificacin para los protocolos TCP y UDP: Los puertos con nmeros inferiores a 1.024 estn reservados para servicios muy definidos, como telnet, SMTP, POP3... Estas asignaciones son fijas y no pueden ser utilizadas por otros servicios. A menudo estos puertos son llamados puertos bien conocidos. Los puertos numerados entre 1024 y 49151 son puertos registrados. Significa que la IANA intenta ordenar el uso de este rango, pero sin las restricciones que existen para los puertos bien conocidos. Por ltimo, los puertos numerados entre 49152 y 65535 son puertos privados de los que se puede disponer para cualquier uso.
http:// www.google.es Telnet 192.168.1.1

El registro IANA puede ser consultado en la pgina web de esta organizacin: www.iana.org/assignments/ port-numbers/

66.102.9.104

Internet

192.168.1.1

pegasus 192.168.1.100

gunilde 192.168.1.11

1048

23

1051

80

Puerto origen Puerto destino Segmento telnet

Puerto origen Puerto destino Segmento http

Fig. 5.31. Puertos origen y destino en segmentos TCP.

109 05

5. Protocolo TCP/IP
5.5 Multiplexacin de datos

Aplicacin kaaza MSN Messenger VNC CU-SeeMe WinGate 2.1 HTTP alternativo Quake

Puerto TCP 1214 1863 5800+ y 5900+ 7648 y 7649 8010 8080 26000 a 28000

Puerto UDP 1214

7648 a 7652, 24 032 8080

Tabla 5.2. Ejempos de puertos registrados.

Fig. 5.32. Resultados impresos para netstat n y netstat.

Algunas aplicaciones reservan distintos nmeros de puerto, como por ejemplo CU-SeeMe, que recurre a puertos TCP y UDP. Otras utilizan puertos consecutivos a partir de un nmero concreto, como hace el programa VNC (desde los puertos 5800 y 5900). Y las hay que requieren rangos con miles de puertos (vase el ejemplo del juego Quake, desde el puerto 26000 al 28000).

Aplicacin Puerto TCP Puerto UDP FTP Telnet SMTP DNS TFTP HTTP POP3 NetBIOS SNMP 21 23 25 53 69 80 110 139 161 21 23 25 53 69 80 110 139 161

En la capa de transporte un segmento TCP puede emplear el mismo puerto que un datagrama UDP, sin que exista riesgo de confusin, ya que los procesos son identificados por la combinacin protocolo-puerto. Algunos de los puertos TCP y UDP bien conocidos se encuentran en la Tabla 5.1, con su aplicacin asociada. Muchas aplicaciones pueden funcionar con puertos TCP o UDP. En negrita se ha resaltado el protocolo que utiliza con mayor frecuencia cada una. La Tabla 5.2 resume una seleccin de los puertos registrados para aplicaciones de descarga compartida, vdeoconferencia, control remoto, juegos, etctera.
Web server 66.102.9.104

Asignacin dinmica de puertos

Los puertos bien conocidos simplifican las conexiones, ya que los equipos involucrados en ambos extremos saben de sobra a qu aplicacin van destinados los datos. Adems de los puertos bien conocidos, cada conexin necesita asignar dinmicamente un segundo nmero de puerto. La eleccin de este nmero es aleatoria, y lgicamente no ser una cifra inferior a 1024. La principal ventaja de la asignacin dinmica es que permite que un servicio soporte simultneamente ms de un usuario. En la Figura 5.32 se ve cmo el servicio http mantiene al mismo tiempo dos usuarios a los que se han asignado dinmicamente los puertos TCP 1051 y 1052. Durante la negociacin de una conexin en el protocolo TCP los host origen y destino se intercambian los nmeros de puertos. La Figura 5.33 muestra un ejemplo de ello. La combinacin de la direccin IP y el nmero de puerto es denominada socket. Un socket identifica un proceso de red de manera nica en Internet.

Tabla 5.1. Seleccin de puertos bien conocidos.

Pegasus 192.168.1.100

1051,80 1052,80
SYN SYN

80,1051
SYN,ACK SYN,ACK

80,1052

En el ejemplo de la Figura 5.33 para el equipo pegasus, un socket es 192.168.1.100.1051, es decir, su direccin IP seguida del puerto asignado dinmicamente; mientras que para el servidor web ser 66.102.9.104.80. Este par de sockets es conocido por ambos extremos una vez que finaliza con xito la negociacin y se establece la conexin, que es identificada por ellos. No existir en Internet otra conexin que posea un par de sockets coincidentes con sta.

1051,80 1052,80
ACK,dato ACK,dato

80,1051 80,1052

Fig. 5.33. Intercambio de puertos en la negociacin TCP.

110 05

5. Protocolo TCP/IP
5.5 Multiplexacin de datos

Caso prctico 4
Muchos usuarios de ordenadores conectados en red creen que sus equipos establecen por su cuenta conexiones con otros equipos remotos, y que transmiten datos sin su consentimiento: efectivamente, estn en lo cierto. Sistemas operativos como Windows XP mantienen abiertos muchos puertos como parte intrnseca de funcionamiento. Esto no supone un riesgo para el equipo, pero quien tenga dudas puede intentar disiparlas. El comando netstat visualiza los nmeros de puertos TCP locales y remotos, las direcciones IP de los hosts y el estado de las conexiones. Podemos ampliar esta informacin y ver tambin los puertos UDP (opcin a), o el identificador del proceso PID que utiliza cada puerto UDP y TCP (opcin o). La Figura 5.34 muestra una ejecucin del comando netstat desde un equipo que tiene instalado el sistema Windows XP. La Figura 5.34 muestra que en los puertos UDP no aparece el socket de direccin remota ni los estados de la conexin. Esto es lo normal, ya que el protocolo UDP no est orientado a conexin, y la nica informacin de la que dispone el sistema en cuanto a los datagramas UDP es local. Con el protocolo TCP no sucede lo mismo: la negociacin de la conexin a tres vas proporciona informacin acerca del host remoto y del estado de la conexin. Netstat puede presentar en la columna de estado estos valores: SYN_SEND indica que el puerto se abre y es activo. SYN_RECEIVED: el host remoto indica que ha recibido la secuencia de sincronismo (SYN) del host local.
Fig. 5.34. Puertos UCP, TCP e identificador de proceso PID.

ESTABLISHED: el host local ha recibido la secuencia de sincronismo del host remoto: conexin establecida. LISTENING: el host remoto est preparado para aceptar conexiones en los puertos indicados. TIME_WAIT es un estado introducido por el host local justo antes de cerrar la conexin. A veces una aplicacin libera un socket y netstat continua mostrndolo en el estado TIME_WAIT. No debe considerarse anmala esta situacin siempre y cuando no se prolongue durante ms de cuatro minutos. CLOSE_WAIT indica un estado de cierre de conexin; en concreto, aparece cuando el equipo remoto recibe la peticin de cierre (FIN) del equipo local.

corresponden con el puerto 80 (http) y que son utilizados por los procesos 1692, 1708 y 804 respectivamente. Cmo saber de qu procesos se trata? Windows XP permite conocerlo gracias al Administrador de tareas, que aparece al pulsar CTRL+ALT+SUPR. Por defecto el administrador de tareas de Windows no incluye dentro de la ficha denominada Procesos la columna con los identificadores de proceso PID. Tendremos que pulsar la opcin Ver en el men principal y escoger en el submen desplegable Seleccionar columnas. Vemos una serie de opciones y sealamos la del identificador de proceso (PID). La Figura 5.35 muestra la informacin de los procesos actuales en el equipo donde se ha ejecutado netstat aon. Al revisar los valores se ve que los PID 1.692 y 1.708 pertenecen al programa iexplorer.exe (la aplicacin Internet Explorer). El otro PID que usa el puerto 80 es 804: la tabla lo asocia al programa ejecutable mcupdate.exe (lo emplea el antivirus McAfee para actualizaciones automticas).

En nuestro caso vemos cmo tres procesos se encuentran dentro del estado ESTABLISHED. Por tanto, existen otras tantas conexione activas con sistemas remotos. Analizando con detalle los sockets remotos se aprecia que se

111 05

5. Protocolo TCP/IP
5.5 Multiplexacin de datos

Caso prctico 4 (cont.)

Fig. 5.36. Pantalla principal del programa TCPView.

Fig. 5.35. Administrador de tareas de Windows XP.

Parece, por tanto, que los tres procesos son seguros. El anlisis de las tablas de procesos se debe hacer con paciencia y cierta intuicin. En este sentido ayuda mucho la experiencia, porque no siempre todo es lo que parece ser. Nos fijamos ahora en un proceso que casi pasa inadvertido: LSASS.EXE con el PID 576 asociado. Por qu este proceso? Quien lo conoce lo sabe bien, y quien no, seguro que ha odo hablar del gusano W32-Sasser. El programa original LSASS.EXE, es un proceso que Windows emplea para verificar la identidad de los usuarios que acceden al sistema. Lamentablemente W32-Sasser, al igual que otros gusanos, suplanta la identidad de este archivo, abre una conexin simulando ser un servidor FTP a travs del puerto TCP 5554 y crea un acceso remoto en el puerto TCP 9996. Este virus tambin escanea las direcciones IP de puertos TCP que se encuentren en el estado LISTENING a partir del puerto 1068. Afortunadamente para el usuario de este sistema, LSASS.EXE est utilizando el puerto UDP 500, as que no se trata de un equipo infectado. Otra cosa muy distinta sera que visemos al PID 576 asociado con un socket cuya direccin IP y puerto TCP se correspondiese con lo descrito para el famoso gusano.

El anlisis continuo de las conexiones abiertas y los puertos utilizados es ya una tarea rutinaria para los programas antivirus. En este sentido netstat se queda corto, pues su ejecucin cuando existen muchas conexiones abiertas es lenta y la actualizacin de su informacin no es automtica. Afortunadamente existen multitud de programas, la mayora de ellos de distribucin gratuita, que permiten visualizar el estado de los puertos en tiempo real y con detalle. Para este caso prctico se ha elegido TCPView v2.34 de Sysinternals (www.sysinternals.com/ntw2k/utilities.shtml). Al iniciar el programa una pantalla muestra todos los puertos UDP y TCP que se encuentran activos y qu procesos los estn utilizando. Adems resuelve nombres de dominio y host en direcciones IP, e informa del estado de las conexiones IP (vase la Fig. 5.36). Por defecto TCPView actualiza los datos cada segundo, variando su presentacin: cuando una conexin cambia de estado entre actualizaciones es resaltada en amarillo; cuando finaliza o va ser borrada, en rojo; y las nuevas conexiones activas, en verde. Con este programa se evita recurrir al administrador de tareas para conocer el proceso asociado al identificador PID. TCPView muestra en la primera columna el nombre del programa o proceso, seguido del cdigo PID. Tambin podemos decidir finalizar uno de estos procesos o concluir una conexin. Basta con resaltar la entrada en cuestin, hacer clic sobre el botn derecho del ratn y elegir la opcin deseada.

112 05

5. Protocolo TCP/IP
Actividades prcticas

Actividad prctica 1
Objetivos Determinar que tipo de mscara de subred se debe emplear para asignar una cantidad adecuada de hosts y de subredes. Comprobar la segmentacin efectiva de una subred de clase C empleando las herramientas de diagnstico ms adecuadas. g) Materiales Una red LAN, compuesta al menos por ocho equipos a los que se pueda asignar una direccin IP. Resulta indiferente si los medios de transmisin son cableados o inalmbricos. El sistema operativo no tiene por que ser el mismo en todos los equipos, slo es necesario que funcionen con el protocolo TCP/IP y que permitan ejecutar sus comandos. f) Comprobar la conectividad IP mediante el comando ping entre equipos de la misma subred. Visualizar las tablas dinmicas ARP antes y despus de cada prueba. Aparece una nueva entrada ARP despus de cada ping? En caso de que la respuesta sea negativa, se deben revisar todas las conexiones fsicas y comprobar que los diodos led de enlace en los adaptadores de red estn encendidos. Ejecutar los comandos ipconfig y/o winipcfg desde cada equipo de la red. Comprobar que la mscara de subred es la misma para todos ellos, que la direccin de host se encuentra dentro del rango adecuado de su subred, y que no aparece direccin alguna para la puerta de enlace. Una vez verificada la conectividad entre equipos de la misma subred comprobar que realmente existe segmentacin IP entre equipos que pertenezcan a distintas subredes. Ejecutar el comando ping desde un equipo de la subred 1 a direcciones IP de las subredes 2, 3 y 4.

h)

Observaciones Tiempo estimado: 45 min. Enunciado En una LAN con direccin 192.168.1.0 se pretende hacer una segmentacin IP de cuatro subredes para mejorar la eficiencia de la misma. Procedimiento a) Determinar la mscara de subred que permita la creacin de las cuatro subredes. Anotar su valor primero como nmero binario y despus en notacin binario decimal. Calcular para la subred 1, la direccin de red, direccin de difusin, primera y ltima direccin vlida de host. c) Repetir el punto anterior para el resto de las subredes, a las que denominaremos: subred 2, subred 3 y subred 4. Introducir en la configuracin TCP/IP de cada uno de los equipos la mscara de subred calculada en el primer apartado. Modificar sus direcciones IP de tal manera que cada subred est compuesta al menos por dos de ellos. Una vez introducidos los cambios debemos reiniciar los equipos en los que el sistema operativo lo demande para que tengan efecto. Puede suceder que se disponga de equipos en los que el sistema operativo no sea el mismo; por ejemplo: Windows en unos y Linux en otros, o que las versiones sean distintas. Todo ello no modifica el proceso de esta actividad siempre y cuando el protocolo instalado en todos ellos sea TCP/IP. Si en el apartado 6 del procedimiento se detectan errores de conectividad, primero se revisar que todos los equipos estn correctamente conectados a nivel fsico, despus se pasar el apartado g y se revisar la configuracin TCP/IP de cada equipo antes de volver de nuevo al apartado f. Al consultar las tablas ARP que se guardan en la memoria cach de cada adaptador de red, se debe tener en cuenta que la mayora de ellos slo almacena cuatro entradas. Al modificar las direcciones IP y mscaras de subred de cada equipo comprobaremos que en ninguno de ellos hay una direccin IP especificada para la puerta de enlace. Para identificar adecuadamente los mensajes esperados despus de ejecutar el comando ping, se recomienda consultar los casos prcticos uno y dos de esta unidad. Para responder a los apartados 2 y 3 se recomienda utilizar el informe RFC 1878. Dentro de l hay una tabla (Tabla 1-2) con todas las combinaciones posibles. Considerar que el identificador genrico N.N.N de la tabla equivale a 192.168.1 en esta actividad.

b)

d)

e)

113 05

5. Protocolo TCP/IP
Actividades prcticas

Actividad prctica 2

Objetivos Emplear utilidades software para realizar pruebas de conectividad IP y medir la eficiencia de la red.

f)

Realiza las pruebas de conectividad desarrolladas en el Caso prctico 1, utilizando en esta ocasin QCheck. Para ello hacemos clic sobre los botones TCP y Response Time de la consola, en el campo From Endpoint 1 introducimos la direccin IP del host origen, y en el campo To Endpoint 2 la direccin IP del host destino. La aplicacin QCheck se ejecuta desde el host origen.

g) Materiales Una LAN con un esquema similar al visto en el Caso prctico 1 (se puede prescindir de la parte Wi-Fi). Los datos de configuracin LAN pueden ser los mismos. Utilidad de diagnstico QCheck. Esta utilidad se puede descargar desde http://www.netiq.com/qcheck/

Observaciones QCheck realiza las pruebas de diagnstico slo entre dos equipos cada vez. Es imprescindible que la utilidad est instalada en ambos, por lo que se recomienda instalarlo en todos los equipos de la red. Cada vez que se haga una prueba, la aplicacin se ejecuta en uno solo de los extremos, en el otro QCheck se ha ejecutado en memoria residente al iniciar el PC. Los resultados obtenidos en las medidas de eficiencia de la red se corresponden con el momento concreto en el que se hacen. Para evitar resultados no representativos se realizarn en diferentes ocasiones y admitiremos como vlido el que se repita con ms frecuencia.

Tiempo estimado: 30 min. Enunciado Sobre una configuracin de red adaptada del Caso prctico 1 (vase la Figura 5.7) realizaremos pruebas de conectividad, eficiencia en la tasa de transferencia de datos para los protocolos TCP y UDP.

Procedimiento a) Instalar en cada uno de los equipos de la red el programa de diagnstico QCheck. Ejecutar desde uno de los equipos de la red cableada Ethernet la utilidad QCheck. Aparecer la consola mostrada en la Figura 5.37. Para medir la eficiencia de la red con otro equipo de la red inalmbrica hacemos clic sobre los botones TCP y Throughput de la consola. El campo From Endpoint 1 tendr el valor localhost y en el campo To Endpoint 2 tecleamos la direccin IP de uno de los equipos de la red inalmbrica, por ejemplo 192.168.135.101. Para comenzar el diagnstico hacemos clic sobre el botn Run. Anotamos el valor obtenido. (El tamao de los datos empleados ser de 100 Kbps). Realizar el apartado c cambiando al protocolo UDP. Comprobar los apartados 3 y 4 haciendo las pruebas en direccin contraria. Es decir, ejecutando la utilidad Check desde el otro equipo. Repite los apartados 3, 4 y 5 de la siguiente manera: primero entre dos equipos de la red inalmbrica, y despus entre dos equipos de la red cableada. Comparar los resultados obtenidos.

b)

c)

Fig. 5.37. Consola de la aplicacin QCheck.

d) e)

e)

114 05

5. Protocolo TCP/IP
Ejercicios propuestos

Preguntas de evaluacin
1

Qu diferencias hay entre una direccin fsica y una direccin lgica? Por qu el protocolo TCP se considera ms fiable que el protocolo UDP?

10 11

Qu mensajes ICMP emplea el comando ping? Enumera varios de los servicios de red disponibles en la capa de aplicacin del protocolo TCP/IP. Cuando se habla de nmeros de puertos TCP o UDP, qu significan los denominados bien conocidos? En una conexin TCP, en cul de los extremos se realiza una asignacin dinmica de puerto? Qu significa el trmino socket en una conexin TCP? Para qu sirven las tablas de rutas? Explica como se puede determinar la traza de una ruta. Las conexiones del protocolo TCP que muestra el comando
netstat estn acompaadas de un estado. Cuntos estados

12 3

Cmo se denomina a los paquetes de datos en cada capa del protocolo TCP/IP?
13

Cmo se consigue separar en una direccin IP la direccin de red de la direccin de host?

14

En una direccin IP escrita en binario, qu reglas se siguen para determinar a qu clase pertenece? En una direccin IP escrita en notacin punto decimal, qu reglas se siguen para determinar a qu clase pertenece? Qu ventajas se obtienen al segmentar redes? En qu capa opera el protocolo ARP? Cul es su principal cometido? Describe los pasos que se siguen durante una negociacin a tres vas del protocolo TCP.

15 16 17

7 8

posibles hay? Cul es su significado?

18

El comando netstat puede mostrar un cdigo de identificacin de proceso para cada puerto activo. Indica al menos dos formas de averiguar a qu aplicacin se corresponde ese cdigo PID.

Ejercicios
1

Calcula el nmero de redes que puede haber en cada una de las clases de direcciones IP (clases A, B y C). Calcula el nmero de hosts que puede haber en cada una de las clases de direcciones IP (clases A, B y C). Indica a qu clase pertenece cada una de las siguientes direcciones IP: a) 64.81.234.120 b) 124.23.45.28 c) 192.154.23.14

Cuntas subredes crea cada una de estas mscaras al ser asociada a una direccin IP de clase C? a) 255.255.255.192 b) 255.255.255.224 c) 255.255.255.248

Indica para cada una de las siguientes direcciones IP, cul es el identificador de red y cul es el identificador de host: a) b) c) d) e) f) 127.0.0.1 66.102.9.104 245.34.67.14 122.23.9.167 171.34.59.201 114.50.34.29

115 05