Si j'envoie du trafic de l'hôte A vers B par un commutateur, l'activation d'un port miroir / SPAN augmentera-t-elle le temps nécessaire à mes trames pour passer de A à B?
Nb: Je ne m'inquiète pas du temps qu'il faut à la trame en miroir pour atteindre mon hôte de surveillance. Je me demande simplement si cela affectera les performances du réseau dans un environnement à temps critique.
Quelqu'un a-t-il testé cela? (J'accueillerais également tous les liens vers un article / article à ce sujet)
Réponses:
En règle générale, selon Cisco, «L'impact sur la structure de commutation haute vitesse est négligeable».
Cela dépend bien sûr de votre commutateur, de sa structure et de la charge sur le commutateur lui-même. Le port auquel les données copiées sont envoyées peut cependant supprimer des paquets s'il est trop souscrit. Personnellement, je n'ai jamais subi de préjudice en utilisant la mise en miroir ou SPAN.
Voici un document de Cisco directement sur le sujet sur certaines de leurs lignes de chat: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41. html # anc48
la source
Il est possible d'affecter les sources (c'est-à-dire les ports surveillés) si le trafic global dépasse la capacité de la destination (c'est-à-dire le port de surveillance). Je n'ai pas la référence à laquelle je pensais au départ, mais en voici une autre: la contre- pression d'un port SPAN .
Imaginez donc que vous ayez un serveur sur un port de dix gig que vous souhaitez SPAN vers un périphérique de capture de paquets (ou IDS / IPS, etc.). Le dispositif de surveillance est également sur une interface de dix gig.
N'oubliez pas que lorsque vous configurez un SPAN, vous avez la possibilité de transmettre SPANning (hors de l'interface du commutateur vers le serveur), ou de recevoir (du serveur vers le commutateur), ou les deux. Normalement, nous voudrions voir les deux côtés d'une conversation, nous choisissons donc de SPAN à la fois la transmission et la réception.
Imaginez maintenant que le serveur est très occupé et que les flux de transmission et de réception soient assez pleins, constamment supérieurs à 5 gig dans chaque direction.
Vous souhaitez maintenant envoyer DEUX flux supérieurs à 5 gig au périphérique de surveillance via le port de destination SPAN. Le trafic total envoyé vers la destination SPAN est supérieur à 10 gig. Mais, cette interface est UNIQUEMENT 10 Gigabits vers le dispositif de surveillance. Que se passe-t-il alors? Je me souviens que les documents de Cisco ont dit qu'au départ, les paquets seraient déposés du tampon de transmission de l'interface vers le dispositif de surveillance (c'est-à-dire le tampon de transmission de destination SPAN). Cependant, dans le cas de flux de trafic soutenus de longue durée, la capacité du commutateur à supprimer le trafic en excès du tampon de transmission sera finalement épuisée (ce qui ne me semble pas, et ne le faisait pas à l'époque), et alors le commutateur commencera à utiliser d'autres mécanismes pour diminuer le débit, y compris la «contre-pression» en utilisant 802.
Et vous avez désormais un impact sur votre trafic source. De mauvaises choses arrivent.
Ce problème est / était particulièrement important pour un grand réseau à très haut débit et à faible latence, qui avait de nombreuses sources pour le SPAN. Ce qui a été une considération majeure et a entraîné le remplacement de l'utilisation des sessions SPAN ayant de nombreuses sources pour les TAPS optiques, l'alimentation des commutateurs d'agrégation avec des ACL entrantes (filtrage pour le trafic intéressant), puis la liaison de ce trafic entrant à plusieurs consommateurs de paquets spécialisés de 10 Gigabits (pour les données besoins d'archivage et d'analyse).
Morale de l'histoire: si vous avez l'intention d'utiliser de nombreuses sources SPAN, assurez-vous que la bande passante globale des DEUX tx et rx est inférieure à la bande passante de votre périphérique de capture.
Voici un traité décent sur l'utilisation des ports SPAN
la source