Segmentación Ethernet


La historia de cómo Ethernet maneja las colisiones y los dominios de colisión se remonta a la investigación
realizada en la Universidad de Hawai en 1970. En su intento por desarrollar un sistema de comunicaciones
inalámbrico entre las islas de Hawai, los investigadores de la Universidad desarrollaron un protocolo llamado Aloha. En realidad, el protocolo de Ethernet se basa en el protocolo Aloha.

Una habilidad importante de todo profesional de networking, es la capacidad de reconocer los dominios de
colisión. Conectar varios computadores a un solo medio de acceso compartido que no tiene ningún otro
dispositivo de networking conectado, crea un dominio de colisión. Esta situación limita el número de
computadores que pueden utilizar el medio, también l amado segmento. Los dispositivos de Capa 1 amplían
pero no controlan los dominios de colisión.

Los dispositivos de Capa 2 dividen o segmentan los dominios de colisión. El control de propagación de
trama con la dirección MAC asignada a todos los dispositivos de Ethernet ejecuta esta función. Los
dispositivos de Capa 2, los puentes y switches, hacen un seguimiento de las direcciones MAC y el
segmento en el que se encuentran. Al hacer esto, estos dispositivos pueden controlar el flujo de tráfico en el
nivel de Capa 2. Esta función hace que las redes sean más eficientes, al permitir que los datos se
transmitan por diferentes segmentos de la LAN al mismo tiempo sin que las tramas colisionen. Al usar puentes y switches, el dominio de colisión se divide efectivamente en partes más pequeñas, que se transforman cada una a su vez en un dominio de colisión.

Estos dominios de colisión más pequeños tendrán menos hosts y menos tráfico que el dominio original. Cuanto menor sea la cantidad de hosts en un dominio de colisión, mayores son las probabilidades de que el medio se encuentre disponible. Siempre y cuando el tráfico entre los segmentos puenteados no sea demasiado pesado, una red puenteada funciona bien. De lo contrario, el dispositivo de Capa 2 puede desacelerar las comunicaciones y convertirse en un cuello de botella en sí mismo.

Los dispositivos de Capa 3, al igual que los de Capa 2, no envían las colisiones. Es por eso que usar dispositivos de Capa 3 en una red produce el efecto de dividir los dominios de colisión en dominios menores.

Los dispositivos de Capa 3 tienen más funciones que sólo las de dividir los dominios de colisión. Los dispositivos de Capa 3 y sus funciones se tratarán con mayor profundidad en la sección sobre dominios de
broadcast.

Broadcasts de Capa 2

Para comunicarse con todos los dominios de colisión, los protocolos utilizan tramas de broadcast y multicast a nivel de Capa 2 en el modelo OSI. Cuando un nodo necesita comunicarse con todos los hosts de la red, envía una trama de broadcast con una dirección MAC destino 0xFFFFFFFFFFFF. Esta es una dirección a la cual
debe responder la tarjeta de interfaz de la red (Network Interface Card, NIC) de cada host.

Los dispositivos de Capa 2 deben inundar todo el tráfico de broadcast y multicast. La acumulación de tráfico de broadcast y multicast de cada dispositivo de la red se denomina radiación de broadcast. En algunos casos, la circulación de radiación de broadcast puede saturar la red, entonces no hay ancho de banda disponible para los datos de las aplicaciones. En este caso, no se pueden establecer las conexiones en la red, y las conexiones existentes pueden descartarse, algo que se conoce como tormenta de broadcast. La probabilidad de las tormentas de broadcast aumenta a medida que crece la red conmutada.

Como la NIC tiene que interrumpir a la CPU para procesar cada grupo de broadcast o multicast al que
pertenece, el efecto de radiación de broadcast afecta el rendimiento de los hosts de la red. La Figura muestra los resultados de pruebas que Cisco condujo sobre el efecto de la radiación de broadcast en el
rendimiento de un CPU de Sun SPARCstation 2 usando una tarjeta Ethernet estándar incorporada. Como se ve en los resultados, los broadcasts que inundan la red efectivamente pueden desconectar una estación de trabajo IP. Aunque parezca extremo, durante las tormentas de broadcast, se han observado picos de miles de broadcasts por segundo. Pruebas en un entorno controlado con una variedad de broadcasts y multicasts de la red mostraron una degradación del sistema mensurable a tan sólo 100 broadcasts o multicasts por segundo.

La mayoría de las veces, el host no se beneficia al procesar el broadcast, ya que no es el destino buscado. Al host no le interesa el servicio que se publicita, o ya lo conoce. Los niveles elevados de radiación de broadcast pueden degradar el rendimiento del host de manera considerable. Las tres fuentes de broadcasts y multicasts en las redes IP son las estaciones de trabajo, los routers y las aplicaciones multicast.

Las estaciones de trabajo envían en broadcast una petición de protocolo de resolución de direcciones
(Address Resolution Protocol, ARP) cada vez que necesitan ubicar una dirección MAC que no se encuentra en la tabla ARP. Aunque los números en la figura pudieran parecer bajos, representan una red promedio IP bien diseñada. Cuando el tráfico de broadcast y multicast hace un pico debido a una tormenta, la pérdida pico de la CPU puede tener una magnitud mayor al promedio. Las tormentas de broadcast pueden originarse en un dispositivo que requiere información de una red que ha crecido demasiado. La petición original recibe tantas respuestas que el dispositivo no las puede procesar, o la primera petición desencadena peticiones similares de otros dispositivos que efectivamente bloquean el flujo de tráfico en la red.

Como ejemplo, el comando telnet mumble.com se traduce a una dirección IP a través de una búsqueda en el sistema de denominación de dominios (Domain Naming System, DNS). Para ubicar la dirección MAC
correspondiente, se envía una petición ARP. Por lo general, las estaciones de trabajo IP guardan entre 10 y
100 direcciones en sus tablas ARP durante dos horas aproximadamente. La velocidad de un ARP en una estación de trabajo típica puede ser cercana a 50 direcciones cada dos horas o 0,007 ARP por segundo. Eso significa que 2000 estaciones terminales IP producen cerca de 14 ARP por segundo.

Los protocolos de enrutamiento que están configurados en la red pueden aumentar el tráfico de broadcast de modo significativo. Algunos administradores configuran todas las estaciones de trabajo para que ejecuten el protocolo de información de enrutamiento (Routing Information Protocol, RIP) como una política de redundancia y alcance. Cada 30 segundos, el RIPv1 utiliza broadcasts para retransmitir toda la tabla de
enrutamiento a otros routers RIP. Si 2000 estaciones de trabajo se configuraran para ejecutar RIP y, en
promedio, se requieren 50 paquetes para transmitir la tabla de enrutamiento, las estaciones de trabajo
generarían 3333 broadcasts por segundo. La mayoría de los administradores de red sólo configuran un número pequeño de routers, por lo general de cinco a diez, para ejecutar un RIP. En el caso de una tabla de
enrutamiento que tiene un tamaño de 50 paquetes, 10 routers RIP generarán cerca de 16 broadcasts por
segundo.

Las aplicaciones multicast en IP pueden afectar negativamente el rendimiento de redes conmutadas de gran
escala. Aunque el multicast es una forma eficiente de enviar un flujo de datos de multimedia a muchos usuarios en un hub de medios compartidos, afecta a cada usuario de una red plana conmutada. Una aplicación de paquete de video determinada, puede generar un flujo de siete megabytes (MB) de datos
multicast que, en una red conmutada, se enviarían a cada segmento, causando una gran congestión.

Califica este Artículo
0 / 5 (0 votos)

Categoría: Conectividad y Redes.




Deja un comentario