33
Wie Broadcaster ausfindig machen?
Hallo, kennt sich hier eventuell jemand ganz gut mit Wireshark aus? Bei einem mittelständigen Unternehmen blinken alle Switchports pausenlos - auch die wo Geräte dran stecken die nichts weiter machen im Netzwerk...also ein masssiver Broadcast der im Netzwerk rumgeht.
Mit Wireshark kenne ich mich aber nicht sogut aus, um den/die übeltäter zu finden wer da soviel feuer gibt. Ein Loop scheint es nicht zu sein, die Switche melden dahingehend keinen Fehler
Oder gibt es andere möglichkeiten das rauszufinden was da an jeden Port hingefeuert wird?
Mit Wireshark kenne ich mich aber nicht sogut aus, um den/die übeltäter zu finden wer da soviel feuer gibt. Ein Loop scheint es nicht zu sein, die Switche melden dahingehend keinen Fehler
Oder gibt es andere möglichkeiten das rauszufinden was da an jeden Port hingefeuert wird?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 564783
Url: https://administrator.de/contentid/564783
Ausgedruckt am: 24.11.2024 um 17:11 Uhr
33 Kommentare
Neuester Kommentar
Wenn du mit Wireshark reinhörst, wird dir zu jedem ausgewählten Paket die jeweilige MAC-Adresse des Absenders angezeigt.
Die gehst du dann auf deinen (managed) Switches suchen und findest damit den Switchport raus, an dem der Verursacher hängt.
Die gehst du dann auf deinen (managed) Switches suchen und findest damit den Switchport raus, an dem der Verursacher hängt.
Einfach einen Wireshark ohne irgendwelche Filter an einen der betroffenen Switchports hängen und sehen was der anzeigt.
Die oder der Hauptverursacher der Broad- oder Multicasts zeigt sich dann schon gleich an der schieren Masse der Pakete die immer gleich sind.
Damit hast du dann Mac Adresse und IP und kannst den immer sicher identifizieren. Kollege @LordGurke hat es oben schon gesagt.
Mit dem Wireshark bist du auf dem richtigen Weg !
Als Anfänger solltest du das hier dazu lesen:
https://www.heise.de/ct/artikel/Fehler-erschnueffeln-221587.html
Damit hast du dann das grundlegende Rüstzeug für den Kabelhai.
Die oder der Hauptverursacher der Broad- oder Multicasts zeigt sich dann schon gleich an der schieren Masse der Pakete die immer gleich sind.
Damit hast du dann Mac Adresse und IP und kannst den immer sicher identifizieren. Kollege @LordGurke hat es oben schon gesagt.
Mit dem Wireshark bist du auf dem richtigen Weg !
Als Anfänger solltest du das hier dazu lesen:
https://www.heise.de/ct/artikel/Fehler-erschnueffeln-221587.html
Damit hast du dann das grundlegende Rüstzeug für den Kabelhai.
Oh, als Tipp noch:
Bei der MAC-Adresse wird standardmäßig der Anfang mit dem lesbaren Herstellernamen ersetzt, aber das hilft dir bei der Suche auf den Switches nicht.
Die vollständige Adresse wird dir aber angezeigt, wenn du in der Paketansicht den Block "Ethernet" öffnest.
Bei der MAC-Adresse wird standardmäßig der Anfang mit dem lesbaren Herstellernamen ersetzt, aber das hilft dir bei der Suche auf den Switches nicht.
Die vollständige Adresse wird dir aber angezeigt, wenn du in der Paketansicht den Block "Ethernet" öffnest.
Ja nur Wireshark zeigt echt viel an, innerhalb von 5 sekunden werden mir 1400 einträge erzeugt 
Primär UDP und LLMNR und ARP Protokolle von verschiedensten IP Adressen/MAC Adressen
Primär UDP und LLMNR und ARP Protokolle von verschiedensten IP Adressen/MAC Adressen
Zitat von @Assassin:
Hallo, kennt sich hier eventuell jemand ganz gut mit Wireshark aus? Bei einem mittelständigen Unternehmen blinken alle Switchports pausenlos - auch die wo Geräte dran stecken die nichts weiter machen im Netzwerk...also ein masssiver Broadcast der im Netzwerk rumgeht.
Mit Wireshark kenne ich mich aber nicht sogut aus, um den/die übeltäter zu finden wer da soviel feuer gibt. Ein Loop scheint es nicht zu sein, die Switche melden dahingehend keinen Fehler
Hallo, kennt sich hier eventuell jemand ganz gut mit Wireshark aus? Bei einem mittelständigen Unternehmen blinken alle Switchports pausenlos - auch die wo Geräte dran stecken die nichts weiter machen im Netzwerk...also ein masssiver Broadcast der im Netzwerk rumgeht.
Mit Wireshark kenne ich mich aber nicht sogut aus, um den/die übeltäter zu finden wer da soviel feuer gibt. Ein Loop scheint es nicht zu sein, die Switche melden dahingehend keinen Fehler
Moin,
Alle (Netzwerk-)Stecker an den Switches ziehen und dann einen nach dem andren reinhängen. Irgendwann findest Du den schuldigen.
Oder Du kannst die Intervall-Methode nehmen, indem Du erst nur die eine Hälfte und danach nur die andre Hälfte reinsteckst. udn schaust ,beim welcher es blinkt. Und dann mmachst Du bei der blinkenden Häflte mit der Intervall-halbierung weiter.
lks
Naja, in nem Produktiven Mittelständigen Firmennetzwerk mit über 350 Clients ist das eher ungünstig mit dieser Methode :D
daher die frage, obs auch anders geht das mit Wireshark zu filtern was da alles so angeballert kommt auf allen Ports...
daher die frage, obs auch anders geht das mit Wireshark zu filtern was da alles so angeballert kommt auf allen Ports...
Zitat von @Assassin:
Naja, in nem Produktiven Mittelständigen Firmennetzwerk mit über 350 Clients ist das eher ungünstig mit dieser Methode :D
Naja, in nem Produktiven Mittelständigen Firmennetzwerk mit über 350 Clients ist das eher ungünstig mit dieser Methode :D
Manchmal ist sowas die einzige Methode, die funktioniert.
daher die frage, obs auch anders geht das mit Wireshark zu filtern was da alles so angeballert kommt auf allen Ports...
ich würde eher auf den switches accounting und error-logs aktivieren und schauen, welcher Port den highscroe im Traffic knackt.
mit wireshark könnte man das auch, aber da wirst Du zuviel traffic haben, um das "per hand" zu analysieren. Man kann natürlich einen nertzwerkmitschnitt machen und dann per skript die einzelen Datenquellen auszählen. Allerdings wirst Du mit Wireshark nur einen Bruchteil des traffices sehen.
lks
lks
1Naja, in nem Produktiven Mittelständigen Firmennetzwerk mit über 350 Clients
Ist das ein dummes, flaches Layer 2 Campus Netzwerk OHNE jegliche Segmentierung (VLANs) ??Wenn ja wäre das schon der erste grundsätzliche Fehler, denn kein vernünftiger Netzwerker packt mehr als 100 bis 150 Endgeräte in eine gemeinsame L2 Colloision Domain. Das nur mal nebenbei...
Kein Campus in diesem falle, aber ja, einfaches Layer2 Netzwerk mit bisher haufen unmanaged HP Switchen...jetzt gibts Managed switche und es wird auch bald segmentiert werden. Aber das Dauerfeuer gabs vorher schon.
Ich finde, 1400 Pakete bzw Wireshark einträge innerhalb von 5 sekunden schon recht viel (was auf allen Ports ankommt), oder?
Ich finde, 1400 Pakete bzw Wireshark einträge innerhalb von 5 sekunden schon recht viel (was auf allen Ports ankommt), oder?
HP hatings von aqui in 3.2.1.
Aber wie die Kollegen oben schon gesagt haben, das Netzwerk muss segmentiert werden, sonst wirst du dich dumm und dämlich suchen wenn nicht wie schon erwähnt die finde den Fehler mit ziehen und stecken durchführst.
Das die Netzwerklämpchen blinken wie verrückt ist in einem "größeren" Netz aber normal.
Oder wie hast du ausgemacht das ein massiver Broadcast umher geht? Ist vielleicht einfach viel los?
Grüße
Gansa28
Aber wie die Kollegen oben schon gesagt haben, das Netzwerk muss segmentiert werden, sonst wirst du dich dumm und dämlich suchen wenn nicht wie schon erwähnt die finde den Fehler mit ziehen und stecken durchführst.
Das die Netzwerklämpchen blinken wie verrückt ist in einem "größeren" Netz aber normal.
Oder wie hast du ausgemacht das ein massiver Broadcast umher geht? Ist vielleicht einfach viel los?
Grüße
Gansa28
Zitat von @Assassin:
Kein Campus in diesem falle, aber ja, einfaches Layer2 Netzwerk mit bisher haufen unmanaged HP Switchen... ... Aber das Dauerfeuer gabs vorher schon.
Kein Campus in diesem falle, aber ja, einfaches Layer2 Netzwerk mit bisher haufen unmanaged HP Switchen... ... Aber das Dauerfeuer gabs vorher schon.
Das ist auch kein Wunder. Bei 350 Stationen findet sich ganz viele, die dauernd plappern und sich allen anderen Mitteilen wollen. Ist wie in einer vollen Kneipe, wenn alle dauernd miteinander reden wollen. Ab einer gewissen größer der Kneipe hast Du dann Dauerplappern.
Soger wenn imemr nur ganz wenige plappern, ist durch dei statistusche Verteilung "immer was los
Ich finde, 1400 Pakete bzw Wireshark einträge innerhalb von 5 sekunden schon recht viel (was auf allen Ports ankommt), oder?
Kommt drauf an, was für Traffic das ist. Ich finde es eher etwas wenig - wenn es der komplette Netzwerkverkehr ist.
Prost.
lks
Das ist nicht der komplette Netzwerkverkehr - nur das was im Brodacsast/Multicast umher saust. Festgestellt habe ich das mit Wireshark dass da ganz schön was los ist auf jeden einzelnen Port, was meiner meinung nach nicht normal ist. Das sind IPv6 UDP pakete. Ich glaube ich habe schon den übeltäter gefunden...es gibt eine Stratus everRun Einheit (also 2 Knoten) wo die Business Links untereinander sich permanent abfragen ob die noch da sind...ich werd die mal in ein VLAN packen und die VMs die da rauskommen wollen in den Virtuellen Netzwerktreibern sagen das die in ein Tagged vlan gehen sollen - weil bei der everRun selber habe ich keine möglichkeit den Phys. port mit einem VLAN Tagg zu versehen - also mach ich den Port halt zu nem anderen nativen VLAN und die VMs müssen dann halt Tagged raussenden. mal schaun was das dann so bringt.
Die senden ca 280 Pakete pro sekunde über UDP von jedem Business link, aber als Ziel immer zur ff02::8998 - was auch immer das ist
Die senden ca 280 Pakete pro sekunde über UDP von jedem Business link, aber als Ziel immer zur ff02::8998 - was auch immer das ist
Zitat von @Assassin:
Die senden ca 280 Pakete pro sekunde über UDP von jedem Business link, aber als Ziel immer zur ff02::8998 - was auch immer das ist
Die senden ca 280 Pakete pro sekunde über UDP von jedem Business link, aber als Ziel immer zur ff02::8998 - was auch immer das ist
https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast ...
Hi
nur mal als Anmerkung: nur weil die LED am Port blinkt heisst es nicht das dort ein riesen Broadcasttraffic vorhanden, das kommt schon durch den "normalen" Broadcast und ist nichts besonderes.
Da du bereits sagtest das du ein 350 Client Netz ohne Segmentierung hast, ist der Broadcast eh groß - das ist in dem Fall "normal" wenn man von mit einem /<23 Netz Arbeitet - darum segmentiert man ja.
IPv6 ist auch vollkommen normalen durch das ND (so etwas -im groben- ähnliches wie Broadcast nur "besser".
1400 Einträge pro 5s ist nicht viel ... bei 350 Clients - wo jeder im Broadcast schreit ist das eher wenig
- ich habe in normalen Client-VLAN über 2k/5s ohne das irgendetwas auffällig "brüllt".
Gruß
@clSchak
nur mal als Anmerkung: nur weil die LED am Port blinkt heisst es nicht das dort ein riesen Broadcasttraffic vorhanden, das kommt schon durch den "normalen" Broadcast und ist nichts besonderes.
Da du bereits sagtest das du ein 350 Client Netz ohne Segmentierung hast, ist der Broadcast eh groß - das ist in dem Fall "normal" wenn man von mit einem /<23 Netz Arbeitet - darum segmentiert man ja.
IPv6 ist auch vollkommen normalen durch das ND (so etwas -im groben- ähnliches wie Broadcast nur "besser".
1400 Einträge pro 5s ist nicht viel ... bei 350 Clients - wo jeder im Broadcast schreit ist das eher wenig
- ich habe in normalen Client-VLAN über 2k/5s ohne das irgendetwas auffällig "brüllt".Gruß
@clSchak
Zitat von @clSchak:
1400 Einträge pro 5s ist nicht viel ... bei 350 Clients - wo jeder im Broadcast schreit ist das eher wenig - ich habe in normalen Client-VLAN über 2k/5s ohne das irgendetwas auffällig "brüllt".
1400 Einträge pro 5s ist nicht viel ... bei 350 Clients - wo jeder im Broadcast schreit ist das eher wenig
- ich habe in normalen Client-VLAN über 2k/5s ohne das irgendetwas auffällig "brüllt".Meine Rede.
Mir gefällt nur das dauer Blinken aller Ports nicht :D
Prinzipiell läuft ja alles...aber gefällt mir trotzdem nicht - darum jetzt auch andere Switche womit mal segmentiert werden kann Und wenn ich jetzt ein Broadcaster gefunden habe den man vieleicht eliminieren kann - warum nicht. habe den Support von Stratus mal angehauen warum der server das macht, und ob ich das zeugs in ein VLAN packen kann damits nicht mehr überall rumschwirrt...
Prinzipiell läuft ja alles...aber gefällt mir trotzdem nicht - darum jetzt auch andere Switche womit mal segmentiert werden kann
Und wenn ich jetzt ein Broadcaster gefunden habe den man vieleicht eliminieren kann - warum nicht. habe den Support von Stratus mal angehauen warum der server das macht, und ob ich das zeugs in ein VLAN packen kann damits nicht mehr überall rumschwirrt...
Wenn der Port nicht blinkt bei einem verbundenen Gerät: ist ein Problem - aber nicht wenn der blinkt, im TCP/IP Netzwerk hast du IMMER Aktivität auf den Ports das ist normal.
und ob ich das zeugs in ein VLAN packen kann damits nicht mehr überall rumschwirrt...
Das ist immer sinnvoll in einem vernünftig designten Netzwerk !!
Ja, darauf will ich hinaus mit der segmentierung Aber erstmal infos beim Hersteller (Stratus) einholen wie das ist bei so einem everRun Enterprise Fault-Tolerant serversystem...da kann man im laufendem betrieb den Stromstecker vom Server abziehen ohne das die User was mitbekommen - da wird der RAM inhalt, Prozessorstatus und HDD aller VMs in echtzeit synchronisiert über 8x 10Gb FC direktverbindung...aber diese verbindungen sind nicht im netzwerk. Aber das ding macht eine aktive portüberwachung aller Physikalischen Schnittstellen wo ein vSwitch drauf liegt... na mal schauen was da rauskommt.
Aber erstmal infos beim Hersteller (Stratus) einholen wie das ist bei so einem everRun Enterprise Fault-Tolerant serversystem...da kann man im laufendem betrieb den Stromstecker vom Server abziehen ohne das die User was mitbekommen - da wird der RAM inhalt, Prozessorstatus und HDD aller VMs in echtzeit synchronisiert über 8x 10Gb FC direktverbindung...aber diese verbindungen sind nicht im netzwerk. Aber das ding macht eine aktive portüberwachung aller Physikalischen Schnittstellen wo ein vSwitch drauf liegt... na mal schauen was da rauskommt.
erm 10G FC gibt es es nicht, wenn dann ist es 10G FCoE oder 2/4/8/16/32G FC. Das FibreChannel eine eigene Infrastruktur benötigt ist auch klar, da es kein Ethernet Protokoll ist . Darum muss das auch auf eigener Hardware laufen, wir dann voraussichtlich Brocade/Broadcom sein was die Switche betrifft - ggf. QLOGIC, aber eher unwahrscheinlich.
FaultTolerance ist nichts besonderes, das macht jede VMWare Installation auch.
Aber Back to Topic, ein hoher oder sehr hoher Broadcasttraffic kann auch ein Netzwerkloop sein, da du ja nur 08/15 Geräte einsetzt werden die das nicht kompensieren, geschweige denn STP oder LoopDetection (je nach Hersteller) die/der das regeln würde/n.
. Darum muss das auch auf eigener Hardware laufen, wir dann voraussichtlich Brocade/Broadcom sein was die Switche betrifft - ggf. QLOGIC, aber eher unwahrscheinlich.FaultTolerance ist nichts besonderes, das macht jede VMWare Installation auch.
Aber Back to Topic, ein hoher oder sehr hoher Broadcasttraffic kann auch ein Netzwerkloop sein, da du ja nur 08/15 Geräte einsetzt werden die das nicht kompensieren, geschweige denn STP oder LoopDetection (je nach Hersteller) die/der das regeln würde/n.
doch, RSTP und LoopDetection ist mit aktiv, ich kann also einfach ein Patchkabel nehmen und irgendwo in einer Datendoppeldose ein Loop bauen - da passiert nix außer dass ich eine Mail bekomme dass der und der Port auf Standby geschaltet wurde wegen STP.
Ein loop ist das nicht...das ist schon die everRun:
https://everrundoc.stratus.com/7.6.1.0/en-us/Default.htm#Help/P01_Users/ ...
und wegen den FC - stimmt, das sind keine FibreChannel karten, sondern normale Glasfaßer Netzwerkkarten mit 10Gbit (Intel X520-SR2)
Ein loop ist das nicht...das ist schon die everRun:
https://everrundoc.stratus.com/7.6.1.0/en-us/Default.htm#Help/P01_Users/ ...
und wegen den FC - stimmt, das sind keine FibreChannel karten, sondern normale Glasfaßer Netzwerkkarten mit 10Gbit (Intel X520-SR2)
da hast doch geschrieben das die nicht managebar sind, was denn nun? Wenn die STP können, muss man das auch konfgurierbar haben, ansonsten hast ja bei fast jedem Event einen Rootbridge-Change was dir immer das halbe Netz lahmlegt - wenn alle Geräte mit Prio arbeiten.
Und das STP der HP Gurken ist meistens nicht mit anderen STP Protkollen "kompatibel" - wenn ein HP auf 100% geht bleibt ein vergleichbarer Ruckus/Brocade bei 1-5% Load.
Und lt. deinem verlinkten Eintrag sendet der keinen Broadcast sondern gezielte UDP Pakete um einen Verbindungsabbruch festzustellen, bspw. durch eine defekte Leitung oder defekten Switch.
Das gesamte Layout scheint eher ein halbes Horrorscenario zu sein das ohne viel Verstand installiert wurde, mich wundert dann eher das das von dir genannte System "sauber" funktioniert.
Und das STP der HP Gurken ist meistens nicht mit anderen STP Protkollen "kompatibel" - wenn ein HP auf 100% geht bleibt ein vergleichbarer Ruckus/Brocade bei 1-5% Load.
Und lt. deinem verlinkten Eintrag sendet der keinen Broadcast sondern gezielte UDP Pakete um einen Verbindungsabbruch festzustellen, bspw. durch eine defekte Leitung oder defekten Switch.
Das gesamte Layout scheint eher ein halbes Horrorscenario zu sein das ohne viel Verstand installiert wurde, mich wundert dann eher das das von dir genannte System "sauber" funktioniert.
Und das STP der HP Gurken ist meistens nicht mit anderen STP Protkollen "kompatibel"
Das kommt weil die Gurken nur das primitive Single Span Verfahren können. HP Gurken eben... Das Design hört sich in der Tat sehr gruselig an da kann man dem Kollegen @clSchak nur zustimmen. Zumal es ja auch in einem dummen, flachen L2 Netzwerk liegt ohne jegliche Segmentierung. Da solltest du wirklich nochmal drüber nachdenken...
neee...die alten bisherigen Switche waren Nicht managebar...die neuen natürlich schon, und da ist auch das LoopDetection eingeschaltet und RSTP genauso. Alle Switche sind mit 10G untereinander verbunden...da werden von haus aus die ganzen 1G Loop- verbindungen die ein user machen kann direkt geblockt.
Jetzt sind wie gesagt neue Switche drin, damit eben langsam das Netzwerk segmentiert werden kann und man auch mal was sieht was da so losgeht im Netzwerk
Jetzt sind wie gesagt neue Switche drin, damit eben langsam das Netzwerk segmentiert werden kann und man auch mal was sieht was da so losgeht im Netzwerk
Hoffentlich dann nicht wieder überbuchte HP Gurken...?!
Nein, ubiquiti unifi usw pro 48
Igitt, das ist ja noch schlimmer. Proprietärer Mist mit Vendor Lock... Vom Regen in die Traufe aber manchen ist ja einfach nicht zu helfen...
Naja eigentlich sind die nicht so schlim... Haben wir schon an einigen stellen im einsatz...
Es gibt hakt nicht nur Cisco... Auch andere können gute produkte haben ;)
Aber ja, in anderen firmen sind auch SG350 im einsatz ;)
Es gibt hakt nicht nur Cisco... Auch andere können gute produkte haben ;)
Aber ja, in anderen firmen sind auch SG350 im einsatz ;)
naja, sparen am falschen Ende, evtl. im Edge Bereich kann man so etwas einsetzen, aber im Core Bereich definitiv nicht.
als Core dient eine Securepoint RC1000 mit 10G Uplink ports...
Das ist eine Firewall?! Im Core und Aggregationlayer setzt man in Regel L2 und ggf. L3 taugliche Hardware ein die über eine entsprechende Backplane verfügen um volle Leistung zu fahren (auf allen Ports) und das im HA Modus oder als Stack (oder welche Verfügbarkeitssteigernde Methode man auch wählt) - aber ein Einzelgerät und keine FW, die nicht über einer entsprechenden Backplane, geschwiegen denn den passenden ASICS verfügt.
Wie bereits gesagt: gruseliges Layout und Design.
PS: Selbst wenn ich man alle Werte addiert, bei 2 x 10G Ports musst du mindestens eine 40G Backplane haben und danach sieht es bei der RC1000 nicht aus, wenn man dann noch Firewall usw. abzieht bleibt für das normale L3 Routing nicht mehr viel übrig.
Wie bereits gesagt: gruseliges Layout und Design.
PS: Selbst wenn ich man alle Werte addiert, bei 2 x 10G Ports musst du mindestens eine 40G Backplane haben und danach sieht es bei der RC1000 nicht aus, wenn man dann noch Firewall usw. abzieht bleibt für das normale L3 Routing nicht mehr viel übrig.
Hmm, gut, die Securepoint kümmert sich halt ums Layer 3 VLAN Routing. Der USW Pro 48 ist doch ein non blocking switch. Richtige redundanz kann man eh nicht schaffen weil die ganzen Client PCs auch nur eine Netzwerkkarte haben. Dafür haben wir aber immer ein switch auf Cold Standby liegen dass wenn einer ausfällt, der schnell getauscht werden kann. Die unterverteilungen im Gebäude sind halt so gebaut dass alles Sternförmig verläuft, aber es keine ringstrecke gibt, damit ist richtiges STP eh nicht zu realisieren. würde ja nur was bringen, wenn jeder unterverteiler über eine strecke direkt mit der anderen unterverteilung sprechen könnnte.
wenn du die neuen Switche eh im Einsatz hast, warum schaust dann nicht dort nach, z.B. Port Utilisation oder limitierst Broadcast im allgemeinen
