Acciones del conmutador
RESUMEN Utilice el panel Acciones para resolver problemas que afecten a los conmutadores.
Al hacer clic en el botón Cambiar del panel 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.
Sus suscripciones determinan las acciones que puede ver en el panel Acciones. Para obtener más información, consulte Requisitos de suscripción para acciones de Marvis.
Falta VLAN
La acción VLAN faltante indica que una VLAN está configurada en un punto de acceso, 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 del AP con la VLAN en el tráfico del puerto del conmutador y determina a qué dispositivo le falta la configuración de VLAN.
En el siguiente ejemplo, Marvis identifica dos puntos de acceso que no ven ningún tráfico entrante debido a la falta de una configuración de VLAN. 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.
Si necesita más información, también puede usar el menú de la izquierda para ir a la página Interruptores. Allí, haga clic en el conmutador para ver la información de cada puerto, incluidas las VLAN.
Después de solucionar el problema en la red, Mist AI supervisa el conmutador durante un período determinado y se asegura de que el problema de VLAN que falta se resuelva. Por lo tanto, la acción VLAN faltante puede tardar hasta 30 minutos en resolverse automáticamente y aparecer en la sección Últimas actualizaciones.
Para obtener más información acerca de la acción VLAN faltante, vea el siguiente vídeo:
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.
Inadecuación de la negociación
La acción Negociación no coincidente detecta instancias en los puertos del conmutador en las que la negociación no se ha completado. Este problema puede producirse cuando Marvis detecta una discrepancia de dúplex entre dispositivos debido a que la negociación automática no pudo establecer el modo dúplex correcto. Marvis proporciona detalles sobre el puerto afectado. Puede comprobar la configuración en el puerto y el dispositivo conectado para resolver el problema.
En el ejemplo siguiente se muestran los detalles de la acción Discrepancia de negociación. Observe que Marvis enumera el conmutador y el puerto en el que se produjo la discrepancia de la negociación.
Después de solucionar el problema en la red, la acción Negociación no coincidente se resuelve automáticamente y aparece en la sección Últimas actualizaciones en una hora.
Bucle detectado
La acción Bucle detectado indica un bucle en la red que da como resultado que el conmutador reciba el mismo paquete que envió. Un bucle se produce 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:
Aleta de puerto
La acción Fuga de puerto identifica los puertos que rebotan de forma persistente durante un breve intervalo de tiempo, lo que indica que un puerto o cliente tiene un problema. El aleteo de puertos puede ocurrir debido a conexiones poco confiables, reinicio continuo de un dispositivo conectado al puerto o configuraciones dúplex incorrectas. En el siguiente ejemplo se muestran los detalles que Marvis Actions proporciona para una acción de Flap de puerto:
Puede deshabilitar un puerto de aleteo persistente directamente desde la página Acciones de Marvis. En la sección Acciones de bloqueo de puerto, 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, en la que se enumeran 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 se deshabilita un puerto, las configuraciones de puertos de los puertos seleccionados cambian a deshabilitadas y los puertos dejan de funcionar. 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 Fuga de puerto se resuelve automáticamente y aparece en la sección Últimas actualizaciones 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. Varios factores pueden causar un alto uso de la CPU: tráfico de multidifusión, bucles de red, problemas de hardware, temperatura del dispositivo, etc. La acción CPU alta enumera los conmutadores, los procesos que se ejecutan en el conmutador junto con la tasa de utilización de CPU y el motivo de la alta utilización. En el ejemplo siguiente, verá que el proceso fxpc tiene un alto uso de CPU y la causa de la alta utilización es el uso de ópticas no certificadas en el conmutador:
Puerto atascado
La acción Puerto atascado detecta una diferencia en el patrón de tráfico en un puerto de conmutador, como ningún paquete transmitido o recibido, lo que indica que el cliente conectado al puerto no funciona normalmente. En el siguiente ejemplo, verá que Marvis Actions recomienda que rebote el puerto y compruebe 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 a la VLAN asociada.
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 errores de conectividad, la vista Detalles muestra una línea 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 uno de los conmutadores afectados.
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.