Danke für die Ergänzungen!
Wir müssen natürlich immer abwägen, welche Begriffe und technischen Details wir erklären und welche nicht. In diesem Fall haben wir darauf verzichtet, auf die Unterschiede zwischen Hub und Switch einzugehen, weil das aus meiner Sicht für die historische Einordnung nicht so wichtig ist. Entscheidend ist, dass es mit Einführung der Sterntopologie einen zentralen Verteiler gab, was den Aufbau vereinfachte (und das Kabelmanagement auf LAN-Partys komfortabler machte), aber in gewisser Weise eine Abkehr darstellte vom ursprünglichen Gedanken eines geteilten Mediums - wie dieser Verteiler genau funktioniert, ist aus meiner Sicht zweitrangig. Aber das darf man natürlich gern anders sehen, daher sind Ergänzungen wie Deine immer willkommen.
Als jemand der viel mit Netzwerken macht, ist Netzwerk heute, auf den Kern runtergebrochen, super simpel. Du musst nur die Uplinks der Switche bis hin zum Router ordentlich verkabeln. Das kannst du mit einem oder 1000 Switchen. Bleibt immer gleich. Dann brauchst du noch einen DHCP (Komfort) und DNS (braucht man schon - wenn man nicht blank mit IPs arbeiten will). Das macht dann der Router oder ein eigener Server im Netz - oder ein Layer 3 Switch, aber das ist schon fast wieder out of Scope. Falls du die Switche Stacken kannst, werden aus vier oder zehn auch mal einer.
Alles Komplizierte, abseits von Security, kommt von Spezialhardware, die du nicht mal im Job oft sehen wirst. Sowas wie MPIO bei iSCSI SAN / Hypervisor Clustern, mit 100GBit Transceivern, werden wohl die wenigsten machen. Da brauchst du dann auch brauchbare Switche dafür und da hört auch das Wissen der meisten (Fach)Informatiker definitiv auf. Einfach weil man das fast nicht lernen kann, ohne Hardware und da bist du schnell im sechs bis siebenstelligen Bereich. Ich glaube ich hab für die 10 DELL S4148F-ON weit über fünfstellig pro Switch bezahlt. Und das waren schon sehr gedrückte Preise und teilweise hat DELL dann dafür andere Kunden durch unseren Serverraum geschleust. So oft scheint man das also nicht besichtigen zu können. Und das war vor wahrscheinlich 10 Jahren und jetzt kosten die Dinger immer noch um die 2500€ leer. Im freien Handel. Aber das willst du nicht kaufen, weil dir ja dann der Support fehlt. Den bekommst du nur bei DELL direkt. Also musst du auch bei DELL kaufen und da steht dann „kontaktieren Sie den Vertrieb“. Das ist sicher kein gutes Zeichen und der Vertrieb wird sicher nicht für 2500€ tätig. Und du brauchst ja pro Port dann auch noch einen Transceiver bzw. ein Transceiver Kabel, das dann auch nochmal um die 400€ (aktuell) kostet. Also absolute Spezialfälle.
Im Endeffekt kommt das ganze andere Gedöns (Mikrosegmentierung, Zero-Trust, NAC, etc. ) außen rum aus reinen Security-Bedenken. Das erfordert etwas mehr Hirnschmalz und sollte auch bei kleinen Betrieben umgesetzt werden. Ein Ethernet-Gruppen-Drucker ist halt immer ein Sicherheitsrisiko. Natürlich musst du den weg-segmentieren und Freigaben auf IP und Portebene machen. Auch wenn nur drei Hansel und ein Billo-NAS im Büro hocken.
Und dann kommst du wieder an die, die ich im Post vorher verteufelt habe, Low-Cost Geräte, weil sich der Invest sonst nicht trägt. Und die machen dann echt oft Probleme. So richtig hab ich da den Sweet-Spot zwischen Anschaffungs- und Folgekosten noch nicht gefunden. Die Hardware zu wechseln, bedeutet ja auch immer, die Techniker neu zu schulen. Eben auch aufgrund der Inhomogenität der graphischen Interfaces. Würde man sich immer an den Cisco Standard für die CLI halten, wäre vieles einfacher. Aber auch seltsam implementierte Funktionalitäten machen einem das Leben da sehr schwer. Thema STP bei Unifi z.B. Ich steck eine QNAP NAS mit einem Kabel an einen Unifi Switch und der macht den Port wegen STP/Loop dicht. Kann aber eigentlich gar nicht sein, weil wie soll ein Kabel von der NAS einen Loop produzieren? Hilft nicht, da muss man STP auf dem Port abschalten.
Bei Routern/Firewalls ist die Lage noch ungeordneter. Sophos, Fortinet, Barracuda, Cisco, DELL Sonicwall, Cato, … jeder kocht da sein eigenes Süppchen. Geht es dann Richtung Trend-Begriffe wie SD-WAN, etc. wird es komplett wild. Das flanscht jeder, wie er will, an sein Produkt an. Einfach nur um bei Google gefunden zu werden. Ist genau so, wie alles inzwischen KI hat. Egal ob und wie beschissen es implementiert ist.
Nur, dass wir uns nicht missverstehen: In der historischen Herleitung habe ich all diese Details auch überhaupt nicht vermisst. „Das verbindet halt Dinge“ reicht da völlig aus, wie das genau funktioniert ist da genauso unwichtig wie eine komplette Erklärung des OSI-Modells oder wie ein Rechner die Signale genau abhört. War schon genau der richtige Detailgrad.
Es ging mir rein um das Ende der Folge, wo in kurzer Folge die weitere Entwicklung in wenigen Sätzen, dafür aber mit mehr „Fachausdrücken“ (jedenfalls, wenn man da nicht schon alt genug war, selbst Rechner zu verkabeln) abgehandelt wurde. Da muss und sollte man nicht jeden einzelnen Schritt der weiteren Entwicklung auseinanderklamüsern, aber durch die vielen Worte hatte es einen leichten Eindruck von „Naja, den Rest kennt ihr ja alle“ und…nein, eben nicht alle. 
Lieber @Henner_Thomsen, ich bin echt begeistert, was Du so durch Recherche an Informationen rausfindest, was in einschlägiger Literatur so nicht zu finden ist 
und wie Du die Puzzle-Teile redaktionel zusammensetzt. Ganz goßes Lob 
SFT ist mittlerweile mein Favorit hier. Vielleicht kannst Du ja doch mal bei unserem Hörertreffen (Hamburg) erscheinen 
Naja, so simpel finde ich das auch vom Ursprung her nicht. Man muss als Bestandteil des TCP/IP Systems auch noch die Ports und ihre Gruppierungen berücksichtigen. Ich meinte das auch mehr theoretisch. Aber ok, also der Router macht die DNS-Vergabe automatisch und dann braucht man nur noch einen Switch und muss alles richtig verkabeln und dann läuft es? Man muss dann also praktisch nur den Switch selbst konfigurieren (IP einstellen) und sich dann im System um die Freigabe der Geräte kümmern? Also müsste man für ein einfaches kleines Netzwerk nur einen brauchbaren Switch kaufen, oder? Was ich z.B. unabhängig von den Hardware-Besonderheiten kompliziert finde, sind so erweiterte Konzepte wie Segmentierung, Proxyserver und DMZ. Die sind ja eigentlich auch nur aus Security-Gründen entstanden, weil es kaum noch Rechner und Netzwerke gibt, die nicht irgendwie mit dem Internet verbunden sind und die Hardware wurde dann daran angepasst.
Mir war aber nicht so klar, dass Netzwerk-Problematik zu so einem großen Teil auf so spezialisierte Hardware wie Switches und Router und deren Kombination zurückzuführen sind, wenn ich das richtig verstanden habe. Wenn man eine Firewall konfigurieren muss, was an sich schon schwer genug ist, kann ich mir gut vorstellen, dass es durch so ein Chaos wie ignorierte Standards und schlecht implementierte Funktionen noch schwieriger wird, vor allem im Verhältnis zur regulären Standardvernetzung im LAN.
Nicht mal das. Im einfachsten Netzwerk sind Switche unmanaged und damit transparent. Also keine Oberfläche, keine Konfiguration. Fast wie Hubs, die jedes Paket auf jeden Port rausgestrullt haben. Nur das auch unmanaged Switche wissen, welche MAC an welchem Port hängt und daher einen genauen Weg durch die Verkabelung bereitstellen können. Ähnlich wie ein Navi. Die hier z.B., die viele noch kennen werden:
Du stellst also nur den DNS/DHCP am Router ein (eine FritzBox und Konsorten kommen sogar da schon vorkonfiguriert. Das klassische AVM 192.168.178.1/24 Netz.) und dann verbindest du deine Geräte (ich sag jetzt mal lieber PCs) via Kabel mit dem Switch und ein Port am Switch geht zum Router. Fertig, funktioniert. TCP/UDP Ports usw. sind wieder Security/Firewallthemen. Ganz klassisch war das alles offen. Windows Defender Firewall kam auch erst 2001 mit XP.
Und für das aller einfachste verkabelte Netzwerk, reicht dir sogar nur eine FritzBox (o.ä), die hat nämlich oft einen vier-Port-Switch eingebaut. Die gelben Buchsen hier im Bild:
Nicht viel aber zwei PCs, einen Drucker und ein NAS bekommst du dran.
Sicherheitstechnisch ist das natürlich der Tod, aber in der Theorie ist es so leicht.
Aber ja, praktisch ist das längst nicht mehr so. Eigentlich sind Layer-3 Switche, Firewalls und Router totale Feature Creeps. Jedes einzelne Gerät vereinigt nämlich die Eigenschaften von Switchen, Routern und Firewalls in sich. Dazu kommen dann neben den hardwarenahen auch noch Softwarethemen, wie Virenscanner, SSL Inspection, Spam-Filter, … Da die Fehlerquelle in großen Netzen zu finden ist sportlich. Aber da kommen wir dann schon in den SIEM Bereich, weil du mit rein Syslog / SNMP nicht mehr zu Rande kommst. Das ist wohl etwas viel für hier.
Ach ja, bei WLAN hast du die gleichen Themen in grün. Klar, du musst nicht verkabeln (zumindest wenn du ohne Controller arbeitest). Dafür musst du dann aber wieder über WLAN Controller, Ausleuchtung, Transitioning (also welcher AP nimmt dein Gerät an, bevor es die Verbindung zum letzten AP verliert und deine Verbindung nicht abreist) und 1000 andere Themen nachdenken. Vor allem VLANs und Radius. Und hier ist es so wie bei allem anderen: Mit „billigen“ UniFi APs kommst du schnell zum Ziel. Über einen Cisco Catalyst 9800-L Wireless Controller kannst du eine Doktorarbeit schreiben.
Ich war überrascht, dass es auch schon so ganz kleine und billige Mini Router gibt, zum Beispiel der GL.iNet GL-AR300M16. Da läuft dann eine Variante von OpenWRT drauf:
So einen habe ich jetzt an meiner Playstation 2 Slim hängen, als SMB Server, weil der Ethernet Anschluss an der Konsole mit Abstand der schnellste ist.
Kleine Switch-Anekdote: Wir sind in unserer LAN-Gruppe Ende 1999 nach langer Debatte (schließlich brauchte jeder eine neue Netzwerkkarte und neue Kabel) auf Fast Ethernet mit Switch umgestiegen. Ein riesiger, schwerer, aktiv belüfteter Stahlkasten, gebraucht bei eBay gekauft für ein kleines Vermögen.
Gleich bei der ersten LAN haben wir es irgendwie geschafft, mit einem Kurzschluss einen der acht Ports zu zerstören. Da konnte man nur hoffen, dass nie alle acht Mitglieder gleichzeitig vor Ort sind 
Ja, das kann vorkommen.
wir haben in den 2000ern mit 3 Stück 24 Port 100Mbit Switchen ohne extra Uplink gearbeitet.
Natürlich wollten immer allen an dem hängen wo auch der “DatenServer” dran war.
Eines schönen Tages passte aber einer beim verkabeln nicht auf, und steckte eine Loop.
Was glaubt ihr wie lange wir gebraucht habe raus zu finden warum unser Netzwerk so schlecht und instabil lief.
Bin auf die Folge gespannt. Gestern erst im neuen Bürogebäude meiner Arbeit einen Switchstack konfiguriert 
Alles klar, danke dir. Ich hab da etwas weltfremd argumentiert, weil ich von einfachen Netzen ohne Router und ohne DHCP ausgegangen bin, wo die IP-Adressen nicht automatisch zugewiesen werden. In dem Fall muss man die Adressen ja manuell zuweisen und ohne IP-Kenntnisse kann da einiges daneben gehen. Aber heutzutage haben die meisten Heim-Netze ja schon einen Router mit integriertem Switch oder Firmennetze einen DHCP-Server wo die Adresszuweisung automatisch funktioniert. Da muss man sich dann nicht mehr um so Probleme reservierte Adressbereiche kümmern. Andererseits hat man dafür dann dafür die Security-Probleme. Das betrifft aber dann nicht nur externe Gefahren, sondern auch so Sachen wie interne Benutzer-Authentifizierung, z.B. unter Windows über einen Domain Controller. Aber da sieht man eben auch, wie viele Missverständnisse durch dieses theoretische TCP/IP Gebilde entstehen können. Mir hat mal jemand gesagt, 80% der Arbeit im Netzwerk ist Trouble Shootig. Also die Einrichtung an sich ist wohl eher nicht so sehr die Herausforderung wie später dann die Verwaltung oder der Ausbau.
In der Übergangszeit hatte ich einen Hub mit 5 Ports und einem BNC Anschluss. So konnten wir überbrücken bis alle auf RJ45 waren.
Hier geht es weiter mit Teil 2:
Um Gottes Willen, bei 1:16:50 wird gesagt, TCP/IP käme erst mit WIndwos 95, das stimmt nicht. Windows NT 3.1 (1993) war das erste WIndows-OS, dass das mitbrachte. Allerdings nur mit einer sogenannten STREAMS-API, die man von AT&T lizenziert hatte und nicht gut zu programmieren war.
Windows NT 3.5 (1994) wurde das komplett neugemacht und seit dem haben wir die sogenannte SOCKET-API, und das ist der Grundstein, der bis heute in allen Windows (ja auch diesen seltsamen 95, 98 und Me-Konstrukten auf MS-DOS) implementiert ist. Also auch das immer noch mehr als ein Jahr vor WIndows 95.
59:50: Ich hatte damals nen installierten MS Proxy Server zu den Windows-Zeiten bei mir immer gehabt, da war das gar kein Problem, das Internet freizugeben. Als Programmierer hatte ich damals (legal) Zugriff auf das MSDN (Microsoft Developer Network) und somit konnte ich einen Server mit WIndows NT 4.0 Server und Microsoft Proxy Server 2.0 installieren :)…
Eine kleine Anmerkung zu Token Ring.
Die 4-Mbit-Variante wurde relativ schnell durch die 16-Mbit-Variante ergänzt. Mir ist auch in der freien Wildbahn nur die 16-MBit-Variante über den Weg gelaufen, weil die eben schneller war als Ethernet und man die Priorität der einzelnen Hosts mit dem Token besser steuern konnte. Das war aber um einiges teurer. Und ja, das waren IBM Mainframe Netze.
Bei den ganzen herstellerspezifischen Netzwerken habt ihr AppleTalk ausgelassen. Das hatte in der Apple-Bubble eine extreme Verbreitung. Hauptanwendung war, damit sich mehrere Macs einen Apple LaserWriter teilen können. FileSharing ging aber auch darüber. Es war ein Netzwerk, basierend auf der seriellen Schnittstelle, daher max. Durchsatz von 230 kBit. In den seriellen Port hat man eine kleine Box eingesteckt, die hatte zwei Ausgänge. Im Prinzip so was wie ein T‑Stück beim Ethernet. Die einzelnen Rechner, Drucker etc. wurden dann in der Kette geschaltet, wie beim Ethernet auch. Lediglich das Terminieren war nicht nötig. Die Box hat erkannt, wenn kein Kabel eingesteckt ist, und hat den Anschluss automatisch terminiert.
Später hatte man das AppleTalk Protokoll auf andere Hardware (wie z. B. Ethernet) portiert. Damit es keine Verwechslung zwischen dem Protokoll und der Hardware gibt, hat man die Hardware (diese Boxen) umbenannt in LocalTalk. Erwähnenswert in diesem Zusammenhang ist noch das PhoneNet, das hatte die Hardware durch eigene Boxen ersetzt. Der Clou an diesen Boxen war, dass die mit ordinären Telefonkabeln funktioniert haben.
Es gab auch ISA Karten für PCs, damit diese auch in das AppleTalk Netz eingebunden werden können.
Gute Info zu AppleTalk. Ich vermute, man hat es ausgelassen, weil es eben kein “PC-Netzwerk” (sondern Mac) war, und auch im Spielekontext deswegen eher irrelevant war.
Das würde ich nicht so unterschreiben. Falcon MC (die Mac Version von Falcon 3.0) oder Marathon von Bungee liefen sehr gut über AppleTalk. Das Letztere haben wir sehr wohl auf LAN-Partys gespielt.
Ach ja, noch ein kleiner Nachtrag: Warcarft II lief auch im LAN über AppleTalk.
Wir gehen nicht näher drauf ein, erwähnen AppleTalk aber in Teil 2.
Da kommen Erinnerungen an das Informatiksemester und die gute alte Starcraft LAN-Party auf. Einfach wieder eine tolle SFT-Folge.