December 15, 2010

AUTOMATIZACIÓN: La clave para la ¿siguiente? actual generación de redes

Cuántas veces no hemos oído el argumento del TCO para justificar la compra de nueva tecnología. En el apartado de las redes, esto ha justificado desde la migración a VoIP, hasta esotéricas arquitecturas de cores agregados. Durante el año que entramos la guerra entre TRILL y SPB probablemente se llene del termino TCO conforme los fabricantes definan sus preferencias. Esto es sólo un ejemplo del uso de este término.

Sin embargo, queda para analizar los ahorros de TCO generados en el acceso de las redes. Obviamente los fabricantes tenemos nuestras inclinaciones, somos geeks de corazón, nos preocupa más como conectar dos equipos que cómo se conecta nuestro usuario. Esto da lugar a un lamentable agujero en la profundidad como hasta ahora se ha tratado el escabroso asunto de la conectividad de los usuarios y su impacto en el TCO.

A los tecnólogos nos encanta hablar de las bondades y supuestas bajadas de TCO que aportan unos u otros protocolos hablados entre equipos. Cómo los tiempos de convergencia de una u otra arquitectura abundan en la reducción de TCO. Todos estos argumentos afectan a unas pocas decenas de enlaces entre unas pocas decenas de equipos.
La relación entre enlaces a los usuarios de la red y enlaces dentro de la red puede muy fácil estar en el orden de 1:100, es decir hay un enlace de red por cada 100 enlaces a usuarios. La lógica nos dice pues que pasaremos 100 veces más tiempo configurando los enlaces de los usuarios que los enlaces entre equipos.

¿Bajo qué razonamiento una reducción en el tiempo que paso configurando los enlaces de red puede afectar salvo en un 1/100 del TCO? Curiosamente la reducción de TCO del acceso es muy fácil de conseguir. Lamentablemente se le ha prestado tan poca atención que existen pocas o ninguna soluciones orientadas a ella. Y todos sabemos que si Cisco no tiene solución, entonces es que no se puede, ¿o sí?.

¿Cuántos tipos de configuraciones distintas pueden aparecer en el acceso, 1, 2, 100?
Desde luego finitas, cada conexión que realizamos a la red, requiere de un operador que revise bajo que modelo encaja el usuario y que configure el puerto de red de forma adecuada. Esto repetido por todos los usuarios. Sigamos contando y pasemos de usuarios a dispositivos, cada vez más cosas se conectan a la red IP:

• Dispositivos SCADA de control – alguna vez hablaremos de ellos que dan lugar a un post completo.
• Video en IP.
• Voz en IP.
• Sistemas de información al público.
• Thin clients.
• Sistemas de control de edificio inteligente.
• Servidores virtuales en un CPD

Cada uno de estos dispositivos requiere sus propios parámetros de conexión de red y las cantidades de cada uno pueden elevarse a los miles en una red mínimamente compleja. La capacidad que tiene cada uno de estos sistemas para volver loco a un administrador de Red preguntado por:

• Dónde está conectado X (generalmente X proporcionado mediante un esotérico nombre DNS o de host o Netbios, nada de las cálidas direcciones IP o MAC)
• Está en la Vlan adecuada
• Quién lo conectó
• Cuándo se conectó

Es incomparable.

La única solución para administrar estas redes es la automatización de la red. Mientras que podemos tener miles de dispositivos conectados a la red y creciendo, todos caen en un número infinitamente menor de categorías y configuraciones. Cada categoría puede tener asociada su configuración y esa configuración asociarse al puerto de conexión automáticamente al descubrir el tráfico adecuado. Ésto es reducción de TCO en el acceso. Eliminar el factor humano de las conexiones de dispositivos individuales para centrarse en las configuraciones comunes de las clases de dispositivos o usuarios que se conectan a la red.
Esto es lo que lleva haciendo durante años la solución NAC de Enterasys. El uso de esta tecnología permite a los operadores centrarse en los problemas y eliminar las tareas repetitivas de configuración de elementos individuales, sean éstos los que sean. El beneficio es enorme en TCO, pero es aún mayor en la fase de análisis, cuando una búsqueda en una base de datos proporciona información de:

• Lugar de la conexión
• Nombre DNS, netbios, host, IP, MAC del equipo conectado
• Datos adicionales:
o UUID de máquina virtual
o Nombre de máquina virtual
o Software instalado
o Versión de OS
o Versión de kernel de Linux

• Configuración aplicada a ese dispositivo.
o Razones por las que se le ha aplicado esta esta configuración a la conexión
Permitiendo la resolución de problemas en una llamada.

Las redes Enterasys pueden habilitarse de forma automática con estas funcionalidades, hemos sido tan flexibles como para poder activar estas funciones en redes de otros como Cisco, Avaya, Alcatel, dado que los respectivos proveedores no proporcionan una arquitectura que lo permita de forma nativa.

Si de verdad queremos bajar el TCO de nuestras redes, haríamos bien prestando más atención a las arquitecturas NAC y algo menos a las arquitecturas de core.

About The Contributor:
Salvador FerrerDirector of Solutions Architecture

Salvador Ferrer has been with Extreme Networks for over five years is the Director of Solutions Architecture. Ferrer has more than 15 years of leadership experience in the networking market at companies such as Nortel and Bull.

See My Other Posts

Leave a Reply

Your email address will not be published. Required fields are marked *