RFCE004: IEEE statt RFC II

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. :)

avatar Anna-Lena Paypal Icon Flattr Icon Amazon Wishlist Icon
avatar 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

14 Gedanken zu „RFCE004: IEEE statt RFC II

  1. 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?

  2. 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

  3. 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?

    • 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. :)

  4. 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.

  5. 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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.