Acciones por cable
Utilice el panel de acciones para resolver problemas que afecten a sus conmutadores.
Al hacer clic en el botón Conectado en el panel de Acciones, verá una lista de todas las acciones disponibles. A continuación, puede hacer clic en una acción para investigar más a fondo. Las acciones disponibles se describen más adelante en este tema.
Las suscripciones determinan las acciones que puede ver en el panel Acciones. Para obtener más información, consulte Requisitos de suscripción para Marvis Actions.
Falta de VLAN
La acción Falta una VLAN indica que una VLAN está configurada en un AP, pero no en el puerto del conmutador. Como resultado, los clientes no pueden comunicarse en una VLAN específica y tampoco pueden obtener una dirección IP del servidor DHCP. Marvis compara la VLAN en el tráfico de AP con la VLAN en el tráfico del puerto de conmutador y determina a qué dispositivo le falta la configuración de VLAN.
El conmutador puede ser un conmutador de las series EX o QFX de Juniper, o un conmutador de terceros.
En el siguiente ejemplo, Marvis identifica dos AP que no ven ningún tráfico entrante debido a una configuración de VLAN faltante. Marvis también identifica los conmutadores específicos a los que les falta la configuración de VLAN y proporciona la información del puerto, lo que le permite mitigar este problema con facilidad.
Cuando vea una acción Falta de VLAN, puede ir a la sección Eventos del cliente en la página Información de AP y comprobar si hay errores en la VLAN que se informan en la acción Falta de VLAN. Puede comprobar si todos los clientes que se conectan en esa VLAN están experimentando errores de DHCP.
Si necesita más información, también puede usar el menú de la izquierda para ir a la página de Conmutadores. Allí, haga clic en el conmutador para ver la información de cada puerto, incluidas las VLAN.
Después de solucionar el problema en su red, Mist AI monitorea el conmutador durante un cierto período y garantiza que el problema de VLAN faltante se resuelva. Por lo tanto, la acción Falta de VLAN puede tardar hasta 30 minutos en resolverse automáticamente.
Para obtener más información sobre la acción Missing VLAN, vea el siguiente video:
Missing VLANs is a two-decade-old networking problem. It sounds so simple, but in a large enterprise it can become the ghost in the machine, as users complain their calls always drop in a certain area and conventional wisdom is, well, there must be interference or Wi-Fi issues over there. In many cases when Mist support helped troubleshoot, we found a user VLAN was indeed not provisioned on the network switch.
Hence, the user had no place to roam and the call dropped. For customers with tens of thousands of APs, this truly becomes the needle in the haystack problem. At Mist, we wanted to use AI to solve this problem, but first let's take a look at how you might start out today.
You can manually take a look, but I only have two VLANs. Or you can programmably take a look, but this makes my brain hurt. If an AP is connected to a switch port, but the user can't get an IP address or pass any traffic, then the VLAN probably isn't configured on the port or it's black holed.
The traditional way to measure a missing VLAN is to monitor traffic on the VLAN and if one VLAN continuously lacks traffic, then there's a high chance that the VLAN is missing on the switch port. The problem of this approach is false positives. Here you can see during a 24-hour window, we detected more than 33,000 APs missing one or more VLANs because they had little or no traffic, but this was not accurate as we learned that every VLAN is not created equal.
There are at least two types of special purpose VLANs that can cause detection problems. One is the black hole VLAN. Folks can create a black hole VLAN on all unconfigured ports or as a quarantine VLAN for users until they are fully authorized. This VLAN is supposed to be provisioned on the switch in case a quarantined user shows up on the AP. The second example is the over-provisioned VLAN. Larger customers use special VLANs for special sites.
For example, legacy devices might only be present at certain sites, so special VLAN should only be applicable to those sites, but because people do use automation, they want to keep their configurations consistent so they provision that VLAN across all the sites. In this case, you would expect low traffic or no traffic. Those VLANs shouldn't be flagged as missing because they were intentionally over-provisioned.
So the key for reducing false positives is to really identify the purpose of each VLAN. We could ask the customer for their own internal list, perhaps in the form of a spreadsheet, but that's very error prone. MIST developed an unsupervised machine learning model to automatically discover the purpose of each VLAN by learning from the traffic patterns on the VLANs.
In this graph, each dot represents all of the VLANs across the MIST customer base. So for each VLAN, we collect several features. How many APs lack traffic on that VLAN? How many sites lack traffic? How busy is that VLAN minute by minute from all the APs? Then we use another technique called principal component analysis to combine all of these features and map them into this two-dimensional space.
The interesting thing here is the different VLAN types, high traffic, low traffic, black hole, and over-provisioned are separated really well, even across different customers, because it turns out VLAN behavior is very similar across different customers. The beauty of this is instead of developing per customer anomaly detection tools, we actually built one model for everybody. So for any new customers, we don't have to ask them anything.
We can determine the purpose of their VLANs very quickly after they deploy. This is really the power of this multi-tenant infrastructure design. Every customer can benefit from the knowledge learned from our extended customer base.
By precisely identifying each VLAN's purpose, we reduced our initial detection rate from 33,000 plus to specifically 607 VLANs, which we believed were actually missing from the AP switch ports. For MIST, this was the moment of truth. When we were confident in the model, we contacted the customers with these 607 detected missing VLANs, and when we finally heard back, we had an astonishing 100% hit rate, no false positives.
For MIST, this was simply awesome, as there are so many mundane problems we can apply this technique to going forward. So right now, this is shown in Marvis Actions, and with a supported Juniper switch, we can provide the user specific CLI commands that we suggest they add to their config to get these missing VLANs going, with a goal to automatically doing this from the cloud as we gain their trust. And for non-Juniper switches, we give detailed info like which switch, which port, and which VLAN ID to guide them how to solve the problem that they probably didn't even know they had.
This is all built on open protocols like OpenConfig and NetConf. And lessons learned by the MIST data science team, AI solutions should first start by solving real problems, rather than deploying models and hoping for the best. Some AI vendors treat AI as a hammer in search of a nail, and this isn't going to work.
The Marvis AI engine was designed starting with human expertise and then learning over time. At MIST, each support ticket is first run through Marvis to both measure its efficacy and continue to train the model to solve the most important customer issues.
Negociación incompleta
La acción Negociación incompleta detecta instancias en puertos de conmutador en las que se producen errores de negociación automática. Este problema puede producirse cuando Marvis detecta una discrepancia dúplex entre dispositivos debido a que la negociación automática no logra establecer el modo dúplex correcto. Marvis proporciona detalles sobre el puerto afectado. Puede comprobar la configuración del puerto y del dispositivo conectado para resolver el problema.
En el ejemplo siguiente se muestran los detalles de la acción Negociación incompleta. Observe que Marvis enumera el conmutador y el puerto en el que falló la negociación automática.
Después de solucionar el problema en su red, la acción Negociación incompleta se resuelve automáticamente en una hora.
discordancia de UMT
Marvis detecta discordancias de UMT entre el puerto de un conmutador y el puerto del dispositivo que está conectado directamente a ese puerto de conmutador. Todos los dispositivos en la misma red de capa 2 (L2) deben tener el mismo tamaño de UMT. Cuando se produce una discordancia de MTU, los dispositivos pueden fragmentar paquetes, lo que da como resultado una sobrecarga de red.
Deberá revisar la configuración de los puertos del conmutador y del dispositivo conectado para resolver el problema. Aquí hay un ejemplo de una discordancia de MTU identificada por Marvis. La columna Detalles enumera el puerto en el que se produce la discordancia.
Bucle detectado
La acción Bucle detectado indica un bucle en su red que da como resultado que el conmutador reciba el mismo paquete que envió. Se produce un bucle cuando existen varios vínculos entre dispositivos. Los vínculos redundantes son una causa común de bucles L2. Un vínculo redundante sirve como vínculo de respaldo para el vínculo principal. Si ambos vínculos están activos al mismo tiempo y protocolos como el protocolo de árbol de expansión (STP) no se implementan correctamente, se produce un bucle de conmutación.
Marvis identifica la ubicación exacta en su sitio donde se produce el bucle de tráfico y le muestra los conmutadores afectados. Aquí hay un ejemplo:
Los bucles de conmutación se enumeran en Eventos del conmutador en la página Información del conmutador. En el ejemplo siguiente, puede ver la lista de cambios en la topología STP.
Movimiento de puerto de red
La acción Flap de puerto de red identifica los puertos de troncalización que rebotan de forma persistente durante al menos una hora. Por ejemplo, tres aleteos por minuto durante una hora. Los puertos configurados como puertos de troncalización se utilizan para conectarse a otros conmutadores, puertas de enlace o AP como puertos de troncalización individuales o como parte de un canal de puerto. La oscilación de puertos puede ocurrir debido a un cable o transceptor defectuoso que causa tráfico unidireccional o intercambio LACPDU, o el reinicio continuo de un dispositivo final conectado al puerto. En el siguiente ejemplo, se muestran los detalles que Marvis Actions proporciona para una acción de oscilación de puerto de red:
Puede ver los eventos de puerto activo y descendente en Eventos del conmutador en la página Información del conmutador. Marvis no enumera las oscilaciones de puerto lentas como una acción, a menos que la frecuencia de oscilación aumente. Marvis sigue monitoreando la oscilación lenta de puertos para determinar la gravedad del problema. Si el aleteo se vuelve excesivo, Marvis lo enumera como una acción después de considerar la frecuencia y la gravedad. Puede usar el asistente conversacional para ver detalles sobre oscilaciones de puertos lentas.
Para obtener más información sobre las oscilaciones de puerto de acceso, consulte Oscilación de puerto de acceso,
Puede deshabilitar un puerto que oscila de forma persistente directamente desde la página de Marvis Actions. En la sección Acciones de oscilación de puerto de red, seleccione el conmutador en el que desea deshabilitar un puerto y haga clic en el botón DESHABILITAR PUERTO .
Aparece la página Deshabilitar puerto, con una lista de los puertos que puede deshabilitar. No puede seleccionar un puerto si ya está deshabilitado (ya sea anteriormente a través de la página Acciones o manualmente desde la página Detalles del conmutador).
Cuando deshabilita un puerto, las configuraciones de puerto en los puertos seleccionados cambian a deshabilitado y los puertos desactivan. Después de solucionar el problema, puede volver a habilitar estos puertos editando la configuración del puerto en la página Detalles del conmutador. Después de volver a habilitar los puertos, puede volver a conectar los dispositivos a los puertos.
Después de solucionar el problema en la red, la acción Oscilación de puerto se resuelve automáticamente en una hora.
Looking at the switch, in this case, specifically the Juniper switch, we've introduced the action of a port flapping continuously. In this case, we do take into account a simple port down and up, which usually happens when a device connects, and this is currently reflecting a case where the port is continuously flapping, thereby not only causing a poor experience for the device which is connected on the other end, but also having high resource consumption for the switch which can be detrimental to other devices connected on the switch. Here too, we show all the required information in terms of the port, the client which is connected, and the VLAN, if in case it did communicate and we know the VLAN ID.
CPU alta
Marvis detecta conmutadores que constantemente tienen un alto uso de CPU (> 90 %). Varios factores pueden causar una alta utilización de la CPU: tráfico de multidifusión, bucles de red, problemas de hardware, temperatura del dispositivo, etc. La acción Uso alto de CPU enumera los conmutadores, los procesos que se ejecutan en el conmutador junto con la tasa de utilización de la CPU y el motivo del uso elevado. En el ejemplo siguiente, verá que el proceso fxpc tiene un alto uso de la CPU y la causa del alto uso es el uso de elementos ópticos no certificados en el conmutador:
Si ve una acción de CPU alta, puede ir a la página Información del conmutador y analizar el gráfico de uso de CPU en Gráficos de conmutadores. Aquí hay un ejemplo:
Puerto bloqueado
La acción Puerto bloqueado detecta una diferencia en el patrón de tráfico en un puerto de acceso de un conmutador, como paquetes no transmitidos o recibidos, lo que indica que el cliente conectado al puerto no funciona normalmente. En el siguiente ejemplo, verá que Marvis Actions recomienda rebotar el puerto y verificar si el cliente comienza a funcionar normalmente. Tenga en cuenta que, además del número de puerto, Marvis también enumera el cliente (en este caso, una cámara) que está conectado al puerto y la VLAN asociada.
Cuando Marvis detecta un problema de puerto bloqueado, inicia un rebote automático de puerto para solucionar el problema. Si el rebote automático del puerto no resuelve el problema, Marvis lo enumera como una acción. Puede ver la acción de rebote automático en Eventos del interruptor en la página Información del conmutador, como se muestra en el siguiente ejemplo. El gráfico de la derecha muestra el tráfico antes y después del rebote del puerto. Verá que antes de que el puerto rebote solo se ve el tráfico de transmisión (indicado en verde). Después del rebote del puerto, verá que también se ve el tráfico de recepción.
La capacidad autónoma para la acción Puerto bloqueado está habilitada de forma predeterminada. Para obtener más información sobre la función autónoma, consulte Marvis Actions autónomas.
Anomalía de tráfico
Marvis detecta una caída o un aumento inusual del tráfico de difusión y multidifusión en un conmutador. También detecta cualquier error de transmisión o recepción inusualmente alto. Al igual que la vista Detección de anomalías para los errores de conectividad, la vista Detalles muestra una escala de tiempo, la descripción de la anomalía y detalles de los puertos afectados. Si el problema afecta a todo un sitio, Marvis muestra los detalles de los conmutadores afectados y los detalles del puerto de cada conmutador afectado.
Marvis, our AI-powered virtual network assistant, employs an actions framework to automatically identify network problems and anomalies that are likely impacting user experience. This helps you to significantly reduce mean time to resolution. Marvis can detect switched traffic anomalies, such as traffic storms or abnormal high TxRx count, with respect to broadcast, unknown, unicast, or multicast traffic.
It uses our third generation of algorithms, including long short-term memory, or LSTM for short, to boost efficacy and eliminate false positives. Visit the link below to learn more.
Puerto mal configurado
Cuando un conmutador está conectado a otro, la comunicación requiere propiedades comunes en los puertos. Para detectar errores de configuración, Marvis compara estas propiedades en los puertos de enlace ascendente:
-
Velocidad
-
Dúplex
-
VLAN nativa
-
VLAN permitida
-
UMT
-
Modo de puerto (ambos puertos "acceso" o ambos puertos "troncalización")
-
Modo STP (ambos puertos "reenvío")
En el panel Acciones, haga clic en Cambiar > puerto mal configurado para ver los problemas y la acción recomendada en la parte inferior de la pantalla.
Haga clic en el vínculo Ver más para ver las direcciones MAC y los puertos.
Cambiar sin conexión
Marvis detecta conmutadores que están desconectados de la nube de Juniper Mist. Los conmutadores pueden desconectarse debido a muchas razones, incluidas las siguientes:
-
Problemas de energía
-
Cable defectuoso
-
Los puertos de firewall necesarios no están abiertos
-
Configuración incorrecta
Cuando un conmutador se desconecta, Marvis monitorea el conmutador para verificar la duración del estado fuera de línea. Si el conmutador está fuera de línea durante más de tres minutos, Marvis genera la acción Cambiar sin conexión. Tenga en cuenta que las alertas y los eventos de infraestructura de Switch Offline de la página Información del conmutador aparecen tan pronto como se desconecta un conmutador.
Aquí hay un ejemplo que muestra la acción Cambiar sin conexión de Marvis. Haga clic en el vínculo Ver más para ver los detalles del conmutador que está sin conexión. Si hace clic en el nombre del conmutador, puede ver la página Información donde puede ver el evento que aparece en Eventos del conmutador.
Para solucionar problemas de un conmutador que está sin conexión, consulte Solución de problemas de conectividad del conmutador.