Buen día Carlos.

Mucho depende del método que utilices para autenticar a tus usuarios, lo más básico sería utilizar un método de autenticación abierta es decir sin seguridad, El siguiente paso sería utilizar WPA o WPA2.

Un punto importante es que debes de utilizar las siguientes combinaciones:

WPA- TKIP

WPA2 - AES

En caso de utilizar ambas métodos algunos clientes inalámbricos tienen problemas al tratar de manejar los dos tipos de encriptación en forma simultanea, por eso se pueden presentar problemas al momento de autenticas a los usuarios.

Otros casos más específicos es cuando utilizas algún método mas especifico, tal como autenticación con MAC, 802.1X, EAP, PEAP, LEAP.

En estos casos es necesario verificar desde, que la dirección MAC address este dada de alta en el WLC, los usuarios, Certificados, ETC

Mucho ayudaría si nos indicaras que tipo de problemas tienes y que tipo de autenticación ocupas. así podríamos ser más específicos. 

**Por favor si la información proporcionada fue útil, marca esta respuesta como correcta**

**Tu contribución nos hace continuar ayudando en el Foro**

Hola Carlos,

En WiFi/WLANs tenemos básicamente tres tipos de autenticación:

• 802.11 Open System Authentication: Esta es la autenticación más básica del estándar en WiFi, que siempre sucede y básicamente nunca falla a menos de que haya un problema de software en el AP o cliente, o problemas de RF (problemas de calidad de señal que no permiten establecer una conexión inalámbrica). Es el primer paso en el proceso de asociación de un cliente WiFi independientemente de si el SSID tiene seguridad mayor o se configura abierto. Es como “conectar el cable” y siempre lo inicia el cliente con un Authentication frame hacia el AP, seguido por una respuesta de Authentication frame del AP al cliente. Una vez que este proceso es exitoso (el cliente ha seleccionado el AP al que se quiere conectar), se establece el proceso de Asociación entre el AP y el cliente, donde el cliente envía un Association Request y el AP responde con un Association Response. A partir de este momento, el cliente puede empezar a pasar tráfico de datos, o realizar un proceso de autenticación más complejo que incluye alta seguridad.

• Autenticación de Capa 2 de seguridad alta: Luego del proceso de asociación explicado anteriormente, en WiFi podemos implementar un siguiente nivel de autenticación incluso antes de que el cliente obtenga dirección IP. Uno de ellos es MAC authentication donde se valida la dirección MAC del cliente antes de permitir la conexión (no muy utilizado ni seguro, ni parte del 802.11 estándar). Luego, tenemos la autenticación realizada por WPA/WPA2, donde existen dos tipos:
  • WPA/WPA2-PSK: Donde el cliente se autentica usando un Pre-Shared Key que se configura para el SSID en el AP y todos los clientes. (Para redes pequeñas y sencillas)
  • WPA/WPA2-EAP: Donde el cliente se autentica contra un servidor RADIUS utilizando un método más complejo y seguro de autenticación (conocido como un método 802.1X/EAP), y en el cual se pueden validar distintos tipos de credenciales (usuario/contraseña, certificados, Tokens, etc.). WPA/WPA2-EAP es la forma más segura de autenticación en WLANs, bastante utilizado y principalmente donde un método PSK simplemente no es suficiente para los requerimientos de seguridad de la red. El siguiente post es un resumen de los métodos EAP más utilizados en este tipo de autenticación WiFi:

https://supportforums.cisco.com/document/12572951/eap-methods-summary

• Autenticación de Capa 3: Este tipo de autenticación en WiFi es utilizado principalmente para control de acceso de invitados (guest WLAN) y no tanto por seguridad de la red, ya que el mayor nivel de seguridad y control se realiza en capa-2 utilizando WPA/WPA2-EAP como se mencionó anteriormente. Este tipo es el que se conoce como captive portal, Web-Authentication, Guest Access, etc., donde el cliente se conecta al WiFi en un SSID normalmente abierto en capa-2, luego obtiene IP, y antes de poder empezar a pasar tráfico de datos, necesita abrir un navegador donde es redireccionado a una página Web en la cual el usuario tiene que aceptar ciertos términos o incluso ingresar credenciales que le permitan autenticarse a la red.

Entendiendo esto, podemos enfocar su pregunta en el típico problema que afecta a la mayoría de WLANs y que causan el principal dolor de cabeza y complejidad tanto para entenderlo como para hacer troubleshooting: WPA/WPA2-EAP Authentication.

Para poder hacer troubleshooting de WPA/WPA2-EAP, es importante entender cómo funciona, por lo que recomiendo el siguiente post donde explico los componentes de EAP, el proceso de autenticación, detalles relevantes, y los pasos para un adecuado troubleshooting:

https://supportforums.cisco.com/document/12572956/8021xeap-troubleshooting

Evito entrar en detalles aquí para no repetir el documento ni extender mucho esta respuesta (el post es bien detallado al respecto), pero básicamente se puede enfocar el análisis en los siguientes pasos:

• Primero identificar claramente cada uno de los componentes (Supplicant, Authenticator, y Authentication Server).
• Luego confirmar cual es el método EAP que se implementó o desea implementar.
• Luego verificar que todos los componentes se hayan configurado apropiadamente para el método de autenticación.
• Si la autenticación sigue fallando, debugs en el Authenticator (WLC/AP) pueden mostrar si el problema sucede entre el cliente y el WLC/AP, o entre el WLC/AP y el servidor RADIUS. La autenticación realmente se realiza entre el cliente y el servidor, mientras que el Authenticator es como un “proxy” entre ellos dos, pero estos debugs nos permiten confirmar si el cliente está respondiendo, y si la comunicación entre el WLC/AP y el servidor está funcionando.
• Luego, podemos revisar los logs en el servidor, que normalmente van a explicar la razón del porque la autenticación ha fallado, y así poder tomar las medidas necesarias.

Si tiene alguna pregunta con respecto a esto o luego de ver alguno de los documentos/posts, por favor siéntase libre en preguntar lo que desee y lo podemos tratar en más detalle en otra pregunta aparte específicamente para autenticación EAP.

Saludos,

Jeal

Hola Tocayo.

Mucho tiene que ver el método de autenticación con el tipo de roaming que se utilice el presente documento me ayudo a entenderle mejor. Adicional a lo que nos comente Jeal, este documento me parece muy bueno y te puedo ayudar a entender mejor por que métodos como CCKM nos ayuda con un roaming muchos mas rápido y transparente.

Saludos

http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/116493-technote-technology-00.html#anc10

**Por favor si la información proporcionada fue útil, marca esta respuesta como correcta**

**Tu contribución nos hace continuar ayudando en el Foro**

Hola Dany,

Como menciona Daniel Ordoñez, el siguiente documento que publiqué hace un tiempo en Cisco.com es bastante detallado y organizado para poder entender Fast-Secure Roaming de la mejor manera, así como para hacer troubleshooting de cualquiera de los métodos Fast-Secure Roaming disponibles en nuestras soluciones CUWN:

http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/116493-technote-technology-00.html

En resumen:

- Qué es Fast-Secure Roaming?

Es un método que permite hacer una transición entre APs (roaming) de forma más rápida y eficiente, CUANDO la configuración del SSID incluye seguridad alta (básicamente para cuando se ha implementado WPA/WPA2-EAP Authentication). El método “Fast-Secure Roaming” que deseamos implementar tiene que ser soportado por el cliente (Supplicant) y el WLC/AP (Authenticator).

Existen varios métodos disponibles para poder realizar esto, algunos son propietarios, otros recomendaciones o definidos por el 802.11 estándar, explicados en detalle en el documento mencionado anteriormente, pero brevemente, los siguientes son los más conocidos/utilizados y soportados por las soluciones Cisco:

• CCKM: Es bastante eficiente pero inventado por Cisco por lo que solo es soportado por WLCs/APs Cisco y clientes que sean Cisco compatible (CCX).
• WPA2 PMKID Caching: Es sugerido por el estándar 802.11 cuando WPA2 es implementado, pero soportado por muy pocos clientes, ya que es el más limitado de todos debido a que esa “reautenticación rápida” solo se puede dar con un AP al cual ya el cliente se ha autenticado, por lo que la primera vez que el cliente conecte con un AP, no se puede realizar Fast-Secure Roaming.
• Proactive Key Caching (PKC) u Opportunistic Key Caching (OKC): Es una variante al anterior para WPA2, pero más eficiente ya que solo requiere una autenticación completa al inicio, y luego el cliente puede hacer Fast-Secure Roaming hacia cualquiera de los APs que maneje esa infraestructura a la cual se autenticó originalmente. Es el más soportado y adoptado hasta el momento, pero que se está empezando a sustituir por el que define oficialmente el 802.11 estándar unos años más tarde y que menciono a continuación.
• 802.11r / FT / Fast BSS Transition: Es el método oficialmente ratificado por el estándar para WiFi, mucho más eficiente y que permite distintas variantes según las necesidades. Hoy en día varios clientes/supplicants están empezando a soportarlo, pero su adopción ha sido un poco lenta.

- Qué tiene que ver Roaming con seguridad y cómo se logra esto?

La transición entre APs (roaming) es algo que siempre sucede cuando los clientes WiFi se mueven entre las celdas de cobertura de dos o más APs (incluso auque no haya movimiento, pero si las celdas de cobertura entre dos o más APs cubren la misma zona, es posible que el cliente haga “roaming” entre ellos buscando el que provee la mejor conexión). Hacer roaming es una decisión especifica del cliente, quien considera que puede obtener una mejor conexión con un AP que escucha y es distinto al actual (decisión definida por algoritmos roaming a nivel de cliente, y que involucran no solo “esuchar mejor” otro AP, sino también fallar ciertos requerimientos con el AP actual, como por ejemplo calidad de señal, retransmisiones, utilización, etc.).

Que tiene que ver esto con seguridad? Bueno, que el cliente siempre va a hacer roaming cuando lo considere, independientemente de cual método de seguridad se está utilizando en la WLAN. Sin embargo, cuando se utiliza alta seguridad tipo WPA/WPA2-EAP Authentication, el cliente tiene que autenticarse por completo cada vez que se conecta a un nuevo AP (esto implica que el cliente tiene que pasar por todo el proceso de autenticación EAP contra el servidor RADIUS, intercambiando certificados y credenciales, comunicándose nuevamente con el servidor independientemente de la latencia que exista hacia este, etc.).

Este proceso de autenticación puede tardar hasta algunos segundos, pero no es un problema la primera vez que se realiza, ya que es el momento en que el cliente se conecta a la red, por lo que todavía no tiene servicios activos (como una llamada por ejemplo). Sin embargo, una vez conectado, el cliente puede tener varios servicios activos y que pueden verse afectados por otro proceso de autenticación completo cada vez que el cliente hace roaming hacia un nuevo AP (imagine una llamada en proceso que se interrumpe durante unos segundos mientras hace roaming, o una aplicación en vivo que no tolera dicha interrupción… Si, esto implica muchas quejas, problemas, tiquetes, etc.).

Es debido a este “comportamiento normal” de EAP que se inventan los métodos de “Fast-Secure Roaming”, los cuales permiten evitar más procesos de autenticación contra el servidor RADIUS una vez que el primero se ha realizado (básicamente haciendo un cache por cada cliente, y que se da entre el Supplicant y el Authenticator, por lo que estos son los que deben soportarlo –el mismo método- y donde se debe configurar). Estos métodos permiten “acelerar” la reautenticación cada vez que el cliente hace roaming en una red WLAN segura con EAP, y de ahí su relación con seguridad.

Entendiendo esto, podemos concluir que “Fast-Secure Roaming” no se utiliza en una red que no tiene seguridad, ya que no hay nada que acelerar (no vamos a evitar todo el proceso de autenticación EAP completo contra el servidor, ya que no existe tal proceso, pero cuando existe, estos métodos “Fast-Secure Roaming” nos ayudan para evitar esas interrupciones).

Espero que esto ayude! Los temas son complejos y por lo tanto las respuestas un poco largas, sin embargo trato de resumirlas lo más que puedo, pero por favor pregunte lo que quiera si tuviera más dudas al respecto.

Saludos,

Jeal

Hola Jorge,

Me trae buenos recuerdos hablar del flujo de tráfico en CUWN con usted :), me alegra que esté tratando de entender bien estos detalles para hacer un buen diseño, que claramente está en buenas manos!

Una pizarra sería genial como en los viejos tiempos, ya que esto no es sencillo de cubrir, pero vamos a ver si nos entendemos:

*** Primero que todo, hay momentos en que el WLC (Foreign o Anchor) contacta al ISE dependiendo del setup, pero hay momentos en que es el cliente el que contacta al ISE, y para sus dudas, lo que nos interesa es cubrir el flujo del tráfico del cliente.

- El cliente primeramente se asocia a nivel de capa-2 (wireless 802.11 Association), lo cual básicamente sucede con el Foreign WLC (ya que este es el que maneja los APs).

- Una vez asociado en capa-2, el cliente es exportado por el Foreign WLC hacia el Anchor WLC en el DMZ, en donde finalmente el cliente es ubicado en una VLAN/subnet directamente conectada en el Anchor WLC (donde la VLAN también es configurada para asignarla al SSID), y en donde finalmente puede empezar a pasar tráfico de datos (y por lo tanto pedir IP e iniciar conexión en capa-3, de hecho, los primeros paquetes que este cliente va a enviar van a ser para ARP si tiene IP o DHCP, que realmente “tocan” la red hasta este punto, en la VLAN que les asignó el Anchor WLC).

- Hasta el momento, llevamos que el tráfico desde el cliente fluye de la siguiente manera:

Paquete sale desde el cliente por Radio-Frecuencia hasta el AP, el cual lo encapsula con CAPWAP para enviarlo dentro del CAPWAP tunnel por la LAN hasta el Foreign WLC, el cual remueve el CAPWAP encapsulation para ahora meter el paquete original del cliente en un EoIP tunnel hacia el Anchor WLC, el cual finalmente remueve el encabezado de EoIP para finalmente poner el paquete del cliente en la VLAN a la cual fue asignado (donde obtiene IP).

- A partir de este momento, y ya el cliente teniendo IP, que lo detiene para salir a Internet directamente? Primero recuerda, el cliente todavía no está en RUN state, sino en “CENTRAL_WEBAUTH_REQD” state. El SSID está configurado para hacer ese tipo de “Layer-3 Authentication” / Redirection con el ISE (cuando se hace CWA con el ISE, realmente no se define “Layer 3” authentication como en un Web-Authentication setup normal, sino que se utiliza MAC filtering para devolverle atributos al Foreign WLC y así aplicar un redirect ACL –esta es la parte donde el Foreign se comunica con el ISE, y si, solamente el Foreign, pero esta información es compartida con el Anchor-), por lo que, una vez que el cliente obtiene IP y mientras esté en “CENTRAL_WEBAUTH_REQD” state, se le bloquea todo tipo de tráfico a excepción del permitido en el “redirect ACL”.

- Cuál es el objetivo del redirect ACL? Permitir solamente DNS (para que el cliente pueda resolver la IP del sitio Web que quiere accesar con su navegador y que va a iniciar el redireccionamiento) y acceso al guest portal del ISE (es decir, tenemos que permitir tráfico hacia el ISE, preferiblemente solo en el puerto 8443 que es el del guest portal). El resto de tráfico es bloqueado (ICMP, ftp, etc.), y si fuera Web browsing (HTTP/HTTPS), entonces el Anchor WLC redirige el cliente hacia el URL del ISE guest portal (básicamente, el WLC intercepta el HTTP Get hacia el sitio que el cliente intentaba navegar, y le responde con el URL del ISE guest portal forzando el redireccionamiento).

- Cuando se da este redireccionamiento, el cliente realmente inicia una nueva sesión TCP con el ISE guest portal y envía un nuevo HTTP Get hacia el ISE en el puerto 8443. Es por esto que realmente es el cliente el que se comunica directamente con el ISE (no el WLC haciendo algún tipo de “proxy”), por lo que tienes que permitir este flujo en el FW del DMZ (solo necesita permitir comunicación desde la VLAN del cliente hacia el ISE en puerto TCP 8443).

- El cliente se comunica con el ISE para recibir la página del guest-portal, ingresar la información o enviar los credenciales, etc. (dependiendo de su configuración para esta conexión guest, aceptar terminos, autenticar, etc.), y una vez que el cliente es validado por el ISE, el ISE envía el RADIUS CoA (Change of Authorization) al WLC para confirmarle que el cliente ya es válido, y así finalmente moverlo al “RUN” state permitiendo todo tipo de tráfico y sin aplicar más ningún redireccionamiento.

- A partir de aquí, ya el cliente está totalmente conectado en la VLAN que se le asignó, y como mencioné, puede pasar todo tipo de tráfico, a menos que se aplique otro ACL normal (no "redirect ACL") para el control del tráfico guest, ya sea configurado en el WLC (estáticamente asignado al SSID o la VLAN, o dinámicamente asignado como atributo enviado desde el ISE) o incluso configurado en el GW de esa VLAN (“wired side”).

Por favor confirme si esto le aclara sus dudas o pregunte lo que sea necesario para asegurarnos que le queda claro cómo implementar ese nuevo diseño.

Saludos Jorge!

Jeal

Jeal,

Muchas gracias, no solo por la inmediata respuesta, si no por la calidad de la misma, no esperaba menos de usted. Como dices, una pizarra sería ideal al estilo de la vieja escuela…

La respuesta fue bastante clara, básicamente me quedan un par de dudas muy puntuales referentes al momento en el que Cliente se comunica con el ISE, voy a tratar de explicarme: Si imaginamos un diagrama donde el inside de la red es el punto 1 y el DMZ es el punto 2, comprendo que tenemos un EoIP tunnel desde el Foreign WLC en punto 1 con el Anchor WLC en punto 2, hasta ahí entiendo que el cliente intercambie tráfico desde el punto 1 al 2 a través del túnel.

Sin embargo me nacen estas dudas:

1. En el momento que se intercambia información Cliente-ISE, esto se hace todo en el punto 1 (comunicación directa en la red de producción), o toda la Info enviada por el cliente se va por el túnel y luego de ser des-encapsulada, vuelve a atravesar el FW desde el punto 2 hacia el inside para poder hablar con el ISE?
2. Lo segundo seria, como se logra pues el Cliente comunicar con el ISE, si la subnet de la cual el cliente recibe IP, solo existe en el DMZ y no es ruteable dentro de la red de produccion?

Como te comentaba, en una parte de nuestra red ya la solución de ISE está funcionando, y lo hace con IPs de una subnet única de DMZ. Podrías por favor aclarar estos dos puntos?

De antemano muchas gracias por la respuesta y por abrir este foro, creo que mucho tenemos dudas de Wireless difíciles de aclarar haciendo research ya que la documentación muchas veces no es clara y otras incluso contradictoria.

Saludos!!!!

Jorge,

En efecto, el cliente se comunica directamente con el ISE en el guest portal port, por lo tanto:

1.    En el momento que se intercambia información Cliente-ISE, esto se hace todo en el punto 1 (comunicación directa en la red de producción), o toda la Info enviada por el cliente se va por el túnel y luego de ser des-encapsulada, vuelve a atravesar el FW desde el punto 2 hacia el inside para poder hablar con el ISE?

El tráfico es enviado del Foreign al Anchor por el EoIP tunnel, y este lo pone en la VLAN del cliente (punto 2), por lo que ya (sin ningún encapsulamiento) pasa desde el punto-2 a través del FW hacia el inside (punto-1) para poder hablar con el ISE.

2.    Lo segundo seria, como se logra pues el Cliente comunicar con el ISE, si la subnet de la cual el cliente recibe IP, solo existe en el DMZ y no es ruteable dentro de la red de producción?

Si es cierto, la subnet del cliente está en el DMZ, pero normalmente la infraestructura sabe cómo enrutar entre INSIDE y el DMZ, y lo que realmente se hace es que se bloquea la comunicación entre INSIDE-DMZ pero por security levels, no por routing (de hecho, en este momento usted esta enrutando desde la subnet del Foreign en el INSIDE al Anchor en el DMZ, y viceversa). Puede que el cliente esté en una subnet en el DMZ distinta a la subnet del Anchor WLC, pero así como se encargó de enrutar entre INSIDE-DMZ para la comunicación entre los WLCs, también necesita enrutar entre la subnet del cliente y el ISE para que esta autenticación con el guest-portal se pueda dar (y por lo tanto, permitir comunicación de la VLAN del cliente en el DMZ hacia el ISE en el puerto del guest-portal).

3. Como te comentaba, en una parte de nuestra red ya la solución de ISE está funcionando, y lo hace con IPs de una subnet única de DMZ. Podrías por favor aclarar estos dos puntos?

Esto tiene que estar funcionando como te lo explico en las otras preguntas arriba, pero si quieres confirmar, puedes tomar una captura de paquetes en el puerto del Anchor WLC en el DMZ (o en el GW del cliente en el DMZ) y la puedes adjuntar aquí para analizarla y explicarla (deberíamos de ver el tráfico del cliente haciendo esa sesión TCP/HTTPS con el guest portal del ISE).

Saludos!

Jeal

Excelente Jeal,

Muchísimas gracias por la explicación. Voy a tratar de conseguir el capture, sin embargo lo veo un poco difícil porque el Data Center donde se Ubica el WLC está en un sitio remoto sin personal habitual en sitio, sin embargo voy a tratar.

Excelente información, muchas gracias. Es posible que aproveche mañana para aportar otro tema al foro relacionado con High Density   =)   Por el momento ha sido de gran ayuda… Los felicito por este espacio.

Saludos!!!!

Perfecto Jorge!

Y gracias por el feedback; que bueno que se considere este espacio como beneficioso y necesario, y me alegra que usted le pueda sacar buen provecho al mismo.

Saludos!

Jeal

Hola Jorge,

Esta consulta es mucho más abierta, y para cubrir este tema y responder todas sus preguntas específicas, realmente hay mucho que discutir y entender con respecto a  Radio Frecuencia, radios y antenas, cómo funcionan las redes inalámbricas y el 802.11 estándar, y el comportamiento de los distintos dispositivos móviles que tenemos hoy en día (no es lo mismo un Smartphone que una laptop por ejemplo, y el desempeño de cada dispositivo trabajando en el mismo canal afecta el desempeño total/final de todos los dispositivos trabajando en ese canal).

Es por esto que mejor le comparto los siguientes documentos para su lectura y aprendizaje:

http://www.cisco.com/c/en/us/products/collateral/wireless/aironet-1250-series/design_guide_c07-693245.html

http://www.cisco.com/c/en/us/products/collateral/wireless/aironet-3700-series/white-paper-c11-731923.html

Básicamente, “High Density” o “Alta Densidad” no es simplemente tecnología(s) que manejan alta cantidad de clientes en un área determinada, sino realmente un concepto de implementación en redes inalámbricas que involucra un apropiado Diseño, tanto en RF como en la utilización de múltiples tecnologías que se pueden aprovechar para lidiar con alta densidad de clientes (algunas que dependen de otras tecnologías o de ciertas características en el cliente o el ambiente, mientras que algunas tecnologías no tienen tanta dependencia).

Muchas de las tecnologías que ayudan en estos diseños fueron implementadas con el estándar 802.11n, y otras con 802.11ac (donde las cosas cambian bastante, principalmente con la última versión conocida como Wave2), así como también hay varias tecnologías propietarias y que como puede ver en la documentación que le comparto, Cisco implementa en nuestros APs y WLCs para un mejor rendimiento.

Sin embargo, es importante recordar un aspecto fundamental de las redes inalámbricas: Se trabaja en un canal de radio frecuencia que es un medio compartido y donde por lo tanto, solamente un dispositivo puede hablar a la vez (solamente 11ac Wave2 ya permite varios clientes a la vez, pero esto depende de soporte en los clientes, y como todavía no tenemos clientes 11ac Wave2, no vamos a profundizar en este tema). Esto significa que incluso dispositivos que causen interferencia en ese canal (otras WiFi alrededor, o dispositivos como teléfonos inalámbricos, Hornos de Microondas, etc.), van a causar que los clientes intentando transmitir en nuestro AP/Canal tengan que esperar a que el “ambiente esté desocupado”, causando no solamente latencia sino también otro montón de problemas como las desconexiones que ustedes experimentan. Esto también significa que, aunque tenga un excelente AP con muchas tecnologías de alta densidad soportadas, todos los clientes van a tener que competir por su turno de transmisión, y  mientras más clientes hay, más larga es la espera, y si esos clientes son “lentos” (clientes viejos como 802.11b, o 802.11g transmitiendo a un data-rate bajo y/o con mala señal, muchas retransmisiones, colisiones, etc., debido a problemas de cobertura o interferencia, que normalmente están relacionados con un mal diseño de RF), entonces la competencia por el medio es aún más complicada y como mencioné anteriormente, afecta el rendimiento total/global de los dispositivos en ese canal.

Recordando esto y leyendo los documentos compartidos, podríamos responder sus preguntas de la siguiente manera:

1. Está hecha la tecnología de alta densidad solo para la banda 5GHz?

No, porque no es una tecnología específica, sino un concepto que involucra muchas cosas (incluyendo diseño), y de las cuales muchas se pueden aprovechar en la banda de 2.4GHz.

Si bien es cierto la banda de 2.4GHz es la más saturada y afectada por interferencia, tiene básicamente solo 3 canales (que no traslapan) disponibles mientras que 5GHz normalmente 12 canales o muchos más (según el Regulatory-Domain), no se soporta  802.11ac (que fue ratificado solo para 5GHz), ni soporta Channel-Bonding de 40MHz o más (que realmente es solo una tecnología de 802.11n y 802.11ac para incrementar throughput, y no realmente lo único o tecnología para Alta Densidad como lo interpretabas), a pesar de todo esto, como vas a ver en la documentación, un buen diseño y varias tecnologías propietarias y de 802.11n ayudan para una Alta Densidad en 2.4GHz.

2. Basado en el entendido de que la densidad de clientes que el AP soporta está asociada con el tipo y cantidad de tráfico que esté pasando, cuanto seria en general el número de clientes que un AP soporta antes de tener problemas.

Realmente mejor no nos basamos en ese entendimiento :) Los APs, Cisco o incluso puede que hasta algunos SOHO, podrían “soportar” a nivel de arquitectura interna y como dispositivo de red, hasta “cientos” de clientes asociados y MAC addresses. Sin embargo, son muchos los factores (incluyendo tipo y cantidad de tráfico, pero también varios más) que terminan definiendo el numero recomendado por radio(banda/canal). El primer documento explica esto de una manera muy detallada.

3. Cuál es la diferencia en lo que se refiere a densidad de usuarios, entre los modelos de AP 2700 y 3700?

La respuesta es similar a la anterior… Ambos son excelentes APs y pueden manejar una gran cantidad de clientes que depende de varios factores, sin embargo, el 3700 es definitivamente nuestro “Rock Star” actualmente, y con la principal ventaja sobre el 2700 de que se le puede adaptar un módulo/radio extra que al final de cuentas puede recibir más clientes y/o ayudar en otros aspectos de “Alta Densidad”.

4. Cuanto seria el máximo de clientes que pueden trabajar adecuadamente en la banda 5GHz en los AP 2700 y 3700 respectivamente.

Misma respuesta, no podemos definir un número exacto porque hasta las tecnologías soportadas por los clientes que conecte a esos APs van a determinar este valor.

5. Existe la forma de trabajar en alta densidad en la banda 2.4?

Si, ver respuesta 1.

Espero que esto aclare algunas dudas específicas y que pueda servir por lo menos como una guía inicial para ese complejo aprendizaje de diseños de WLAN con alta densidad. Saludos!

- Jeal