Llegamos a ustedes gracias a:



Reportajes y análisis

Las redes planas son el futuro

[04/02/2011] Una red larga y plana de capa 2 es la clave para una nueva estructura unificada del centro de datos. La idea es que todo en el centro de datos -servidores, aplicaciones y almacenamiento- debe ser parte de una capa plana de dos grandes estructuras.

La virtualización de servidores es la gran razón para que sean planas. La gran ventaja de una red plana es su flexibilidad. Una red de capa 2 es plug and play, sin necesidad de reconfigurar o cambiar las direcciones IP cuando los recursos se mueven. Esto hace más fácil la aplicación de virtualización de servidores con menos posibilidad de errores de configuración, y hace que el centro de datos esté más cerca de convertirse en una nube.
La única manera en que esto puede funcionar es que el piso nuevo no sea como el viejo. Lo qué tiene que cambiar es el viejo algoritmo de árbol de expansión, ya que crea problemas de escala. El árbol de expansión es ineficiente, ya que no utiliza todas las rutas disponibles entre los switches y las rutas no siempre son las más cortas o más rápidas.
Las ineficiencias del árbol de expansión crean otro problema. El tráfico entre los servidores, las aplicaciones y el almacenamiento se están convirtiendo en el tipo de tráfico dominante en el centro de datos y requiere muy baja latencia. El tráfico de almacenamiento requiere que la red tenga una característica sin pérdida, lo que significa que los switches ya no pueden desechar los paquetes, sino que deben evitar la congestión. El árbol de expansión no puede cumplir con el reto de latencia extremadamente baja y sin pérdidas.
La pregunta siempre ha sido como superar las limitaciones del árbol de expansión mientras se preserva la flexibilidad de una red plana. Las revisiones del protocolo árbol de expansión se han implementado en los últimos años haciéndolo mejor, pero nunca ha resuelto por completo los problemas.
El cambio que hace que la nueva prescripción plana de la red trabaje es el enrutamiento en la Capa 2. Se libera del árbol de expansión y sus limitaciones, preservando el carácter plug and play de la Capa 2. El enrutamiento selecciona la ruta más corta y más rápida. También utiliza todos los eslabones en el centro de datos, aumentando instantáneamente la capacidad de la red y disminuyendo la congestión. Se llama plana porque todavía utiliza la MAC (Media Access Control) address, lo que significa que el espacio de direcciones es plano, ya que no tiene estructura jerárquica, como las direcciones de ubicación que dependen de IP.
¿Por qué no se hizo el enrutamiento en el pasado? La razón es simple, era demasiado costoso en la década de 1980 cuando el bridging y el routing se inventaron. El enrutamiento necesitaba la ayuda de una dirección que contenga información de ubicación para proporcionar un aumento de rendimiento, permitiendo que los routers fueran construidos utilizando menos potencia de procesamiento y memoria. Ahora, la memoria y los procesadores son más potentes y más baratos. Hoy es posible construir grandes redes de centros de datos que se pueden enrutar según la dirección MAC de localización independiente.
Aquí viene TRILL
A la industria de redes rara vez se le ocurre una sola solución. Hay dos respuestas estándar y muchos vendedores están aplicando sus propias soluciones.
Una de las respuestas se llama TRILL. TRILL significa Interconexión transparente de un montón de enlaces (Transparent Interconnection of Lots of Links, en inglés). TRILL se está trabajando en la IETF. El protocolo de base fue aprobado en marzo del año pasado. Se espera que este año sea aprobada la norma final con todas las piezas necesarias para hacer que funcione.
La forma más sencilla de pensar en TRILL es que encapsula los paquetes a lo largo de un número de saltos. A continuación, enruta el mensaje a través de los switches TRILL del centro de datos utilizando el protocolo de enrutamiento Sistema Intermedio a Sistema Intermedio (IS-a-IS), que lo encapsula antes de entregarlo a su destino.
Los switches de Capa 2 que implementan TRILL se llaman RBridges.  RBridges es la abreviatura de puentes de enrutamiento. Bridges (Puentes) era el nombre del switching de nivel 2 antes que los departamentos de marketing de los proveedores se involucraran. Los RBridges en los centros de datos intercambian el control de los mensajes sobre las características de la red actual, permitiéndoles calcular las mejores rutas.
Los RBridges también encuentran automáticamente la mejor estructura para el envío de mensajes de multi difusión y de difusión entre ellos. Un punto importante es que las rutas no tienen por qué ser simétricas; es decir, la ruta entre A y B no tiene por qué seguir el mismo camino de regreso de B a A. Al igual que en el caso de IP, cada dirección es el mejor camino, pero en algunos casos, los caminos seguirán la misma ruta.
Los RBridges aprenden las direcciones MAC y VLAN de los dispositivos conectados a ellos. Cuando un dispositivo envía un mensaje a un destino que no está directamente conectado al RBridge, éste emite el paquete a todos los otros RBridge para descubrir quién tiene el dispositivo de destino. El RBridge que tiene el dispositivo responde, dejando que el RBridge de origen sepa a donde tiene que enviar los mensajes.
Otras forma en que los RBridges aprenden direcciones MAC es utilizando su protocolo de distribución de información de direcciones de punto final; al configurarlos manualmente o mediante otros registros de protocolo de capa 2. La mayoría de las empresas encontrará que el método de aprendizaje automático es adecuado. Todas las entradas de la tabla agotan por lo que si el dispositivo se mueve, el RBridge solo tiene la información desactualizada por un corto período tiempo. Los switches intermedios, tales como los switches de core y de agregación, no aprenden direcciones de la estación final MAC, reduciendo su carga.
Los RBridges envían paquetes de datos entre ellos mediante el encapsulado usando un pequeño encabezado TRILL de 8 bytes. La cabecera tiene el siguiente RBridge en la ruta del paquete. Cada RBridge a lo largo del camino, lo reemplaza por la identidad del siguiente RBridge de la trayectoria. Esta sustitución de ID en cada paso, abre la posibilidad de que se puedan formar loops, un problema que el IP tuvo en sus inicios. La solución es la misma que se aplicó al IP: un contador de tiempo para vivir (TTL) que cada RBridge disminuye... Cuando llega a cero, el mensaje es descartado. Los datos de multidifusión presentan más de un problema y fue agregado un mecanismo adicional llamado Reverse Path Forwarding Check (Comprobación inversa de ruta) para identificar posibles bucles. Reverse Path Forwarding Check es una manera en que el switch puede comprobar si el paquete llegó al puerto esperado. El RBridge descarta paquetes recibidos desde el puerto equivocado.
TRILL es totalmente compatible con las VLAN. RBridges identifica un dispositivo tanto por su número MAC o VLAN. Esto les permite tratar de distinta manera a cada MAC y VLAN. Un ejemplo simple con un servidor con dos aplicaciones que utilizan diferentes números de VLAN demuestra la flexibilidad de TRILL. El RBridge puede enviar el flujo de cada VLAN por un camino diferente a través de la red. Además, si el servidor está conectado a dos RBridges diferentes, entonces un par de MAC y VLAN pueden estar asociados a una RBridge mientras que el otro par de MAC y VLAN puede estar asociado con la otra RBridge.
Acortando camino con el Bridging
Una alternativa a TRILL es Shortest Path Bridging (SPB). SPB se define en el estándar IEEE 802.1aq y se basa en el trabajo previo realizado para proporcionar Backbone Bridges (PBB), destinado a servidores y proveedores de Metro Ethernet. Esto proporciona SPB con una ventaja, ya que la mayoría de técnicas de gestión y control no necesitan ser modificadas para seguir el SPB. Se espera que el trabajo sobre la norma se termine este año.
TRILL y el SPB tienen muchos conceptos en común. SPB, al igual que TRILL, utiliza IS-a-IS para comprender la topología del centro de datos y calcular la mejor ruta a través de la red. Encapsula los paquetes con la mayoría de las implementaciones usando 802.1ah (Mac en Mac). Mac en Mac coge el paquete existente y pone un nuevo encabezado en él con la dirección MAC del primer switch SPB y el switch de llegada SPB. Esta versión de SPB también se conoce como SPBM. Toda la información del encabezado del paquete original se conserva -igual que en TRILL- en el mensaje encapsulado.
SPB se entera de donde están las direcciones MAC por la petición de difusión de ARP, que la transmitirá a los demás nodos de SPB y luego emitirá una respuesta, tal como lo hace TRILL. Todos los switches de SPB que ven la emisión aprenden dónde está el origen, ampliando la red rápidamente. Solo los switches de los extremos conocen la localización de los puntos finales, una mejora sobre el viejo árbol de expansión en el que cada nodo del árbol tenía que aprender todos los dispositivos.
La diferencia clave entre el SPB y TRILL es que SPB utiliza las estructuras de los árboles, pero de una manera creativa para ofrecer la misma flexibilidad y robustez que TRILL. El antiguo árbol de expansión tenía un árbol de expansión para toda la red de Capa 2. Una nueva versión, 802.1Q, mejoró esto con un árbol de expansión para cada VLAN. El punto clave es que con el árbol de expansión todos los switches usan el mismo árbol universal. SPB mejora los árboles de expansión pues cada switch genera su propio árbol para cada VLAN, lo que representa el mejor camino para que llegue a los otros switches. En lugar de un árbol compartido por todos los switches, cada switch SPB tiene su propio árbol optimizado basado en IS-a-IS. Esto permite que se usen todos los enlaces en el centro de datos. SPB permite hasta 16 rutas o árboles entre dos switches con más posibles extensiones para el protocolo.
Otra diferencia entre TRILL y SPB es que las rutas de SPB son simétricas. La ruta de A a B y el regreso de B a A utilizan el mismo camino. Las rutas simétricas permiten que SPB aproveche la mayor parte de la gestión y control ya existentes como el bucle de retorno y trazado de ruta. SPB también utiliza el mismo árbol, tanto para el tráfico unicast y multicast, donde TRILL no necesariamente utiliza el mismo camino.
SPB también difiere de TRILL en la forma en que previene la formación de bucles. SPB no utiliza un enfoque TTL. En su lugar, determina qué puertos están esperando recibir paquetes; esto lo realiza mediante un Reverse Path Forwarding Check (Comprobación inversa de ruta).
Un gran switch
Una alternativa es hacer que los switches del centro de datos actúen como un gran switch- uno virtual. Esto permite que los proveedores implementen enrutamiento en el cluster de sus propios switches como rutas de switches entre los puertos. La mejor ruta puede ser utilizada y todos los enlaces entre switches están activos. Esto resuelve el problema que tanto TRILL y el SPB están haciendo frente, y provee un buen paso a un enfoque basado en estándares. El switch virtual aparece ante los otros switches en el centro de datos como un solo switch e interopera con equipos de otros proveedores. Brocade, Extreme, Juniper y HP tienen o planean lanzar este año una versión de la solución de interruptor virtual.
El mayor problema con este enfoque es que es propietario. La solución solo funciona con el switch de un fabricante, sin que esté permitida la mezcla o congruencia entre marcas. Algunos proveedores han reducido la limitación al basar su solución en normas. Brocade se basa en TRILL y Extreme basa su solución en la agregación de enlaces. La siguiente cuestión es que el número de switches que se pueden unir para formar el interruptor virtual es limitado. En general, el número de switches que se pueden unir es entre 9 y 11.
Muchos proveedores ven al switch virtual como un escalón a una solución basada en TRILL o en SPB. Se puede entregar ahora, mientras aun se trabaja sobre el enfoque basado en estándares. Además, una vez que han aplicado TRILL o SPB todavía pueden mantener el switch virtual. Este switch aparece como un gran RBridge o switch SPB. La ventaja de este enfoque es que con el switch virtual se configuran automáticamente.
VLAN
Hay un beneficio secundario interesante de TRILL y el SPB que ayuda a implementar la virtualización de servidores o potencializa un impacto negativo en función de cómo se utilizan las VLAN. Ambas soluciones utilizan un número de VLAN que no tiene relación con el número de VLAN que utiliza el dispositivo. Por ejemplo, RBridges utiliza su número de VLAN propio para la comunicación entre ellos, un número que no tiene nada que ver con las VLAN que usan los servidores. La aplicación VLAN se oculta por el encabezado TRILL y no se utiliza en el envío entre RBridges. Esto significa que el número real de la aplicación VLAN solo se utiliza en el borde, entre los RBridges y el dispositivo.
El lado positivo es que hace más fácil mover los dispositivos virtualizados. Hoy, cuando un servidor virtual se muda a un nuevo switch, ese swich debe ser actualizado para apoyar a la VLAN. Además, todos los switches inmediatos en los caminos que utilizan los dispositivos, tienen que ser actualizado para apoyar a la VLAN. Los vendedores de interruptores y virtualización disponen de sistemas para actualizar la VLAN en el interruptor al que el dispositivo se conecta y retirarlo cuando el servidor virtual es dado de baja, pero nadie ha elaborado una buena manera de manejar esto en los switches intermedios. RBridges elimina el problema inmediato del interruptor pues RBridges no utiliza la aplicación VLAN y por lo tanto no tiene que ser configurado para el número de VLAN del dispositivo.
El problema potencial con esto es que si las VLAN se utilizan para mantener el tráfico fuera de ciertos switches o rutas; entonces, RBridges no lo hará. Esto no debería ser un problema para la mayoría de las empresas ya las VLAN no se utilizaban para vigilar switches intermedios, sino que solían evitar que el tráfico llegue a los servidores no autorizados, algo que RBridges seguirá haciendo. Es posible superar este problema con el SPB, pero se requiere una cuidadosa configuración.
Los fabricantes toman partido
Blade Networking, Brocade, Cisco, Extreme Networks, Force10 Networks, Huawei y HP planean apoyar TRILL. Cisco se refiere a su solución FabricPath como una versión pre-estándar de TRILL. La versión de Cisco tiene algunas características adicionales no incluidas en la norma para admitir la migración y las características que le agregaron antes de TRILL. Es necesario señalar que cuando TRILL salga, los clientes tendrán que migrar a él. Si necesitan las características propietarias de FabricPath no serán capaces de soportar a TRILL ni a FabricPath ejecutándose en el switch. Brocade tiene una temprana versión de TRILL como una parte en su próximo lanzamiento Virtual Cluster Switching (VCS).
SPB también tiene sus fans. Avaya está implementando SPB en sus switches y espera que se envíen en el primer trimestre del 2011. Alcatel-Lucent, Enterasys, HP y Huawei están planeando apoyar a SPB.
Las soluciones múltiples serán una realidad en el 2011 y la posibilidad de ir más allá. La noticia no es del todo mala. Los vendedores están llevando a cabo pruebas para asegurarse de que sus implementaciones van a funcionar.
Robin Layland, Network World (EE.UU.)