el 07-27-2015 10:49 AM
Con el experto de Cisco: Jeal Jiménez
Haga sus preguntas y aclare sus dudas a cerca de como implementar, configurar, y hacer troubleshooting/análisis en una Cisco WLAN, cubriendo las opciones y funcionalidades que se soportan hoy en día en los productos WLAN del portafolio de Cisco.
Jeal Jiménez es ingeniero de soporte High Touch especializado en tecnologías WLAN (LAN inalámbrica). Anteriormente colaboró como ingeniero de soporte donde se centró en la tecnología LAN inalámbrica (WLAN / WiFi) en el Centro de Asistencia Técnica TAC, antes de ser promovido como escalation lead y trainer, trabajando también como administrador del laboratorio de Cisco durante estos años. Tiene más de nueve años de experiencia en el área de las tecnologías de LAN inalámbrica, y ha contribuido con documentación interna y externa en Cisco. También contribuyó para el examen escrito CCIE Wireless y demás certificaciones Cisco wireless (CCNA y CCNP). Poseé una Ingeniería de Sistemas de la Universidad Latina en Heredia, Costa Rica. Jeal también cuenta con las certificaciones CCNA, CCNP R&S, CWNA, CWSP, VCP5-DCV y CCIE Wireless (# 31554).
Por favor use las estrellas para calificar las respuestas e indique si la respuesta que ha recibido es la correcta.
Puede ser que Jeal no pueda responder cada una de las preguntas debido la cantidad que anticipamos para este evento. Recuerde que usted puede preguntar o seguir haciendo preguntas en la comunidad de Wireless
Este evento estará disponible del lunes 27 de Julio al 12 de Agosto del 2015.
el 08-03-2015 07:34 AM
Buenos días Jeal,
¿Me podrías decir qué recomendaciones tienes para solucionar (troubleshoot) una WLAN cuando la autenticación está fallando?
¡Gracias!
Saludos,
Carlos
el 08-03-2015 08:23 AM
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**
el 08-03-2015 09:57 AM
Hola Carlos,
En WiFi/WLANs tenemos básicamente tres tipos de autenticación:
https://supportforums.cisco.com/document/12572951/eap-methods-summary
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:
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
el 08-03-2015 07:37 AM
Disculpa Jeal, tengo algunas dudas,
¿Me puedes explicar que es Fast-Secure Roaming? y también ¿Qué tiene que ver roaming con seguridad y cómo se logra esto?
Ojalá me puedas ayudar.
Dany
el 08-03-2015 08:44 AM
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
**Por favor si la información proporcionada fue útil, marca esta respuesta como correcta**
**Tu contribución nos hace continuar ayudando en el Foro**
el 08-03-2015 10:54 AM
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:
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:
- 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
el 08-04-2015 01:50 PM
Buenas tardes Jeal,
En la empresa en la que trabajo estamos trabajando en el deployment de una Guest LAN autenticando los usuarios contra un ISE server, con el método de auto-provisioning, donde el usuario se conecta y recibe un captive portal que viene del ISE, en el cual debe de llenar una información de nombre, empresa, email, etc… y el ISE server automáticamente le asigna un username y password.
En este momento tenemos esta solución trabajando para la mitad de USA y queremos implementarla en la otra mitad y además en Latinoamérica (que actualmente utiliza Web-Authentication regular). Sin embargo estaremos aplicando estos cambios en un nuevo DMZ y para definir los rules adecuados en el FW, necesitamos entender apropiadamente el flujo del tráfico desde el momento en que el usuario se conecta y envía el request de autenticación, hasta el momento en que es debidamente autenticado.
Como referencia:
El Anchor Controller se encuentra en un DMZ remoto y algunos de los Foreign WLC deben atravesar una o varias nubes MPLS para alcanzarlo.
El Pool de DHCP para los Guest está definido en el Anchor controller, con IP privadas pero NO ruteables dentro de la infraestructura de producción.
(User)----|AP|----|Foreign WLC|------.:MPLS:.------[FW]------|Anchor WLC|
|
|
|
[ISE]
De acuerdo con el research que he estado realizando, entiendo el proceso de la siguiente forma:
1 El cliente se conecta al SSID que percibe open.
2 El request viaja hasta el Anchor por medio del Capwap tunnel y el EoIP tunnel.
3 El cliente recibe una IP de DMZ (no routable) del Anchor WLC.
***********************************************************************************
4 El cliente envía el request al ISE el cual le envía el Captive Portal.
5 El cliente interactúa con el ISE hasta llenar los valores de auto-provisioning y recibir username y password.
6 Durante este proceso es el Foreign WLC el que habla con el ISE server.
***********************************************************************************
7 Una vez autenticado el tráfico de producción continua viajando por el EoIP tunnel hasta el Anchor, donde el tráfico se des-encapsula y sale a Internet por medio de la interfaz de DMZ del FW.
Ahora bien, las dudas que tengo son las siguientes:
A Con la descripción dada, estoy entendiendo bien el proceso? O estoy obviando/inventando algo?
B En el paso 4, si el cliente ya tiene IP, que lo detiene para salir a Internet directamente? Porque regresa a pedir autenticación al ISE? Se debe a los ACL definidos en el WLC?
C Es correcto que es el Foreign WLC el único que habla con el ISE? O el anchor tiene algún tipo de interacción?
D Si el Foreign es el que habla con el ISE, funciona este como Proxy del cliente? O entonces como haría el cliente para interactuar con el ISE si obtuvo una IP No ruteable?
E Es correcto que ningún request de autenticación viaja por el EoIP tunnel en este diseño?
Esta seria básicamente mi consulta, por favor ayudrme a comprender el flujo correcto del tráfico, ya que aunque muchos documentos de Cisco explican como configurar la solución y cuales puertos se deben de abrir en el FW, no he encontrado ninguno que diagrame el flujo del tráfico y los requests de autenticación.
De antemano agradezco su ayuda y el tiempo dedicado a este foro.
Atte: Jorge Carrasquillla Retana.
el 08-04-2015 04:04 PM
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
el 08-04-2015 04:46 PM
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:
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!!!!
el 08-04-2015 05:21 PM
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).
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
el 08-04-2015 05:57 PM
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!!!!
el 08-05-2015 07:59 AM
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
el 08-06-2015 02:25 PM
Buenas tardes,
Aprovechando de nuevo este espacio, quisiera hacer una consulta respecto a las nuevas tecnologías para el manejo de ambientes de alta densidad. En la empresa para la que trabajo los APs más comunes son los viejos LAP1240, y dependiendo de la cantidad de personas que se encuentren en las oficinas, las conexiones comienzan a caerse aleatoriamente. He encontrado documentación de Cisco donde se afirma que estos APs pueden recibir hasta 75 clientes, sin embargo en escenarios reales veo que después de 25 conexiones comienzan los problemas.
Haciendo un poco de research podemos ver que se ha trabajado en tecnologías que manejan Alta densidad, que por lo que puedo ver está relacionada con el aumento del ancho de los canales en la banda 5GHz, pasando de 20 a 40, 80, etc… sin embargo parece que no existe tal ventaja para la banda 2.4.
Basado en esta información tengo las siguientes consultas:
De antemano agradezco sus respuestas en este espacio.
Saludos!!!
el 08-06-2015 05:40 PM
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:
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
Descubra y salve sus notas favoritas. Vuelva a encontrar las respuestas de los expertos, guías paso a paso, temas recientes y mucho más.
¿Es nuevo por aquí? Empiece con estos tips. Cómo usar la comunidad Guía para nuevos miembros
Navegue y encuentre contenido personalizado de la comunidad