Retour au blog

Capture du trafic EtherNet/IP d’un Allen-Bradley 842E

Un flux de capture de paquets non intrusif pour un codeur Allen-Bradley 842E, couvrant le positionnement du port miroir, les classes de trafic EtherNet/IP, la temporisation RPI, les éléments de pre...

Un ordinateur portable connecté au même commutateur administrable qu’un codeur Allen-Bradley 842E ne verra pas automatiquement le trafic cyclique du codeur. Un commutateur achemine normalement les trames monodiffusion uniquement vers le port de destination. L’analyseur peut donc n’afficher presque rien alors que l’automate signale un délai d’expiration des E/S.

Capture de paquets sur un commutateur administrable pour un codeur Allen-Bradley 842E

Une capture utile commence par une hypothèse de panne vérifiable et un point de capture capable d’observer les trames pertinentes.

Définir la question avant de collecter les paquets

Décrivez le symptôme en termes mesurables. Il peut s’agir d’un délai d’expiration de la connexion lors d’une transition précise de la machine, d’une valeur de codeur qui cesse de changer, de reconnexions répétées ou de données de position qui arrivent plus tard que prévu par l’automate. Notez le code de défaut de l’automate, l’heure, les voyants du codeur et l’état du port du commutateur.

Déterminez quelles observations confirmeraient ou réfuteraient chaque hypothèse. Si la question est de savoir si les trames quittent le codeur, mettez en miroir le port connecté au codeur. S’il s’agit de vérifier qu’elles atteignent la liaison montante de l’automate, observez cette liaison. Une capture effectuée d’un seul côté d’un commutateur intermédiaire ne permet pas toujours de localiser la perte.

Le matériel pour codeurs peut être consulté dans la collection Capteurs, tandis que les commutateurs administrables et les adaptateurs réseau sont regroupés sous Communication et réseaux.

Comprendre le chemin réseau du 842E

Rockwell Automation décrit le 842E comme une famille de codeurs absolus EtherNet/IP dotés de deux ports Ethernet pour les topologies linéaires et en anneau de niveau appareil prises en charge. Le catalogue exact et la configuration du projet déterminent la connexion de données, l’assemblage, l’intervalle de paquets demandé et le comportement de diagnostic.

Documentez les deux ports physiques, les paramètres IP, la connexion à l’automate, la topologie, le micrologiciel et l’activation éventuelle de l’anneau de niveau appareil. Dans une topologie linéaire, un câble ou un appareil en aval peut affecter le trafic traversant le codeur. Dans un anneau, un événement de topologie fournit un élément supplémentaire à corréler avec le défaut de connexion.

Ne supposez pas que le port le plus proche de l’automate est toujours le seul point de capture utile. Dessinez le chemin réel, y compris les ports du commutateur, les liaisons montantes, le superviseur d’anneau, les convertisseurs de support et les éventuelles routes redondantes.

Sélectionner une méthode de capture non intrusive

Une session de mise en miroir sur un commutateur administrable est généralement la méthode la moins perturbatrice. Configurez comme source le port du codeur, celui de l’automate ou la liaison montante requise par l’hypothèse. Définissez le port connecté à l’analyseur comme destination et vérifiez si le commutateur met en miroir le trafic entrant, sortant ou les deux.

Un point d’accès réseau passif spécialement conçu à cet effet constitue une autre option lorsque l’architecture et la procédure d’arrêt le permettent. N’insérez pas un commutateur non administrable ni un concentrateur de bureau ordinaire dans un chemin de commande en fonctionnement. Cette modification peut changer la topologie, la qualité de service, la gestion de la multidiffusion, la négociation de liaison et la chronologie des défauts.

Utilisez une interface dédiée pour l’analyseur. Désactivez les protocoles et services inutiles lorsque la procédure d’exploitation l’autorise. L’analyseur doit observer, et non annoncer des appareils, demander des adresses ou devenir un autre participant du réseau de commande.

Vérifier que la mise en miroir dit vrai

Générez ou identifiez une trame connue et vérifiez qu’elle apparaît sur l’analyseur. Assurez-vous que les deux directions sont visibles lorsque cela est nécessaire. Une session de mise en miroir peut exclure les erreurs de la couche physique, perdre des paquets lorsque le port de destination est saturé ou ne copier qu’une seule direction.

Comparez le débit du port source à la capacité de la destination de mise en miroir. Mettre en miroir les deux directions d’une liaison montante occupée à 1 Gbit/s vers un port à 1 Gbit/s peut dépasser la bande passante de destination. Réduisez la source ou la durée de capture au lieu de supposer que chaque interruption s’est produite sur le réseau de commande.

Notez le modèle du commutateur, son micrologiciel, la configuration de mise en miroir, le port source, le port de destination, le comportement du VLAN et les paramètres de l’interface de capture. Sans ces informations, un autre ingénieur ne pourra pas reproduire la mesure.

Différencier les classes de trafic EtherNet/IP

EtherNet/IP utilise la messagerie explicite pour la gestion des connexions, la configuration et les diagnostics, tandis que les E/S cycliques utilisent généralement le transport UDP. Les échanges de découverte ne prouvent pas qu’une connexion d’E/S établie est saine. Conservez les phases d’établissement et de fermeture de la connexion autour du défaut, et pas uniquement les paquets cycliques.

Commencez par les adresses IP connues du codeur et de l’automate. Identifiez ensuite la connexion concernée au lieu d’étiqueter chaque trame UDP comme une donnée de codeur. Les ports EtherNet/IP courants peuvent aider à réduire le périmètre de la trace, mais les points d’extrémité, la chronologie et le contexte de connexion fournissent des preuves plus solides.

Conservez les éléments relatifs à ARP, à la topologie et à la gestion du commutateur autour de l’événement. Un conflit d’adresses ou une transition de liaison peut apparaître en dehors du flux d’E/S filtré. Enregistrez la capture non filtrée et utilisez des filtres d’affichage pour l’analyse afin de ne pas supprimer définitivement le contexte.

Analyser la temporisation et les interruptions du RPI

L’intervalle de paquets demandé définit la cadence de mise à jour attendue pour la connexion d’E/S configurée. Mesurez le temps entre les arrivées sur une période saine et autour du défaut. Recherchez les intervalles manquants, les rafales après une pause, les comportements de séquence dupliquée ainsi qu’une fermeture ou une réouverture de connexion.

Ne considérez pas chaque paquet arrivant après le RPI nominal comme un défaut de l’automate. Comparez l’interruption observée au comportement de délai d’expiration de la connexion configuré dans l’automate. Une variation de quelques microsecondes et une interruption de plusieurs intervalles n’ont pas la même signification.

Représentez graphiquement l’heure d’arrivée des paquets à côté du bit de défaut de l’automate, de l’état de la tâche, de l’événement machine et des journaux du commutateur. Si le flux de paquets s’arrête avant l’apparition d’un événement de liaison interrompue, le dispositif source ou le chemin en amont mérite une attention particulière. Si la mise en miroir continue de voir les trames du codeur alors que l’automate arrive à expiration, examinez le reste du chemin et le traitement par l’automate.

Utiliser les informations du commutateur avec la trace

Lisez les compteurs de port avant et après le test. Les erreurs CRC ou de contrôle de trame, les transitions de liaison, les paquets abandonnés, les changements de débit et les événements d’anneau peuvent expliquer une interruption de paquets. Un analyseur connecté au-dessus de la liaison défaillante peut ne jamais recevoir les trames corrompues, car le commutateur les élimine.

Vérifiez l’état des câbles et des connecteurs, les pratiques de blindage et de mise à la terre, le rayon de courbure, la contamination et la traction. Ne remplacez qu’un seul composant contrôlé à la fois, après avoir préservé la référence. Remplacer plusieurs câbles et réglages de commutateur simultanément empêche d’identifier la cause.

Confirmez le débit et le duplex négociés conformément à la configuration prise en charge par l’appareil. Évitez de forcer ces paramètres sans consulter les manuels du codeur et du commutateur. Une incompatibilité peut générer des erreurs qui semblent dépendre de la charge.

Protéger la capture et le réseau

Limitez la durée de capture ou utilisez un tampon circulaire afin d’éviter que le disque de l’analyseur ne se remplisse. Notez précisément l’heure locale et l’heure de l’installation. Les traces de paquets peuvent révéler des adresses, des noms d’appareils, des configurations et le comportement du procédé ; stockez-les avec des contrôles d’accès appropriés.

Supprimez la configuration de mise en miroir après le test et vérifiez que le port de destination revient à son état prévu. Une mise en miroir laissée en place peut exposer le trafic de commande à un appareil non autorisé ou consommer des ressources du commutateur.

Ne modifiez jamais la configuration en vous fondant uniquement sur une trace de paquets. Corrélez les éléments avec les diagnostics de l’automate, les voyants du codeur, les compteurs du commutateur et un événement machine reproductible. La capture enregistre le trafic ; elle ne certifie pas la position mécanique et ne prouve pas que le codeur lui-même est précis.

Transformer les observations en conclusion de panne

Les trames s’arrêtent aux deux points de capture

Examinez l’alimentation du codeur, son état interne, la connexion au programme en amont ou la liaison commune avant le premier point de capture. Vérifiez si l’appareil redémarre ou si la connexion est volontairement inhibée.

Les trames apparaissent au niveau du codeur, mais pas sur la liaison montante

Concentrez-vous sur le chemin du commutateur intermédiaire, le VLAN, l’événement d’anneau, les erreurs de port, la congestion ou le câblage. Répétez le test avec des compteurs synchronisés avant de remplacer le codeur.

Les trames atteignent le chemin de l’automate, mais l’automate arrive à expiration

Examinez la connexion configurée, le RPI, le délai d’expiration, la charge des tâches de l’automate, les adresses en double et vérifiez que les paquets capturés appartiennent à la connexion attendue.

La capture de paquets devient précieuse lorsque le positionnement, la chronologie et le contexte réseau de la capture sont maîtrisés. L’objectif n’est pas d’obtenir un volumineux fichier Wireshark, mais un ensemble réduit de preuves montrant où l’échange cyclique a changé et quel événement physique ou de configuration a changé en même temps.

Laisser un commentaire

Veuillez noter que les commentaires doivent être approuvés avant d'être publiés.