La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
Switch => Discussion démarrée par: Nico le 01 mai 2014 à 19:38:04
-
Quand je regarde la TV avec le décodeur, je m'aperçois que le flux est poussé à tout mon LAN et toutes les machines.
C'est pas super étonnant en soit, un flux multicast qui est diffusé en multicast ça se tient. Ceci dit je me dis qu'il y a surement moyen d'arranger ça en jouant avec les VLANs.
Sachant que chez moi entre la NB6v et le décodeur il y a 2 switchs manageables. Bref si quelqu'un a un début d'idée je prends !
-
Quand je regarde la TV avec le décodeur, je m'aperçoit que le flux est poussé à tout mon LAN et toutes les machines.
C'est pas super étonnant en soit, un flux multicast qui est diffusé en multicast ça se tient. Ceci dit je me dis qu'il y a surement moyen d'arranger ça en jouant avec les VLANs.
Sachant que chez moi entre la NB6v et le décodeur il y a 2 switchs manageables. Bref si quelqu'un a un début d'idée je prends !
IGMP
-
https://fr.wikipedia.org/wiki/IGMP_Snooping (https://fr.wikipedia.org/wiki/IGMP_Snooping)
-
C'est pas super étonnant en soit, un flux multicast qui est diffusé en multicast ça se tient.
Tu veux dire en broadcast ? C'est quand même très étonnant en tout cas, surtout si tu peux capter le flux sur ta machine et le lire en clair (pas sûr que TF1 soit ravi par exemple).
Méthode crade : une ACL bien placée pour bloquer le flux sur les switches, si tu ne veux pas les voir.
Après oui si ce sont des adresses multicast, il doit y avoir moyen de faire comme jewome62 et mattmatt le disent sobrement :)
-
Tu veux dire en broadcast ?
Oui pardon.
C'est quand même très étonnant en tout cas, surtout si tu peux capter le flux sur ta machine et le lire en clair (pas sûr que TF1 soit ravi par exemple).
J'imagine que c'est pas en clair, mais si tu as un moyen de regarder... Mais étonnant je ne sais pas, la box n'a qu'un port de connecté sur le premier switch donc c'est obligé de passer par là.
Après oui si ce sont des adresses multicast, il doit y avoir moyen de faire comme jewome62 et mattmatt le disent sobrement :)
Je vais regarder ce que je peux faire avec mes switchs.
-
Parfois IGMP est activé par défaut sur les switches manageables et donc il n'y a rien à faire pour gérer les flux multicast ... sauf si les IGMP ne sont pas reconnus.
-
Faire igmp-snooping enable sur les deux switchs ça ne suffit pas à première vue. J'ai toujours 12M qui vont sur tout ce qui est connecté.
Il faut surement faire une conf' plus poussée que juste ça.
-
Parfois IGMP est activé par défaut sur les switches manageables et donc il n'y a rien à faire pour gérer les flux multicast ... sauf si les IGMP ne sont pas reconnus.
Je n'ai jamais vu un switch manageable qui est igmp par défaut, car si ton équipement ne gère pas l'igmp snooping, il ne verra jamais les flux multicast....
-
C'est quand même un coup à DDoS mon imprimante cette histoire :o :o
-
Je n'ai jamais vu un switch manageable qui est igmp par défaut, car si ton équipement ne gère pas l'igmp snooping, il ne verra jamais les flux multicast....
N'importe quel Cisco 29xx/35xx/37xx fait de l'IGMP snooping par défaut.
http://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/29480-167.html (http://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/29480-167.html)
Mais c'est pas pour autant que ça marche.
-
Bizarre, sur les catalyst qu'on utilise, on doit activer la fonction
N'importe quel Cisco 29xx/35xx/37xx fait de l'IGMP snooping par défaut.
http://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/29480-167.html (http://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/29480-167.html)
Mais c'est pas pour autant que ça marche.
-
C'est quand même un coup à DDoS mon imprimante cette histoire :o :o
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.
Je dis ça, mais c'est une simple supposition de néophyte, n'hésitez pas à me corriger.
Du coup, pour seulement 12Mb/s, sur un réseau switché 100Mb/s, pas la peine de s'affoler.
Faire igmp-snooping enable sur les deux switchs ça ne suffit pas à première vue. J'ai toujours 12M qui vont sur tout ce qui est connecté.
Est-ce qu'il ne faut pas activer ce "igmp snooping" dans le VLAN qui va bien?
Leon.
-
Tu as sans doute raison, je disais plus ça pour rire qu'autre chose. Cela dit j'aimerais autant apprendre à diriger ça proprement vers qui de droit (a.k.a. mon décodeur). Ce serait plus propre et puis je saurais faire un truc en plus :).
-
Pour moi la carte réseau ne filtre pas les trames multicast. Sinon comment le processeur verrait le trafic ?
-
et ces flux on peut s'y connecter sur un PC ?
Parceque perso impossible d'avoir quoi que ce soit dans VLC
-
Pour moi la carte réseau ne filtre pas les trames multicast. Sinon comment le processeur verrait le trafic ?
Simple supposition : le processeur déclarerai à la carte réseau qu'elle doit s'abonner à tel flux multicast (au sens Ethernet). Du coup, la carte mets à jour ses filtres en temps réel.
Leon.
-
et ces flux on peut s'y connecter sur un PC ?
Parceque perso impossible d'avoir quoi que ce soit dans VLC
tu rentres bien les bonnes commandes dans vlc ?
https://lafibre.info/sfr-tutoriels/sfr-bbox-tv-sur-pc-en-haute-qualite-flux-multicast/ (https://lafibre.info/sfr-tutoriels/sfr-bbox-tv-sur-pc-en-haute-qualite-flux-multicast/)
-
tu rentres bien les bonnes commandes dans vlc ?
https://lafibre.info/sfr-tutoriels/sfr-bbox-tv-sur-pc-en-haute-qualite-flux-multicast/ (https://lafibre.info/sfr-tutoriels/sfr-bbox-tv-sur-pc-en-haute-qualite-flux-multicast/)
Ben j'ai recup le fichier donc je pense
-
Ben j'ai recup le fichier donc je pense
attention au différentes version de vlc qui ne prennent pas la même syntaxe
-
Simple supposition : le processeur déclarerai à la carte réseau qu'elle doit s'abonner à tel flux multicast (au sens Ethernet). Du coup, la carte mets à jour ses filtres en temps réel.
Leon.
L'abonnement se gère via IGMP qui est traité par le CPU. C'est le switch qui t'envoie en fonction de tes trames IGMP le flux multicast ou pas.
Si le switch ne gère pas IGMP OU n'arrive pas à identifier le flux multicast, il le traite par défaut en flux broadcast et donc tout le monde voit le flux.
-
Si le switch ne gère pas IGMP OU n'arrive pas à identifier le flux multicast, il le traite par défaut en flux broadcast et donc tout le monde voit le flux.
et là, c'est le drame....
-
L'abonnement se gère via IGMP qui est traité par le CPU. C'est le switch qui t'envoie en fonction de tes trames IGMP le flux multicast ou pas.
Si le switch ne gère pas IGMP OU n'arrive pas à identifier le flux multicast, il le traite par défaut en flux broadcast et donc tout le monde voit le flux.
Tu es sur?
De ce que j'ai compris, les èmetteurs de Multicast utilisent des adresses Ethernet (MAC, pas IP) de destination différentes des adresses unicast ou broadcast. Je suis d'accord avec toi, un switch qui ne sait pas gérer le multicast va traiter ces trames multicast comme du broadcast. Mais leur adresse Ethernet de destination restera spécifique à du Multicast, ce qui me fait penser que la carte ethernet pourra les filtrer sans trop de problème.
Rappelle-toi d'il y a 20 ans où les switches ethernet étaient inabordables. Les réseaux ethernet étaient souvent faits avec des hubs, donc tout le monde recevait tout. Pareil avec les réseaux coaxiaux ethernet. Pourtant, les cartes réseau savaient filtrer ce qui ne leur était pas destiné, et c'était même primordial vu la faible puissance des cpu de l'époque.
Leon.
-
Tu es sur?
Oui
-
Tu es sur?
De ce que j'ai compris, les èmetteurs de Multicast utilisent des adresses Ethernet (MAC, pas IP) de destination différentes des adresses unicast ou broadcast. Je suis d'accord avec toi, un switch qui ne sait pas gérer le multicast va traiter ces trames multicast comme du broadcast. Mais leur adresse Ethernet de destination restera spécifique à du Multicast, ce qui me fait penser que la carte ethernet pourra les filtrer sans trop de problème.
Rappelle-toi d'il y a 20 ans où les switches ethernet étaient inabordables. Les réseaux ethernet étaient souvent faits avec des hubs, donc tout le monde recevait tout. Pareil avec les réseaux coaxiaux ethernet. Pourtant, les cartes réseau savaient filtrer ce qui ne leur était pas destiné, et c'était même primordial vu la faible puissance des cpu de l'époque.
Leon.
Le but du multicast est d'économiser de la bande passante sur la diffusion d'un flux. Si tu filtres à réception du trafic, t'as rien économiser du tout, ton lien sera rempli par le trafic et en plus ta carte réseau prend le temps de lire le début de la trame pour vérifier si c'est pour elle ou pas.
Donc c'est le switch qui a pour role de n'envoyer le flux qu'aux abonnés d'où le protocole IGMP.
Sinon tu as raison sur la partie Ethernet : l'adresse MAC de destination est en effet spécifique. Mais ce n'est pas pour autant que le switch lui fera un traitement spécifique. Il essaierai et s'il n'a pas de groupe IGMP associé, broadcast pour tout le monde !
@mattmatt73 : non, avec du AFDX là c'est le drame :)
-
@mattmatt73 : non, avec du AFDX là c'est le drame :)
je ne connais pas l'afdx, mais des fluxs multicast de fort débit qui se promènent sur ton réseau sans igmp ou Vlan, satureront forcement des équipements
-
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.
-
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.
Alors que chez moi, on des flux multicast de plusieurs Mb/s chacun, quand tu cumules les flux, tu satures les ports 100Mb/s, les firewalls, voir les ports 1Gb/s
-
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.
-
Merci corrector.
Effectivement, je ne suis pas complètement fou, je me rappelais bien avoir lu tout ça quelque part. Donc le trafic Multicast n'est pas du tout envoyé au CPU par la carte réseau, qui filtre ça grâce aux adresses Ethernet, si l'adresse multicast n'a pas été souscrite par la machine. Donc OK, du multicast peut polluer le réseau, si les switches ne savent pas le gérer (uniquement en broadcast), mais les CPU ne seront pas perturbés, ne verront pas de charge supplèmentaire.
http://guillaumemuller1.free.fr/Cours/ESIL/Reseau/TP1_corrige.pdf (http://guillaumemuller1.free.fr/Cours/ESIL/Reseau/TP1_corrige.pdf)
Les stations du réseau sont-elles pénalisées par la réception de trames multicast qui ne leur sont pas
destinées ? Pourquoi ?
Non, car c’est le hardware de la carte réseau (ou équivalent sur la carte mère) qui filtre le multicast.
Si tu filtres à réception du trafic, t'as rien économiser du tout, ton lien sera rempli par le trafic et en plus ta carte réseau prend le temps de lire le début de la trame pour vérifier si c'est pour elle ou pas.
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.
-
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.
-
Bon avec tout ça je n'ai pas encore trouvé comment faire en sorte que ce soit bien géré chez moi.
Faudrait savoir quelles infos la NB donne au switch pour identifier à qui doit aller le trafic. D'ailleurs comme entre ma NB et son décodeur il y a 2 switchs, je me disais que peut-être que le premier (qui reçoit le flux) n'arrive pas à voir qu'il est destiné à un device sur le second ? Comment peuvent-ils partager cette "information" ?
(j'ai ptet dit une connerie mais on est relativement éloigné de ce que je connais plus)
-
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?
-
Bah pour le coup le flux n'est présent que si le décodeur le demande. Et donc qqn s'en sert (le décodeur)...
Je regarderai les options que j'ai sur l'IGMP mais y a surement. C'est du Huawei S3300 et S5300.
-
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.
-
Oui mais la puce ne peut que stocker quelques adresses différentes.
Si ton test es précis tu dois arriver à déterminer le seuil au delà duquel le filtrage remonte au CPU.
-
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 !
-
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.
Je parlais d'un switch bas de gamme. Mon switch 8 ports à 20€ ne sait certainement pas traiter tout ça (L3, QOS, Vlans) en hardware (ou pas en hardware). Pourtant, ce switch à 20€ sait analyser chaque adresse ethernet de chaque paquet ethernet, et ce en temps réel, à la vitesse maxi permise par l'interface.
Et dans le réseau de Nico, on ne parle que d'un seul flux multicast qui ne dépassera jamais les 12Mb/s, donc je ne vois pas pourquoi tu me parles de difficulté de certaines cartes à traiter en hardware du 1Gb/s! Il y a un facteur 100 entre les 2!
Oui, c'est "crade" de voir ça sur tout son réseau, on est tous d'accord là dessus. Mais je pense sérieusement que dans le cas de Nico, aucun des CPU de ses équipements (PC ou autre) ne sera impacté.
Leon.
-
Je demande à voir que ton switch à 20€ soit capable d'analyse 8x flux 1Gb avec des paquets de 64octets. 1500octets, oui, mais certainement pas 64. Et c'est là toute la différence (c'est la ligne marquée "pps" pour "packets per seconds" qui indique les VRAIES capacités d'un matériel, à 20€ on ne l'indique pas !!!). Dans le cas d'AFDX, on a testé en lab avec toutes sortes de switches : tous abdiquaient, des petits comme des gros. Comme quoi, le multicast ne résume pas à juste lire une adresse MAC.
Je tiens à faire remarquer que je parlais de l'impact CPU sur des machines aux ressources limitées, genre une imprimante. C'est sur qu'avec un PC d'aujourd'hui on s'en fiche, c'est juste sale. A l'échelle d'un réseau d'entreprise, ça reste catastrophique.
-
Je demande à voir que ton switch à 20€ soit capable d'analyse 8x flux 1Gb avec des paquets de 64octets. 1500octets, oui, mais certainement pas 64. Et c'est là toute la différence (c'est la ligne marquée "pps" pour "packets per seconds" qui indique les VRAIES capacités d'un matériel, à 20€ on ne l'indique pas !!!).
Euh, c'est un switch 100Mb/s bien évidemment.
Dans le cas d'AFDX, on a testé en lab avec toutes sortes de switches : tous abdiquaient, des petits comme des gros. Comme quoi, le multicast ne résume pas à juste lire une adresse MAC.
Mais là on parle du cas de Nico, pas de l'AFDX, Nico a un seul et unique flux Multicast de 12Mb/s. Et d'après ce que j'avais vu, les paquets entre un routeur et le décodeur font plutôt ~500 octets (et pas 64). Donc en terme de PPS, c'est très raisonnable (~3000pps).
Je tiens à faire remarquer que je parlais de l'impact CPU sur des machines aux ressources limitées, genre une imprimante. C'est sur qu'avec un PC d'aujourd'hui on s'en fiche, c'est juste sale. A l'échelle d'un réseau d'entreprise, ça reste catastrophique.
Mais pourquoi le CPU de l'imprimante recevrait-il les paquets multicast ethernet, si ces paquets sont filtrés par la "carte réseau"?
Et puis j'avais vraiment cru que tu parlais de l'impact sur la carte réseau, voir ci dessous:
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.
Leon.
-
Les petits switch Netgear pas cher (50€) gèrent quand même le débit max du GigaEthernet soit 1 448 000 frames/secondes , trames de 72 octets, le minimum pour Ethernet (en comptant le préambule).
Ca dépend beaucoup du fond de panier (backplane) et si y'a l’appellation 'non bloquant' ou pas.
Donc quand on a peu de ports un switch pas cher n'est pas forcement limité. Apres tout dépend des marques bien sur. Mais y'a eu pas mal de progrès et de baisse de prix pour les non bloquants.
AFDX c'est le truc d'Airbus ou autre chose ? si c'est celui d'Airbus dont vous parlez, il n'est pas prévu pour des switch Ethernet normaux donc c'est pas étonnant que ca les plante ou les sature : on sort des limites des specs d'Ethernet 'normal'. Un peu comme si j'envoyai du 220 volts dans un port Ethernet aussi, peu de switch vont aimer ca. Ca n'a pas vraiment de sens de faire ca ou de juger les switches sur ca.
-
Mais là on parle du cas de Nico, pas de l'AFDX, Nico a un seul et unique flux Multicast de 12Mb/s. Et d'après ce que j'avais vu, les paquets entre un routeur et le décodeur font plutôt ~500 octets (et pas 64). Donc en terme de PPS, c'est très raisonnable (~3000pps).
Puis côté switchs j'ai 9.6Mpps sur le petit, et 66Mpps sur le gros.
Tant que j'étais dans la datasheet j'ai trouvé ça :
supports IGMP v1/v2/v3, IGMP snooping, IGMP filter, IGMP fast leave, and IGMP proxy
-
AFDX c'est le truc d'Airbus ou autre chose ? si c'est celui d'Airbus dont vous parlez, il n'est pas prévu pour des switch Ethernet normaux donc c'est pas étonnant que ca les plante ou les sature : on sort des limites des specs d'Ethernet 'normal'. Un peu comme si j'envoyai du 220 volts dans un port Ethernet aussi, peu de switch vont aimer ca. Ca n'a pas vraiment de sens de faire ca ou de juger les switches sur ca.
C'est bien le protocole d'Airbus qui en avait marre des bus propriétaires. Les développeurs utilisent souvent des switches Ethernet car les switches AFDX coutent très chers. J'ai passé beaucoup de temps à leur expliquer que ça ne pourrait jamais marcher à vitesse normale et qu'il fallait qu'ils réduisent la fréquence de fonctionnement du bus (c'est un réglage soft) pour que ça fonctionne. On a meme essayé avec un hub, ça donnait des résultats pas trop dégueulasse excepté les collisions...
Ensuite, on a aussi le problème des parties softs développées sur des PC. De temps en temps, des flux AFDX partaient sur le réseau entreprise. Je te dis pas le bordel sur les switches. Pendant longtemps on a impliqué Cisco qui était persuadé que ces switches pouvaient gérer mais la tronche de la trame multicast faisait paniquer le CPU. Depuis on a mis en place des contre-mesures actives (storm-control) et fait la chasse aux applis AFDX.
Tant que j'étais dans la datasheet j'ai trouvé ça :
supports IGMP v1/v2/v3, IGMP snooping, IGMP filter, IGMP fast leave, and IGMP proxy
Ouais ça c'est les fonctions de base de tout switch manageable. Mais en l'absence de flux IGMP ça n'aide pas. J'ai regardé sur mon Netgear perso, il n'y a aucun moyen de faire une gestion manuelle.
-
[HW5328]igmp-snooping ?
enable Enable IGMP-Snooping
send-query Send IGMP query
J'avais pas fait attention au "send-query", je vais tester ça. Si ça parle à quelqu'un je vous écoute.
-
A priori ça serait pour reforwarder les IGMP query vers tous les ports.
-
Bon, j'ai allumé la télé pour regarder un peu. Bizarrement à ce moment là mon iPad et l'iPhone de ma copine galéraient. J'ai coupé et c'était reparti nickel.
A voir si c'est juste une coïncidence ou pas maintenant.
-
Y'a plus qu'à sortir tcpdump et faire un monitor sur ton switch :D
-
C'est vraiment con, j'étais à 2 doigts de rendre le décodeur (qui ne me sert pas vraiment) et là je m'aperçois que j'ai envie de résoudre cette histoire...
(wireshark ça irait pour capturer les-dites trames ?)
-
Oui parfait.
-
En tout cas je confirme que décodeur allumé mon iPad est en difficulté avec le WiFi ! Mon AP doit cracher le flux c'est con.
Ci-dessous une capture Wireshark.
-
Ben alors la carte réseau de l'Ipad filtre pas les flux multicast ?!? :D Leon, je te laisse méditer là-dessus....
-
Euh c'est peut-être juste le WiFi qui "sature", à voir quoi.
Si il cherche à envoyer 12M aux 7 devices connectés en WiFi...
-
T'es pas en Wifi 11Mb ?
Sinon ta capture ne montre pas grand chose. Pas de trace d'IGMP ou alors on est passé à coté (il aurait été émis avant le début du flux).
-
T'es pas en Wifi 11Mb ?
Non, 4 connexions sur du n 2,4GHz et 3 connexions sur du n 5GHz...
Sinon ta capture ne montre pas grand chose. Pas de trace d'IGMP ou alors on est passé à coté (il aurait été émis avant le début du flux).
Ah mince :/ (t'as vu la capture avec l'allumage du décodeur en DM ?)
-
Y'a juste les trames LLMNR qui sont rigolotes. C'est quoi tes IP ?
-
Y'a juste les trames LLMNR qui sont rigolotes.
Rien à voir avec le fait que le serveur DNS du PC qui faisait tourner wireshark est un autre PC du LAN ? (je connaissais pas LLMNR et Wikipedia ne m'a qu'un peu aidé)
C'est quoi tes IP ?
PC avec wireshark : 192.168.26.64
Décodeur : 192.168.26.155
Précision : le PC est sur le même switch que la neufbox, le décodeur sur un autre switch (relié au premier). Et le "flood" est vu sur tous les ports up des 2 switchs.
-
Rien à voir avec le fait que le serveur DNS du PC qui faisait tourner wireshark est un autre PC du LAN ? (je connaissais pas LLMNR et Wikipedia ne m'a qu'un peu aidé)
PC avec wireshark : 192.168.26.64
Décodeur : 192.168.26.155
T'as pas une imprimante Brother en 192.168.26.47 ?
Précision : le PC est sur le même switch que la neufbox, le décodeur sur un autre switch (relié au premier). Et le "flood" est vu sur tous les ports up des 2 switchs.
Le flood c'est "normal" vu qu'il n'y a pas de gestion par IGMP.
Quand tu actives IGMP sur le switch, il y a normalement une option pour bloquer les multicast inconnus.
-
T'as pas une imprimante Brother en 192.168.26.47 ?
Si. J'ai pas listé les 30 appareils connectés :).
Le flood c'est "normal" vu qu'il n'y a pas de gestion par IGMP.
Quand tu actives IGMP sur le switch, il y a normalement une option pour bloquer les multicast inconnus.
Faut que je regarde les options que j'ai oui.
-
Hello
Je sais pas si ca fait avancher le smhilblick mais j'avais 'exactement le meme probleme sur ma config:
Box --> ASUS RT66 U en DMZ
Le multicast TV floodait comme un malade et le RT66 ne laissait plus rien passer
malheuresement au bout d'un moment et ne trouvant pas de solution (et devant les reponses les plus betes du monde sur le forum SFR) j'ai laché l'affaire et coupé la DMZ en laissant ma box tout gerer...
-
La différence c'est que mon routeur c'est toujours la NB, je n'ai que des switchs derrière. Par contre j'ai bien une DMZ, je vais voir si ça ne serait pas ça qui pose problème.
-
Ah ok, j'avais mis mon ASUS RT66 en routeur; toi tu a donc BOX (routeur) --> Switch --> Switch ? et la DMZ qui va sur une becane au pif? (sans indiscretion c'est pr quelle raison? un firewall?)
Tente avec la DMZ, dès desactivation chez moi tout etait rentré dans l'ordre...
-
C'est ça, box <-> switch <-> switch. Le décodeur étant sur le second switch (qui est au niveau du "coin télé" pour alimenter TV, décodeur & co).
La DMZ pointe sur une VM avec laquelle je fais qqs tests, elle est là plus par flem de toucher tout le temps à la redirection de ports qu'autre chose (et donc elle n'est pas indispensable).
-
Eh donc sans DMZ ça ne change rien, j'ai toujours 12M qui vont dans tous le LAN quand j'allume mon décodeur.
-
N'empeche que les switches devraient voir les IGMP.
T'as quoi comme option : version ? vlan ? (tu pourrais le forcer à 1) autre ?
-
J'ai ça :
[HW5328]igmp-snooping ?
enable Enable IGMP-Snooping
send-query Send IGMP query
[HW5328]igmp-snooping enable ?
vlan Specify parameters for VLAN
[HW5328]igmp-snooping send-query ?
enable Enable to send IGMP query
source-address Specify source address
J'ai pas spécifié de VLAN pour le moment.
Y a que ça dans ma conf :
#
igmp-snooping enable
igmp-snooping send-query enable
#
Niveau version :
Tant que j'étais dans la datasheet j'ai trouvé ça :
supports IGMP v1/v2/v3, IGMP snooping, IGMP filter, IGMP fast leave, and IGMP proxy
-
Je suppose que tu es tout en Vlan 1 ? Essayes de faire un "igmp-snooping enable vlan 1" ainsi qu'un "igmp-snooping send-query enable" qui est je pense nécessaire car tu as deux switches.
-
Je suppose que tu es tout en Vlan 1 ?
Oui, j'ai rien touché côté VLAN.
Essayes de faire un "igmp-snooping enable vlan 1"
Fait mais ça n'a pas rajouté de ligne dans la conf donc je pense que le enable sous-entend "VLAN 1".
ainsi qu'un "igmp-snooping send-query enable" qui est je pense nécessaire car tu as deux switches.
Déjà fait.
-
Pour moi la carte réseau ne filtre pas les trames multicast. Sinon comment le processeur verrait le trafic ?
En configurant la carte réseau?
Je ne comprends pas la question.
-
Pour info mes switch GS105E gère le multicast de la neufbox
http://www.netgear.fr/business/products/switches/prosafe-plus-switches/GS105E.aspx (http://www.netgear.fr/business/products/switches/prosafe-plus-switches/GS105E.aspx)
-
J'ai pas tout suivi le topic, t'as pas réussi au final a séparer une multicast sur un VLAN ?
-
Pour info mes switch GS105E gère le multicast de la neufbox
Par défaut ? Rien à régler ?
J'ai pas tout suivi le topic, t'as pas réussi au final a séparer une multicast sur un VLAN ?
Pour l'instant j'ai seulement activé l'igmp-snooping sur les 2 switchs et ça n'a rien résolu. Pas touché aux VLANs. Tu proposerais quoi ?
-
Je sais pas si j'ai tout bien compris, donc a prendre avec des pincettes.
Deja, ca me parait normal que l'igmp snooping soit pas la solution a ton problème.
Pour orange je comptais faire ca :
- Tagguer un vlan sur le lan
- identifier le traffic multicast en amont
- l'envoyer sur ce vlan
- tagguer ce vlan sur un port du switch et brancher la box dessus
Adapter igmpproxy pour que le downstream soit ce vlan.
Normalement avec ce setup, tu n'auras pas de multicast hors du vlan targué sur le lan.
Chez orange l'étape "identifier le traffic multicast en amont" est facile puisque ca vient d'un vlan, chez sfr ca sera peut être plus compliqué, et la suivante aussi (bridge du vlan du LAN avec les vlans wan video d'orange)
-
- identifier le traffic multicast en amont
- l'envoyer sur ce vlan
Tu fais ça avec quoi ? J'ai pas de routeur avec lequel jouer.
Sinon je peux peut-être brancher un second câble de ma box au switch et faire en sorte de ne permettre à mon décodeur de ne voir que lui. En gros faire deux réseaux +- séparés. A voir si ça peut marcher et si c'est possible.
-
Je regardais vite fait les options du switch, je pense pas que tu arrives a quoi que ce soit.
Faut forcèment intervenir en amont ou au milieu, cad entre la box et le lan.
N'importe quel routeur linux (openwrt, etc...) pourra blocker manager le multicast.
J'ai pas compris ta 2e phrase, le multicast arrive de la box "modem", sans routage/fw il ira partout sur ton LAN.
-
Pour la première partie, pas bien grave, je ferai sans. Pas envie de mettre qqch de plus entre la box et le LAN pour l'instant.
Sur la seconde idée, je me disais que la NB si elle "voit" directement le décodeur sur son port 2 (par exemple), elle ne pousserait pas le multicast sur le port 1 (où se trouve tout le reste de mon réseau).
Mon idée (mais c'est peut-être pas faisable et tout) serait de créer un "tunnel" entre un port de la box et le port du décodeur, via les 2 switchs.
-
Mais si tu peux pas bidouiller la box elle enverra tjrs sur tous les ports, c'est cette partie que je saisis pas.
-
Aujourd'hui j'en sais rien si la box envoie le multicast sur tous les ports. Je n'ai qu'un seul port de connecté sur ma neufbox dans la configuration actuelle.
-
Ca vaut le coup de tester mais, ca m'étonnerait vraiment qu'elle contrôle le port sur lequel est branchée le décodeur pour envoyer le flux.
-
Et si tu faisais un port sur ta neufbox que tu dédierait à la TV, que tu mettrai sur un switch manageable, connecté à la STB sur un autre port, et comme tu mettrai un seul VLAN pour les deux, alors la neufbox verrait directement la STB, sans passer par un switch/routeur/whateveryouwant.
-
Les commutateurs Ethernet simples traitent les trames multicast comme des trames broadcast, c'est-à-dire en les répliquant sur toutes les portes à l'exception de la porte èmettrice. Le protocole IGMP Snooping ne transmet les trames qu'aux hôtes ayant manifesté de l'intérêt pour le groupe, ce qui est plus efficace.
https://fr.wikipedia.org/wiki/Multicast (https://fr.wikipedia.org/wiki/Multicast)
Par contre on revient sur le snooping qui règlerait donc le pb.
Apres si tu veux vraiment ne plus voir ce traffic, faut isoler et le switch y arrivera pas.
-
Et si tu faisais un port sur ta neufbox que tu dédierait à la TV, que tu mettrai sur un switch manageable, connecté à la STB sur un autre port, et comme tu mettrai un seul VLAN pour les deux, alors la neufbox verrait directement la STB, sans passer par un switch/routeur/whateveryouwant.
Oui mais en fait j'ai un soucis de WAF (https://fr.wikipedia.org/wiki/Wife_acceptance_factor) : les deux switchs sont reliés en fibre (2 jarretières, faut que je trouve des SFP bi-dir pour en enlever une), c'est assez discret (et fin) pour passer sous un tapis et aller du coin "serveurs" au coin "TV" sans gêner Mlle.
Les commutateurs Ethernet simples traitent les trames multicast comme des trames broadcast
Pour le coup c'est pas un switch "simple" que j'ai, après j'ai peut-être mal interprété le "simple".
Par contre on revient sur le snooping qui règlerait donc le pb.
Voila, si ce n'est qu'à première vue ce n'est pas le cas. Je vais creuser les options sur le switch mais y a pas grand chose.
-
Qu'est ce qui te faire dire que le snooping ne règle pas le souci ? Comment tu verifies ?
-
Disons qu'activer l'igmp-snooping sur les deux switchs n'a pas résolu le soucis. Après c'est peut-être pas bien fait, ou que sais-je.
-
Tu peux tester le fonctionnement de l'IGMP avec des captures Ethernet?
-
Surement, mais je veux bien une petite explication (ou un lien) sur quoi/comment faire.
-
Il faut un espion : sur une patte sur switch, tu mets un PC qui fait une capture. Tu peux mettre un filtre pour ne capturer que ce qui n'est à destination du PC.
Il faut un consommateur de flux : un PC sur une autre patte qui demande un flux IGMP.
Il faut un fournisseur.
-
Les IGMP sont forcement pas destinés a une cible precise puisqu'ils sont broadcastés ?
A la limite tu peux regarder les sources ?
-
Les messages de type IGMP sont destinés aux routeurs IGMP.
Les messages envoyés à une adresse multicast gérée par IGMP sont destinés à tout le groupe, c'est à dire les abonnés.
-
A la limite tu peux regarder les sources ?
Comment ?
@corrector : Je vois un peu l'idée pour tester l'IGMP, moins comment réaliser ça facilement. Ça peut-être des machines du LAN (et pas forcement donc qqch qui viendrait de "dehors") ?
-
dixit la doc Huawei, les commandes a saisir dans les switch :
system-view
igmp-snooping enable
vlan 1
igmp-snooping enable
quit
la 2ere ligne active globablement l'IGMP Snooping
la 3eme ligne passe en configuration du vlan 1 (donc le vlan par defaut). Le prompt devrait changer en conséquence
la 4eme ligne active l'IGMP Snooping pour le vlan 1.
J'ai pas de switch Huawei sous la main pour tester donc je ne garanti rien ;)
-
Alors globalement j'avais fait igmp-snooping enable mais pas dans le vlan 1. Là ça a plutôt pas trop mal marché car ça n'envoie plus le flux partout.
Sauf que ... ça continue de l'envoyer sur le seul truc que je ne voulais pas, le routeur TP-Link (utilisé en AP, un WDR3600) qui me sert de borne WiFi. Sachant que ce flux de 12M me pourri le WiFi.
J'ai vu que "IGMP Proxy" était à enable, en le passant à disable on dirait que le problème n'est plus présent. Merci à tous du coup.
-
Pour résumer, côté switchs :
system-view
igmp-snooping enable
vlan 1
igmp-snooping enable
quit
Et côté routeur/AP :
IGMP Proxy : disable
-
Il ne semble pas y avoir d'option sur l'IGMP snooping sur le TP-Link, voici ce qu'on lit sur la page de configuration Network / LAN :
IGMP(Internet Group Management Protocol) works for IPTV multicast stream.
The device supports both IGMP proxy with enabled/disabled option and IGMP snooping.
-
Quelqu'un sait ce que signifie "IGMP proxy" sur un switch?
-
C'est pour renvoyer les IGMP reçus afin que les messages ne se perdent pas d'un switch à l'autre. Ca c'est la théorie, à mon avis, en pratique y'a des effets de bord.
@Nico: et l'IGMP snooping est activé ou pas sur l'AP ?
-
@Nico: et l'IGMP snooping est activé ou pas sur l'AP ?
Activé je pense, mais pas réglable.
-
'IGMP proxy' sert surtout dans les routeurs quand on a du NAT notamment. Le routeur fait 'proxy' pour les clients NATés vis a vis de l'amont.
Dans les switch c'est plus rare , ca sert quand on a des VLANs différents non routés entre eux par exemple. Dans ce cas le switch va servir de proxy entre les clients sur un VLAN et l'amont qui est sur un autre VLAN.
Ca permet aussi de soulager l'amont quand on a beaucoup de clients car le proxy 'factorise' les requêtes d'abonnement/désabonnement et donc 100 clients derrière un proxy sont vu comme un seul par l'amont.
Avec le multicast les choses peuvent vite devenir compliquées et on s'embrouille facilement. Comme toujours en réseau il faut raisonner par couches et par 'tiers' (access , distribution, core):
IGMP est un protocol au dessus d'IP. Il ne sert qu'entre des clients et un routeur multicast donc en général sur le LAN uniquement. Au delà, en amont, vers les sources multicast (vidéos ou autres) , c'est d'autres protocoles qui sont utilisés comme par exemple PIM.
IP Multicast est de niveau 3 et pour fonctionner sur des switch Ethernet il existe un mapping vers des adresse Ethernet multicast (MAC multicast) de la couche 2 facon ARP comme avec les adresses IP unicast vers les adresses MAC classiques.
Par défaut tout switch va diffuser les adresses MAC multicast sur tout ses ports.
En utilisant IGMP Snooping un switch 'écoute' la couche 3 (IP donc) pour capter les messages IGMP et en fonction d'eux changer la façon dont il diffuse les adresses MAC multicast. IGMP Snooping est donc un mécanisme interne au switch qui ne concerne que le switch et sa facon dont il gere le mapping 3->2 pour le multicast d'IP.
Ce dessin de Wikipedia resume assez bien les 'tiers' et les couches:
(http://upload.wikimedia.org/wikipedia/commons/c/c9/IGMP_basic_architecture.png)
Un proxy sert a relayer le traffic IGMP (en rouge) quand le LAN est plus étendu ou complexe (NAT ou/et VLAN par exemple ou si il y a énormèment de clients pour soulager le routeur multicast).