02.redes Ethernet

Introduccin a las redes IP.
Ethernet conmutada

Dpt. Ingeniera Electrnica y Comunicaciones
rea de Ingeniera Telemtica

Laboratorio de Telemtica Prctica 1. Introduccin a las redes IP. Ethernet conmutada

2


3
ndice
1. Nivel de Red: el protocolo IP (Internet Protocol)......5
1.1.Introduccin ..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 fragmentacin de datagramas IP11
1.4. Resolucin de direcciones (ARP)......12
1.5. Las subredes...14
1.6. Encaminamiento IP16
1.6.1. Introduccin.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. Introduccin20
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. Introduccin....29
3.2. Elementos de una red Ethernet conmutada30
3.3. Ethernet conmutada en el laboratorio de telemtica...31
3.3.1. Composicin del puesto de trabajo..31
3.3.2. Superstack II 12 port PS hub 40..32
3.3.2.1. Caractersticas Generales.32
3.3.2.2. Uso del PS Hub34
3.3.2.3. Gestin del PS Hub..36
3.3.3. Superstack II switch 110038
3.3.3.1. Caractersticas generales..38
3.3.3.2. Conexiones del swicth..38
3.3.3.3. Gestin del switch39

4. Realizacin de la prctica...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: Anlisis del comportamiento de la red Ethernet mediante el
programa IPERF...44
4.2.1. Ethernet compartida...44
4.2.2. Anlisis de la eficiencia de la red Ethernet44
4.3. PARTE III: Desarrollo de una herramienta de medida del ancho de banda.45

ANEXO I...47

4
Introduccin a las redes IP. Ethernet conmutada
Prctica
Presentacin de la Prctica
Objetivos
Estudiar y entender las redes IP y en particular las redes de rea local
Construir y analizar el trfico de una red LAN Ethernet, mediante diferentes hub o
segmentos de hub conectados entre s a travs de un switch.
Estructura documento
Este documento comienza introduciendo los conceptos bsicos asociados a las
redes IP, como son el direccionamiento y la formacin de subredes.
Tambin se dan las nociones bsicas de la red de rea local ms ampliamente
utilizada en la actualidad: Ethernet conmutada
La realizacin prctica se centra en la implementacin de una red ethernet
conmutada. Veremos cmo se puede gestionar y tambin cmo se puede analizar el
trfico que viaja por ella.


5
1 Nivel de Red: el protocolo IP (Internet Protocol)

1.1 Introduccin

Los protocolos de red se disean en forma de capas o niveles, donde cada nivel es
responsable de una faceta diferente de las comunicaciones. Una torre de protocolos es la
combinacin 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 fsicamente diferentes (como pueden ser Ethernet, Token Ring, X.25, Frame
Relay, ATM...) en una red aparentemente homognea, lo que se conoce como interconexin
de redes. De esta forma IP oculta las redes fsicas subyacentes creando por encima de stas
una nica red virtual o red de redes, donde:

Hay un esquema de identificacin (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 nmero nico de 32 bits (en IPv4, Internet
Protocol versin 4 ) llamado direccin IP.
Los datos viajan por la red virtual IP agrupados en paquetes denominados
datagramas. La manipulacin de estos datagramas por parte de la red sigue un
mtodo 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 conexin.
o La red se esfuerza al mximo 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 controlarn protocolos superiores). El protocolo IP asume
pocas cosas de las capas inferiores, slo que los datagramas probablemente sern
transportados al host de destino.

1.2 Las direcciones de Internet

Las direcciones de Internet pueden ser simblicas o numricas:
Las direcciones simblicas son las que usualmente utilizamos los humanos porque
son ms fciles de recordar que las numricas. Estas direcciones son cadenas de
caracteres separadas por puntos. Por ejemplo: www.unizar.es
Las direcciones numricas son las que usualmente utiliza el software IP. La forma
numrica es una secuencia de 32 bits. Para que sea ms inteligible, habitualmente se
expresa en forma de nmeros decimales separados por puntos (dotted-decimal en
ingls), donde cada decimal representa 8 bits (rango 0-255). Por ejemplo, la
direccin binaria 10011011. 11010010. 00001100. 00010100 se puede expresar en
notacin decimal como 155.210.12.20 (que a su vez se corresponde con la direccin
simblica www.unizar.es). Las funciones de mapeo entre las direcciones
simblicas y las direcciones numricas las realiza el DNS (Domain Name System).
Una direccin no identifica una mquina en Internet, sino a un determinado
interfaz de red de la mquina. Dicho de otra forma, la direccin IP identifica a una
determinada mquina en una determinada red fsica. Cuando la mquina est
conectada a ms de una red se la denomina "multi-homed" y tiene una direccin por
cada interfaz de red. En realidad, para interpretar correctamente una determinada
direccin IP se necesita una segunda secuencia de 32 bits denominada mscara
(netmask). La mscara se utiliza para dividir la direccin en dos partes:
La parte de red, denominada formalmente nmero de red (RFC 1166), aunque en
ocasiones se usan los trminos direccin de red y netID. Los nmeros de red estn
administrados centralmente por el INTERNIC ( INTErnet Network Information
Center) y son nicos en toda Internet. Cuando se solicita al INTERNIC una
direccin IP, no se asigna una direccin a cada mquina individual, sino que se da

7
un nmero de red, permitiendo asignar segn las necesidades todas las direcciones
IP vlidas dentro de este rango.
La parte de host, denominada formalmente nmero de host, aunque
ocasionalmente se usan los trminos direccin de host y hostID. Para dividir una
direccin IP en nmero de red y nmero de host se utiliza la mscara, de manera
que aquellos bits de la direccin donde la mscara tiene un "1" forman parte del
nmero de red, mientras que las posiciones donde la mscara tiene 0 forman
parte del nmero de host. Por ejemplo si tenemos la direccin 10011011. 11010010.
00001100. 00010100 con una mscara 11111111. 11111111. 00000000. 00000000
tenemos un nmero de red 10011011. 11010010. y un nmero de 00001100.
00010100. Por convenio el nmero de red se encuentra en los bits ms
significativos (los bits de la izquierda de la direccin) mientras que el nmero de host
se suele encontrar en los bits menos significativos (los bits de la derecha de la
direccin). Adems los nmeros de red y host suelen estar formados por bits
consecutivos de la direccin IP (es muy extrao ver mscaras con ceros y unos no
consecutivos). La mscara de red tambin se suele representar en formato decimal,
de manera que para el ejemplo anterior tenemos la direccin 155.210.12.20 y la
mscara 255.255.0.0. Otra manera de representar una direccin IP es poniendo la
direccin en formato decimal y la mscara como un nmero decimal que indica
cuntos unos consecutivos forman el nmero de red. As para nuestro ejemplo, la
direccin 155.210.12.20 con mscara 255.255.0.0 se puede escribir como
155.210.12.20/16. El tamao de la parte dedicada al host depende del tamao de la
red. Para satisfacer mltiples necesidades se han definido varias clases de redes,
fijando diferentes puntos donde dividir la direccin 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 mquinas por red. Por lo tanto, la
mscara 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 direccin de host reservada posible sera
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 mscara 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 direccin de host posible reservada sera
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 mscara 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 direccin 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 multidifusin.

Clase E
Las direcciones que estn en el rango 240.0.0.0 hasta 247.255.255.255 son
experimentales o estn 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 direccin IP donde todos los bits de la parte de host son cero se refiere
a la direccin de la red misma.
Una direccin donde todos los bits de la parte de host son uno se denomina
direccin de difusin (o broadcast), ya que hace referencia a todas las
mquinas de la red especfica. As 147.83.20.255 no es un hostid vlido, 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 estn reservadas. La primera direccin se llama
encaminamiento por defecto (por donde IP encamina los datagramas), y la
segunda es la direccin de loopback. La red 127.0.0.0 est reservada para el
trfico local IP de la mquina. Normalmente la direccin 127.0.0.1 se asigna
a una interfaz de la mquina (la interfaz de loopback) que acta 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. Bsicamente 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 mxima (MTU,
Maximum Transfer Unit), dependiendo del hardware de red usado. Para Ethernet, esta es
tpicamente de 1500 bytes. En vez de limitar el datagrama a un tamao mximo, IP puede
tratar la fragmentacin y el reensamblado de sus datagramas. En particular, IP no impone
un tamao mximo, pero establece que todas las redes deberan ser capaces de manejar al
menos 576 bytes. Los fragmentos de datagramas tienen todos una cabecera, copiada
bsicamente del datagrama original, y de los datos que la siguen. Los fragmentos se tratan
como datagramas normales mientras son transportados a su destino. Ntese, sin embargo,
que si uno de los fragmentos se pierde, todo el datagrama se considerar perdido, y los
restantes fragmentos tambin se considerarn 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 versin del protocolo IP. La versin 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 indicacin de la calidad del servicio solicitado
para este datagrama IP. Una descripcin 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 nmero nico que asigna el emisor para ayudar a reensamblar un
datagrama fragmentado. Los fragmentos de un datagrama tendrn el mismo nmero de
identificacin.

Flags son flags para el control de fragmentacin.
Donde:
El bit 0 est reservado y debe ser 0.
El bit DF significa no fragmentar (Do not Fragment). Con 0 se permite
fragmentacin y con 1 no.
El bit MF significa que hay ms fragmentos (More Fragments). Con 0 significa que se
trata del ltimo fragmento del datagrama y con 1 que hay ms 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 nmero 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 ms en una cuenta de saltos que en una mtrica 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 debera fijar el protocolo de alto nivel que
crea el datagrama.

Protocol indica el nmero oficial del protocolo de alto nivel al que IP debera
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 podra haber llegado a un destino equivocado.

11
Source IP Address es la direccin IP de 32 bits del host emisor.

Destination IP Address es la direccin 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 depuracin, por tanto no se requiere que toda
implementacin 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 funcin de la opcin seleccionada. Algunas
opciones tienen una longitud de un solo byte y otras tienen longitudes variables. El
primer byte de cualquier opcin 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 nmero de opcin
dentro de cada clase.

1.3.2 La fragmentacin de datagramas IP

Cuando un datagrama IP viaja de un host a otro puede cruzar distintas redes fsicas. Las
redes fsicas imponen un tamao mximo 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 ms pequeos 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 fragmentacin y el reensamblado
tendrn 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 tamao mnimo posible de los datos
en un fragmento (8 bytes). Las implementaciones de IP no estn obligadas a manejar
datagramas sin fragmentar mayores de 576 bytes, pero la mayora podr manipular valores
ms grandes, tpicamente ligeramente por encima de 8192 bytes o incluso mayores, y
raramente menos de 1500. Un datagrama sin fragmentar tiene a cero toda la informacin
de fragmentacin. Es decir, los flags FC y FO estn a 0. Cuando se ha de realizar la
fragmentacin, se ejecutan los siguientes pasos:

12
Se chequea el bit de flag DF para ver si se permite fragmentacin. Si est a uno, el
datagrama se desecha y se devuelve un error al emisor usando ICMP 1(Internet
Control Message Protocol).
Basndose en el valor MTU, el campo de datos se divide en partes donde cada
parte, excepto la ltima, debe ser mltiplo 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 localizacin de la porcin 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 slo 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 enva 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 nmero
nico dentro de los lmites impuestos por el uso de un nmero de 16 bits. Como la
fragmentacin 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. Adems el campo Protocol tambin se chequea.
Los fragmentos que van llegando se copian en el buffer en la localizacin indicada
por el campo FO.
Cuando han llegado todos los fragmentos, se restaura el datagrama original y se
contina 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 Resolucin de direcciones (ARP)

En una sola red fsica, los hosts individuales se conocen en la red a travs de sus
direcciones fsicas 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 direccin es una direccin IP) de la red virtual. Los drivers del dispositivo de
red de la red fsica (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 traduccin de
direcciones de nivel 3 a direcciones de nivel 2. En el caso de redes IP sobre Ethernet, la
traduccin se realiza de direccin IP a direccin Ethernet (que es una secuencia de 48 bits).
Esta traduccin se realiza en el host mediante una tabla usualmente denominada cach

13
ARP. Cuando la direccin no se encuentra en la cach ARP el host utiliza el protocolo
ARP (Address Resolution Protocol) para averiguarla. ARP es un protocolo de
peticin/respuesta. La peticin se enva en forma de broadcast de nivel 2 a la red. Si una de
las mquinas de la red reconoce su propia direccin IP en la peticin, devuelve una
respuesta ARP al host que la solicit. La respuesta contendr la direccin fsica
correspondiente a la direccin IP solicitada. Esta direccin se almacenar en la cach ARP
del host solicitante. Todos los posteriores datagramas enviados a esta direccin IP se podrn
asociar a la direccin fsica 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 aplicacin desea enviar datos a una determinada direccin IP de destino, el software
de encaminamiento IP determina en primer lugar la direccin 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 debera enviar. A continuacin se consulta el mdulo ARP para hallar la direccin
fsica. El mdulo ARP intenta hallar la direccin en su cach. Si la encuentra, devuelve la
correspondiente direccin fsica. 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 direccin fsica. Cuando un host recibe un paquete ARP
(bien un broadcast o una respuesta punto a punto), el dispositivo receptor pasa el paquete
al mdulo ARP, que lo aadir a la cach ARP. La prxima vez que un protocolo de nivel
superior quiera enviar un paquete a ese host, el mdulo de ARP encontrar la direccin
hardware, a la que se enviar el paquete.


14

Figura 1.9: Ejemplo de ARP

1.5 Las subredes

Es obvio que una direccin de clase A slo se asignar a redes con un elevado nmero de
hosts, y que las direcciones de clase C son adecuadas para redes con pocos hosts. Sin
embargo, esto significa que las redes de tamao medio (aquellas con ms de 254 hosts o en
las que se espera que en el futuro haya ms de 254 hosts) deben usar direcciones de clase B.
El nmero de redes de tamao pequeo y medio ha ido creciendo muy rpidamente en los
ltimos aos y se tema que, de haber permitido que se mantuviera este crecimiento, todas
las direcciones de clase B se habran 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
seccin 1.2 cada parte de la direccin IP (nmero de red y nmero de host) es
responsabilidad de entidades diferentes: el nmero de red es asignado por INTERNIC,
mientras que la asignacin de los nmeros de host es responsabilidad de la autoridad que
controla la red. Como veremos a continuacin el nmero de host puede dividirse an ms:
esta divisin tambin 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 estndar se volvi demasiado rgido para permitir cambiar
con facilidad la configuracin de redes locales. Estos cambios podan ser necesarios cuando:

Se instala una nueva red fsica.
El crecimiento del nmero de hosts requiere dividir la red local en dos o ms redes.

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

15
denominarse direccin local o parte local. La creacin 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 direccin IP como un nmero de host. La divisin de la
parte local de la direccin IP en nmeros de subred y de host queda a libre eleccin 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 pblicas de Internet, que dividen en subredes para despus asignarlas
a sus clientes. La divisin se efecta empleando una mscara de red diferente a las que
dividen las direcciones IP en clases estndar. El funcionamiento de estas mscaras es
equivalente al que se describe en la seccin 1.2 para las clases estndar, es decir, los bits a
cero en esta mscara indican posiciones de bits correspondientes al nmero de host, y los
que estn a uno, indican posiciones de bits correspondientes al nmero de subred. Las
posiciones de la mscara pertenecientes al nmero 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 direccin IP con subredes del mismo modo que a una direccin IP
que no las tenga. Notar que al hacer subnetting, el nmero de mquinas sobre las que se hace
broadcast (difusin) se reduce, optimizando el trfico 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 direccin de broadcast. Supongamos que hemos de repartir este
direccionamiento en dos subredes de la misma dimensin, 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 algn 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,
quedndonos 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 continuacin resumimos las direcciones
de red, de mscara y de hosts implicadas en el subnetting de este ejemplo.

Red bsica original: 11000000. 10101000. 00000001. 00000000 = 192.168.1.0/24
Mscara: 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 quedarn 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 Introduccin
La funcin ms importante de la capa IP es el encaminamiento de datagramas extremo a
extremo a travs de la red virtual. Por tanto esta funcin proporciona los mecanismos
necesarios para interconectar distintas redes fsicas. La formacin de la red virtual que
conecta mltiples 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 enva tramas entre ellos.
El hub sirve como prolongacin del cable fsico que conecta las mquinas de la LAN y su
nica funcin es difundir la seal que llega por un cierto puerto (entrada) al resto de
puertos. Los hubs pueden ser pasivos (si no amplifican las seales recibidas por sus puertos)
o activos (si las amplifican).

El conmutador (switch) es un dispositivo parecido al hub pero en el que se realiza
conmutacin entre sus diferentes puertos, es decir, conmuta los paquetes observando sus
direcciones fsicas origen/destino.

Un puente (bridge) interconecta segmentos de LAN a nivel de interfaz de red y enva
tramas entre ellos. Un puente realiza la funcin de retransmisin MAC (Medium Access
Control) y es independiente de cualquier capa superior (incluyendo LLC). Proporciona, si se
necesita, conversin de protocolos a nivel MAC. Un puente es transparente para IP. Es
decir, cuando un host enva un datagrama a otro host en una red con el que se conecta a
travs de un puente, enva 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
mquinas que tiene en cada puerto y aislar el trfico y las colisiones de cada tramo LAN.

Un router interconecta redes fsicas 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
transmisin as como tamaos ptimos para los datagramas realizando fragmentacin 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
transformacin de datos entre distintos entornos para conseguir conectividad entre los
extremos de la comunicacin. Las pasarelas tpicamente proporcionan conectividad de dos
redes para un subconjunto de protocolos de aplicacin soportados en cada una de ellas.
Una pasarela es opaca para IP. Es decir, un host no puede enviar un datagrama IP a travs
de una pasarela: slo puede enviarlo a la pasarela. La pasarela se ocupa de transmitirlo a la
otra red con la informacin 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
circulacin 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 transmisin de un datagrama desde el host origen hasta el
host destino a travs de una sola red fsica, dicho de otra forma, dos hosts slo
pueden comunicarse mediante entrega directa si ambos estn conectados
directamente a la misma red fsica (por ejemplo, una sola red Ethernet).
Bsicamente en la entrega directa el emisor encapsula el datagrama dentro de una
trama fsica, transforma la direccin IP destino en una direccin fsica y enva la
trama resultante al destino a travs 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 fsicas, y para ello es necesario atravesar routers. La entrega indirecta es
ms compleja ya que el host origen ha de identificar al router al que debe entregar el
datagrama, el primer router debe identificar cul ser el siguiente router al que debe
enviar el datagrama, esto tambin se denomina identificar el siguiente salto. La
comunicacin 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 fsica, sino no es posible su
comunicacin. A su vez, el ltimo router de la ruta que sigue el datagrama debe estar
conectado a la misma red fsica 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 fsica mediante el prefijo de red. El host origen extrae
el nmero de red de la direccin IP del destino y la compara con el nmero de red de su
propia direccin 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 mtodo utilizado por un router o un host para averiguar la siguiente mquina a la que debe
enviar un determinado datagrama se denomina genricamente como el algoritmo de
encaminamiento. La gran mayora de algoritmos de encaminamiento utilizan tablas de
encaminamiento. En las tablas de encaminamiento de cada host o router se almacena
informacin sobre los posibles destinos y sobre cmo alcanzarlos. La informacin que
contienen las tablas de encaminamiento debe ser mnima, ya que si cada tabla de
encaminamiento contuviera informacin sobre cada posible direccin destino sera
imposible mantener actualizadas las tablas. Adems, las mquinas no tendran suficiente
espacio ni capacidad de proceso para manejarlas. Se trata de minimizar la informacin que
deben guardar las tablas aplicando un esquema de ocultacin de informacin global,
manteniendo slo la informacin local mnima necesaria. Afortunadamente el esquema de
direccionamiento IP permite realizar esto de forma fcil: como se mencion en la seccin
1.2, la direccin IP se divide en nmero de red y en nmero de host. Mediante este esquema
es posible almacenar nmeros de red en las tablas de encaminamiento en lugar de
direcciones IP completas. De esta forma se ocultan los detalles de qu hosts y cmo estn
conectados a las diferentes redes y se minimiza el tamao de las tablas de encaminamiento.
El contenido de las tablas de encaminamiento suelen ser pares del tipo <N,R>. Donde N
es un nmero de red y R es la direccin IP del router en el siguiente salto para alcanzar dicha
red (por tanto el router debe estar conectado a la misma red fsica). Para simplificar ms las
tablas de encaminamiento aparece el concepto de ruta por defecto. La ruta por defecto
contiene la direccin del router del siguiente salto al que se deben enviar los datagramas
(tambin denominado router por defecto) si tras recorrer la tabla de encaminamiento no se
encontr ninguna ruta especfica para el nmero de red al que va dirigido el datagrama.
Aunque se ha comentado la conveniencia de encaminar en base al nmero de red destino,
la tabla de encaminamiento permite especificar una ruta especial para un host en particular.
De esta forma el algoritmo bsico de encaminamiento de un datagrama IP es el siguiente:

1. Extraer la direccin IP destino D.
2. Computar el prefijo de red N con la mscara local.
3. Si N se corresponde con alguna red fsica a la que estamos conectados se realiza
entrega directa (realizando ARP).
4. Si no se puede realizar entrega directa, se comprueba si hay ruta especfica para
D y en caso afirmativo se enva el datagrama al router del salto siguiente
especificado en la tabla.
5. Si no hay ruta especfica, se comprueba si hay una ruta para la red N y en caso
afirmativo se enva el datagrama al router del salto siguiente especificado en la
tabla.
6. Si no hay ruta para N, se enva 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 trfico dirigido a una determinada red
desde un host origen va a seguir el mismo camino aunque existan diversas
posibilidades.
2. Slo el ltimo router de la ruta puede determinar si el host destino est disponible
(estas situaciones se reportan mediante ICMP). Adems tambin necesitamos
reportes de los routers intermedios si sucede algn 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 travs de 2 routers y la tabla de rutas del
router R1. Es importante entender que a excepcin de la disminucin 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 mquina 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 direccin IP, se
debe comprobar la correspondiente identificacin de subred (si la red est dividida)
y adems 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 Introduccin
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 clasificacin de los protocolos en cuanto a cmo establecen la conexin
y a su fiabilidad. Un protocolo puede clasificarse en funcin de cmo realiza la conexin en:

Orientado a conexin. En este caso, para realizar un intercambio de informacin entre
dos entidades se pueden distinguir las siguientes fases:

1. Establecimiento de la conexin
2. Intercambio de informacin
3. Cierre de la conexin

Una de las caractersticas de un servicio orientado a conexin es que una vez establecida la
conexin, los mensajes llegan al receptor en el mismo orden en que fueron enviados por el
emisor. Un ejemplo de este procedimiento es la comunicacin a travs del telfono:

1. Establecimiento de la conexin: La persona llamante, inicia el establecimiento de
la conexin descolgando el telfono y marcando el nmero del abonado llamado. El
abonado llamado descuelga el telfono y la conexin ya est realizada.
2. Intercambio de informacin: Ambos abonados, llamante y llamado, conversan a
travs del telfono.
3. Cierre de la conexin: Los abonados cuelgan el telfono dando por finalizada la
llamada.

No orientado a conexin. En este caso, el intercambio de informacin no necesita de las
fases de establecimiento y cierre de la conexin. La entidad transmisora enva el mensaje
sin que la receptora sepa que va a recibir ese mensaje. Un ejemplo de un servicio no
orientado a conexin es el sistema postal. En este caso, el remitente enva una carta al
destinatario. El destinatario sabe que el remitente le envi una carta en el momento en que
la recibe. Otro parmetro que se utiliza para clasificar un protocolo es la fiabilidad del
protocolo en cuanto a la entrega de la informacin. Se dice que un protocolo es fiable
cuando implementa los mecanismos necesarios para que la informacin 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 conexin y no fiable. Es no orientado a conexin
porque un datagrama IP se entrega a la red sin un establecimiento previo de la conexin y
es no fiable porque no incorpora ningn 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 conexin, no fiable, los protocolos que estn por encima de
IP (Nivel de Transporte) se van a tener que enfrentar con las siguientes situaciones de error:

1. Prdida de una trama
2. Llegada de una trama fuera de orden
3. Duplicacin de una trama
4. Modificacin de los datos de la trama

21

TCP (Transmission Control Protocol) es un protocolo orientado a conexin 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 conexin 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 conexin y no fiable. Si una
aplicacin desea un servicio fiable, o bien utiliza TCP o si utiliza UDP deber ser la
aplicacin quien implemente los mecanismos de fiabilidad.

Obsrvese que el uso de TCP o UDP depender de varios aspectos. Entre ellos, y adems
de la fiabilidad, la eficiencia: Supongamos que vamos a realizar una conferencia telefnica
durante la que estaremos hablando 10 minutos. El tiempo invertido en marcar el telfono
del abonado llamado y que ste descuelgue es de 30 segundos y el tiempo de "liberar la
llamada" (despedirse y colgar el telfono) 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 informacin son 600 segundos. La eficiencia obtenida es de 600/635,
94.5%. Si el tiempo invertido en el intercambio de informacin hubiese sido de 5 segundos
(decir solo una palabra) la eficiencia hubiera bajado al 12.5%. Un protocolo orientado a
conexin (como TCP) utiliza un cierto tiempo en establecer y liberar la conexin. La
fiabilidad de un protocolo puede ser un factor determinante, pero no siempre. Cuando se
transmite voz, es ms importante que las muestras de voz estn disponibles en los instantes
requeridos en el receptor, que el hecho de que haya alguna muestra errnea, perdida o
duplicada. Por esta razn, la mayora de sistemas de transmisin multimedia sobre IP
utilizan el protocolo UDP. Un ejemplo de protocolo no orientado a conexin 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 direccin del destinatario.
Dicho sobre se entrega al servicio postal de correos, cuya misin es hacer llegar el sobre a
la direccin 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 sern informados de este hecho (no fiable). Si el remitente
desea enviar otra carta al mismo destinatario, debera introducirla de nuevo en un sobre
con la direccin pertinente y entregarlo al servicio postal de correos. Si el transporte de este
segundo sobre se realiza de forma ms rpida que el primero (por ejemplo por avin), es
posible que los sobres (y las cartas) lleguen desordenados (problema inherente a un
servicio no orientado a conexin). Una de las caractersticas de un servicio no orientado a
conexin es que las unidades de datos (los sobres) se manejan de forma independiente
aunque la informacin transportada (las cartas) formen parte de una misma comunicacin.
Por esta razn, cada sobre debe llevar la direccin del destinatario. Obsrvese que en el
ejemplo de la llamada telefnica (servicio orientado a conexin), la direccin (nmero de
telfono del abonado receptor) slo se proporciona en el establecimiento de la conexin.

No es difcil notar, que a pesar de tener un servicio no orientado a conexin y no fiable,
nosotros (el escritor de cartas) puede utilizar mecanismos para obtener, finalmente, un
servicio fiable. Estos mecanismos seran:

1. Para solucionar el problema de la fiabilidad, el remitente de la carta incluye una
postdata pidiendo al destinatario una confirmacin antes de 14 das. El remitente
est suponiendo que en el peor de los casos, el servicio postal de correos no tardar
ms de 7 das en entregar la carta al remitente y 7 das ms en recibir la

22
confirmacin. Si en 14 das no ha recibido confirmacin puede suponer que la carta
que envo o la confirmacin 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 conexin 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 conexin y fiable.

2.2 Puertos y sockets

Para explicar qu son los puertos y los sockets lo realizaremos a travs de un ejemplo.
Supongamos que tenemos en un misma mquina (Maq-A) varios procesos comunicndose
simultneamente 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 informacin y la pasa al nivel
de transporte (UDP TCP). El nivel de transporte, realizar las funciones especficas segn
sea UDP o TCP y posteriormente debe entregar la informacin al proceso al cual va
dirigida. El nivel de transporte en la torre TCP/IP, utiliza el concepto de puerto para
demultiplexar la informacin recibida y entregarla a la aplicacin correspondiente. El
puerto es un nmero de 16 bits sin signo (0-65535) que se asigna a un proceso que quiere
comunicarse a travs de TCP/IP y ese nmero 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 conexin entre dos procesos en TCP/IP. Refirindonos a
la Figura 2.1, la conexin entre los procesos a y a est identificada por el socket (IP
1
, P1,
IP
2
, P4) , es decir, direccin IP y puerto de origen y direccin IP y puerto de destino.
Obsrvese que el nmero de puerto es local a la mquina; as dos procesos en mquinas
diferentes pueden tener el mismo nmero 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 acta como un servidor
(proporciona servicios a los clientes) y espera que algn cliente se conecte a l en demanda
de un servicio. Otro proceso acta como cliente y se conecta al servidor para obtener un
servicio.

Figura 2.2: Arquitectura cliente servidor

Un ejemplo del funcionamiento es la conexin desde un navegador a un servidor de WEB.
El servidor de WEB debe estar esperando que algn navegador se conecte a l con el fin
de proporcionar una pgina HTML. Desde el punto de vista del usuario, primero arranca el
navegador, luego se realiza la conexin y cuando el usuario se ha cansado de navegar,
cierra el navegador, mientras que el servidor de WEB contina 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 electrnico), 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 mayora 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, slo 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 sera 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
conexin y no fiable. La especificacin 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 aplicacin que
utiliza UDP, debe controlar el tamao 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 fsico. Por ejemplo, si el medio
fsico es una Ethernet con tramas Ethernet II, el campo de datos de la trama Ethernet tiene una
longitud mxima de 1500 bytes. En este caso, la longitud mxima 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
mximo 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 clculo del checksum es opcional. Si el emisor no
realiza el clculo del checksum, enva este campo con ceros. Si el emisor realiza el clculo del
checksum y obtiene un valor 0, enva todo unos (65535) que es equivalente en aritmtica de
complemento a uno. Si el emisor calcula el checksum y el receptor detecta un checksum
errneo, el datagrama UDP se descarta silenciosamente (esta condicin 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 conexin, fiable. Especficamente, se dice que TCP
proporciona un servicio de transporte de un flujo de bytes, orientado a conexin, fiable. El
concepto de transporte de un flujo de bytes, indica que la aplicacin entrega a TCP los bytes
que desea transmitir y que TCP no interpretar esos bytes, nicamente los har llegar a la
aplicacin receptora en el orden en que se los entregaron. En otras palabras, si una
aplicacin entrega 20 bytes a TCP, seguido de una entrega de 30 bytes, seguido de una
entrega de 60 bytes, la aplicacin receptora no sabe cuntas 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 aplicacin son fragmentados en lo que TCP considera que es el
mejor tamao para ser transmitidos.
Cuando TCP enva un segmento, inicia un temporizador, esperando que el otro
extremo reconozca la recepcin 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, enva un reconocimiento al extremo
que lo ha enviado.
TCP incluye un checksum de la cabecera y los datos cuyo propsito es detectar
cualquier modificacin de los datos en trnsito. 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 aplicacin, los datos en el orden correcto.
Dado que los datagramas IP pueden llegar duplicados, TCP debe descartar los
segmentos TCP duplicados.
TCP tambin proporciona control de flujo. Los extremos TCP tienen una cantidad
finita de espacio de almacenamiento. El extremo TCP receptor indica al extremo
TCP emisor cunto espacio de almacenamiento tiene para los datos recibidos. De
esta forma se previene que un ordenador cuyo ritmo de generacin 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, cmo puede un protocolo proporcionar un servicio de
transferencia fiable sobre un sistema de comunicaciones no fiable? Una de las tcnicas ms
utilizadas es el ARQ (Automatic Repeat Request) o peticin de retransmisin automtica. En
ARQ, el receptor informa al emisor del xito o fracaso de la ltima transmisin, a travs 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 simultneamente ambos tipos de reconocimiento. Por ejemplo TCP
slo utiliza reconocimientos positivos y cuando hay errores no enva nada, utilizando
temporizadores para las retransmisiones. En la Figura 2.4 se muestra la transmisin de dos
tramas con reconocimiento. Este sistema se conoce con el nombre de Stop & Wait porque
despus de enviar un paquete, el emisor debe parar de transmitir y esperar la recepcin del
reconocimiento. Obsrvese que el tiempo efectivo utilizado para transmitir una trama es
desde el inicio de la transmisin de la trama hasta que se recibe el reconocimiento. En este
caso la eficiencia de transmisin 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
mximo F tramas no reconocidas. El emisor podr enviar como mximo F tramas sin
recibir reconocimiento de ellas. F se denomina el tamao 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 tamao de ventana
F=6.

Figura 2.5: Ventana deslizante

El hecho de utilizar ventana deslizante implica que las tramas de informacin deben ir
numeradas para que los reconocimientos indiquen mediante este nmero 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 automtica, quedan reconocidas la 1 y la 2. Es habitual que en una comunicacin
entre dos ordenadores, cada uno de ellos acte simultneamente de emisor y receptor, ya
que la informacin suele fluir tanto en un sentido como en el otro. Para aumentar la

27
eficiencia, el paquete de informacin incluye un campo utilizado para reconocimiento,
evitndose el tener que enviar tramas de reconocimiento y de informacin diferentes
cuando ambas tramas viajan en el mismo sentido. A esta tcnica 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 transmisin 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 razn 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 tamao de ventana indica el nmero de octetos que
pueden ser enviados y el receptor indica al emisor, en cada trama enviada, qu tamao de
ventana tiene disponible para recibir el siguiente segmento, realizando, de esta manera, el
control de flujo. Si se indica un tamao de ventana 0, el emisor deja de enviar segmentos
hasta que recibe otro paquete indicando un tamao de ventana distinto de 0.

2.5.3 El segmento TCP

La Figura 2.6 muestra cmo 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
nmero de secuencia. El nmero de secuencia identifica el byte del flujo de datos que est
siendo enviado y que ocupa la primera posicin en el campo de datos del segmento. El
primer byte de un flujo en un segmento TCP no lleva el nmero 1 como nmero de
secuencia, sino que se elige un nmero aleatorio (Inital Sequence Number) en cada conexin
realizada y este nmero representa el nmero de secuencia del primer byte a transmitir
durante esa conexin. Si el ISN de una conexin es el 1415531521, el primer byte estara
identificado por este mismo nmero y el segundo sera 1415531521 + 1, y as
sucesivamente. De esta forma si un segmento TCP llega a una conexin equivocada (cosa
bastante inverosmil), los nmeros de secuencia de ambas conexiones no podran a llegar a
confundirse nunca, ya que ambas conexiones utilizaron un ISN muy diferente y los datos

28
que llegaron a la conexin equivocada nunca sern pasados a la aplicacin equivocada (el
TCP generara un error al recibir un nmero de secuencia no esperado). El campo del
nmero de reconocimiento (acknowledge number) se utiliza para almacenar el nmero del
siguiente byte que se espera recibir. Este campo slo se decodifica si el flag ACK est
activado. Si se recibi un paquete de datos con el nmero de secuencia 1415531521 y con
100 bytes de datos (desde el 1415531521 hasta el 1415531620), el segmento TCP de
respuesta llevara activado el flag ACK y el nmero de reconocimiento sera 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 vare. A continuacin vienen 6 bits reservados (no se utilizan) y 6 bits que actan
de flags:

urg: Urgent Pointer vlido
ack: Nmero de reconocimiento vlido
psh: Segmento con datos de usuario. Pasarlos a la aplicacin tan pronto como sea
posible.
rst: Reinicio de la conexin
syn: Inicio de conexin
fin: Final de conexin

El campo window size es de 16 bits e indica el tamao 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 ms utilizada es el MSS (Maximum Segment Size). Cada
extremo de una conexin indica al otro cul es el tamao mximo de segmento que desea
recibir. Este valor se especifica dentro del campo de opciones al inicio de la conexin.


29
3 Ethernet conmutada

3.1 Introduccin

Las redes de rea local son aquellas que conectan una red de ordenadores normalmente
confinadas en un rea geogrfica, 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 fsicos han hecho posible la
proliferacin de LAN's en grandes organizaciones multinacionales, aplicaciones industriales
y educativas.

Ethernet es la capa fsica ms popular la tecnologa 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 instalacin.
Estos puntos fuertes, combinados con la amplia aceptacin en el mercado y la habilidad de
soportar virtualmente todos los protocolos de red populares, hacen a Ethernet la tecnologa
ideal para la red de la mayora los usuarios de la informtica actual. La norma de Ethernet
fue definida por el Instituto para los Ingenieros Elctricos y Electrnicos (IEEE) como
IEEE Standard 802.3. Adhirindose 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
topologa de estrella. Generalmente un ordenador se sita a un extremo del segmento, y el
otro extremo se termina en una situacin 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 slo a los dos nodos en ese eslabn. Otros usuarios de los ordenadores
de la red continuarn operando como si ese segmento no existiera. En la figura 3.1
podemos ver un ejemplo de la topologa en estrella.

Figura 3.1: Topologa 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 seal entrante y la
repite hacia todos los puertos. Lo ms importante a resaltar sobre los concentradores es
que slo 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 estn contendiendo por la transmisin de datos hacia una sola red (dominio de
colisin). Esto significa que miembros individuales de una red compartida slo 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 seal a todos los
puertos. Los conmutadores trazan las direcciones Ethernet de los nodos que residen en
cada segmento de la red y permiten slo el trfico 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.
Adems, los conmutadores previenen la difusin de paquetes errneos al no remitirlos. El
filtrado de paquetes, y la regeneracin de paquetes remitidos permite a la tecnologa de
conmutacin dividir una red en dominios de colisin separados. La regeneracin de
paquetes permite disear redes de mayores distancias y ms nodos, y disminuyen
drsticamente los ratios de colisin globales. En redes conmutadas, cada segmento es un
dominio de colisin independiente. En redes compartidas todos los nodos residen en un
slo gran dominio de colisin compartido. Los conmutadores LAN tienen, bsicamente,
dos arquitecturas, "store and forward" (almacenar y remitir) y "cut through" (cortar y
atravesar). Inicialmente, los modelos "cut through", tenan una ventaja de velocidad porque
cuando un paquete entra en el conmutador, slo se examina la direccin 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 ms
tiempo para examinar el paquete entero, pero permite al conmutador detectar ciertos
errores del paquete e impedir su propagacin a travs 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 mnima. Hay tambin, un gran nmero de
conmutadores hbridos que mezclan ambas arquitecturas. Ambos conmutadores separan la
red en dominios de colisin, permitiendo extender las reglas de diseo 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 oposicin a los concentradores que slo 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 trfico.

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 utilizacin 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 comunicacin entre PC1 y PC7 afectar a todos los dems PC conectados
PC1
PC2
PC3 PC4
PC5
PC6
PC7
PC1
PC2
PC3
PC4
PC5
PC6
PC1
PC2
PC3
PC4
PC5

32
a la red. En el caso D, la comunicacin entre PC4 y PC5 no afectar en absoluto al resto de
la red ya que el switch encamina los paquetes slo a travs 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 telemtica

3.3.1 Composicin del puesto de trabajo

El puesto de prcticas ser denominado bancada, distinguindose por su numeracin: 1,
2, 3, 4, 5 y 6. Cada bancada constar de cuatro ordenadores: PCN1 PCN2, PCN3 y PCN4,
siendo N el nmero de la bancada. En la figura 3.4 podemos ver una bancada. Tambin
disponemos de un hub, al cual estn conectados los cuatro PC de la bancada de prcticas,
siendo PCN1 el ordenador que est ms 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 sern nominados como hub1, hub2, hub3 y hub4, en clara
alusin a la bancada que corresponda, lo mismo se har con los switch, que recibirn el
nombre de switch12 y switch34. Las direcciones IP de estos dispositivos vienen en el
ANEXO I.
Para el desarrollo de la prctica ser de gran ayuda apuntar las direcciones IP y MAC de
las mquinas 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
Hub2
Hub1

34
3.3.2 Superstack II 12 port PS hub 40

3.3.2.1 Caractersticas 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 slo se retransmitirn a los puertos pertenecientes a ese
segmento y no a los del otro segmento. La segmentacin de los hub es una opcin muy
interesante para la distribucin 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 travs de un cable cruzado. Adems dispone de un puerto de consola
DB9, con los parmetros 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 diagnstico 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 Gestin del PS Hub

Existen diversos mtodos 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 gestin.

Figura 3.10: Comandos disponibles para la gestin de hub

En la figura 3.15 podemos ver para qu se utiliza cada uno de los comandos mostrados en
la figura 3.10.

Gestin mediante interfaz de comandos

El interface de lnea de commandos nos permite de una forma directa configurar el hub
cuando entramos por primera vez al equipo. Tambin nos permite habilitar los dems
mtodos de gestin.


37
Gestin mediante el protocolo Telnet

El protocolo TELNET proporciona una interfaz estandarizada, a travs 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.

Gestin mediante el interface WEB

Los hubs del laboratorio tambin disponen de un interfaz WEB para su gestin. De esta
forma, para acceder a la gestin del dispositivo, lo nico que tenemos que hacer es
introducir la direccin IP del dispositivo en la URL de un navegador WEB y accederemos
al interface WEB de gestin. Las opciones que podemos gestionar a travs de este mtodo
son las mismas que con los mtodos anteriores pero ahora las encontramos organizadas de
forma grfica. En la figura 3.11 podemos ver la pgina principal de gestin de un hub.

Figura 3.11: Pantalla del navegador en la gestin WEB.

Gestin mediante agente SNMP

SNMP (Protocolo de Administracin 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 Informacin de Gestin o "Management Information Base") y puede ser
propietarios o adecuarse a las normas establecidas. El software SNMP ejecutndose en un
servidor puede acceder a la informacin de SNMP en dispositivos de la red que soportan el
protocolo. Como ejemplos de software de administracin podemos mencionar HP
Openview y el NetManager de Sun, que ofrecen grficas mejorando la presentacin de la
informacin SNMP.

38
3.3.3 Superstack II switch 1100

3.3.3.1 Caractersticas 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 caractersticas principales de los switch de estas series son las siguientes:

Cada usuario dispone de 10 Mb reales como ancho de banda
Elimina la prdida de paquetes por colisiones
Ofrece una mxima proteccin y un mnimo nmero de errores
Instalacin simple y rpida
Tecnologa PACE que mejora la transmisin de datos multimedia
Soporte para la implementacin de redes virtuales
Gestin 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 Gestin del switch


39
Al igual que el hub, el switvh se puede gestionar a travs de lnea de comandos, protocolo
TELNET, interfaz WEB y protocolo SNMP. Ya que estos mtodos de gestin 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 gestin del switch

La figura 3.15 nos ofrece de una forma esquemtica qu representa cada una de las
opciones de gestin.


40

Figura 3.15: Resumen de los comandos de gestin

4 Realizacin de la prctica

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 gestin del hub:

A.-La primera de ellas se basa en el tipo de puerto al cual se conecta el equipo de gestin.
1.-Puerto de consola: utilizado como tal o conectado a un MODEM
2.-Puerto Ethernet: situado comnmente en el segmento 1 del hub, con una direccin
IP asignada.

B.-La segunda clasificacin est en funcin del servidor utilizado para la gestin:
1.-Interfaz lnea de comandos: Directamente sobre una consola.
2.-TELNET. Conectndonos a un servidor telnet situado en el hub, con una
presentacin similar a la interfaz lnea de comandos.
3.-HTTP. Utilizando el protocolo http, conectndonos a un servidor web residente en
el propio hub. Siendo necesario el uso de un navegador.
4.-SNMP/RMON. Donde el hub acta como agente SNMP/RMON, siendo
necesario un gestor externo.

Llegados a este punto vamos a poner en prctica cuatro mtodos de gestin: 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
configuracin. 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 sesin de
prcticas. A continuacin lo que haremos ser conectarnos a los diferentes servidores de
gestin del hub y realizar una serie de acciones de gestin 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 direccin IP asignada, por lo que el nico medio que
tenemos para gestionar el equipo es a travs de la lnea de comandos. Para ello nos
aseguramos que conectamos el puerto serie del ordenador al puerto de consola del equipo y
lanzamos cualquier aplicacin de emulacin 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 direccin IP del hub).
Una vez conectados vemos que el entorno es el mismo que para la interfaz de comandos.
A continuacin nos disponemos a realizar una serie de funciones relacionadas con los
puertos y los segmentos del hub:
1. Comprobamos las estadsticas de los puertos del hub. Prestamos atencin al estado de
los mismos y al segmento al que pertenecen. Vemos cmo se puede modificar del
estado de los puertos
2. Analizamos la informacin detallada de cada uno de los segmentos del hub.

42
3. Realizamos pruebas relacionadas con la segmentacin 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 continuacin,
segmentamos el hub, dejando el puerto al que est conectado PCN3 en el segmento 2
y repetimos la operacin.
4. Si conectamos el ordenador a un segmento que no sea el 1, no se puede realizar una
conexin remota. Esto ocurre por motivos de seguridad. Podemos comprobarlo
intentando acceder desde el PCN3, que ahora se encuentra en el segmento 2.
5. Comprobamos cules son los principales parmetros IP del hub y cmo 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 ms amigable que los anteriores. Comprobamos
cmo podemos realizar la gestin del hub a travs del interfaz web:
1. Vemos los parmetros 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 caractersticas de los puertos y comprobamos cmo podemos segmentar el
hub de manera sencilla.
3. Verificamos los IP del hub y localizamos dnde se encuentra la direccin Ethernet
del mismo.
Puede comprobarse que hay parmetros 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 conexin al servidor SNMP del hub se realizar utilizando los siguientes comandos:
snmpwalk, snmpget o snmpset. Este mtodo es menos intuitivo que los anteriores, ya
que se necesita conocer la codificacin ASN.1 (MIB) de los parmetros de configuracin
del hub. Por otra parte, es el ms eficiente, siendo utilizado por todos los programas
comeciales de gestin 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 direccin del hub. El valor de
comunidad se facilitar en la propia sesin de prcticas. El resultado del comando
ser una lista de los puertos del hub y el segmento al que estn 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 nmero al que es igual cada fila (valor numrico de la interfaz de gestin).
2. Modificar el puerto 10 ponindolo 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 numrico de la interfaz de gestin, 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 direccin IP del hub

43
la mscara de la direccin IP del hub
la direccin IP del router por defecto.
4. Modificar la direccin 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 comparacin entre los tres servidores remotos,
hemos visto el tiempo que se tarda en comprobar la segmentacin del hub.
El uso de SNMP nos proporciona la respuesta ms rpida, aunque tenga el
entorno ms "rido".
El uso de telnet es ms amigable pero el tiempo de respuesta es mayor.
El tiempo de respuesta del servidor web es el mayor, aunque se sita en un
entorno de utilizacin al cual todos estamos acostumbrados (el navegador).
El servidor SNMP permite modificar cualquier valor, cosa que no ocurra en los
otros servidores, que dependan de su programacin.

4.1.2 Superstack II switch 1100

Los escenarios para la gestin del switch son muy parecidos a los del hub. Por supuesto
cambian los parmetros 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 gestin,
ambos a travs de Ethernet, concretamente la conexin 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 sesin. Las acciones a
realizar sern 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 direccin Ethernet del switch.
-Verificar los datos de IP del switch.
-Comprobar el funcionamiento de la conexin 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 direccin 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: Anlisis 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 continuacin se describe
el funcionamiento bsico de este programa. Para ms detalle, acudir al manual incluido en
un anexo de la prctica o la ayuda en linux (iperf --help).
Para establecer una comunicacin 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 trfico fluye de cliente a servidor durante el
tiempo que dure la conexin. Una vez finalizada, el servidor permanece activo, a la espera
de que el cliente realice otra peticin.
Para configurar el servidor debe teclearse
iperf s
y para configurar el cliente
iperf c @IP_servidor
Algunas opciones interesantes son:
-t: duracin de la conexin (por defecto 10 segundos)
-i: tiempo entre estadsticas
-u: para indicar que la conexin es UDP (por defecto TCP)
-b: ancho de banda (en el caso de conexin 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 conexin UDP con un ancho de banda de 2 Mbps,
con una duracin de 30 segundos y sacando estadsticas cada 2 segundos, deberamos 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 trfico TCP
entre PCN1 y PCN3 y observamos el ancho de banda obtenido. A continuacin
establecemos otra conexin con las mismas caractersticas entre PCN2 y PCN4, de
manera que se simultaneen ambas conexiones. Cul es el ancho de banda ahora?
Por qu?
- A continuacin, pasamos PCN2 y PCN4 al segmento 2 del hub, y volvemos a
establecer las dos conexiones. Qu est ocurriendo ahora?

4.2.2 Anlisis de la eficiencia de la red Ethernet

- Vamos a generar varias conexiones UDP entre PCN1 y PCN3 variando el tamao 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 tericamente es el mximo proporcionado por la red
Ethernet. Anotar los valores obtenidos en cada caso y justificarlos tericamente.
DATOS: Cabecera UDP: 8bytes. Cabecera IP: 20 bytes. Overhead total Ethernet
(Cabecera + Prembulo + 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 trfico entre dos equipos y medir el ancho de banda que experimenta la
comunicacin de una manera automatizada. A continuacin, para entender mejor el
proceso de medida de ancho de banda y los conceptos asociados, vamos a realizar un
anlisis detallado del mismo. Para ello, utilizaremos un generador de trfico 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 comunicacin a partir de dicha traza. Todo el proceso se
realizar en entorno Windows.

Para generar trfico, vamos a emplear un programa desarrollado en C++. Para poder
ejecutarlo, as como observar el cdigo fuente del mismo, abrimos el programa Microsoft
Visual Studio y caragamos el workspace packet_generator.

Figura 4.1: Interfaz grfico del generador de trfico

Si ejecutamos el programa (build -> excute packet_generator.exe o el icono
correspondiente de la barra de herramientas) aparece el interfaz grfico de gestin del
generador, en el que debemos especificar los siguientes parmetros:

- Longitud de los paquetes (en bytes): El tamao de los paquetes generados sigue
una distribucin 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 generacin de
cada paquete. Dicho tiempo tambin sigue una distribucin uniforme.

A partir de estos dos parmetros, puede obtenerse de forma directa la tasa de
transmisin efecitva de datos de la comunicacin.

- Direccin IP destino: La direccin IP fuente viene fijada por el equipo desde el
que se genera el trfico. Debemos especificar la direccin IP destino del equipo al
que queremos mandar el trfico.

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 parmetros, 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 botn Generar comienza la transmisin de paquetes, que permanecer activa
hasta que se pulse el botn Parar.

Para capturar el trfico asociado a la comunicacin, empleamos el programa Wireshark,
que nos permite exportar a un fichero de texto la traza de la transmisin 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 transmisin. Se desea
obtener el ancho de banda medio de toda la traza, as como la evolucin del ancho
de banda cada cierto intervalo de tiempo, cuyo valor debe ser un parmetro
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 mscara: 255.255.255.0
HUB2 IP LAN: 155.210.157.21 mscara: 255.255.255.0
HUB3 IP LAN: 155.210.157.37 mscara: 255.255.255.0
HUB4 IP LAN: 155.210.157.53 mscara: 255.255.255.0
HUB5 IP LAN: 155.210.157.69 mscara: 255.255.255.0
HUB6 IP LAN: 155.210.157.85 mscara: 255.255.255.0

SWITCH12 IP LAN: 155.210.157.13 mscara: 255.255.255.0
SWITCH34 IP LAN: 155.210.157.45 mscara: 255.255.255.0

02.redes Ethernet

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

02.redes Ethernet

Transféré par

Droits d'auteur :

Formats disponibles

Introduccin a las redes IP.

Vous aimerez peut-être aussi