<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="de">
	<id>https://wiki-de.moshellshocker.dns64.de/index.php?action=history&amp;feed=atom&amp;title=Broadcast-Sturm</id>
	<title>Broadcast-Sturm - Versionsgeschichte</title>
	<link rel="self" type="application/atom+xml" href="https://wiki-de.moshellshocker.dns64.de/index.php?action=history&amp;feed=atom&amp;title=Broadcast-Sturm"/>
	<link rel="alternate" type="text/html" href="https://wiki-de.moshellshocker.dns64.de/index.php?title=Broadcast-Sturm&amp;action=history"/>
	<updated>2026-06-08T14:10:00Z</updated>
	<subtitle>Versionsgeschichte dieser Seite in Wikipedia (Deutsch) – Lokale Kopie</subtitle>
	<generator>MediaWiki 1.43.8</generator>
	<entry>
		<id>https://wiki-de.moshellshocker.dns64.de/index.php?title=Broadcast-Sturm&amp;diff=1117629&amp;oldid=prev</id>
		<title>imported&gt;DarkMoon am 22. September 2023 um 10:12 Uhr</title>
		<link rel="alternate" type="text/html" href="https://wiki-de.moshellshocker.dns64.de/index.php?title=Broadcast-Sturm&amp;diff=1117629&amp;oldid=prev"/>
		<updated>2023-09-22T10:12:57Z</updated>

		<summary type="html">&lt;p&gt;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;Neue Seite&lt;/b&gt;&lt;/p&gt;&lt;div&gt;[[Datei:Broadcast storm.png|thumb|Schematische Darstellung eines Broadcast-Sturms]]&lt;br /&gt;
Ein &amp;#039;&amp;#039;&amp;#039;Broadcast-Sturm&amp;#039;&amp;#039;&amp;#039; ist die starke Anhäufung von [[Broadcast]]- und [[Multicast]]-Verkehr in einem [[Rechnernetz]] wie beispielsweise [[Ethernet]]. Im Endstadium eines Broadcast-Sturms können keine neuen Netzwerkverbindungen mehr aufgebaut werden, und bestehende Verbindungen werden möglicherweise unterbrochen. Besonders in großen [[Broadcast-Domäne|Broadcast-Domänen]] kann sich durch verschiedene Ursachen bei einem Broadcast-Sturm die [[Antwortzeit]] des Netzwerks durch einen [[Schneeballeffekt]] dramatisch erhöhen.&lt;br /&gt;
&lt;br /&gt;
== Ursachen ==&lt;br /&gt;
Die häufigste Ursache ist die redundante Verkabelung mit zwei oder mehr [[Uplink|Uplinks]] zwischen zwei [[Switch (Computertechnik)|Switches]]. In einem solchen Fall werden Broadcasts und Multicasts auf alle Ports weitergeleitet mit Ausnahme des Ports, von dem der [[Datenverkehr]] kam. Dadurch wird eine Schleife erzeugt, ein [[Switching-Loop|Switching Loop]], und die Switches leiten die Broadcasts des jeweils anderen Switches weiter. Darüber hinaus kann ein Broadcast-Sturm z.&amp;amp;nbsp;B. auch durch [[Denial of Service|Denial-of-Service]]-Angriffe (wie den [[Smurf-Angriff]] oder den [[Fraggle-Angriff]]) oder durch eine fehlerhafte [[Netzwerkkarte]] ausgelöst werden.&lt;br /&gt;
&lt;br /&gt;
== Gegenmaßnahmen ==&lt;br /&gt;
* [[Shortest Path Bridging]], und [[Spanning Tree Protocol]] ist geeignet, Schleifen zwischen Switches sinnvoll zu verwalten. In Metropol-Netzwerken werden Broadcast-Stürme durch [[Ethernet Automatic Protection Switching|Ethernet Automatic Protection Switching (EAPS)]] verhindert.&lt;br /&gt;
* Filterung von Broadcasts durch Layer-3-Geräte, im Normalfall durch [[Router]], zum Teil auch durch [[BRouter]].&lt;br /&gt;
* Physische Segmentierung einer Broadcast-Domäne durch Router oder [[Layer-3-Switch]]es.&lt;br /&gt;
* Logische Segmentierung einer Broadcast-Domäne durch den Einsatz von [[VLAN|VLANs]].&lt;br /&gt;
* Router und [[Firewall|Firewalls]] können so konfiguriert werden, dass sie bösartige oder überdurchschnittlich viele Broadcasts erkennen und blockieren.&lt;br /&gt;
&lt;br /&gt;
== Fehlinterpretationen ==&lt;br /&gt;
* Eine weit verbreitete Fehlinterpretation ist, dass Routing-Schleifen etwas damit zu tun haben. Router, die auf [[Vermittlungsschicht|Layer 3]] des [[OSI-Modell|OSI-Modells]] arbeiten, leiten jedoch keine [[OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht|Layer-2]]-Broadcasts weiter, wie es Switches tun.&lt;br /&gt;
* Eine weitere unzutreffende Annahme ist, dass Router keine Layer-3-Broadcasts weiterleiten können. Es gibt Routing-Protokolle, die Broadcasts zu anderen Netzwerken weiterleiten. &lt;br /&gt;
* Ebenfalls eine Fehleinschätzung ist, dass nur Router eine Broadcast-Domäne begrenzen und damit Broadcast-Stürme eingrenzen können. Wie bei den Gegenmaßnahmen erwähnt, können dies auch Switches mit VLANs oder Layer-3-Funktionalitäten.&lt;br /&gt;
* Außerdem kann ein Broadcast nicht mit einem Broadcast beantwortet werden. Allerdings kann ein Broadcast dazu genutzt werden, herauszufinden, wie auf einen empfangenen Broadcast geantwortet werden kann. In einer redundanten Topologie kann ein solcher zweiter Broadcast dasjenige [[Netzwerkschnittstelle|Netzwerkinterface]] erreichen, welches den initialen Broadcast gesendet hat.&lt;br /&gt;
&lt;br /&gt;
== MANET-Broadcast-Stürme ==&lt;br /&gt;
In einem mobilen [[Ad-hoc-Netz]] (MANET) werden Pakete zur Anforderung von Routing-Informationen (RREQ) meist per Broadcast verschickt, um neue Routen zu finden. Diese RREQ-Pakete verursachen möglicherweise Broadcast-Stürme. Ein Ansatz, diese zu verringern, besteht darin, manche [[Host (Informationstechnik)|Hosts]] für erneute Broadcasts zu sperren.&lt;br /&gt;
&lt;br /&gt;
== Quellen ==&lt;br /&gt;
#Appendix E: Broadcasts in Switched LAN Internetworks [http://www.cisco.com/univercd/cc/td/doc/cisintwk/idg4/nd20e.htm]&lt;br /&gt;
#Defense Against the DoS/DDoS Attacks on Cisco Routers [http://web.archive.org/web/20110621083038/http://www.securitydocs.com/library/2553] ([[Memento (Webarchivierung)|Memento]] vom 21. Juni 2011 im [[Internet Archive|Internetarchive]]) (englisch) &lt;br /&gt;
#Disassociation Broadcast Attack Using ESSID Jack [http://manageengine.adventnet.com/products/wifi-manager/disassociation-broadcast-attack.html]&lt;br /&gt;
#The Broadcast Storm Problem in a Mobile Ad Hoc Network [http://www.cs.berkeley.edu/~culler/cs294-f03/papers/bcast-storm.pdf] (PDF; 1,2&amp;amp;nbsp;MB)&lt;br /&gt;
&lt;br /&gt;
[[Kategorie:Rechnernetze]]&lt;br /&gt;
[[Kategorie:Sicherheitslücke]]&lt;/div&gt;</summary>
		<author><name>imported&gt;DarkMoon</name></author>
	</entry>
</feed>