Actions de commutation
Utilisez le tableau de bord Actions pour résoudre les problèmes affectant vos commutateurs.
Lorsque vous cliquez sur le bouton Basculer dans le tableau de bord Actions, une liste de toutes les actions disponibles s'affiche. Vous pouvez ensuite cliquer sur une action pour approfondir vos investigations. Les actions disponibles sont décrites plus loin dans cette rubrique.
Vos abonnements déterminent les actions que vous pouvez voir sur le tableau de bord Actions. Pour plus d’informations, consultez Conditions d’abonnement à Marvis Actions.
VLAN manquant
L’action VLAN manquant indique qu’un VLAN est configuré sur un point d’accès, mais pas sur le port du commutateur. Par conséquent, les clients ne peuvent pas communiquer sur un VLAN spécifique et sont également incapables d’obtenir une adresse IP du serveur DHCP. Marvis compare le VLAN sur le trafic du point d’accès avec le VLAN sur le trafic du port de commutation et détermine quel appareil ne dispose pas de configuration VLAN.
Dans l’exemple suivant, Marvis identifie deux points d’accès qui ne voient aucun trafic entrant en raison d’une configuration VLAN manquante. Marvis identifie également les commutateurs spécifiques pour lesquels la configuration VLAN n’a pas été configurée et fournit les informations sur les ports, ce qui vous permet d’atténuer ce problème en toute simplicité.
Si vous avez besoin de plus d’informations, vous pouvez également utiliser le menu de gauche pour accéder à la page Commutateurs. Cliquez sur le commutateur pour afficher les informations de chaque port, y compris les VLAN.
Une fois que vous avez résolu le problème dans votre réseau, Mist AI surveille le commutateur pendant un certain temps et s’assure que le problème de VLAN manquant est bien résolu. Par conséquent, il peut s’écouler jusqu’à 30 minutes avant que l’action VLAN manquant ne se résolve automatiquement et n’apparaisse dans la section Dernières mises à jour.
Pour plus d’informations sur l’action VLAN manquant, regardez la vidéo suivante :
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.
Négociation incomplète
L’action Négociation incomplète détecte les instances sur les ports de commutateur où des échecs de négociation automatique se produisent. Ce problème peut se produire lorsque Marvis détecte une incompatibilité duplex entre les appareils, car la négociation automatique n’a pas réussi à définir le mode duplex correct. Marvis fournit des détails sur le port concerné. Vous pouvez vérifier la configuration du port et de l’appareil connecté pour résoudre le problème.
L’exemple suivant montre les détails de l’action Négociation incomplète. Notez que Marvis répertorie le commutateur et le port sur lesquels la négociation automatique a échoué.
Une fois que vous avez résolu le problème sur votre réseau, l’action Négociation incomplète est automatiquement résolue et apparaît dans la section Dernières mises à jour dans l’heure qui suit.
Incompatibilité MTU
Marvis détecte les incompatibilités MTU entre le port d’un commutateur et le port de l’appareil qui est connecté directement à ce port de commutateur. Tous les appareils d’un même réseau de couche 2 (L2) doivent avoir la même taille de MTU. Lorsqu’une incompatibilité MTU se produit, les périphériques peuvent fragmenter les paquets, ce qui entraîne une surcharge réseau.
Pour résoudre le problème, vous devrez examiner la configuration des ports du commutateur et de l'appareil connecté. Voici un exemple d’incompatibilité MTU identifiée par Marvis. La colonne Details (Détails ) répertorie le port sur lequel l’incompatibilité se produit.
Boucle détectée
L’action Boucle détectée indique une boucle dans votre réseau, ce qui fait que le commutateur reçoit le même paquet que celui qu’il a envoyé. Une boucle se produit lorsqu’il existe plusieurs liens entre des périphériques. Les liens redondants sont souvent à l’origine des boucles L2. Une liaison redondante sert de liaison de secours pour la liaison principale. Si les deux liaisons sont actives en même temps et que des protocoles tels que le protocole STP (Spanning Tree Protocol) ne sont pas déployés correctement, une boucle de commutation se produit.
Marvis identifie l’emplacement exact sur votre site où la boucle de trafic se produit et vous indique les commutateurs concernés. Voici un exemple :
Instabilité des ports réseau
L’action Battement de port réseau identifie les ports trunk qui rebondissent de manière persistante pendant au moins une heure. Par exemple, trois battements par minute pendant une heure. Les ports configurés en tant que ports trunk sont utilisés pour se connecter à d’autres commutateurs, passerelles ou points d’accès en tant que ports trunk individuels ou dans le cadre d’un canal de port. Des signes d’instabilité des ports peuvent se produire en raison d’un câble ou d’un émetteur-récepteur défectueux, provoquant un trafic unidirectionnel ou un échange LACPDU, ou un redémarrage continu d’un terminal connecté au port. L’exemple suivant montre les détails fournis par Marvis Actions pour une action de rabat de port réseau :
Pour plus d’informations sur les ports d’accès, reportez-vous à la section Ports d’accès,
Vous pouvez désactiver un port instable et persistant directement depuis la page Marvis Actions. Dans la section Network Port Flap actions, sélectionnez le commutateur sur lequel vous souhaitez désactiver un port, puis cliquez sur le bouton DÉSACTIVER LE PORT .
La page Désactiver le port s’affiche et répertorie les ports que vous pouvez désactiver. Vous ne pouvez pas sélectionner un port s’il est déjà désactivé (soit précédemment via la page Actions, soit manuellement à partir de la page Détails du commutateur).
Lorsque vous désactivez un port, les configurations des ports sélectionnés deviennent désactivées et les ports tombent en panne. Une fois le problème résolu, vous pouvez les réactiver en modifiant la configuration des ports sur la page Détails du commutateur. Une fois que vous avez réactivé les ports, vous pouvez reconnecter les périphériques aux ports.
Une fois que vous avez résolu le problème dans votre réseau, l’action Port Flap est automatiquement résolue et apparaît dans la section Dernières mises à jour dans l’heure qui suit.
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.
Processeur élevé
Marvis détecte les commutateurs qui ont constamment une utilisation élevée du processeur (> 90 %). Divers facteurs peuvent entraîner une utilisation élevée du processeur : trafic multicast, boucles réseau, problèmes matériels, température de l’appareil, etc. L’action CPU élevé répertorie les commutateurs, les processus en cours d’exécution sur le commutateur, ainsi que le taux d’utilisation du CPU et la raison de l’utilisation élevée. Dans l’exemple suivant, vous voyez que le processus fxpc utilise fortement le processeur, et que la cause de cette utilisation élevée est l’utilisation d’optiques non certifiées sur le commutateur :
Port bloqué
L’action Port bloqué détecte une différence dans le modèle de trafic sur un port d’accès d’un commutateur, par exemple l’absence de paquets transmis ou reçus, ce qui indique que le client connecté au port ne fonctionne pas normalement. Dans l'exemple suivant, vous verrez que Marvis Actions vous recommande de faire rebondir le port et de vérifier si le client commence à fonctionner normalement. Notez qu’en plus du numéro de port, Marvis répertorie également le client (dans ce cas, une caméra) connecté au port et le VLAN associé.
Anomalie de trafic
Marvis détecte une baisse ou une augmentation inhabituelle du trafic de diffusion et de multidiffusion sur un commutateur. Il détecte également toute erreur d’émission ou de réception anormalement élevée. À l’instar de la vue Détection des anomalies pour les échecs de connectivité, la vue Détails affiche une chronologie, la description de l’anomalie et des détails sur les ports concernés. Si le problème concerne un site entier, Marvis affiche les détails des commutateurs concernés et les détails des ports de chaque commutateur affecté.
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.
Port mal configuré
Lorsqu’un commutateur est connecté à un autre commutateur, la communication nécessite des propriétés communes sur les ports. Pour détecter les erreurs de configuration, Marvis compare les propriétés suivantes :
-
Vitesse
-
Duplex
-
VLAN natif
-
VLAN autorisé
-
MTU
-
Mode port (les deux ports « accès » ou les deux ports « trunk »)
-
Mode STP (transfert des deux ports)
Dans le tableau de bord Actions, cliquez sur Basculer > port mal configuré pour afficher les problèmes et l’action recommandée dans la partie inférieure de l’écran.
Cliquez sur le lien Afficher plus pour afficher les adresses MAC et les ports.
