Optimisation des réseaux en corrigeant les erreurs générant une diffusion inutile
L’optimisation du réseau utilise la surveillance du trafic sur la plate-forme comme un moyen facile d’identifier les problèmes de performances et, dans le meilleur des cas, de les résoudre. Lorsque nous surveillons un segment de réseau, nous pouvons observer le trafic Unicast, en tant que trafic Broadcast et Multicast, constituant généralement le nombre de paquets Unicast qui deviennent un élément essentiel de l’analyse.
Cependant, nous sommes conscients que la présence de trafic Broadcast et Multicast implique un risque pour la performance globale du réseau. La génération d’une quantité excessive de ce type de packages peut même entraîner l’effondrement total de la plate-forme. Nous devons donc accorder une attention particulière. Dans cet article, nous allons être très attentifs au trafic Broadcast et Multicast, qui, sans devenir excessifs, peuvent détériorer les performances globales d’une plate-forme IPv4.
Nous nous référons au trafic Broadcast et Multicast “inutile”, c’est-à-dire celui qui est présent sur une plate-forme en raison de défaillances dans la configuration et dans l’administration des périphériques qui la composent.
L’effet de ce trafic ne doit pas être évalué par le nombre total de packages, mais par l’effet que ces packages ont et pourraient avoir à l’avenir sur les performances globales de la plate-forme.
N’oubliez pas que chaque paquet Broadcast en particulier, implique que tous les commutateurs du segment de réseau en feront une copie et le placeront dans chacun de ses ports. De plus, chaque appareil doit exécuter une interruption d’entrée / sortie pour l’analyser.
Si nous partons du fait que le package est inutile, tout le processus précédent sera effectué afin que les périphériques finissent par le rejeter. Nous en arrivons ainsi à notre proposition qui consiste à mettre en place une stratégie d’optimisation du réseau basée sur :
- Surveiller chaque segment de réseau.
- Analyser le trafic Broadcast et Multicast en partant du principe que tout ce trafic doit être justifié.
- Identifiez l’échec de la configuration qui est la source du trafic inutile Broadcast et Multicast.
- Appliquer les activités de support technique nécessaires dans le but d’éliminer ou de minimiser leurs effets.
Que devrions-nous rechercher ? En principe, nous devons nous concentrer sur le trafic Broadcast et Multicast récurrent, quel que soit le volume global de ces packages ou tout autre aléatoire, il représente par son volume, un risque pour l’intégrité de la plate-forme.
Vous trouverez ci-dessous une liste des problèmes que nous pouvons identifier et corriger lors de l’analyse du trafic inutile Broadcast et Multicast :
Problèmes liés au schéma de résolution de noms
Lorsqu’un périphérique doit résoudre le nom d’une ressource, il s’appuie sur ses serveurs DNS domain name server), mais si le nom n’est pas résolu, le périphérique peut générer une rafale récurrente de trafic Broadcast inutile dans l’espoir que le nom soit reconnu par un autre appareil du réseau.
Ceci étant le cas, lorsque nous analysons le trafic Broadcast et Multicast d’un segment de réseau, nous pouvons identifier les périphériques qui recherchent de manière récurrente une ressource et ne reçoivent pas de réponse, et appliquons les actions de support technique pour éliminer la référence à la ressource. L’exemple typique de ce cas est celui des stations de travail qui tentent de résoudre le nom d’un serveur qui n’existe plus dans le réseau.
Erreurs dans la configuration du périphérique plug and play
Les périphériques plug and play ont généralement un grand nombre de protocoles installés, le problème se produit lorsque ces protocoles sont dans l’état “actif” par défaut. Cette situation peut entraîner une rafale récurrente de trafic Broadcast ou Multicast sur le segment de réseau.
L’exemple typique est l’installation d’imprimantes dans des segments IP, car le protocole IPX / SPX est configuré et activé pour les imprimantes. Ainsi, lors de la surveillance, ce qui est visualisé est une rafale constante de trafic Broadcast IPX inutile.
Erreurs de configuration de la station
En général, les administrateurs réseau gèrent les normes régissant la manière dont les postes de travail doivent être installés : quel système d’exploitation ils doivent utiliser, quels protocoles et quels services doivent être configurés. Mais si, par inadvertance ou par l’exécution d’un test, un protocole inutile reste configuré, nous le verrons sûrement lors de la surveillance d’une séquence de trafic de Broadcast ou Multicast non nécessaire associé audit protocole.
Outils de gestion de réseau inutilisés
De nombreux fabricants d’équipements de réseau, tels que les commutateurs, les routeurs et les serveurs, incluent parmi leur arsenal d’outils des produits permettant d’administrer ces périphériques.
Ces outils peuvent fonctionner si chaque périphérique génère un paquet Broadcast ou Multicast, de sorte que l’outil d’administration prenne en charge sa présence. Le fait est que, si nous n’avons aucun outil qui gère ce type de périphérique, nous n’avons pas besoin de trafic inutile.
Problèmes avec les tables mac-adress
Si, lors de l’analyse du trafic Broadcast et Multicast, nous rencontrons du trafic Unicast, nous pouvons être en présence d’un flux de trafic de diffusion appelé Unicast Flooding.
Le trafic Unicast Flooding fait référence au trafic acheminé entre deux périphériques qui est converti en trafic Broadcast par les commutateurs. Situation susceptible de se produire pour plusieurs raisons, mais cela est régulièrement dû à la taille insuffisante des tables tables mac-adress afin de gérer le volume de trafic transitant par le commutateur.
Le trafic Unicast Flooding est un comportement normal, en particulier lorsque les commutateurs sont en phase d’apprentissage, mais une quantité excessive de ce type de trafic peut nuire considérablement aux performances globales de la plate-forme, notamment en raison de son caractère aléatoire.
Des fabricants tels que Cisco ont développé des procédures et des commandes pour contenir le trafic Unicast Flooding. Cependant, il peut être intéressant d’évaluer également la corrélation entre les capacités des tables et la taille des segments de réseau en termes de volume de trafic.
En conclusion, l’optimisation de la plate-forme peut et doit être enrichie par la surveillance des segments de réseau, l’analyse du trafic inutile Broascast et Multicast et la réalisation d’activités techniques destinées à l’éliminer ou à en minimiser les effets.
À propos de Pandora FMS
Pandora FMS est un logiciel de supervision flexible, capable de surveiller des appareils, des infrastructures, des applications, des services et des processus d’entreprise.
Voulez-vous savoir ce que Pandora FMS peut vous offrir ? Pour en savoir plus, cliquez ici.
Ou si vous avez à surveiller plus de 100 appareils, vous pouvez également profiter d’un ESSAI GRATUITE de 30 jours de Pandora FMS Enterprise. Obtenez-le ici.
Par ailleurs, n’oubliez pas que si vos besoins en matière de supervision sont plus limités, vous avez à votre disposition la version OpenSource de Pandora FMS. Pour plus d’informations, cliquez ici.
N’hésitez pas à envoyer vos questions, l’équipe de Pandora FMS se fera un plaisir de vous aider !
L’équipe éditoriale de Pandora FMS est composée d’un groupe de rédacteurs et de professionnels de l’informatique ayant un point commun : leur passion pour la surveillance des systèmes informatiques. L’équipe éditoriale de Pandora FMS est composée d’un groupe de rédacteurs et de professionnels de l’informatique ayant un point commun : leur passion pour la surveillance des systèmes informatiques.
