Check Ping Cmd: Resolución esencial de problemas de red

Un invitado puede navegar en un sitio pero no en otro. El personal dice que el WiFi va "lento" cerca de la recepción. Una terminal PMS de hotel se desconecta de la red cada pocos minutos, pero el panel de control del controlador parece estar bien. En ese momento, no empiezas con la teoría. Abres una consola y ejecutas ping.

Por eso el comando check ping cmd sigue siendo importante. Es rápido, local y brutalmente honesto. No te lo dirá todo, pero te dirá dónde dejar de adivinar.

La mayoría de las guías básicas se limitan a "escribe ping google.com". Eso es útil, pero pasa por alto las complejidades más profundas de las redes WiFi empresariales modernas. En los sectores de hostelería, comercio minorista, sanidad y centros multiinquilino, los problemas de conectividad suelen residir en la autenticación, el roaming, la accesibilidad del controlador, la discordancia de MTU o los flujos de trabajo de identidad. Un ping correcto a un host público no demuestra que el proceso del invitado sea correcto. Un ping fallido tampoco demuestra siempre que la red esté caída.

Utilizado correctamente, ping es menos un comando único y más un hábito de diagnóstico. Primero se prueba cerca del dispositivo. Luego te desplazas hacia fuera. Comparas objetivos. Varías el tamaño de los paquetes. Observas la pérdida y el jitter a lo largo del tiempo. Y cuando ping deja de ser suficiente, pasas a tracert, pathping, registros y captura de paquetes con una hipótesis clara en lugar de buscar a ciegas.

Por qué el ping sigue siendo tu primer recurso ante problemas de red

Un invitado dice que el WiFi no funciona, pero el fallo subyacente puede residir en el DNS, la redirección del Captive Portal , la accesibilidad ascendente o la ruta de autenticación detrás del SSID. Ping sigue siendo el primer comando a ejecutar porque separa esas posibilidades rápidamente y te ofrece un límite de fallos antes de abrir paneles, registros del controlador o capturas de paquetes.

Empieza por la verdad más cercana

Una buena resolución de problemas empieza cerca del dispositivo.

Unos cuantos echo requests a la pila local, a la puerta de enlace predeterminada y a un objetivo ascendente conocido pueden decirte si te enfrentas a un problema del cliente, a un problema local de RF o subred, o a algo más alejado en la ruta. En un entorno gestionado por Purple, esto es importante porque la queja suele llegar como "el WiFi va lento" incluso cuando el enlace de radio es correcto y el retraso real se encuentra en la incorporación, la aplicación de políticas o la salida a internet.

El comando ping también obliga a la disciplina. Si la puerta de enlace es estable y el objetivo público no lo es, pasar los primeros veinte minutos en la configuración del punto de acceso suele ser un esfuerzo inútil. Si la propia puerta de enlace pierde respuestas o muestra una latencia errática, no hay razón para empezar con suposiciones del lado de la nube.

Por qué las guías básicas se quedan cortas

Muchos manuales para principiantes tratan el ping como una prueba de sí o no. Las redes reales no son tan sencillas.

Enterprise WiFi, especialmente el acceso de invitados y personal basado en la identidad, añade dependencias que los manuales de resolución de problemas más antiguos apenas mencionan. Un dispositivo puede asociarse al SSID, obtener una dirección IP y, aun así, tener una experiencia de usuario deficiente porque la gestión del Captive Portal es lenta, una transacción RADIUS se retrasa o una decisión de política estanca la primera conexión utilizable. Como se ha señalado anteriormente, algunas guías públicas sobre cómo comprobar el ping con CMD apuntan a que las pruebas sencillas de host pasan por alto esos retrasos en el inicio de la sesión en los flujos de trabajo de acceso modernos.

Por eso no trato un ping exitoso a un sitio público como prueba de que el servicio funciona correctamente. Solo demuestra que ICMP funcionó entre dos puntos en ese momento. En un despliegue de Purple, la experiencia del usuario todavía puede estar rota por encima de esa capa.

Regla práctica: ping valida la accesibilidad y el tiempo para una ruta específica. No valida la lógica del Captive Portal, la salud de la aplicación o los flujos de trabajo de identidad de extremo a extremo.

El ping ayuda a desarrollar un mejor criterio de red

Los ingenieros experimentados siguen utilizando ping por otra razón. Crea el hábito de probar un límite a la vez.

Empiece por lo local. Pruebe la puerta de enlace. Pruebe un objetivo interno controlado si dispone de uno. A continuación, pruebe un destino externo. Compare la latencia, la pérdida y la coherencia en lugar de limitarse a observar una única respuesta y darla por buena. En entornos WiFi saturados, este enfoque suele revelar si el problema sigue al cliente, a la VLAN, al enlace ascendente del sitio o a una dependencia del servicio fuera de la red inalámbrica.

Si está desarrollando ese instinto, los fundamentos sólidos de enrutamiento y conmutación siguen importando. Recursos como este Examen de práctica de CCNA ayudan a reforzar la lógica de resolución de problemas que hay detrás de lo que parece un comando sencillo.

Ping no resuelve todos los problemas. Le ofrece una primera lectura limpia y, en las operaciones de red, eso suele ser lo que más tiempo ahorra.

Dominando el comando Ping en CMD y PowerShell

La sintaxis básica es sencilla:

• Prueba básica de host: ping hostname
• Prueba básica de IP: ping target-ip

Tanto en el Símbolo del sistema como en PowerShell, ping funciona de forma similar en Windows. El valor reside en elegir los parámetros adecuados para el problema que intenta aislar.

Los parámetros que realmente importan

Estas son las opciones a las que recurro con más frecuencia cuando realizo un flujo de trabajo adecuado para comprobar el ping con CMD en Windows.

Parámetro	Qué hace	Cuándo usarlo
-t	Se ejecuta de forma continua hasta que se detiene	Caídas intermitentes, problemas de itinerancia, WAN inestable
-n	Envía un número determinado de solicitudes de eco	Prueba rápida y repetible para notas de incidencias
-l	Establece el tamaño del paquete	Pruebas de MTU y fragmentación
-w	Establece el tiempo de espera en milisegundos	Comprobaciones de alta latencia o de sitios remotos

Ejemplos útiles en CMD

Algunos patrones prácticos:

• Prueba rápida de accesibilidad: ping host-destino
• Supervisión continua: ping -t host-destino
• Prueba de muestra corta: ping -n recuento-destino host-destino
• Prueba de paquetes más grandes: ping -l tamaño-destino host-destino
• Espera más larga antes del tiempo de espera: ping -w tiempo-espera-destino host-destino

Use Ctrl+C para detener un ping continuo y mostrar las estadísticas de resumen.

Los mismos hábitos en PowerShell

En Windows PowerShell, puede seguir ejecutando el comando ping estándar directamente. Para muchos administradores, eso es suficiente. La ventaja de PowerShell es lo que se puede hacer a su alrededor.

Puede integrar ping en scripts, añadir marcas de tiempo a la salida, recorrer listas de destinos en bucle o registrar fallos durante una prueba de itinerancia. Esto resulta muy útil cuando un problema no aparece de forma inmediata.

Un ejemplo sencillo consiste en ejecutar un ping continuo en una ventana mientras se desplaza por un recinto con un dispositivo de prueba. Otro consiste en enviar un ping con un recuento fijo antes y después de un cambio de configuración para disponer de un registro limpio del antes y el después.

Cómo elegir el parámetro correcto

No utilice todas las opciones cada vez. Adapte la prueba al síntoma.

• El usuario dice que el problema es constante: empiece con un ping normal, luego con un recuento fijo -n.
• El usuario dice que ocurre "de vez en cuando": use -t.
• El inicio de sesión en el Captive Portal o la incorporación de dispositivos parece inconsistente: pruebe el tamaño del paquete con -l.
• Propiedad remota o red de transporte lenta: aumente el tiempo de espera con -w.

No confunda la comodidad con la evidencia. El éxito de cuatro paquetes solo le indica que esos cuatro paquetes llegaron a su destino.

Cuándo adquiere importancia el tamaño del paquete

Muchos administradores nunca tocan -l, y eso es un error. Los pings pequeños estándar pueden parecer limpios mientras que el tráfico real de mayor tamaño experimenta dificultades. En entornos WiFi empresariales, esto suele indicar un desajuste de MTU, fragmentación o traspasos problemáticos a través de túneles y capas de seguridad.

El movimiento práctico consiste en comparar un ping normal con una prueba de carga útil mayor. Si los paquetes pequeños funcionan bien y los más grandes se comportan mal, habrá descubierto algo importante sin necesidad de tocar un analizador de paquetes todavía.

Ahí es donde el comando ping deja de ser un mero trámite y empieza a actuar como un bisturí.

Cómo interpretar las estadísticas de ping como un profesional

Una respuesta de ping limpia aún puede coexistir con una mala experiencia de usuario. Esto ocurre constantemente en las redes WiFi empresariales. Un dispositivo llega a la puerta de enlace, pero el inicio de sesión en el Captive Portal se congela, la asignación de políticas se retrasa o el roaming interrumpe una sesión durante unos segundos. Leer correctamente el resultado de un ping significa tratarlo como una señal más dentro de una cadena más amplia.

Comience con el resumen y luego observe el patrón

El resumen de la parte inferior importa más que cualquier respuesta individual. Concéntrese en la pérdida de paquetes, el tiempo de ida y vuelta y la diferencia entre los tiempos de respuesta mínimo y máximo.

Si estoy probando un espacio gestionado por Purple, no valoro todos los destinos de la misma manera. Un ping de cliente a puerta de enlace suele ser estable y de baja latencia. Un ping a un endpoint público de SaaS tardará más de forma natural. Lo que importa es si el resultado se corresponde con la parte de la ruta que se está probando.

Un solo párrafo de resultados puede responder a tres preguntas útiles. ¿La ruta está perdiendo paquetes? ¿El retraso es constantemente alto? ¿El retraso fluctúa constantemente entre una respuesta y otra?

Evalúe el resultado en función del destino

Una puerta de enlace, un servidor DNS, un servidor RADIUS, un controlador y un sitio web público aportan información diferente.

La infraestructura local debería ser predecible. Las respuestas deben ser estables. Si no lo son, empiece a buscar cerca del extremo del cliente: calidad de radiofrecuencia (RF), comportamiento del controlador del cliente, carga del punto de acceso, asignación de VLAN, enlaces ascendentes del switch o políticas del firewall local. No se apresure a culpar a Microsoft 365, Google o a un proveedor de Captive Portal si el primer salto ya es inestable.

Los destinos remotos requieren más matices. Una mayor latencia es normal en enlaces WAN, puntos de salida a internet y capas de seguridad en la nube. Una gran variación es más preocupante que un promedio simplemente más alto, especialmente en redes WiFi basadas en identidad, donde los usuarios perciben el retraso durante el registro, las comprobaciones de certificados, las búsquedas de políticas y las redirecciones posteriores a la autenticación.

Como se ha señalado anteriormente en la descripción general de Kentik sobre el ping en la supervisión y resolución de problemas de red, la pérdida de paquetes y los tiempos de ida y vuelta inconsistentes son las primeras señales que merecen atención.

La variación suele explicar la queja

Los usuarios rara vez informan de una "latencia alta". Lo que notifican son inicios de sesión que no cargan, llamadas entrecortadas, páginas de bienvenida bloqueadas y aplicaciones que solo funcionan al segundo intento.

Esto suele ser un problema de variación.

Los promedios lo ocultan. Si las respuestas llegan a 8 ms, 9 ms, 11 ms y luego a 180 ms, el promedio puede seguir pareciendo aceptable a primera vista. El usuario seguirá sintiendo el pico. En WiFi, esto puede indicar retransmisiones, saturación del tiempo de uso del canal, comportamiento de ahorro de energía en el cliente, interrupción del roaming o cola de espera en la red ascendente.

Patrón	Significado probable	Siguiente paso
Promedio bajo, intervalo estrecho	Ruta en buen estado	Probar la siguiente dependencia de la cadena
Promedio bajo, intervalo amplio	Inestabilidad intermitente, colas de espera o problemas de RF	Ejecutar una prueba más larga y comparar destinos locales frente a remotos
Pérdida de paquetes presente	Congestión, problemas de RF, filtrado o pérdida ascendente	Probar primero la puerta de enlace, luego un host de internet conocido
Local correcto, remoto incorrecto	Problema en la WAN, ISP, ruta de la nube o servicio externo	Validar con herramientas basadas en rutas y comprobaciones de servicio

El TTL ayuda, pero solo un poco

El TTL es útil como pista. Puede sugerir que se está llegando a un host diferente al esperado, recorriendo una ruta distinta o comparando sistemas con valores predeterminados diferentes.

No es una prueba sólida por sí sola.

Demasiados administradores pierden tiempo explicando las diferencias de TTL mientras ignoran el resultado que más importa: una latencia local estable sin pérdidas, o una latencia local inestable con picos evidentes. El TTL respalda el diagnóstico, no lo determina.

En WiFi, un ping correcto no garantiza el funcionamiento de toda la ruta del servicio

Esto es importante en las redes modernas de acceso para invitados y empresas. En entornos Purple, un usuario puede tener una conectividad ICMP perfectamente correcta y, aun así, fallar en la renovación de DHCP, la resolución de DNS, la redirección al Captive Portal o la aplicación de la identidad. Por eso, un ping sólido a la puerta de enlace solo descarta una parte del problema.

Si el ICMP local parece correcto pero la sesión sigue fallando, revise los servicios adyacentes. La guía de Purple sobre los fundamentos de DHCP y DNS WiFi es una buena referencia porque muchos problemas que parecen fallos de RF comienzan en realidad con la asignación de direcciones o la resolución de nombres.

La pregunta profesional es sencilla: ¿qué ha descartado este resultado y qué le obliga a probar a continuación?

Ampliando su caja de herramientas con Tracert y Pathping

Un usuario se conecta al WiFi, supera la asociación, accede a internet de forma intermitente y asegura que el problema solo ocurre en una parte del edificio. Ping confirma el síntoma. Tracert y pathping ayudan a localizarlo.

En la práctica, utilizo estas herramientas una vez que sé que la conectividad básica no cuenta toda la historia. Responden a preguntas diferentes. Tracert muestra la ruta que parece tomar un paquete. Pathping dedica más tiempo a medir la pérdida y el retraso a lo largo de esa ruta. En un entorno gestionado por Purple, esa distinción importa porque una incidencia puede residir en la LAN del establecimiento, en la ruta WAN o en una dependencia de la nube vinculada a la autenticación, las políticas o el acceso de invitados.

Qué le ofrece tracert

Tracert es la forma rápida de preguntar dónde cambian las condiciones.

Si un cliente puede hacer ping a la puerta de enlace local sin problemas pero una plataforma SaaS va lenta, ejecute un trace al punto de conexión del servicio o a un destino público estable. Observe dónde empieza a aumentar la latencia y si la ruta difiere entre ubicaciones. Eso le proporciona información práctica. Un problema que aparece en el segundo salto le redirige hacia el extremo local, el cortafuegos o la entrega del ISP. Un problema que aparece mucho más tarde suele trasladar el foco hacia la ruta del proveedor o la red de destino.

La contrapartida es la precisión frente a la velocidad. Tracert es una instantánea, y algunos routers limitan la velocidad o ignoran las respuestas ICMP. Un salto intermedio lento o inexistente no demuestra que el reenvío esté fallando ahí. Lo que importa es el patrón en los saltos posteriores.

Por qué pathping se gana su sitio

Pathping es más lento, pero es mejor para incidencias de inestabilidad. Realiza el trazado primero y luego toma muestras de cada salto a lo largo del tiempo para estimar la pérdida de paquetes en la ruta.

Esto lo hace muy útil cuando los usuarios informan de que el WiFi va "casi siempre bien" pero las llamadas de voz se entrecortan, un paso del portal agota el tiempo de espera o las aplicaciones en la nube se congelan durante unos segundos y luego se recuperan. Una sola ejecución de ping puede pasar por alto este tipo de comportamiento. Pathping tiene más posibilidades de mostrar si la pérdida se está acumulando cerca del cliente, en el extremo WAN o más arriba.

También ayuda a evitar derivaciones erróneas. He visto a equipos culpar al ISP porque un servicio externo parece inestable, solo para descubrir que la pérdida empieza antes de que el tráfico llegue a salir de las instalaciones.

Cuándo se adapta cada herramienta

Utilice la herramienta que mejor responda a la pregunta.

• Utilice ping para confirmar la conectividad y obtener una línea base de latencia y pérdida.
• Utilice tracert para identificar dónde cambia la ruta o dónde empieza el retraso.
• Utilice pathping para medir si la pérdida es persistente y, de forma aproximada, dónde aparece.

Para obtener un contexto más amplio sobre cómo es un "buen" rendimiento más allá de un solo comando, la guía de Purple para medir el rendimiento de la red WiFi es una referencia útil.

Un patrón de escalado práctico

Una secuencia simple funciona bien:

• Comience con ping a una puerta de enlace local y a un objetivo ascendente.
• Ejecute tracert si los resultados locales son limpios pero la experiencia remota es deficiente.
• Ejecute pathping si la ruta parece normal pero los usuarios siguen informando de interrupciones intermitentes.
• Pruebe el tamaño del paquete por separado si sospecha de MTU o fragmentación. Tracert y pathping no resolverán esa duda por sí solos.

La precaución principal es la misma en cualquier red empresarial. La visibilidad de ICMP es incompleta por diseño. Algunos saltos permanecerán en silencio, algunos responderán lentamente y algunas rutas en la nube parecerán más extrañas de lo que realmente son. Utilice estas herramientas como indicadores, no como veredictos. En entornos WiFi complejos, especialmente aquellos con capas de identidad, políticas y flujos de trabajo de invitados, ayudan a reducir el dominio del fallo para que la siguiente prueba sea más inteligente que la anterior.

Diagnóstico de problemas de WiFi complejos con Ping

Un usuario camina por el vestíbulo, su teléfono muestra cobertura WiFi completa y, aun así, la sesión se interrumpe a la mitad de un inicio de sesión de invitado o de un roaming seguro. Ese es el tipo de fallo que ping ayuda a aislar rápidamente. En un entorno gestionado por Purple, la pregunta rara vez es simplemente "¿puede este dispositivo acceder a Internet?". La mejor pregunta es "¿qué dependencia en el recorrido del usuario está fallando y en qué punto?".

Roaming y caídas intermitentes

Para quejas sobre roaming, comienzo con un ping continuo a un objetivo local y estable. El comando ping -t a la puerta de enlace predeterminada suele ser la primera prueba más limpia porque mantiene el resultado centrado en la continuidad de la WLAN en lugar de en el ruido de la ruta de Internet.

Ejecute la prueba mientras el usuario se desplaza por la zona problemática. Observe si hay tiempos de espera agotados, picos de latencia o una breve pausa seguida de una recuperación. Una interrupción corta durante un roaming puede ser aceptable en algunas combinaciones de dispositivos móviles y puntos de acceso. Las caídas repetidas en la misma puerta, escalera o límite de cobertura suelen indicar un diseño de RF, comportamiento de clientes adherentes (sticky clients) o tiempos de traspaso del punto de acceso.

La elección del objetivo es importante. Una puerta de enlace comprueba si el cliente sigue conectado a la red local. Un host remoto añade variaciones de WAN, políticas de DNS y congestión ascendente, lo que puede ocultar el problema subyacente.

Comprobaciones del Captive Portal y del recorrido del invitado

El WiFi para invitados añade otra capa. Un dispositivo puede asociarse al SSID y, aun así, fallar en el recorrido real del usuario.

Use ping para separar el transporte de la política. Si el cliente puede llegar a la puerta de enlace pero no a una IP externa, el problema puede residir en las reglas del firewall, el enrutamiento ascendente o la política de walled-garden. Si ambos responden pero el invitado aún no puede completar el acceso, concéntrese en la lógica del portal, la interceptación de DNS, el estado de la sesión o la gestión de tiempos de espera dentro del flujo de incorporación.

Aquí también es donde importa la disciplina. El ping no valida el portal en sí. Solo le indica si la ruta subyacente se está comportando correctamente.

Passpoint, OpenRoaming y acceso respaldado por identidad

El WiFi basado en identidad cambia el modelo de resolución de problemas. Con Passpoint o OpenRoaming , los usuarios pueden fallar antes de que aparezca cualquier aviso del navegador, por lo que "internet arriba" no es una prueba útil por sí sola.

Haga ping a la infraestructura de la que depende la sesión. A menudo, esto significa el controlador local o la puerta de enlace, y luego la ruta de autenticación si se permite ICMP. Una prueba de paquetes más grandes como ping -l 1472 puede ayudar a exponer problemas de MTU o fragmentación entre el segmento del cliente y un controlador o servicio ascendente, especialmente cuando los pings de tamaño estándar parecen limpios pero la incorporación o la reautenticación aún se detienen.

RADIUS merece especial atención. Si los usuarios informan un inicio de sesión lento, solicitudes de credenciales repetidas o una incorporación segura inconsistente, pruebe la accesibilidad y la estabilidad del segmento de red de autenticación siempre que sea posible. La alta latencia o la pérdida intermitente en esa ruta pueden arruinar la experiencia de inicio de sesión mucho antes de que alguien abra un panel de control.

Mida la ruta que el usuario realmente toma

En el WiFi empresarial, ping funciona mejor cuando los objetivos coinciden con el flujo de la sesión.

• Puerta de enlace local para la continuidad de la WLAN
• Controlador o extremo de servicio local para el estado de la infraestructura
• Dependencia de autenticación para el acceso basado en identidad
• Host externo para la accesibilidad general ascendente

Esa secuencia es operativamente útil porque se asigna a cómo los usuarios se conectan en lugares con acceso de invitados, aplicación de políticas y tráfico segmentado. Los equipos que también necesitan un contexto de servicio y RF más amplio deben combinar las comprobaciones de la línea de comandos con una guía para medir el rendimiento de la red WiFi .

Una última advertencia. ICMP es una herramienta de resolución de problemas, no una prueba de que todo el servicio esté en buen estado. Un ping limpio no confirma la representación del portal, la asignación de políticas, la confianza en el certificado ni la accesibilidad de la aplicación. Le ofrece una forma rápida de reducir el dominio de fallos, que es exactamente lo que necesita en entornos complejos de WiFi y seguridad de red donde múltiples sistemas pueden fallar de diferentes maneras al mismo tiempo.

Un flujo de trabajo práctico de resolución de problemas para administradores de Purple

El mejor flujo de trabajo es el que su equipo puede repetir bajo presión. El mío es sencillo. Comience en el dispositivo y luego avance hacia fuera en una secuencia fija. No se adelante solo porque un panel de control parezca convincente.

El método de dentro hacia fuera

1. Verifique primero el endpoint Confirme que el dispositivo está conectado y tiene el estado de red esperado. No asuma que el icono de WiFi significa una sesión utilizable.

2. Haga ping a la dirección de loopback
   Esto comprueba la pila TCP/IP local. Si falla, no tiene un misterio de red. Tiene un problema del host.

3. Haga ping a la puerta de enlace predeterminada
   Esto separa rápidamente los problemas del cliente local y de la WLAN de los problemas ascendentes.

4. Haga ping a la siguiente dependencia importante
   Puede ser un controlador, un destino de autenticación u otro servicio interno. Adapte el destino al síntoma.

5. Haga ping a un host externo
   Esto confirma si el problema se extiende más allá del límite del recinto.

6. Escale a tracert o pathping cuando sea necesario
   Úselos solo después de saber qué segmento merece ser analizado.

7. Consulte los paneles de control y los sistemas de políticas al final, con una hipótesis definida
   Ahora sus registros tendrán más sentido porque sus pruebas de línea de comandos ya habrán acotado el campo de búsqueda.

Qué funciona y qué no

Lo que funciona es la coherencia. Todos los ingenieros del equipo deben seguir el mismo orden, registrar los mismos resultados y comparar el comportamiento local con el ascendente antes de cambiar nada.

Lo que no funciona es saltar directamente a los reinicios, culpar al firewall o abrir incidencias con el proveedor sin un historial del proceso. Eso hace perder tiempo y, a menudo, destruye las pruebas que necesitaba.

Gran parte de esta disciplina se solapa con una mentalidad más amplia de seguridad de red. La identidad, la segmentación, el filtrado y las políticas pueden influir en si el protocolo ICMP está permitido, priorizado o si es representativo. Una buena resolución de problemas respeta eso sin quedar paralizada por ello.

Trate cada ping fallido como un dato dentro de una secuencia controlada, no como un veredicto sobre toda la red.

Si se enfrenta a anomalías en los endpoints tras cambios en el sistema operativo, esta guía para resolver problemas de conectividad a internet en Windows 11 tras la actualización es una referencia práctica. Un número sorprendente de "incidentes de red" comienzan con una pila de cliente que cambió sin que el usuario se diera cuenta.

El objetivo no es adorar a ping. El objetivo es usarlo de forma que se obtenga claridad rápidamente. Sigue siendo uno de los hábitos de mayor valor que puede desarrollar un administrador de redes.

---

Si ofrece WiFi para invitados, personal o multi-inquilino y desea una menor fricción en la autenticación, una mejor visibilidad del acceso basado en la identidad y un modelo operativo más limpio que las contraseñas compartidas y los frágiles Captive Portals , eche un vistazo a Purple .