C'est là où AFDX est rigolo. C'est d'un débit relativement faible (quelques Mb/s) mais ça suffit à mettre par terre la CPU de n'importe quel Cisco (2950, 2970, 3560, 3750....).

Ca a la couleur du multicast, l'odeur du multicast mais ça n'en n'est pas. Du coup l'ASIC ne sachant pas quoi en faire, il renvoie ça au CPU qui du coup explose.

storm-control ou ACL obligatoire si tu veux vivre.

Est-ce que ça ne s'arrête pas à la carte réseau de chaque équipement? Si j'ai bien compris ce que j'ai lu sur le sujet (je ne suis pas un expert), une carte réseau filtre les trames Ethernet reçues avant de les passer au processeur. Du coup, pour les trames ethernet multicast (je ne parle pas des broadcast), je pense qu'elle s'arrêtent probablement directement à la carte réseau, sans surcharger le processeur des PC ou de l'imprimante, vu qu'ils n'ont pas souscrits au multicast.

Voilà.

Mais au delà d'un certain nombre d'adresses multicast mises en écoute, la carte réseau ne filtre plus et envoie tout vers le processeur.

Et oui, je confirme que tu te trompes : une carte réseau "prends le temps" de lire toutes les adresses MAC de destination des trames reçues. Elle ne transmet au CPU que celles qui sont utiles.

Leon.

T'as rien compris à ce que j'ai dit et non, je ne me trompe pas, je connais très bien Ethernet, bien sur qu'une carte réseau lit toutes les trames, je n'ai jamais dit ou écrit le contraire.

Soit un flux multicast de 12Mb/s.

S'il n'est pas géré correctement par les switches, le flux est diffusé à tout le monde.

Soit une carte réseau de 10Mb -> elle sera complètement floodée, le lien 10Mb sera saturé par le multicast.

Soit une carte réseau de 100Mb -> sa bande passante Ethernet ne sera utilisée qu'à 12% mais elle perdra du temps à lire 12% de trames qui ne lui servent à rien. Une carte réseau n'est pas seulement limitée par une bande passante mais aussi par sa capacité à lire un certain nombre de trames par seconde. Le 12Mb/s peut s'avérer très gourmand en ressources s'il est composé de nombreux petits paquets. Dans le cas d'une imprimante, le controleur Ethernet n'est pas prévu pour gérer de tels flux. Par rapport au traitement CPU, ça dépend de l'OS, de mémoire Windows cherche à tout lire du fait de sa capacité à gérer de l'uPNP qui est en multicast.

En conséquence, un flux multicast non géré par des switches peut s'avérer catastrophique pour les machines d'un LAN. Le summum en la matière étant le protocole AFDX qui ressemble à s'y méprendre à du multicast Ethernet ce qui fait paniquer toute machine connectée.

C'est IGMP qui permet justement cela. Tant que personne ne s'en sert pour ce flux (ni la source ni le destinataire) les switches n'ont aucun moyen d'identifier quoi que ce soit -> ils broadcast le flux.

Eventuellement, vérifies sur tes switches s'il est possible de déclarer manuellement le flux/groupe.

EDIT: c'est quoi le modèle de tes switches?

Soit une carte réseau de 100Mb -> sa bande passante Ethernet ne sera utilisée qu'à 12% mais elle perdra du temps à lire 12% de trames qui ne lui servent à rien. Une carte réseau n'est pas seulement limitée par une bande passante mais aussi par sa capacité à lire un certain nombre de trames par seconde. Le 12Mb/s peut s'avérer très gourmand en ressources s'il est composé de nombreux petits paquets. Dans le cas d'une imprimante, le controleur Ethernet n'est pas prévu pour gérer de tels flux.

Pour le filtrage des trames ethernet par la carte réseau, je ne pense vraiment pas que ça consomme beaucoup de ressource, même pour les plus petits "devices" (imprimante). Regarder si une adresse MAC correspond, c'est très facile à faire, et les cartes réseau le font directement en hardware. Regarde n'importe quelle puce de switch Ethernet : elle est capable d'analyser les adresses Ethernet de tous les paquets qui lui arrivent sur tous ses ports, à 100Mb/s ou 1Gb/s, sans limitation de débit (y compris sur les petits paquets), même pour des puces bas de gamme qui ne coutent que quelques euros.

Je ferais des tests avec des petites cartes de développement que j'ai (ARM 9 et ARM Cortex M3) pour vérifier l'impact d'un flux multicast en entrée.

Leon.

Léon, tu ne peux pas comparer la puissance des ASIC embarqués dans des switches Ethernet avec un controleur Ethernet pour PC. Les capacités n'ont strictement rien à voir !

Un switch est capable de traiter en hardware des tonnes de fonctionnalités (QoS, 802.1q, ACL L2/L3, etc) que ton controleur n'a meme pas idée. Dans ton controleur, on va justement retrouver des fonctions pour soulager le CPU par des techniques d'offloading : checksumming, gestion des segments TCP etc.... Il n'en demeure pas moins que ça reste limité en capacité de gestion en nombre de paquets/s. On ne fait pas 1Gb/s avec des trames de 64 octets facilement. Tu n'as jamais remarqué qu'avec une carte 1Gb premier prix le débit est moins bon qu'avec une carte 1Gb haut-de-gamme ? Idem sur un switch.

Certes le 100Mb est aujourd'hui bien plus abordable mais il n'empeche qu'il existe des controleurs limités. Le but du multicast est de limiter sa diffusion uniquement aux abonnés pour éviter d'occuper de la bande passante et des ressources inutilement. Qu'un controleur soit capable de choisir l'information au CPU c'est pas mal mais les drivers ne sont pas tous aussi bien fait. J'ai déjà vu des Linux renvoyer des ICMP unreachable avec des flux mDNS envoyés par une application Windows écrite avec les pieds. Si tu commences à laisser tout le monde envoyer son quota de flux multicast pourri sur le réseau, bonjour la fete au bout d'un moment !