Hola, ¿qué tal? Bienvenida o bienvenido a este entrenamiento de Aruba Mobility Essentials. Mi nombre es Ricardo Cobos y ahora estoy por comenzar la parte 2-4, que habla de arquitectura de WLAN. Esencialmente, el contenido del módulo explica las maneras en las que podemos implementar los diferentes equipos de red inalámbrica, como pueden ser los "access points" y de qué manera ellos van a interactuar con los usuarios, con otros dispositivos de red, y cómo es que tú los vas a poder gestionar. En el caso de Aruba Networks, realmente ofrece un abanico bastante grande de opciones para cumplir los requerimientos del cliente o tus propias necesidades. Vamos a comenzar con ellos. El primero es "access points" autónomos. Los "access points" autónomos o "Autonomous AP", son, esencialmente, dispositivos que se configuran de manera manual; son entidades completamente independientes y, por eso, tú vas a tener que configurar cada uno de ellos y cada equipo va a tener que guardar su propia configuración. Prácticamente, en un principio, todos los "access points" fueron autónomos, lo cual era bueno porque, normalmente, las implementaciones eran pequeñas. Nosotros teníamos, en un principio, tal vez, tres "access points", cuatro, tal vez cinco, entonces, configurar cada uno de ellos era bastante eficiente porque la cantidad no era muy elevada y cada uno de ellos podría tener características o configuraciones diferentes. Sin embargo, con el tiempo, los ingenieros se dieron cuenta que cuando nosotros hacemos una implementación de tipo Enterprise, lo que nosotros queremos hacer es hacer una red uniforme y homogénea. En otras palabras, aunque tengas muchas características que pudieras configurar de manera individual para cada uno de los "access points", en el 95 por ciento de los casos tú quieres que todos los "access points" se comporten de manera igual, estén propagando los mismos SSID's, estén dando el mismo tipo de servicio y, básicamente, estén ofreciendo acceso en las mismas bandas. Luego, configurar cada uno de manera individual ya no era visto como una ventaja, sino, posiblemente, como una desventaja, ya que ahora, si la red crecía, si tú tenías más de seis "access points", vamos a decir 10, 20 o 30, o más, cientos o miles, el estar configurando cada uno de ellos de manera individual, simplemente, no es escalable. En ambientes pequeños, esa implementación de "access points" autónomos, que nosotros también acostumbramos llamar "Fat AP's" o "'access points gordos", en el buen sentido, porque ellos, realmente, van a tener toda su configuración, como ya dije, en ambientes pequeños podría ser práctico. Nosotros conectamos una computadora en un puerto de red de ellos, accedemos a su interfaz gráfica y colocamos las configuraciones. En ambientes pequeños es viable. Tal vez en tu casa, tal vez en una pequeña oficina o en algún pequeño local comercial. Sin embargo, cuando nosotros tenemos ambientes grandes, como un campus, como una oficina remota con bastantes usuarios, probablemente, esta no es la mejor opción y eso es lo que nos lleva al siguiente modelo, que es el Thin AP o, básicamente, un "access point" delgado, y se llama "delgado" porque, realmente, él no tendrá su propia configuración. Él la descarga de manera dinámica de un punto centralizado, pero no es en el "access point" donde tú la defines; tú la vas a definir en algún otro lugar. Aquí tenemos una lista de características. Por ejemplo, cada "access point" va a tener una identidad única y va a ser parte de un grupo. Los "access points" delgados reciben su configuración desde una plataforma de gestión central, como ya mencioné, y pueden recibir tanto configuraciones individuales o específicas para ese "access point", como también configuraciones generales que vienen del grupo del cual es miembro. Además, hay bastantes tipos de plataforma de gestión que incluyen, pero no están limitadas, a controladores. En el caso de Aruba, nosotros tenemos los Mobility Controllers y estos tienen diferentes arquitecturas o diferentes formas de implementarse, dependiendo de la versión del código que estén corriendo. Por ejemplo, cuando nosotros tenemos Mobility Controllers usando una versión relativamente vieja, la versión ArubaOS 6, en ese caso, nosotros teníamos una arquitectura que llevábamos en Master/Local. Un controlador controlaba muchos otros controladores locales. El controlador de más alta jerarquía, nosotros lo llamábamos "Máster", los otros controladores los llamábamos "Locales". Y esto permitía una red bastante escalable y que podía soportar bastantes "access points", porque tú podrías no solamente tener un controlador controlando los "access points", sino podrías tener otro controlador controlando controladores en un nivel de jerarquía inferior. Esta era una arquitectura buena en su tiempo; la realidad es que ya ha sido reemplazada por otra, que nosotros la llamamos "ArubaOS 8", con Mobility Master. Este término, "Mobility Master", realmente ha cambiado. Ahora, a esta entidad o a este dispositivo, nosotros le llamamos "Mobility Conductor". Realmente, tenemos una arquitectura con Mobility Conductors y Mobility Controlers. ¿Y de qué se trata? Vas a tener un cerebro central, el Mobility Conductor, que es, realmente, un servidor o una máquina virtual que se va a encargar de gestionar otros controladores en un nivel de jerarquía inferior, y ellos, a su vez, se encargarán de controlar "access points". La idea podría ser similar a una implementación de Master/Local, sin embargo, la implementación con un Mobility Conductor es mucho más escalable, porque, realmente, no estamos utilizando un controlador para controlar otros controladores, sino estamos usando un servidor especializado con funciones especializadas para gestionar controladores que, a su vez, se encargan de los "access points". Esta arquitectura también introdujo muchas funcionalidades muy avanzadas que no se encontraban en versiones anteriores del código. Otra alternativa que nosotros tenemos es un Wireless Network Management/Monitoring System , que es, básicamente, un servidor que se pueda encargar de gestionar tanto los "access points" como, probablemente, los controladores que estén arriba. Aruba tiene un producto especializado que se llama "AirWave", el cual se encarga de todos estos dispositivos inalámbricos. La realidad de las cosas es que, aún cuando esta opción es viable y el servidor de gestión del Wireless Network Management/Monitoring System podría gestionar otros dispositivos que no sean necesariamente Aruba, o también otros dispositivos que no sean necesariamente "access points", como "switches", la realidad de las cosas es que no tiene todas las funcionalidades de un Mobility Conductor. Es por eso que, cuando nosotros tenemos una solución grande, una solución de cientos o miles de "access points", la arquitectura de Mobility Conductor con "access points" delgados es, realmente, la mejor, y como un agregado, nosotros podemos colocar este servidor de monitoreo. Después, tenemos la opción de Cluster Management con Virtual Controllers. En este caso, lo que nosotros vamos a tener es un grupo de "access points" que, en lugar de estar reportando a un Mobility Controller, el "access point" realmente va a tratar de descubrir otros AP's que se encuentren en el mismo dominio de "broadcast". Eso quiere decir que si nosotros tuviéramos un "switch" que esté conectando varios "access points", todos ellos podrían. Descubrirse a través de la red Ethernet y, finalmente, uno de ellos sería elegido el virtual controller, que es simplemente el rol que define que ese access point se encargará de la configuración de todos los otros AP en el grupo. En otras palabras, cuando tú conectas estos access points, el virtual controller va a ser elegido. Ahora, ese es el dispositivo que tú tendrías que acceder para definir los parámetros y las configuraciones que aplicarán en todos los access points. Si este AP falla, supongamos que este access point se cae, algún otro access point que siga vivo en el grupo tomará el nuevo rol del virtual controller, y él empezará a controlar cluster y la solución. La realidad de las cosas es que esto es una solución escalable, low cost y con una cantidad de features de nivel enterprise, que es bastante atractiva para los clientes de Aruba y muchos de ellos realmente lo utilizan en ambientes corporativos, que no sean tan exageradamente grandes, por ejemplo, lo utilizan en campos pequeños o en oficinas de branch. Es bastante atractivo. La realidad de las cosas es que una de las características importantes de esta solución es que, opuesto a la arquitectura del mobility conductor, en virtual controllers, nosotros no requerimos licencias. Eso quiere decir que esto es license free. Usted solamente tiene que invertir en los access points. Después, tenemos una solución similar, sin embargo, con una gestión centralizada, con Aruba Central. Lo que ocurre en este caso es que los access points, cuando se conectan a una red, pueden generar un cluster, como lo acabo de explicar, y además de que tú puedas acceder al virtual controller para poder monitorear y analizar cuál es el estado de la red inalámbrica como un todo, también habrá un cerebro centralizado en Internet, que es Aruba Central. Vamos a colocar otro color para la fuente. Aruba Central, entonces, todos estos access points realmente van a crear este cluster aquí. Después, cada uno de ellos, también de manera independiente, va a establecer una comunicación con Aruba Central. Y aún cuando nosotros tenemos un access point, que es el virtual controller, que podríamos utilizarlo para un monitoreo local, la realidad es que también podemos tener un monitoreo global desde Aruba Central, y este es el lugar donde tú vas a definir todas las configuraciones que quieres que se apliquen en la red. Realmente, la solución de Cloud Management con Aruba Central es una opción que se monta encima del virtual controller, al menos en la versión de código 8. En la versión de código 10, ya no tenemos un virtual controller. Los access points realmente hablan directamente con Aruba Central y todo se hace desde este punto central. Esto quiere decir, que ya no tienes un punto de monitoreo local, todo es global a través de esta solución en la nube. La realidad de las cosas es que es más eficiente y, además de simplemente enseñarte capacidades de configuración y monitoreo central, viene con muchas otras funciones, como presence analytics, como reportes, como estadísticas y bastante información que podría estar disponible para ti con tan solo unos clics, cosa que un virtual controller realmente no te puede ofrecer. Al final del día, los access points ligeros pueden ser implementados y gestionados de diferentes maneras, ya sea con un Wireless LAN Controller, con un Wireless Network Management System, con un Virtual Controller o, finalmente, con una solución en la nube, como puede ser con Aruba Central. En el caso del Wireless Controller, como yo ya te mencioné, esta es una opción donde nosotros necesitamos un a appliance, es el controlador. Si te estás preguntando, ¿qué es ese controller?, ese mobility controller que menciono tantas veces, es una caja, es un appliance. Es, básicamente, un dispositivo que solíamos llamar un switch inalámbrico. La razón por la que solíamos llamarle un switch inalámbrico es porque, del mismo modo que nosotros tenemos switches en la red que reciben el tráfico de todos los usuarios, cuando tú instalas un mobility controller y colocas varios access points, ellos pueden generar túneles en tunnel mode y todo el tráfico que los usuarios estén enviando hacia los access points, vamos a pensar que aquí tenemos varias computadoras y los access points están propagando la red, el tráfico que estos usuarios estén enviando, la realidad de las cosas es que va a ser redirigido, va a ser enviado al access point y el access point va a redirigirlo al mobility controller. En este caso, el mobility controller recibe todo el tráfico de los clientes. Esa es la razón por la cual nosotros solíamos llamarle un switch inalámbrico, porque, igual que un switch Ethernet, él recibe todo el tráfico de cada uno de los clientes. Esto sería en el caso de una implementación de modo túnel. Si nosotros hacemos una implementación de modo bridge, en este caso, los access points van a recibir el tráfico de los clientes y lo pueden enviar directamente a su destino. Esto quiere decir que, en lugar de enviar ese tráfico a través de un túnel hasta el controlador, el tráfico de los clientes, los paquetes de los clientes van a ser reenviados a su destino de manera directa, sin centralizarlo en el controlador. Tú te estarás preguntando, esto parece ser más eficiente, ¿cuál sería la ventaja de enviarlo al controlador? Porque el controlador podría ser posiblemente un cuello de botella o un punto único de falla. La realidad es que no es ninguno de los dos. El controlador puedes volverlo redundante colocando varios controladores en un mismo cluster. También, puedes incrementar así su capacidad de reenvío de paquetes, a través del mismo cluster, lo cual elimina estos dos posibles problemas. Sin embargo, la pregunta continúa, ¿cuál es la ventaja? La ventaja es que el mobility controller, como nosotros vamos a ver más adelante, es realmente una caja de múltiples servicios. Contiene bastantes servicios dentro de él, es un switch, es un wireless controller, es un enrutador, es una caja de análisis de tráfico; puede también hacer análisis de espectro. Y, finalmente, también puede, entre tantas cosas, ser un firewall. Es realmente un firewall de capa de exceso. El mobility controller es capaz de analizar el tráfico en capa de aplicación y poder identificar cuál es realmente el servicio o la aplicación que está generando ese tráfico y, en base eso, generar o tomar decisiones. Además del Deep Packet Inspection, él también puede, por ejemplo, distinguir las páginas web que el cliente quiere acceder, dependiendo de su reputación o su clasificación. Tú puedes decidir si quieres permitir el tráfico o no. Realmente, es un firewall de capa de exceso bastante avanzado. Es stateful, bidireccional, consciente de la aplicación y, realmente, es una opción que puede levantar drásticamente el nivel de seguridad de tu empresa. Esa es una de las ventajas y, obviamente, la mayor o la que más justifica el hecho de que queramos enviar el tráfico hasta ahí. Aquí, algunos puntos importantes con ArubaOS 6, la gestión es realizada por un mobility controller, pero con ArubaOS 8 tenemos una plataforma de gestión dedicada, que nosotros solíamos llamar mobility master, pero ahora le llamamos mobility conductor, el cual puede ser una caja física, un servidor o puede ser una máquina virtual. Ahora, yo estoy hablando un poco de entunelar el tráfico, de recibir el tráfico de los clientes y enviarlo al controlador. ¿Cómo funciona esto? Primero, debemos entender que cuando nosotros tenemos una red inalámbrica que tiene seguridad, vamos a hablar de algunos ejemplos, W-P-A-2 o W-P-A-3. Lo que ocurre es que, la red inalámbrica en sí está cifrada, va a haber una llave de cifrado, que se va a generar durante el proceso de autenticación, ya sea que nosotros tengamos 802.1 X, como ya mencioné anteriormente, o que solamente tengamos "brochure key", en cualquiera de esos dos casos, una llave que se llama "perwaist master key", lo voy a poner acá, P-M-K, sería la que se genera y a través de ella se crean otras llaves para poder cifrar el tráfico de los clientes. Entonces, cuando ese usuario, cuando esta computadora, está generando tráfico paquetes a través del aire, estos datos van a ser cifrados y después, encapsulados en el encabezado 802.11, van a ser enviados a través del aire y el "acces point" en modo túnel, realmente no va a descifrarlos, el simplemente, los va encapsular sobre un túnel G-R-E, sobre Ethernet y enviarlo directamente al controlador. Aquí, en este caso, cuando los paquetes llegan al controlador, él los va a desencapsular, los va a descifrar y analizar por el "firewall". Este "firewall", como yo ya mencioné, va realmente a revisar si el paquete está permitido dependiendo de políticas que tú defines y si ese es el caso, entonces realmente los envía a su destino. El siguiente modo "forwarding" que nosotros tenemos disponible, es "bridge". En el caso de "bridge mode", lo que sucede es que, el cliente va a generar el tráfico, él va a obviamente, cifrarlo en el aire, si es que tenemos W-P-A-2 o W-P-A-3, y enviarlo con los encabezados de 802. 11. Esos van a ser recibidos por el "acces point" pero puesto al caso anterior, donde realmente era el controlador quien descifraba el tráfico, ahora será el "access point" mismo. Eso quiere decir que la llave de cifrado que se generó, entre el "Mobility controller" y el cliente, ahora va a ser compartida con el "Access Point", él va a ser capaz realmente de hacer este descifrado, tenemos la llave descifrado, y obviamente, cuando el tráfico o los paquetes lleguen, él los va a revisar y recapsular para enviarlos a través de la red Ethernet. Eso significa que el tráfico no se va a centralizar en el "mobility controller", simplemente va a ser reenviado de manera directa, como mencioné anteriormente, y entonces, en este caso, el "mobility controller", el "wireless controler" va única y exclusivamente, gestionar el "access point", este no centralizaría el tráfico. La siguiente solución de arquitectura que nosotros tenemos disponible es el "virtual controller", este ya lo mencioné, es básicamente, varios "access point", se van a conectar en un mismo transporte capa 2, uno de ellos va a ser elegido como el "virtual controller". Este no solamente va a ser aquel que ofrece un punto central de monitoreo de la red, pero también es aquel donde tú vas a configurar los parámetros que aplican de manera global para todos los "access point", por ejemplo, las redes inalámbricas, los radios, las velocidades de transmisión, cuáles son, por ejemplo, inclusive políticas de "firewall", porque en una solución de "virtual controller", cada "access point" también tiene un módulo de "firewall" integrado. Entonces, las mismas políticas de "firewall" que nosotros podríamos tener un "mobility controller" las tenemos en un "access point instant" que genera un clúster con un "virtual controller". Obviamente, las capacidades no son las mismas, no es el mismo "Firewall through put" que tenemos con un controlador, el que tenemos con un "Access Point", sin embargo, es una muy buena opción, es una opción, una alternativa muy buena. Ahora, en este caso, el "Virtual Controller" solamente se encarga de la gestión de todo el clúster, él de ninguna manera va a centralizar el tráfico de los usuarios, lo que significa que cuando este cliente, que nosotros vemos aquí, esté decidido a enviar tráfico, el tráfico se va a mover de manera local por el "access point" que lo recibe. En otras palabras, no hay ningún tipo de túnel. Importante mencionar algo que ya había yo hablado hace unos momentos, es que una vez que este "virtual controller" se elige, todos los "access point" van a recibir la configuración de ese dispositivo. Y en caso de falla de este "virtual controller", algún otro "access point" va automáticamente a tomar el rol. Si aquí nos tenemos este "access point" y que trabaja con "virtual controller" y se cae, algún otro se volvería el nuevo "V-C". Entonces, esa arquitectura, bastante robusta, que podrías implementar, inclusive en una red de campos, pero, obviamente, va a tener una limitante. Aruba nos recomienda tener más de 128 "access point" dentro del mismo clúster, lo que significa que si tú tienes una implementación con varios cientos o miles de Apps, requeriría tener diferentes clúster, lo cual, obviamente, comienza a no ser tan atractivo. Y tal vez la mejor idea sería tener una solución con un "mobility conductor" y con "mobility controllers". Finalmente, la alternativa a ese "mobility conductor" y "controllers", cuando nosotros queremos una red de alta escalabilidad, es tenerlos gestionados desde un punto central, que es Aruba central. Esto ya lo mencioné también hace unos momentos. Nosotros podríamos tener en una red bastante grande, varios clúster, Aquí tenemos un clúster, aquí tenemos otro y aquí tenemos otro. Y, en lugar de estarlos gestionando de manera local, cada uno de ellos, lo que podemos hacer es permitirles que se conecten a esta plataforma en la nube a través de H-T-T-P-S, y, si nosotros tenemos las suscripciones y la cuenta preparada para recibirlos, entonces, ahora lo único que tú tienes que hacer es acceder a esta misma plataforma en la nube. Y tú puedes realmente controlar todos estos clústers, no solamente cada "Access Point", sino todos los clústers como un todo y, tener una visibilidad más amplia de lo que está ocurriendo en toda la red o en cada uno de los sitios o en alguna parte dentro de ese sitio. Es una solución bastante fuerte, obviamente, es lo que Aruba está empujando porque tiene bastantes beneficios. Realmente no tenemos que invertir en un controlador. Obviamente, sí hay costos de licencias, que son suscripciones, pero los beneficios son funcionalidades adicionales, que no tenemos con un controlador como "process analytics", y también puedes generar reportes, recibir alertas e, inclusive, puedes interactuar con esta plataforma en la nube utilizando "Rests IPAs". Eso quiere decir que podrías realmente contactar a central y obtener las estadísticas desde ahí, a través de un "script" de Python, por ejemplo, para después utilizarlas en cualquier otra solución o software que tú tuvieras en tu compañía. Esas son realmente las opciones que nosotros tenemos disponibles. Cada una de ellas tiene un caso de uso diferente y, obviamente, se cubren cualquier tipo de ambiente, necesidad o circunstancia. Aquí tenemos una lista final de todo lo que hemos cubierto. Hablamos de los "access point" autónomos, de los "access point" delgados, de los controladores con modo "forwarding tunnel", y "bridge", los "virtual controllers" y, obviamente, la solución en la nube. Espero que hayas encontrado este video informativo. Te veo en el siguiente donde hablaré de seguridad y control de acceso. Gracias por su tiempo.
