Diskussion:Switch (Netzwerktechnik)/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Switch (Netzwerktechnik)/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Switch_(Netzwerktechnik)/Archiv/1#Thema_1

Managed Switch?!

Was ist unmanaged - smart managed und full-managed?

Diese Frage solltest Du den Marketingabteilungen der Switch-Hersteller stellen... Wenn ein Switch managed ist, bedeutet das, dass man sich darauf einloggen kann um irgendwelche Dinge einzustellen. Zum Beispiel kann man Ports konfigurieren, VLANs einrichten und weiß der Geier was sonst noch. Der Funktionsumfang und wie das Management genannt wird, liegt im Ermessen des Herstellers. Unmanaged Switches sind just that - man kann nichts einstellen. Sie funktionieren einfach. --Echoray 15:38, 17. Aug 2005 (CEST)

Uplink (Verbindung mehrerer Switches)

Dieses Thema wäre, finde ich, noch einen Absatz wert. Leider entziehen sich die Details auf diesem Gebiet meiner Kenntnis. 24.07.2005 14:20

Eigentlich hat er Recht. Ist zwar mittlerweile nicht mehr 100% aktuell (GB-Ethernet generell und viele aktuelle Switches beherrschen auto-uplink) aber das Thema fehlt gänzlich. -cljk 14:42, 24. Jul 2005 (CEST)

Auto Uplink ist eine Funktion von Switch-Ports. Der entsprechende Port erkennt selbstständig ob er mit einem Switch verbunden ist (Uplink) oder mit einem Endgerät. Beim Uplink kreuzt er automatisch die notwendigen Kontakte. Bei Switches mit Auto Uplink ist kein Kreuzkabel erforderlich. MB, 26. Jan 2006

Nun das trifft es auch nicht ganz. Also erstens heißt dieses Feature Auto-MDI/MDIX und nicht Auto-Uplink und zweitens hat Uplink mehrere Bedeutungen:

• die Verbindung zwischen zwei Switchen, wobei eigentlich die Verbindung zwischen Access- und Core-Ebene gemeint ist (vom Core zum Access wäre es der Downlink)
• ganz schwammig bedeutet Uplink für den Switch, daß mehr als eine MAC-Adresse hinter einem Port aktiv wird - der Switch sollte also STP auf diesem Port sprechen oder seine Adresstabelle (für diesen Port) vergrößern oder was auch immer...

Nun ist das ganze Geraffel mit dem Uplink historisch begründet, als man an einem Hub oftmals einen Port hatte, der zwischen MDIX und MDI (per Schalter) umschaltbar war - man sich also ein Kreuzkabel sparen konnte. Später als die Switche aufkamen hatte der Uplinkport oftmals eine höhere Geschwindigkeit (alle Ports 10Mbit/s, der Uplinkport 100Mbit/s). Bei Billigswitches bürgerte sich dann irgendwann mal ein, einen Port "doppelt" aufzulöten - einmal als MDIX und einmal als MDI, was zu lustigen Phänomenen führt, wenn man nicht genau hinsieht und beide Ports zum Anschließen von Stationen benutzt. Übrigens: ein Switchport ist ein MDIX-Port. Erst wenn man diesen wie auch immer zum MDI-Port macht kann man ihn direkt mit dem MDIX-Port eines anderen Switch verbinden. Also MDIX ist die normale Operation und erst das Kreuzkabel macht das MDIX (analog doppelter Verneinung) wieder zum MDI... Bsteinmann 14:34, 24. Mai 2006 (CEST)

Unterschied zwischen Layer2 und Layer3 Switch

Kann mir bitte jemand den Unterschied der Funktionsweise eines Layer2 und eines Layer3 Switches erklären, außer dass sie auf verschiedenen Schichten des OSI-Modells arbeiten? Danke

Das mit dem OSI-Modell ist das elementare an der Sache. Im OSI-TCP Modell ist auf Schicht 2 reine Rechner-Rechner-Verbindung - also Ethernet/MAC in den meisten Fällen, während in der Schicht 3 die TCP-Verbindung residiert. Sprich: L3-Switches können auch anhand der IP-Adressen entscheiden, was Sie wohin leiten. -cljk 22:48, 1. Mär 2005 (CET)

Korrektur: Layer 3 ist die Netzwerk-Schicht. Dort wird das IP-Protokoll eingesetzt. TCP kommt erst auf Layer 4 (Transport-Schicht).

Morepower 09:35, 25. Aug 2005

Aus meiner Sicht ist ein Layer3-Switch immer VLAN-fähig und hat eine Routingfunktion. Er kann also zwischen IP-Netz vermitteln, was ein Layer2-Switch nicht kann. Ein Layer3-Switch arbeitet mit Routingtabellen, während der Layer2-Switch mit MAC-Tabellen arbeitet.

Der Unterschied zwischen einem Layer3-Switch und einem Router besteht darin, dass der Router (i.d.R.) kein Switching durchführen kann, dafür aber weitere Schnittstellen als Ethernet besitzt (z.B. DSL).

Rößle 4. Nov. 2006

Titel

Wenn "hub" unter "Hub_(Netzwerk)" ist, warum dann nicht auch "Switch" und "switch_(netzwerk) bzw. vice versa? => vereinheitlichen. Kann das mal jemand machen? Kenn mich da nicht so aus...

-- Sina Eetezadi 14:11, 12. Feb 2005 (CET)

Weil es auch Hubs für USB, Firewire etc. gibt. Übrigens werde ich deinen Link wieder entfernen. - cljk 14:41, 12. Feb 2005 (CET)

Hmm, okay daran hatte ich nicht gedacht. Klar, wenn Du denkst der Link is unütz, kein Problem. Ich dachte er wäre nützlich...-- Sina Eetezadi 15:54, 12. Feb 2005 (CET)

_________________________________________

ist "Switch" nicht eigentlich die Kurzform für "Switching Hub"? Flups 03:10, 3. Okt 2002 (CEST)

nein, "Switching Hub" ist nur ein Marketingbegriff um einem Hub den Namen "Switch " geben zu können. Ein "Switching Hub" ist einfach ein 10/100Mbit Hub, bzw eigentlich sinds zwei Hubs, einer 10Mbit einer 100Mbit, mit ner Bridge dazwischen die die 10/100 Umsetzung macht. --Tali 13:59, 17. Jun 2003 (CEST)

Allein schon das große Suchergebnis von Google bei der Suche nach Switched Ethernet Switching Hub spricht absolut dagegen, dass das ein Marketing-Begriff ist. Soweit ich mich erinnere, wurde bei der Einführung von Switched Ethernet die Funktionsweise des Hubs erweitert und diese neuen Hubs dann Switching Hubs genannt. Switch hat sich dann als Kurzform davon eingebürgert.--ChristianHujer 10:41, 3. Feb 2005 (CET)

---

Eigentlich ist ein Switch eher eine Bridge als ein Hub. Sollten wir den Switch und Bridge Artikel zu einem zusammenfassen? --Tali 14:03, 17. Jun 2003 (CEST)

Da eine Bridge und ein Switch doch auch unterschiedliche Aufgaben haben, z.B. werden Bridges eingesetzt, um 10Base2 mit 100BaseT zu verbinden, wofür es aber praktisch keine Switches gibt, bin ich gegen eine Zusammenlegung der Artikel. Aber ich stimme zu, dass ein Hinweis auf Bridge unbedingt schon in der Definition sein muss.--ChristianHujer 10:41, 3. Feb 2005 (CET)

Also ein Switch ist eine Bridge mit vielen Ports. Gaaanz früher wurden Switches auch mal als Multiport-Bridge bezeichnet, was den Kern der Sache ganz gut trifft. Einen Switch mit einem Hub zu vergleichen verleitet sicher schnell, da sie im Endeffekt ziemlich das selbe erreichen. Aber ein Hub (Repeater) ist ein Koppelelement im L1 des OSI-Modells und eine Bridge / ein Switch ein Koppelelement im L2 des OSI-Modells! Das Beispiel mit 10Base2 auf 10BaseT bezieht sich auf sogenannte Medienkonverter, bei denen es sich üblicherweise um Bridges handelt. Es soll aber auch Hersteller gegeben haben, die Medienkonverter als Repeater (Hubs) aufgebaut haben. Bsteinmann 11:30, 24. Mai 2006 (CEST)

Begriffsklärung

Warum steht eigentlich unter Switch der LAN-Artikel und nicht die Begriffsklärung, wie es normalerweise üblich ist ???

Was heißt schön üblich? Das Konstrukt nennt sich glaub' ich "Begriffsklärung nach Modell II" oder so. Dabei steht so wie hier unter dem Stichwort der Artikel der häufigsten Wortbedeutung, und alle anderen Sachen werden im Begriffsklärungsartikel auseinanderdividiert. --Echoray 10:15, 12. Sep 2004 (CEST)

Hm. Na dann. Hab ich bisher noch nirgends so gesehn, aber das muss ja nix heissen. Dann scheint das ja so ok zu sein.217.80.80.241 16:06, 12. Sep 2004 (CEST)

Geändert. --Hinrich 14:23, 21. Sep 2004 (CEST)

Switch Nachrichtentechnik/Computer/Telefon

Gemeinsamkeiten und Unterschiede zwischen Switches für Daten- und Telefonnetze sollten besser rausgearbeitet werden. --Marc van Woerkom 22:11, 21. Sep 2004 (CEST)

Bild

Frage: auf dem Bild ist grad mal ganz oben am Rand ein Switch zu sehen...oder guch ich falsch? Das ist doch ein Patchfeld. Soll ich einen bei uns im Rack fotografieren? --cljk 15:00, 15. Okt 2004 (CEST)

Backplane

Welche Backplane ist bei billigen Switches (SOHO) üblich? Wenn der Hersteller den Durchsatz der Backplane nicht angibt, sollte ich davon ausgehen, dass es nur 100 oder 200 MBit Backplane sind oder dass die Backplane für ein gleichzeitiges Senden aller Ports ausgelegt ist (also bei 8 Ports 0,8/1,6 GBit, bei 16 Ports 1,6/3,2 GBit)? --Matthäus Wander 17:38, 3. Mär 2005 (CET)

Fragment Free

Die neu hinzugefügte Fragment-Free-Methode ist noch etwas unausgegoren. Mir erschließt sich nicht, wie man auf einem Ethernet-Frame einen Fehlerfreiheitswert nur für die ersten 64 Byte berechnen könnte, wenn das Paket nicht zufällig 64 Byte lang ist. Geht es nicht viel eher darum, dass man einerseits keinen Müll weiterleitet, der bereits aus irgendeinem Grund eine Kollision hinter sich hat, und andererseits kurz abwartet, bis das "Kollisionsfenster" vorüber ist? Ist Fragment-Free eigentlich eine reine Halbduplex-Switchingmethode? Bei Vollduplex hat man das Kollisionsproblem doch ohnehin erschlagen? --Echoray 11:45, 5. Mai 2005 (CEST)

Zu letzterem: Nein, da Du ja nicht weiß, was am anderen Ende der Vollduplexverbindung hängt. Falls da z.B. ein weiterer Switch mit early oder speculative forwarding dranhängt, können durchaus abgebrochene Pakete auftauchen. -- [[Benutzer:M-O-W|MOW]] 05:29, 4. Sep 2006 (CEST)

An einem Switch kann ja immer auch ein Hub (unabhängig von der Switchingmethode) hängen, so dass er Halbduplex arbeiten muss. --Michael Rößle 16:09, 4. Nov. 2006 (CET)

ARP-Spoofing

Ich hatte den Satz zwar ursprünglich nicht geschrieben, der just gelöscht wurde ... denke aber schon, er hat was mit einem Switch zu tun, weil es die einzige Möglichkeit ist, über ein geswitchtes Netzwerk zu sniffen... -cljk 11:58, 16. Jun 2005 (CEST)

Der folgende Satz ist IMHO falsch:

"Antwortet der Angreifer [auf eine ARP-Anfrage] nun mit einer gefälschten MAC-Adresse (nicht mit seiner eigenen, daher die Bezeichnung Spoofing) zur erfragten IP, so wird das Opfer seine Netzwerkpakete an den Angreifer senden [...]."

Stimmt das wirklich? Würde der Angreifer seine tatsächliche MAC-Adresse in der ARP-Antwort nicht verwenden, sondern eine gefälschte, könnte er doch gar keine Antworten erhalten, es sei denn, er setzt seine eigene MAC-Adresse auf die gefälschte -- aber ich denke nicht, dass die Aussage so gemeint war. Ich verstehe ARP-Spoofing so, dass ein Angreifer seine eigene MAC-Adresse zur gesuchten IP-Adresse als ARP-Antwort sendet, anstatt den tatsächlichen Empfänger antworten zu lassen. --CosmoDad 03:36, 31. Mai 2006 (CEST)

Photonic Switches

Hallo, weiss jemand was Photonic Switches sind? Meine erste kurze Quellenrecherche besagt, dass diese Switche die eingehenden optischen Signale nicht in elektrische Singanle umwandeln, sondern dass die Packete gleich in der optischen Form an den Zielport weitergeleitet werden. Diese Switche sollen viel Leistungsfähiger sein als herkömliche Switche. Ein kleiner Absatz wäre dazu auch mal interessant, da der Markt für Photonic Switches ein stetig wachsender Markt ist. -- Alvo 12:28, 15. Okt 2005 (CEST)

Es ist fraglich, ob das in den Artikel reinpasst, da das Funktionsprinzip von "Photonic Switches" stark von dem herkömmlicher Switches abweicht... Die Dinger gehören eher in einen eigenen Artikel... Wie ich grad seh gibt es schon Wikis die mehr oder weniger mit dem Thema zu tun haben: http://de.wikipedia.org/wiki/Photonischer_Kristall bzw. http://de.wikipedia.org/wiki/Photonisches_Netz. -- DarknesS 09. Dez 2005 (CEST)

Vorteil: Automatische Erkennung des Netzwerkkabels

Viele Switches können automatisch erkennen, ob an einem Port ein Patch- oder ein Crossover-Kabel hängt. Da das eigentlich jeder aktuelle Switch kann, könnte man das doch eigentlich als Vorteil anführen. --Redeemer 22:48, 13. Apr 2006 (CEST)

Dieses ist Auto-MDI/MDIX und hat mit der Funktionalität als Switch an sich nix zu tun. Die Aussage, daß dies jeder aktuelle Switch könnte ist sicher nicht richtig. Richtig wäre zu sagen, daß heutzutage fast jeder nichtmanagebare Billigswitch dies kann. Aber gerade im Hochpreissegment der managebaren Switches sucht man dieses Feature vergeblich - dort macht es ja auch nicht so viel Sinn. Bsteinmann 11:30, 24. Mai 2006 (CEST)

IP-Adresse eines Switches

Als Laie frage ich mich:

Haben auch einfache, nicht managebare Switche eine IP-Adresse? Wenn ja, ist diese unveränderlich festgelegt (wie seine MAC-Adresse), oder kann der Switch auch eine von einem DHCP-Server zugewiesene Adresse akzeptieren.

Wie sieht es bei Hubs aus? (Vorstehender nicht signierter Beitrag stammt von 88.64.51.150 (Diskussion • Beiträge) 19:21, 10. Jul 2006 (CEST)) -- Flothi 17:05, 6. Nov. 2006 (CET)

(Solche Fragen besser in einer Newsgroup (http://groups.google.de) stellen) Switche/Hubs benötigen keine IP-Adresse. Einfache Switche haben daher auch keine (z.B. mein 8-Port Noname Gigabit Switch). Sobald SNMP oder DHCP verwendet wird, muss eine IP-Adresse vorgeben wären. Im Gegensatz zu MAC-Adressen wären fest vergebene (unveränderliche) IP-Adressen Quatsch, da diese immer im Bereich der IP-Adressen liegen sollte. --Hubi 07:08, 7. Nov. 2006 (CET)

Begriffserklärungen: Source Address Table oder Content Addressable Memory

In vielen erklärungen über Switche findet man die bezeichnung Content Addressable Memory. Ist diese gleichzusetzen mit der Source Address Table? Oder ist der Content Addressable Memory nur der gesamte Speicherbereich der Source Address Table? Oder ist die Content Addressable Memory die beschreibung für Source Address Table bei Catalyst Switches von CISCO? (Vorstehender nicht signierter Beitrag stammt von 141.64.226.2 (Diskussion • Beiträge) 17:02, 6. Nov 2006 (CEST)) -- Flothi 17:05, 6. Nov. 2006 (CET)

(Solche Fragen besser in einer Newsgroup stellen) Content Adressable Memory scheint eher eine spezielle Implementierung der SAT zu sein (Hash-Algorithmus, sortiert etc.). --Hubi 07:11, 7. Nov. 2006 (CET)

Ich finde es schon wichtig diese Begriffserklärung zu berücksichtigen, da man im Internet oftmals die CAM bezeichnung anstatt die SAT findet. Wenn nun jemand nicht weiss was die CAM bei Switches ist, wird er sich die definition bei wiki anschauen und auch nicht schlauer werden. Das sorgt für verwirung wenn man eine Definition oder Erklärung über Switches sucht. (Vorstehender nicht signierter Beitrag stammt von 85.178.58.76 (Diskussion • Beiträge) 21:14, 7. Nov 2006 (CEST)) -- Flothi 21:19, 7. Nov. 2006 (CET)

Bei der Begriffserklärung sollte vielleicht auch berücksichtigt werden, dass es im Standart "Filtering Database" heißt. SAT oder ähnliche Begriffe sind zwar geläufiger, aber dennoch sollte die korrekte Bezeichnung zumindest erwähnt werden.

FastForward

Was bedeutet dieser Switching mode? Da ich darüber leider nichts gefunden habe.

Ist das selbe wie Cut-Through, nur in grün. --Echoray 10:23, 18. Nov. 2006 (CET)

Begriff "N-Way"-Switch

Was hat man sich eigentlich unter dem Begriff "N-Way"-Switch vorzustellen? Liest man ja immer häufiger.

NWay ist ein Begriff aus dem 802.3u-Standard (Fast Ethernet) und bedeutet ganz einfach nur, dass der glorreiche Switch Autonegotiation zwischen 10 und 100 MBit/s sowie Halb- und Vollduplex beherrscht. Die noch etwas modernere Variante nennt sich MDI/MDIX und kann zusätzlich noch erkennen, ob ein Crossover-Kabel angeschlossen ist. --Echoray 10:08, 31. Jan. 2007 (CET)

Geschwindigkeitsunterschied der Switchingmethoden?!?

Aus meiner Sicht ist ein Geschwindigkeitsunterschied bei den Switchingmethoden irrelevant, da die Unterschiede kaum messbar und auf jeden Fall nicht spürbar sind. Der Store-and-Forward-Switch hat deutlich höhere Hardwareanforderungen als die anderen Technologien. Die Verzögerung, die durch diese Switchingmethode entsteht, spielt jedoch keine Rolle für die Datenübertragung. Die Frage ist eher, ob man die Kollisions- und Fehlererkennung tatsächlich benötigt? --Michael Rößle 16:09, 4. Nov. 2006 (CET)

Die Switching-Methode macht den Unterschied zwischen einem performanten und einem lahmen Unternehmensnetzwerk, weil sie nämlich direkt den Durchsatz des Switches in Paketen pro Sekunde beeinflusst. Nur im Heimnetzwerk ist dieser Durchsatz meistens egal. --Echoray 22:26, 28. Sep. 2007 (CEST)

Die Switchingmethode bestimmt sicherlich die Hardwareanforderung des Switches, aber nicht die Druchsatzrate der Backplane. Im übrigen schalten alle Switche die ich kenne von Store-and-Forward auf eine Cut-through-Methode, wenn ihre Hardware überfordert ist. Das bedeutet, dass in der Praxis kein Geschwindiwgkeitsunterschied bemerkbar ist, allerdings kann es sein, dass die Store-and-Forward-Methode evtl. nicht angewandt wird obwohl sie eingestellt ist.

Lahm kann Datendurchsatz oder Latenzzeit bedeuten. Beim Kopieren großer Datenmengen wird eine Latenzzeit kaum ins Gewicht fallen, bei Client-Server basierten Programmen hingegen, ins Besondere bei 2 Tier oder 3 Tier Server-Architekturen, oder bei Cluster-Systemen ist die Latenzzeit maßgeblich an der resultierenden System-Leistung beteiligt.

Die Latenzzeit von konstanten 112 Bit bei Cut Through und maximal 12000 Bit (plus ein Bisschen Rechenzeit) bei Store und Forward ist ein gewaltischer Unterschied! Bei kleinen Netzen merkt man da zwar fast nichts da meist 100 Millionen Bit per Sekunde verarbeitet werden, bei größeren Installationen, mit zahlreichen Switches und noch mehr Usern, bemerkt man die Verhundertfachung deutlich.--Nmoas 17:05, 25. Nov. 2007 (CET)

Ich meine da liegst Du falsch. Du darfst die Latenzzeit nicht einfach über alle Frames addieren. Es werden ja durchaus mehrer Frames hinteinander geschickt, wobei die Latenzzeit nur einmal ins Gewicht fällt. Sollten nicht mehrer Frames direkt hintereinander (und in eine Übertragungsrichtung) verschickt werden, dann spielen die Latenzzeiten der Switchingmethoden erst recht keine Rolle gegenüber den ganzen übrigen Latenzzeiten. Ich verstehe übrigens nicht, was das mit der Anzahl der User zu tun hat, es kommt ja wohl auf die Gesamtdatenmenge die übertragen wird an.

Cut-Through

Nach meinen Unterlagen (Informatik 4.Semester Rechnernetze) ist eine primäre Eigenschaft der Cut-Through Funktionsweise die Weiterleitung von noch nicht komplett empfangenen Paketen, wodurch zwar keine Verbesserung der Latentzeit entsteht, jedoch gegenüber Store-and-Forward allgemeine Geschwindigkeitsvorteile entstehen.

wodurch zwar keine Verbesserung der Latentzeit entsteht, --Nmoas 17:12, 25. Nov. 2007 (CET) Die Latenzzeit verringert sich! Kann sich Zeit verbessern?

allgemeine Geschwindigkeitsvorteile entstehen. --Nmoas 17:12, 25. Nov. 2007 (CET) Das ist eine sehr unwissenschaftliche Ausdrucksweise. Es entsteht eine verringerte Latenzzeit. CT: konstant 112 Bit, SuF: min 512 und max. 12000 Bit (plus Rechenzeit).

Unterschied zwischen Cut-Through und Fast Forward?

So wie das im Moment beschrieben ist, klingen die beiden genau identisch. Kann das jemand der Ahnung hatte bitte ein bisschen klarer formulieren? (5. Aug 2006)

Fast Forward und und Cut Through werden als Synonyme benutzt. Leider nicht immer, es kommt auf den Kontext an, geht es um Vermaschte Netze (Loop detection, Spanning Tree usw.) so ist Fast Forward kein Synonym zu Cut Trough.--Nmoas 17:20, 25. Nov. 2007 (CET)

Eine Bridge kann auch mehr als 2 Ports haben

Meiner Meinung nach kann eine Bridge auch mehr als 2 Ports haben. "Im Unterschied zu Bridges haben Switches mehr als 2 Ports (meist zwischen 4 bis 48 Ports) und können mehrere Ports unabhängig voneinander zeitgleich verbinden (non Blocking)"

Eine Bridge unterscheidet sich nur darin, dass eine Bridge NUR Store-and-Foreward kann ein Switch hingegen kann außerdem auch Cut-Through und Fragement-Free.

Also: Jeder Switch ist eine Bridge, aber nicht jede Bridge ist ein Switch! (ist Falsch --Nmoas 17:48, 25. Nov. 2007 (CET))

So einfach ist es nicht, ein wesentliches Merkmal von Switches ist die hohe Portdichte oder Portanzahl, Bridges hatten Typischerweise 2 Ports und selten 3 oder mehr Ports, lässt man SOHO mal außen vor, hatten bereits die ersten kommerziell verfügbare Modelle 7 Ports (Hersteller Kaplana), heute haben Profi-Switche meist 12, 16, 24, 32 oder noch mehr Ports und können alle Ports paarweise unabhängig voneinander zeitgleich verbinden (Stichwort: non Blocking, Crossbar). Non Blocking ist ein weiteres wichtiges Feature.

Cisco wollte seine Router-Marktanteile durch den Spruch a switch is a multiport bridge sichern, hat aber heute verstanden, dass dieser Spruch falsch ist. Switches sollten damals als nichts besonders dagestellt werden, man wollte damals den Innovativen Ansatz und die hohe Performance nebst günstigem Preis ignorieren - Schließlich hat man Kaplana dann doch gekauft. Ähnlich falsch Jeder Switch ist eine Bridge, aber nicht jede Bridge ist ein Switch! - Die Performanceunterschiede (Portdichte und Non Blocking) werden schlicht untergraben. Egal der Markt hat es verstanden, heute gibt es fast überall performante Switches und keine lahmen Multiport Bridges.--Nmoas 17:48, 25. Nov. 2007 (CET)

Einleitung

In der Einleitung sind die Definitionen Layer 2 zu Layer 3 falsch. z.B." Professionelle Layer-3- bzw. höhere Switches verfügen in der Regel über Management-Funktionen; neben den grundlegenden Switch-Funktionen verfügen sie zusätzlich über Steuer- und Überwachungsfunktionen, die auch auf Informationen aus höheren Schichten als Layer 2 beruhen können, wie z. B. IP-Filterung, VLAN, " Layer 2 switche kennen natürlich VLAN's auch Managmentfunktionen sind ihnen nicht unbekannt. Ausserdem verfügen vernüftige Layer 2 switch auch über snmp Funktionalitäten zu Überwachungs- und Statistikzwecken.

Die únterscheidung dieser zwei Geräteklassen ist folgende.

Layer 2 Switche treffen ihre forward entscheidung anhand von Vlan und MAC-Adresse

Layer 3 Switche ihre nach Layer 2 Info (IP-Adressen)

So einfach ist es nicht. Denn woher kennen die L3 (Layer 3) Switche die IP-Adressen wenn nicht über eine Managementfunktion? In der Praxis haben solche Switches dann auch weitere sinnvolle Features.

Der Satz L2 Switche treffen ihre forward entscheidung anhand von Vlan ... ist falsch, denn nicht jeder L2 Switch versteht was ein Vlan ist. Oft genug sind VLans gar nicht implementiert, ohne managementinterface ist auch nur VLAN nach IEEE 802.1Q (mit Einschränkungen) möglich (was sowieso nur neuere Modelle implementieren), die Zahlreichen anderen am Markt befindlichen meist proprietären VLAN Varianten (3Com, Bay, Cisco) funktionieren so nicht.

Der Satz Layer 2 Switche kennen natürlich VLAN's auch Managmentfunktionen sind ihnen nicht unbekannt. ist so falsch, denn die Mehrzahl der heute vermarkteten (billigen) Layer 2 Switche kennen keine Managementfunktionen.

Der Satz Layer 3 Switche ihre nach Layer 2 Info (IP-Adressen) ist Falsch denn auf Layer 2 gibt es nunmal noch keine IP-Adressen. Auch nennt man L3 basiertes Weiterleiten Routing.

Ausserdem verfügen vernüftige Layer 2 switch ist ebenfalls unsinnig, denn vernünftig ist kein Attribut für einen Switch. Vielleicht ist wie im Artikel auch so geschehen "höherwertige Switches" gemeint. --Nmoas 18:20, 25. Nov. 2007 (CET)

Funktionsweise

Nach dem einleitenden Satz "Das eigentliche Switching, also die Entscheidung, an welchem Port ein gerade eingetroffener Frame wieder herausgeschickt wird, kann nach folgenden Methoden erfolgen:" wird nicht beschrieben, wie der Ausgangsport bestimmt wird, sondern vielmehr unter welchen Bedingungen Pakete weitergeleitet werden. Daher schlage ich folgende Formulierung vor:

Die Weiterleitung von Paketen/Frames in einem Switch kann nach folgenden Betriebsmodi stattfinden, die sich hinsichtlich ihrer Verzögerungszeit und Fehlerkorrektur unterscheiden:

Store-and-Forward – Die grundlegendste, aber auch langsamste Switching-Methode. Sie wird von jedem Switch beherrscht.

Das ist falsch. Die Erfinder der Technologie, die Fa. Kaplan, stellte die ersten Switche am Markt her, diese beherrschten nur die Cut-Through Technik - dadurch konnte Speicher gespart werden, was damals ein enormer kostenfaktor war, und zusätzlich die Latenzzeit niedrig gehalten werden. --Nmoas 16:52, 23. Dez. 2007 (CET)

Cut-Through – Eine sehr schnelle Methode, wird hauptsächlich von besseren Switches implementiert.

Sind diese beiden Sachen nicht vertauscht? Es ist doch eher so das jeder Switch Cut-Through beherscht da dies eine sehr "einfache" Methode ist und Store and Forward aufgrund seines benötigten Speicher Platzes eher von besseren Switches benutzt wird. --Nmoas 16:53, 23. Dez. 2007 (CET)

Nein die sind nicht vertauscht. Store and Forward muss von jedem Switch beherscht werden. Das ist der Standard nach der IEEE802. Ein Cut-Throug Switch muss immer auch Store an Forward unterstützen da er z.b. Broadcast Nachrichten nur dann im Cut Through weiterleiten kann wenn alle Ports beim Eintreffen frei wären. Das ist aber selten der Fall. Ich denke ich kann die meisten Fragen hier beantworten. Werde mir nächstes Wochenende mal Zeit nehmen.

Das ist falsch. Switche wurden von der Fa. Kaplan erfunden und zwar lange bevor es einen Switching Standard nach IEEE802 gab. Kaplan stellte wie gesagt die ersten Switche am Markt her, diese beherrschten nunmal nur die Cut-Through Technik. --Nmoas 16:54, 23. Dez. 2007 (CET)

"Switch (Computertechnik)" in "LAN-Switch" ändern

Der Artikel behandelt nur LAN-Switches, deshalb sollte auch der Titel entsprechend angepasst werden. Es gibt schließlich auch noch andere Switches im Computerbereich, z.B. Fibre Channel-Switches in SAN-Fabrics.

Der Ausdruck Switch (ohne Zusätze) bezeichnet in der Computertechnik traditionell einen Switch für Ethernet Netzwerke, denn hiermit wurde der Ausdruck Switch eingeführt. Andere techniken wie FC oder SANs sind neuer. Dortige Geräte werden nicht als (nur-) Switch sondern immer als FC-Switch oder manchmal auch als SAN-Switch bezeichnet. "LAN-Switch" ist außerden kein sehr gebräuchlicher Ausdruck. --Nmoas 17:05, 23. Dez. 2007 (CET)

Promiscuous Mode

Die angeschlossenen Karten können den Promiscuous Mode signalisieren, womit ein Switch effektiv zu einem Hub umfunktioniert wird - die angeschlossene Karte hört jetzt den gesamten Traffic mit. Damit wäre die Argumentation "schwierig zu debuggen" hinfällig, aber diese Angelegenheit sollte auch noch in anderer Form in den Artikel einfließen. Bitte erweitern. --Yanestra 06:31, 9. Sep. 2007 (CEST) http://donate.wikimedia.org/de/campaign/dewiki Wikimedia verändert die Welt und Du kannst helfen!

Ich denke nicht, dass man einem ernsthaften Switch irgendwie signalisieren kann, dass das Endgerät jetzt im Promiscous Mode ist und gerne den kompletten Verkehr sehen würde. Der Promiscous Mode ist so ein Überbleibsel aus der Zeit, als es noch Hubs gab. Was die Netzwerkkarte macht, interessiert aber den Switch nicht. --Echoray 22:30, 28. Sep. 2007 (CEST)

Promiscuous Mode signalisiert nichts an irgendwelche Switches. NICs wissen ja nichtmal, dass sie an einen Switch angeschlossen sind, können also auch nichts signalisieren. --Tashbarg 10:50, 9. Okt. 2007 (CEST)

Hallo? So ein grober Unfug. Bitte dann doch noch mal nachlesen, Leute. --84.58.250.148 21:59, 26. Okt. 2007 (CEST)

Hallo? Ohne irgendeinen Beleg etwas als groben Unfug zu bezeichnen ist dreist. Nachgelesen und verifiziert (in beispielsweise Computer Networking von Jim Curose)! --Tashbarg 11:03, 17. Jan. 2008 (CET)

Vermutlich ist die Funktion von managbaren Switches gemeint, die einen Port in den Überwachungsmodus (Monitoring) schaltet, dann werden alle Pakete die den Switch passieren an diesen Port weitergeleitet. Je nach Implementierung kann das Monitoring teilweise auch auf VLANs beschränkt werden.

funktion

wie heisst denn noch mal die funktion beim switch bei der es egal ist ob man ein patch oder crossover kabel verwendet. hab ich das im artikel übersehen oder steht es noch nicht drin?

Auto-MDI(X). Siehe Medium Dependent Interface. --Echoray 20:31, 20. Jan. 2008 (CET)

Auto-MDI(X)

Danke Echoray! Mir ist es nicht mehr eingefallen. Aber warum steht denn im Artikel nichts darüber? Auf:Naja, Auto-MDI-X hat eigentlich nichts mit dem Switch zu tun, sondern betrifft zum Beispiel auch Netzwerkkarten. Kernkompetenz eines Switches ist das switchen von Paketen, nicht die Kabels. Switches ohne RJ-45-Buchsen betrifft Auto-MDI-X überhaupt nicht. Von daher zögere ich, die ohnehin längliche siehe-auch-Liste im Artikel mit dieser Nebensächlichkeit zu verlängern. --Echoray 10:08, 21. Jan. 2008 (CET)

Store-and-Forward

Das eigentliche Merkmal von Store-and-Forward ist, dass der Switch das Paket erst weiter schickt, wenn er das ganze Paket empfangen hat. Bei viel Datenverkehr kann daher natürlich leichter ein "Stau" entstehen als beim Cut-through-Verfahren.

• So natürlich ist es mit dem Stau nun wirklich nicht, denn die Store-and-Forward-Technik erhöht zwar die Latenzzeit, hat aber auf die Paketrate keinen unmittelbaren Einfluss. Folglich hat das Verfahren auf Daten-Staus also KEINEN Einfluss. Staus entstehen immer dann wenn mehr Pakete für einen Zielport angenommen werden, als der Zielport verarbeiten kann, also dann wenn aus mehreren Ports Pakete kommen die alle über einen einzelnen Port, z.B. den Uplink Port, oder den Port an dem der Server hängt, weitergeleitet werden sollen. Latenzzeiten haben, so lange es genug (Puffer-) Speicher gibt (pro Port genügt zum Beispiel ein Ringspeicher der die doppelte MTU aufnimmt) hierauf keinen Einfluss.--Nmoas 18:00, 8. Feb. 2008 (CET)

Portbündelung

"Um die Geschwindigkeit zu steigern, beherrschen professionelle Switches auch häufig die Port-Bündelung (engl.: trunking, bonding, etherchannel - je nach Hersteller) von zwei oder mehreren Ports für die Verbindung von Switch-zu-Switch oder von Switch-zu-Server"

• Ja (Liste einiger Synonyme und deren Umfeld: Bonding, im Linux Umfeld; Etherchannel, bei Cisco; Link Aggregation, bei IEEE; Load Balancing, allgemein; Port Aggregation, bei Hewlett-Packard; Trunking, bei 3Com oder Sun Microsystems, aber auch bei anderen Herstellern; Bündelung auf Deutsch) --Nmoas 07:39, 16. Jun. 2008 (CEST)

Portbündelung gibt es, ABER trunking hat damit nichts zu tun: Unter einem Trunk versteht man bei VLAN's den Transport von mehreren VLANS über einen Port (Trunking Port).

• Das ist ganz einfach falsch - Trunking bedeutet im Zusammenhang LAN/Switch einfach Bündeln, dabei kann man ein einzelnes Lan (= VLAN) auf mehreren Physikalischen Links abbilden - AKA "Link Aggregation" - also mehrere phys. Links zu einem logischen Link bündeln. Oder aber auch mehrere VLans als ein gemeinsames "Bündel" abbilden, also gemeinsam z.B. auf einen phys. Link aber auch auf einen logischen Link abbilden - das nennt sich dann "VLan Trunking" (und nicht "nur" Trunking) - beides ist also in beliebiger Mischung möglich - wenn gleich nicht jeder Switch das Trunking in allen Kombinationen und Lebenslagen beherrscht. (Genaueres gibt es (Synonyme beachten!) z.B. bei Herstellern aus dem Enterprise-Switch-Bereich: 3com/Cisco/HP/uvm. in den Switch-Management-Doks - auch unter Linux ist Bonding in allen Lebenslagen gut dokumntiert http://www.mjmwired.net/kernel/Documentation/networking/bonding.txt) --Nmoas 07:39, 16. Jun. 2008 (CEST)

Geschichte

Die Switching-Technologie wurde 1984 entwickelt von Wolfgang Rau (IBR-SC). Am 9.4.1990 wurde die Technologie beim deutschen Patentamt angemeldet unter P40 12 166.6, Node-Controller, Erfinder: Wolfgang Rau. Durch die Umstellung von Routern zu Switches konnte der Durchsatz in den Netzwerken um zunächst um Faktor 1000 bis 2000 gesteigert werden. Mittlerweile wurden noch einige Zehnerpotenzen mehr möglich, wobei die Möglichkeiten noch längst nicht ausgereizt sind.

MfG Wolfgang Rau wmr@ibr-sc.de

Ich kann das o.g. Patent nicht im DEPATISnet finden. Helfen Sie mir mal. --Echoray 12:26, 12. Sep. 2008 (CEST)

Sicherheit

Da steht ."war das Abhören des gesamten Netzwerkverkehrs noch kinderleicht" ...ich bezweifle das Kinder das schon können. Könnte man nicht besser schreiben ...es war vergleichsweise einfach ...? --91.34.170.182 14:01, 16. Jul. 2009 (CEST)

Gigabit und erst Auto MDI(X)

Also ich zweifel diesen Satz an, bzw. dessen Einleitung, da auf 10/100 Switches dies können aber im Artikel steht:

Bis zur Einführung von Gigabit-Ethernet (1000BaseTX) erfolgte die Verbindung mehrerer Switche entweder über einen speziellen Uplinkport oder über ein gekreuztes Kabel (crossover cable), neuere Switche wie auch alle Gigabit-Ethernet Switche beherrschen Auto-MDI(X), sodass diese auch ohne spezielle Kabel miteinander gekoppelt werden können. (nicht signierter Beitrag von 213.252.171.99 (Diskussion | Beiträge) 08:48, 21. Jul 2009 (CEST))

Widerspruch im Artikel

Unter "Architekturen" wird völlig richtig beschrieben, dass ein Bus nur von EINEM Frame pro Zeiteinheit durchlaufen werden kann.

Unter "Vorteile" ist ausgeführt, dass ein Switch über die Backplane mehrere Pakete gleichzeitig übertragen kann. Die Backplane ist nichts anderes als ein von allen Ports gemeinsam genutzer Bus, der ein Vielfaches der Bandbreite eines Ports besitzt. Es kann also nicht sein, dass dieser Bus mehrere Frames gleichzeitig transferieren kann.

Ist es nicht so, dass wegen der hohen Geschwindigkeit des Busses eine scheinbare "Gleichzeitigkeit" erzeugt wird, die aber nie erreicht werden kann?

Es könnte ja sein, dass ein Frame am Switch gerade angekommen ist, während ein anderes gerade den Bus durchquert. Das ankommende Frame müsste in diesem Fall warten. Bei "Gleichzeitigkeit" müsste das Frame bereits auf den Bus gelegt werden können, obwohl noch ein Frame unterwegs ist. Und dies wird in bestimmten Konstellationen zu Kollisionen führen. --Gandalf 2011 19:25, 9. Jun. 2011 (CEST)

CRC-Link

Unter 1. Funktionsweise/Store and Forward ist ein Link nach CRC. Ich wollte das gerade mal von der Begriffsklärungs- auf die Cyclic Redundancy Check-Seite umbiegen, bin mir jetzt aber nicht sicher ob das gewollt ist, da ja der Zwobot alle ^[A-Z]{3}$ ignoriert. (nicht signierter Beitrag von 217.226.252.91 (Diskussion | Beiträge) 13:29, 29. Aug. 2004 (CEST))

Naja, da keiner was dazu gesagt hat, habe ich den Link jetzt mal umgebogen. Mal sehen, ob er so bleibt. (nicht signierter Beitrag von 217.232.32.188 (Diskussion | Beiträge) 21:28, 24. Okt. 2004 (CEST))

Inhalt (Ergänzung )

für die forwarding Table kenne ich noch den Begriff adress lookup table, also dort, wo der Switch nachsieht, von welchem Port er irgendwann ein Paket (absendeadresse) für diese Zeiladresse bekommen hat. (Quelle: Datenblatt des 5-Port-Chip KS8995MA ).

Diese Tabelle wird - durch Ausschalten zurückgesetzt. - zum Teil (also für eine Adresse), wenn ein Timeout (Wert je nach Gerät) verstrichen ist, z.B. nach 10 Minuten...

Des Weiteren gibt es einige Leistungsmerkmale: - Mbit/s (Megabit per Second) - kpps (Kilopackets per second) - Speicherbandbreite Backbone - Größe des Zwischenspeicher und zuordnung zu den Ports (fest / variabel)

- managebar oder nicht - ist auch noch ein (großes) Thema.

mfg, Tomcat42 (der sein passwort grad nicht bei der Hand hat....) (nicht signierter Beitrag von 194.138.39.55 (Diskussion | Beiträge) 12:52, 9. Feb. 2005 (CET))

Nachtrag zu Cut-Through

Ich finde wie der Artikel Cut-Through nun beschrieben ist, ist es ok. Aber die Passage: " Latenzzeit in Bit beträgt hier 112. Sie setzt sich aus der Präambel (8Byte) und der „Destination-MAC-Adresse” (6Byte) zusammen." finde ich nicht gut formuliert. Außerdem wird die Latenzzeit in Zeiteinheiten (z.B. Millisekunden (ms)) und nicht in Bit gemessen. Da ich nicht mehr genau weiß, wie man das umrechnet, fodere ich jemanden, der das weiß, auf dies zu korrigieren. (ursprünglich nicht korrekt signierter Beitrag von Tobevision (Diskussion | Beiträge) 09:05, 6. Jul. 2005 (CEST))

Latenzzeit setzt sich aus Präambel und Destination-MAC-Adresse zusammen?!

Im Punkt 1.1 unter Cut through steht folgendes:

„Die Latenzzeit in Bit beträgt hier 112. Sie setzt sich aus der Präambel (8 Byte) und der „Destination-MAC-Adresse“ (6 Byte) zusammen.“

Entweder stehe ich auf dem Schlauch oder das ist totaler Schwachsinn. (nicht signierter Beitrag von 90.186.110.118 (Diskussion | Beiträge) 21:21, 9. Mai 2007 (CEST))

Du stehst auf dem Schlauch: richtige Antwort ist 1,12µs

-> ((6Byte+8Byte)*8)/100Mbps=1,12µs (nicht signierter Beitrag von 84.179.96.118 (Diskussion | Beiträge) 14:24, 4. Jul. 2007 (CEST))

OSI-Layer

Eine Grafik die den Switch ins OSI-Modell einordnet ähnlich: http://de.wikipedia.org/wiki/Router#Arbeitsweise wäre sinvoll IMO 18:30 CET 15.02.2008 (nicht signierter Beitrag von 84.162.203.44 (Diskussion | Beiträge) 18:29, 15. Feb. 2008 (CET))

zu: Mehrere Switches in einem Netzwerk, 2. Absatz, 2. Satz

Habe den Satz etwas "entbündelt", dh. zwei daraus gemacht. So ists besser lesbar und die Argumentation logischer, da die Bedingung ("wenn Switches verschiedener...") jetzt VOR dem Bedingten ("ist die Port-Bündelung ...") steht. (nicht signierter Beitrag von Frank1211 (Diskussion | Beiträge) 09:01, 23. Feb. 2008 (CET))

Non Blocking

Ein Layer2-Switch oder Layer3-Switch gilt nur dann als non blocking, wenn er über alle ports full-duplex in voller Leitungsgeschwindigkeit vermitteln kann. Das konnten vor einigen Jahren viele CISCOs nicht, sondern nur die Foundrys und später auch die Extreme Networks. (nicht signierter Beitrag von 192.109.190.88 (Diskussion | Beiträge) 17:17, 20. Aug. 2008 (CEST))

Klärung

"Für die angeschlossenen Geräte verhält sich ein Switch transparent (nahezu unsichtbar). Aus Netzwerksicht wird die Paketanzahl in den Segmenten drastisch reduziert, wenn die Kommunikation überwiegend zwischen den Geräten innerhalb eines Segments stattfindet. Muss ein Switch allerdings Pakete auf andere Segmente weiterleiten, führt der Einsatz eines Switches eher zu einer Verzögerung der Kommunikation (sog. Latenz)."

Kann jemand erklären, was das heißen soll? "Für die angeschlossenen Geräte verhält sich ein Switch transparent (nahezu unsichtbar)." stimmt so nicht. Für die Schicht 3 ist ein Switch als Gerät der Schicht 2 unsichtbar, und für einen Anwender sind die Schichten 1 und 2 i. A. nicht sichtbar. Das heißt aber nicht, dass er für Geräte im allgemeinen nicht sichtbar ist. Für einen anderen Switch, der mit LLC arbeitet, ist ein Switch sichtbar. Auf L1-Ebene ist ein Switch nicht unsichtbar, wenn er z. B. die Datenrate ändert. Der Rest ergibt m. E. keinen Sinn. Wieso wird die Paketanzahl reduziert? Welche Art von Segmenten ist gemeint? Eine Kollisionsdomäne (Layer1)? Broadcastdomäne (L2)? Routing-Segment (L3)? Evtl. L3-Switching im Vergleich zur direkten Kopplung? Zac67 23:20, 19. Jan. 2012 (CET)

Unbrauchbarer Artikel

Auch hier gilt für mich was ich im Abschnitt über Router geschrieben habe: dieser Artikel ist unbrauchbar. Unagebracht finde ich den Hinweis, persönliche Betrachtungen gehören nicht hierher. Ich dachte Wikipedia soll ein allgemein verständliches Werk sein? Und dann solche Artikel, die mit Hieroglyphen gespickt sind? Ein Beispiel:

"Einfache Switches arbeiten auf der Schicht 2 (Sicherungsschicht) des OSI-Modells. Der Switch verarbeitet bei Erhalt eines Pakets die 48 Bit lange MAC-Adresse (z. B. 08:00:20:ae:fd:7e) und legt dazu einen Eintrag in der SAT (Source-Address-Table) an, in der neben der MAC-Adresse auch der physische Port, an dem diese empfangen wurde, gespeichert wird."

Ist man hier wirklich der Meinung, dass ein solcher Satz in einem Wikipediaartikel stehen darf? Und das ist nicht der einzige unverständliche Satz. Der Artikel ist eine Aneinanderreihung davon. --Aeberl (Diskussion) 12:53, 17. Dez. 2012 (CET)

Der Satz ist zugegebenerweise nicht schön und sollte aufgeräumt werden, aber welche Hieroglyphen meinst du? Alle Abkürzungen werden erklärt, SAT könnte aber durchaus einen eigenen Absatz bekommen. Zac67 (Diskussion) 23:01, 17. Dez. 2012 (CET)

Hieroglyphen sind für mich als Laien Bezeichnungen wie "OSI-Modell", "Sicherungsschicht", "MAC-Adresse" usw., die zwar alle sich durch die Verlinkungen aufklären lassen aber eben für den Laien zunächst abschreckend wirken. In den ersten Sätzen sollte allgemeinverständlich Wesen und Funktion eines Switches erklärt werden. Danach kann man ja in die Fachsprache wechseln.--Aeberl (Diskussion) 19:30, 20. Dez. 2012 (CET)

Frames statt Pakete

Ich möchte ja nicht meckern und ich glaube, dass ich dies bereits geändert hatte. Ein normaler Switch arbeitet - wie korrekt vom Author beschrieben - auf Schicht 2 des OSI Modells.

Im Wikipediaartikel über Frames wird auch korrekt gesagt, dass auf dieser Schicht Frames und keine Pakete versendet werden. Ein Frame kapselt viel mehr ein Paket. (IP)Pakete werden von Routern verarbeitet und nicht vom Switch. Ich ändere die entsprechenden Stellen nun nochmals. (nicht signierter Beitrag von 88.153.124.149 (Diskussion) 20:41, 20. Jan. 2013 (CET))

Quellen?

Bei Durchsicht des Artikels verfügt der Autor entweder über ein von ihm Gott gegebenes riesiges Vorabwissen, oder es fehlen Quellen. Der Artikel hat lediglich nur eine Quelle?! (nicht signierter Beitrag von 88.153.124.149 (Diskussion) 20:41, 20. Jan. 2013 (CET))

Dieser Artikel wurde zu einer Zeit geschrieben, als Wikipedia überhaupt noch keine technische Möglichkeit für Einzelnachweise von Quellen hatte. Es hat sich aus meiner Sicht bewährt, in solchen Fällen nicht krampfhaft auf Quellensuche zu gehen, sondern erst aktiv zu werden, wenn einzelne Aussagen des Artikels tatsächlich angezweifelt werden. Quellensuche nur um der Quellen wegen halte ich für Verschwendung wertvoller freiwilliger Projektarbeitszeit. --Echoray (Diskussion) 14:01, 21. Jan. 2013 (CET)14:01, 21. Jan. 2013 (CET)

Naja, ob man das dann beim Urheberrecht auch so sieht. Mir ist es im Prinzip auch egal. (nicht signierter Beitrag von 153.100.131.12 (Diskussion) 15:30, 21. Jan. 2013 (CET))

Backplane

Kann ein Switch wirklich die zu transferierenden Frames gleichzeitig verarbeiten? Nach meinen Infos hat ein Switch eine Backplane, deren Geschwindigkeit so bemessen ist (Mediengeschwindigkeit * Anzahl Ports *2(nicht sicher)), dass Frames quasi zeitlich verarbeitet werden und so nur der gleichzeitige Eindruck entsteht, obwohl diese seriell verarbeitet werden. (nicht signierter Beitrag von 88.153.124.149 (Diskussion) 23:25, 31. Jan. 2013 (CET))

Ein Switch muss zwingend ein hohes Maß an Parallelität haben - an jedem Port können gleichzeitig jeweils ein Paket (Frame) ein- und eins ausgehen (non-blocking vorausgesetzt). Üblicherweise wird das wohl mit einer entsprechend schnellen Backplane gemacht, aber grundsätzlich ließe sich das auch anders lösen. Zac67 (Diskussion) 08:34, 1. Feb. 2013 (CET)