Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Trop de Broadcast tue le réseau
Salut,
Une bonne image vaut mieux qu'un long discours :
Je souffre
Pourriez-vous me dire si ce relevé vous semble normal ?
Si, non ! Pourriez-vous m'indiquer comment puis-je trouver les éléments perturbateurs ?
Sachant que je pars de loin avec quelques switchs 2224 de chez HP.
La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !
Albert Einstein
Woooww
Non, ce n'est pas normal...
La chose à faire maintenant, c'est de sous-catégoriser tous ces broadcasts pour savoir quels sont les protocoles les plus bavards.
Steph
Merci de ton retour.
Et comment dois-je m'y prendre ? Car je ne suis pas issue du monde du réseau
La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !
Albert Einstein
Si tu n'as pas d'outil sophistiqué sous la main, tu peux prendre une trace Wireshark en filtrant les Broadcasts et Multicasts, ça devrait donner une 1ère idée de l'étendue des dégâts
Menu Capture
Menu Options
Cliquer sur Capture Filter
Cliquer sur New
Filter name : Broadcast & Multicast
Filter string : broadcast and multicast
Cliquer OK
Normalement, le filtre est actif en tant que "Capture Filter" (ça doit être vert).
Puis tu cliques sur Start...
Tu attends quelques minutes (fais gaffe à pas overloader ton disque dur nonplus).
Menu Capture
Cliquer sur Stop.
Tu sauvegardes ta capture (File -> Save As...).
Maintenant, tu vas dans le menu Statistics, puis tu cliques "Protocol Hierarchy". Tu vas avoir le pourcentage des protocoles qui génèrent toute cette friture
Fais éventuellement une copie d'écran...
Steph
Bonjour,
Sans (trop) d'indiscretion, tu es dans quel type de boite ?
Je pose la question car non seulement la part de broadcast est incroyablement elevee, mais 7% de multicast, c'est aussi assez impressionnant comme volume, donc il se pourrait que l'utilisation que tu montres ne soit pas aussi catastrophique que la repartition le laisse penser (sachant qu'elle est tout de meme anormale).
Je ne suis pas pudique, donc ta question n'est pas indiscrète.
Je bosse pour une société spécialisé dans l'impression, autrement dit une imprimerie. Mais j'ai dans chaque bureau une seule prise réseau et 2 à 4 personnes branchées dessus...
Je préviens cette installation n'est pas de moi, je viens d'arriver et je reprends cet historique
La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !
Albert Einstein
Personnellement, à chaque fois que j'ai vu des ratios de Broadcast/Unicast supérieurs à 40/60, j'ai toujours trouvé des problèmes... Pour moi, ça n'est pas normal.
Une première approche statistique est donc la bienvenue. Et parfois, ça tient à très peu choses. Il suffit parfois de segmenter de façon pertinente en isolant du mieux qu'on peut les flux clients/serveurs. Un jour, sur un très gros réseau, j'ai réussi à diminuer de plus de moitié ce type de traffic sur un VLAN rien qu'en isolant 2 serveurs et un PC sur un autre VLAN.
Après, il faut voir le design global L2/L3.
Steph
Bonsoir
Sur cette prise réseau partagée tu utilises un HUB ou un Switch ?
La capture n'a rien donnée mais je vais me brancher sur le même switch que le serveur EON qui héberge NTOP.
Sinon peut être que cela vous sera utile (tjs extrait de NTOP)
Sinon pour répondre à JML19 il s'agit d'un ProCurve Switch 2650 qui est connecté sur le port 50 à 3 switchs 2224 qui cascade ensuite 1 autre ProCurve Switch 2650.
La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !
Albert Einstein
C'est drole, ton trafic n'est absolument pas celui qu'on attendrait...
Tu as un trafic SNMP a faire palir les plus gros superviseurs, et plus de deux fois plus de trafic UDP que TCP, alors que la plupart des applications quotidiennes utilisent TCP.
Je pense que tu vas devoir effectivement passer un peu de temps a monitorer le trafic pour savoir qui le produit, et ensuite tu pourras voir les restrictions a mettre en place.
Idee : tu as 1% d'ICMP, c'est beaucoup - beaucoup trop pour un reseau qui fonctionne. Essaye de regarder quels sont ces paquets, ca pourrait te donner une piste.
Bonjour
Tu fais de la Visioconférence, des applications interactives de groupe ou quelque chose de ce type ?
Le trafic UDP est souvent un trafic Multicast.
Rien de tout ça !
Je vais dans un premier temps arrêter EON on verra bien de combien je diminue mon trafic SNMP.
Ensuite je n'ai pas d'autre piste...
La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !
Albert Einstein
Tu veux dire que tu n'as pas reussi a voir un seul paquet broadcast ? Soit tu n'es pas branche au bon endroit, soit ta capture etait mauvaiseEnvoyé par llaffont
Je pense neanmoins que c'est un bon moyen de diagnostique : tu pourras obtenir de bonnes infos sur ce qui se passe, voir des debuts de piste.
Si tu es plus habitue de la ligne de commande que de wireshark, tu peux capturer les donnees avec tcpdump, puis ensuite les ouvrir avec Wireshark (plus facile pour travailler dessus en general).
Mets-toi dans le même VLAN que ton NTOP, tu verras les mêmes broadcasts/multicasts.
Tout pendant que je ne verrai pas de display fiable, je ne sauterai à aucune conclusion
Steph
Salut,
sur l'EON t'aurais pas un serveur d'impression ? Je suis plus ou moins néophyte mais il me semble que cela peut-être lié avec la "découverte".
Vive les roues en pierre
Pour les Statistiques WireShark :
Non pas de serveur d'impression, il s'agit d'un serveur de supervision sans superflu.
La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !
Albert Einstein
Ces broadcasts/multicasts proviennent majoritairement du traffic ARP et UDP.
Maintenant, il faudrait filtrer la trace sur ARP et/ou UDP :
- tu reprends la trace Wireshark que tu as capturée,
- dans le filtre de display, tu saisis "arp" puis tu cliques sur Apply pour afficher les broadcasts arp, tu peux faire la même chose avec "udp" pour afficher les broadcasts UDP, tu peux aussi afficher les deux avec le filtre "udp or arp".
* Filtre ARP
Tu filtres sur ARP puis tu vas dans Statistics, Conversation List, Ethernet.
Puis tu cliques sur la colonne Packets pour savoir quelles sont les MAC @ qui génèrent le plus de traffic ARP sous forme de Broadcast.
* Filtre UDP
Tu filtres sur UDP puis tu vas dans Statistics, UDP Multicast Streams. Tu vas avoir un tableau récapitulatif. Tu cliques sur la colonne Packets pour avoir les adresses IP les plus bavardes. Tu verras notamment les ports UDP destination.
On aura alors 2 pistes sérieuses sur l'origine de ce "background traffic" sur ton réseau.
Steph
Le filtre UDP m'affiche bien des trames, mais aucune stat sur l'UDP Multicast Streams.
Comment dois-je traduire ça ?
La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !
Albert Einstein
Bizarre...
Alors filtres sur les broadcasts UDP (display filter 'udp').
Cliques sur la colonne 'Source'.
Tu auras ainsi toutes adresses IP qui génèrent ces paquets.
Quelles sont ces adresses ? Et surtout, vers quels ports UDP envoient-elles ces broadcasts ?
Steph
Merci pour votre aide.
NTOP me remonte plus que 35 % Broadcast pour ce jour.
J'ai refais une capture et je continu toujours d'avoir 54 % d'ARP sur 10 minutes de sniff.
J'ai regardé les configurations des postes certains avaient des DNS erronés donc c'était facile à régler. Mais d'autre ont les DNS à jour et continu à faire des requête à la con. je ne sais plus où regarder
Auriez-vous encore des idées ?
La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !
Albert Einstein
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager