5 PUENTES Y CONMUTADORES LAN

Existen muchas circunstancias en las que no se quiere o no se puede tener una sola red; en estos casos es posible tener múltiples redes locales interconectadas mediante el uso de unos dispositivos llamados puentes. Los puentes se encargan de capturar las tramas de una red local, y reenviarlas selectivamente a otra red local. Para esto analizan la dirección de origen y destino de la trama a nivel MAC. Algunas de las situaciones en las que puede ser conveniente utilizar puentes son las siguientes:

o Interoperabilidad: Se dispone de redes basadas en medios físicos diferentes. Por ejemplo en una empresa puede haberse empezado a tender una red Token Ring en unos edificios y Ethernet en otros.

o Distancia: Se necesita cubrir una distancia mayor que la que puede cubrirse con una red local (por ejemplo más de 4 Km en Ethernet a 10 Mb/s).

o Número de ordenadores: Se quiere conectar más equipos que los que se permiten en una red local (más de 1024 en Ethernet, o mas de 72-250 en Token Ring).

o Tráfico: Si existe una elevada cantidad de tráfico, principalmente de carácter local, se puede reducir éste dividiendo la red en varias mediante puentes. Por ejemplo si en una empresa cada departamento tiene su propio servidor mucho de su tráfico será local.

o Fiabilidad: Si se quiere evitar que un problema en un ordenador pueda colapsar toda la red (por ejemplo en Ethernet una tarjeta o transceiver averiado puede inutilizar toda la red). Si se divide la red por zonas el problema afectará a menos equipos.

o Seguridad: En una red local cualquier ordenador funcionando en modo promiscuo puede ver todas las tramas. La división en varias redes evita en cierta medida que los paquetes puedan ser vistos fuera de la red.

5.2 PUENTES

De acuerdo con la funcionalidad que desempeñan podemos clasificar los puentes en los siguientes tipos:

Puentes transparentes

Puentes remotos, también llamados encapsuladores

Puentes traductores

Puentes con encaminamiento desde el origen

Ahora veremos cada uno de ellos en detalle.

5.2.1 Puentes transparentes

Como su nombre indica, lo que se pretende con estos puentes es que puedan utilizarse sin alterar para nada el protocolo o la configuración de los ordenadores. Normalmente estos equipos no necesitan ningún tipo de configuración previa, actuando como dispositivos 'plug and play'.

Veamos como funciona un puente transparente. Supongamos un puente que une dos redes, LAN1 y LAN2. El puente tendrá dos interfaces físicas, cada una conectándole con cada una de las dos LANs. Al encender el puente éste empieza reenviando todas las tramas que recibe por LAN1 a LAN2, y viceversa. En todo momento el puente actúa en modo promiscuo, es decir, capturando todas las tramas que se envían por cada una de las redes a las que está conectado, independientemente de cual sea la dirección de destino.

Además de reenviar las tramas de forma indiscriminada, el puente va silenciosamente extrayendo de cada una la dirección de origen y la dirección de destino; la de origen la anota en una tabla hash correspondiente a la LAN por la que ha llegado la trama, y la de destino la busca en la misma tabla. Supongamos que el puente recibe por la interfaz LAN1 una trama que lleva la dirección de origen A y la dirección de destino B. Primeramente el puente buscará en su tabla de direcciones si en la columna LAN1 aparece B; si es así sencillamente descartará la trama, ya que sabe que A y B están ambas en LAN1 y no hay ninguna necesidad de reenviar esa trama. Si B no aparece en la tabla de LAN1 el puente reenviará la trama a LAN2. En segundo lugar el puente actualizará su tabla de direcciones de LAN1 añadiendo A, salvo que ya exista tal entrada en cuyo caso simplemente actualizará el contador de tiempos asociado con dicha entrada. Es posible que B esté en LAN1 y el puente no le tenga aún 'fichado' (porque B no haya enviado aún ninguna trama), pero ante la duda el puente se 'cura en salud' y reenvía la trama por la otra interfaz. Esta estrategia de tirar por elevación enviando la información en caso de duda se denomina inundación (flooding)

El mecanismo utilizado por los puentes para averiguar que ordenadores tienen conectados en cada una de sus redes tiene algunas consecuencias que merece la pena destacar:

Un ordenador 'tímido', es decir, que no emita ninguna trama, no puede ser localizado, por lo que los puentes enviarán por todas sus interfaces (excepto aquella por la que les ha llegado) cualquier trama dirigida a dicho ordenador. Sin embargo no es probable que un ordenador que recibe tráfico permanezca callado durante mucho tiempo (o de lo contrario pronto dejará de recibirlo, ya que la mayoría de los protocolos requieren alguna contestación, al menos de vez en cuando).

Las tramas enviadas a direcciones de grupo (multicast o broadcast, las que tienen a 1 el primer bit) siempre son retransmitidas por los puentes por todas sus interfaces, ya que en principio puede haber destinatarios en cualquier parte. Los puentes no almacenan este tipo de direcciones en sus tablas ya que nunca aparecen como direcciones de origen en las tramas.

A fin de adaptarse a cambios en la red (por ejemplo un ordenador es desenchufado físicamente de LAN1 y enchufado en LAN2), las entradas en las tablas de direcciones son eliminadas cuando han pasado varios minutos sin que la dirección correspondiente haya enviado ninguna trama.

Existen puentes multipuerta, es decir, con múltiples interfaces, que permiten interconectar varias LANs en una misma caja. El algoritmo es similar, manteniéndose en este caso una tabla de direcciones para cada interfaz. Las tablas se van llenando con las direcciones 'escuchadas' en cada interfaz; cuando se recibe una trama en cualquiera de las interfaces se busca la dirección de destino en la columna de dicha interfaz; si el destinatario se encuentra allí la trama simplemente se descarta, si no se busca en las columnas correspondientes a las demás interfaces; si se encuentra en alguna columna se manda a la interfaz correspondiente. Por último, si no se encuentra en ninguna de las tablas se envía a todas las interfaces excepto aquella por la que llegó (inundación).

Los puentes han de mantener una tabla de direcciones para cada una de sus puertas; la cantidad de memoria destinada a dichas tablas es limitada, y en redes grandes puede llegar a agotarse. Los fabricantes suelen especificar el número máximo de direcciones MAC que sus puentes son capaces de soportar. Algunos equipos se bloquean sin más explicaciones cuando se les llena la tabla de direcciones MAC.

5.2.1.1 Spanning Tree

En algunas situaciones es interesante unir dos LANs con más de un puente, normalmente por razones de fiabilidad o redundancia. Analicemos a la luz del algoritmo antes descrito que ocurriría si dos puentes unen dos LANs. Imaginemos LAN1 y LAN2, unidas por los puentes B1 y B2. Una estación en LAN1 emite una trama que lleva una dirección de destino F aun no registrada; al no aparecer en sus tablas B1 reenvía la trama a LAN2; lo mismo hace B2. A continuación B1 detecta en LAN2 la trama generada por B2 y, al no encontrar en sus tablas la dirección de destino (ya que F aún no esta 'fichado') la reenvía a LAN1. Análogamente B2 detecta en LAN2 la trama de B1 y al no estar F en su tabla de direcciones, la reenvía a LAN1. LAN1 recibe pues dos copias de una trama que ya tenía, y se repite el proceso: B1 recoge la trama de B2 y la retransmite; B2 hace lo mismo con la de B1, y así sucesivamente. El ciclo no tiene fin, por lo que una sola trama es suficiente para saturar ambas redes.

Para evitar este problema existe un mecanismo que permite a los puentes comunicarse entre sí, pasándose información sobre la topología de las conexiones existentes; una vez averiguada dicha topología los puentes desactivarán las conexiones redundantes para garantizar que haya un único camino (directo o indirecto) uniendo todas las redes, de forma que se evite la creación de bucles. Las conexiones que lógicamente se pongan fuera de servicio quedarán listas para entrar en funcionamiento si las conexiones activas fallan por algún motivo. El algoritmo se repite cada cierto tiempo, por lo que si alguno de los enlaces queda fuera de funcionamiento por algún motivo (por ejemplo una avería) en la siguiente ronda se habilitará algún camino alternativo que lo sustituya. El protocolo que permite esto se conoce como Spanning Tree Protocol (STP) y también como Spanning Tree Learning Bridge Protocol, y forma parte de la especificación IEEE 802.1D.

La topología de una interconexión de LANs con puentes podemos representarla con un grafo en el que los nodos son las LANs y los arcos los puentes que las unen. El algoritmo spanning tree consiste en dejar únicamente un camino para llegar a cada una de las redes, para lo cual se suprime del grafo toda unión que ocurra en sentido descendente entre ramas distintas del árbol. Este tipo de estructura es lo que se conoce como spanning tree (que podemos traducir como árbol de expansión), de ahí el nombre del protocolo.

Con el Spanning Tree es posible tener varios puentes conectando dos redes sin que se produzcan conflictos. En la práctica lo que ocurre sencillamente es que se inhabilitan todos los caminos posibles, menos uno. Los otros quedan como rutas alternativas dispuestas a entra en funcionamiento en caso de avería en la principal. No es posible con Spanning Tree tener varias conexiones activas al mismo tiempo, lo cual permitiría repartir el tráfico entre varios puentes, mejorando así el rendimiento de la conexión (como se hace por ejemplo en etherchannel).

Aunque forma parte del estándar 802.1D y debería formar parte de cualquier puente transparente, no todos los equipos implementan el protocolo spanning tree. Al construir una topología basta con que uno de los puentes que forman el bucle incorpore el spanning tree para que el puente ‘rompa’ el bucle y la red funcione correctamente.

5.2.2 Puentes remotos o ‘encapsuladores’

En ocasiones se tiene necesidad de conectar entre sí dos redes locales remotas como si fueran la misma LAN. Para esto se usa un tipo de puentes denominados puentes remotos. Los mecanismos básicos de funcionamiento son los mismos que para los puentes locales (transparentes y con encaminamiento desde el origen), salvo que el puente está constituido por dos 'medios puentes' interconectados por una línea dedicada cuya velocidad típicamente suele estar entre 64 Kb/s y 2,048 Mb/s. También se pueden unir los puentes remotos por redes X.25, Frame Relay o incluso radioenlaces.

El protocolo spanning tree también se utiliza en puentes remotos. Para representar topológicamente un puente remoto el enlace punto a punto se debe considerar como una LAN con un puente en cada extremo.

Dado que generalmente los puentes remotos se conectan mediante líneas de menor velocidad que las redes a las que enlazan, es frecuente que dicha conexión sea el factor limitante de las prestaciones de la red (aun cuando el algoritmo propio de los puentes evita que el tráfico local cruce al otro lado). Esto es especialmente crítico cuando se utilizan líneas de baja velocidad (por ejemplo 64 Kb/s) y mas aun cuando se trata de LANs grandes en las que el tráfico broadcast/multicast es importante (recordemos que este tipo de tráfico siempre atraviesa los puentes transparentes).

5.3 REDES LOCALES CONMUTADAS

En la discusión anterior sobre diversos tipos de puentes hemos supuesto casi todo el tiempo que el puente tenía únicamente dos interfaces. Hoy en día son muy populares los puentes transparentes con elevado número de puertas, habiendo modelos que pueden llegar a más de 500. Estos equipos suelen ir equipados con chips VLSI diseñados específicamente para este tipo de tareas denominados ASIC (Application Specific Integrated Circuit), gracias a los cuales desarrollan su tarea con gran rapidez. A estos puentes multipuerta de alta velocidad se les suele llamar conmutadores LAN o switches LAN, ya que gracias al encaminamiento inteligente que realizan mediante sus tablas de direcciones actúan de hecho conmutando tramas entre sus múltiples puertas. También se les denomina a veces conmutadores de nivel 2 (nivel de enlace) por contraste con los llamados conmutadores de nivel 3, que realizan la conmutación al nivel de red, también llamados routers (normalmente el término conmutador de nivel 3 se utiliza para indicar un router que dispone de hardware específicamente diseñado para labores de routing y que por tanto realiza esta función de manera notablemente mas rápida que un router convencional). A las redes locales basadas en conmutadores se las suele llamar redes locales conmutadas (switched LANs).

En conmutadores Ethernet se suele decir que cada puerto constituye un dominio de colisiones independiente, ya que las colisiones que se producen en un puerto no afectan a los demás.

Los conmutadores Token Ring pueden funcionar según el principio de puente por encaminamiento desde el origen o puente transparente.

Con conmutadores LAN de elevado número de puertas es posible incrementar de forma notable la capacidad de una red local con una modificación mínima de la misma. Por ejemplo, si en una red se sustituye un hub o concentrador Ethernet de 24 puertas por un conmutador LAN de 24 puertas, el rendimiento máximo teórico se ha multiplicado por 24 sin haber tenido que modificar el cableado o las tarjetas de red de los ordenadores.

En el caso de redes Ethernet el uso de conmutadores tiene un efecto adicional en la mejora del rendimiento; recordemos que en redes CSMA/CD la eficiencia disminuye a medida que aumenta el número de ordenadores, por lo que si se divide una red en varias mediante un conmutador se consigue un mejor rendimiento en cada una de ellas al soportar un número más reducido de equipos.

Un problema que se presenta con los conmutadores LAN es que se pueden producir situaciones de congestión, para las que no disponen de muchos mecanismos de control pues funcionan únicamente a nivel de enlace. Por ejemplo, si en un conmutador de puertos a 10 Mb/s diferentes puertos quieren enviar tráfico a la vez a un mismo puerto a 10 Mb/s cada uno y esta situación se mantiene durante bastante tiempo el conmutador puede agotar el espacio en buffers disponible, perdiéndose tramas a partir de ese momento. En el caso de Ethernet este problema se resuelve mediante el control de flujo.

Al igual que los puentes, los conmutadores LAN han de mantener en memoria las tablas de direcciones MAC en cada una de sus puertas. Las especificaciones de un conmutador LAN indican normalmente el número máximo de direcciones que puede soportar. Si el número de equipos activos en la red es superior a este número máximo el rendimiento de la red se ve afectado ya que las entradas en la tabla de direcciones caducan con demasiada rapidez, provocando tráfico adicional en la red debido al mecanismo de inundación

5.3.1 Almacenamiento y Reenvío vs ‘Cut-Through’

Dado que los conmutadores LAN son esencialmente puentes con muchas puertas su funcionamiento normal requiere que antes de retransmitir una trama la reciban en su totalidad para que puedan comprobar el CRC y descartarla en caso de que éste sea erróneo. Esto obliga a que los conmutadores funcionen como dispositivos de almacenamiento y reenvío. En el caso de tramas grandes el requerimiento de comprobación del CRC introduce un retardo notable en la propagación de la trama, a menudo superior al que introduce el propio proceso de conmutación; además si la trama ha de atravesar varios conmutadores el almacenamiento y reenvío se ha de realizar en cada uno de ellos. Si no se hiciera la comprobación del CRC la velocidad de conmutación podría aumentarse notablemente y el retardo reducirse, ya que el conmutador podría empezar a enviar los bits tan pronto hubiera recibido la dirección MAC a la que va dirigida la trama. Esto es lo que se denomina funcionamiento en modo ‘Cut-Through’ (literalmente abrirse camino) implementado en algunos conmutadores. El problema del funcionamiento Cut-Through es que se pueden estar produciendo errores de CRC que pasen inadvertidos. En este caso las tramas erróneas serán descartadas por el host de destino, por lo que no hay riesgo de que se interpreten como correctos datos erróneos, pero aun así la situación es perjudicial para la red puesto que se esta ocupando ancho de banda con tráfico inútil.

Para evitar este problema cuando los conmutadores funcionan en modo Cut-Through siguen comprobando el CRC; cuando se produce un error no pueden descartar la trama puesto que esta ya ha sido transmitida, pero sí que pueden poner a la estación emisora bajo sospecha y a partir de ese momento pasar a funcionar en modo almacenamiento y reenvío de forma selectiva, únicamente para las tramas que tengan como dirección de origen la de la estación sospechosa; si se comprueba más tarde que el error detectado fue algo esporádico se volverá al modo Cut-Through para esa estación, de lo contrario se la mantendrá en estado vigilado, es decir en modo almacenamiento y reenvío; esta forma de proceder se basa en la hipótesis de que una estación que genera tramas correctas tiene una alta probabilidad de seguir generando tramas correctas, mientras que una que genera tramas erróneas, normalmente por algún problema de tipo físico, tendrá una probabilidad mayor de seguir generando tramas erróneas.

5.4 CONMUTACIÓN EN REDES ETHERNET

La introducción de los conmutadores LAN permite una serie de mejoras en el funcionamiento de las redes locales que comentaremos a continuación Aunque nos centraremos en el caso concreto de Ethernet, por ser la más común de las tecnologías actuales, la mayoría de estos principios son aplicables a otros protocolos MAC, aunque su desarrollo está en general más retrasado que en Ethernet.

5.4.1 Transmisión full dúplex

Una red Ethernet puede funcionar en modo full dúplex si se dan simultáneamente las tres condiciones siguientes:

Que el medio físico permita transmisión full-dúplex; esto se cumple en todos los casos habituales excepto 10BASE5, 10BASE2 y 100BASE-T4.

o Que sólo haya dos estaciones conectadas entre sí (por ejemplo conmutador-conmutador, conmutador-host o host-host).

o Que los adaptadores de red y transceivers de ambos equipos soporten el funcionamiento en modo full-dúplex.

Con sólo dos estaciones en la red y un canal de comunicación independiente para cada sentido el medio de transmisión no es compartido, por lo que no hay ninguna necesidad de protocolo MAC; se puede por tanto inhabilitar el CSMA/CD y manejar el medio físico como si se tratara de un enlace punto a punto full dúplex de la velocidad de la red (10, 100 ó 1000 Mb/s). Al no haber colisiones en full dúplex no rige la limitación de distancia impuesta por el 2t de la Ethernet ‘tradicional’ o half dúplex. La única restricción es la que viene impuesta por la atenuación de la señal según el medio físico utilizado. Por ejemplo 100BASE-FX, que tiene una distancia máxima en half dúplex de 412 m, puede llegar en full dúplex a 2 Km.

Cuando una estación se configura en modo full dúplex sin que se den las tres condiciones antes mencionadas el rendimiento decae de forma espectacular, ya que se producen colisiones que no son detectadas.

Aprovechando la supresión de la restricción en distancia debida al CSMA/CD algunos fabricantes suministran transceivers láser que utilizando fibra monomodo en tercera ventana permiten llegar en Ethernet a distancias de más de 100 Km, a cualquiera de las velocidades habituales (10, 100 ó 1000 Mb/s). Estos equipos no están estandarizados por lo que si se utilizan es conveniente poner en ambos extremos sistemas del mismo fabricante, o asegurarse previamente de su compatibilidad e interoperabilidad. Mediante dispositivos regeneradores de la señal de bajo costo es posible extender este alcance en principio indefinidamente, habiéndose hecho pruebas a distancias de hasta 800 Km. De esta forma Ethernet se convierte en una alternativa interesante en redes de área extensa. Evidentemente cuando se transmite la señal a grandes distancias se introduce un retardo, a veces importante, debido a la velocidad de propagación en el medio físico.

Además de aumentar el rendimiento y permitir distancias mayores el uso de full dúplex simplifica el funcionamiento, puesto que se suprime el protocolo MAC. El aumento en el rendimiento obtenido por la transmisión full dúplex normalmente sólo es significativo en conexiones conmutador-conmutador o conmutador-servidor. En un equipo monousuario el full dúplex supone una mejora marginal ya que las aplicaciones casi siempre están diseñadas para dialogar de forma half-dúplex [1].

En Gigabit Ethernet full dúplex se suprimen la extensión de protadora y las ráfagas de tramas, puesto que son innecesarias. Por tanto las ventajas en Gigabit Ethernet full dúplex son aun mayores que las obtenidas en Ethernet o Fast Ethernet, hasta el punto que algunos autores dudan de que lleguen a extenderse en el mercado productos Gigabit Ethernet half dúplex [13].

Para permitir el funcionamiento full dúplex en Gigabit Ethernet sin tener que recurrir a la conmutación por puerta, que podría resultar excesivamente cara en algunas situaciones, se han ideado recientemente unos dispositivos que son algo intermedio entre los concentradores y los conmutadores, denominados ‘buffered repeaters’, ‘buffered distributor’, ‘full duplex repeater’ o ‘full duplex distributor’. Un ‘buffered repeater’ es un conmutador que carece de tabla de direcciones MAC, por lo que cualquier trama que recibe la replica en todas sus interfaces por inundación, actuando de la misma forma que un conmutador cuando recibe una trama dirigida a una dirección que no aparece en sus tablas. Por tanto desde este punto de vista un buffered repeater actúa como un concentrador. Sin embargo a diferencia del concentrador, que reproduce la trama bit a bit, el buffered repeater la almacena en su totalidad antes de reenviarla, actuando como un puente; esto le permite funcionar en modo full dúplex, con lo que no sufre las limitaciones de distancia del half dúplex; tampoco tiene que detectar colisiones o generar extensiones de portadora, lo cual simplifica la electrónica asociada. Se espera que el buffered repeater sea bastante más barato de fabricar que un conmutador de Gigabit Ethernet, ya que debido a su funcionamiento el tráfico total agregado de un buffered repeater está limitado a 1 Gb/s, lo cual simplifica el diseño respecto a un conmutador normal, que en principio debe poder soportar un tráfico total agregado igual a la suma del de todas sus interfaces. Estrictamente hablando los buffered repeaters no son parte del estándar Gigabit Ethernet; y podrían aplicarse igualmente a Ethernet, Fast Ethernet u otras redes 802 ya que su principio de funcionamiento es el mismo que el de los conmutadores (que corresponde al estándar 802.1D. de puentes transparentes).

A la vista de estos desarrollos, que muy probablemente dejarán en desuso la Gigabit Ethernet half dúplex, cabría preguntarse por que razón el subcomité 802.3z emprendió la ardua tarea de estandarizar Gigabit Ethernet half dúplex, con toda la complejidad que esto supuso (definición del concepto de extensión de portadora y ráfagas de tramas, por ejemplo). La explicación es de tipo político: para que el grupo que definía Gigabit Ethernet pudiera constituirse como un subcomité de 802.3 era necesario que contemplara el uso de CSMA/CD (y por ende el funcionamiento half dúplex), ya que ésta es la característica esencial que identifica al subcomité 802.3 dentro del comité 802. En caso de no haber contemplado el CSMA/CD el grupo de Gigabit Ethernet habría tenido que solicitar al IEEE la creación de un nuevo subcomité 802; esto habría retrasado considerablemente la estandarización, cosa no deseada por ninguno de los participantes en el grupo.

5.4.2 Control de flujo

El funcionamiento full dúplex se introdujo inicialmente como una extensión no estándar por parte de varios fabricantes. Cuando en 1997 el subcomité 802.3x lo estandarizó incluyó además una nueva funcionalidad, el control de flujo, que en Ethernet se implementa mediante el comando PAUSE. El receptor puede en cualquier momento enviar al emisor un comando PAUSE indicándole por cuanto tiempo debe dejar de enviarle datos. Durante ese tiempo el receptor puede enviar nuevos comandos PAUSE prolongando, reduciendo o suprimiendo la pausa inicialmente anunciada. Con esto se pretende evitar el desbordamiento de los buffers del receptor con el consiguiente descarte de tramas, lo cual causaría males mayores. El control de flujo está especialmente indicado en el caso de conmutadores, sobre todo si forman parte del backbone de una red. Puede establecerse de forma asimétrica, por ejemplo en una conexión conmutador-host puede que de flujo sobre el host, pero no a la inversa.

Desde el punto de vista de Ethernet el control de flujo se implementó como un nuevo tipo de protocolo de red. Para que funcione correctamente es fundamental que las tramas de control de flujo sean rápidamente identificadas por los conmutadores, por lo que esta función se implementa normalmente en hardware. Esto es mucho más fácil de hacer si los comandos de control de flujo pueden identificarse en la cabecera MAC de la trama y no en la LLC, por lo que se vio que era más eficiente utilizar el formato DIX que el 802.2, ya que permitía poner el campo tipo en la cabecera MAC. Se propuso entonces al comité 802.3 un nuevo formato de trama, que coincidía precisamente con el formato DIX. El comité aceptó la propuesta, pero ya puestos decidió estandarizar el nuevo formato para todos los posibles protocolos de Ethernet, no sólo para el control de flujo. Como consecuencia de esto desde 1997 los dos formatos de trama: el 802.2 y el DIX son ‘legales’ según el estándar 802.3; la distinción entre ambos se hace según el valor del campo tipo/longitud, como ya era habitual en todas las implementaciones.

Cuando en una conexión full dúplex se implementa control de flujo cada equipo debe disponer de espacio suficiente en buffers para aceptar todo el tráfico proveniente del otro extremo en caso de que este envíe un comando PAUSE. Dicho espacio ha de ser como mínimo igual a la cantidad de datos que el otro equipo pueda transmitir durante el tiempo de ida y vuelta (ya que mientras el comando PAUSE viaja se considere conveniente que el conmutador ejerza control hacia el emisor éste continúa enviando datos). Dicho de otro modo, hay que reservar un espacio en buffers igual al doble de lo que ‘cabe’ en el cable. Por ejemplo en una conexión 1000BASE-LX full dúplex de 5 Km (tiempo de ida y vuelta 50 µs) se deberá disponer de 50.000 bits (6,1 KBytes) para buffers. En el caso de conexiones Ethernet de larga distancia (superiores a las permitidas por el estándar) puede ocurrir que el espacio en buffers sea insuficiente para albergar todos los datos recibidos cuando se emite un comando PAUSE.

5.4.3 Autonegociación

Los medios físicos 1000BASE-T y 100 BASE-TX utilizan el mismo conector que 10BASE-T. Esto permite aprovechar la misma instalación de cableado y latiguillos para las tres redes, lo cual da gran flexibilidad. Sin embargo desde el punto de vista del usuario supone también la posibilidad de cometer errores, ya que la compatibilidad de conectores no garantiza la compatibilidad de medios físicos. El funcionamiento full dúplex y el control de flujo plantean un problema parecido, ya que al ser partes opcionales del estándar no tienen por qué estar disponibles en todos los equipos. Esta diversidad de posibilidades en cuanto a velocidad y funcionalidades disponibles en el mismo conector requiere una laboriosa tarea de documentación para asegurar el correcto funcionamiento de una red. Para simplificar esta tarea se añadió al estándar 802.3 una característica denominada autonegociación, consistente en que cuando dos equipos se conectan intercambian unas señales anunciando sus posibilidades, de acuerdo con un protocolo especial. Esto les permite ‘negociar’ y funcionar de la forma compatible más eficiente posible [2].

En el caso de un conector RJ-45 se negocia en primer lugar el medio físico en el siguiente orden:

1.-           1000BASE-T
2.-           100BASE-T2
3.-           100BASE-TX
4.-           100BASE-T4
5.-           10BASE-T

Una vez acordada la velocidad se negocia el funcionamiento half/full-dúplex, y por último el control de flujo y si éste se establece con carácter simétrico o asimétrico.

En el caso de la fibra óptica la velocidad no es negociable normalmente, ya que se utilian varias longitudes de onda y esta no es ajustable. En estos casos lo único que se suele negociar es el funcionamiento dúplex (half o full) y el control de flujo.

La autonegociación es opcional, por lo que conviene comprobar que esté soportada por los equipos antes de dejarlo todo en manos del funcionamiento automático. Aun en el caso de que se soporte autonegociación es conveniente comprobar que se ha pactado el funcionamiento más eficiente posible, sobre todo en conexiones entre conmutadores, ya que en este caso la ausencia de control de flujo o el funcionamiento half dúplex puede suponer una diferencia importante de rendimiento.

En algunos casos la autonegociación puede causar problemas. Por ejemplo si conectamos mediante cableado categoría 3 dos equipos que soportan 100BASE-TX y 100BASE-T4 las señales de autonegociación, que tienen unos requerimientos ínfimos en cuanto a ancho de banda, se transmiten perfectamente en el cable, pero no verifican su categoría (ya que incluir esta verificación en el transceiver sería muy costoso). Por tanto la negociación dará como resultado el funcionamiento en 100BASE-TX. Una conexión 100BASE-TX sobre cableado categoría 3 no funcionará o lo hará con muchos errores, por lo que en este caso será necesario configurar manualmente los equipos y forzar el uso de 100BASE-T4 para que la red funcione correctamente. Afortunadamente esta situación se da raramente ya que muy pocos equipos implementan 100BASE-T4.

La autonegociación sólo es posible en conmutadores y hosts, no en concentradores, ya que estos requieren funcionar a la misma velocidad en todos sus puertos, y siempre en modo half dúplex. En el mercado existen equipos denominados ‘concentradores’ con autonegociación 100/10 por puerto; estos equipos en realidad son internamente un conmutador con dos puertos, uno de 10 y uno de 100 Mb/s, que tiene un concentrador de 10 y uno de 100 Mb/s conectados a cada puerto del conmutador; los puertos físicos se adscriben internamente a uno u otro concentrador en función de la velocidad del equipo que se conecta.

5.4.4 Agregación de enlaces

La agregación de enlaces, también llamada ‘trunking’ o multiplexado inverso, es una técnica desarrollada inicialmente por la empresa Kalpana para utilizar varios enlaces Ethernet full-dúplex en la comunicación entre dos equipos, realizando reparto del tráfico entre ellos. Hoy en día esta funcionalidad es ofrecida por multitud de fabricantes para todas las velocidades de Ethernet.

En principio según el estándar si dos conmutadores se unen por dos enlaces el protocolo Spanning Tree desactivará uno de ellos, dejándolo preparado para entrar en funcionamiento en caso de fallo del otro [3]. La agregación de enlaces requiere deshabilitar el Spanning Tree entre los enlaces que se agregan, para así poder repartir el tráfico entre ellos. Los enlaces pueden ser de 10, 100 ó 1000 Mb/s, pero han de ser todos de la misma velocidad.

Además de permitir acceder a capacidades superiores cuando no es posible cambiar de velocidad por algún motivo, la agregación de enlaces permite un crecimiento gradual a medida que se requiere, sin necesidad de cambios traumáticos en las interfaces de red o en la infraestructura. Aunque existen en el mercado productos que permiten agregar hasta 32 enlaces full dúplex, parece que cuatro es un límite razonable, ya que al aumentar el número de enlaces la eficiencia disminuye, y por otro lado el costo de las interfaces aconseja entonces pasar a la velocidad superior en vez de agregar enlaces.

La estandarización de la técnica de agregación de enlaces ha sido llevada a cabo por el grupo de trabajo 802.3ad, que terminó la elaboración del documento en fase de borrador en 1998. Su ratificación es ya inminente. Actualmente existen multitud de productos en el mercado conformes con dicho borrador que pueden interoperar entre sí.

La agregación de enlaces requiere evidentemente el uso de múltiples cables, cosa que no siempre es posible, sobre todo si se trata de enlaces a gran distancia. En el caso de fibra óptica el problema puede resolverse mediante la técnica conocida como WDM (Wavelength Division Multiplexing) que consiste en multiplexar varias señales en una misma fibra utilizando longitudes de onda ligeramente distintas dentro de la misma ventana (equivalente a usar luz de diferentes ‘colores’). La WDM se utiliza desde hace algún tiempo en enlaces de área extensa donde el mejor aprovechamiento de las fibras compensa el elevado costo de los equipos. Recientemente han aparecido dispositivos WDM a precios asequibles (unos 2 millones de pesetas) que multiplexan cuatro señales Gigabit Ethernet en una misma fibra, pudiendo así transmitir 4 Gb/s full dúplex por un par de fibras. Como detalle curioso comentaremos que con WDM también es posible multiplexar el canal de ida y el de vuelta en una misma fibra, con lo que es posible tener comunicación full dúplex por una sola fibra.

5.5 DISEÑO DE REDES LOCALES

5.5.1 Planificación de capacidad. Dimensionamiento

El responsable de una red local tiene a menudo que plantearse la mejora de partes de la misma para evitar que los niveles de saturación produzcan una merma en la calidad de servicio percibida por los usuarios, cosa que no debería ocurrir en una red local donde en principio el ancho de banda está disponible a bajo costo.

Para esta toma de decisiones es necesario disponer de parámetros de medida objetivos, que nos permitan comparar los niveles de calidad de servicio de acuerdo con criterios homogéneos para toda la red. Como ya hemos comentado las colisiones de una red Ethernet no son en sí mismas una medida adecuada del grado de saturación de una red, ya que su interpretación está íntimamente ligada al tamaño de trama medio de una red.

Un parámetro mucho más apropiado es el nivel de ocupación medio de la red. Este valor puede obtenerse a partir de los contadores de tráfico de las interfaces en los diversos dispositivos de la red (conmutadores, routers, etc.), por ejemplo cada cinco minutos vía SNMP. De esta forma es posible calcular y representar gráficamente el tráfico medio en una red a intervalos de cinco minutos. Una vez hemos recopilado esta información para todas las interfaces que constituyen nuestra red local podemos comparar los valores y aplicar criterios objetivos para decidir donde es pertienente adoptar medidas para ampliar la capacidad.

Según Seifert [13], [16] en el caso de una red local utilizada para aplicaciones típicas de ofimática con decenas de estaciones por red se puede considerar que se da una carga excesiva en la red si se da alguna de las siguientes circunstancias:

Se supera el 50% de ocupación durante 15 minutos, o bien
Se supera el 20-30% durante una hora, o bien
Se supera el 10-20% durante ocho horas.

En principio una red podría estar al 100% de ocupación durante cinco minutos, y eso no sería motivo para plantearse un aumento de capacidad. La razón es la siguiente: esa ocupación podría estar provocada por un usuario que transfiere un fichero grande (por ejemplo 400 Mbytes en una red de 10 Mb/s). Si ese tipo de utilización es esporádico normalmente el tiempo de respuesta será aceptable, y si es frecuente provocará que se supere alguno de los umbrales antes mencionados.

Una posible excepción a la regla anterior serían las redes en las que se utilicen aplicaciones en tiempo real (vídeoconferencia o vídeo bajo demanda, por ejemplo). En este caso el criterio debería ser mas exigente (por ejemplo 50% de ocupación durante 5 minutos) y aun así se pueden producir colapsos momentaneos. En realidad si se quiere utilizar este tipo de aplicaciones con garantías en una red Ethernet es preciso utilizar conmutadores hasta el puesto del usuario final.

5.5.2 Diseño de redes Ethernet

Gracias a los desarrollos habidos en los últimos años Ethernet presenta una enorme gama de posibilidades: diversos medios físicos (cobre y fibra), velocidades (10/100/1000 Mb/s) y modos de funcionamiento (puertos compartidos/conmutados, transmisión half/full dúplex y agregación de enlaces). Esto da una gran versatilidad que permite diseñar una red local completa cualesquiera que sean las necesidades que se presenten. Vamos a dar en este apartado algunas indicaciones generales sobre aspectos a tener en cuenta al diseñar una red local basada en Ethernet.

En primer lugar se plantea la disyuntiva del medio compartido o conmutado, es decir, si se debe conectar los equipos de usuario final a concentradores (hubs) o directamente a conmutadores.

Analizando la evolución a lo largo de varios años del costo por puerto de los concentradores frente a los conmutadores observamos que la diferencia es cada vez menor, como se aprecia en la tabla 1.1.

Tipo de red	1991	1993	1996	1998
10 Mb/s compartidos	15-30	7-15	3-10	1,5-6
10 Mb/s conmutados	150-200	40-90	15-30	4-10
Ratio 10 Mb/s	8:1	6:1	3:1	2:1
100 Mb/s compartidos			15-30	5-10
100 Mb/s conmutados			70-150	10-20
Ratio 100 Mb/s			5:1	2:1
1 Gb/s compartidos				(70-150)
1 Gb/s conmutados				(100-300)
Ratio 1 Gb/s				2:1

Tabla 1.1.- Precio por puerto (en miles de pesetas) de Ethernet compartida y conmutada. Datos obtenidos de [13].

En 1991 la relación para Ethernet 10 Mb/s conmutado:compartido era de 8:1, mientras que en 1998 se había reducido a 2:1. Una evolución análoga ha ocurrido con Fast Ethernet, que también se encuentra actualmente en 2:1. Es previsible que para Gigabit Ethernet se mantenga una relación similar (en el caso de que se lleguen a desarrollar concentradores de Gigabit Ethernet).

Esta evolución se explica porque el costo de la electrónica de conmutación disminuye a mayor velocidad que el del resto de componentes. Extrapolando los datos de la tabla anterior podemos esperar que el ratio descienda aún más en el futuro. Si además tenemos en cuenta que el costo de la instalación física (cableado) y de las interfaces de red son los mismos en ambos casos, el ratio es aún menor. Por todos estos motivos hoy en día se considera que el diseño de una red Ethernet debe basarse normalmente en el uso de conmutación a nivel del usuario final, es decir se recomienda la completa supresión de los concentradores.

El uso de conmutadores permite suprimir totalmente el protocolo CSMA/CD, y eventualmente extender el funcionamiento en modo full dúplex a toda la red. El uso de la transmisión full dúplex es especialmente importante en el caso de conexiones conmutador-conmutador, conmutador-router y conmutador-servidor.

Respecto a los medios físicos disponemos básicamente de tres alternativas cuyas distancias y costo relativo aparecen en la tabla 1.2.

Medio físico	10 Mb/s	100 Mb/s	1000 Mb/s	Costo relativo
Cobre UTP-5	150 m	100 m	100 m	1
F.O. 1ª ventana	2 Km	500 m	275-550m	2
F.O. 2ª ventana	-	2 Km	550m-5Km	6

Tabla 1.2.- Medios físicos más comunes en Ethernet

A pesar del desarrollo de optoelectrónica VCSEL de bajo costo en primera ventana, las interfaces en fibra óptica seguirán siendo más caras que las de UTP-5. Por tanto es preferible utilizar cable de cobre siempre que las distancias lo permitan, salvo que las condiciones ambientales aconsejen otra cosa.

En cuanto a la elección de velocidad de la red, esto dependerá evidentemente del tipo de aplicaciones y de las necesidades. En la tabla 1.3 damos unas recomendaciones orientativas en función del tipo de equipo a conectar.

Equipo a conectar	Tipo de conexión aconsejada
Puesto de trabajo	o 10BASE-T conmutada full duplex o 100BASE-TX conmutada full duplex
Servidor	o 100BASE-TX conmutada full duplex o 2, 3 ó 4 100BASE-X conmutada full duplex (etherchannel, 802.3ad) o 1000BASE-T conmutada full duplex con buffered repeater
Backbone (conmutador-conmutador)	o 100BASE-X conmutada full duplex o 2, 3 ó 4 100BASE-X conmutada full duplex (etherchannel, 802.3ad) o 1000BASE-X conmutada full duplex o 2, 3 ó 4 1000BASE-X conmutada full duplex (etherchannel, 802.3ad)

Tabla 1.3.- Recomendaciones de diseño de una red local Ethernet

5.5.3 Redes locales virtuales (VLANs)

Una de las grandes virtudes de los puentes y los conmutadores es su sencillez de manejo. Debido a su funcionamiento transparente es posible realizar una compleja red, incluso con enlaces WAN si se utilizan puentes remotos, sin tener que configurar ningún router. A finales de los ochenta se puso de moda la idea de desarrollar grandes redes, incluso a nivel de redes nacionales, basadas únicamente en el uso de puentes transparentes.

Sin embargo pronto se vio que esta estrategia tenía dos inconvenientes serios:

Los puentes propagan el tráfico broadcast y multicast; generalmente los protocolos orientados a redes locales hacen un uso exhaustivo de este tipo de tramas, especialmente las broadcast, para anunciar todo tipo de servicios (a veces se les llama por esto ‘protocolos charlatanes’); incluso IP, que no es especialmente pródigo en mensajes broadcast los emplea para la resolución de direcciones (protocolos ARP, RARP, BOOTP y DHCP). La proliferación de tráfico broadcast en una red es especialmente grave más que por el ancho de banda desperdiciado por el consumo de ciclos de CPU que se produce en todos los ordenadores de la red; este no es el caso con las tramas multicast, ya que cuando una trama multicast no incumbe a una estación (es decir, dicha estación no pertenece a dicho grupo multicast) es descartada por la interfaz de red local.

La transparencia de los puentes hace difícil establecer mecanismos de control, protección y filtrado de tráfico, por lo que las redes muy grandes basadas en puentes se hacen inmanejables. Además en los casos en que quieren controles o mecanismos de gestión se han de utilizar direcciones MAC que no son agregables, es decir no existe ningún prefijo común en la dirección MAC que permita referirse o identificar una parte de la red, ya que la asignación no ha seguido ningún criterio geográfico ni se corresponde con la topología de la red.

Como consecuencia de esto la creación de grandes redes locales está desaconsejada y es práctica habitual en estos casos separar mediante routers las diversas partes de la red; este es el caso en un campus o gran edificio, por ejemplo. Los routers, al actuar a nivel de red, aíslan las tramas broadcast y multicast y facilitan la gestión al realizar una agregación de las direcciones de nivel de red

Es difícil fijar un número concreto para el máximo de nodos que debe haber en una red local, ya que este depende de las características de la red y los protocolos utilizados, pero a título orientativo diremos que en redes que utilizan un protocolo relativamente discreto en cuanto al tráfico broadcast (como es el caso de IP) en torno a 800 ordenadores como máximo por red local es un número razonable. Si la misma red local maneja varios protocolos de nivel de red simultáneamente el número máximo no debería estar por encima de los 200-300. Estos últimos valores de 200-300 ordenadores también se aplican cuando se utiliza alguno de los protocolos calificados de ‘charlatanes’, como AppleTalk o NetBios (NetBios es el protocolo de red utilizado comúnmente por los sistemas operativos Windows de Microsoft, aunque estos servicios también se pueden soportar sobre TCP/IP). Muchos programas analizadores permiten medir la cantidad de tráfico broadcast de una red (en paquetes por segundo) pudiendo incluso disparar una alarma cuando esta cantidad supera un determinado valor umbral fijado como excesivo por el usuario. El uso de estas herramientas en una red nos permitirá medir el tráfico broadcast de cada zona y tomar así las decisiones apropiadas sobre una posible división o reestructuración de la red en base a datos objetivos y cuantificables.

Dividir una red local con criterios geográficos resulta relativamente sencillo, ya que normalmente la topología del cableado nos permite realizar esa división de manera directa. Por ejemplo supongamos que queremos dividir en varias una red local que abarca el campus de una universidad. Si decidimos crear una red local por edificio conectaremos entre sí los conmutadores de cada edificio y a su vez conectaremos cada edificio a una interfaz diferente del router que interconecte todo el campus. Sin embargo a menudo se requiere realizar una división lógica de acuerdo a criterios funcionales, que no siempre coinciden con la ubicación física. Por ejemplo en el caso de una universidad se podría pensar por razones de eficiencia y seguridad en crear una red para investigación, otra para docencia y otra para tareas administrativas y de gestión. Normalmente habrá varios edificios en los que habrá que dotar una serie de puestos de cada una de las tres redes mencionadas, en cuyo caso habría que instalar en los correspondientes armarios de cableado conmutadores independientes e interconectarlos entre sí por separado. Esto provoca una red compleja y muy cara, ya que en muchos casos habrá equipos infrautilizados.

La solución a este problema es la creación de redes locales virtuales, o VLANs. Podemos pensar en las VLANs como una forma de realizar una partición lógica de un conmutador en otros más pequeños, de forma que aunque se trata de un solo equipo dividimos los puertos en grupos que son completamente independientes entre sí. Esta funcionalidad está disponible hoy en día en la mayoría de los conmutadores del mercado, excepto en los de gama más baja.

Supongamos, siguiendo con nuestro supuesto anterior, que hemos decidido en efecto dividir la red de campus en tres VLANs que denominamos I (de investigación), D (de docencia) y A (de administración); en un momento dado nos encontramos en un armario de cableado configurando un conmutador de 16 puertos y se nos plantea la necesidad de suministrar servicio a 4 equipos de la VLAN I, 4 de la D y 4 de la A. Podríamos asignar por ejemplo los puertos 1 a 4 a la VLAN I, 5 a 8 a la VLAN D y 9 a 12 a la VLAN A, dejando los puertos 13 a 16 libres para futuras ampliaciones (los puertos de una misma VLAN no tienen por que estar contiguos, aunque a menudo se hace así por sencillez). A partir de ese momento el conmutador se comportará como cuatro conmutadores ‘virtuales’ de 4 puertos cada uno (los correspondientes a las tres VLANs y un cuatro correspondiente a los puertos no asignados). De esta forma podemos ir asignando puertos a una u otra VLAN de forma flexible en función de las necesidades.

Nos queda por resolver la conexión de nuestras tres VLANs con el resto de la red. Una posibilidad sería asignar los puertos 13, 14 y 15 a cada una de las tres VLANs y conectarlos con tres cables a tres puertos del conmutador principal del edificio, asignados a las tres VLANs. Siguiendo este sistema llegaríamos al router del campus donde un conmutador con puertos en las tres VLANs se conectaría a tres interfaces físicas diferentes del router. Aunque físicamente las tres VLANs comparten los conmutadores sigue habiendo tres redes separadas en el cableado, ya que nunca viajan por un mismo cable tramas de VLANs diferentes.

Cabría pensar en un nivel adicional de optimización en el que se compartiera un mismo cable para diferentes VLANs. Esto permitiría un ahorro considerable en el número de puertos consumidos en los enlaces troncales o de agregación, especialmente cuando se manejan muchas VLANs; por ejemplo en nuestro caso podríamos emplear solo un puerto (digamos el 13) para conectar las tres VLANs, liberando así los puertos 14 y 15 para otros usos. Esto se denomina configurar un enlace ‘trunk’ o troncal. Como es lógico los enlaces Trunk suelen ser de mayor capacidad que los puertos normales del conmutador ya que soportan un tráfico más elevado; por ejemplo en un conmutador de puertos a 10 Mb/s el enlace trunk típicamente será de 100 Mb/s y en uno con puertos de 100 Mb/s será de Gigabit Ethernet.

Los enlaces Trunk suponen un cambio importante en el funcionamiento de los conmutadores, ya que al mezclar tramas de diferentes VLANs por el mismo cable es preciso marcarlas o etiquetarlas de alguna manera a fin de poder entregarlas a la VLAN adecuada en el otro extremo. El marcado se hace añadiendo un campo nuevo en la cabecera de la trama MAC, lo cual hace que el tamaño de la trama Ethernet supere ligeramente la longitud máxima de 1500 bytes en algunos casos, ya que un conmutador puede recibir una trama de 1500 bytes y si la ha de enviar por un enlace trunk tendrá que incorporarle la etiqueta correspondiente (en ningún caso está permitido fragmentar la trama original). Los primeros sistemas de etiquetado de tramas eran propietarios, por lo que los enlaces trunk solo podían interoperar entre equipos del mismo fabricante. Hoy en día existe un formato estándar para colocar las etiquetas de VLAN que es el conocido como IEEE 802.1q que es el que utilizan prácticamente la totoalidad de los equipos actuales. De esta forma es posible diseñar complejas redes con VLANs utilizando equipos de diferentes fabricantes

Es interesante comentar las consecuencias que la creación de VLANs tiene sobre el funcionamiento del protocolo Spanning Tree. En principio en un conmutador todos los puertos se encuentran asignados a la VLAN por defecto y cualquier bucle que se realice a través de cualquiera de ellos será detectado y desactivado por el conmutador. Sin embargo cuando creamos VLANs nuevas el conmutador ejecuta una instancia diferente de Spanning Tree para cada VLAN con los puertos que tiene asignados, y detectará de forma completamente independiente la aparición de bucles en cualquiera de sus VLANs. Por ejemplo, si en el conmutador de nuestro ejemplo anterior conectamos el puerto 4 con el 5 antes de crear las VLANs esa conexión se detecta como un bucle con lo que el conmutador desactiva una de las dos puertas y por tanto el enlace. En cambio después de haber creado las VLANs esa conexión ya no es un bulce, sino una conexión entre la VLAN I y la D.

En algunos casos una buena combinación de VLANs Spanning Tree permite conseguir mejoras en el rendimiento. Veámoslo con un ejemplo. Supongamos que tenemos una red formada por dos conmutadores, cada uno con 48 puertos 10BASE-T y 2 puertos 100BASE-F; en los puertos 10BASE-T hay configuradas varias VLANs y los dos conmutadores están unidos entre sí por uno de los puertos 100BASE-F configurado como truk (el otro puerto 100BASE-F está libre). Evidentemente por dicho enlace trunk circula mezclado el tráfico correspondiente a todas las VLANs definidas. Supongamos que hemos medido el tráfico en el enlace trunk y hemos observado que se encuentra saturado, por lo que necesitamos aumentar la capacidad de la conexión entre ambos conmutadores y no podemos comprar nuevo equipamiento. Para ello conectamos los dos equipos a través de la segunda interfaz 100BASE-F, pero como los conmutadores no soportan agregación de enlaces el Spanning Tree desactiva la segunda conexión, con lo que no hemos conseguido ningún aumento de la capacidad. Ahora bien, el Spanning Tree elige como vía preferente de comunicación uno de los dos enlaces 100BASE-F en base a un algoritmo determinista, en el que intervienen entre otros parámetros configurables por el usuario. Por defecto todas las VLANs tienen los mismos valores de estos parámetros y todas eligen el mismo enlace como vía preferente, pero es posible alterar el valor de esos parámetros en algunas VLANs forzando así la elección inversa, de forma que podremos repartir el tráfico entre los dos enlaces y en la práctica aumentar el flujo de tráfico entre ambos conmutadores. Jugando con la asignación preferente para cada VLAN de uno u otro enlace trunk podremos conseguir un reparto lo más equilibrado posible entre ambos.

Una propiedad interesante de las VLANs es la posibilidad de configurar interfaces virtuales en los hosts. Supongamos por ejemplo que en nuestro supuesto de campus con tres VLANs, I, D y A, tenemos un servidor importante y potente que deseamos esté accesible de forma directa en las tres, de forma que cualquier host de cualquiera de las VLANs pueda acceder a él sin necesidad de pasar por un router. Una posibilidad sería dotar a dicho servidor de tres interfaces de red y conectar cada una de ellas a un puerto del conmutador asignado a cada una de las VLANs. Cada interfaz recibiría una dirección de red correspondiente a la VLAN en la que se encontrara. Sin embargo esta solución se hace inmanejable si aumenta el número de VLANs. Otra posibilidad, más interesante, sería configurar una interfaz de red del servidor como tres interfaces virtuales y conectarla a un puerto trunk del conmutador. Para esto necesitaremos disponer de drivers con soporte de IEEE 802.1q para la interfaz de red y el sistema operativo que estemos utilizando. Dada la gama de posibilidades existente a veces hay la tendencia a ubicar los servidores principales de una red en todas las VLANs de ésta, a fin de evitar el paso por el router y conseguir una comunicación más directa con los hosts. Conviene destacar sin embargo que en caso de ubicar un host en varias VLANs (tanto si es con una interfaz física como virtual en cada una de ellas) el host tendrá que procesar los paquetes broadcast que reciba en todas las VLANs en las que esté presente.

5.6 EJERCICIOS

1. Indique si es verdadera o falsa cada una de las siguientes afirmaciones:

a) Cuando una red crece de forma considerable es conveniente utilizar puentes para reducir el tráfico broadcast generado a nivel MAC.

b) El Spanning Tree es un protocolo que permite tener enlaces redundantes en una red, pero no repartir tráfico entre ellos.

c) La comunicación full dúplex en redes locales solo es posible cuando la red esta formada por dos estaciones únicamente.

2. Suponga que en un punto de un edificio tiene que unir entre si tres redes Ethernet (segmentos 10Base5 por ejemplo). Para ello puede utilizar bien un puente con tres interfaces, o un repetidor también con tres interfaces. En principio por lo que se refiere a la topología de la red y el número de estaciones puede utilizar uno u otro. Cual sería la diferencia entre emplear el puente o el repetidor? En que caso serían ambos equivalentes, desde el punto de vista del tráfico que circularía por cada segmento?.

3. Siguiendo con el supuesto anterior de los tres segmentos Ethernet (que llamaremos X, Y y Z), suponga ahora que dispone para unirlos de tres puentes y tres repetidores, cada uno con dos interfaces, y puede utilizar cualquier combinación de estos equipos para unir los segmentos entre sí. Diga cuales de las siguientes topologías serían válidas y cuales no, y comente que ocurriria en cada una de ellas. Suponga que los puentes implementan el protocolo spanning-tree.

A: B:

X---r---Y X---p---Y

\ / \ /

r r p p

\ / \ /

Z Z

C: D:

X---p---Y X---r---Y

\ / \ /

r r p p

\ / \ /

Z Z

E: F:

X Y X Y

\ / \ /

r r p p

\ / \ /

Z Z

G: H:

X Y X Y

\ / | \ /

p r | p r

\ / | \ /

Z r- --Z

4. Las prestaciones de un puente se suelen medir en pps (paquetes por segundo) filtrados por interfaz y pps transmitidos; el primer parámetro indica el número de paquetes que el puente es capaz de analizar en cada interfaz (entendiendo por análisis el proceso de interpretar la dirección MAC en la trama y buscarla en sus tablas); el segundo indica que cantidad de paquetes puede pasar el puente de una red a otra (evidentemente un número igual o menor que el primero). Calcule el número de pps que debe poder filtrar y transmitir un puente con dos interfaces 10Base2 para asegurar que el puente no supondrá en ningún caso un factor limitante del rendimiento de la red.

5. Los puentes disponen de una zona de memoria limitada, destinada a almacenar las direcciones MAC de los equipos que están presentes en cada una de las LANs a las que están conectados. Una empresa tiene un puente con capacidad máxima de 1024 direcciones que está conectado a dos redes Ethernet, A y B, con 400 y 800 ordenadores respectivamente. Cuando todos los ordenadores están conectados el puente se bloquea, ya que su tabla de direcciones se desborda. Para resolver el problema el administrador de la red ha decidido partir la Ethernet B por la mitad, instalando otro puente que conecte 400 equipos a cada lado; de esta forma cada puente solo está conectado directamente a 800 equipos (400 en cada red). Ha resuelto el administrador el problema?

6. Una empresa posee una LAN Ethernet formada por dos segmentos de cable coaxial, A y B, unidos entre sí mediante un repetidor. La empresa dispone de dos servidores principales, X e Y, que son accedidos por los demás ordenadores de la empresa. El administrador de la red encarga una auditoría de la red a una empresa especializada, la cual emite el siguiente informe:

El tráfico se comporta de forma regular con un volumen medio de 4 Mb/s, el 50% del cual es generado por el servidor X, el 40% por el servidor Y y el 10% restante por otros ordenadores. El 80% del tráfico generado por el servidor X va dirigido a ordenadores situados en el segmento A, y el 75% del tráfico generado por el servidor Y está destinado a ordenadores ubicados en el segmento B.

Los servidores están ubicados físicamente en la misma habitación que el repetidor, y pueden estar conectados indistintamente a uno u otro de ambos segmentos. Inicialmente ambos servidores se encontraban en el segmento A, pero a la vista del informe anterior el administrador decide cambiar el servidor Y al segmento B. Diga si dicha decisión es correcta, incorrecta o irrelevante en cuanto al rendimiento que podrá obtenerse de la red.

Más adelante la empresa decide sustituir el repetidor por un puente transparente de dos interfaces, para aumentar así la capacidad de su red. Cual sería en este caso la forma óptima de conectar los servidores? y la forma pésima, es decir, la menos eficiente?

7. Un puente transparente con dos interfaces tiene un defecto en la memoria RAM que utiliza para almacenar las direcciones MAC, como consecuencia de la cual ocasionalmente las direcciones contenidas en sus tablas son incorrectas (la tasa de error es de uno en un millón). Que consecuencias tiene esto para el funcionamiento de la red?

a) No funciona en absoluto

b) Funciona normalmente

c) Funciona normalmente, salvo una pequeña merma de la eficiencia

d) Funciona normalmente, salvo una pequeña merma de la eficiencia y una remota posibilidad de que alguna estación quede inaccesible durante algunos minutos.

8. Una empresa tiene dos oficinas, en cada una de las cuales hay una red local constituida por una red 802.3 (10BASE2) a la cual están conectados los ordenadores. Las oficinas están conectadas mediante dos líneas E1, y en cada oficina hay dos puentes transparentes, cada uno conectado a una de las líneas y a la LAN. Los cuatro puentes son del mismo modelo y del mismo fabricante e implementan el protocolo spanning tree.

La única aplicación de red que utilizan los empleados de la empresa es un sistema de vídeoconferencia punto a punto (es decir, uno a uno), y solo la utilizan para comunicar con empleados de la otra oficina, nunca dentro de la misma oficina. La aplicación utilizada genera un paquete cada 40 milisegundos y para funcionar correctamente necesita 160 Kb/s (medidos a nivel de red, es decir contando el paquete de nivel 3 incluida la cabecera).

Calcule:

a) El número máximo de vídeoconferencias simultáneas que podrán mantenerse entre las dos oficinas

b) Si en un momento en que se están celebrando ese número de vídeoconferencias se mide con un analizador el tráfico a nivel físico en la red local de una de las oficinas, que valor se obtendría?

c) El número de paquetes por segundo que estaría procesando cada uno de los puentes en ese momento.

Suposiciones:

No será factor limitante la capacidad de proceso o la memoria de los ordenadores, ni la de los puentes.
Cada ordenador solo puede mantener como máximo una vídeoconferencia
Aunque los puentes encapsulan las tramas 802.3 en tramas HDLC, considere despreciable el overhead introducido por las cabeceras HDLC y el debido al relleno de bits.

9. A continuación se adjunta la salida (parcial) obtenida por consola de dos comandos ejecutados en el conmutador que desde el Servicio de Informática conectaba el campus de Burjassot en 1999. En este caso se refleja únicamente la información relativa a los edificios A, B, C y D del campus. La conexión de estos edificios es como sigue:

Todos los ordenadores del edificio A se conectan al conmutador por 10BASE-FL. Todo el edificio forma una única red Ethernet de 10 Mb/s compartida.
Los edificios B y D se conectan cada uno mediante dos enlaces 10BASE-FL (aproximadamente la mitad de los ordenadores de cada edificio a través de cada uno de los dos enlaces). Cada una de estas dos mitades forma una red Ethernet (un dominio de colisiones).
En el edificio C hay un conmutador con una puerta 100BASE-FX y múltiples puertas de 10 Mb/s (10BASE-T); el conmutador se conecta por la puerta 100BASE-FX al conmutador del Servicio de Informática y las puertas 10BASE-T se usan para repartir lo mejor posible los ordenadores situados en el edificio en dominios de colisión diferentes.

Los comandos muestran una serie de contadores de tráfico de cada uno de los puertos; los contadores fueron borrados a las 14:28 aproximadamente y la ejecución que se muestra corresponde a las 15:32, aproximadamente. Haciendo uso de la información disponible calcule:

o El tráfico medio de cada puerto, en tramas/s y bits/s.

o El tráfico broadcast y multicast (en tramas/s y bits/s).

o El tamaño medio de las tramas recibidas por cada puerto, y el tamaño medio de trama para el tráfico en los seis puertos (ojo, este último no necesariamente será la media de los seis anteriores).

o Realice los comentarios y extraiga las conclusiones que considere pertinentes a la vista de los valores mostrados en estos comandos.

cataciuv> show port

Port Name Status Vlan Level Duplex Speed Type

----- ------------------ ---------- ---------- ------ ------ ----- ------------

4/1 Edif. A (1/1) connected 2 normal half 10 10BaseFL MM

4/2 Edif. B (1/2) connected 2 normal half 10 10BaseFL MM

4/3 Edif. B (2/2) connected 2 normal half 10 10BaseFL MM

4/5 Edif. D (1/2) connected 2 normal half 10 10BaseFL MM

4/6 Edif. D (2/2) connected 2 normal half 10 10BaseFL MM

7/5 Edificio C connected 2 normal half 100 100BaseFX MM

Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize

----- ---------- ---------- ---------- ---------- ---------

4/1 0 0 0 0 0

4/2 4 4 0 0 6

4/3 0 3 0 0 0

4/5 907 130 0 0 0

4/6 5 1 0 0 25

7/5 0 0 0 0 0

Port Single-Col Multi-Coll Late-Coll Excess-Col Carri-Sen Runts Giants

----- ---------- ---------- ---------- ---------- --------- --------- ---------

4/1 495 230 0 0 0 0 0

4/2 1669 602 0 0 0 4 0

4/3 172 40 0 0 0 0 0

4/5 10601 8565 0 0 0 48 0

4/6 12642 5040 0 6 0 6 0

7/5 94 0 0 0 0 0 0

Last-Time-Cleared

--------------------------

Mon Mar 29 1999, 13:27:49

cataciuv> show mac

MAC Rcv-Frms Xmit-Frms Rcv-Multi Xmit-Multi Rcv-Broad Xmit-Broad

-------- ---------- ---------- ---------- ---------- ---------- ----------

4/1 38364 228619 628 104850 1318 88342

4/2 77597 260150 1039 104440 3910 85750

4/3 11875 222617 137 105342 1390 88272

4/5 725014 584790 2315 103164 5030 84632

4/6 1049886 595129 1299 104179 7850 81813

7/5 148030 325113 9600 96204 2473 87192

Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast

-------- -------------------- -------------------- --------------------

4/1 36427 628 1320

4/2 72772 1039 3914

4/3 10350 137 1391

4/5 717826 2317 5032

4/6 1042406 1299 7870

7/5 136001 9610 2477

Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast

-------- -------------------- -------------------- --------------------

4/1 35484 104921 88472

4/2 70088 104510 85879

4/3 29052 105412 88402

4/5 397102 103232 84765

4/6 409260 104250 81926

7/5 113668 96260 87327

Port Rcv-Octet Xmit-Octet

-------- -------------------- --------------------

4/1 10996295 47524699

4/2 13737961 55135179

4/3 1160993 41191428

4/5 533770839 131307431

4/6 506340919 428444894

7/5 26532573 91511781

Last-Time-Cleared

--------------------------

Mon Mar 29 1999, 14:27:49

cataciuv> show time

Mon Mar 29 1999, 15:32:22 MET

cataciuv> exit

Información suplementaria:

Descripción de los campos del comando 'show port' (obtenida directamente del manual del fabricante)

Field Description

Port Module and port number.

Name Name (if configured) of the port.

Status Status of the port (connected, notconnect, connecting, standby, faulty,

inactive, shutdown, disabled, or monitor).

Vlan VLANs to which the port belongs.

Level Level setting for the port (normal or high).

Duplex Duplex setting for the port (auto, full, fdx, half, hdx, a-half, a-hdx,

a-full, a-fdx).

Speed Speed setting for the port (auto, 10, 100,155, a-10, a-100, 4, 16,

a-14, a-16).

Type1 Port type, for example, 10BaseT, 10BaseFL MM, 100BaseTX,

100BaseT4, 100BaseFX MM, 100BaseFX SM, 10/100BaseTX,

TokenRing, FDDI, CDDI, and RSM.

Align-Err Number of frames with alignment errors (frames that do not end with

an even number of octets and have a bad CRC) received on the port.

FCS-Err Number of frame check sequence errors that occurred on the port.

Xmit-Err Number of transmit errors that occurred on the port (indicating that

the internal transmit buffer is full).

Rcv-Err Number of receive errors that occurred on the port (indicating that the

internal receive buffer is full).

UnderSize Number of received frames less than 64 octets long (but are otherwise

well-formed).

Single-Coll Number of times one collision occurred before the port successfully

transmitted a frame to the media.

Multi-Coll Number of times multiple collisions occurred before the port

successfully transmitted a frame to the media.

Late-Coll Number of late collisions (collisions outside the collision domain).

Excess-Col Number of excessive collisions that occurred on the port (indicating

that a frame encountered 16 collisions and was discarded).

Carri-Sen Number of times the port sensed a carrier (to determine whether the

cable is currently being used).

Runts Number of received runt frames (frames that are smaller than the

minimum IEEE 802.3 frame size) on the port.

Giants Number of received giant frames (frames that exceed the maximum

IEEE 802.3 frame size) on the port.

Last-Time-Cleared Last time the port counters were cleared.

Descripción de los campos del comando 'show mac' (obtenida directamente del manual del fabricante)

Field Description

MAC Module and port.

Rcv-Frms Frames received on the port.

Xmit-Frms Frames transmitted on the port.

Rcv-Multi Multicast frames received on the port.

Xmit-Multi Multicast frames transmitted on the port.

Rcv-Broad Broadcast frames received on the port.

Xmit-Broad Broadcast frames transmitted on the port.

Rcv-Unicast Number of unicast frames received on the port.

Rcv-Multicast Number of multicast frames received on the port.

Rcv-Broadcast Number of broadcast frames received on the port.

Xmit-Unicast Number of unicast frames transmitted on the port.

Xmit-Multicast Number of multicast frames transmitted on the port.

Xmit-Broadcast Number of broadcast frames transmitted on the port.

Rcv-Octet Number of octet frames received on the port.

Xmit-Octet Number of octet frames transmitted on the port.

Last-Time-Cleared Date and time of the last clear counters command.

10. Suponga que tiene una red local con dos VLANs que denominaremos ‘Roja’ y ‘Azul’. Un experto ha monitorizado la red durante períodos de intensa actividad y ha llegado a la conclusión de que una de las dos debe partirse porque tiene un tráfico broadcast excesivo, pero ha perdido la nota que indicaba a que red se refería. Como aun dispone del analizador usted decide repetir las medidas para averiguar a cual de ellas se refería el experto, y obtiene los siguientes resultados:

	Tráfico broadcast
VLAN	Paquetes/s	Kbits/s
Roja	100	60
Azul	50	100

A cual de las dos redes se refería el experto?

5.7 SOLUCIONES

S1.-

a) Falsa. El uso de puentes no aísla el tráfico broadcast.

b) Verdadera.Entre dos redes solo un enlace puede estar activo en un momento dado, pues de lo contrario se producirían bucles.

c) Verdadera.La comunicación full dúplex inhibe el protocolo MAC y utiliza el medio de transmisión como si se tratara de un enlace punto a punto, por lo que solo puede funcionar entre dos estaciones.

S2.-

Con el puente el tráfico local de cada segmento no pasa a los otros dos, mientras que con el repetidor si. En un caso ideal en que todo el tráfico de cada segmento fuera local el rendimiento de la red en su conjunto podría llegar a ser de 30 Mb/s utilizando un puente, mientras que con el repetidor estaría limitado a 10 Mb/s.

Las dos soluciones serían equivalentes en el caso de que todo el tráfico fuera broadcast o multicast.

S3.-

Son válidas todas excepto la A (suponiendo que todos los puentes soportan el protocolo spanning tree):

A. Al existir un bucle entre repetidores cualquier señal eléctrica emitida será repetida indefinidamente, lo cual bloquearía toda la red con una colisión permanente en cuanto se intentara transmitir la primera trama.

B. En este caso los puentes detectarían el bucle gracias al spanning tree, con lo que uno de ellos se desactivaría automáticamente, quedando por tanto una topología en V similar a la mostrada en F. Incluye un cierto grado de redundancia que permitiría seguir funcionando en caos de avería de uno de los puentes.

C. El puente detectaría el bucle por spanning tree y se desactivaría, quedando una topología igual que la mostrada en E. Posee redundancia ya que en caso de avería de uno de los repetidores la comunicación se reanudaría a través del puente.

D. Uno de los dos puentes se desactivaría, quedando una topología similar a la mostrada en G. La red podría funcionar en caso de avería de uno cualquiera de los tres elementos.

E. Caso normal de una red formada por tres segmentos unidos entre sí por repetidores. No hay redundancia.

F. Caso normal de tres redes unidas entre sí por puentes. No hay redundancia.

G. Dos redes (ZY y X) unidas entre sí por un puente. Sin redundancia.

H. Red formada por tres segmentos unidos mediante repetidores. El puente detecta el bucle y se desactiva, quedando una topología equivalente a E. En caso de avería del repetidor X-Z el puente entraría en funcionamiento, dando una topología equivalente a G.

S4.-

Para calcular la cantidad máxima de paquetes que puede circular por una red 802.3 utilizaremos el tamaño mínimo de paquete, o sea 64 bytes. En la práctica dichas tramas van acompañadas de 8 bytes adicionales (por el preámbulo y el delimitador de inicio) y de 12 bytes 'virtuales' correspondientes al interframe gap, dando un total de 84 bytes que tardan en enviarse 67,2 ms. Por tanto el número máximo de paquetes que pueden viajar por una red 802.3 es de 1/(67,2 * 10^-6), o sea 14881 paquetes por segundo.

Para que un puente con dos interfaces no suponga factor limitante debe poder filtrar en total 29762 pps, y transmitir 14881 pps entre ambas interfaces. Obsérvese que en el primer caso suponemos que ningún paquete atraviesa el puente, mientras que en el segundo caso suponemos que todo el tráfico pasa de un lado a otro; por tanto en el primer caso cada red tiene 10 Mb/s de tráfico propio, mientras que en el segundo el tráfico propio de una y otra red suma 10 Mb/s (podrían ser por ejemplo 7 Mb/s en una red y 3 en la otra).

S5.-

Con la nueva topología se dispone de tres redes en vez de dos; supongamos que las llamamos A, B y C. Las redes A y B estan unidas por el puente 'viejo', causante de los problemas, que denominamos P1, mientras que B y C están unidas por el puente nuevo, que llamamos P2.

Dividiendo por la mitad la red B no se ha resuelto el problema, ya que aun cuando ahora no hay mas de 800 ordenadores directamente conectados a cada puente éstos siguen teniendo que almacenar en sus tablas las direcciones de todas las estaciones, puesto que cuando un puente propaga una trama de una red a otra lo hace repitiéndola con la misma dirección origen.

Aun en el caso de que no hubiera ningún intercambio de tramas entre ordenadores de la red A y la red C, en cuanto un ordenador de C enviara su primera trama ésta sería propagada por inundación a la red B, momento en el que el puente que conecta con A tendría que anotar en sus tablas la correspondiente dirección origen.

En ambos casos la red solo funcionaría correctamente en el caso de que hubiera menos de 1024 ordenadores enviando tramas.

S6.-

Dado que los servidores X e Y son los que originan la mayor parte del tráfico en la red (90%) es previsible que la mayoría de las colisiones en la red se produzcan por tráfico entre estos dos equipos. Para reducir el riesgo de colisión es conveniente reducir el tiempo de propagación, por lo que la decisión de poner cada servidor en un lado diferente del repetidor es incorrecta, pues aumenta el tiempo de propagación entre X e Y y con ello el riesgo de colisión.

En el caso de poner un puente se separa el tráfico, con lo que la forma óptima de conectar los servidores sí que es la que había adoptado el administrador de la red, es decir el servidor X en el segmento A y el Y en el B; de esta forma el tráfico de X, que va dirigido principalmente a ordenadores ubicados en la red A, no carga a la red Y, y otro tanto ocurre con el tráfico del servidor Y y la red B. A partir de los datos del enunciado podemos calcular como se distribuye el tráfico en este caso:

Tráfico generado por X: 4 * 0,5 = 2 Mb/s

Tráfico generado por Y: 4 * 0,4 = 1,6 Mb/s

Tráfico de X dirigido a A: 2 * 0,8 = 1,6 Mb/s

Tráfico de X dirigido a B: 2-1,6 = 0,4 Mb/s

Tráfico de Y dirigido a B: 1,6 * 0,75 = 1,2 Mb/s

Tráfico de Y dirigido a A: 1,6 - 1,2 = 0,4 Mb/s

Tráfico total en la red A: 2 + 0,4 = 2,4 Mb/s

Tráfico total en la red B: 1,6 + 0,4 = 2 Mb/s

Tráfico total en el puente: 0,8 Mb/s (0,4 en cada sentido)

La forma pésima o menos eficiente sería justo al revés, poner el servidor X en el segmento B y el Y en el A, ya que así se obliga a que una mayoría del tráfico de A pase por B y viceversa. Cuantitativamente sería:

Tráfico en la red A: 1,6 + 1,6 = 3,2 Mb/s

Tráfico en la red B: 2 + 1,2 = 3,2 Mb/s

Tráfico total en el puente: 2,8 Mb/s (1,2 Mb/s de A a B y 1,6 Mb/s de B a A).

S7.-

Los puentes capturan todas las tramas que llegan a sus interfaces y analizan las direcciones de origen, a partir de las cuales construyen sus tablas de direcciones. Dichas tablas les permiten optimizar el enrutamiento de las tramas, enviándolas únicamente a la interfaz donde se encuentra la estación de destino si ésta está identificada; en caso contrario aplican la técnica de inundación, esto es envían la trama por todas sus interfaces excepto por la que ha llegado.

Las tablas de los puentes almacenan parejas dirección MAC-número de interfaz;la dirección MAC tiene 6 bytes, mientras que el número de interfaz dependerá del tipo de puente y del número de éstas, pero generalmente será bastante menor (un byte sería suficiente para 256 interfaces).

Si como consecuencia de un error en la memoria RAM se altera una entrada en la tabla de direcciones pueden ocurrir dos cosas: que afecte a una dirección MAC o a un número de interfaz. En el primer caso (mas probable ya que las direcciones MAC ocupan mas memoria) una dirección desaparece y otra aparece en la tabla; la dirección que desaparece de las tablas seguiría funcionando normalmente, aunque con una pequeña merma en la eficiencia, ya que la siguiente trama después del error llegaría a su destino al aplicar el puente la técnica de inundación; la dirección que aparece como consecuencia del error no corresponderá normalmente a ninguna estación de la red, por lo que pasará desapercibida hasta que caduque por antigüedad. En el remoto caso de que la nueva dirección errónea coincidiera con alguna estación de la red, la estación real quedaría inaccesible hasta que la nueva entrada caducara por antigüedad.

Si el error en la RAM afecta a una entrada en la tabla de interfaces la estación correspondiente quedaría inaccesible hasta que la nueva entrada caducara por antigüedad. Sin embargo como estas entradas tienen un tamaño mucho menor la probabilidad de que esto ocurra es menor.

En resumen, el efecto percibido sería el d):

Funciona normalmente, salvo una pequeña merma de la eficiencia y una remota posibilidad de que alguna estación quede inaccesible durante algunos minutos.

S8.-

a) Aun cuando hay dos líneas E1 solo se podrá utilizar una, ya que el protocolo spanning tree se ocupará de desactivar la otra para evitar que se produzcan bucles entre ambas redes.

Calculamos en primer lugar el tamaño de cada trama transmitida:

160000 * 0,04 = 6400 bits -> 800 bytes

Estos 800 bytes son el paquete a nivel de red. Dicho paquete se incluirá normalmente en una trama LLC (802.2). Sabemos que la cabecera LLC son normalmente 8 bytes (ver apuntes) lo cual nos da un tamaño de trama LLC de 808 bytes.

Para su envío por la red local esta trama LLC se incluirá como parte de datos de una trama 802.3. Esto significa que la trama 802.3 tendrá una longitud de 826 bytes, los 808 de la trama LLC datos mas los campos de dirección origen (6 bytes), dirección destino (6), longitud (2) y checksum (4). Dicha longitud está dentro de los márgenes que establece la norma 802.3 (entre 64 y 1518) por lo que no necesitaremos utilizar relleno ni fragmentar la trama generada por la aplicación. Obsérvese que el preámbulo (7 bytes), el delimitador de inicio de trama (1 byte) y el interframe gap (equivalente a 12 bytes) , al no formar parte del nivel MAC de la trama 802.3 no son transmitidos por los puentes.

Así pues transmitimos 826 bytes, equivalentes a 6608 bits, cada 40 milisegundos. Esto supone un caudal medio de 165,2 Kb/s (6608/0,04). Cada videoconferencia genera 165,2 Kb/s en cada sentido, pero como la línea E1 tiene una capacidad de 2048 Kb/s en cada sentido (pues es full duplex) bastará con calcular un solo sentido para saber el número máximo de vídeoconferencias que pueden celebrarse simultáneamente:

2048/165,2 = 12,4 -> 12 videoconferencias simultáneas

Esto en realidad supone 24 ordenadores participando, 12 en cada lado.

b) Para calcular el tráfico en la red local sí que deberemos tomar en cuenta el preámbulo y el delimitador de inicio, pero no el interframe gap ya que éste no representa la transmisión de información alguna. Tendremos pues que considerar la transmisión de una trama de 834 bytes, o sea 6672 bits, cada 40 milisegundos, lo que nos da un caudal de 166,8 Kb/s por vídeoconferencia (6672/0,04). Pero esta vez si que debemos considerar ambos sentidos, ya que el medio de transmisión de la LAN no es full duplex. Será por tanto:

166,8 * 12 * 2 = 4003,2 Kb/s

Es decir, tenemos una ocupación de la red del 40,03 %

c) Cada vídeoconferencia genera 25 paquetes por segundo (pps) en cada sentido. Los puentes activos están en todo momento recibiendo 25*12 = 300 pps de su interfaz LAN y enviándolos por la línea E1, y recibiendo 300 pps por la interfaz WAN y enviándolos por la LAN. Así pues cada uno procesa 600 paquetes por segundo.

En cuanto a los puentes que están inactivos por el Spanning Tree, no reenvían paquete alguno y por tanto cabría pensar que no procesan ningún paquete; pero estrictamente hablando están recibiendo los 600 pps de la LAN; dichos paquetes han de procesarlos y descartarlos, ya que esta es la única manera como pueden mantenerse alerta para el caso en que reciban algún paquete del protocolo propio de los puentes que les indicará que deben entrar en funcionamiento (por ejemplo por avería de la otra línea E1). Ciertamente el protocolo de control de los puentes introduciría un tráfico residual que no hemos considerado, pero que podemos considerar despreciable.

S9.-

El período de tiempo al que corresponde la muestra es de las 14:27:49 a las 15:32:22, o sea 3873 segundos.

Tráfico en bits/s

Para calcular el tráfico por puerto en bits/s sumaremos los valores de las columnas Rcv-Octet y Xmit-Octet. Por ejemplo para el puerto 4/1 sería:

10996295 + 47524699 = 58520994 bytes = 468167952 bits

Esto nos da un tráfico medio de:

468167950 / 3873 = 120880 bits/s = 120,9 Kb/s

De la misma forma calculamos el tráfico medio para los demás puertos:

Puerto	Kbits Tx + Rx	Tráfico medio Tx + Rx (Kb/s)
4/1	468168	120,9
4/2	550985	142,3
4/3	338819	87,5
4/5	5320626	1373,8
4/6	7478286	1930,9
7/5	944355	243,8

Podemos ver que los puertos 4/5 y 4/6 (correspondientes al bloque D) son con diferencia los que soportan mas tráfico; en el caso del puerto 4/6 la ocupación se enuentra muy próxima al 20%, valor considerado suficiente para plantear una mejora de la red. Es muy probable que en caso de repetir la medida en otra hora mas punta del día (por ejemplo de 12 a 13 horas) el resultado hubiera sido apreciablemente mayor.

Tráfico en tramas/s

Aquí procedemos como antes, sumando esta vez las columnas Rcv-Frms y Xmit-Frms:

Puerto	Tramas Tx + Rx	Tráfico medio (tramas/s)
4/1	266983	68,9
4/2	337747	87,2
4/3	234492	60,5
4/5	1309804	338,2
4/6	1645015	424,7
7/5	473143	122,2

Tráfico broadcast/multicast

Para el tráfico broadcast/multicast calcularemos el número de tramas por segundo a partir de los datos Rcv-Multi, Xmit-multi, Rcv-Broad y Xmit-Broad; alternatiamente podríamos haber utilizado los datos Rcv-Multicast, Rcv-Broadcast, Xmit-Multicast y Xmit-Broadcast:

Puerto	Tramas multicast Tx + Rx	Tráfico medio multicast (tramas/s)
4/1	105478	27,2
4/2	105479	27,2
4/3	105479	27,2
4/5	105479	27,2
4/6	105478	27,2
7/5	105804	27,3

Puerto	Tramas broadcast Tx + Rx	Tráfico medio broadcast (tramas/s)
4/1	89660	23,2
4/2	89660	23,2
4/3	89662	23,2
4/5	89662	23,2
4/6	89663	23,2
7/5	89665	23,2

Puede apreciarse que el tráfico broadcast y multicast es prácticamente el mismo en todos los puertos, salvo por una pequeña diferencia en el caso del tráfico multicast del puerto 7/5 que seguramente se debe a la diferencia de tiempo que se produce en la obtención de los contadores del sistema. También se observa alguna pequeña diferencia, seguramente por el mismo motivo, entre los valores de las columnas Rcv-Multi, Xmit-multi, Rcv-Broad y Xmit-Broad y los de las columnas Rcv-Multicast, Rcv-Broadcast, Xmit-Multicast y Xmit-Broadcast.

Sabiendo que el tráfico broadcast/multicast asciende a 23,2 + 27,2 = 50,4 tramas/s podemos calcular fácilmente el número de tramas unicast por segundo en cada puerto:

Puerto	Tramas unicast Tx + Rx	Tráfico medio unicast (tramas/s)
4/1	71845	18,5
4/2	142608	36,8
4/3	39351	10,1
4/5	1114663	287,8
4/6	1449874	374,3
7/5	277674	71,8

Tamaño medio de tramas

A partir del número de bits calculado en 1 y del número de tramas calculado en 2 obtenemos el tamaño medio de trama para cada puerto:

Puerto	Tamaño medio de trama (en Bytes)
4/1	219,2
4/2	203,9
4/3	180,6
4/5	507,8
4/6	568,3
7/5	249,5

El tamaño medio de trama para los seis puertos lo obtendremos dividiendo el número total de bits por el número total de tramas:

15101239000/(8*4267184) = 442,4 Bytes

Podemos observar una relación entre el tamaño medio de trama en cada puerto y la cantidad de tramas unicast en dicho puerto. A medida que crece la proporción relativa de estas tramas crece el tamaño medio. Esto nos hace pensar que las tramas broadcast/multicast tienen un tamaño de trama pequeño en comparación con el de las tramas unicast.

Nos falta calcular la cantidad de tráfico en bits/s que se produce como consecuencia de las emisiones multi/broadcast. Este no lo podemos calcular de manera directa ya que no disponemos de la cantidad de octetos multi/broadcast transmitidos, solo del número de tramas.

Dado que las tramas multi/broadcast son las mismas en todos los puertos su tamaño medio será también el mismo en todos. Sin embargo el tráfico unicast es distinto en cada puerto, por lo que su tamaño medio será también diferente. Supongamos que denominamos T_m el tamaño de trama multi/broadcast en bits, y T_u4/1, T_u4/2, etc. el tamaño de trama unicast de cada puerto (en bits). Se cumple entonces el siguiente sistema de ecuaciones:

120900 = 18,5 T_u4/1+ 50,4 T_m

142300 = 36,8 T_u4/2+ 50,4 T_m

87500 = 10,1 T_u4/3+ 50,4 T_m

1373800 = 287,8 T_u4/5+ 50,4 T_m

1930900 = 374,3 T_u4/6+ 50,4 T_m

243800 = 71,8 T_u7/5+ 50,4 T_m

Como tenemos un sistema de 6 ecuaciones con 7 incógnitas no es posible resolverlo sin hacer alguna simplificación. Podemos por ejemplo suponer que el tamaño de las tramas unicast será el mismo en dos puertos. Con esto obtendremos un valor aproximado del tamaño de las tramas multicast que nos permitirá conocer el tamaño de las tramas unicast en el resto de los puertos. Esta aproximación será tanto más válida cuanto mayor sea el tráfico multicast, ya que menor será el error introducido por la aproximación anterior. Tomaremos por tanto para nuestra aproximación los datos correspondientes a los puertos 4/1 y 4/3:

120900 = 18,5 T_u+ 50,4 T_m

87500 = 10,1 T_u+ 50,4 T_m

De aquí obtenemos:

T_u = 3976 bits = 497 bytes

T_m = 939 bits = 117 bytes

De lo cual obtenemos que el tráfico multi/broadcast de cada puerto es de:

50,4 * 939 = 47325 bits/s = 47,3 Kb/s

Esto representa el 54% del tráfico total en el puerto 4/3 y el 39% en el 4/1

Una vez sabido el tamaño de trama multi/broadcast podemos calcular el tamaño medio de trama unicast en cada puerto:

Puerto	Tamaño medio trama unicast (en Bytes)
4/1	497
4/2	323
4/3	497
4/5	576
4/6	629
7/5	342

Colisiones

Vamos a intentar calcular la tasa de colisiones en cada puerto. Dado que cuando ocurren múltiples colisiones no se nos da el número de reintentos vamos a adoptar la simplificación mas optimista de suponer que las múltiples colisiones se resuelven siempre en el segundo intento, por lo que las contaremos como dos colisiones sencillas:

Puerto	Colisiones	Tramas transmitidas	Tasa de colisiones (%)
4/1	955	228619	0,4
4/2	2873	260150	1,1
4/3	252	222617	0,1
4/5	27731	584790	4,5
4/6	22722	595129	3,7
7/5	94	325113	0,03

Como era de esperar los puertos con más tráfico (4/5 y 4/6) son los que tienen una tasa de colisiones mayor. El puerto 7/5, al ser una conexión directa entre dos conmutadores, presenta una tasa de colisiones mucho menor que el resto de puertos; de hecho este puerto podría estar funcionando en modo full-dúplex, con lo que las colisiones se habrían suprimido totalmente.

También podemos comparar la relación entre colisiones sencillas y colisiones múltiples:

Puerto	Relación colisiones múltiples/sencillas
4/1	0,46
4/2	0,36
4/3	0,23
4/5	0,81
4/6	0,40
7/5	0,00

Esta relación, que es del mismo orden en todos los puertos salvo el 7/5, nos indica que el nivel de saturación de la red cuando ha estado en uso ha sido relativamente parecido en todos los casos, es decir, que el bajo tráfico registrado en los puertos 4/1, 4/2 y 4/3 se debe a que han sido usados durante poco tiempo dentro del intervalo estudiado, pero durante ese tiempo han tenido un tráfico de una intensidad comparable al del puerto 4/6; destaca el puerto 4/5 con un valor próximo a la unidad, lo cual hace pensar que ha tenido un uso mas intenso que los demás puertos, aunque haya registrado valores de tráfico medio inferiores al 4/6.

Se observan 6 'Excess-Col' en el puerto 4/6,.lo cual hace pensar que se haya producido algún momento de mucha saturación en la red, o en el mal funcionamiento de algún equipo.

Fiabilidad

En cuanto a la tasa de errores podemos para calcularla agrupar los que aparecen como 'Align-Err' y los 'FCS-Err'. Si suponemos que cada trama errónea contiene un solo bit erróneo podemos calcular fácilmente la tasa de error o BER. Debemos tomar en cuenta al hacer este cálculo que la detección de errores solo se realiza sobre las tramas recibidas, no sobre las transmitidas:

Puerto	Errores	Mbits recibidos	Tasa de error (BER)
4/1	0	88,0	< 10^-8
4/2	8	110	7 * 10^-8
4/3	3	9,3	3 * 10^-7
4/5	1037	4270	2 * 10^-7
4/6	6	4051	1,5 * 10^-9
7/5	0	21,2	< 5 * 10^-9

Se observa que la tasa de error es anormalmente elevada en los puertos 4/3 y 4/5, por lo que estas redes deberían revisarse.

S10.-

El mayor problema del tráfico broadcast no es el caudal que ocupa éste en la red local, sino la cantidad de ciclos de CPU que se pierden en todas las máquinas de la VLAN al tener que procesar estas tramas en el nivel de red del host. Este efecto es directamente proporcional al número de tramas broadcast por segundo, y prácticamente independiente del tamaño de éstas, por lo que la VLAN que habría que dividir primero es la roja, aun cuando la VLAN azul tiene un mayor caudal de tráfico broadcast.

En la práctica sería difícil que se diera el supuesto de este ejercicio, ya que generalmente el tamaño medio de las tramas broadcast en diferentes redes es similar, por lo que suele ser equivalente medirlo en paquetes por segundo o en bits por segundo.

[1] Con la notable excepción de la videoconferencia punto a punto, donde la información fluye de forma full-dúplex bastante simétrica.

[2] La idea es parecida a la utilizada en los módems de red telefónica conmutada, que mediante un proceso de negociación acuerdan funcionar según la velocidad más alta soportada por ambos.

[3] En el caso de que ninguno de los dos conmutadores implementara el protocolo Spanning Tree se produciría un bucle que colapsaría e inutilizaría ambos enlaces.