Actions filaires
Utilisez le tableau de bord Actions pour résoudre les problèmes affectant vos commutateurs.
Lorsque vous cliquez sur le bouton Filaire dans le tableau de bord Actions, vous verrez une liste de toutes les actions disponibles. Vous pouvez ensuite cliquer sur une action pour approfondir l’enquête. 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 AP mais pas sur le port du commutateur. Par conséquent, les clients ne peuvent pas communiquer sur un VLAN spécifique et ne peuvent pas non plus obtenir d’adresse IP du serveur DHCP. Marvis compare le VLAN sur le trafic AP et le trafic VLAN client avec le VLAN sur le trafic des ports de commutation et détermine quel appareil n’a pas la configuration VLAN.
Il peut s’agir d’un commutateur Juniper EX Series ou QFX Series, ou d’un commutateur tiers.
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 est manquante et fournit les informations sur les ports, ce qui vous permet d’atténuer ce problème facilement.
Lorsque vous voyez une action VLAN manquant, vous pouvez accéder à la section Événements client de la page Client Insights et rechercher les défaillances liées au VLAN signalé. Vous pouvez vérifier si tous les clients qui se connectent sur ce VLAN rencontrent des échecs DHCP.
Si vous avez activé les Marvis Minis, les validations sont automatiquement lancées lorsque Marvis identifie un problème potentiel de VLAN manquant sur le réseau. Marvis Minis valide la connectivité le long du chemin suspecté du VLAN pour confirmer si le VLAN est manquant et localiser les éventuels problèmes. Le lien Afficher plus fournit des détails sur les validations des Marvis Minis, comme indiqué dans l’exemple suivant.
Si vous avez besoin de plus d’informations, vous pouvez également utiliser le menu de gauche pour accéder à la page des Commutateurs. Là, 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 effectivement résolu.
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 commutation où des échecs de négociation automatique se produisent. Ce problème peut se produire lorsque Marvis détecte une incompatibilité de duplex entre les appareils en raison de l’incapacité de la négociation automatique à définir le bon mode de duplex. 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 inachevée. Notez que Marvis répertorie le commutateur et le port sur lesquels la négociation automatique a échoué.
Une fois le problème résolu dans votre réseau, l’action Négociation incomplète est automatiquement résolue dans l’heure qui suit.
Incompatibilité MTU
Marvis détecte les incompatibilités de MTU entre le port d’un commutateur et le port de l’appareil connecté directement à ce port de commutateur. Tous les appareils sur le 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, entraînant une surcharge du réseau.
Pour résoudre le problème, vous devez vérifier la configuration des ports du commutateur et de l'appareil connecté. Voici un exemple d’incompatibilité MTU identifiée par Marvis. La colonne Détails répertorie le port sur lequel l’incompatibilité se produit.
Boucle détectée
L’action Boucle détectée indique qu’une boucle se produit dans votre réseau, ce qui fait que le commutateur reçoit le même paquet qu’il a envoyé. Une boucle se produit lorsque plusieurs liaisons existent entre les équipements. Les liaisons redondantes sont une cause fréquente de boucles L2. Un lien redondant sert de lien de secours pour le lien principal. 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 de la boucle de trafic sur votre site et vous montre les commutateurs concernés. Voici un exemple :
Les boucles de commutation sont répertoriées sous Événements de commutation sur la page Informations sur les commutateurs. Dans l’exemple suivant, vous pouvez voir la modification de topologie STP répertoriée.
Instabilité des ports réseau
L’action Basculement des ports 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 en tant que partie d’un canal de port. Une instabilité de port peut 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 le redémarrage continu d’un équipement final connecté au port. L’exemple suivant montre les détails fournis par Marvis Actions pour une action d’instabilité des ports réseau :
Vous pouvez afficher les événements de port haut et de port bas sous Événements de commutation sur la page Informations sur les commutateurs. Marvis ne répertorie pas les instabilités de port lentes comme une action, sauf si la fréquence des instabilités augmente. Marvis continue de surveiller la lenteur des ports instables pour déterminer la gravité du problème. Si l’instabilité devient excessive, Marvis l’indique comme une action après avoir pris en compte la fréquence et la gravité. Vous pouvez utiliser l’assistant conversationnel pour afficher des détails sur les ports lents.
Pour plus de détails sur les instabilités des ports d’accès, reportez-vous à la section Instabilité des ports d’accès,
Vous pouvez désactiver un port instable de manière persistante directement à partir de la page Marvis Actions. Dans la section Actions d’instabilité des ports réseau, sélectionnez le commutateur sur lequel vous souhaitez désactiver un port et cliquez sur le bouton DÉSACTIVER LE PORT .
La page Désactiver le port s’affiche, répertoriant 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 réactiver ces ports en modifiant la configuration des ports sur la page Détails du commutateur. Après avoir réactivé les ports, vous pouvez reconnecter les périphériques aux ports.
Une fois le problème résolu dans votre réseau, l’action Port Flap se résout automatiquement en une heure.
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 élevé
Marvis détecte les commutateurs qui utilisent constamment le 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 beaucoup le processeur, et que la cause de cette utilisation élevée est l’utilisation de modules optiques non certifiés sur le commutateur :
Si vous voyez une action CPU élevée, vous pouvez accéder à la page Insights du commutateur et analyser le graphique d’utilisation du CPU sous Graphiques de commutateur. Voici un exemple :
Port bloqué
L’action Port bloqué détecte une différence dans le schéma de trafic sur un port d’accès d’un commutateur, telle qu’aucun paquet transmis ou reçu, indiquant que le client connecté au port ne fonctionne pas normalement. Dans l'exemple suivant, 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 au VLAN associé.
Lorsque Marvis détecte un problème de port bloqué, il lance un retour automatique de port pour résoudre le problème. Si le rebond automatique des ports ne parvient pas à résoudre le problème, Marvis l’indique comme une action. Vous pouvez afficher l’action de rebond automatique sous Switch Events sur la page Switch Insights, comme illustré dans l’exemple suivant. Le graphique de droite montre le trafic avant et après le rebond du port. Vous verrez qu'avant le rebond du port, seul le trafic Tx est visible (indiqué en vert). Après le rebond du port, vous verrez que le trafic Rx est également visible.
La capacité d’autonomie de l’action Port bloqué est activée par défaut. Pour plus d’informations sur la capacité d’autonomie, consultez la section Conduite autonome de Marvis Actions.
Anomalie de trafic
Marvis détecte une baisse ou une augmentation inhabituelle du trafic de diffusion et de multicast sur un commutateur. Il détecte également les erreurs de transmission ou de réception anormalement élevées. Comme la vue de 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 affectés. Si le problème affecte un site entier, Marvis affiche les détails des commutateurs concernés et les détails des ports de chaque commutateur concerné.
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 sur les ports de liaison montante :
-
Vitesse
-
Duplex
-
VLAN natif
-
VLAN autorisés
-
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 Commutateur>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 voir les adresses et les ports MAC.
Basculer hors ligne
Marvis détecte les commutateurs déconnectés du cloud Juniper Mist. Les commutateurs peuvent être déconnectés pour de nombreuses raisons, notamment :
-
Problèmes d’alimentation
-
Câble défectueux
-
Les ports de pare-feu requis ne sont pas ouverts
-
Configuration incorrecte
Lorsqu’un commutateur est hors ligne, Marvis surveille le commutateur pour vérifier la durée de son état hors ligne. Si le commutateur est hors ligne pendant plus de trois minutes, Marvis génère l’action Commutateur hors ligne. Notez que les alertes et les événements d’infrastructure hors ligne des commutateurs sur la page Informations sur les commutateurs s’affichent dès qu’un commutateur est hors ligne.
Voici un exemple qui montre l’action Commutateur hors ligne Marvis. Cliquez sur le lien Afficher plus pour afficher les détails du commutateur hors ligne. Si vous cliquez sur le nom du commutateur, vous pouvez afficher la page Insights où vous pouvez afficher l’événement répertorié sous Événements de commutateur.
Pour dépanner un commutateur hors ligne, reportez-vous à la section Dépannage de la connectivité de votre commutateur.
Serveur DHCP non autorisé détecté
L’action Serveur DHCP non autorisé détecté est déclenchée lorsque Marvis identifie des serveurs DHCP non autorisés sur des commutateurs EX Series sur lesquels la surveillance DHCP est activée. La détection précoce d’un serveur DHCP non autorisé est essentielle car elle peut perturber les opérations normales du réseau en :
-
Attribution d’adresses IP à partir du mauvais sous-réseau, ce qui fait que les appareils se retrouvent sur des réseaux incorrects ou non routables
-
Causer des problèmes de connectivité aléatoires ou intermittents, tels que des problèmes d’accès aux ressources internes ou à Internet
Marvis génère cette action lorsque les conditions suivantes sont remplies :
-
Observe les offres DHCP à partir d’un serveur inconnu
-
Mappe l’événement à un commutateur, un port, un VLAN ou un site spécifique
-
Observez les occurrences répétées d’activités DHCP non autorisées, confirmant qu’il ne s’agit pas d’une anomalie ponctuelle, mais d’un problème récurrent qui doit être résolu
L’action Marvis détecté par un serveur DHCP non autorisé est une action autonome. Par défaut, la capacité autonome de l’action est désactivée.
Si vous avez activé la fonctionnalité autonome pour cette action, Marvis désactive automatiquement le port de commutation utilisé par le serveur DHCP non autorisé. Notez que cela ne s’applique qu’aux ports d’accès.
Si la conduite autonome est désactivée, vous pouvez désactiver manuellement le port en cliquant sur le bouton Désactiver le port .
Pour plus d’informations sur la capacité autonome et comment l’activer, consultez la section Conduite autonome de Marvis Actions.
Cliquez sur le lien Afficher plus pour afficher un graphique qui montre les événements liés aux serveurs non autorisés sur une période de 24 heures. La survol du graphique affiche la date, l’heure et le nombre d’événements détectés. Les événements peuvent également être consultés sur la page Informations sur les commutateurs dans le cadre des événements de commutation.
