Lange hat es gedauert und dann muss ich noch die Shownotes nachliefern, aber der Teil II der Sondersendung zu Ethernet und Switching mit dem “coolen Teil” ist da. Neben dem persönlichen Debugging meiner Netzwerkstolperfallen geht es um Link Aggregation, Trunking, Stacking und VLANS. Während Clemens derzeit in Buenos Aires mit am Netz für die ietf schraubt, erzählt er im Podcast wie er seine Switches auf Veranstaltungen am liebsten miteinander sprechen lässt. Viel Spaß dabei!
Es gab beim zweiten Teil der Aufnahme ziemlich heftige technische Probleme, hoffe aber sie alle erwischt zu haben.
podseed.org ist weiterhin eine Spende wert, denn von dort ladet ihr die Episoden runter. :)
Anna-Lena
Clemens Schrimpe
| Feed | Enclosure |
|---|---|
| Podcast Feed: Request for Comments (Request for Comments (MPEG-4 AAC Audio)) | MPEG-4 AAC Audio |
| Podcast Feed: Request for Comments (Request for Comments (MP3 Audio)) | MP3 Audio |
| Podcast Feed: Request for Comments (Request for Comments (Opus Audio)) | Opus Audio |
| Podcast Feed: Request for Comments (Request for Comments (Ogg Vorbis Audio)) | Ogg Vorbis Audio |
Hallo Ihr Lieben,
möchte mich an dieser Stelle mal riesig bedanken für all die vielen Stunden interessanten Netzwerk-und-mehr Gesabbels. :) Ich bin kein Profi, finde das ganze Netzwerkthema nur einfach sehr interessant und möchte es besser verstehen. Dabei habt Ihr mir wirklich sehr geholfen.
Eine Frage zu VLANs möchte ich euch trotzdem gerne stellen:
Mein Switch erlaubt die Unterscheidung zwischen Port-based und 802.1Q-based. Habe ich das richtig verstanden, dass nun im Port-based Modus meine Geräte quasi überhaupt nichts von VLAN wissen müssen und es sich für sie “anfühlt” als wären sie quasi in verschiedenen P-LANs? Aber was passiert, wenn ich nun einen Port dafür benutze ins große böse Internetz zu telefonieren? Dafür konfiguriere ich diesen Port als Mitglied aller Gruppen, die raus wollen. Habe ich dadurch nicht ne Brücke zwischen den VLANs geschaffen? Klar ne IP-Brücke sowieso, aber auch Ethernet? Ums dazu zu sagen: Es scheint eigentlich alles richtig zu funktionieren. Ich “sehe” aus dem VLAN 2 keine Geräte des VLAN 1 aber warum eigentlich nicht?
Hoffe das war nicht zu lang und vielen Dank, falls sich jemand findet, der mir das erklären mag. ;)
Liebe Grüße
Marc
Bei der Link Aggregation habt ihr darüber gesprochen, nach welchen Kriterien ein Endgerät entscheidet, ob ein Paket über den einen oder den anderen physischen Link geht. Da hat Clemens explizit gesagt, dass es kein round robin Prinzip gibt, eines links, eines rechts, eines in der Mitte. Ich hab mich die ganze Zeit gefragt: Warum eigentlich nicht? Wäre doch supereinfach und es gäbe immer eine schöne Lastverteilung. Ich vermute Mal das hätte unerwünschte Nebeneffekte, aber welche?
Super toller Podcast, höre mit Begeisterung zu und muss sagen, dass mir Podcasts jetzt schon generell mehr gebracht haben als so manche Uni Vorlesung.
Ein Begriff der mir ein bisschen gefehlt hat und von dem ich auch nicht weiß, ob er hier überhaupt hingehört, ist Software Defined Networking. Gehört der ganze Teil wo Switche aktive in die Datenweiterleitung eingreifen(mit definierten Regeln) schon dazu?
Bin endlich dazu gekommen diese Ausgabe zu hören.
Super interessant! Bitte weitermachen!
Top Podcast! Nach solch einem Format habe ich lange gesucht! Habe leider schon alle Folgen durch, bitte unbedingt fortführen! Freue mich schon auf die nächsten Folgen!
Grüße aus München
Alex
Großartig!
Ein ganz großes Log an Euch beide!
Ein kleine Bitte aber:
Kannst Du noch die Shownotes für den zweiten Teil nachliefern?
Oh weh…die hab ich total vergessen. :/ Jupp, mach ich
*bump* :)))
Ich würde mich auch sehr über shownotes zu dieser Episode freuen!
TOP Podcast! Ich warte schon gespannt auf die nächste Folge! :)
Danke für den Podcast und diese Folge insbesondere, ich habe so viel gelernt!
Macht ihr auch eine Folge zu WLAN *liebkuck*?
Hi,
WLAN ist natürlich nochmal so ein Spezialthema – ja, ein sehr wichtiges. Es muss allerdings wahrscheinlich erstmal hinter ein paar anderen Themen zurückstehen, die ich zunächst einmal behandeln will. :)
Wollte nur mal Danke sagen, ich finde deinen Podcast und deine Gäste sehr interessant !!
Das war eine sehr tolle Sendung, viele Informationen, gut erklärt – auch die Länge stimmt ;-)
Trotzdem natürlich zwei Anmerkungen ;-):
– Zum einen halte ich von Stacks, aus meinen eigenen Erfahrungen mit der 3750er Reihe von Cisco, nicht so viel wie Clemens. Inbesondere die von dir angepriesene Kompatibilität mit größeren Modellen funktionierte bei mir nie – da reicht dann doch schon eine andere Hardwarerevision, um das ganze zu verkomplizieren. Und wenn man dann einen gefunden hat, dann muss man erstmal alle auf die gleiche IOS Version bringen – die dann mit der alten Hardware nicht mehr läuft … Vielleicht sind das aber auch alles inzwischen gelöste Probleme (In Place Upgrade?).
– VLANs versuche ich eigentlich nicht mehr zur Trennung von Netzwerken zu nutzen, insbesondere wenn die VLANs durch das ganze Netzwerk laufen. Natürlich funktioniert es, aber man hat trotzdem den vollen Broadcasttraffic auf allen Trunkports, die an den VLANs teilnehmen. Das heißt, dort habe ich quasi keinen Vorteil der Segementierung der Broadcastdomain. Statt dessen würde ich versuchen die VLANs so schnell wie möglich an Layer 3 enden zu lassen (SVI, routed Ports, etc.) um dann den Rest über IP zu trennen.
Warum will man für die Entscheidung durch welches Kabel des Bundles man das Paket schickt extra Hashwerte errechnen? Kann man nicht einfach ein Bit aus dem CRC im Frame davor nehmen? Das sollte doch auch hinreichend random sein.
Das Problem ist dass die CRC Informationen am Ende des Frames angehängt sind (siehe https://de.m.wikipedia.org/wiki/Ethernet#Datenframe). Das heißt der Switch müsste immer das komplette Ethernet Frame empfangen und Zwischenspeichern bevor die Entscheidung für einen physikalischen Port erfolgen kann. Das ist nicht immer optimal bzw. erwünscht . Siehe auch Cut-through-switching (https://en.m.wikipedia.org/wiki/Cut-through_switching). Eine nette Übersicht der möglichen Parameter bei Cisco Switchen (und anderen Herstellern in den Kommentaren) gibt dieser Artikel: http://packetpushers.net/understand-etherchannel-load-balancing-catalyst-switches/
Gerade verstanden, dass die CRC Checksumme des VORHERIGEN Frames gemeint war. Der Standard schreibt vor, dass Frames der gleichen Konversation/Streams deterministisch über den gleichen physikalischen Link übertragen werden sollen (https://www.thomas-krenn.com/de/wiki/Link_Aggregation_und_LACP_Grundlagen#Verteilung_des_Datenverkehrs). Das wäre bei Nutzung des CRC Wertes des vorherige. Frames nicht gegeben. Warum hat man das so definiert? Ethernet sieht keine Mechanismen vor Frames beim Empfänger neu zu sortieren. Dies ist Aufgabe der darüber liegenden Protokolle (z.B. TCP). In einem reinen L2 Ethernet kann und sollte man aber nicht davon ausgehen, dass IMMER so eine Funktionalität in einer höheren Protokollschicht gegeben ist. Mit der Einführung einer neuen Funktion wie LACP sollte man daher nicht unnötigerweise neue Abhängigkeiten zu anderen Protokollen einführen.
@Clemens: Cut-through switching findet man noch bei “high-frequency-trading” Anwendungen. Bekannte Produkte z.B. von Arista (https://en.m.wikipedia.org/wiki/Arista_Networks)