Les paquets Ethernet ne mentent pas, du moins dans la plupart des cas.

Ils disent la vérité, sauf si leur enregistrement est erroné. Dans ces cas, les paquets peuvent effectivement contenir des mensonges flagrants.

Lors de l'analyse des fichiers de traces, nous pouvons découvrir dans les paquets des symptômes qui en surprendraient plus d'un. Il s'agit d'événements qui semblent étranges au premier abord et qui peuvent même perturber temporairement notre dépannage. Certains de ces problèmes ont en réalité induit en erreur… network Les analystes passent des heures, voire des jours, à rechercher des problèmes et des événements qui n'existent tout simplement pas sur le site. network.

La plupart de ces exemples peuvent être facilement évités en capturant les paquets à partir d'un network Effectuez le test du point d'accès (TAP) plutôt que sur la machine où le trafic est généré. Avec un network TAP, vous pouvez capturer le network Les données sont transmises de manière transparente et sans altération, permettant de voir ce qui est réellement transmis sur le réseau.

Dans la plupart des cas, la taille des paquets ne doit pas dépasser la taille maximale Ethernet de 1518 802 octets, ou la valeur spécifiée pour le MTU de la liaison. Cependant, cela n'est vrai que si nous n'utilisons pas de balises 1Q ou si nous sommes dans un environnement de trames jumbo.

Comment est-il possible que des paquets dépassent la taille maximale Ethernet ? En d'autres termes, nous les capturons avant qu'ils ne soient segmentés par la carte réseau. De nombreuses piles TCP/IP utilisent aujourd'hui le délestage de segmentation TCP, qui délègue la charge de segmentation des paquets à la carte réseau. Le pilote WinPcap ou Libpcap capture les paquets avant ce processus, de sorte que certains paquets peuvent sembler bien trop volumineux pour être légitimes.

Si la même activité était enregistrée sur le networkCes grands châssis seraient segmentés en plusieurs châssis plus petits pour le transport.

Temps zéro delta

Un delta de temps nul signifie qu'il n'y a pas de temps mesuré entre les paquets. Lorsque ces paquets entrent dans le dispositif de capture, ils reçoivent un horodatage et un delta de temps mesurable. L'horodatage d'entrée sur le dispositif de capture ne pouvait pas suivre le volume de paquets. En revanche, si ces paquets étaient capturés avec un serveur TAP externe, nous pourrions probablement obtenir un horodatage sans erreur.

Paquets précédents non capturés

Cet avertissement s'affiche car Wireshark a détecté une interruption dans le flux de données TCP. Grâce aux numéros séquencés, il peut déterminer qu'un paquet est manquant. Cela est parfois justifié par une perte de paquets en amont. Cependant, cela peut également indiquer que l'analyseur ou le SPAN a abandonné le paquet, car il n'a pas pu gérer la charge.

Après cet avertissement, vous devriez rechercher une série de paquets ACK dupliqués plutôt qu'un paquet défectueux. Cela indique qu'un paquet a effectivement été perdu et doit être retransmis. Si vous ne constatez aucune retransmission ni aucun paquet défectueux, l'analyseur ou le SPAN n'a probablement pas pu suivre le flux de données. Le paquet était en fait sur le networkmais nous ne l'avons pas vu.

Segments TCP ACK non remarqués

Dans ce cas, un accusé de réception s'affiche pour un paquet de données non détecté. Le paquet de données a peut-être emprunté un chemin différent, ou le périphérique de capture ne l'a tout simplement pas détecté.

J'ai récemment observé ces événements dans des fichiers de trace capturés par des commutateurs, des routeurs et des pare-feu. La capture du trafic étant moins prioritaire que le transfert (heureusement !), l'appareil peut simplement manquer certaines trames du flux de données. L'accusé de réception nous indique que le paquet est arrivé à destination.

Dans la plupart des cas, les emballages disent vrai. Ils peuvent nous mener à la cause profonde de notre problème. network et les problèmes d'application. Parce qu'elles présentent des données si claires et détaillées, il est très important de les enregistrer au plus près de la réalité. network Dans la mesure du possible. Cela signifie que nous devons les détecter pendant la transmission, et non sur le serveur lui-même. Cela nous permet d'éviter de perdre du temps avec des faux négatifs.

Si vous voulez en savoir plus sur network Considérations de visualisation pour les professionnels : téléchargez notre infographie gratuite, TAP vs SPAN.