Einführung

R. und N. hatten für das Selbstorganisierte lernen (SOL) die Idee einen umanaged Layer 2 Switch zu bauen oder simmulieren.

Ziel (naiv, deprecated, Version 1)

  • Mit GPIO und Microcontroller/RPI einen Layer 2 Switch bauen, welcher mit Pcs über Twisted Pair kommunizieren kann
  • Eine einfache Nachricht verschicken
  • (Optional) Paketsniffer bauen und gesendete Datenpakete analysieren
    • Man in the Middle am Beispiel zeigen
  • (Optional) Über http eine Übersicht geben über den Aufbau, Inhalt der gesendeten Pakete

Vorgehen

  1. Über Protokolle(Ethernet, Manchester Kodierung) informieren, Anforderungen festhalten
  2. Die physische Layer definieren
  3. richtigen Mikrocontroller / Einplatinencomputer wählen, der den Anforderungen entspricht
  4. Projekt mit Micropython implementieren

Anforderung

  • Presentationsmedium (HedgeDoc oder mdBook)
  • Evt. Physisches Gerät

Diagramm

graph LR
    S[Sender] -->|Frame zu MAC: DD:EE:FF| SW[Layer 2 Switch]
    SW -->|Unicast| E[Empfaenger]
    SW -.->|kein Frame| A[Anderes Geraet]

Ziel (Version 2)

  • eine Simulation für einen Layer-2 Netzwerkswitch bauen, Netzwerk ist fest vorgegeben (2 Netzwerkgeräte, 1 Switch)
  • (Optional) Netzwerk variabel aufbauen
  • (Optional) GUI

Vorteile:

  • Konzepte verstehen unabhängig von technischen Implementierungen
  • wir können entscheiden auf welchen Level abstrahiert wird

Nachteile:

  • keine Kontrolle(durch Probe) möglich, ob Ethernet Standart korrekt umgesetzt wurde

Vorgehen

  1. Erkenntnisse aus vorheriger Recherche festhalten

  2. Anforderungen festhalten

    • welche Aufgaben hat Layer 1+2 (Switch und Endgeräte)
    • welche Funktionalität soll die Simulation haben
    • Wie technisch/physikalisch soll implementiert werden
    • Eingabe ? Ausgabe ? -> über terminal, Textdateien ?
    • Zeitbasiert Simulation oder Eventbasierte simulation ?

  3. Software Projekt planen

    • Aufteilen in Teilbereiche(z.B. Ein Ausgabe, Netzwerkkomponenten, Kodierungen, Nachrichten, Leitungen, ...) --> möglichst modular
    • (UML Klassendiagramm ???)

  4. Software Projekt umsetzen

    • Implementierung alleinstehender Klassen
    • Implementierung zusammenhängender Klassen
    • (Testen ???)

Anforderung

  • funktionierende Simulation eines Layer 2 Switches und Endgeräte
  • Dokumentation in Hedgedoc (Übertragung in mdBook)

Hinweis: die Bilder in Funktionsweise stammen aus dem Repo von R.: layer 2 switch learning process

Notizen

Dieser Bereich ist nicht wichtig aber zeigt wie wir vorgegangen sind.

Nachtrag, Anmerkung

In der Recherche ist uns aufgefallen, dass Ethernet über twisted pair mit GPIO pins nicht direkt umsetzbar ist(differential signaling)

Design und Implementierung eines Layer 2 Unmanaged Switches (Lernprojekt)

Vorgehen

  1. Über Protokolle(Ethernet, Manchester Kodierung) informieren, Anforderungen festhalten
  2. Die physische Layer definieren
  3. richtigen Mikrocontroller / Einplatinencomputer wählen, der den Anforderungen entspricht
  4. Projekt mit Micropython implementieren

Ethernet Protokoll

  • IEEE 802.3 ist der Ethernet Standart --> Details zum Standart liegen hinter einer Paywall
    • beschreibt für jede Übertragungsart/Kabeltyp die technischen Details um eine Kommunikation zu gewährleisten

Die gängigen Ethernet Standarts:

BezeichnungÜbertragungsmediummax. SegmentlängeDatenrate (brutto)
100Base-TXTP-Kabel (2 Adernpaare)100 m100 MBit/s
1000Base-T (1GE)TP-Kabel (4-Adernpaare)100 m1.000 MBit/s
2500Base-T (2G5)TP-Kabel (4-Adernpaare)100 m2.500 MBit/s
5000Base-T (5GE)TP-Kabel (4-Adernpaare)100 m5.000 MBit/s
10Base-T (10GE)TP-Kabel (4-Adernpaare)(Cat6a) 100 m10.000 MBit/s

Twisted Pair

  • 8 Adern -> 4 Aderpaare
  • jedes Aderpaar kann ein Bit übertragen

Differential Signaling

Differential Signaling

  • überträgt auf einer Ader das normale Signal und auf der anderen Ader das invertierte Signal
  • falls eine Störung von z.B. +0,5 Volt zu irgendeinem Zeitraum auftritt wirkt diese auf beide Adern und Signale
  • Durch Störungen bleibt die Differenz der Signale gleich --> es gehen keine Informationen verloren (Man könnte oben im Bild an einer Stelle beide Signale gleich verändern, die differnz bleibt gleich!)

Problem: Bei Twisted Pair werden kleinere Spannungen von (+1,25V -1,25V oder +1V -1V) benötigt und Frequenzen von 16MHZ GPIO Switch Speed

Manchester Kodierung

Bei der Datenübertragung ist die Manchester-Codierung eine Form der digitalen Codierung, bei der der Zustand eines Datenbits (0 oder 1) durch den Übergang von einem Spannungspegel (V) zum anderen dargestellt wird.

-> Codierungsart wird im Header festgelegt z.B. IEEE 802.3 oder G. E. Thomas (Original)

Vorteil:

  • hohe Zuverlaessigkeit

Nachteil:

  • mehr Bitübertragung als Bitstrom ohne Taktsignal

Simulation eines Layer-2 Unmanaged Switches (Lernprojekt)

Vorgehen

  1. Erkenntnisse aus vorheriger Recherche festhalten

  2. Anforderungen festhalten

    • welche Aufgaben hat Layer 1+2 (Switch und Endgeräte)
    • welche Funktionalität soll die Simulation haben
    • Wie technisch/physikalisch soll implementiert werden
    • Eingabe ? Ausgabe ? -> über terminal, Textdateien ?
    • Zeitbasiert Simulation oder Eventbasierte simulation ?

  3. Software Projekt planen

    • Aufteilen in Teilbereiche(z.B. Ein Ausgabe, Netzwerkkomponenten, Kodierungen, Nachrichten, Leitungen, ...) --> möglichst modular
    • (UML Klassendiagramm ???)

  4. Software Projekt umsetzen

    • Implementierung alleinstehender Klassen
    • Implementierung zusammenhängender Klassen
    • (Testen ???)

1. Erkenntnisse vorheriger Recherchen

  • Aufbau von Ethernet Frames ist stark Standartabhängig --> Es gibt viele Ethernet Standarts, CSMA/CD wird überall verwendet
  • Es werden Leitungscodes verwendet, welche den Takt und Daten gleichzeitig übertragen -> Manchester Code(verwendet in älteren Standarts) und 4B5B Code(aktuelle Standarts setzen diese Kodierung um)
  • Twisted Pair Kabel benutzen Differential Signaling und Rasperry pi, Arduino könen das nicht umsetzen

2. Anforderung an die Simulation

technische Anforderungen

  • Eventbasierte Simulation, teschnische Details (Layer1) werden abstrahiert

  • Sendevorgang der Endgeräte

    1. Eingabe von Text für den Payload(evtl über txt Dateien oder TerminalInput) und in Binär mit ASCII kodieren
    2. Zerteilen des langen Textes in einzelne Segmente (für Payload)
    3. Frame entsprechend befüllen (MAC Addressen, Länge, Payload,...)
    4. CRC Prüfsumme berechnen und anhängen
    5. Präambel und SFD anfügen
    6. Prüfen ob die Leitung frei ist -> Paket senden
    7. (optional Wenn es ein Frame crash gibt Jam Signal senden und Frame neu senden)

  • Empfangsvorgang der Endgeräte

    1. Frame mit CRC prüfen --> evtl Fehler korrigieren oder Frame verwerfen, ...
    2. Ziel Mac prüfen --> sonst verwerfen
    3. Payload entnehmen, Daten zusammenfügen
    4. Binärdaten mit ASCII dekodieren und ausgeben

  • (optional Leitung)

    • signalisiert crashes an Endgeräte
    • signalisiert alle verbundenen Geräte, wenn ein Frame eingeht
    • Bitfehler simulieren

  • Switch

    1. Frame und Port über dem Empfangen wurde speichern
    2. CRC prüfen --> evtl Fehler korrigieren oder verwerfen, ...
    3. in Tabelle schauen, ob Empfangs-Port mit Absender-Mac verknüpft ist, ggf. in die Tabelle eintragen
    4. in Tabelle schauen, ob Empfangs-Mac in der Tabelle steht:
      • wenn ja: Frame über hinterlegten Port senden (es sei denn Empfangsport = Zielport; Dann nicht)
      • wenn nein: Frame über alle Ports (außer Empfangsport) senden

Funktionsweise Layer 2 Switch

Recap Ethernet

Ethernet Frame

FeldZweck
7 Byte Präamble:dient zur Taktsynchronisation, Bytes haben alle den gleiche Inhalt "10101010"
SFD:Markiert Beginn des Frame Headers, enthält "10101011"
Destination Mac Address:Enthält die Mac Addresse des Empfängers (Ziel)
Source Mac AddressEnthält die Mac Addresse des sendenden Gerätes
Length / TypeGibt die Länge der Nutzdaten an oder bei moderneren Protokollen den Typ des Ethernet Frames
DataEnthält die eigentlichen Nutzdaten
CRCEnthält eine CRC-Checksum, zum überprüfen ob Bits gekippt sind (ähnlich wie die Quersumme einer Zahl)

Sendevorgang, Empfangsvorgang (nur Kabel also CSMA/CD)

  1. Endgerät bereitet Ethernet Frame vor (z.B. Mac Addressen werden eingetragen, ...)
  2. Die physische Leitung wird abgehört, wenn diese frei ist werden die Daten Bitweise übertragen
  3. Der Empfänger speichert einzelne Bits ab, bis das Frame vollständig übertragen ist
  4. Der Empfänger überprüft das Frame mit der CRC-Checksum --> falls es Fehlerhaft ist, wird das Frame verworfen (höhere Schichten müssen damit rechnen, dass Frames verloren gehen)
  5. Der Empfänger vergleicht die Ziel Mac-Addresse mit der eigenen Mac-Addresse --> stimmt diese nicht überein wird das Paket verworfen
  6. Höhere Schichten verarbeiten die Nutzdaten

mögliche Fehler, die auftreten können

  1. Wenn Geräte gleichzeitig senden kollidieren Signale

    • alle aktiven Netzwerkgeräte können das erkennen und senden ein Jam-Signal, damit wissen alle Geräte in der Kollisionsdomäne, dass eine Kollision aufgetreten ist und stoppen den Sendevorgang. Nach einer bestimmten Zeit, wird die Leitung wieder abgehört und wenn möglich erneut gesendet

  2. Durch Elektromagnetische Strahlung werden Spannungen in den Leiter induziert und verursachen Störungen --> z.B. kippt ein Bit von 1 auf 0

    • wird vom Empfänger meistens als Fehler erkannt, durch CRC

Aufgaben (Hub vs Switch)

Hub (Layer1)

  • Alle angeschlossenen Geräte werden physisch miteinander verbunden
  • die Signale, die ein Gerät sendet werden an alle Teilnehmer verteilt
  • keine Überprüfung der Signale und Frames

Switch (Layer2)

  • Frames werden vom Switch zwischengespeichert und analysiert, bei Fehlern wird das Paket verworfen
  • Switch führt eine interne Tabelle, welche einer Mac-Addresse einen Port zuordnet
    • Bei Inbetriebnahme "lernt" der Switch welche Mac Addressen hinter welchem Port liegen
    • Wenn für eine Ziel Mac Addresse kein Eintrag in der Tabelle vorliegt wird das Frame über alle Ports gesendet
    • Wenn es einen Eintrag der Ziel Mac Addresse gibt, wird das Frame nur über den hinterlegten Port weitergeleitet

Switch - Frame Weiterleitung

  1. Switch empfängt Bitweise ein Frame und merkt sich den Port über den das Frame empfangen wurde
  2. Switch prüft CRC Checksum, wenn falsch wird das Frame verworfen
  3. Switch trägt die Sender-Mac Addresse und den Port(über dem Enmpfangen wurde) in die Tabelle ein
  4. Switch sucht Empfänger-Mac und den hinterlegten Port
    • Wenn es einen Eintrag gibt sendet der Switch das Frame nur über den hinterlegten Port
    • Wenn es keinen Eintrag gibt sendet der Switch das Frame an alle Ports(außer dem Eingangsport des Frames in den Switch)

Beispiel Switch Frameweiterleitung

Die Tabellen unter den Switches speichern die Mac - Port Zuweisung, welche die Switche beim weiterleiten von Frames lernen

1. PC1 sendet ein Frame an PC5

1.1 PC1 sendet das Frame über das angeschlossene Kabe an PC2 und Switch1.

  1. PC1 erstellt Frame und trägt alle Daten ein, darunter Ziel-Mac(vom PC5), Sender-Mac(die eigene).
  2. PC1 sendet das Frame über das angeschlossene Kabel. -->PC2 und Switch1 erhalten es
  3. PC2 verwirft es, weil die Ziel-Mac des Frames nicht mit der vom PC2 übereinstimmt.
  4. Switch1 speichert das Frame im Buffer

1.2 Switch1 leitet das Frame weiter

  1. Switch1 weiß jetzt, über welchen Port PC1 verbunden ist, da PC1 gerade ein Frame(welches die Mac von PC1 enthält) über den Port gesendet hat. Die Mac Addresse und der Port werden in die Tabelle eingetragen
  2. Switch1 vergleicht die Ziel-Mac des Frames mit den Einträgen der Mac-Port Tabelle. Es gab kein Match --> das Frame wird über alle Ports(außer dem Empfangsport) weitergeleitet.
  3. PC3 und PC4 verwerfen das Frame, da die Ziel Mac-Addresse des Frames nicht mit der eigenen Mac-Addresse übereinstimmmt.
  4. Switch2 speichert das Frame im Buffer

1.3 Switch 2 leitet das Frame weiter

  1. Switch2 trägt die Sender-Mac des Frames und den Port über den das Frame empfangen wurde in die Mac-Port Tabelle ein

  2. Switch2 sucht nach Eintrag der Ziel-Mac Addresse in der Mac-Port Tabelle

    • da es keinen gibt wird das Frame über alle Ports(außer dem Empfangsport) weitergeleitet

  3. PC6 verwirft das Frame, da eigene Mac und Ziel-Mac des Frames nicht übereinstimmen

  4. PC5 akzeptiert das Frame, da die eigene Mac und die Ziel-Mac des Frames übererinstimmen -> Die Daten können jetzt von höheren OSI-Layern verwendet werden

2. PC5 sendet ein Frame an PC1

2.1 PC5 sendet das Frame über das angeschlossene Kabel an Switch2

  1. PC5 erstellt Frame, trägt als Ziel Mac die vom PC1 ein, als Sender Mac die eigene Mac und alle anderen Felder.

  2. PC5 sendet das Frame über das Kabel

  3. Switch2 speichert das Frame im Buffer und überprüft die CRC Checksumme und verwirft das Frame falls diese falsch ist

2.2 Switch2 leitet das Frame weiter

  1. Switch2 nimmt PC5 in die Mac-Port Tabelle auf
  2. Switch2 findet die Ziel Mac Addresse des Frames in der Tabelle
  3. Switch2 sendet das Frame nur über den in der Tabelle hinterlegten Port --> Port 1
  4. Switch1 speichert das Frame im Buffer und überprüft die CRC Checksumme und verwirft das Frame falls diese falsch ist

2.3 Switch1 leitet das Frame weiter

  1. Switch1 nimmt PC5 in die Mac-Port Tabelle auf
  2. Switch1 findet die Ziel Mac Addresse des Frames in der Tabelle
  3. Switch1 sendet das Frame nur über den in der Tabelle hinterlegten Port --> Port 1
  4. PC2 empfängt das Frame und verwirft es, weil Ziel Mac des Frames und die eigene Mac Addresse nicht übereinstimmen
  5. PC1 empfängt und akzeptiert das Frame, da die Mac Addressen übereinstimmen

3. PC4 sendet ein Frame an PC5

3.1 PC5 sendet das Frame über das angeschlossene Kabel an Switch2

  1. PC4 erstellt Frame, trägt als Ziel Mac die vom PC5 ein, als Sender Mac die eigene Mac und alle anderen Felder.
  2. PC4 sendet das Frame über das Kabel
  3. Switch1 speichert das Frame im Buffer und überprüft die CRC Checksumme und verwirft das Frame falls diese falsch ist

3.2 Switch1 leitet das Frame weiter

  1. Switch1 nimmt PC4 in die Mac-Port Tabelle auf
  2. Switch1 findet die Ziel Mac Addresse des Frames in der Tabelle
  3. Switch1 sendet das Frame nur über den in der Tabelle hinterlegten Port --> Port 3
  4. Switch2 speichert das Frame im Buffer und überprüft die CRC Checksumme und verwirft das Frame falls diese falsch ist

3.3 Switch2 leitet das Frame weiter

  1. Switch2 nimmt PC4 in die Mac-Port Tabelle auf
  2. Switch2 findet die Ziel Mac Addresse des Frames in der Tabelle
  3. Switch2 sendet das Frame nur über den in der Tabelle hinterlegten Port --> Port 2
  4. PC1 empfängt und akzeptiert das Frame, da die Mac Addressen übereinstimmen