Supervision du Trafic Unicast Flooding

Trafic Unicast Flooding : cause principale et supervision

Le Trafic Unicast Flooding, ou l’Inondation de Trafic Unicast, dans sa version la plus conviviale, est associé au processus d’apprentissage des commutateurs réseau.

En fait, c’est la méthode par laquelle les commutateurs identifient les adresses au niveau de la liaison de données ou adresse MAC des périphériques qui sont accessibles par chacun de leurs ports, construisant ainsi une table qui sera utilisée plus tard. Pour décider la destination de chaque frame qui atteint le commutateur.

Cependant, ce type de trafic peut aussi présenter un côté pervers, dans lequel on affrontera une quantité excessive de frames Unicast qui sans justification apparente sont transmises par tous les ports du commutateur.

Il y a consensus pour accepter que les périodes d’inondation par Unicast peuvent supposer d’une faible performance à la panne complète du réseau.

Et bien que nous n’ayons pas trouvé de données statistiques permettant d’estimer la prévalence des problèmes de trafic Unicast Flooding, il est vrai que nous observons constamment de nombreux administrateurs réseau dans les forums techniques à la recherche d’informations sur le sujet.

Il est également à noter que les fabricants de périphériques réseau, tels que Cisco, ont développé des procédures et des commandes pour tenter de contenir l’effet négatif de ce type de trafic. Bien que les questions de diagnostic et de supervision n’aient pas été abordées de manière aussi énergique.

Maintenant, quels symptômes peuvent nous amener à penser que nous pourrions avoir un problème associé au Trafic Unicast Flooding?

Symptômes

En principe, un problème avec le Trafic Unicast Flooding dans une phase aiguë peut entraîner une forte augmentation de la quantité de trafic sur un VLAN, une augmentation du nombre de paquets perdus, une augmentation de la latence des services affectés et, comme nous l’avons dit, il peut dégénérer en la chute complète du réseau.

En revanche, l’effet négatif que cette condition pourrait avoir n’est pas négligeable lorsqu’elle ne reflète pas des symptômes trop alarmants et que le réseau « s ‘y habitue », c’est-à-dire qu’il y a un trafic excessif, qu’il y a une dégradation des performances et des cas de support associé sont fermés sans atteindre la cause première.

D’après notre expérience, ces cas de support « récurrents », qui ne sont pas clôturés de manière satisfaisante et sont ouverts par des utilisateurs qui signalent une lenteur ou une incapacité à accéder aux ressources du réseau, peuvent en fait être un symptôme qui nous amène à suspecter la présence de Trafic Unicast Flooding sur la plate-forme.

Je soupçonne que j’ai du Trafic Unicast Flooding. Et maintenant ?

Il y a trois éléments qui rendent difficile la gestion du trafic Unicast Flooding. Le premier est que cette condition est difficile à cerner.

Les analystes du support peuvent voir l’état de Unicast Flooding s’ils ont la possibilité d’évaluer les paquets de diffusion du segment avec un analyseur de trafic et peuvent observer le trafic Unicast, où ils ne devraient voir que des paquets Broadcast ou Multicast.

Ici, le deuxième élément est présenté ; Cette condition, en fonction de sa cause première, peut être temporaire. Par conséquent, vous pouvez avoir un trafic Unicast Flooding pendant une période de temps variable et il peut disparaître sans aucune intervention.

Cela complique la visualisation, car vous devez avoir la possibilité d’analyser le bon trafic, du bon segment, au bon moment, ce qui dans une grande plate-forme peut être très compliqué et coûteux en ressources.

Le troisième point est qu’il existe de nombreuses conditions qui peuvent générer l’inondation, ce qui complique sa visualisation, son analyse et sa prise de décision.

Causes possibles par rapport à la cause fondamentale

Il existe de nombreuses conditions documentées comme générant un trafic Unicast Flooding ; des changements de topologie qui pourraient révéler des failles dans la conception du réseau et dans la configuration des commutateurs aux attaques malveillantes qui favorisent l’inondation, en passant par différentes conditions techniques, comme le redoutable routage asymétrique.

Cependant, toutes ces conditions sont basées sur la manière dont les noms et les adresses sont résolus dans un schéma de réseau basé sur un commutateur.

Le schéma de résolution de nom prend en charge les communications à partir du moment où un appareil A souhaite établir un contact et transférer des informations vers un autre appareil B, pour lequel l’adresse IP est requise au niveau du réseau et l’adresse MAC dudit appareil au niveau de la liaison de données.

Les protocoles et procédures impliqués dans ce schéma de résolution de noms sont nombreux, mais en ce qui concerne le trafic Unicast Flooding, nous devons nous arrêter à deux éléments qui participent au schéma et sont gérés par les commutateurs : la table ARP et la table d’adresses MAC.

Le périphérique A peut obtenir l’adresse IP du périphérique B dans la table ARP, où les enregistrements ont un temps de séjour, appelé génériquement arp aging time, dont la valeur peut être de 4 heures, par exemple.

Si le registre n’existe pas, une triple diffusion des messages sera émise consécutivement à la recherche de l’adresse en question. Si vous souhaitez en savoir un peu plus sur les packages Broadcast et leur effet négatif, nous vous recommandons de lire cet article, publié dans ce blog.
(https://pandorafms.com/blog/fr/optimisation-du-reseau/)

Une fois l’adresse IP définie, puis, au niveau de la liaison de données, l’adresse MAC est requise, pour laquelle la table d’adresses MAC est utilisée, dont les enregistrements ont également un temps de résidence que nous pouvons appeler mac address table aging time, dont la valeur par défaut peut être de 5 minutes. En l’absence d’enregistrement approprié, le commutateur comprend qu’il doit essayer de savoir où se trouve cette adresse et générer le Trafic Unicast Flooding.

Les capacités et la situation actuelle de chaque table, en plus de l’inégalité des temps de rétention des enregistrements et de la manière dont les protocoles utilisent ces enregistrements, sont à la base de la plupart des conditions qui génèrent un Trafic Unicast Flooding :

• Les modifications de topologie peuvent entraîner des incohérences de tables ou leur débordement.
• Les codes malveillants utilisent le débordement de table comme outil.
• Le routage asymétrique peut être généré par des liaisons multiples entre deux VLAN et par la différence des temps de séjour entre les tables arp et les adresses MAC.

C’est la raison, donc notre recommandation est qu’avant d’étudier les conditions spécifiques de chaque situation, et bien sûr avant de prendre des décisions administratives telles que le blocage du trafic Unicast sur un ou plusieurs ports ou pour un VLAN entier, il est pratique de s’assurer de :

• Rechercher et comprendre bien le fonctionnement du schéma de résolution de noms dans la plate-forme basée sur des commutateurs, en tenant compte des marques et des modèles de commutateurs disponibles.
• Passer en revue les tables d’adresses ARP et MAC, ainsi que les commandes d’affichage et de modification qui leur sont associées.

Cela vous offrira une capacité de travail avec laquelle vous pourrez essayer de résoudre les conditions spécifiques de génération de trafic Unicast Flooding, lorsqu’elles se présentent. La supervision reste en suspens.

Une première approche de la supervision

Une première approche de la tâche de supervision des conditions qui peuvent générer un Trafic Unicast Flooding peut commencer par l’évaluation du comportement de la table d’adresses MAC.

Pour cela, vous pouvez utiliser Pandora FMS pour obtenir les informations des commutateurs, automatiser la revue que vous pourriez faire dans un premier temps manuellement puis utiliser les informations et toutes les fonctionnalités de visualisation pour faciliter votre analyse.

Vous pourriez alors suivre ces étapes :

Afficher la topologie réseau :

L’idée à ce stade est de réaliser une carte qui permette :

• Identifier les commutateurs qui composent la plate-forme (avec des variables telles que le nom, la marque, le modèle et le nombre de ports).
• Identifier les commutateurs gérables et ingérables, ainsi que ceux qui fonctionnent au niveau de la couche réseau et ceux qui fonctionnent uniquement au niveau de la couche liaison de données.
• Identifier les ports qui interconnectent les commutateurs et le schéma de configuration de ces ports (liens simples ou définis comme des jonctions ou autres).
• Établissez la distribution des périphériques de chaque VLAN sur les commutateurs.

Pour cela, utilisez les fonctionnalités offertes par Pandora FMS dans la rubrique Cartes réseau. Gardez à l’esprit que les cartes dans Pandora FMS peuvent être générées automatiquement, mais elles vous permettent également d’établir les informations que vous voulez qui soient présentes sur la carte, afin d’obtenir une carte de topologie à la fois physique et logique, qui est particulièrement utile pour le cas qui nous occupe.

Une fois la carte développée, peut-être pourrez-vous la rendre visible depuis le tableau de bord des responsables de la supervision réseau, ce qui n’est pas nécessaire pour le groupe de personnes plus orienté vers l’administration des applications, par exemple. Pour ce faire, utilisez les fonctionnalités de Pandora FMS qui vous permettent de définir des tableaux de bord personnalisés pour chaque utilisateur.

Évaluez la table d’adresses MAC :

Disons, par exemple, que vous voulez évaluer le nombre d’enregistrements utilisés et disponibles dans les tables d’adresses MAC de tous ou d’un groupe sélectionné de vos commutateurs réseau, afin d’identifier s’il y a une condition de débordement à tout moment ou des fluctuations aussi trop larges qui méritent d’être étudiées.

Pour automatiser la revue des tables, considérons comme exemple les commandes suivantes, extraites des commutateurs Cisco qui vous permettent d’évaluer la situation actuelle des tables d’adresses MAC :

• show mac address-table
  Il montre de manière générale les adresses MAC qui sont accessibles par chaque port et à quels VLAN appartiennent ces adresses.
• show mac address-table aging time
  Il affiche des informations sur la durée pendant laquelle les enregistrements restent sur la table.
• show mac address-table count
  Il affiche la capacité en termes de nombre d’enregistrements que contient la table. Il montre également le nombre d’enregistrements disponibles.

Gardez à l’esprit que l’application de ces commandes implique la connexion aux commutateurs via SSH, la présentation des identifiants et l’exécution de la commande en tant que telle.

Vous pourriez alors automatiser l’application de la commande show mac address-table count à des intervalles inférieurs à mac address age age time, en utilisant les fonctionnalités fournies par Pandora FMS pour automatiser ce type d’évaluations, ou la supervision basée sur SNMP si dans la MIB du commutateur en question affichera les variables requises.

Ensuite, ces informations de chaque commutateur seront enregistrées dans un fichier ou un graphique que vous pourrez évaluer plus tard, en identifiant si elles changent au fil du temps et si une table subit un débordement. Ici, vous pourrez évaluer la nécessité de générer une alarme sur cette condition.

De même, vous pourriez croiser ces données avec celles fournies par le schéma de supervision Pandora FMS sur des indicateurs de performance que vous mesurez déjà sur votre plateforme, et essayer de relier un comportement identifié dans la table d’adresses MAC avec des fluctuations d’indicateurs inacceptables, comme la latence dans un service ou une application, par exemple.

À partir de là, vous pourrez continuer à travailler sur l’analyse de ce type de trafic, en fonction de son existence sur votre plateforme et de ses effets sur les performances globales.

Enfin, nous espérons que cette première approche de la supervision d’une condition si évasive que Trafic Unicast Flooding vous motivera à considérer la supervision basée sur Pandora FMS comme un outil pour superviser cette condition d’erreur et d’autres.

Bien entendu, nous vous invitons à partager vos expériences avec le Trafic Unicast Flooding et à demander des informations sur les capacités de supervision réseau fournies par Pandora FMS en visitant ce lien.
(https://pandorafms.com/fr/supervision-reseau/)