Souvent, lorsque je travaille sur un problème, je demande aux gens de m'envoyer une trace du réseau. Une trace réseau permet souvent de remonter à la source du problème. Au minimum, elle réduit l'espace du problème à quelque chose qui est gérable. Par exemple, lorsqu'une imprimante réseau a commencé à imprimer des déchets, nous avons passé plusieurs jours à examiner les TTP ; lorsque nous avons finalement obtenu une trace réseau, nous avons découvert que nous envoyions du texte parfaitement correct ; le problème se situait au niveau de l'imprimante. Dans un autre cas, un problème de performance OSL entre des modules distants de plusieurs milliers de kilomètres semblait être un problème de réseau, mais une trace montrait clairement que le problème se situait au niveau du module serveur. Je travaillerais encore sur ces deux problèmes si ce n'était pas de la trace réseau.
Comment obtenir une trace du réseau ? Il y a trois possibilités.
packet_monitor
La commande VOS packet_monitor, avec certaines limitations, vous permet de surveiller tout ce que le module envoie et reçoit du réseau. Voir http://community.stratus. com/blog/openvos/getting-most-out-packetmonitor et http://stratadoc.stratus.com/vos/17.0.1/r419-09/wwhelp/wwhimpl/js/html/wwhelp.htm?context=r419-09&file=ch9r419-09i.html pour plus d'informations.
La commande packet_monitor a plusieurs limites. Vous ne pouvez pas être certain à 100% qu'une trame qui est signalée comme envoyée a bien été envoyée. Par exemple, des erreurs sur l'adaptateur peuvent empêcher l'envoi de la trame. De plus, les trames reçues avec des erreurs, comme une erreur CRC, ne seront pas envoyées en amont pour que packet_monitor puisse les voir. Comme packet_monitor ne place pas l'adaptateur en mode de promiscuité, seules les trames adressées à l'adaptateur ou l'adresse de diffusion lui seront transmises en amont. Un lien peut être occupé à 90% alors que packet_monitor ne signale qu'une trame par seconde car c'est la seule trame qui est adressée à l'adaptateur ou à l'adresse de diffusion.
En général, les moniteurs basés sur l'hôte, tels que packet_monitor, ne sont utiles qu'en complément d'autres formes de traçage, ou lorsqu'aucune autre forme de traçage réseau n'est disponible.
Port Mirroring alias SPAN (Switch Port for ANalysis)
Un port miroir ou de travée est un port sur un commutateur qui reproduit tout le trafic vu sur un ou plusieurs ports (ou même sur un VLAN) du commutateur. Le port miroir doit être connecté à un appareil de surveillance du réseau. Cet appareil peut être un dispositif spécial ou un PC fonctionnant sous Linux ou Microsoft Windows avec un moniteur hôte tel que Wireshark(http://www.wireshark.org/) ou tcpdump. Les ports miroirs sont faciles à mettre en place, il suffit de taper quelques commandes au niveau du commutateur.
Malheureusement, l'utilisation d'un port miroir présente plusieurs inconvénients majeurs. Tout d'abord, le port doit être correctement configuré. Des ports mal configurés peuvent conduire à des trames manquantes ou dupliquées dans la trace du réseau. Deuxièmement, les commutateurs ne répliqueront pas une trame présentant un type d'erreur quelconque, de sorte que ces trames ne seront pas tracées. Troisièmement, un commutateur occupé peut laisser tomber des trames au lieu de les répliquer sur le port miroir. Quatrièmement, un port miroir qui accepte des trames provenant d'un VLAN entier, ou de plusieurs ports de commutateur, ou même d'un seul port duplex intégral, peut être surchargé et donc laisser tomber certaines trames. Cinquièmement, les erreurs introduites entre le commutateur et l'hôte ne peuvent pas être vues par l'application de surveillance du réseau connectée à un port de commutateur complètement différent. De même, les erreurs introduites entre le port miroir et l'application réseau donneront à l'application réseau une vue déformée de ce que l'hôte reçoit réellement du commutateur.
Les prises de réseau
Les robinets sont des dispositifs passifs qui se connectent entre le commutateur et l'hôte ; ils se branchent littéralement sur la connexion réseau. Comme un port miroir, ils doivent être connectés à une appliance réseau, mais ils présentent moins d'inconvénients qu'un port miroir.
Premièrement, il n'y a généralement pas de configuration ; il suffit de le brancher et il fonctionne. Deuxièmement, les prises les plus avancées ne dépendent de l'alimentation que pour répliquer les trames vers le port de surveillance. et disposent d'une double alimentation pour garantir la fiabilité de l'activité de réplication. En cas de panne de courant, ces prises continueront à transmettre les trames entre les ports du réseau ; seule la réplication s'arrête. Troisièmement, une prise n'a qu'une seule fonction, qui est de répliquer et de transférer les trames vers l'application de surveillance du réseau. Une prise a beaucoup moins de chances d'être submergée par un volume de trafic élevé. En outre, les points d'agrégation disposent d'un espace tampon qui leur permet de transférer de gros volumes de trafic sur une liaison en duplex intégral sans perte de trames. Bien entendu, un débit élevé et soutenu peut toujours submerger la mémoire tampon. Les prises d'agrégation vous permettent également de combiner plusieurs entrées. Par exemple, un dispositif à deux ports vous permettra de surveiller à la fois les adaptateurs actifs et de veille d'une paire d'adaptateurs duplex. Cela garantit une surveillance continue, même en cas de panne d'un adaptateur. Enfin, en connectant le robinet à l'adaptateur hôte, vous avez la meilleure assurance possible que l'application de surveillance du réseau verra toutes les trames quittant l'adaptateur hôte et toutes les trames arrivant du commutateur à l'adaptateur hôte.
L'un des inconvénients que partagent de nombreux robinets avec un port miroir est qu'ils laissent tomber les images endommagées. Étant donné que de nombreux appareils de surveillance de réseau, en particulier ceux qui ne sont que des PC équipés de matériel Ethernet standard, laissent également tomber les images endommagées, les fabricants de prises ne considèrent pas cela comme un défaut critique.
Pour plus d'informations sur les robinets ou les ports de commutation, consultez les sites http://www.lovemytool.com/blog/2007/08/span-ports-or-t.html ou http://taosecurity.blogspot.com/2009/01/why-network-taps.htm l ou tapez "network taps and span ports" dans votre moteur de recherche préféré.
Les défis de la surveillance
Le premier défi est de savoir quand et pendant combien de temps il faut surveiller. Idéalement, les liens critiques du réseau dans un système de production devraient être surveillés en permanence. Il est beaucoup plus rapide de détecter un problème dès sa première apparition et d'avoir une trace du réseau en main que de rencontrer un problème, de mettre en place une surveillance et d'essayer de le reproduire ou d'attendre qu'il se reproduise. Les fichiers de trace peuvent être volumineux ; une charge de 50% sur un lien gigabit produit environ 62,5 mégaoctets par seconde ou 3,75 gigaoctets par minute. Les fichiers de trace ne doivent pas être conservés plus longtemps que votre temps de réponse dans le pire des cas. Si vous pouvez répondre à un problème signalé en une heure, vous n'avez besoin de conserver qu'une heure de données de trace. Plus vous conservez de données de suivi, plus vous avez de marge de manœuvre pour réagir ou pour reconnaître qu'il y a eu un problème qui doit faire l'objet d'une enquête. Les gros disques sont assez peu coûteux, du moins par rapport au coût d'une interruption, alors envisagez d'acheter un ou plusieurs disques durs de la taille d'un téraoctet pour conserver les données de suivi.
Il peut être difficile de maintenir ce niveau de surveillance lorsqu'on utilise un port de portée. Dans un réseau complexe, les administrateurs de réseau sont entraînés dans de nombreuses directions et il peut être difficile de maintenir un port de portée et une surveillance continue au cas où quelque chose tournerait mal.
D'autre part, un robinet réseau installé à côté de l'hôte est dédié à cet hôte. Vous pouvez acheter un appareil de surveillance réseau sophistiqué, ou vous pouvez commencer en utilisant un PC de base avec un disque dur de 1 téraoctet fonctionnant sous Linux ou Windows et en exécutant le programme tshark (l'interface non-GUI de wireshark). Cette configuration vous donnera 266 minutes de données de trace (en supposant un débit de 500 mbps) et est parfaitement adaptée à la plupart des besoins. Vous pouvez acheter un disque de 1 téraoctet pour moins de 100 $ si vous faites le tour du marché.
La santé du réseau sous-jacent est essentielle pour que l'application soit disponible en permanence. Faites l'effort de capturer une trace précise de l'activité du réseau sur une base régulière. Lorsque des problèmes surgissent, vous pourrez les résoudre rapidement sans attendre qu'ils se reproduisent. En prime, vous pouvez également analyser les données de trace et apprendre des choses sur votre réseau qui étaient cachées auparavant.