4
Broadcast-Strom VLAN-übergreifend?
Hi,
eine Frage, wir haben versuchsweise mal einen Broadcast-Strom in einem VLAN provoziert. Dabei ist uns aufgefallen, dass dann auch alle anderen VLANs davon betroffen sind, sprich nicht mehr arbeiten. Die Frage ist, sollten VLANs nicht gerade die Broadcast-Domänen auftrennen? Ein Inter-VLAN-Routing findet nicht statt, wobei das dann ja eh L3 und nicht L2 wäre...
Denken wir falsch?
Grüße
Gustel
eine Frage, wir haben versuchsweise mal einen Broadcast-Strom in einem VLAN provoziert. Dabei ist uns aufgefallen, dass dann auch alle anderen VLANs davon betroffen sind, sprich nicht mehr arbeiten. Die Frage ist, sollten VLANs nicht gerade die Broadcast-Domänen auftrennen? Ein Inter-VLAN-Routing findet nicht statt, wobei das dann ja eh L3 und nicht L2 wäre...
Denken wir falsch?
Grüße
Gustel
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: 347599
Url: https://administrator.de/forum/broadcast-strom-vlan-uebergreifend-347599.html
Ausgedruckt am: 22.12.2024 um 03:12 Uhr
4 Kommentare
Neuester Kommentar
Hi Gustel,
kann es sein, dass der Broadcast-Storm einfach deine Switche ans Limit gebracht hat und deshalb alle VLAN's ausgestiegen sind? Oder hast du geprüft, ob auf den anderen VLAN's auch Pakete ankommen?
Gruß, JD
kann es sein, dass der Broadcast-Storm einfach deine Switche ans Limit gebracht hat und deshalb alle VLAN's ausgestiegen sind? Oder hast du geprüft, ob auf den anderen VLAN's auch Pakete ankommen?
Gruß, JD
dass dann auch alle anderen VLANs davon betroffen sind
Das ist technisch falsch oder nur sehr oberflächlich und laienhaft ausgedrückt !Einen Broadcast Storm können, wie der Name es ja schon selber sagt, nur Broad- oder Multicast Pakete auslösen.
Diese werden aber logischerweise niemals von einem VLAN in ein anderes übertragen, da die VLANs komplett isolierte Layer 2 Broadcast Domains sind.
Also auch hier sagt schon allein der Name das lokale Brodcast immer zwingend auf ein VLAN beschränkt sind !
Brodcast Pakete aus VLAN x tauchen also niemals in VLAN y auf. Das ist technisch unmöglich.
Nichtmal wenn eine Routing Beziehung besteht (Layer 3 Switch) ist das möglich, denn wie jeder weiss leiten auch Router niemals Broad- und Multicast Pakete in andere Segmente.
Ein Grundpfeiler der IP Segmentierung.
Tun sie es doch und kann man das auch mit einem Wireshark nachweisen (was du hoffentlich gemacht hast ?!) gibt es einen gravierenden Konfigurationsfehler im Netzwerk, denn dann wären fatalerweise diese VLAN Segmente mit einer Bridge verbunden was erhebliche Probleme und Fehlfunktionen in so einem Netz nach sich ziehen würde.
Kannst du also mit einem Wireshark Brodcast Pakete aus VLAN x auch in VLAN y sehen hast du ein echtes Problem.
Andererseits ist es möglich das die CPU Last des Switches durch das Provozieren des Broadcast Sturmes auch über 70% oder höher geht. Das hätte dann eine erhebliche Auswirkung auf die Gesamtperformance des Switches, denn ein überlasteter Switch beeinträchtigt natürlich und logischerweise dann ALLE Vlans auf dem Switch und natürlich auch noch andere Switch Funktionen generell.
Eine Überlappung des Broadcast Traffics darf aber niemals und zu keinen Umständen auftreten sofern das Netz bzw. der oder die Switches sauber konfiguriert sind !
Solche Binsenweisheiten und Basiscs im Netzwerk kennt aber auch der Azubi im ersten Lehrjahr....
Danke für eure Antworten, die uns darin bekräftigen, dass wir nicht ganz blöd sind ;)
Es kann natürich sein, dass die Switche so in die Knie gehen, dass die - nicht betroffenen - VLANs auch nicht mehr korrekt ausgeführt werden.
Ich würde es nicht technisch falsch nennen, es ist die Realität ;) Stecke ich einen Loop, sind die durch den Loop zwar nicht direkt in ihrer Broadcast Domäne betroffenen VLANs trotzdem tot. Was sie ja nicht unerheblich *betrifft*. Wie der erste Kollege meinte, vermutlich durch eine Überlastung der SWs.
Könnten wir noch machen. Das war nur ein kleiner Test, ob die LBD der Switche auch funktioniert. Für eine größere Analyse war (noch) keine Zeit.
PS: Kann es auch damit zusammenhängen, dass die Uplinks (Trunks) auf denen die VLANs tagged anliegen so ausgelastet werden? Darüber läuft ja dann auch der ganze Broadcast-Verkehr. Die Idee kam uns auch noch...
Es kann natürich sein, dass die Switche so in die Knie gehen, dass die - nicht betroffenen - VLANs auch nicht mehr korrekt ausgeführt werden.
Zitat von @aqui:
dass dann auch alle anderen VLANs davon betroffen sind
Das ist technisch falsch oder nur sehr oberflächlich und laienhaft ausgedrückt !Ich würde es nicht technisch falsch nennen, es ist die Realität ;) Stecke ich einen Loop, sind die durch den Loop zwar nicht direkt in ihrer Broadcast Domäne betroffenen VLANs trotzdem tot. Was sie ja nicht unerheblich *betrifft*. Wie der erste Kollege meinte, vermutlich durch eine Überlastung der SWs.
Tun sie es doch und kann man das auch mit einem Wireshark nachweisen (was du hoffentlich gemacht hast ?!) gibt es einen gravierenden Konfigurationsfehler im Netzwerk, denn dann wären fatalerweise diese VLAN Segmente mit einer Bridge verbunden was erhebliche Probleme und Fehlfunktionen in so einem Netz nach sich ziehen würde.
Könnten wir noch machen. Das war nur ein kleiner Test, ob die LBD der Switche auch funktioniert. Für eine größere Analyse war (noch) keine Zeit.
PS: Kann es auch damit zusammenhängen, dass die Uplinks (Trunks) auf denen die VLANs tagged anliegen so ausgelastet werden? Darüber läuft ja dann auch der ganze Broadcast-Verkehr. Die Idee kam uns auch noch...
VLANs auch nicht mehr korrekt ausgeführt werden.
Was genau meinst du mit dieser Bemerkung ?? Was ist "ausgeführt" ?Klappt das Layer 2 Forwarding dann nicht mehr oder fluten die Switches dann tatsächlich VLAN spezifischen Traffic in fremde VLANs ?
Letzteres wäre gravierend und ein sehr schlimmer Bug, denn auch unter Überlast passiert sowas niemals.
Lediglich das die Switches dann in die Knie gehen und Kommunikation sehr zäh, langsim bis unmöglich wird.
Niemals aber sollte fremder Broadcast Traffic geflutet werden. Das wäre ein Unding und ganz sicher ein Firmware Bug im Switch.
es ist die Realität
Oha.... gruselig !!! Das ist dann ein Fall für die ganz schnelle Entsorgung auf dem Recycling Hof.WAS genau sind das für Frames ?? Hier bist du leider mal wieder sehr oberflächlich
Ist das möglich das das Spanning Tree BPDUs sind die da loopen und die du auch in anderen VLANs siehst.
Wenn du einen Billigswitch hast (was leider zu vermuten ist) der kein sog. PVSTP (Per VLAN Spanning Tree) kann dann wäre das normal.
Solche Billig Switches supporten meist nur ein Single Span Verfahren, also einen einzigen Spanning Tree Prozess der alle VLANs bedient statt wie beim besseren PVSTP einen separaten, eigenen Spanning Tree Prozess pro VLAN.
Bei Single Span Verfahren siehst du diese gleichen BPDUs in allen VLANs gleich.
Was sagt also dein Wireshark ?? Sind das BPDUs.
Abgesehen davon sollte ein Switch bei einem solchen Loop nicht in die Knie gehen. Das unterbindest du übrigens sicher indem du gerade Spanning Tree aktivierst und zwingend dazu immer eine Port Loop Detection damit du nicht von externen Switches und eigen Port BPDUs geflutet werden kannst.
Heutzutage ein Standard und Muss um Netze Loop fest und sicher zu machen !!
vermutlich durch eine Überlastung der SWs.
Auf einem besseren Switch kann man die CPU Auslastung per CLI, GUI oder mindestens per SNMP abfragen !! Hast du das mal gemacht ??Per SNMP eignet sich das STG Tool hervorragend dazu:
RX Dropped Pkts Problem
Der Switch sollte nie über 5-10% CPU gehen !
LBD der Switche ??
Lustiger Byte Detektor ??auf denen die VLANs tagged anliegen so ausgelastet werden?
Nein !Die werden in Silizium als direkt im ASIC des Switches geforwardet. Broad- und Multicast erfordert immer ein Kopieren dieser Paket auf alle aktiven Ports was die Switch CPU machen muss.
Genau der tiefere Sinn warum man die Broad- und Multicast Last in Netzen möglichst immer gering halten sollte und niemals mehr als max. 150 Clients in einem L2 Segment (VLAN) betreiben sollte !!
Segmentierung ist also das Zauberwort !
