02.redes ethernet

Introducción a las redes IP. Ethernet conmutada

Dpt. Ingeniería Electrónica y Comunicaciones

Área de Ingeniería Telemática

Laboratorio de Telemática Práctica 1. Introducción a las redes IP. Ethernet conmutada

2


3

Índice 1. Nivel de Red: el protocolo IP (Internet Protocol)………...……………………...5

1.1.·Introducción …………………………………………………………..……5 1.2.·Las direcciones de Internet………………………………………..………...6 1.3. El datagrama IP………………………………………………………...……9

1.3.1. El formato del datagrama IP…………………………………...……..9 1.3.2. La fragmentación de datagramas IP…………………………………11

1.4. Resolución de direcciones (ARP)………………………………………......12 1.5. Las subredes………………………………………………………………...14 1.6. Encaminamiento IP…………………………………………………………16

1.6.1. Introducción………………………………………………………….16 1.6.2. Entrega directa e indirecta…………………………………………...17 1.6.3. El algoritmo de encaminamiento…………………………………….18

2. Nivel de Transporte: los protocolos TCP (Transmission Control Protocol) y UDP (User Datagram Protocol)……………………………………………………..…20 2.1. Introducción…………………………………………………………………20 2.2. Puertos y sockets…………………………………………………………….22 2.3. Arquitectura cliente-servidor..........................................................................23 2.4. User Datagram Protocol (UDP)......................................................................24 2.5. Transmission Control Protocol (TCP)............................................................24

2.5.1. Protocolos de ventana deslizante..........................................................25 2.5.2. TCP y la ventana deslizante………………………………………….27 2.5.3. El segmento TCP……………………………………………………..27

3. Ethernet conmutada……………………………………………………………...29 3.1. Introducción………………………………………………………………....29 3.2. Elementos de una red Ethernet conmutada…………………………………30 3.3. Ethernet conmutada en el laboratorio de telemática………………………...31

3.3.1. Composición del puesto de trabajo…………………………………..31 3.3.2. Superstack II 12 port PS hub 40……………………………………..32

3.3.2.1. Características Generales…………………………………….32 3.3.2.2. Uso del PS Hub………………………………………………34 3.3.2.3. Gestión del PS Hub…………………………………………..36

3.3.3. Superstack II switch 1100……………………………………………38 3.3.3.1. Características generales……………………………………..38 3.3.3.2. Conexiones del swicth………………………………………..38 3.3.3.3. Gestión del switch……………………………………………39

4. Realización de la práctica………………………………………………………...41 4.1. PARTE I: Estudio de los equipos de una red ethernet conmutada…………..41

4.1.1. Hub Superstack II…………………………………………………….41 4.1.2. Superstack II switch 1100…………………………………………….42

4.2. PARTE II: Análisis del comportamiento de la red Ethernet mediante el programa IPERF……………………………………………………………...44

4.2.1. Ethernet compartida…………………………………………………...44 4.2.2. Análisis de la eficiencia de la red Ethernet……………………………44

4.3. PARTE III: Desarrollo de una herramienta de medida del ancho de banda….45

ANEXO I……………………………………………………………………………...47


4

Introducción a las redes IP. Ethernet conmutada Práctica

Presentación de la Práctica

Objetivos

Estudiar y entender las redes IP y en particular las redes de área local

Construir y analizar el tráfico de una red LAN Ethernet, mediante diferentes hub o segmentos de hub conectados entre sí a través de un switch.

Estructura documento

Este documento comienza introduciendo los conceptos básicos asociados a las redes IP, como son el direccionamiento y la formación de subredes.

También se dan las nociones básicas de la red de área local más ampliamente utilizada en la actualidad: Ethernet conmutada

La realización práctica se centra en la implementación de una red ethernet conmutada. Veremos cómo se puede gestionar y también cómo se puede analizar el tráfico que viaja por ella.


5

1 Nivel de Red: el protocolo IP (Internet Protocol) 1.1 Introducción Los protocolos de red se diseñan en forma de capas o niveles, donde cada nivel es responsable de una faceta diferente de las comunicaciones. Una torre de protocolos es la combinación de diversos protocolos de varios niveles. TCP/IP se considera un sistema de 4 niveles (o 4 capas) tal y como se muestra en la figura 1.1

Figura 1.1: Las 4 capas de TCP/IP

TCP e IP son los dos protocolos que dan nombre a una arquitectura de red. Sin embargo, una red TCP/IP necesita otros protocolos para tener todas las funcionalidades. La figura 1.2 muestra los protocolos que forman la familia TCP/IP. El objetivo del protocolo IP es convertir redes físicamente diferentes (como pueden ser Ethernet, Token Ring, X.25, Frame Relay, ATM...) en una red aparentemente homogénea, lo que se conoce como interconexión de redes. De esta forma IP oculta las redes físicas subyacentes creando por encima de éstas una única red “virtual” o red de redes, donde:

• Hay un esquema de identificación (o direccionamiento) de todos los sistemas, uniforme y universal.

• Este esquema de direccionamiento ha de ser independiente del hardware. Esto se consigue asignando a cada nodo un número único de 32 bits (en IPv4, Internet Protocol versión 4 ) llamado dirección IP.

• Los datos viajan por la red virtual IP agrupados en paquetes denominados datagramas. La manipulación de estos datagramas por parte de la red sigue un método uniforme llamado “encaminamiento de datagramas”, independiente de la red en particular donde se encuentren estos datagramas.

• La entrega de datagramas de un extremo a otro por la red IP es: o No fiable (no hay control de errores, ni control de flujo). o No orientado a conexión. o La red se esfuerza al máximo para entregar los paquetes, pero no asegura la

entrega (best effort).


6

Figura 1.2: Protocolos de la familia TCP/IP

Por tanto los datagramas se pueden perder, desordenar o incluso duplicar, e IP no tendrá en cuenta estas situaciones (lo controlarán protocolos superiores). El protocolo IP asume pocas cosas de las capas inferiores, sólo que los datagramas “probablemente” serán transportados al host de destino. 1.2 Las direcciones de Internet Las direcciones de Internet pueden ser simbólicas o numéricas:

• Las direcciones simbólicas son las que usualmente utilizamos los humanos porque son más fáciles de recordar que las numéricas. Estas direcciones son cadenas de caracteres separadas por puntos. Por ejemplo: www.unizar.es

• Las direcciones numéricas son las que usualmente utiliza el software IP. La forma numérica es una secuencia de 32 bits. Para que sea más inteligible, habitualmente se expresa en forma de números decimales separados por puntos (dotted-decimal en inglés), donde cada decimal representa 8 bits (rango 0-255). Por ejemplo, la dirección binaria 10011011. 11010010. 00001100. 00010100 se puede expresar en notación decimal como 155.210.12.20 (que a su vez se corresponde con la dirección simbólica www.unizar.es). Las funciones de mapeo entre las direcciones simbólicas y las direcciones numéricas las realiza el DNS (Domain Name System). Una dirección no identifica una máquina en Internet, sino a un determinado interfaz de red de la máquina. Dicho de otra forma, la dirección IP identifica a una determinada máquina en una determinada red física. Cuando la máquina está conectada a más de una red se la denomina "multi-homed" y tiene una dirección por cada interfaz de red. En realidad, para interpretar correctamente una determinada dirección IP se necesita una segunda secuencia de 32 bits denominada “máscara” (netmask). La máscara se utiliza para dividir la dirección en dos partes:

• La parte de red, denominada formalmente “número de red” (RFC 1166), aunque en ocasiones se usan los términos dirección de red y netID. Los números de red están administrados centralmente por el INTERNIC ( INTErnet Network Information Center) y son únicos en toda Internet. Cuando se solicita al INTERNIC una dirección IP, no se asigna una dirección a cada máquina individual, sino que se da


7

un número de red, permitiendo asignar según las necesidades todas las direcciones IP válidas dentro de este rango.

• La parte de host, denominada formalmente “número de host”, aunque ocasionalmente se usan los términos dirección de host y hostID. Para dividir una dirección IP en número de red y número de host se utiliza la máscara, de manera que aquellos bits de la dirección donde la máscara tiene un "1" forman parte del número de red, mientras que las posiciones donde la máscara tiene “0” forman parte del número de host. Por ejemplo si tenemos la dirección 10011011. 11010010. 00001100. 00010100 con una máscara 11111111. 11111111. 00000000. 00000000 tenemos un número de red 10011011. 11010010. y un número de 00001100. 00010100. Por convenio el número de red se encuentra en los bits más significativos (los bits de la izquierda de la dirección) mientras que el número de host se suele encontrar en los bits menos significativos (los bits de la derecha de la dirección). Además los números de red y host suelen estar formados por bits consecutivos de la dirección IP (es muy extraño ver máscaras con ceros y unos no consecutivos). La máscara de red también se suele representar en formato decimal, de manera que para el ejemplo anterior tenemos la dirección 155.210.12.20 y la máscara 255.255.0.0. Otra manera de representar una dirección IP es poniendo la dirección en formato decimal y la máscara como un número decimal que indica cuántos unos consecutivos forman el número de red. Así para nuestro ejemplo, la dirección 155.210.12.20 con máscara 255.255.0.0 se puede escribir como 155.210.12.20/16. El tamaño de la parte dedicada al host depende del tamaño de la red. Para satisfacer múltiples necesidades se han definido varias clases de redes, fijando diferentes puntos donde dividir la dirección IP. De esta manera se dispone las siguientes clases:

Clase A La clase A comprende redes desde 1.0.0.0 hasta 127.0.0.0. El identificador de red está contenido en el primer octeto, quedando para el host los 24 bits restantes y permitiendo aproximadamente 1.6 millones de máquinas por red. Por lo tanto, la máscara de red resultante es 255.0.0.0 (11111111. 00000000. 00000000. 00000000 en formato binario). Dentro de esta clase, el rango 10.0.0.0 hasta 10.255.255.255 es un rango reservado para uso privado. Una dirección de host reservada posible sería 10.0.0.1/8. Clase B La clase B comprende las redes desde 128.0.0.0 hasta 191.255.0.0, donde el netid está en los dos primeros octetos. Esta clase permite 16320 redes con 65024 lugares cada una. La máscara de esta clase es 255.255.0.0 (11111111. 11111111. 00000000. 00000000 en formato binario). En esta clase el rango 172.16.0.0 hasta 172.31.0.0 se reserva para uso privado. Una dirección de host posible reservada sería 172.31.0.1/16. Clase C Las redes de clase C van desde 192.0.0.0 hasta 223.255.255.0, donde el netid está en los tres primeros octetos. Esta clase permite cerca de 2 millones de redes con 254 lugares. La máscara de esta clase es de la forma 255.255.255.0 (11111111. 11111111. 11111111. 00000000 en formato binario). En esta clase se reserva para uso privado el rango 192.168.0.0 hasta 192.168.255.0. Una posible dirección de host privada puede ser 192.168.128.1/24.


8

Clase D Son direcciones dentro del rango 224.0.0.0 hasta 239.255.255.255 y se las llama direcciones multicast o de multidifusión. Clase E Las direcciones que están en el rango 240.0.0.0 hasta 247.255.255.255 son experimentales o están reservadas para futuras aplicaciones. Direcciones Especiales Cabe destacar que en la parte reservada a host, los valores 0 y 255 se reservan porque tienen un significado especial:

• Una dirección IP donde todos los bits de la parte de host son cero se refiere a la dirección de la red misma.

• Una dirección donde todos los bits de la parte de host son uno se denomina dirección de difusión (o broadcast), ya que hace referencia a todas las máquinas de la red específica. Así 147.83.20.255 no es un hostid válido, pero se refiere a todos los hostid de la red 147.83.20.0. Las direcciones de red 0.0.0.0 y 127.0.0.0 están reservadas. La primera dirección se llama encaminamiento por defecto (por donde IP encamina los datagramas), y la segunda es la dirección de loopback. La red 127.0.0.0 está reservada para el tráfico local IP de la máquina. Normalmente la dirección 127.0.0.1 se asigna a una interfaz de la máquina (la interfaz de loopback) que actúa como un circuito cerrado. Cualquier paquete IP enviado a este interfaz será devuelto como si hubiera vuelto desde alguna red. Esto permite por ejemplo instalar software de red o probar tarjetas ethernet, aunque no se disponga de una red real.

Figura 1.3: Clases de direcciones IP


9

1.3 El datagrama IP El datagrama IP es la unidad de transferencia en las redes IP. Básicamente consiste en una cabecera IP y un campo de datos para protocolos superiores. El datagrama IP está encapsulado en la trama de nivel de enlace, que suele tener una longitud máxima (MTU, Maximum Transfer Unit), dependiendo del hardware de red usado. Para Ethernet, esta es típicamente de 1500 bytes. En vez de limitar el datagrama a un tamaño máximo, IP puede tratar la fragmentación y el reensamblado de sus datagramas. En particular, IP no impone un tamaño máximo, pero establece que todas las redes deberían ser capaces de manejar al menos 576 bytes. Los fragmentos de datagramas tienen todos una cabecera, copiada básicamente del datagrama original, y de los datos que la siguen. Los fragmentos se tratan como datagramas normales mientras son transportados a su destino. Nótese, sin embargo, que si uno de los fragmentos se pierde, todo el datagrama se considerará perdido, y los restantes fragmentos también se considerarán perdidos. 1.3.1 El formato del datagrama IP La cabecera del datagrama IP está formada por los campos que se muestran en la figura 1.4

Figura 1.4: Formato del datagrama IP

Donde: Version es la versión del protocolo IP. La versión actual es la 4. La 5 es experimental y la 6 es IPng. Hdr Len es la longitud de la cabecera IP contada en cantidades de 32 bits. Esto no incluye el campo de datos. Type Of Service es el tipo de servicio es una indicación de la calidad del servicio solicitado para este datagrama IP. Una descripción detallada de este campo se puede encontrar en el RFC 1349. Total Length es la longitud total del datagrama, cabecera y datos, especificada en bytes.


10

Identification es un número único que asigna el emisor para ayudar a reensamblar un datagrama fragmentado. Los fragmentos de un datagrama tendrán el mismo número de identificación. Flags son flags para el control de fragmentación.

Donde: El bit 0 está reservado y debe ser 0. El bit DF significa no fragmentar (Do not Fragment). Con 0 se permite fragmentación y con 1 no. El bit MF significa que hay más fragmentos (More Fragments). Con 0 significa que se trata del último fragmento del datagrama y con 1 que hay más fragmentos.

Figura 1.5: Detalle del campo Flags

Fragment Offset (FO) se usa en datagramas fragmentados para ayudar al reensamblado de todo el datagrama. El valor es el número de partes de 64 bits (no se cuentan los bytes de la cabecera) contenidas en fragmentos anteriores. En el primer (o único) fragmento el valor es siempre cero. Time To Live especifica el tiempo (en segundos) que se le permite viajar a este datagrama. Cada "router" por el que pase este datagrama ha de sustraer de este campo el tiempo tardado en procesarlo. En la realidad un "router" es capaz de procesar un datagrama en menos de 1 segundo; por ello restará uno de este campo y el TTL se convierte más en una cuenta de saltos que en una métrica del tiempo. Cuando el valor alcanza cero, se asume que este datagrama ha estado viajando en un bucle y se desecha. El valor inicial lo debería fijar el protocolo de alto nivel que crea el datagrama. Protocol indica el número oficial del protocolo de alto nivel al que IP debería entregar los datos del datagrama. Algunos valores importantes se muestran en la Tabla 1.1.

Tabla 1.1: Algunos Protocol Numbers

Header Checksum es el checksum de la cabecera. Se calcula como el complemento a uno de la suma de los complementos a uno de todas las palabras de 16 bits de la cabecera. Si el checksum de la cabecera no se corresponde con los contenidos, el datagrama se desecha, ya que al menos un bit de la cabecera está corrupto, y el datagrama podría haber llegado a un destino equivocado.


11

Source IP Address es la dirección IP de 32 bits del host emisor. Destination IP Address es la dirección IP de 32 bits del host receptor. Options es un campo de longitud variable. Las opciones se incluyen en principio para pruebas de red o depuración, por tanto no se requiere que toda implementación de IP sea capaz de generar opciones en los datagramas que crea, pero sí que sea capaz de procesar datagramas que contengan opciones. El campo Options tiene longitud variable en función de la opción seleccionada. Algunas opciones tienen una longitud de un solo byte y otras tienen longitudes variables. El primer byte de cualquier opción se denomina type byte y su estructura se muestra en la figura 1.6.

Donde: FC es el flag de copia (Flag Copy), e indica si el campo de opciones se ha de copiar (1) o no (0) cuando el datagrama está fragmentado.

Figura 1.6: Detalle de type byte

class es un entero sin signo de 2 bits, donde:

Tabla 1.2: Option classes

number es un entero sin signo de 5 bits que indica el número de opción dentro de cada clase.

1.3.2 La fragmentación de datagramas IP

Cuando un datagrama IP viaja de un host a otro puede cruzar distintas redes físicas. Las redes físicas imponen un tamaño máximo de trama, llamado MTU (Maximum Transmission Unit), que limita la longitud de un datagrama. Por ello, existe un mecanismo para fragmentar los datagramas IP grandes en otros más pequeños y luego reensamblarlos en el host de destino. IP requiere que cada enlace tenga un MTU de al menos 68 bytes, de forma que si cualquier red proporciona un valor inferior, la fragmentación y el reensamblado tendrán que implementarse en la capa de la interfaz de red de forma transparente a IP. 68 es la suma de la mayor cabecera IP, de 60 bytes, y del tamaño mínimo posible de los datos en un fragmento (8 bytes). Las implementaciones de IP no están obligadas a manejar datagramas sin fragmentar mayores de 576 bytes, pero la mayoría podrá manipular valores más grandes, típicamente ligeramente por encima de 8192 bytes o incluso mayores, y raramente menos de 1500. Un datagrama sin fragmentar tiene a cero toda la información de fragmentación. Es decir, los flags FC y FO están a 0. Cuando se ha de realizar la fragmentación, se ejecutan los siguientes pasos:


12

• Se chequea el bit de flag DF para ver si se permite fragmentación. Si está a uno, el datagrama se desecha y se devuelve un error al emisor usando ICMP 1(Internet Control Message Protocol).

• Basándose en el valor MTU, el campo de datos se divide en partes donde cada parte, excepto la última, debe ser múltiplo de 8 bytes.

• Todas las porciones de datos se colocan en datagramas IP. • Se copian las cabeceras de la cabecera original, con algunas modificaciones:

o El bit de flag MF se pone a uno en todos los fragmentos, excepto en el último.

o El campo FO se pone al valor de la localización de la porción de datos correspondiente.

o Si se incluyeron opciones en el datagrama original, el bit FC del type byte determina si se copiaran o no en todos los fragmentos o sólo en el primero2.

o Se inicializa el campo Hdr Len (longitud de la cabecera). o Se inicializa el campo Total Length (longitud total). o Se recalcula el Header Checksum de la cabecera.

Cada uno de estos datagramas se envía como un datagrama IP normal. IP maneja cada fragmento de forma independiente, es decir, los fragmentos pueden atravesar diversas rutas hacia su destino, y pueden estar sujetos a nuevas fragmentaciones si pasan por redes con MTUs inferiores. En el host de destino, los datos se tienen que reensamblar. Para ello se siguen los siguientes pasos:

• Con el fin de reensamblar los fragmentos, el receptor destina un buffer de almacenamiento en cuanto llega el primer fragmento.

• Una vez ha llegado el primer fragmento se inicia un contador temporal3. • Cada fragmento se identifica mediante el campo Identification que es un número

único dentro de los límites impuestos por el uso de un número de 16 bits. Como la fragmentación no altera este campo, los fragmentos que van llegando al destino pueden ser identificados gracias a este identificador y a las direcciones IP fuente y destino del datagrama. Además el campo Protocol también se chequea.

• Los fragmentos que van llegando se copian en el buffer en la localización indicada por el campo FO.

• Cuando han llegado todos los fragmentos, se restaura el datagrama original y se continúa con su proceso.

• Si vence el contador temporal y no se han recibido todos los fragmentos, el datagrama en fase de reensamblado se desecha.

1.4 Resolución de direcciones (ARP) En una sola red física, los hosts individuales se conocen en la red a través de sus direcciones físicas o direcciones de nivel 2. Los protocolos de alto nivel encaminan los datagramas al destino mediante direcciones globales o direcciones de nivel 3 (para el caso de redes IP la dirección es una dirección IP) de la red virtual. Los drivers del dispositivo de red de la red física (por ejemplo los drivers de las tarjetas Ethernet de los PCs del laboratorio) no entienden las direcciones de nivel 3. Por tanto, es necesario realizar una traducción de direcciones de nivel 3 a direcciones de nivel 2. En el caso de redes IP sobre Ethernet, la traducción se realiza de dirección IP a dirección Ethernet (que es una secuencia de 48 bits). Esta traducción se realiza en el host mediante una tabla usualmente denominada “caché


13

ARP”. Cuando la dirección no se encuentra en la caché ARP el host utiliza el protocolo ARP (Address Resolution Protocol) para averiguarla. ARP es un protocolo de petición/respuesta. La petición se envía en forma de broadcast de nivel 2 a la red. Si una de las máquinas de la red reconoce su propia dirección IP en la petición, devuelve una respuesta ARP al host que la solicitó. La respuesta contendrá la dirección física correspondiente a la dirección IP solicitada. Esta dirección se almacenará en la caché ARP del host solicitante. Todos los posteriores datagramas enviados a esta dirección IP se podrán asociar a la dirección física correspondiente, que será la que utilice el driver del dispositivo de red para mandar el datagrama. La figura 1.8 muestra el formato de la trama ARP.

Figura 1.8: Formato de la trama ARP

Si una aplicación desea enviar datos a una determinada dirección IP de destino, el software de encaminamiento IP determina en primer lugar la dirección IP del siguiente salto (que puede ser el propio host de destino o un router) y en segundo lugar el dispositivo de red al que se debería enviar. A continuación se consulta el módulo ARP para hallar la dirección física. El módulo ARP intenta hallar la dirección en su caché. Si la encuentra, devuelve la correspondiente dirección física. Si no la encuentra, descarta el paquete (se asume que al ser un protocolo de alto nivel volverá a transmitirlo) y genera un mensaje de broadcast de red para una solicitud ARP de dicha dirección física. Cuando un host recibe un paquete ARP (bien un broadcast o una respuesta punto a punto), el dispositivo receptor pasa el paquete al módulo ARP, que lo añadirá a la caché ARP. La próxima vez que un protocolo de nivel superior quiera enviar un paquete a ese host, el módulo de ARP encontrará la dirección hardware, a la que se enviará el paquete.


14

Figura 1.9: Ejemplo de ARP

1.5 Las subredes Es obvio que una dirección de clase A sólo se asignará a redes con un elevado número de hosts, y que las direcciones de clase C son adecuadas para redes con pocos hosts. Sin embargo, esto significa que las redes de tamaño medio (aquellas con más de 254 hosts o en las que se espera que en el futuro haya más de 254 hosts) deben usar direcciones de clase B. El número de redes de tamaño pequeño y medio ha ido creciendo muy rápidamente en los últimos años y se temía que, de haber permitido que se mantuviera este crecimiento, todas las direcciones de clase B se habrían usado para mediados de los 90. Esto es lo que se conoce como “el problema del agotamiento de las direcciones IP”. Como se comentó en la sección 1.2 cada parte de la dirección IP (número de red y número de host) es responsabilidad de entidades diferentes: el número de red es asignado por INTERNIC, mientras que la asignación de los números de host es responsabilidad de la autoridad que controla la red. Como veremos a continuación el número de host puede dividirse aún más: esta división también es controlada por la autoridad propietaria de la red, y no por INTERNIC. Debido al crecimiento explosivo de Internet, el uso de direcciones IP asignadas mediante las clases estándar se volvió demasiado rígido para permitir cambiar con facilidad la configuración de redes locales. Estos cambios podían ser necesarios cuando:

• Se instala una nueva red física. • El crecimiento del número de hosts requiere dividir la red local en dos o más redes.

Para evitar tener que solicitar direcciones IP adicionales en estos casos, se introdujo el concepto de subred, donde el número de host de la dirección IP se subdivide de nuevo en un número de red y de host. Esta segunda red se denomina subred. La red principal consiste ahora en un conjunto de subredes y la dirección IP se interpreta como <número de red, número de subred, número de host> La combinación del número de subred y del host suele


15

denominarse “dirección local” o “parte local”. La creación de subredes se implementa de forma que es transparente a redes remotas. Un host dentro de una red con subredes es consciente de la existencia de éstas, pero un host de una red distinta no lo es y sigue considerando la parte local de la dirección IP como un número de host. La división de la parte local de la dirección IP en números de subred y de host queda a libre elección del administrador local. Cualquier serie de bits de la parte local se puede tomar para la subred requerida. Por ejemplo, el subnetting es muy utilizado por los ISPs (Internet Service Provider) que se encargan de dar servicio de acceso a la Internet, éstos suelen tener asignado un rango de direcciones públicas de Internet, que dividen en subredes para después asignarlas a sus clientes. La división se efectúa empleando una máscara de red diferente a las que dividen las direcciones IP en clases estándar. El funcionamiento de estas máscaras es equivalente al que se describe en la sección 1.2 para las clases estándar, es decir, los bits a cero en esta máscara indican posiciones de bits correspondientes al número de host, y los que están a uno, indican posiciones de bits correspondientes al número de subred. Las posiciones de la máscara pertenecientes al número de red se ponen a uno pero no se usan. El tratamiento especial de “todos los bits a cero” y “todos los bits a uno” se aplica a cada una de las tres partes de dirección IP con subredes del mismo modo que a una dirección IP que no las tenga. Notar que al hacer subnetting, el número de máquinas sobre las que se hace broadcast (difusión) se reduce, optimizando el tráfico útil dentro de la red. Como ejemplo supongamos que tenemos la red privada de clase C 192.168.1.0/24. En este caso tendremos un total de 254 (256 – 2 (subred y broadcast), por tener 8 bits de hostid) direcciones posibles de host, de la 192.168.1.1/24 hasta la 192.168.1.254/24. Observe que las direcciones 192.168.1.0 y 192.168.1.255 se reservan, la primera para identificar la red y la segunda como dirección de broadcast. Supongamos que hemos de repartir este direccionamiento en dos subredes de la misma dimensión, ya que tenemos dos oficinas en poblaciones diferentes y montaremos dos LANs unidas por la WAN (Wide Area Network o red de transporte que alquilaremos a algún operador). Así pues, tenemos que la parte de hostid ha de ceder terreno para la parte de subred. Como necesitamos hacer dos subredes, con un bit tendremos suficiente para identificar la subred en la que nos encontramos, quedándonos dos subredes: la 192.168.1.0/25 y la 192.168.1.128/25, con 126 direcciones posibles de host en cada subred (7 bits de hostid). A continuación resumimos las direcciones de red, de máscara y de hosts implicadas en el subnetting de este ejemplo. Red básica original: 11000000. 10101000. 00000001. 00000000 = 192.168.1.0/24 Máscara: 11111111. 11111111. 11111111. 00000000 = 255.255.255.0 = /24 Hay 254 direcciones posibles para asignar a la red: host # 0 11000000. 10101000. 00000001. 00000001 = 192.168.1.1/24 (netmask 255.255.255.0) host # 1 11000000. 10101000. 00000001. 00000010 = 192.168.1.2/24 (netmask 255.255.255.0) host # 253 11000000. 10101000. 00000001. 11111110 = 192.168.1.254/24 (netmask 255.255.255.0) Si hacemos subnetting nos quedarán estas dos subredes: Subnet # 0 11000000. 10101000. 00000001. 00000000 = 192.168.1.0/25 (netmask 255.255.255.128) Subnet # 1 11000000. 10101000. 00000001. 10000000 = 192.168.1.128/25 (netmask 255.255.255.128) Con las siguientes direcciones de host disponibles en cada oficina: Subnet # 0 de una oficina: host # 0 11000000. 10101000. 00000001. 00000001 = 192.168.1.1/25 (netmask 255.255.255.128) host # 1 11000000. 10101000. 00000001. 00000010 = 192.168.1.2/25 (netmask 255.255.255.128) host# 125 11000000. 10101000. 00000001. 01111110 = 192.168.1.126 / 25 (netmask 255.255.255.128) Subnet # 1 de la otra oficina: host # 0 11000000. 10101000. 00000001. 10000001 = 192.168.1.129/25 (netmask 255.255.255.128)


16

host # 1 11000000. 10101000. 00000001. 10000010 = 192.168.1.130/25 (netmask 255.255.255.128) host # 125 11000000. 10101000. 00000001. 11111110 = 192.168.1.254/25 (netmask 255.255.255.128) 1.6 Encaminamiento IP 1.6.1 Introducción La función más importante de la capa IP es el encaminamiento de datagramas extremo a extremo a través de la red virtual. Por tanto esta función proporciona los mecanismos necesarios para interconectar distintas redes físicas. La formación de la red virtual que conecta múltiples redes se consigue por medio de unos hosts especiales denominados "routers". Es importante distinguir entre un hub, un puente, un router y una pasarela. El hub interconecta segmentos de LAN a nivel de interfaz de red y envía tramas entre ellos. El hub sirve como prolongación del cable físico que conecta las máquinas de la LAN y su única función es difundir la señal que llega por un cierto puerto (entrada) al resto de puertos. Los hubs pueden ser pasivos (si no amplifican las señales recibidas por sus puertos) o activos (si las amplifican). El conmutador (switch) es un dispositivo parecido al hub pero en el que se realiza conmutación entre sus diferentes puertos, es decir, conmuta los paquetes observando sus direcciones físicas origen/destino. Un puente (bridge) interconecta segmentos de LAN a nivel de interfaz de red y envía tramas entre ellos. Un puente realiza la función de retransmisión MAC (Medium Access Control) y es independiente de cualquier capa superior (incluyendo LLC). Proporciona, si se necesita, conversión de protocolos a nivel MAC. Un puente es transparente para IP. Es decir, cuando un host envía un datagrama a otro host en una red con el que se conecta a través de un puente, envía el datagrama al host y el datagrama cruza el puente sin que el emisor se dé cuenta. El puente es capaz de aprender las direcciones hardware de las máquinas que tiene en cada puerto y aislar el tráfico y las colisiones de cada tramo LAN. Un router interconecta redes físicas diferentes a nivel de la capa de red y encamina paquetes entre ellas. El router debe comprender la estructura de direccionamiento asociada con los protocolos que soporta (IP en nuestro caso) y debe elegir las mejores rutas de transmisión así como tamaños óptimos para los datagramas realizando fragmentación si lo considera oportuno. La pasarela (gateway) interconecta redes a niveles superiores que los puentes y los routers. Una pasarela suele soportar el mapeado de direcciones de una red a otra, así como la transformación de datos entre distintos entornos para conseguir conectividad entre los extremos de la comunicación. Las pasarelas típicamente proporcionan conectividad de dos redes para un subconjunto de protocolos de aplicación soportados en cada una de ellas. Una pasarela es opaca para IP. Es decir, un host no puede enviar un datagrama IP a través de una pasarela: sólo puede enviarlo a la pasarela. La pasarela se ocupa de transmitirlo a la otra red con la información de los protocolos de alto nivel que vaya en él. Estrechamente ligado al concepto de pasarela, está el de cortafuegos (firewall), que se usa para restringir la circulación de datagramas entre redes por motivos de seguridad.


17

1.6.2 Entrega directa e indirecta El encaminamiento IP se puede dividir en dos partes: entrega directa y entrega indirecta:

• La entrega directa es la transmisión de un datagrama desde el host origen hasta el host destino a través de una sola red física, dicho de otra forma, dos hosts sólo pueden comunicarse mediante entrega directa si ambos están conectados directamente a la misma red física (por ejemplo, una sola red Ethernet). Básicamente en la entrega directa el emisor encapsula el datagrama dentro de una trama física, transforma la dirección IP destino en una dirección física y envía la trama resultante al destino a través del driver del dispositivo hardware correspondiente.

• La entrega indirecta es necesaria cuando el host destino no está conectado directamente a la red del origen, lo que implica que el datagrama deberá atravesar varias redes físicas, y para ello es necesario atravesar routers. La entrega indirecta es más compleja ya que el host origen ha de identificar al router al que debe entregar el datagrama, el primer router debe identificar cuál será el siguiente router al que debe enviar el datagrama, esto también se denomina identificar el “siguiente salto”. La comunicación entre dos routers consecutivos de la ruta se realiza siempre mediante entrega directa, es decir, un determinado router de la ruta y el router del siguiente salto deben estar conectados a la misma red física, sino no es posible su comunicación. A su vez, el último router de la ruta que sigue el datagrama debe estar conectado a la misma red física que el host destino.

Figura 1.10: Entrega directa e indirecta

El host origen averigua si debe realizar entrega directa o no, es decir, si el host destino está conectado o no directamente a su red física mediante el prefijo de red. El host origen extrae el número de red de la dirección IP del destino y la compara con el número de red de su propia dirección IP. Si ambas se corresponden significa que se puede utilizar entrega directa, sino se ha de utilizar entrega indirecta.


18

1.6.3 El algoritmo de encaminamiento El método utilizado por un router o un host para averiguar la siguiente máquina a la que debe enviar un determinado datagrama se denomina genéricamente como el “algoritmo de encaminamiento”. La gran mayoría de algoritmos de encaminamiento utilizan “tablas de encaminamiento”. En las tablas de encaminamiento de cada host o router se almacena información sobre los posibles destinos y sobre cómo alcanzarlos. La información que contienen las tablas de encaminamiento debe ser mínima, ya que si cada tabla de encaminamiento contuviera información sobre cada posible dirección destino sería imposible mantener actualizadas las tablas. Además, las máquinas no tendrían suficiente espacio ni capacidad de proceso para manejarlas. Se trata de minimizar la información que deben guardar las tablas aplicando un esquema de ocultación de información global, manteniendo sólo la información local mínima necesaria. Afortunadamente el esquema de direccionamiento IP permite realizar esto de forma fácil: como se mencionó en la sección 1.2, la dirección IP se divide en número de red y en número de host. Mediante este esquema es posible almacenar números de red en las tablas de encaminamiento en lugar de direcciones IP completas. De esta forma se ocultan los detalles de qué hosts y cómo están conectados a las diferentes redes y se minimiza el tamaño de las tablas de encaminamiento. El contenido de las tablas de encaminamiento suelen ser pares del tipo <N,R>. Donde N es un número de red y R es la dirección IP del router en el siguiente salto para alcanzar dicha red (por tanto el router debe estar conectado a la misma red física). Para simplificar más las tablas de encaminamiento aparece el concepto de “ruta por defecto”. La ruta por defecto contiene la dirección del router del siguiente salto al que se deben enviar los datagramas (también denominado router por defecto) si tras recorrer la tabla de encaminamiento no se encontró ninguna ruta específica para el número de red al que va dirigido el datagrama. Aunque se ha comentado la conveniencia de encaminar en base al número de red destino, la tabla de encaminamiento permite especificar una ruta especial para un host en particular. De esta forma el algoritmo básico de encaminamiento de un datagrama IP es el siguiente:

1. Extraer la dirección IP destino D. 2. Computar el prefijo de red N con la máscara local. 3. Si N se corresponde con alguna red física a la que estamos conectados se realiza

entrega directa (realizando ARP). 4. Si no se puede realizar entrega directa, se comprueba si hay ruta específica para

D y en caso afirmativo se envía el datagrama al router del salto siguiente especificado en la tabla.

5. Si no hay ruta específica, se comprueba si hay una ruta para la red N y en caso afirmativo se envía el datagrama al router del salto siguiente especificado en la tabla.

6. Si no hay ruta para N, se envía el datagrama al router por defecto especificado en la tabla.

7. Si no hay ruta por defecto y el software de encaminamiento IP ha llegado a este punto se produce un error (que se puede reportar mediante ICMP).

Como conclusiones importantes del algoritmo de encaminamiento IP podemos destacar que:

1. En la mayor parte de implementaciones, el tráfico dirigido a una determinada red desde un host origen va a seguir el mismo camino aunque existan diversas posibilidades.

2. Sólo el último router de la ruta puede determinar si el host destino está disponible (estas situaciones se reportan mediante ICMP). Además también necesitamos reportes de los routers intermedios si sucede algún problema.


19

3. Los datagramas que viajen de A a B pueden seguir rutas diferentes a los datagramas que viajen de B a A.

La figura 1.11 muestra 4 redes interconectados a través de 2 routers y la tabla de rutas del router R1. Es importante entender que a excepción de la disminución del campo TTL el software de encaminamiento no modifica la cabecera del datagrama original. En particular, las direcciones IP origen y destino permanecen inalteradas durante toda la ruta5. Por lo que respecta a los datagramas entrantes:

• Cuando un datagrama llega a un host el driver del dispositivo de red lo entrega al software IP para su procesamiento. El software IP determina si el datagrama es para el propio host en cuyo caso lo pasa al software del protocolo de nivel alto apropiado. El datagrama se descarta si no es para el propio host.

• En el caso de los routers, estos deben encaminar el datagrama si no va dirigido hacia ellos. Decidir si una máquina es o no la destinataria de un datagrama no es una tarea tan trivial como a simple vista pueda parecer. En primer lugar pueden haber muchos interfaces de red cada uno de ellos con su correspondiente dirección IP, se debe comprobar la correspondiente identificación de subred (si la red está dividida) y además se deben reconocer los mensajes de broadcast y los de multicast.

Figura 1.11: Ejemplo de encaminamiento


20

2 Nivel de Transporte: los protocolos TCP (Transmission Control Protocol) y UDP (User Datagram Protocol)

2.1 Introducción Dos de los protocolos de transporte estandarizados en la torre TCP/IP son TCP (Transmission Control Protocol) y UDP (User Datagram Protocol). Previamente a describir TCP y UDP, veremos una clasificación de los protocolos en cuanto a cómo establecen la conexión y a su fiabilidad. Un protocolo puede clasificarse en función de cómo realiza la conexión en: Orientado a conexión. En este caso, para realizar un intercambio de información entre dos entidades se pueden distinguir las siguientes fases:

1. Establecimiento de la conexión 2. Intercambio de información 3. Cierre de la conexión

Una de las características de un servicio orientado a conexión es que una vez establecida la conexión, los mensajes llegan al receptor en el mismo orden en que fueron enviados por el emisor. Un ejemplo de este procedimiento es la comunicación a través del teléfono:

1. Establecimiento de la conexión: La persona llamante, inicia el establecimiento de la conexión descolgando el teléfono y marcando el número del abonado llamado. El abonado llamado descuelga el teléfono y la conexión ya está realizada. 2. Intercambio de información: Ambos abonados, llamante y llamado, conversan a través del teléfono. 3. Cierre de la conexión: Los abonados cuelgan el teléfono dando por finalizada la llamada.

No orientado a conexión. En este caso, el intercambio de información no necesita de las fases de establecimiento y cierre de la conexión. La entidad transmisora envía el mensaje sin que la receptora sepa que va a recibir ese mensaje. Un ejemplo de un servicio no orientado a conexión es el sistema postal. En este caso, el remitente envía una carta al destinatario. El destinatario sabe que el remitente le envió una carta en el momento en que la recibe. Otro parámetro que se utiliza para clasificar un protocolo es la fiabilidad del protocolo en cuanto a la entrega de la información. Se dice que un protocolo es fiable cuando implementa los mecanismos necesarios para que la información que transporta llegue al otro extremo libre de errores. Se dice que un protocolo es no fiable si no nos asegura la entrega de los mensajes al extremo receptor. Como ejemplo, Internet Protocol (IP) es un protocolo no orientado a conexión y no fiable. Es no orientado a conexión porque un datagrama IP se entrega a la red sin un establecimiento previo de la conexión y es no fiable porque no incorpora ningún mecanismo que nos informe de si el datagrama ha sido entregado al extremo receptor con éxito o si no ha podido ser entregado. Dado que IP es un protocolo no orientado a conexión, no fiable, los protocolos que estén por encima de IP (Nivel de Transporte) se van a tener que enfrentar con las siguientes situaciones de error:

1. Pérdida de una trama 2. Llegada de una trama fuera de orden 3. Duplicación de una trama 4. Modificación de los datos de la trama


21

TCP (Transmission Control Protocol) es un protocolo orientado a conexión y fiable. Esto nos indica que TCP va a tener que resolver las cuatro posibles situaciones de error que hemos visto para proporcionar un servicio orientado a conexión y fiable, a sus propios usuarios (por usuarios se entiende aquellos protocolos o aplicaciones que utilicen TCP como protocolo de transporte). UDP (User Datagram Protocol) es un protocolo no orientado a conexión y no fiable. Si una aplicación desea un servicio fiable, o bien utiliza TCP o si utiliza UDP deberá ser la aplicación quien implemente los mecanismos de fiabilidad. Obsérvese que el uso de TCP o UDP dependerá de varios aspectos. Entre ellos, y además de la fiabilidad, la eficiencia: Supongamos que vamos a realizar una conferencia telefónica durante la que estaremos hablando 10 minutos. El tiempo invertido en marcar el teléfono del abonado llamado y que éste descuelgue es de 30 segundos y el tiempo de "liberar la llamada" (despedirse y colgar el teléfono) de 5 segundos. El tiempo total invertido para completar toda la llamada será de 10*60+30+5=635 segundos y el tiempo invertido en el intercambio de información son 600 segundos. La eficiencia obtenida es de 600/635, 94.5%. Si el tiempo invertido en el intercambio de información hubiese sido de 5 segundos (decir solo una palabra) la eficiencia hubiera bajado al 12.5%. Un protocolo orientado a conexión (como TCP) utiliza un cierto tiempo en establecer y liberar la conexión. La fiabilidad de un protocolo puede ser un factor determinante, pero no siempre. Cuando se transmite voz, es más importante que las muestras de voz estén disponibles en los instantes requeridos en el receptor, que el hecho de que haya alguna muestra errónea, perdida o duplicada. Por esta razón, la mayoría de sistemas de transmisión multimedia sobre IP utilizan el protocolo UDP. Un ejemplo de protocolo no orientado a conexión y no fiable es el sistema postal de correos. En este sistema el remitente escribe una carta que posteriormente “encapsula” (introduce) en un sobre con la dirección del destinatario. Dicho sobre se entrega al servicio postal de correos, cuya misión es hacer llegar el sobre a la dirección del destinatario. El destinatario, a priori, no sabe que el remitente ha entregado el sobre al servicio postal de correos. Si durante el trasporte del sobre, éste se pierde, ni el destinatario, ni el remitente serán informados de este hecho (no fiable). Si el remitente desea enviar otra carta al mismo destinatario, debería introducirla de nuevo en un sobre con la dirección pertinente y entregarlo al servicio postal de correos. Si el transporte de este segundo sobre se realiza de forma más rápida que el primero (por ejemplo por avión), es posible que los sobres (y las cartas) lleguen “desordenados” (problema inherente a un servicio no orientado a conexión). Una de las características de un servicio no orientado a conexión es que las unidades de datos (los sobres) se manejan de forma independiente aunque la información transportada (las cartas) formen parte de una misma comunicación. Por esta razón, cada sobre debe llevar la dirección del destinatario. Obsérvese que en el ejemplo de la llamada telefónica (servicio orientado a conexión), la dirección (número de teléfono del abonado receptor) sólo se proporciona en el establecimiento de la conexión. No es difícil notar, que a pesar de tener un servicio no orientado a conexión y no fiable, nosotros (el escritor de cartas) puede utilizar mecanismos para obtener, finalmente, un servicio fiable. Estos mecanismos serían:

1. Para solucionar el problema de la fiabilidad, el remitente de la carta incluye una postdata pidiendo al destinatario una confirmación antes de 14 días. El remitente está suponiendo que en el peor de los casos, el servicio postal de correos no tardará más de 7 días en entregar la carta al remitente y 7 días más en recibir la


22

confirmación. Si en 14 días no ha recibido confirmación puede suponer que la carta que envío o la confirmación se ha perdido. En este caso vuelve a enviar la carta. 2. Para solucionar el problema de “ordenamiento”, las cartas se numeran de forma consecutiva. De esta forma el remitente sabe leerlas de forma “ordenada” o bien detectar qué carta se ha perdido. Finalmente, el siguiente ejemplo, muestra un servicio no orientado a conexión y fiable. Este caso es el de las empresas de transporte de paquetes (estilo “packet express”). Se deja como ejercicio al lector determinar porque es un servicio no orientado a conexión y fiable.

2.2 Puertos y sockets Para explicar qué son los puertos y los sockets lo realizaremos a través de un ejemplo. Supongamos que tenemos en un misma máquina (Maq-A) varios procesos comunicándose simultáneamente con otros tantos procesos en diversas maquinas (Maq-B, Maq-C ...). Cada vez que un datagrama IP llega a Maq-A, el nivel IP extrae la información y la pasa al nivel de transporte (UDP ó TCP). El nivel de transporte, realizará las funciones específicas según sea UDP o TCP y posteriormente debe entregar la información al proceso al cual va dirigida. El nivel de transporte en la torre TCP/IP, utiliza el concepto de puerto para demultiplexar la información recibida y entregarla a la aplicación correspondiente. El puerto es un número de 16 bits sin signo (0-65535) que se asigna a un proceso que quiere comunicarse a través de TCP/IP y ese número de puerto va encapsulado en los paquetes TCP y UDP. La Figura 4.1 muestra un ejemplo de lo que se acaba de describir. Un socket identifica de forma univoca una conexión entre dos procesos en TCP/IP. Refiriéndonos a la Figura 2.1, la conexión entre los procesos a y a’ está identificada por el socket (IP1, P1, IP2, P4) , es decir, dirección IP y puerto de origen y dirección IP y puerto de destino. Obsérvese que el número de puerto es local a la máquina; así dos procesos en máquinas diferentes pueden tener el mismo número de puerto.

Figura 2.1: Puertos y sockets


23

2.3 Arquitectura cliente-servidor En el mundo de TCP/IP las comunicaciones entre procesos siguen una arquitectura denominada clienteservidor. La idea es que un proceso actúa como un servidor (proporciona servicios a los clientes) y espera que algún cliente se conecte a él en demanda de un servicio. Otro proceso actúa como cliente y se conecta al servidor para obtener un servicio.

Figura 2.2: Arquitectura cliente servidor

Un ejemplo del funcionamiento es la conexión desde un navegador a un servidor de WEB. El servidor de WEB debe estar “esperando” que algún navegador se conecte a él con el fin de proporcionar una página HTML. Desde el punto de vista del usuario, primero arranca el navegador, luego se realiza la conexión y cuando el usuario se “ha cansado” de navegar, cierra el navegador, mientras que el servidor de WEB continúa “esperando” otras conexiones. La Figura 4.2 muestra el flujograma que describe este comportamiento. De esta arquitectura se deduce que un cliente debe conocer la IP y el puerto del servidor. Siguiendo con el ejemplo del navegador, si el usuario introduce la URL http://www.unizar.es, el navegador se conectará al puerto 80. Esto es debido a que hay una serie de puertos conocidos con el nombre de “well known ports” en los que se aconseja qué tipo de servicio deben proporcionar. Así el puerto 21 es para el servidor de ftp, 23 es para el servidor de telnet, el 25 para el servidor de SMTP (servicio de correo electrónico), el 80 para el servidor de http, etc. Esto no significa que todos los servidores WEB “escuchen” en el puerto 80, ya que es potestad del administrador del sistema decidir qué puerto utilizará su servidor WEB. Sin embargo, la mayoría de clientes tienen establecido un puerto por defecto para el servidor (como en el caso del navegador y el puerto 80), de forma que si se cambia el puerto de un servicio bien definido, sólo se logrará confundir al cliente (tanto el cliente software como al usuario que está utilizando ese cliente). A modo de ejemplo, si se desea utilizar un navegador para conectarnos a un puerto diferente del de defecto (por ejemplo el 8080), la forma de introducir la URL es http://nombre_servidor:8080. Si el servidor de WEB de la UZ estuviese en el puerto 8080, la URL sería http://www.unizar.es:8080.


24

2.4 User Datagram Protocol (UDP) Tal como se ha comentado UDP (User Datagram Protocol) es un protocolo no orientado a conexión y no fiable. La especificación oficial de UDP se encuentra en el RFC768. El formato y los campos de un datagrama UDP se muestran en la Figura 4.3. El campo de longitud se refiere a la longitud total, en bytes, de la cabecera y los datos. La aplicación que utiliza UDP, debe controlar el tamaño del paquete UDP (la cantidad de bytes enviados en un mismo

Figura 2.3: Datagrama UDP

paquete UDP) si quiere evitar que el nivel IP fragmente el paquete UDP porque se ha excedido el MTU (Maximum Transmission Unit) del medio físico. Por ejemplo, si el medio físico es una Ethernet con tramas Ethernet II, el campo de datos de la trama Ethernet tiene una longitud máxima de 1500 bytes. En este caso, la longitud máxima del datagrama IP encapsulado en una trama Ethernet sera de 1500 bytes. Si utilizamos UDP como protocolo de transporte, la cantidad de bytes de usuario (campo data del datagrama UDP) será como máximo 1500-20-8=1472 bytes (a 1500 se le resta la cabecera IP, usualmente 20 bytes, y la cabecera UDP, 8 bytes). El checksum incluye tanto la cabecera UDP como el campo de datos, (recordemos que el checksum de la cabecera de IP solo incluye la cabecera IP y no los datos del datagrama IP). En UDP el cálculo del checksum es opcional. Si el emisor no realiza el cálculo del checksum, envía este campo con ceros. Si el emisor realiza el cálculo del checksum y obtiene un valor 0, envía todo unos (65535) que es equivalente en aritmética de complemento a uno. Si el emisor calcula el checksum y el receptor detecta un checksum erróneo, el datagrama UDP se descarta silenciosamente (esta condición de error no se indica ni al emisor ni a los protocolos de nivel superior del receptor). 2.5 Transmission Control Protocol (TCP) TCP es un protocolo orientado a conexión, fiable. Específicamente, se dice que TCP proporciona un servicio de transporte de un flujo de bytes, orientado a conexión, fiable. El concepto de transporte de un flujo de bytes, indica que la aplicación entrega a TCP los bytes que desea transmitir y que TCP no interpretará esos bytes, únicamente los hará llegar a la aplicación receptora en el orden en que se los entregaron. En otras palabras, si una aplicación entrega 20 bytes a TCP, seguido de una entrega de 30 bytes, seguido de una entrega de 60 bytes, la aplicación receptora no sabe cuántas entregas se hicieron al TCP, sino que puede ocurrir que al leer los bytes recibidos, lo haga en cinco lecturas de 22 bytes. TCP proporciona fiabilidad utilizando los siguientes mecanismos:

• Los datos de la aplicación son fragmentados en lo que TCP considera que es el mejor tamaño para ser transmitidos.

• Cuando TCP envía un segmento, inicia un temporizador, esperando que el otro extremo reconozca la recepción correcta del segmento enviado. Si el


25

reconocimiento no ha sido recibido cuando el temporizador ya ha expirado, el extremo transmisor vuelve a enviar el mismo segmento.

• Cuando TCP recibe un segmento de datos, envía un reconocimiento al extremo que lo ha enviado.

• TCP incluye un checksum de la cabecera y los datos cuyo propósito es detectar cualquier modificación de los datos en tránsito. Si el checksum recibido es incorrecto, el segmento TCP se descarta silenciosamente y no se reconoce. Se espera que el temporizador del TCP del extremo opuesto expire y se lo vuelva a enviar. Este reconocimiento se denomina ACK (acknowledge).

• Dado que los segmentos TCP viajan encapsulados en datagramas IP, y dado que los datagramas IP pueden llegar desordenados, los segmentos TCP pueden llegar desordenados. El TCP del extremo receptor reordena, si es necesario, los segmentos recibidos y entrega, a la aplicación, los datos en el orden correcto.

• Dado que los datagramas IP pueden llegar duplicados, TCP debe descartar los segmentos TCP duplicados.

• TCP también proporciona control de flujo. Los extremos TCP tienen una cantidad finita de espacio de almacenamiento. El extremo TCP receptor indica al extremo TCP emisor cuánto espacio de almacenamiento tiene para los datos recibidos. De esta forma se previene que un ordenador cuyo ritmo de generación de datos es alto pueda superar la capacidad de recibir y procesar datos del ordenador receptor.

El sistema que utiliza TCP para proporcionar fiabilidad se engloba en los llamados protocolos de ventana deslizante. 2.5.1 Protocolos de ventana deslizante La pregunta que nos hacemos es, ¿cómo puede un protocolo proporcionar un servicio de transferencia fiable sobre un sistema de comunicaciones no fiable? Una de las técnicas más utilizadas es el ARQ (Automatic Repeat Request) o petición de retransmisión automática. En ARQ, el receptor informa al emisor del éxito o fracaso de la última transmisión, a través de una trama de reconocimiento. Los reconocimientos pueden ser positivos (reconocimiento de éxito) y negativos (reconocimiento de errores en la trama recibida). No todos los protocolos utilizan simultáneamente ambos tipos de reconocimiento. Por ejemplo TCP sólo utiliza reconocimientos positivos y cuando hay errores no envía nada, utilizando temporizadores para las retransmisiones. En la Figura 2.4 se muestra la transmisión de dos tramas con reconocimiento. Este sistema se conoce con el nombre de Stop & Wait porque después de enviar un paquete, el emisor debe parar de transmitir y esperar la recepción del reconocimiento. Obsérvese que el tiempo efectivo utilizado para transmitir una trama es desde el inicio de la transmisión de la trama hasta que se recibe el reconocimiento. En este caso la eficiencia de transmisión es baja, puesto que el hecho de que el emisor deba esperar el reconocimiento le imposibilita para seguir transmitiendo.


26

Figura 2.4: Stop&Wait

Supongamos que modificamos el algoritmo de manera que el emisor pueda tener como máximo F tramas no reconocidas. El emisor podrá enviar como máximo F tramas sin recibir reconocimiento de ellas. F se denomina el tamaño de la ventana y en cuanto reciba el reconocimiento de la primera trama (ACK(1)), podrá enviar una nueva trama, y así sucesivamente. Este es el caso representado en la Figura 4.5, para un tamaño de ventana F=6.

Figura 2.5: Ventana deslizante

El hecho de utilizar ventana deslizante implica que las tramas de información deben ir numeradas para que los reconocimientos indiquen mediante este número qué trama ha sido recibida correcta o incorrectamente. Es importante destacar que en un sistema de ventana deslizante, no es necesario enviar una trama de reconocimiento por cada trama de datos. Se puede reconocer con una sola trama de reconocimiento varias tramas de datos teniendo en cuenta que si se han enviado 3 tramas de datos y se reconoce la trama 3, entonces, de forma automática, quedan reconocidas la 1 y la 2. Es habitual que en una comunicación entre dos ordenadores, cada uno de ellos actúe simultáneamente de emisor y receptor, ya que la información suele fluir tanto en un sentido como en el otro. Para aumentar la


27

eficiencia, el paquete de información incluye un campo utilizado para reconocimiento, evitándose el tener que enviar tramas de reconocimiento y de información diferentes cuando ambas tramas viajan en el mismo sentido. A esta técnica se le conoce con el nombre de piggybacking. 2.5.2 TCP y la ventana deslizante TCP utiliza un mecanismo especializado de ventana deslizante con objeto de mejorar la eficiencia de transmisión y realizar un control de flujo. Como se ha comentado anteriormente, TCP ve los datos de usuario como un flujo de bytes que divide en segmentos para ser transmitidos. Por esta razón TCP no numera los segmentos sino los octetos transmitidos y a su vez, los reconocimientos reconocen octetos recibidos y no segmentos recibidos. En TCP el tamaño de ventana indica el número de octetos que pueden ser enviados y el receptor indica al emisor, en cada trama enviada, qué tamaño de ventana tiene disponible para recibir el siguiente segmento, realizando, de esta manera, el control de flujo. Si se indica un tamaño de ventana 0, el emisor deja de enviar segmentos hasta que recibe otro paquete indicando un tamaño de ventana distinto de 0. 2.5.3 El segmento TCP La Figura 2.6 muestra cómo es el segmento TCP.

Figura 2.6: Segmento TCP

Los primeros 32 bits indican los puertos origen y destino. Los siguientes 32 bits son el número de secuencia. El número de secuencia identifica el byte del flujo de datos que está siendo enviado y que ocupa la primera posición en el campo de datos del segmento. El primer byte de un flujo en un segmento TCP no lleva el número 1 como número de secuencia, sino que se elige un número aleatorio (Inital Sequence Number) en cada conexión realizada y este número representa el número de secuencia del primer byte a transmitir durante esa conexión. Si el ISN de una conexión es el 1415531521, el primer byte estaría identificado por este mismo número y el segundo sería 1415531521 + 1, y así sucesivamente. De esta forma si un segmento TCP llega a una conexión equivocada (cosa bastante inverosímil), los números de secuencia de ambas conexiones no podrían a llegar a confundirse nunca, ya que ambas conexiones utilizaron un ISN muy diferente y los datos


28

que llegaron a la conexión equivocada nunca serán pasados a la aplicación equivocada (el TCP generaría un error al recibir un número de secuencia no esperado). El campo del número de reconocimiento (acknowledge number) se utiliza para almacenar el número del siguiente byte que se espera recibir. Este campo sólo se decodifica si el flag ACK está activado. Si se recibió un paquete de datos con el número de secuencia 1415531521 y con 100 bytes de datos (desde el 1415531521 hasta el 1415531620), el segmento TCP de respuesta llevaría activado el flag ACK y el número de reconocimiento sería el 1415531621, puesto que espera recibir el siguiente al 1415531620. El campo hdr len (Header Length) indica la longitud de la cabecera que puede llevar opciones haciendo que la longitud de la cabecera varíe. A continuación vienen 6 bits reservados (no se utilizan) y 6 bits que actúan de flags:

• urg: Urgent Pointer válido • ack: Número de reconocimiento válido • psh: Segmento con datos de usuario. Pasarlos a la aplicación tan pronto como sea

posible. • rst: Reinicio de la conexión • syn: Inicio de conexión • fin: Final de conexión

El campo window size es de 16 bits e indica el tamaño de ventana en bytes. Los 16 bits siguientes se utilizan para el checksum y los siguientes 16 bits para indicar un urgent pointer. Existen varias opciones en TCP, y la más utilizada es el MSS (Maximum Segment Size). Cada extremo de una conexión indica al otro cuál es el tamaño máximo de segmento que desea recibir. Este valor se especifica dentro del campo de opciones al inicio de la conexión.


29

3 Ethernet conmutada 3.1 Introducción Las redes de área local son aquellas que conectan una red de ordenadores normalmente confinadas en un área geográfica, como un solo edificio o un campus de la universidad. Las LAN, sin embargo, no son necesariamente simples de planificar, ya que pueden unir muchos centenares de ordenadores y pueden ser usadas por muchos miles de usuarios. El desarrollo de varias normas de protocolos de red y medios físicos han hecho posible la proliferación de LAN's en grandes organizaciones multinacionales, aplicaciones industriales y educativas. Ethernet es la capa física más popular la tecnología LAN usada actualmente. Otros tipos de LAN incluyen Token Ring, Fast Ethernet, FDDI, ATM y LocalTalk. Ethernet es popular porque permite un buen equilibrio entre velocidad, costo y facilidad de instalación. Estos puntos fuertes, combinados con la amplia aceptación en el mercado y la habilidad de soportar virtualmente todos los protocolos de red populares, hacen a Ethernet la tecnología ideal para la red de la mayoría los usuarios de la informática actual. La norma de Ethernet fue definida por el Instituto para los Ingenieros Eléctricos y Electrónicos (IEEE) como IEEE Standard 802.3. Adhiriéndose a la norma de IEEE, los equipo y protocolos de red pueden interoperar eficazmente. 10BASE-T Ethernet y Fast Ethernet conectan una red de ordenadores mediante una topología de estrella. Generalmente un ordenador se sitúa a un extremo del segmento, y el otro extremo se termina en una situación central con un concentrador. La principal ventaja de este tipo de red es la fiabilidad, dado que si uno de los segmentos "punto a punto" tiene una rotura, afectará sólo a los dos nodos en ese eslabón. Otros usuarios de los ordenadores de la red continuarán operando como si ese segmento no existiera. En la figura 3.1 podemos ver un ejemplo de la topología en estrella.

Figura 3.1: Topología de red en estrella


30

3.2 Elementos de una red Ethernet conmutada Concentradores (hubs): Los concentradores son, repetidores para cableado de par trenzado. Un concentrador, al igual que un repetidor, toma cualquier señal entrante y la repite hacia todos los puertos. Lo más importante a resaltar sobre los concentradores es que sólo permiten a los usuarios compartir Ethernet. Una red que contenga solamente repetidores es denominada "Ethernet compartido", lo que implica que todos los miembros de la red están contendiendo por la transmisión de datos hacia una sola red (dominio de colisión). Esto significa que miembros individuales de una red compartida sólo consiguen un porcentaje del ancho de banda de red disponible. Conmutadores (switches): Los conmutadores ocupan el mismo lugar en la red que los concentradores. A diferencia de los concentradores, los conmutadores examinan cada paquete y lo procesan en consecuencia en lugar de simplemente repetir la señal a todos los puertos. Los conmutadores trazan las direcciones Ethernet de los nodos que residen en cada segmento de la red y permiten sólo el tráfico necesario para atravesar el conmutador. Cuando un paquete es recibido por el conmutador, el conmutador examina las direcciones hardware (MAC) fuente y destino y las compara con una tabla de segmentos de la red y direcciones. Si los segmentos son iguales, el paquete se descarta ("se filtra"); si los segmentos son diferentes, entonces el paquete es "remitido" al segmento apropiado. Además, los conmutadores previenen la difusión de paquetes erróneos al no remitirlos. El filtrado de paquetes, y la regeneración de paquetes remitidos permite a la tecnología de conmutación dividir una red en dominios de colisión separados. La regeneración de paquetes permite diseñar redes de mayores distancias y más nodos, y disminuyen drásticamente los ratios de colisión globales. En redes conmutadas, cada segmento es un dominio de colisión independiente. En redes compartidas todos los nodos residen en un sólo gran dominio de colisión compartido. Los conmutadores LAN tienen, básicamente, dos arquitecturas, "store and forward" (almacenar y remitir) y "cut through" (cortar y atravesar). Inicialmente, los modelos "cut through", tenían una ventaja de velocidad porque cuando un paquete entra en el conmutador, sólo se examina la dirección del destino antes de remitirlo a su segmento de destino. Un conmutador "store and forward", por otro lado, acepta y analiza el paquete completo antes de remitirlo a su destino. Ello conlleva más tiempo para examinar el paquete entero, pero permite al conmutador detectar ciertos errores del paquete e impedir su propagación a través de la red. Actualmente, la velocidad de los conmutadores "store and forward" ha alcanzado a los "cut through" hasta el punto en que la diferencia entre ambos es mínima. Hay también, un gran número de conmutadores híbridos que mezclan ambas arquitecturas. Ambos conmutadores separan la red en dominios de colisión, permitiendo extender las reglas de diseño de la red. Cada uno de los segmentos conectados a un conmutador Ethernet tiene el ancho de bando completo de 10 Mbps., compartido por menos usuarios, lo que resulta en unas mejores prestaciones (en oposición a los concentradores que sólo permiten compartir el ancho de banda de una sola red Ethernet). Los nuevos conmutadores ofrecen enlaces de gran velocidad, como FDDI, Fast Ethernet o ATM, que pueden usarse para comunicar conmutadores o proporcionar anchos de banda superiores a servidores particularmente importantes que tienen mucho tráfico. En la figura 3.2 se puede ver un ejemplo del funcionamiento de los concentradores y los conmutadores.


31

Figura 3.2: Conmutadores y concentradores En la figura 3.3 podemos ver un ejemplo de las ventajas que tiene la utilización de una red ethernet conmutada.

Figura 3.3: Ejemplos de ethernet conmutada y compartida

En efecto, el ancho de banda en el caso A está compartido por todos los usuarios de la red. De esta forma, la comunicación entre PC1 y PC7 afectará a todos los demás PC conectados

PC1 PC2

PC3 PC4 PC5

PC6

PC7

PC1

PC2PC3

PC4 PC5

PC6

PC1PC2

PC3

PC4 PC5


32

a la red. En el caso D, la comunicación entre PC4 y PC5 no afectará en absoluto al resto de la red ya que el switch encamina los paquetes sólo a través del puerto al que está conectado el PC5 en caso de que el transmisor sea el PC4 y viceversa. 3.3 Ethernet conmutada en el laboratorio de telemática 3.3.1 Composición del puesto de trabajo El puesto de prácticas será denominado bancada, distinguiéndose por su numeración: 1, 2, 3, 4, 5 y 6. Cada bancada constará de cuatro ordenadores: PCN1 PCN2, PCN3 y PCN4, siendo N el número de la bancada. En la figura 3.4 podemos ver una bancada. También disponemos de un hub, al cual están conectados los cuatro PC de la bancada de prácticas, siendo PCN1 el ordenador que está más cerca de la pizarra y PCN4 el que se encuentra en la ventana. Por último se dispone de un switch por cada dos bancadas.

Figura 3.4: Bancada 3

A partir de ahora los hub serán nominados como hub1, hub2, hub3 y hub4, en clara alusión a la bancada que corresponda, lo mismo se hará con los switch, que recibirán el nombre de switch12 y switch34. Las direcciones IP de estos dispositivos vienen en el ANEXO I. Para el desarrollo de la práctica será de gran ayuda apuntar las direcciones IP y MAC de las máquinas que la componen, tanto PC, hub como switch.


33

Por último, advertir de la existencia de dos posibles esquemas de conexiones, dependiendo de la bancada en la que nos encontremos. Estas configuraciones se pueden ver en la figura 3.5.

Figura 3.5: Hubs y switch dedicados a dos bancadas.

El detalle de conexiones para las bancadas impares se puede ver en la figura 3.6 y para las bancadas pares en la 3.7.

Figura 3.6: Bancadas impares Figura 3.7: Bancadas pares

Switch

Hub impar

PC N1 PC N2 PC N3 PC N4

7 8 9

1 7 9 3 4 5 6

PC N1 PC N2 PC N3 PC N4

Switch

Hub par

1 7 9 3 4 5 6 10 11 12

Switch

Hub 2Hub 1


34

3.3.2 Superstack II 12 port PS hub 40 3.3.2.1 Características Generales Este hub dispone de 12 puertos l0baseT RJ45, con la posibilidad de generar 4 segmentos. A todos los efectos un segmento del hub se comporta como un hub diferente. De esta forma, si tenemos segmentado el hub en 2 segmentos diferentes, los paquetes entrantes por uno de los segmentos sólo se retransmitirán a los puertos pertenecientes a ese segmento y no a los del otro segmento. La segmentación de los hub es una opción muy interesante para la distribución de la carga en las redes LAN. Estos puertos pueden estar conectados a la tarjeta Ethernet de un ordenador mediante un cable directo, o conectado a otro hub o switch a través de un cable cruzado. Además dispone de un puerto de consola DB9, con los parámetros siguientes: 9600 kbps, 8 bits de datos y 1 bit de parada. Por último existen dos puertos (13 y 14) para apilar varios hub, permitiendo de esta forma el crecimiento de la red. Estas conexiones vienen representadas en la siguiente figura, junto con la posibilidad de utilizar hasta 4 segmentos, como si fueran 4 hub aislados entre sí. 3.3.2.2 Uso del PS Hub En la figura 3.8 podemos ver los LEDs de diagnóstico del hub y su correspondiente utilidad así como los puertos de consola y cascada.

Figura 3.8: Detalle de los LEDs y puertos del hub.


35

En la figura 3.9 se nos muestran los puertos que tenemos disponibles en el hub.

Figura 3.9: Detalle de los puertos del hub.


36

3.3.2.3 Gestión del PS Hub Existen diversos métodos para gestionar un hub, pero antes de pasar a describir cada uno de ellos, vamos a ver qué es lo que se puede gestionar en un hub. En la figura 3.10 se muestra el detalle de las opciones que se encuentran disponibles para la gestión.

Figura 3.10: Comandos disponibles para la gestión de hub En la figura 3.15 podemos ver para qué se utiliza cada uno de los comandos mostrados en la figura 3.10. Gestión mediante interfaz de comandos El interface de línea de commandos nos permite de una forma directa configurar el hub cuando entramos por primera vez al equipo. También nos permite habilitar los demás métodos de gestión.


37

Gestión mediante el protocolo Telnet El protocolo TELNET proporciona una interfaz estandarizada, a través de la cual un programa de un host (el cliente de TELNET) puede acceder a los recursos de otro host (el servidor de TELNET) como si el cliente fuera una terminal local conectada al servidor. Gestión mediante el interface WEB Los hubs del laboratorio también disponen de un interfaz WEB para su gestión. De esta forma, para acceder a la gestión del dispositivo, lo único que tenemos que hacer es introducir la dirección IP del dispositivo en la URL de un navegador WEB y accederemos al interface WEB de gestión. Las opciones que podemos gestionar a través de este método son las mismas que con los métodos anteriores pero ahora las encontramos organizadas de forma gráfica. En la figura 3.11 podemos ver la página principal de gestión de un hub.

Figura 3.11: Pantalla del navegador en la gestión WEB. Gestión mediante agente SNMP SNMP (Protocolo de Administración de Red Simple o "Simple Network Management Protocol") esta basado en IP y define un conjunto de objetos que los administradores pueden interrogar en los dispositivos de red. Estos objetos se definen como atributos MIB (Base de Información de Gestión o "Management Information Base") y puede ser propietarios o adecuarse a las normas establecidas. El software SNMP ejecutándose en un servidor puede acceder a la información de SNMP en dispositivos de la red que soportan el protocolo. Como ejemplos de software de administración podemos mencionar HP Openview y el NetManager de Sun, que ofrecen gráficas mejorando la presentación de la información SNMP.


38

3.3.3 Superstack II switch 1100 3.3.3.1 Características generales El Switch 1100 es un conmutador gestionable que viene equipado con los siguientes puertos:

• 12 o 24 puertos Ethernet 10BASE-T • Dos puertos Fast Ethernet auto-negociables 10BASE-T/100BASE-TX

En concreto, el que se encuentra en el laboratorio de redes es el modelo de 12 puertos. Las características principales de los switch de estas series son las siguientes:

• Cada usuario dispone de 10 Mb reales como ancho de banda • Elimina la pérdida de paquetes por colisiones • Ofrece una máxima protección y un mínimo número de errores • Instalación simple y rápida • Tecnología PACE que mejora la transmisión de datos multimedia • Soporte para la implementación de redes virtuales • Gestión SNMP, incluyendo RMON

3.3.3.2 Conexiones del switch En las figuras, 3.12 y 3.13 podemos ver el esquema de conexiones de que dispone el switch.

Figura 3.12: Vista frontal del switch

Figura 3.13: Vista del reverso switch 3.3.3.2 Gestión del switch


39

Al igual que el hub, el switvh se puede gestionar a través de línea de comandos, protocolo TELNET, interfaz WEB y protocolo SNMP. Ya que estos métodos de gestión han sido introducidos en el hub, aquí no se va a volver a repetir. La figura 3.14 nos muestra todas las opciones que podemos gestionar en el switch.

Figura 3.14: Comandos para la gestión del switch La figura 3.15 nos ofrece de una forma esquemática qué representa cada una de las opciones de gestión.


40

Figura 3.15: Resumen de los comandos de gestión 4 Realización de la práctica 4.1 PARTE I: Estudio de los equipos de una red ethernet conmutada


41

4.1.1 Hub Superstack II Vamos a establecer dos clasificaciones posibles para la gestión del hub: A.-La primera de ellas se basa en el tipo de puerto al cual se conecta el equipo de gestión. 1.-Puerto de consola: utilizado como tal o conectado a un MODEM

2.-Puerto Ethernet: situado comúnmente en el segmento 1 del hub, con una dirección IP asignada.

B.-La segunda clasificación está en función del servidor utilizado para la gestión: 1.-Interfaz línea de comandos: Directamente sobre una consola.

2.-TELNET. Conectándonos a un servidor telnet situado en el hub, con una presentación similar a la interfaz línea de comandos. 3.-HTTP. Utilizando el protocolo http, conectándonos a un servidor web residente en el propio hub. Siendo necesario el uso de un navegador. 4.-SNMP/RMON. Donde el hub actúa como agente SNMP/RMON, siendo necesario un gestor externo.

Llegados a este punto vamos a poner en práctica cuatro métodos de gestión: Interfaz de comandos, servidor TELNET, servidor HTTP y servidor SNMP/RMON. Por motivos de seguridad, para poder acceder al hub será necesario introducir un login de usuario y su clave correspondiente. Existen varios usuarios posibles, de los cuales comentaremos dos, cuyos login son security y monitor, cada uno con unos privilegios asignados diferentes. El usuario security tiene asignados todos los privilegios, lo que permite realizar cambios en la configuración. El usuario monitor únicamente puede ver el estado del hub, sin modificarlo. El usuario que utilizaremos será security y la clave se facilitará en la propia sesión de prácticas. A continuación lo que haremos será conectarnos a los diferentes servidores de gestión del hub y realizar una serie de acciones de gestión sobre los mismos: Interfaz de comandos Este procedimiento lo usaremos para entrar por primera vez en el equipo. En un primer momento, el equipo no tiene ninguna dirección IP asignada, por lo que el único medio que tenemos para gestionar el equipo es a través de la línea de comandos. Para ello nos aseguramos que conectamos el puerto serie del ordenador al puerto de consola del equipo y lanzamos cualquier aplicación de emulación de terminal que tengamos en el ordenador. Servidor TELNET Nos conectamos desde un único PC, por ejemplo el PCN1, al servidor telnet del hub, utilizando el siguiente comando:

• telnet hubN (siendo hubN la dirección IP del hub).

Una vez conectados vemos que el entorno es el mismo que para la interfaz de comandos. A continuación nos disponemos a realizar una serie de funciones relacionadas con los puertos y los segmentos del hub:

1. Comprobamos las estadísticas de los puertos del hub. Prestamos atención al estado de los mismos y al segmento al que pertenecen. Vemos cómo se puede modificar del estado de los puertos

2. Analizamos la información detallada de cada uno de los segmentos del hub.


42

3. Realizamos pruebas relacionadas con la segmentación del hub. Por defecto, todos los puertos se encuentran en el segmento 1. Si realizamos un ping por ejemplo, desde PCN1 a PCN3, podemos comprobar que el destino es alcanzable. A continuación, segmentamos el hub, dejando el puerto al que está conectado PCN3 en el segmento 2 y repetimos la operación.

4. Si conectamos el ordenador a un segmento que no sea el 1, no se puede realizar una conexión remota. Esto ocurre por motivos de seguridad. Podemos comprobarlo intentando acceder desde el PCN3, que ahora se encuentra en el segmento 2.

5. Comprobamos cuáles son los principales parámetros IP del hub y cómo pueden modificarse.

Servidor HTTP

Nos conectamos al servidor web del hub, utilizando un navegador. Una vez conectados se puede apreciar que el entorno es mucho más amigable que los anteriores. Comprobamos cómo podemos realizar la gestión del hub a través del interfaz web:

1. Vemos los parámetros del puerto serie, así como los puertos que sirven para el apilado.

2. Comprobamos los segmentos del hub y los puertos que tienen conectados. Vemos en detalle las características de los puertos y comprobamos cómo podemos segmentar el hub de manera sencilla.

3. Verificamos los IP del hub y localizamos dónde se encuentra la dirección Ethernet del mismo.

Puede comprobarse que hay parámetros que no aparecen en el servidor telnet y sí lo hacen en HTTP. Esto ocurre al tratarse de programaciones distintas en los distintos servidores.

Servidor SNMP

La conexión al servidor SNMP del hub se realizará utilizando los siguientes comandos: snmpwalk, snmpget o snmpset. Este método es menos intuitivo que los anteriores, ya que se necesita conocer la codificación ASN.1 (MIB) de los parámetros de configuración del hub. Por otra parte, es el más eficiente, siendo utilizado por todos los programas comeciales de gestión de redes. Las acciones a realizar son las siguientes:

1. Verificar los segmentos que componen el hub. snmpwalk IP comunidad .1.3.6.1.4.1.43.10.26.1.1.1.5, siendo IP la dirección del hub. El valor de comunidad se facilitará en la propia sesión de prácticas. El resultado del comando será una lista de los puertos del hub y el segmento al que están asignados. Las 14 primeras se corresponden con los puertos del hub y las 4 siguientes, con los 4 segmentos del mismo. Podemos ver a qué segmento pertenece cada puerto a partir del número al que es igual cada fila (valor numérico de la interfaz de gestión).

2. Modificar el puerto 10 poniéndolo en el segmento 2, snmpset IP comunidad .1.3.6.1.4.1.43.10.26.1.1.1.5.1.10 i seg-2 // snmpwalk IP comunidad .1.3.6.1.4.1.43.10.26.1.1.1.5, para comprobar el cambio realizado.

3. Comprobar los valores de direccionamiento IP. snmpget IP comunidad .1.3.6.1.4.1.43.10.27.1.1.1.15.1

Como respuesta obtendremos un valor numérico de la interfaz de gestión, que deberemos utilizar en el siguiente comando.

snmpget IP comunidad .1.3.6.1.4.1.43.10.28.1.1.2.valor, nos devuelve el valor de la dirección IP del hub


43

snmpget IP comunidad .1.3.6.1.4.1.43.10.28.1.1.3.valor, nos devuelve el valor de la máscara de la dirección IP del hub

snmpget IP comunidad .1.3.6.1.4.1.43.10.28.1.1.4.valor, nos devuelve el valor de la dirección IP del router por defecto.

4. Modificar la dirección IP del router por defecto. snmpset IP comunidad .1.3.6.1.4.1.43.10.28.1.1.4.valor a IP_router

En definitiva, para poner un ejemplo de comparación entre los tres servidores remotos, hemos visto el tiempo que se tarda en comprobar la segmentación del hub.

• El uso de SNMP nos proporciona la respuesta más rápida, aunque tenga el entorno más "árido".

• El uso de telnet es más amigable pero el tiempo de respuesta es mayor.

• El tiempo de respuesta del servidor web es el mayor, aunque se sitúa en un entorno de utilización al cual todos estamos acostumbrados (el navegador).

• El servidor SNMP permite modificar cualquier valor, cosa que no ocurría en los otros servidores, que dependían de su programación.

4.1.2 Superstack II switch 1100 Los escenarios para la gestión del switch son muy parecidos a los del hub. Por supuesto cambian los parámetros a definir, dadas las diferencias operativas de los equipos. Al igual que con el hub, vamos a probar en los switch algunos escenarios para la gestión, ambos a través de Ethernet, concretamente la conexión TELNET y la HTTP. Para poder acceder al switch es necesario introducir un login y su clave correspondiente, lo haremos mediante el login monitor, cuyo password se facilitará en la propia sesión. Las acciones a realizar serán las siguientes: PROTOCOLO TELNET Vamos a conectarnos desde dos clientes telnet a cada uno de los switch. Lo haremos desde PCN2 y PCN4. -Encontrar la dirección Ethernet del switch. -Verificar los datos de IP del switch. -Comprobar el funcionamiento de la conexión IP en Ethernet mediante un ping al router por defecto. -Verificar la velocidad de cada puerto, su estado y su funcionamiento en half o full duplex. PROTOCOLO HTTP En este caso nos conectaremos desde un único cliente http, para no cargar el servidor del hub. Lo haremos desde PCN3. -Encontrar la dirección Ethernet del switch. -Verificar los datos de IP del switch. -Verificar la velocidad de cada puerto y su funcionamiento en half o full duplex. -Comprobar la tabla de direcciones MAC en cada puerto.


44

4.2 PARTE II: Análisis del comportamiento de la red Ethernet mediante el programa IPERF

El programa IPERF permite establecer comunicaciones cliente-servidor TCP y UDP y medir el ancho de banda que experimentan de manera sencilla. A continuación se describe el funcionamiento básico de este programa. Para más detalle, acudir al manual incluido en un anexo de la práctica o la ayuda en linux (iperf --help). Para establecer una comunicación entre dos equipos, uno de ellos debe configurase como servidor y otro como cliente. En primer lugar debe configurarse el servidor, y una vez q éste está activo, se configura el cliente. El tráfico fluye de cliente a servidor durante el tiempo que dure la conexión. Una vez finalizada, el servidor permanece activo, a la espera de que el cliente realice otra petición. Para configurar el servidor debe teclearse iperf –s y para configurar el cliente iperf –c @IP_servidor Algunas opciones interesantes son: -t: duración de la conexión (por defecto 10 segundos) -i: tiempo entre estadísticas -u: para indicar que la conexión es UDP (por defecto TCP) -b: ancho de banda (en el caso de conexión UDP, por defecto 1Mbps)

-l: En el caso de UDP, campo de datos del paquete UDP. (por defecto 1470 bytes) Por ejemplo, si queremos establecer una conexión UDP con un ancho de banda de 2 Mbps, con una duración de 30 segundos y sacando estadísticas cada 2 segundos, deberíamos hacer: Servidor: iperf –s –u Cliente: iperf –c @IP_servidor –u –t 30 –i 2 –b 2m Una vez entendido el funcionamiento del programa, vamos a realizar las siguientes pruebas 4.2.1 Ethernet compartida - Estando los 4 PCs de la bancada en el segmento 1 del hub, generamos tráfico TCP

entre PCN1 y PCN3 y observamos el ancho de banda obtenido. A continuación establecemos otra conexión con las mismas características entre PCN2 y PCN4, de manera que se simultaneen ambas conexiones. ¿Cuál es el ancho de banda ahora? ¿Por qué?

- A continuación, pasamos PCN2 y PCN4 al segmento 2 del hub, y volvemos a establecer las dos conexiones. ¿Qué está ocurriendo ahora?

4.2.2 Análisis de la eficiencia de la red Ethernet - Vamos a generar varias conexiones UDP entre PCN1 y PCN3 variando el tamaño del

campo de datos del paquete UDP con estos valores: 1470 (valor por defecto), 500 y 200 bytes. Todas las conexiones se van a generar con un ancho de banda de 10 megabits por segundo, que teóricamente es el máximo proporcionado por la red Ethernet. Anotar los valores obtenidos en cada caso y justificarlos teóricamente. DATOS: Cabecera UDP: 8bytes. Cabecera IP: 20 bytes. Overhead total Ethernet (Cabecera + Preámbulo + Gap): 38 bytes.


45

4.3 PARTE III: Desarrollo de una herramienta de medida del ancho de banda En el apartado anterior, hemos visto que disponemos de herramientas que nos permiten generar tráfico entre dos equipos y medir el ancho de banda que experimenta la comunicación de una manera automatizada. A continuación, para entender mejor el proceso de medida de ancho de banda y los conceptos asociados, vamos a realizar un análisis detallado del mismo. Para ello, utilizaremos un generador de tráfico muy sencillo, capturaremos los paquetes generados mediante el programa Wireshark y finalmente se implementará un programa en MatLab que permita procesar la traza de paquetes capturada y calcular el ancho de banda de la comunicación a partir de dicha traza. Todo el proceso se realizará en entorno Windows. Para generar tráfico, vamos a emplear un programa desarrollado en C++. Para poder ejecutarlo, así como observar el código fuente del mismo, abrimos el programa Microsoft Visual Studio y caragamos el workspace packet_generator.

Figura 4.1: Interfaz gráfico del generador de tráfico

Si ejecutamos el programa (build -> excute packet_generator.exe o el icono correspondiente de la barra de herramientas) aparece el interfaz gráfico de gestión del generador, en el que debemos especificar los siguientes parámetros:

- Longitud de los paquetes (en bytes): El tamaño de los paquetes generados sigue una distribución uniforme cuyo valor medio se especifica en este campo. Dicha longitud es la asociada al campo de datos del paquete UDP generado.

- Tiempo entre paquetes (en ms.): Valor medio del tiempo entre la generación de

cada paquete. Dicho tiempo también sigue una distribución uniforme.

A partir de estos dos parámetros, puede obtenerse de forma directa la tasa de transmisión efecitva de datos de la comunicación.

- Dirección IP destino: La dirección IP fuente viene fijada por el equipo desde el

que se genera el tráfico. Debemos especificar la dirección IP destino del equipo al que queremos mandar el tráfico.


46

- Puerto destino y Puerto origen: Para tener completamente definido el socket que

vamos a establecer, debe especificarse el puerto origen y el destino. En principio, podemos dar cualquier valor entre 0 y 65535 a ambos parámetros, pero es mejor evitar los valores bajos, que pueden entrar en conflicto con los usados por procesos del sistema. Elegir valores superiores a 1000, por ejemplo.

Pulsando el botón Generar comienza la transmisión de paquetes, que permanecerá activa hasta que se pulse el botón Parar. Para capturar el tráfico asociado a la comunicación, empleamos el programa Wireshark, que nos permite exportar a un fichero de texto la traza de la transmisión capturada. A partir de dicha traza, se debe implementar un programa en MatLab que lea el fichero y que realice el procesado oportuno para obtener el ancho de banda de la transmisión. Se desea obtener el ancho de banda medio de toda la traza, así como la evolución del ancho de banda cada cierto intervalo de tiempo, cuyo valor debe ser un parámetro configurable del programa. Algunos comandos interesantes de MatLab para realizar la lectura del fichero son: fopen, fgets, sscanf o strcmp entre otros. Para obtener detalles sobre el funcionamiento concreto de dichos comandos o de otros similares, emplear la ayuda de MatLab (help nombre_comando)


47

ANEXO I HUB1 IP LAN: 155.210.157.5 máscara: 255.255.255.0 HUB2 IP LAN: 155.210.157.21 máscara: 255.255.255.0 HUB3 IP LAN: 155.210.157.37 máscara: 255.255.255.0 HUB4 IP LAN: 155.210.157.53 máscara: 255.255.255.0 HUB5 IP LAN: 155.210.157.69 máscara: 255.255.255.0 HUB6 IP LAN: 155.210.157.85 máscara: 255.255.255.0 SWITCH12 IP LAN: 155.210.157.13 máscara: 255.255.255.0 SWITCH34 IP LAN: 155.210.157.45 máscara: 255.255.255.0

02.redes ethernet

Documents