4 votes

Pourquoi le multicasting rend-il le WAN inaccessible ?

Je suis hésitant à poser cette question car je pourrais ne pas être en mesure d'effectuer les étapes de diagnostic pour savoir ce qui se passe, mais :

J'ai besoin de réimager un laboratoire dans une école, éventuellement pendant les heures de classe. J'utilise un flux multicast car il n'a guère de sens pour le serveur de partager un fichier 30 fois. J'ajuste la vitesse très basse pour qu'il y ait de la marge de manœuvre et le reste du réseau ne devrait pas être trop affecté.

Ce que j'ai constaté, c'est qu'en faisant cela, nous semblons être coupés du WAN. D'autres sites ne sont pas accessibles, tout comme internet. L'école n'est pas visible depuis d'autres endroits pendant la restauration multicast. (La diffusion en mode multipoint fonctionne correctement).

J'ai parlé à mon collègue qui est en charge du réseau lorsque cela s'est produit sur un autre site, et il n'a pas été en mesure de trouver ce que nous faisions qui pourrait causer des problèmes.

Détails : Je réalise une restauration multicast ASR en utilisant DeployStudio sur un serveur Mac OS X. La plupart de nos commutateurs sont des équipements Cisco. Nous avons un certain nombre de points d'accès sans fil (et ils semblent transmettre le flux multicast en sans fil; pas optimal, mais pas forcément un problème.) J'ai mis le flux à un débit de 2 Mb/s (je pense que ce sont des mégabits, pas des octets); les systèmes sont restaurés correctement à 8 et parfois même à 12 Mb/s (donc je sais qu'il y a de la marge de manœuvre).

Il est de préférence de faire du streaming multicast sur un réseau physiquement séparé de celui en production, ou de le faire pendant l'été lorsque peu de membres du personnel sont présents, mais je n'ai pas cette chance ici.

Qu'est-ce qui pourrait expliquer ce problème ?

4voto

radius Points 9485

Le problème est probablement que votre commutateur ne gère pas correctement les groupes multicast et envoie ensuite des multicast comme des diffusions (et ainsi submerge votre lien WAN, ou du moins le routeur WAN) avec des données inutiles).
Vous devez donc avoir au moins un commutateur agissant en tant que requêteur IGMP, cela peut être activé sur les Cisco 2960 et 3750 avec la commande ip igmp snooping querier. Si votre réseau ne comporte que des 2950, vous rencontrerez définitivement des problèmes.
Vous pouvez facilement voir si vos commutateurs diffusent le multicast en exécutant WireShark sur un PC pendant que vous réinstallez l'image sur d'autres ordinateurs. (vous ne devriez pas voir les données multicast si tout fonctionne correctement)

Veuillez également nous indiquer quelle adresse IP multicast est utilisée, certaines sont réservées et ne doivent pas être utilisées, certaines peuvent être routées et d'autres ne sont pas routables (voir http://iana.org/assignments/multicast-addresses/multicast-addresses.xml)

1voto

Bart Silverstrim Points 31022

Inonder le routeur qui gère l'accès à votre passerelle, peut-être?

Y a-t-il un moyen d'obtenir des informations SNMP à partir du routeur ou d'obtenir des informations de journalisation à partir de celui-ci, état du CPU, etc.?

1voto

joeqwerty Points 106914

À quelle vitesse est la connexion WAN ? En fonction de l'adresse de multidiffusion utilisée, il se pourrait que le trafic de multidiffusion sature l'interface WAN, par exemple l'adresse de multidiffusion 224.0.0.1 signifie "tous les hôtes de ce sous-réseau", ce qui signifie que l'interface WAN doit écouter puis rejeter le trafic de multidiffusion.

Si l'interface WAN doit écouter puis rejeter le trafic de multidiffusion, et que le trafic de multidiffusion circule à une vitesse de 8 à 12 Mbps, et que le lien WAN est inférieur à 8 à 12 Mbps, alors je pourrais voir cela comme la cause du problème.

1voto

Ma supposition serait que ce n'est pas un problème de WAN en soi, mais que l'interface côté LAN de votre routeur est submergée par des trames multicast inondées par votre commutateur.

Comme cela a été mentionné dans un autre commentaire, vous devrez activer le snooping IGMP pour permettre à votre commutateur de limiter correctement les trames multicast. Vous devrez probablement également activer le questeur IGMP snooping, à moins que vous n'ayez un routeur multicast (PIM) sur chacune de vos VLAN. Sur un commutateur Cisco, vous pouvez activer le snooping IGMP et le questeur snooping en saisissant les deux commandes suivantes en mode de configuration globale :

ip igmp snooping
ip igmp snooping querier

Vous devez vous assurer que le snooping igmp est activé sur chaque commutateur de votre réseau. Le questeur de snooping n'a besoin d'être activé que sur un commutateur, à condition que ce commutateur ait une IP dans chacune de vos VLAN. À ma connaissance, cela ne nuira pas d'activer également le questeur de snooping sur chaque commutateur. Notez que pour que le questeur de snooping fonctionne, votre commutateur aura besoin d'une IP dans chacune de vos VLAN, ou du moins dans chaque VLAN où vous souhaitez limiter le trafic multicast qui vous préoccupe.

Si vous vous demandez pourquoi vous avez besoin du snooping IGMP :

Comme vous le savez probablement, normalement un commutateur délivre le trafic en consultant sa table CAM. La table CAM est remplie en inspectant l'adresse MAC source de chaque trame reçue par le commutateur. Chaque adresse MAC source que voit le commutateur est ajoutée à la table CAM, avec le port de commutateur par lequel la trame en question est entrée dans le commutateur. De cette manière, le commutateur "apprend" quelles adresses MAC sont connectées à chaque port.

Le commutateur utilise la table CAM pour déterminer où délivrer les trames entrantes. Si l'adresse MAC de destination est trouvée dans la table CAM, le commutateur sait à quel port délivrer la trame, et la trame est délivrée uniquement à ce port. Si l'adresse MAC de destination n'est PAS trouvée dans la table CAM, la trame est inondée sur chaque port du commutateur.

Avec le trafic multicast, l'adresse MAC source de la trame sera l'adresse MAC de l'émetteur multicast, mais l'adresse MAC de destination de la trame sera l'adresse MAC d'un groupe multicast, pas l'adresse MAC d'un PC particulier. Cette adresse MAC multicast ne devrait jamais normalement être l'adresse source d'une trame, donc en opération normale, le commutateur ne saura pas où envoyer les trames multicast. Il n'aura pas le choix que d'inonder les trames sur chaque port. Lorsque cela se produit avec un flux multicast vraiment important, ces trames inondées peuvent parfois submerger d'autres systèmes sur le réseau.

IGMP est en fait un protocole de couche 3 conçu pour permettre aux hôtes IP d'informer les routeurs IP qu'ils souhaitent rejoindre un groupe multicast. Techniquement, IGMP n'a rien à voir avec les commutateurs et le fonctionnement de la couche 2, mais un certain nombre de fabricants de commutateurs, notamment Cisco, ont ajouté des fonctionnalités à leurs commutateurs permettant au commutateur d'écouter (ou de snooper) le trafic IGMP entre les hôtes IP et les routeurs IP activés pour le multicast.

Malheureusement, le snooping IGMP ne fonctionne que s'il y a un routeur multicast sur le(s) sous-réseau(s) en question. S'il n'y a pas de routeur activé pour le multicast, il n'y a pas de conversation IGMP à "snooper". C'est là qu'intervient le questeur de snooping IGMP. Il envoie les requêtes d'adhésion IGMP qui seraient normalement envoyées par un routeur multicast PIM, initiant ainsi l'échange pour que le commutateur "snoope".

Il serait agréable que le snooping IGMP soit activé par défaut sur la plupart des commutateurs, mais je suppose que ce n'est pas le cas parce que, bien qu'IGMP soit une norme de l'IETF, il n'existe pas de norme réelle pour le snooping IGMP.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X