theo/hwr-notes
1
0
Fork 0
mirror of https://github.com/theoleuthardt/hwr-notes.git synced 2026-06-06 01:01:08 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

docs: add obsidian hwr docs

Browse source
This commit is contained in:
theoleuthardt 2026-04-09 11:24:56 +02:00
parent b2636f4b92
commit 850aa3455d
245 changed files with 30757 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

BIN
Netzwerke/zusammenfassungen/Troubleshooting_Netz.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 146 KiB

203
Netzwerke/zusammenfassungen/nw1 - zusammenfassung.md Normal file
View file

@ -0,0 +1,203 @@
# IT2222 – Netzwerktechnik
**Dozentin:** Gabriele Schrenk | HWR Berlin | 17. & 19.02.2026
---
## 1. Netzwerkgrundlagen
Ein **Netzwerk** ist ein Verbund zur Datenkommunikation, der den Datenaustausch zwischen Knoten (Stationen) ermöglicht.
---
## 2. Netzwerk-Komponenten
| Komponente | Funktion |
|---|---|
| **Repeater** | Verstärkt und überträgt Signale zwischen zwei Netzsegmenten |
| **Hub** | Verbindet mehrere Geräte (physikalischer Ring, virtueller Bus) – **veraltet** |
| **Bridge** | Verbindet zwei Netzwerke – **veraltet** |
| **Switch** | Verbindet mehrere Netzsegmente kollisionsfrei |
| **Router** | Verbindet mehrere Netze miteinander |
| **Gateway** | Wandelt Protokolle um |
---
## 3. Adressierungsarten
- **Unicast** – Adressierung an genau einen Empfänger; bidirektionale Kommunikation; Punkt-zu-Punkt
- **Broadcast** – Sendet an alle Systeme eines Netzabschnitts; Punkt-zu-Mehrpunkt
- **Multicast** – Sendet an eine definierte Gruppe mit verschiedenen Adressen; unidirektional, Punkt-zu-Mehrpunkt
- **Anycast** – Eine einzelne IP-Adresse wird von mehreren Servern geteilt; unidirektional, Punkt-zu-Punkt (nächster verfügbarer Server antwortet)
---
## 4. Netzwerk-Topologien
### Physikalische vs. Logische Topologie
- **Physikalisch:** Wie Geräte physisch über ein Medium verbunden sind
- **Logisch:** Wie Komponenten miteinander kommunizieren
### 4.1 Bus-Topologie
- Einsatz: industrielles Umfeld (z. B. Automotive)
- Punkt-zu-Mehrpunkt-Verbindung; Abschlusswiderstand an Kabelenden erforderlich
**Vorteile:** Knotenausfall beeinflusst das Netz nicht · geringe Kosten · einfache Verkabelung · keine aktiven Netzkomponenten
**Nachteile:** Leicht abhörbar (Verschlüsselung nötig) · defektes Kabel blockiert den gesamten Netzstrang · Datenstau möglich
### 4.2 Stern-Topologie
- Punkt-zu-Punkt-Verbindung mit zentralem Knoten (Switch/Hub)
**Vorteile:** Knotenausfall beeinflusst das Netz nicht · hohe Übertragungsraten (mit Switch) · leicht erweiterbar · leicht verständlich
**Nachteile:** Ausfall des zentralen Verteilers legt das gesamte Netz lahm · niedrige Übertragungsraten wenn Hub statt Switch verwendet wird
### 4.3 Baum-Topologie
- Punkt-zu-Punkt-Verbindung, hierarchisch gegliedert (Wurzel → Äste → Blätter)
**Vorteile:** Knotenausfall beeinflusst das Netz nicht · strukturell erweiterbar · große Entfernungen realisierbar
**Nachteile:** Ausfall eines Verteilers legt den gesamten „Ast" lahm · Engpässe an der Wurzel · Latenzprobleme
### 4.4 Leaf-Spine-Architektur (Data Center)
- Modernes Rechenzentrum-Design mit zwei Ebenen: Spine-Switches (Kern) und Leaf-Switches (Zugang)
**Vorteile:** Sehr leistungsfähig · hohe Skalierbarkeit · komplett redundant
**Nachteile:** Hoher Verkabelungsaufwand · hohe Anzahl an Switches · komplexe Auslastungsberechnung bei mehreren Herstellern
### 4.5 Maschen-Topologie (Mesh)
- Jeder Knoten hat mindestens einen Link zu anderen Knoten; vollvermaschtes Netz ermöglicht Umleitung bei Knotenausfall
**Vorteile:** Sehr sicher · sehr leistungsfähig · keine Streckenführung nötig (vollvermascht)
**Nachteile:** Hoher Verkabelungsaufwand · hoher Energieverbrauch · komplexe Streckenführung (teilvermascht)
### 4.6 Zell-Topologie (z. B. WLAN)
- Punkt-zu-Mehrpunkt-Verbindung; drahtloses Netz
**Vorteile:** Knotenausfall beeinflusst das Netz nicht · kabellos
**Nachteile:** Unsicher (Verschlüsselung erforderlich) · störanfällig · begrenzte Reichweite
---
## 5. Layer 2 – Data Link Layer (Sicherungsschicht)
### 5.1 Funktionsweise eines Switches
Ein Switch nutzt einen internen Speicher (Memory/CAM-Tabelle), um Datenpakete gezielt weiterzuleiten – ähnlich einem Kreisverkehr, der Fahrzeuge in die richtige Richtung schickt.
### 5.2 Switch-Funktionalität
- **Lernen:** Pflegt eine Adresstabelle pro Interface; merkt sich MAC-Quelladressen
- **Unicast:** Weiterleitung an das Interface, dessen Zieladresse in der Tabelle steht
- **Broadcast:** Weiterleitung an alle Interfaces
- **Flooding:** Weiterleitung an alle Interfaces, wenn die Zieladresse noch nicht in der Tabelle ist
### 5.3 Ethernet-Rahmenformat
Ein Ethernet-Frame besteht aus folgenden Feldern:
| Feld | Größe | Bedeutung |
|---|---|---|
| Preamble | 8 Byte | Bitmaske (010101...) zur Synchronisierung |
| Destination Address | 6 Byte | Ziel-MAC-Adresse |
| Source Address | 6 Byte | Quell-MAC-Adresse |
| Type/Length | 2 Byte | DIX Typfeld oder IEEE 802.2 Länge |
| DATA | 46–1500 Byte | Nutzdaten |
| CRC | 4 Byte | 32-Bit-Prüfsumme über Header und Daten |
### 5.4 Ethernet-Adressierung (MAC-Adresse)
- Jedes Ethernet-Interface hat eine **eindeutige 48-Bit-Adresse** (MAC-Adresse)
- Darstellung: hexadezimal, z. B. `00:80:48:E8:71:47`
- Aufbau: **OUI** (Organizationally Unique Identifier, 24 Bit, vom Hersteller) + **OUI-owner assigned number** (24 Bit, Gerätenummer)
- **Broadcast-Adresse:** `FF:FF:FF:FF:FF:FF` → jedes Interface verarbeitet diesen Frame
---
## 6. IP-Adressierung (Layer 3)
- IP-Adressen sind **32 Bit** lang (4 Byte)
- Darstellung: punktgetrennte Dezimalzahlen (z. B. `131.108.122.204`)
- Bestehen aus **Netzanteil** und **Hostanteil**
- Ergänzt durch symbolische Namen (DNS)
**Beispiel:**
```
Binär: 10000011 01101100 01111010 11001100
Dezimal: 131 . 108 . 122 . 204
```
---
## 7. ARP – Address Resolution Protocol
- Verbindet **Layer-2-Adressen (MAC)** mit **Layer-3-Adressen (IP)**
- Wird für IP-Adressen im **gleichen Subnetz** per Broadcast verwendet
- Für IP-Adressen in **anderen Subnetzen** wird die MAC-Adresse des Gateways verwendet
### ARP-Ablauf
1. **ARP-Request** (Broadcast): „Welche MAC-Adresse hat IP 172.16.3.2?"
2. Zielhost erkennt seine IP-Adresse und antwortet
3. **ARP-Reply** (Unicast): „Meine MAC-Adresse ist 0800.0020.1111"
4. Sender trägt die Zuordnung in seine **ARP-Tabelle** ein
### Sicherheitshinweis
- ARP-Antworten werden **nicht überprüft** → Angriff durch **ARP-Spoofing** möglich!
### Vollständiges Paket benötigt 4 Adressen:
- Quell-MAC-Adresse
- Ziel-MAC-Adresse
- Quell-IP-Adresse
- Ziel-IP-Adresse
---
## 8. ICMP – Internet Control Message Protocol
- **Zweck:** Informiert über Fehlerzustände im Netz und liefert rudimentäre Statusinformationen
- ICMP ist ein **Kontrollprotokoll**, nicht für Datentransport gedacht
- Bei Verlust von ICMP-Paketen erfolgt **kein automatischer Neuversand**
### Beispiele für ICMP-Einsatz
- Datagramm erreicht sein Ziel nicht
- Router kann ein Paket nicht weiterleiten
- Router kennt einen kürzeren Weg (Redirect)
### ICMPv4 (RFC 792)
- Layer-3-Protokoll; verbindungslos
- Verwendet IP für die Kommunikation
**ICMP-Header (32 Bit):**
| Feld | Größe |
|---|---|
| Typ-Feld | 8 Bit |
| Code-Feld | 8 Bit |
| Checksumme | 16 Bit |
### ICMP Echo Request / Reply (Ping)
- **Sender** schickt einen ICMP Echo-Request
- **Empfänger** sendet die Daten identisch zurück (Echo-Reply)
- Einfachste Methode zur **Verbindungsprüfung**
- Im Fehlerfall werden ICMP-Fehlerpakete gesendet
### ICMP Timestamp
- Dient der **Laufzeitprüfung** zwischen zwei Systemen
- Sender überträgt die Absendezeit in Millisekunden nach Mitternacht
- Empfänger trägt Empfangszeit und Absendezeit für den Rückweg ein (eliminiert interne Verarbeitungsverzögerung)
---
## Schnellreferenz: Schlüsselbegriffe
| Begriff | Bedeutung |
|---|---|
| MAC-Adresse | Eindeutige 48-Bit-Hardware-Adresse (Layer 2) |
| IP-Adresse | 32-Bit-logische Adresse (Layer 3) |
| ARP | Auflösung von IP → MAC im lokalen Netz |
| ICMP | Kontrollprotokoll für Fehler und Diagnosemeldungen |
| Switch | Layer-2-Gerät zur kollisionsfreien Segmentierung |
| Router | Layer-3-Gerät zur Verbindung verschiedener Netze |
| Broadcast | Nachricht an alle Teilnehmer im Netzabschnitt |
| Flooding | Switch leitet weiter, wenn Ziel-MAC unbekannt |
| OUI | Herstellerkennung in der MAC-Adresse |
| CRC | Prüfsumme zur Fehlererkennung im Ethernet-Frame |
| TTL | Time to Live – begrenzt Lebensdauer von IP-Paketen |

157
Netzwerke/zusammenfassungen/nw2 - zusammenfassung.md Normal file
View file

@ -0,0 +1,157 @@
# nw2 - Zusammenfassung
## 1. Grundlagen der Netzwerkkommunikation
Ein Netzwerk ist ein Zusammenschluss verschiedener IT-Systeme zum Zweck des Datenaustausches.
### Grundlegende Komponenten
* **Endsysteme (Hosts):** Start- und Endpunkte der Datenübertragung (PCs, Server, Smartphones).
* **Kopplungselemente:** Verbinden Netzabschnitte oder ganze Netze (Hubs, Switche, Router).
* **Übertragungsmedien:** Kabel (Kupfer, Glasfaser) oder Funkwellen (WLAN).
### Kommunikationsarten
1. **Unicast (Punkt-zu-Punkt):** Gezielte Verbindung zwischen einem Sender und einem Empfänger.
2. **Multicast (Punkt-zu-Mehrpunkt):** Nachricht an eine bestimmte Gruppe von Teilnehmern.
3. **Broadcast (Punkt-zu-Mehrpunkt):** Nachricht an alle Teilnehmer in einem Netzsegment.
---
## 2. Netzwerktopologien und Klassifizierung
Man unterscheidet zwischen der **physikalischen Topologie** (tatsächliche Verkabelung) und der **logischen Topologie** (tatsächlicher Datenfluss).
### Topologien im Überblick
* **Bus-Topologie:** Alle Teilnehmer hängen an einem Hauptkabel. Günstig, aber bei Kabelbruch fällt das gesamte Netz aus.
* **Stern-Topologie:** Alle Teilnehmer sind mit einem zentralen Switch verbunden. Höchste Flexibilität; fällt ein Kabel aus, betrifft es nur einen Teilnehmer.
* **Ring-Topologie:** Daten wandern von Rechner zu Rechner. Ausfall eines Geräts kann den Ring unterbrechen.
* **Vermaschtes Netz (Mesh):** Jeder mit jedem (vollvermascht) oder teils vermascht. Höchste Ausfallsicherheit, aber teuer in der Verkabelung.
### Entfernungsklassen
* **PAN (Personal Area Network):** Bluetooth, ca. 1-10 m.
* **LAN (Local Area Network):** Gebäude/Campus, 10 m bis ca. 1 km.
* **MAN (Metropolitan Area Network):** Stadtnetz, bis 100 km.
* **WAN (Wide Area Network):** Länder/Kontinente.
* **GAN (Global Area Network):** Weltweit (Internet).
---
## 3. Das OSI-Referenzmodell
Das OSI-Modell (Open Systems Interconnection) dient der Standardisierung der Kommunikation über sieben Schichten.
### Visuelle Darstellung
| Schicht | Ebene | Funktion | PDU (Einheit) | Hardware / Beispiel |
| :------ | :------------- | :----------------------------- | :------------ | :--------------------------- |
| **7** | Anwendung | Schnittstelle für Software | Daten | HTTP, FTP, Browser |
| **6** | Darstellung | Datenformate, Kompression | Daten | JPEG, ASCII, Verschlüsselung |
| **5** | Sitzung | Dialogsteuerung, Checkpoints | Daten | RPC, NetBIOS |
| **4** | Transport | End-zu-End Fehlersicherung | Segmente | TCP, UDP |
| **3** | Vermittlung | Routing, logische Adressierung | Pakete | Router, IP, ICMP |
| **2** | Sicherung | Physische Adressierung (MAC) | Frames | Switch, Ethernet |
| **1** | Bitübertragung | Physikalische Signale, Kabel | Bits | Hub, Repeater, Kabel |
**Datenkapselung:** Beim Senden wird eine **SDU** (Service Data Unit) von der höheren Schicht übernommen und durch Hinzufügen eines Protokoll-Headers zur **PDU** (Protocol Data Unit) der aktuellen Schicht. Beim Empfänger findet der umgekehrte Prozess statt (**Decapsulation**).
---
## 4. Layer 1 – Übertragungsmedien (Physical Layer)
Diese Schicht legt mechanische und elektrische Eigenschaften fest.
* **Kupferkabel (Twisted-Pair):** * Nutzt Differenzsignale auf verdrillten Adernpaaren, um elektromagnetische Störungen zu neutralisieren.
* Wellenwiderstand in der Netzwerktechnik meist 50 Ohm (im Vergleich zu 75 Ohm bei TV-Kabeln).
* **Lichtwellenleiter (LWL):**
* **Singlemode (OS1/OS2):** Kern ca. 9 µm. Nutzt Laser. Sehr hohe Reichweite (bis 10 km+) und Bandbreite, da kaum Signalstreuung (Modendispersion).
* **Multimode (OM1-OM5):** Kern 50 oder 62,5 µm. Nutzt LED/VCSEL. Günstiger, aber auf kürzere Distanzen begrenzt (bis ca. 550 m), da die Lichtstrahlen unterschiedlich reflektiert werden.
---
## 5. Layer 2 – Sicherungsschicht (Data Link Layer)
Hier geht es um den fehlerfreien Transport innerhalb eines Netzsegments.
### Ethernet & Switching
* **MAC-Adresse:** 48 Bit lange, eindeutige Hardwareadresse (z. B. `00-80-41-ae-fd-7e`).
* **Switching-Methoden:**
1. **Store-and-forward:** Der Frame wird komplett eingelesen, auf Fehler (CRC) geprüft und dann weitergeleitet (Sicher, aber langsamer).
2. **Cut-through:** Weiterleitung beginnt, sobald die Ziel-MAC gelesen wurde (Schnell, leitet aber auch defekte Frames weiter).
### Spanning Tree Protocol (STP - 802.1D)
Verhindert redundante Schleifen in Netzen, die zu "Broadcast-Stürmen" führen würden.
1. **Wahl der Root-Bridge:** Switch mit der niedrigsten Bridge ID (Priorität + MAC) wird Chef.
2. **Pfadauswahl:** Redundante Wege werden logisch in den Zustand "Blocking" versetzt.
### VLANs (802.1Q)
Ermöglichen die logische Trennung von Netzen auf demselben physikalischen Switch.
* **Statische VLANs:** Port-basiert.
* **Dynamische VLANs:** Zuordnung basierend auf der MAC-Adresse des Endgeräts.
---
## 6. WLAN (Wireless LAN - 802.11)
WLAN ist ein "Shared Medium" – alle Geräte teilen sich die Funkfrequenz.
* **Frequenzen:** * 2,4 GHz (Gute Reichweite, aber überlaufen durch Bluetooth/Mikrowellen).
* 5 GHz (Höhere Datenraten, weniger Reichweite).
* **Prozess beim Verbindungsaufbau:**
1. **Scanning/Probing:** Suchen nach verfügbaren Netzen (SSID).
2. **Authentifizierung:** Prüfung der Zugriffsberechtigung.
3. **Assoziation:** Der Client meldet sich am Access Point an und bekommt eine Port-ID (ähnlich wie beim Switch).
---
## 7. Layer 3 – Vermittlungsschicht (IPv4 Adressierung)
Layer 3 verbindet unterschiedliche Netzwerke durch Routing.
### IPv4-Adressstruktur
Eine Adresse hat 32 Bit (4 Oktette à 8 Bit).
* **Klasse A:** 1 – 126 (Große Netze)
* **Klasse B:** 128 – 191 (Mittlere Netze)
* **Klasse C:** 192 – 223 (Kleine Netze)
* **Klasse D:** 224 – 239 (Multicast)
* **Klasse E:** 240 – 255 (Forschung/Reserviert)
**Spezialfall:** `127.0.0.1` ist die Loopback-Adresse (Localhost), um die eigene Netzwerkkarte zu testen.
### Binäre Umrechnung (Wichtig!)
Computer denken in Binärzahlen. Ein Oktett hat die Wertigkeiten:
`128 | 64 | 32 | 16 | 8 | 4 | 2 | 1`
**Beispiel Umrechnung der Zahl 144:**
1. Passt 128 in 144? **JA** (Bit = 1), Rest 16.
2. Passt 64 in 16? **NEIN** (Bit = 0).
3. Passt 32 in 16? **NEIN** (Bit = 0).
4. Passt 16 in 16? **JA** (Bit = 1), Rest 0.
5. Alle weiteren (8, 4, 2, 1) sind **0**.
**Binärergebnis: 10010000**
---
## 8. TCP/IP-Referenzmodell
Im Gegensatz zum OSI-Modell hat das praxisnahe TCP/IP-Modell meist nur 4 Schichten:
1. **Application:** (OSI 5-7) – HTTP, DNS, SMTP.
2. **Transport:** (OSI 4) – TCP (verbindungsorientiert) und UDP (verbindungslos).
3. **Internet:** (OSI 3) – IPv4, IPv6, ICMP.
4. **Network Access:** (OSI 1-2) – Ethernet, WLAN, ARP.
## 9. Definitionen
### MAC-Adresse (Media Access Control)
Die MAC-Adresse ist die **physische Identität** deines Geräts. Sie wird vom Hersteller direkt in den Netzwerkchip (z. B. WLAN-Modul oder Ethernet-Karte) "eingebrannt".
- **Eigenschaft:** Weltweit einzigartig und (normalerweise) unveränderlich.
- **Vergleich:** Wie die **Fahrgestellnummer** eines Autos. Egal wo das Auto hinfährt, die Nummer bleibt gleich.
- **Format:** Besteht meist aus sechs Paaren von Hexadezimalzahlen, z. B. `00:1A:2B:3C:4D:5E`.
### IP-Adresse (Internet Protocol)
Die IP-Adresse ist die **logische Anschrift** deines Geräts in einem Netzwerk. Sie wird dir zugewiesen, damit Datenpakete wissen, wohin sie geliefert werden müssen.
- **Eigenschaft:** Veränderlich. Sie hängt davon ab, mit welchem Netzwerk du gerade verbunden bist.
- **Vergleich:** Wie eine **Postanschrift**. Wenn du umziehst (oder dich in ein anderes WLAN einwählst), ändert sich deine Adresse, damit die Post dich finden kann.
- **Formate:**
- **IPv4:** Vier Zahlenblöcke (z. B. `192.168.178.1`).
- **IPv6:** Ein längeres Format für mehr verfügbare Adressen (z. B. `2001:0db8:85a3...`).
#### Der entscheidende Unterschied
|**Merkmal**|**MAC-Adresse**|**IP-Adresse**|
|---|---|---|
|**Was ist es?**|Hardware-Identität|Netzwerk-Standort|
|**Wer vergibt sie?**|Der Hersteller|Der Router / Provider|
|**Sichtbarkeit**|Lokal im eigenen Netzwerk|Weltweit (bei öffentlichen IPs)|

711
Netzwerke/zusammenfassungen/nw3 - zusammenfassung.md Normal file
View file

@ -0,0 +1,711 @@
# IT2221 – Netzwerktechnik: Themenliste & Zusammenfassung
**Dozentin:** Gabriele Schrenk
**Datum:** 06.03.2026
**Umfang:** 92 Folien
---
## Themenliste (Inhaltsverzeichnis)
1. **Organisatorisches** (Folie 1–2)
2. **Layer 2 – Data Link Layer / Sicherungsschicht** (Folie 3–9)
- OSI-Modell Kommunikation
- VLAN: Realisierung
- VLAN: IEEE 802.1q (Tagging, Frame-Struktur)
- Priorisierung nach IEEE 802.1p (QoS auf Layer 2)
3. **Layer 3 – Network Layer / Netzwerkschicht** (Folie 10–52)
- IPv4 – Grundlagen und Header
- Komponenten einer IP-Adresse
- IP-Adressklassen (A, B, C)
- Unterteilung der IP-Adressen (Netz- und Broadcastadresse)
- Subnetze und Subnetzmasken (Classless)
- CIDR (Classless Inter-Domain Routing)
- Beispielaufgabe Subnetting (IP 220.8.7.100 / Maske 255.255.255.240)
- Gruppenaufgabe Subnetting (IP 142.63.12.70 / Maske 255.255.254.0)
4. **Layer 2/3 – Address Resolution Protocol (ARP)** (Folie 53–58)
5. **Layer 3 – Internet Control Message Protocol (ICMP)** (Folie 59–73)
- ICMPv4 Meldungen und Protokollstruktur
- ICMP Echo Request/Reply (ping)
- ICMP Fehler: Network Unreachable, Destination Unreachable, Port Unreachable, Time Exceeded
- ICMP Timestamp
- ICMP in der Praxis: Traceroute
6. **Layer 3 – Routing-Protokolle** (Folie 74–92)
- Statisches vs. dynamisches Routing
- Private und reservierte Adressräume (RFC 1918, RFC 5735)
- Anforderungen an Routing-Protokolle
- Metrik
- Distance Vector vs. Link State
- Autonome Systeme (IGP vs. EGP)
- Routing-Protokoll-Beispiele (RIP, IGRP, OSPF, IS-IS, BGP)
- OSPF im Detail: SPF-Algorithmus, Designated Router, Nachbarschaften, Areas, Virtual Links, LSA-Klassen
---
## 1. Organisatorisches (Folien 1–2)
Die Vorlesung IT2221 – Netzwerktechnik umfasst insgesamt **10 Online-Vorlesungen** über BigBlueButton (BBB). Der Kursplan ist wie folgt aufgebaut:
1. Grundlagen, IP-Adressierung, OSI-Modell, Ethernet (Labor)
2. Layer 1 und 2 an den Beispielen Ethernet und WLAN
3. Layer 3 am Beispiel von IPv4 und Routing-Protokolle
4. Layer 3 Routing-Protokolle, Layer 4 am Beispiel von TCP und UDP
5. Layer 3 am Beispiel von IPv6
6. Layer 7 am Beispiel von DNS und DHCP, Weitverkehrsnetze
7. Weitverkehrsnetze, ausfallsichere Netze
8. Netzwerksicherheit
9. Netzwerksicherheit (Fortsetzung)
10. Prüfungsvorbereitung
Die vorliegenden Folien decken primär die **Vorlesungen 2, 3 und Teile von 4** ab – also Layer 2 (VLAN, QoS), Layer 3 (IPv4, Subnetting, ARP, ICMP) und Routing-Protokolle (insbesondere OSPF).
---
## 2. Layer 2 – Data Link Layer / Sicherungsschicht (Folien 3–9)
### 2.1 Kommunikation nach dem OSI-Modell (Folie 4)
Das OSI-Referenzmodell (Open Systems Interconnection) besteht aus **7 Schichten**, die in **obere Schichten** (Layer 5–7: Session, Darstellung, Anwendung) und **untere Schichten** (Layer 1–4: Physikalisch, Data Link, Netzwerk, Transport) unterteilt werden.
Jede Schicht kommuniziert logisch mit ihrer Peer-Schicht auf der Gegenseite (**Peer-to-Peer Communication**), während die tatsächliche physische Kommunikation über den **Physical Link** auf Layer 1 stattfindet. Daten wandern beim Sender von oben nach unten durch den Stack, über das physische Medium zum Empfänger, und dort wieder von unten nach oben. Router arbeiten dabei auf Layer 3 und leiten Pakete zwischen verschiedenen Netzen weiter.
### 2.2 VLAN: Realisierung (Folie 5)
Ein **VLAN (Virtual Local Area Network)** ermöglicht die logische Segmentierung eines physischen Netzwerks. Im gezeigten Beispiel verbinden zwei Switches (Switch A und Switch B) jeweils drei VLANs: Blue VLAN (VLAN 1), Black VLAN (VLAN 2) und Green VLAN (VLAN 3).
Die Switches sind über einen **Trunk-Port** via Fast Ethernet verbunden. Über diesen Trunk werden Frames aller VLANs übertragen, wobei jeder Frame mit einer VLAN-ID getaggt wird. Endgeräte sind jeweils einem bestimmten VLAN zugeordnet und können nur innerhalb ihres VLANs direkt kommunizieren. Die Kommunikation zwischen verschiedenen VLANs erfordert einen Router (Inter-VLAN-Routing).
### 2.3 VLAN: IEEE 802.1q (Folien 6–7)
Der Standard **IEEE 802.1q** definiert das VLAN-Tagging auf Layer 2. Die wichtigsten Merkmale sind:
- Jedem **Switchport** wird ein VLAN zugeordnet (Access Port).
- Zwischen Switches wird jeder Frame mit einer **VLAN-ID markiert** (Tagged/Trunk Port).
- **Verbindungen zwischen VLANs** erfolgen ausschließlich über Router.
- **VLAN-Informationen** müssen auf allen beteiligten Switches identisch konfiguriert sein.
- VLANs sind ein Mittel zur **Strukturierung des Netzes**.
- Es sind bis zu **4095 VLANs** pro Node möglich (12-Bit VLAN-ID).
- Der Standard unterstützt VLAN-Typen 1, 2 und 3.
- Sowohl geswitchte als auch Shared-Media-LANs werden unterstützt.
- IEEE 802.1q führt neue **Priorisierungen** ein (siehe IEEE 802.1p).
**Frame-Struktur mit 802.1q-Tag:**
Der 802.1q-Header wird zwischen Source-MAC-Adresse und dem ursprünglichen EtherType/Length-Feld eingefügt. Er besteht aus:
- **TPID (Tag Protocol Identifier):** In der Regel 0x8100 – zeigt an, dass der Frame nach 802.1q getaggt ist.
- **TCI (Tag Control Information):** Enthält:
- **User Priority / PCP (Priority Code Point):** 3 Bit für die Priorisierung.
- **CFI (Canonical Format Indicator):** Heute als **DEI (Drop Eligible Indicator)** verwendet – 0 = drop-berechtigt, 1 = darf verworfen werden.
- **VID (VLAN ID):** 12 Bit, erlaubt Werte von 0 bis 4095.
Der gesamte getaggte Frame besteht aus: Preamble (7 Byte) → SFD (1 Byte) → Destination MAC (6 Byte) → Source MAC (6 Byte) → **802.1Q Header (4 Byte)** → EtherType/Size (2 Byte) → Payload (variabel) → CRC/FCS (4 Byte).
### 2.4 Priorisierung nach IEEE 802.1p – QoS auf Layer 2 (Folien 8–9)
**IEEE 802.1p** ist kein eigenes Tag-Format, sondern ein Standard für die **Layer-2-Priorisierung** im Rahmen von **Quality of Service (QoS)**. Die Priorisierung wird durch die **3 PCP-Bits** (Priority Code Point) im 802.1q-Header realisiert. Switches können anhand dieser PCP-Bits Queues, Scheduling und Traffic-Klassen steuern.
**Zusammengefasst:**
- **802.1Q:** Markiert den Frame mit einem VLAN-Tag.
- **802.1p:** Interpretiert die 3 PCP-Bits als unterschiedliche Service-Klassen/Prioritäten.
**Die 8 Prioritätsstufen nach 802.1p (herstellerspezifisch):**
|PCP-Wert|Bedeutung|
|---|---|
|0|Best Effort|
|1|Background|
|2|Spare|
|3|Excellent Effort|
|4|Controlled Load|
|5|Video|
|6|Voice|
|7|Network Control|
Wichtig: Switches können intern auch **ohne VLAN-Tag priorisieren**, z. B. nach eingehendem Port, MAC-Adresse, EtherType oder ACL. Dies ist jedoch **herstellerspezifische QoS-Logik** und nicht Teil des IEEE 802.1p Standards.
---
## 3. Layer 3 – Network Layer / Netzwerkschicht (Folien 10–52)
### 3.1 Internet Protocol Version 4 – IPv4 (Folien 11–13)
IPv4 arbeitet auf **Layer 3** (Network Layer / Vermittlungsschicht) und ist das zentrale Protokoll für die Adressierung und Weiterleitung von Datenpaketen im Internet.
**Komponenten einer IPv4-Adresse (Folie 12):**
Eine IPv4-Adresse ist **32 Bit** lang und wird in **4 Oktette** (je 8 Bit = 1 Byte) unterteilt, die in der dezimalen Punkt-Notation dargestellt werden. Beispiel: 131.108.122.204 entspricht in Binär: 10000011.01101100.01111010.11001100.
Jede IP-Adresse besteht aus einem **Netz-Anteil** und einem **Host-Anteil**. Welche Bits zum Netz und welche zum Host gehören, wird durch die Subnetzmaske bestimmt.
**IPv4-Header (Folie 13):**
Der IPv4-Header hat eine Mindestlänge von 20 Byte (ohne Optionen) und enthält die folgenden wichtigen Felder:
|Feld|Beschreibung|
|---|---|
|**Version**|Immer 4 (für IPv4)|
|**HLEN**|Header Length (in 32-Bit-Worten)|
|**TOS (Type of Service)**|3 Bits – enthält Flags für „minimize delay", „maximize throughput", „maximize reliability", „minimize cost"|
|**Total Length**|Gesamtlänge des IP-Datagramms (Header + Daten)|
|**Datagram ID / Identifier**|Eindeutige ID eines Datagramms (für Fragmentierung)|
|**Flags**|Steuerung der Fragmentierung (z. B. „Don't Fragment")|
|**Fragment Offset**|Position des Fragments im ursprünglichen Datagramm|
|**TTL (Time to Live)**|Maximale Anzahl an Hops, wird bei jedem Router um 1 reduziert|
|**Protocol**|Identifiziert das enkapsulierte Protokoll (z. B. 6 = TCP, 17 = UDP, 1 = ICMP)|
|**Header-Prüfsumme (Checksum)**|Prüfsumme nur über den Header|
|**Quell-IP-Adresse**|IP-Adresse des Absenders (32 Bit)|
|**Ziel-IP-Adresse**|IP-Adresse des Empfängers (32 Bit)|
|**IP-Optionen + Padding**|Optional, variable Länge|
### 3.2 IP-Adressklassen (Folie 14)
Im klassischen (classful) IP-Adressierungsschema gibt es drei Hauptklassen:
**Klasse A:**
- Erstes Bit: 0
- Netz-Adresse: 7 Bit → 128 Netze
- Host-Adresse: 24 Bit → 2²⁴ − 2 = **16.777.214 Hosts** pro Netz
- Adressbereich: 1.0.0.0 bis 126.0.0.0
**Klasse B:**
- Erste Bits: 10
- Netz-Adresse: 14 Bit → 16.384 Netze
- Host-Adresse: 16 Bit → 2¹⁶ − 2 = **65.534 Hosts** pro Netz
- Adressbereich: 128.0.0.0 bis 191.255.0.0
**Klasse C:**
- Erste Bits: 110
- Netz-Adresse: 21 Bit → über 2 Millionen Netze
- Host-Adresse: 8 Bit → 2⁸ − 2 = **254 Hosts** pro Netz
- Adressbereich: 192.0.0.0 bis 223.255.255.0
**Wichtige Regeln:**
- Die **niedrigste Adresse** eines Netzes ist die **Netzadresse** (alle Host-Bits = 0).
- Die **höchste Adresse** eines Netzes ist die **Broadcastadresse** (alle Host-Bits = 1).
- Daher werden immer **2 Adressen** vom nutzbaren Adressraum abgezogen.
### 3.3 Unterteilung der IP-Adressen (Folie 15)
- **Netzadresse:** Host-Anteil enthält nur Nullen. Beispiel: 134.30.0.0 mit Maske 255.255.0.0 (/16).
- **Broadcastadresse:** Host-Anteil enthält nur Einsen. Beispiel: 134.30.255.255/16 – erreicht alle Hosts im Netz.
- **Limited Broadcast:** 255.255.255.255 – wird bei **DHCP** verwendet, wenn das konkrete Netz noch nicht bekannt ist. Erreicht alle Hosts im lokalen IP-Segment.
### 3.4 Subnetze – „Classless" (Folien 16–23)
**Warum Subnetting? (Folie 18):**
- **Verringert die Größe einer Broadcast-Domäne** – weniger Broadcast-Traffic.
- Ermöglicht die **Realisierung von Abteilungen** – logische Trennung innerhalb einer Organisation.
- Verhindert Probleme, wenn **zu viel Bandbreite** belegt wird – hohes Verkehrsaufkommen führt zu Verzögerungsanstieg (Latenzen).
**Prinzip des Subnettings (Folie 16–17):**
Beim classless Routing sieht die Außenwelt nur ein einziges Netz, kennt keine Details oder Struktur des internen Aufbaus. Routing-Tabellen bleiben dadurch überschaubar und die Außenwelt braucht nur eine Netzadresse für die Erreichbarkeit.
Beim Subnetting werden **Bits aus dem Host-Feld entlehnt** (mindestens 2 Bits), um ein neues **Subnetz-Feld** zu bilden. Die IP-Adresse setzt sich dann zusammen aus: Netz-Teil + Subnetz-Feld + (neues, kleineres) Host-Feld.
**Subnetzmaske (Folie 19):**
Die Subnetzmaske ist 32 Bit lang und in vier Oktette unterteilt. Im Netz- und Subnetzabschnitt stehen **Einsen**, im Host-Abschnitt stehen **Nullen**.
Beispiel: /20 = 255.255.240.0 = 11111111.11111111.11110000.00000000 → 20 Bits für das Netzwerk, 12 Bits für den Host.
**Die AND-Funktion (Folie 20):**
Um die Netzadresse zu ermitteln, wird ein **logisches UND (AND)** zwischen der Ziel-IP-Adresse und der Subnetzmaske ausgeführt. Das Ergebnis ist die Netzwerk- bzw. Subnetzadresse.
Beispiel:
- IP-Adresse: 195.013.132.163 (binär: 11000011.00001101.10000100.10100011)
- Netzmaske: 255.255.255.224 (binär: 11111111.11111111.11111111.11100000)
- AND-Ergebnis: 195.013.132.160 (binär: 11000011.00001101.10000100.10100000) → Netzadresse
- Hostnummer: IP AND (NOT Maske) = 3
**Subnetz-Bits und Anzahl der Subnetze (Folie 22):**
|Entlehnte Bits|Mögliche Subnetze|
|---|---|
|2 Bits|2² = 4|
|3 Bits|2³ = 8|
|4 Bits|2⁴ = 16|
Beispiel: Bei einem Klasse-C-Netz mit Subnetzmaske 255.255.255.240 → 240 = 11110000 binär → 4 Bits für das Subnetzfeld.
**Dezimaldarstellung gängiger Masken (Folie 23):**
|Binär|Dezimal|
|---|---|
|10000000|128|
|11000000|192|
|11100000|224|
|11110000|240|
|11111000|248|
|11111100|252|
|11111110|254|
|11111111|255|
### 3.5 Classless Inter-Domain Routing – CIDR (Folie 24)
Die CIDR-Notation (/n) gibt die Anzahl der Netz-Bits direkt an. Die Folie zeigt eine vollständige Tabelle aller CIDR-Präfixe von /0 bis /32 mit den zugehörigen Subnetzmasken, Binärdarstellungen und der Anzahl verfügbarer Adressen pro Subnetz.
Besondere Adressen:
- **DHCP-Client** nutzt Source 0.0.0.0 → Destination 255.255.255.255 (da er seine eigene Adresse noch nicht kennt).
- **/0** (0.0.0.0) wird als **Default Route** in Routing-Tabellen verwendet.
Wichtige CIDR-Werte:
|CIDR|Maske|Adressen|
|---|---|---|
|/32|255.255.255.255|1|
|/30|255.255.255.252|4|
|/28|255.255.255.240|16|
|/24|255.255.255.0|256|
|/16|255.255.0.0|65.536|
|/8|255.0.0.0|16.777.216|
### 3.6 Beispielaufgabe – Subnetting (Folien 25–38)
**Gegeben:** IP-Adresse 220.8.7.100, Netzmaske 255.255.255.240
**1. Nutzbare IP-Adressen pro Subnetz:**
- Maske: 255.255.255.240 = 11111111.11111111.11111111.1111**0000** = **/28**
- Es verbleiben 4 Bit für den Host-Anteil.
- Nutzbare Adressen = 2⁴ − 2 = **14**
**2. Zahl der möglichen Subnetze:**
- Bei /28 verbleiben 4 Bit für Hosts. Davon können noch 2 Bits für weitere Subnetze entlehnt werden (bis maximal /30).
- 2² = **4 weitere Subnetze** möglich.
**3. Netzadresse:**
- IP: 11011100.00001000.00000111.0110**0100**
- Maske: 11111111.11111111.11111111.1111**0000**
- AND: 11011100.00001000.00000111.0110**0000**
- Netzadresse = **220.8.7.96**
- Merke: **Netzwerkadressen sind immer gerade Zahlen!**
**4. Broadcastadresse:**
- Netzadresse nehmen, alle Host-Bits (die Nullen in der Maske) auf 1 setzen.
- 11011100.00001000.00000111.0110**1111**
- Broadcastadresse = **220.8.7.111**
- Merke: **Broadcastadressen sind immer ungerade Zahlen!**
**5. Erste nutzbare IP-Adresse:**
- Netzadresse + 1 im Host-Teil.
- 11011100.00001000.00000111.0110**0001**
- Erste IP-Adresse = **220.8.7.97**
- Merke: **Die erste freie IP-Adresse ist immer eine ungerade Zahl!**
**6. Letzte nutzbare IP-Adresse:**
- Broadcastadresse − 1.
- 11011100.00001000.00000111.0110**1110**
- Letzte IP-Adresse = **220.8.7.110**
- Merke: **Die letzte freie IP-Adresse ist immer eine gerade Zahl!**
**Zusammenfassung der Beispielaufgabe:**
|Gesucht|Ergebnis|
|---|---|
|Nutzbare IPs/Subnetz|14|
|Mögliche Subnetze|4|
|Netzadresse|220.8.7.96|
|Broadcastadresse|220.8.7.111|
|Erste IP|220.8.7.97|
|Letzte IP|220.8.7.110|
### 3.7 Gruppenaufgabe – Subnetting (Folien 39–52)
**Gegeben:** IP-Adresse 142.63.12.70, Netzmaske 255.255.254.0
**1. Nutzbare IP-Adressen pro Subnetz:**
- Maske: 255.255.254.0 = 11111111.11111111.1111111**0.00000000** = **/23**
- Es verbleiben 9 Bit für den Host-Anteil.
- Nutzbare Adressen = 2⁹ − 2 = **510**
**2. Zahl der möglichen Subnetze:**
- Von den 9 Host-Bits können bis zu 7 Bits für Subnetze entlehnt werden (bis /30).
- 2⁷ = **128 weitere Subnetze** möglich.
**3. Netzadresse:**
- IP: 10001110.00111111.0000110**0.01000110**
- Maske: 11111111.11111111.1111111**0.00000000**
- AND: 10001110.00111111.0000110**0.00000000**
- Netzadresse = **142.63.12.0**
**4. Broadcastadresse:**
- Host-Bits auf 1 setzen: 10001110.00111111.0000110**1.11111111**
- Broadcastadresse = **142.63.13.255**
**5. Erste nutzbare IP-Adresse:**
- Netzadresse + 1: 10001110.00111111.00001100.0000000**1**
- Erste IP-Adresse = **142.63.12.1**
**6. Letzte nutzbare IP-Adresse:**
- Broadcastadresse − 1: 10001110.00111111.00001101.1111111**0**
- Letzte IP-Adresse = **142.63.13.254**
**Zusammenfassung der Gruppenaufgabe:**
|Gesucht|Ergebnis|
|---|---|
|Nutzbare IPs/Subnetz|510|
|Mögliche Subnetze|128|
|Netzadresse|142.63.12.0|
|Broadcastadresse|142.63.13.255|
|Erste IP|142.63.12.1|
|Letzte IP|142.63.13.254|
Hinweis: Auf Folie 44 wird die Maske fälschlicherweise als 255.255.250.0 angegeben – korrekt ist durchgängig **255.255.254.0**. Ebenso wird auf Folie 47 die Maske als 255.255.255.240 beschrieben, obwohl 255.255.254.0 gemeint ist. Die Berechnungen in den Lösungen sind aber konsistent mit /23 (255.255.254.0).
---
## 4. Layer 2/3 – Address Resolution Protocol (ARP) (Folien 53–58)
### 4.1 Grundlagen (Folie 54–55)
Ein vollständiges Netzwerkpaket benötigt **vier Adressen**: Quell-IP, Ziel-IP (Layer 3), Quell-MAC und Ziel-MAC (Layer 2). ARP stellt die **Verbindung zwischen Layer 2 (MAC) und Layer 3 (IP) Adressen** her.
**Kernmerkmale von ARP:**
- ARP löst eine bekannte IP-Adresse in die zugehörige MAC-Adresse auf.
- Für IP-Adressen **im gleichen Subnetz**: ARP sendet einen **Broadcast** ins lokale Netz.
- Für IP-Adressen **in einem anderen Subnetz**: Es wird die **MAC-Adresse des Gateways (Routers)** verwendet.
- **ARP-Request = Broadcast**, **ARP-Reply = Unicast**.
- Jeder Host führt eine **ARP-Tabelle** mit den zugeordneten MAC/IP-Paaren.
- Die ARP-Antwort wird **nicht authentifiziert oder geprüft** – dies ermöglicht **ARP-Spoofing** als Sicherheitsrisiko!
### 4.2 ARP-Ablauf im Detail (Folien 56–58)
**Schritt 1 – ARP-Request (Broadcast):** Host 172.16.3.1 möchte mit Host 172.16.3.2 kommunizieren, kennt aber dessen MAC-Adresse nicht. Er sendet einen ARP-Request als Broadcast an alle Geräte im Netz: „Welche MAC-Adresse hat 172.16.3.2?"
**Schritt 2 – Empfang und Erkennung:** Alle Hosts im Segment empfangen den Broadcast. Host 172.16.3.2 erkennt, dass seine eigene IP-Adresse angefragt wird und weiß: „Diese Nachricht ist für mich."
**Schritt 3 – ARP-Reply (Unicast):** Host 172.16.3.2 antwortet direkt (Unicast) an den Absender mit seiner MAC-Adresse: „IP: 172.16.3.2, Ethernet: 0800.0020.1111." Der anfragende Host trägt das Ergebnis in seine ARP-Tabelle ein.
---
## 5. Layer 3 – Internet Control Message Protocol (ICMP) (Folien 59–73)
### 5.1 Grundlagen ICMP (Folien 60–63)
ICMP (Internet Control Message Protocol) ist ein **Layer-3-Kontrollprotokoll**, das – im Gegensatz zu IP (Datenübertragung) – für **Fehlermeldungen und Informationsaustausch** definiert ist.
**Wichtige Eigenschaften:**
- ICMP verwendet IP für die Kommunikation.
- Definiert im Standard **IETF RFC 792**.
- ICMP ist **verbindungslos**.
- Bei Verlust von ICMP-Paketen erfolgt **kein automatischer Neuversand**.
**ICMP-Header (32 Bit):**
|Feld|Größe|Beschreibung|
|---|---|---|
|Typ|8 Bit|Art der Anfrage/Antwort|
|Code|8 Bit|Details, z. B. genaue Art des Fehlers|
|CRC/Checksumme|16 Bit|Prüfsumme über den ICMP-Header|
|Unused|32 Bit|Abhängig von Typ und Code als Datenbereich genutzt|
|IP Header + 64 Bit Data|variabel|Anfang des ursprünglichen IP-Pakets|
### 5.2 ICMPv4 Meldungstypen (Folie 61)
**Fehlermeldungen:**
- Empfänger nicht erreichbar (Destination Unreachable)
- Wegumleitung (Redirect)
- Ressourcen verbraucht (Resource Expired)
- Zeitablauf (Time Exceeded)
- Parameterproblem (Parameters Problem)
**Informationsmeldungen:**
- Echo-Anforderung / -Antwort (Echo Request / Reply)
- Information
- Zeitmessung (Timestamp)
- Adressmaske
### 5.3 ICMPv4 – Typ- und Code-Feld (Folie 64)
**Echo Reply (Typ 0) und Echo Request (Typ 8):**
- Wird vom **ping-Kommando** verwendet.
**Destination Unreachable (Typ 3) mit verschiedenen Codes:**
|Code|Bedeutung|
|---|---|
|0|Network unreachable|
|1|Host unreachable|
|2|Protocol unreachable|
|3|Port unreachable|
|9|Destination network administratively prohibited|
### 5.4 ICMP Echo Request/Reply – Ping (Folie 65)
- Der **Sender** überträgt eine ICMP-Echo-Request-Nachricht.
- Der **Empfänger** sendet die Daten als Echo-Reply genauso zurück.
- Dies ist die **einfachste Form der Verbindungsprüfung**.
- Im Fehlerfall werden ICMP-Fehlerpakete zurückgesendet.
### 5.5 ICMP-Fehlermeldungen im Detail
**Network Unreachable (Folie 66):**
- **Symptom:** Ein ganzes Subnetz ist nicht erreichbar.
- **Mögliche Ursachen:** Leitung ausgefallen, Routingprotokoll gestört (z. B. OSPF), Subnetz existiert nicht, Routingtabelle fehlerhaft, kein Default-Router, Ausfall eines Routers.
**Destination Unreachable / Host Unreachable (Folie 67):**
- **Symptom:** Subnetz ist erreichbar, aber das Endgerät nicht.
- **Mögliche Ursachen:** Endgerät ausgeschaltet, Kabelverbindung/WLAN defekt, falsche IP-Adresse konfiguriert, Switch ausgefallen.
**Port Unreachable (Folien 68–69):**
- **Symptom:** Ein Dienst bzw. eine Applikation erreicht das Endgerät nicht, obwohl das Endgerät per ping/traceroute vom Router aus erreichbar ist.
- **Mögliche Ursachen:** Firewall in der Wegstrecke blockiert den Port, Dienst auf dem Endgerät nicht mehr aktiv, falscher Eintrag der Dienst-Portnummer-Zuordnung.
**Time Exceeded (Folie 70):**
- Tritt auf, wenn ein Router das **TTL-Feld auf 0** setzt (Paket wird verworfen) oder wenn ein Endsystem ein **fragmentiertes Paket nicht innerhalb einer bestimmten Zeit** wieder zusammensetzen kann.
### 5.6 ICMP Timestamp (Folie 71)
ICMP Timestamp ermöglicht eine **Laufzeitprüfung** zwischen zwei Systemen:
- Der **Sender** überträgt seine Absendezeit in Millisekunden nach Mitternacht.
- Der **Empfänger** trägt die Empfangszeit ein und fügt die Absendezeit für den Rückweg hinzu (eliminiert die interne Verzögerung des Empfängers).
### 5.7 ICMP in der Praxis – Traceroute (Folien 72–73)
**Traceroute** nutzt die ICMP-Time-Exceeded-Meldungen zur **Routenverfolgung**:
1. Paket mit **TTL = 1** senden → erster Router reduziert TTL auf 0, verwirft das Paket und sendet „Time Exceeded" zurück → IP des ersten Routers bekannt.
2. Paket mit **TTL = 2** senden → zweiter Router meldet Time Exceeded → IP des zweiten Routers bekannt.
3. Dieser Prozess wird fortgesetzt, bis das Ziel erreicht wird.
**Praxisbeispiel (Folie 73):**
```
C:\Users\gabriele>tracert google.com
Tracing route to google.com [216.58.206.46] over a maximum of 30 hops:
1 1 ms 2 ms 1 ms firewall-eantcoffice.eantc.de [192.168.121.1]
2 4 ms 3 ms * 217.110.43.165
3 11 ms 11 ms 11 ms 193.114.169.141
4 * * * Request timed out.
5 10 ms 14 ms 12 ms 108.170.236.175
6 11 ms 11 ms 12 ms 192.178.74.163
7 12 ms 11 ms 11 ms lcfraa-aa-in-f14.1e100.net [216.58.206.46]
Trace complete
```
Hop 4 zeigt „Request timed out" – dies bedeutet, dass der Router an dieser Stelle keine ICMP-Antworten zurücksendet (z. B. Firewall-Einstellung), aber das Routing trotzdem funktioniert.
---
## 6. Layer 3 – Routing-Protokolle (Folien 74–92)
### 6.1 Wegewahl im Netz (Folie 75)
Es gibt zwei grundsätzliche Routing-Ansätze:
- **Statisches Routing:** Der Administrator konfiguriert die Wege manuell.
- **Dynamisches Routing:** Router erkunden selbstständig mögliche Wege und wählen den besten aus.
### 6.2 Private und reservierte Adressräume (Folie 76)
**Private Adressbereiche (RFC 1918)** – werden im Internet nicht geroutet:
|Bereich|CIDR|Adressumfang|
|---|---|---|
|10.0.0.0/8|Klasse A|10.0.0.0 bis 10.255.255.255|
|172.16.0.0/12|Klasse B|172.16.0.0 bis 172.31.255.255|
|192.168.0.0/16|Klasse C|192.168.0.0 bis 192.168.255.255|
**Reservierte Adressbereiche (RFC 5735)** – nicht routbar:
|Bereich|RFC|Verwendung|
|---|---|---|
|0.0.0.0/8|RFC 1122|„Dieses Netzwerk"|
|127.0.0.0/8|RFC 1122|Loopback|
|169.254.0.0/16|RFC 3927|Link-Local (APIPA)|
|192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24|RFC 5737|Dokumentation/Beispiele|
|192.18.0.0/15|RFC 2544|Benchmarking|
|224.0.0.0/4|RFC 3171|Multicast|
|240.0.0.0/4|RFC 1112|Reserviert für zukünftige Verwendung|
### 6.3 Anforderungen an Routing-Protokolle (Folien 77–78)
Ein gutes Routing-Protokoll sollte folgende Anforderungen erfüllen:
- **Optimale Wegewahl:** Entscheidung über eine Metrik für den besten Weg.
- **Einfachheit:** Möglichst geringe Anforderungen an Informationsmenge und Prozessorleistung.
- **Robustheit:** Korrekter Umgang mit unerwarteten Situationen und Implementierungsfehlern.
- **Geringer Ressourcenbedarf:** Soll auch auf einfachen Geräten funktionieren, möglichst geringer zusätzlicher Netzwerkverkehr.
- **Schnelligkeit (Konvergenz):** Schnelle Einigung aller Router auf eine optimale Route nach Topologieänderungen.
- **Flexibilität:** Anpassung an unterschiedliche Netzwerkgegebenheiten.
### 6.4 Metrik (Folie 79)
Die **Metrik** ist der Maßstab, nach dem ein Routing-Protokoll den besten Weg auswählt. Mögliche Metrik-Parameter sind:
- Knotenzahl (Hop Count)
- „Kosten" (administrativ definiert)
- Bandbreite
- Verfügbarkeit
- Latenzzeit (Verzögerung)
- Fehlerrate
- Auslastung
Verschiedene Routing-Protokolle verwenden unterschiedliche Kombinationen dieser Parameter.
### 6.5 Eigenschaften von Routing-Protokollen (Folien 80, 82)
**Einweg oder Mehrweg:**
- **Lastverteilung** über mehrere Wege möglich.
- Gleichverteilung oder Nutzung unterschiedlicher Wege.
**Distance Vector oder Link State:**
- **Distance Vector** = wie ein Straßenschild (kennt nur Richtung und Entfernung zum Ziel).
- **Link State** = wie eine Straßenkarte (kennt die gesamte Topologie).
**Interdomain oder Intradomain:**
- **Interior Gateway Protocol (IGP):** Wegewahl _innerhalb_ eines Autonomen Systems (z. B. RIP, OSPF).
- **Exterior Gateway Protocol (EGP):** Wegewahl _zwischen_ autonomen Systemen (z. B. BGP).
**Flach oder hierarchisch:**
- Abbildung der Organisationsstruktur möglich (z. B. OSPF mit Areas).
**Wegewahl am Eingang oder im Router:**
- **Source Routing:** Wegewahl am Eingang des Netzes.
- **Hop-by-Hop:** Jeder Router entscheidet individuell über den nächsten Hop.
### 6.6 Autonome Systeme (Folie 81)
Ein **Autonomes System (AS)** ist eine Ansammlung von Netzwerken unter **einheitlicher administrativer Kontrolle**. AS-Nummern werden von der **IANA (Internet Assigned Numbers Authority)** vergeben. Private AS-Nummern reichen von 64.512 bis 65.534.
Innerhalb eines AS kommen **IGPs** (z. B. RIP, IGRP, OSPF) zum Einsatz. Zwischen autonomen Systemen wird **BGP** als EGP verwendet.
### 6.7 Routing-Protokoll-Beispiele (Folie 83)
|Protokoll|Typ|Bereich|Standard|Metrik|Besonderheiten|
|---|---|---|---|---|---|
|**RIP**|Distance Vector|IGP|RFC|Hop-Count|Classful, langsam|
|**IGRP / EIGRP**|Distance Vector|IGP|Proprietär (Cisco)|Verzögerung, Bandbreite, Verlässlichkeit, Auslastung|Classful, Load Balancing|
|**OSPF**|Link-State|IGP|RFC|Bandbreite (Kosten)|Classless, hierarchisch, Load Balancing, schnell|
|**IS-IS**|Link-State|IGP|ISO|Ähnlich OSPF|Arbeitet auf Schicht 2|
|**BGP**|Path Vector|EGP|RFC|Attribute|Classless, langsam (Konvergenz), WAN|
### 6.8 OSPF – Open Shortest Path First (Folien 84–92)
#### 6.8.1 Grundlagen (Folie 85)
- **OPEN** bedeutet die freie Verfügbarkeit der Spezifikation (IETF RFC 2328).
- **SHORTEST PATH FIRST** bezieht sich auf den **Dijkstra-Algorithmus** zur optimalen Wegefindung.
- OSPF ermöglicht den **automatischen Abgleich von Routing-Tabellen** und beschränkt sich auf bestimmte Gebiete (Areas).
- OSPF ist ein **IGP (Interior Gateway Protocol)**.
- OSPF registriert und informiert über die **Betriebszustände aller Ports/Links** innerhalb eines Gebietes → daher **Link-State-Protokoll**.
#### 6.8.2 SPF-Algorithmus (Folie 86)
- Jeder Router hat eine **identische Link State Database (LSDB)**.
- Metrik = **Pfadkosten**, berechnet aus der Bandbreite: je höher die Bandbreite, desto kleiner die Kosten.
- OSPF nutzt **Multicasts** an 224.0.0.5 (alle OSPF-Router) und 224.0.0.6 (Designated Router).
- Verwendet **IP-Protokoll 89**.
- **Load Balancing** über Pfade mit identischen Kosten (Equal-Cost Multi-Path).
- Router senden **Link State Advertisements (LSA)**, wenn ein Interface gestartet wird.
- Neue LSAs werden auch bei **Topologiewechseln** oder nach Ablauf von **30 Minuten** generiert.
Der SPF-Algorithmus-Ablauf: Link-State Packets → Topological Database → SPF Algorithm → Shortest Path First Tree → Routing Table.
#### 6.8.3 Designated Router (DR) (Folie 87)
- In jedem Multiaccess-Netzwerksegment werden ein **DR (Designated Router)** und ein **BDR (Backup Designated Router)** gewählt.
- Die Wahl basiert auf **Priorität** und **Router-ID** – die höchsten Werte gewinnen (DR und BDR).
- Die **Router-ID** ist die Adresse des Loopback-Interfaces. Die **Priorität** ist standardmäßig 1 und kann konfiguriert werden.
- Alle anderen Router (**DRother**) unterhalten Nachbarschaften **nur mit DR und BDR** – nicht untereinander.
- **Topologie-Änderungen** werden vom DR an die anderen Router im Segment weitergegeben.
#### 6.8.4 OSPF-Nachbarschaften (Folie 88)
Der Aufbau einer OSPF-Nachbarschaft durchläuft folgende Zustände:
1. **Init (Two-Way):** Router entdecken sich über Hello-Pakete. DR und BDR werden gewählt.
2. **Exstart:** Master-Slave-Beziehung wird ausgehandelt. Der Router mit der höheren IP wird Master. Die erste Sequenznummer wird gebildet.
3. **Exchange:** Übertragen der LSDB-Inhalte (Database Description Packets) zwischen den Routern.
4. **Loading:** Senden von Link State Requests (LSR), bis die LSDB-Inhalte auf beiden Seiten identisch sind.
5. **Full:** Alle Informationen sind übertragen – die Nachbarschaft ist vollständig etabliert.
Hello-Pakete werden alle **10–30 Sekunden** ausgetauscht, um die Nachbarschaft aufrechtzuerhalten.
#### 6.8.5 OSPF Areas (Folien 89–90)
OSPF nutzt ein **hierarchisches Design** mit Areas, um die Skalierbarkeit zu verbessern:
- **Areas verbergen Topologien** vor anderen Areas → geringerer Overhead und weniger Belastung durch kleinere LSDBs.
- **Area 0 (Backbone):** Zentrale Area, mit der alle anderen Areas verbunden sein müssen.
- **Internal Router (IR):** Kennt nur die Topologie seiner eigenen Area.
- **Area Border Router (ABR):** Kennt die Topologien aller mit ihm verbundenen Areas und vermittelt zwischen ihnen (Summary Routes).
- **Autonomous System Border Router (ASBR):** Kann Routing-Informationen aus anderen Routing-Protokollen (z. B. RIP, BGP) in das OSPF-AS integrieren (Redistribution).
#### 6.8.6 OSPF Virtual Links (Folie 91)
Virtual Links lösen spezifische Designprobleme:
- Ermöglichen die **Aufsplittung der Area 0 (Backbone)**, wenn diese physisch nicht zusammenhängend ist.
- Area-Backbone-Anbindungen können **indirekt** realisiert werden (z. B. Area 1 über Area 2 an den Backbone anbinden).
- Bieten **Redundanz** für den Backbone.
#### 6.8.7 OSPF LSA-Klassen (Folie 92)
|LSA-Typ|Erzeuger|Inhalt|Reichweite|
|---|---|---|---|
|**Router-LSA**|Alle Router|Zustand der Router-Interfaces in einer Area|Innerhalb der Area (verlässt sie nicht)|
|**Network-LSA**|DR (Designated Router)|Listen der Router im gleichen Netzwerk|Innerhalb der Area (Intra-Area-Routing)|
|**Summary-LSA**|ABR (Area Border Router)|Routen aus der eigenen Area in andere Areas|In alle assoziierten Areas (Inter-Area-Routing)|
---
## Lernhinweise und Prüfungsrelevante Merkregeln
### Subnetting-Merkregeln:
- **Netzwerkadressen** sind immer **gerade** Zahlen.
- **Broadcastadressen** sind immer **ungerade** Zahlen.
- Die **erste nutzbare IP** ist immer **ungerade** (Netzadresse + 1).
- Die **letzte nutzbare IP** ist immer **gerade** (Broadcastadresse − 1).
- Nutzbare Hosts = **2^n − 2** (n = Anzahl der Host-Bits).
- Netzadresse = IP **AND** Subnetzmaske.
- Broadcastadresse = Netzadresse mit allen Host-Bits auf 1.
### Wichtige Protokoll-Zuordnungen:
- **ARP:** Layer 2/3 – löst IP → MAC auf (Request = Broadcast, Reply = Unicast).
- **ICMP:** Layer 3 – Fehlermeldungen und Diagnose (ping, traceroute).
- **OSPF:** Layer 3 – Link-State IGP, Dijkstra-Algorithmus, IP-Protokoll 89.
- **BGP:** Layer 3 – Path-Vector EGP, zwischen autonomen Systemen.
### IEEE-Standards:
- **802.1q:** VLAN-Tagging (4 Byte Tag, 12-Bit VLAN-ID, max. 4095 VLANs).
- **802.1p:** QoS-Priorisierung auf Layer 2 (3-Bit PCP, 8 Prioritätsstufen).

794
Netzwerke/zusammenfassungen/nw4 - zusammenfassung.md Normal file
View file

@ -0,0 +1,794 @@
# IT2221 – Netzwerktechnik: Vorlesung 4
**Dozentin:** Gabriele Schrenk | **Datum:** 13.03.2026 | **Hochschule:** HWR Berlin (EANTC)
---
## Inhaltsübersicht
1. [OSPF Areas & Route Summarization](#1-ospf-areas--route-summarization)
2. [Zusammenfassen von Routen (IPv4)](#2-zusammenfassen-von-routen-ipv4)
3. [IPv6 – Grundlagen & Motivation](#3-ipv6--grundlagen--motivation)
4. [IPv6-Header](#4-ipv6-header)
5. [IPv6-Adressierung](#5-ipv6-adressierung)
6. [IPv6-Adresstypen](#6-ipv6-adresstypen)
7. [ICMPv6 & Neighbor Discovery](#7-icmpv6--neighbor-discovery)
8. [Migration von IPv4 zu IPv6](#8-migration-von-ipv4-zu-ipv6)
9. [Layer 7 – DHCP](#9-layer-7--dhcp)
10. [Weitverkehrsnetze (WAN)](#10-weitverkehrsnetze-wan)
11. [PPPoE & DSL](#11-pppoe--dsl)
---
## 1. OSPF Areas & Route Summarization
### OSPF Areas
OSPF (Open Shortest Path First) nutzt **Areas**, um große Netzwerke hierarchisch zu strukturieren.
- **Areas verbergen Topologien** vor anderen Areas → reduziert Overhead
- **Kleinere LSDBs** (Link-State Databases) → weniger Belastung auf den Routern
- Jede Area hat eine eigene Topologie-Datenbank; nur zusammengefasste Routen werden über Area-Grenzen hinweg ausgetauscht
**Wichtige Router-Rollen:**
|Router-Typ|Abkürzung|Funktion|
|---|---|---|
|Area Border Router|**ABR**|Vermittelt zwischen verschiedenen OSPF Areas. Gehört zu mindestens zwei Areas (eine davon ist immer Area 0 / Backbone).|
|Autonomous System Border Router|**ASBR**|Empfängt Routing-Informationen aus **anderen Routing-Protokollen** (z. B. BGP, RIP) und leitet sie ins OSPF-Netz ein.|
Die **Backbone Area** (Area 0, 0.0.0.0) ist das Zentrum: Alle anderen Areas müssen direkt oder über virtuelle Links mit ihr verbunden sein.
### ABR/ASBR Route Summarization
ABR und ASBR können Netzwerkadressen und deren Kosten **zusammenfassen** (Route Summarization / Route Aggregation).
**Vorteile der Zusammenfassung:**
- Möglichst **wenige Routen** in der Routing-Tabelle
- **Spart Ressourcen** (CPU, RAM) auf Routern ein
- **Schnellere Konvergenz** – Änderungen in einem Subnetz führen nicht zu Updates in der gesamten Routing-Tabelle
- **Verbergen von Netzdetails** – interne Topologie bleibt hinter der Zusammenfassung versteckt
- **Unempfindlichkeit** gegen Zustandsänderungen einzelner Routen
**Zwei Arten der Zusammenfassung:**
1. **Inter-area route summarization** – Zusammenlegen von Netzwerkadressen, die innerhalb eines Autonomous Systems (AS) liegen. Wird auf ABRs konfiguriert.
2. **External route summarization** – Netzwerkadressen, die von außen in ein AS integriert wurden (z. B. über Redistribution), werden zusammengelegt. Wird auf ASBRs konfiguriert.
---
## 2. Zusammenfassen von Routen (IPv4)
### Algorithmus
1. **Netze in Binärdarstellung umwandeln**
2. **Anzahl der identischen Bits** (von links nach rechts) bestimmen → das wird die neue Präfixlänge
3. **Prüfen**, ob nur die gewünschten Netze in der Zusammenfassung enthalten sind
4. Falls ungewünschte Netze mit eingeschlossen würden → **weitere Bits hinzufügen**, bis nur die gewünschten Netze abgedeckt sind
5. **Restliche Netze** separat behandeln und den Prozess von vorne beginnen
> **Wichtig:** Die zusammengefassten Netze müssen logisch zum **gleichen Next Hop / gleichen Interface** führen!
### Beispiel 1: Einfache Zusammenfassung
Gegeben: 172.16.0.0/24 bis 172.16.3.0/24
```
172.16.0.0: 1010 1100.0001 0000.0000 00|00.0000 0000
172.16.1.0: 1010 1100.0001 0000.0000 00|01.0000 0000
172.16.2.0: 1010 1100.0001 0000.0000 00|10.0000 0000
172.16.3.0: 1010 1100.0001 0000.0000 00|11.0000 0000
↑
Erste 22 Bits identisch
```
**Ergebnis:** `172.16.0.0/22` – Die ersten 22 Bits sind bei allen vier Netzen gleich, die letzten 2 Bits im dritten Oktett variieren (00, 01, 10, 11 = genau 4 Netze).
### Beispiel 2: Nicht-triviale Zusammenfassung
Gegeben: 192.168.0.0/24 bis 192.168.9.0/24
Hier ist eine **einzelne Zusammenfassung nicht möglich**, ohne ungewünschte Netze (192.168.10.0 bis 192.168.15.0) einzuschließen.
```
192.168.0.0: ...0000 0|000.0000 0000 ─┐
... ├─ Erste 21 Bits identisch
192.168.7.0: ...0000 0|111.0000 0000 ─┘
→ Zusammenfassung: 192.168.0.0/21
192.168.8.0: ...0000 100|0.0000 0000 ─┐
192.168.9.0: ...0000 100|1.0000 0000 ─┘ Erste 23 Bits identisch
→ Zusammenfassung: 192.168.8.0/23
```
**Ergebnis:** Zwei Zusammenfassungen nötig:
- `192.168.0.0/21` (deckt .0 bis .7 ab)
- `192.168.8.0/23` (deckt .8 und .9 ab)
### Beispielaufgabe aus der Vorlesung
**Gegeben:**
- 192.168.160.0/24
- 192.168.161.0/24
- 192.168.162.0/23
- 192.168.164.0/22
**Lösung:**
```
192.168.160.0: ...1010 0|000.0000 0000
192.168.161.0: ...1010 0|001.0000 0000
192.168.162.0: ...1010 0|010.0000 0000
192.168.164.0: ...1010 0|100.0000 0000
```
Alle Netze liegen im Bereich 160–167 (drittes Oktett Bits: 1010 0xxx). Die ersten 21 Bits sind identisch.
**Ergebnis:** `192.168.160.0/21`
### Gruppenaufgabe
**Gegeben:**
- 172.30.31.0/24
- 172.30.32.0/24
- 172.30.33.0/24
- 172.30.34.0/23
- 172.30.36.0/23
- 172.30.38.0/24
**Lösung (Schritt für Schritt):**
172.30.31.0 hat das dritte Oktett `0001 1111` – das passt nicht in eine Gruppe mit den anderen (die alle `0010 xxxx` haben), weil eine Zusammenfassung zu viele ungewünschte Netze einschließen würde.
```
172.30.31.0: ...0001 1111.0000 0000 → Einzeln: 172.30.31.0/24
172.30.32.0: ...0010 00|00.0000 0000 ─┐
172.30.33.0: ...0010 00|01.0000 0000 ├─ 22 Bits identisch
172.30.34.0: ...0010 00|10.0000 0000 ─┘
→ Zusammenfassung: 172.30.32.0/22
172.30.36.0: ...0010 01|00.0000 0000 → 172.30.36.0/23
172.30.38.0: ...0010 01|10.0000 0000 → 172.30.38.0/24
```
**Ergebnis:** 4 Zusammenfassungen:
- `172.30.31.0/24`
- `172.30.32.0/22`
- `172.30.36.0/23`
- `172.30.38.0/24`
### Hilfstabelle: Bit-Wertigkeiten im Oktett
|2⁷|2⁶|2⁵|2⁴|2³|2²|2¹|2⁰|
|---|---|---|---|---|---|---|---|
|128|64|32|16|8|4|2|1|
---
## 3. IPv6 – Grundlagen & Motivation
### Warum IPv6?
- **IPv4-Adressraum zu klein:** 2³² = ca. 4,3 Milliarden Adressen – bei über 8 Milliarden Menschen und einem Vielfachen an Geräten nicht ausreichend
- **IPv4-Adressen ungleich verteilt** auf der Welt (historisch bedingte Vergabe)
- **IPv6-Adressraum:** 2¹²⁸ = ca. 3,4 × 10³⁸ Adressen – praktisch unerschöpflich
### Merkmale von IPv6
- Spezifiziert im **Dezember 1995** von der IETF in **RFC 1883** (aktuell RFC 8200)
- Weiterentwicklung von IPv4 mit folgenden Verbesserungen:
- **Vereinfachtes Protokollformat** (keine Header-Checksumme mehr)
- **Dienstgüte (QoS)** – Flow Label im Header
- **Sicherheitsmechanismen** – IPSec war ursprünglich verpflichtend
- **Erweitertes Routing** – Extension Headers statt fester Felder
- **Koexistenz:** IPv6 existiert parallel mit IPv4 (Dual Stack)
- **128-Bit-Adressen** ermöglichen:
- Größeren Adressraum
- Bildung mehrerer Hierarchiestufen
- Verschiedene Adresstypen (Unicast, Multicast, Anycast)
- Neue Diensteadressierung
- **DNS bleibt gültig** (AAAA-Records für IPv6)
- **Autokonfiguration** der Endgeräte (SLAAC)
### Eigenschaften des IPv6-Headers
- **Stark vereinfachter Protokollkopf** – keine Checksumme mehr (Prüfung wird von Layer 2 und 4 übernommen)
- Enthält nur **grundlegende Informationen** zur Weiterleitung
- **Feste Headerlänge von 40 Byte** (nicht 48 wie auf der Folie angegeben – die 48 Byte schließen möglicherweise Padding ein) ermöglicht schnelles Routing
- Trotz **vierfacher Adresslänge** (16 Byte statt 4 Byte) nur **doppelte Headerlänge** gegenüber IPv4 (20 Byte)
- **Verschlüsselung** möglich (IPSec)
- **Quality of Service** über Traffic Class und Flow Label
- **Aktuell (2024):** ca. 30–60% der Netze weltweit auf IPv6 migriert
---
## 4. IPv6-Header
### Aufbau des Basis-Headers (40 Byte fest)
```
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Address (128 Bit) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address (128 Bit) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
|Feld|Bits|Beschreibung|
|---|---|---|
|**Version**|4|Immer `6` für IPv6|
|**Traffic Class**|8|Enthält DSCP (Differentiated Services Code Point) und ECN (Explicit Congestion Notification) für QoS|
|**Flow Label**|20|Identifiziert einen Datenfluss (z. B. eine TCP-Verbindung oder einen Stream). Ermöglicht Routing-Entscheidungen nur anhand des Flow Labels.|
|**Payload Length**|16|Länge des Rests des Pakets **nach dem Header** in Byte|
|**Next Header**|8|Gibt an, welches Protokoll bzw. welcher Extension Header als nächstes folgt (z. B. 6 = TCP, 17 = UDP, 43 = Routing Header)|
|**Hop Limit**|8|Entspricht der TTL aus IPv4 – wird bei jedem Router um 1 heruntergezählt, Paket wird bei Wert 0 verworfen|
|**Source Address**|128|Quelladresse|
|**Destination Address**|128|Zieladresse|
### Extension Headers (Erweiterungsköpfe)
IPv6 verwendet eine **verkettete Liste von Headern** statt fester Felder. Jeder Extension Header enthält ein „Next Header"-Feld, das auf den nächsten Header zeigt.
|Extension Header|Next Header Wert|Beschreibung|
|---|---|---|
|Hop-by-Hop Options|0|Optionen, die von **jedem** Gerät auf dem Pfad geprüft werden|
|Routing|43|Routenvorgabe (z. B. SRv6 Segment Routing Header, Typ 4)|
|Fragment|44|Parameter für Fragmentierung (nur beim Sender, nicht auf dem Pfad!)|
|Authentication Header (AH)|51|Authentizität und Integrität des Pakets|
|ESP (Encapsulating Security Payload)|50|Verschlüsselte Datenübertragung|
|Destination Options|60|Optionen, die nur vom **Ziel** geprüft werden|
|Mobility|135|Mobile IPv6|
|Host Identity Protocol|139|HIPv2|
|Shim6 Protocol|140|Multihoming|
**Beispiel der Verkettung:**
- IPv6 Header (Next Header = 43) → Routing Header (Next Header = 60) → Destination Options (Next Header = 6) → TCP Header → Payload
### IPv6 im Ethernet-Frame
- **IPv6** nutzt den Ethernet Protocol ID (EtherType): **0x86DD**
- **IPv4** nutzt den Ethernet Protocol ID (EtherType): **0x0800**
```
| Dest MAC | Source MAC | 0x86DD | IPv6 Header and Payload |
| Dest MAC | Source MAC | 0x0800 | IPv4 Header and Payload |
```
---
## 5. IPv6-Adressierung
### Darstellungsregeln
IPv6-Adressen sind **128 Bit** lang und werden in **hexadezimaler Notation** dargestellt:
- **8 Blöcke** à 4 Hex-Zeichen (= 16 Bit pro Block)
- Blöcke getrennt durch **Doppelpunkt** `:`
- **Führende Nullen** innerhalb eines Blocks dürfen weggelassen werden
- **Aufeinanderfolgende Nullblöcke** können durch `::` zusammengefasst werden (**maximal 1× pro Adresse!**)
**Beispiel:**
```
Vollständig: 2001:0000:0001:0002:0000:0000:0000:ABCD
Gekürzt: 2001:0:1:2:0:0:0:ABCD
Maximal: 2001:0:1:2::ABCD (3 Nullblöcke durch :: ersetzt)
```
### Adressstruktur
Eine IPv6-Adresse besteht aus zwei Hälften:
```
|←────────── 64 Bit ──────────→|←────────── 64 Bit ──────────→|
| Netz-Präfix | Interface ID |
```
### IPv6 Subnetting
- Funktioniert wie bei IPv4, nur mit 128 Bit Adresslänge und Hex-Schreibweise
- CIDR-Notation wird verwendet: z. B. `2001:0db8:85a3::/64`
- Subnetting bleibt auch bei IPv6 relevant
### Routenzusammenfassung bei IPv6
**Beispiel:** Zusammenfassung von drei /64-Netzen:
```
2001:0db8:85a3:0001::/64 → ...0000 0000 0001 (Hex: 0001)
2001:0db8:85a3:0002::/64 → ...0000 0000 0010 (Hex: 0002)
2001:0db8:85a3:0003::/64 → ...0000 0000 0011 (Hex: 0003)
```
Die ersten **62 Bits** sind identisch (die letzten 2 Bits des 4. Blocks variieren: 01, 10, 11).
**Ergebnis:** `2001:0db8:85a3:0000::/62`
**Vorteile:**
- Effizientere Nutzung des Adressraums
- Weniger Routing-Tabellen-Einträge
- Bessere Routing-Effizienz
- Vereinfachtes Netzwerkmanagement
### Adressierungsschema
- IPv6-Adresse mit allen Bits auf 1: `FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF`
- IPv4-Adresse mit allen Bits auf 1: `255.255.255.255` = `FFFF:FFFF` (nur 32 Bit)
---
## 6. IPv6-Adresstypen
### Spezielle Adressen
|Adresse|Beschreibung|
|---|---|
|`::1` (= 0:0:0:0:0:0:0:1)|**Loopback** – Entspricht 127.0.0.1 bei IPv4|
|`::` (= 0:0:0:0:0:0:0:0)|**Unspecified** – Wird vor der Adresszuweisung verwendet, darf nicht als Zieladresse genutzt werden|
|`::/0`|**Default Route** – Entspricht 0.0.0.0/0 bei IPv4|
### Interface Identifiers (EUI-64)
Der Host-Teil einer IPv6-Adresse (die letzten 64 Bit) kann automatisch aus der **MAC-Adresse** generiert werden:
1. MAC-Adresse (48 Bit) wird in **zwei 3-Byte-Blöcke** geteilt
2. Zwischen beiden Blöcken wird **FFFE** eingeschoben (→ 64 Bit)
3. Das **Universal/Local Bit** (2. Bit des ersten Bytes) wird invertiert
**Beispiel:**
```
MAC: 00:90:27:17:FC:0F
Teilen: 00:90:27 | 17:FC:0F
FFFE: 00:90:27:FF:FE:17:FC:0F
U/L-Bit: 02:90:27:FF:FE:17:FC:0F (Bit 2 von 00 → 02)
```
**Privacy Extension:** Zufällig generierte Interface IDs statt EUI-64 zum Schutz der Privatsphäre (verhindert Tracking über die MAC-Adresse).
### Unicast-Adresstypen
#### Global Aggregatable Unicast Adressen (2000::/3)
Für die **weltweite Kommunikation** im Internet. Über verschiedene Netzwerke hinweg routbar.
```
|←── 48 Bit ──→|←16 Bit→|←────────── 64 Bit ──────────→|
| Global Prefix | Subnet | Interface ID |
| (vom ISP) | ID | |
```
- **Global Prefix** (48 Bit): Von der IANA → RIR → ISP zugewiesen
- **Subnet ID** (16 Bit): Vom Netzwerkadministrator vergeben → bis zu 65.536 Subnetze
- **Interface ID** (64 Bit): Identifiziert das Interface (EUI-64 oder zufällig)
#### Link-Local Unicast Adressen (FE80::/10)
Für die **lokale Kommunikation** innerhalb eines Netzwerksegments.
```
|←────────── 64 Bit ──────────→|←────────── 64 Bit ──────────→|
| FE80:0000:0000:0000 | Interface ID |
```
- Prefix ist immer **FE80::/64**
- Werden **nicht geroutet** – bleiben im lokalen Netz
- Werden für die **Autokonfiguration** und das Neighbor Discovery Protocol verwendet
- Jedes IPv6-fähige Interface hat automatisch eine Link-Local-Adresse
#### Vergleichstabelle
|Merkmal|Global Aggregatable Unicast|Link-Local Unicast|
|---|---|---|
|**Präfix**|2000::/3|fe80::/10|
|**Verwendung**|Kommunikation im Internet|Kommunikation im LAN|
|**Routing**|Ja, weltweit routbar|Nein, nicht routbar|
|**Zuweisung**|Von ISPs zugewiesen|Automatisch, lokal|
|**Beispiel**|2001:0db8:85a3::8a2e:0370:7334|fe80::1a2b:3c4d:5e6f|
IPv6-Adressen werden von der **IANA** (Internet Assigned Numbers Authority) oder regionalen Stellen (RIPE NCC für Europa) zugewiesen.
### Anycast Adressen
- Syntaktisch eine **globale Unicast-Adresse**, die aber **mehrfach vergeben** wird
- Router leitet Verkehr zur **nächstgelegenen Instanz** (nach Routing-Metrik)
- Anwendung: z. B. DNS-Root-Server, CDN-Knoten
### Multicast Adressen (FF00::/8)
Ersetzt IPv4-Broadcast (den es in IPv6 **nicht mehr gibt**).
```
|←8 Bit→|←4 Bit→|←4 Bit→|←────── 112 Bit ──────→|
| FF | Flags | Scope | Group ID |
```
**Flags:**
- R = 0/1: Kein/Eingebetteter Rendezvous Point
- P = 0/1: Nicht/Basierend auf Unicast-Präfix
- T = 0/1: Permanent (IANA-zugewiesen) / Temporär (lokal zugewiesen)
**Scope:**
|Wert|Scope|
|---|---|
|1|Node|
|2|Link|
|3|Subnet|
|4|Admin|
|5|Site|
|8|Organization|
|E|Global|
### Nicht mehr gebräuchliche Adresstypen
- **IPv4-kompatible IPv6-Adresse** (`0:::/96`) – veraltet
- **Site-local Adressen** (`FC00::/7`) – durch Unique Local Addresses (ULA) ersetzt
---
## 7. ICMPv6 & Neighbor Discovery
### ICMPv4 vs. ICMPv6
ICMPv6 (RFC 4443) übernimmt deutlich **mehr Aufgaben** als ICMPv4 (RFC 792):
|Funktion|ICMPv4|ICMPv6|
|---|---|---|
|Connectivity Checks (Ping)|✓|✓|
|Informational/Error Messaging|✓|✓|
|Fragmentation Needed Notification|✓|✓|
|Address Assignment (SLAAC)|✗|✓|
|Address Resolution (ersetzt ARP)|✗|✓|
|Router Discovery|✗|✓|
|Multicast Group Management|✗|✓|
|Mobile IPv6 Support|✗|✓|
### Neighbor Discovery Protocol (NDP) – Neue ICMPv6-Nachrichten
|Nachricht|ICMP Code|Sender|Ziel|Zweck|
|---|---|---|---|---|
|**Router Solicitation (RS)**|133|Nodes|Alle Router (ff02::2)|Router auffordern, ein RA zu senden|
|**Router Advertisement (RA)**|134|Router|Sender des RS oder alle Hosts (ff02::1)|Default Router, Präfixe, Konfigurationsparameter bekanntgeben|
|**Neighbor Solicitation (NS)**|135|Node|Solicited Node Multicast / Target Node|Link-Layer-Adresse des Ziels erfragen (= ARP-Ersatz)|
|**Neighbor Advertisement (NA)**|136|Node|Anfragender Node|Antwort auf NS mit eigener Link-Layer-Adresse|
|**Redirect**|137|Router|–|Host über besseren First Hop informieren|
### Automatische Adressvergabe (SLAAC)
**Stateless Address Autoconfiguration** – Hosts konfigurieren sich selbst ohne DHCP-Server.
**Router Discovery Prozess:**
1. **Host sendet RS** (Router Solicitation, Typ 133) an Multicast-Adresse `ff02::2` (alle Router)
2. **Router antwortet mit RA** (Router Advertisement, Typ 134) an `ff02::1` (alle Hosts) mit:
- Netzwerkpräfix (z. B. `2001:0db8:abcd::/64`)
- Präfix-Lebensdauer (z. B. 3600 Sekunden)
- Flags für DHCPv6-Nutzung
- Informationen ob SLAAC oder DHCPv6 verwendet werden soll
3. **Host generiert seine Adresse** aus Netzwerkpräfix + Interface ID (EUI-64 oder zufällig)
**Flags im Router Advertisement:**
- **A-Flag** (Autonomous): ON = Host darf SLAAC verwenden
- **M-Flag** (Managed): OFF = Kein DHCPv6 für Adressen nötig
Router senden regelmäßig RA-Nachrichten; Hosts können jederzeit RS senden, um aktuelle Informationen zu erhalten.
### Duplicate Address Detection (DAD)
Bevor ein Host seine neu generierte Adresse verwendet, prüft er per **DAD** (RFC 4862), ob die Adresse bereits im Netz existiert:
1. Host empfängt RA mit Präfix
2. Host generiert vorläufige Adresse (Präfix + Interface ID)
3. Host sendet **NS** an die Solicited-Node-Multicast-Adresse der vorläufigen Adresse
4. Wenn **keine Antwort** kommt → Adresse ist eindeutig → wird übernommen
5. Wenn **NA** empfangen wird → Adresse ist bereits vergeben → neue Interface ID generieren
### ARP-Ersatz in IPv6
IPv6 hat **kein ARP** mehr. Stattdessen wird **Neighbor Solicitation / Neighbor Advertisement** verwendet:
1. **Host A** will die MAC-Adresse von **Host B** wissen
2. Host A sendet **NS** (Typ 135) an die Solicited-Node-Multicast-Adresse von Host B
- Enthält: eigene Link-Local-Adresse, Frage nach Host Bs Link-Layer-Adresse
3. **Host B** antwortet mit **NA** (Typ 136) per Unicast an Host A
- Enthält: eigene Link-Local-Adresse und MAC-Adresse
---
## 8. Migration von IPv4 zu IPv6
### Dual Stack
- Server, Router und Hosts betreiben **unabhängige Stacks** für IPv4 und IPv6
- Falls die Gegenseite IPv6 unterstützt → Kommunikation über IPv6
- Anwendungen müssen IPv6 unterstützen
- **Bevorzugte Methode** – natives IPv6
### Tunneling-Verfahren
Verbindung von **IPv6-Inseln** über ein IPv4-Transportnetz.
|Verfahren|Beschreibung|Status|
|---|---|---|
|**Manueller Tunnel (6in4)**|IPv6-Pakete werden in IPv4-Pakete gekapselt. Manuell konfiguriert.|Empfohlen wenn Tunnel nötig|
|**6-to-4**|IPv6-Prefix `2002::/16` + IPv4-Adresse des Edge-Routers. Automatisch.|Übergangslösung|
|**6rd**|Weiterentwicklung von 6-to-4, kontrolliert vom ISP. Teile der Kunden-IPv4-Adresse werden in den IPv6-Präfix eingebaut.|Übergangslösung, Ziel: natives IPv6|
|**Teredo**|IPv6-Pakete werden in IPv4-UDP-Pakete verpackt. Funktioniert auch hinter NAT.|Wird abgelöst|
|**ISATAP**|Intra-Site Automatic Tunnel Addressing Protocol|Veraltet|
**Empfehlung:** Besser natives IPv6 (Dual Stack). Wenn Tunnel nötig, dann manuell mit 6in4 oder 6rd.
---
## 9. Layer 7 – DHCP
### DHCP (IPv4) – Dynamic Host Configuration Protocol
Automatische Vergabe von IP-Adressen und Netzwerkparametern.
#### DORA-Prozess (Discover → Offer → Request → Acknowledge)
|Schritt|Nachricht|Richtung|Typ|Beschreibung|
|---|---|---|---|---|
|1|**DHCP Discover**|Client → Broadcast|0.0.0.0 → 255.255.255.255|Client sucht DHCP-Server. Enthält MAC-Adresse des Clients.|
|2|**DHCP Offer**|Server → Broadcast|Server → 255.255.255.255|Server bietet eine IP-Adresse an.|
|3|**DHCP Request**|Client → Broadcast|0.0.0.0 → 255.255.255.255|Client akzeptiert das Angebot. Enthält Server Identifier in den DHCP-Optionen.|
|4|**DHCP ACK**|Server → Unicast||Server bestätigt die zugewiesene IP-Adresse.|
#### Fehlersituationen
|Nachricht|Beschreibung|
|---|---|
|**DHCP-Decline**|Client macht ARP-Request für angebotene Adresse → wird beantwortet → Adresse bereits in Benutzung → Client lehnt ab|
|**DHCP-NACK**|Server hat die angefragte IP bereits vergeben, angefragte Optionen nicht verfügbar, oder Server nicht für die Adresse zuständig|
|**DHCP-Release**|Client benötigt die IP-Adresse nicht mehr (z. B. `ipconfig /release` unter Windows)|
|**DHCP-Inform**|Client hat bereits eine IP, fragt aber zusätzliche Parameter ab|
#### DHCP Lease-Erneuerung
|Zeitpunkt|Verhalten|
|---|---|
|**Nach 50% der Leasezeit**|Client sendet **DHCP Request per Unicast** an den bekannten Server. Server antwortet mit DHCP ACK (= neue Lease) oder antwortet nicht (Lease kann bis zum Ende genutzt werden).|
|**Nach 7/8 der Leasezeit**|Client sendet **DHCP Request per Broadcast** an alle Server. Verhalten wie bei 50%.|
|**Nach Ablauf der Leasezeit**|IP-Adresse wird freigegeben. Client sendet erneut **DHCP Discover**.|
#### DHCP-Optionen (mögliche Parameter)
- IP-Adresse, Netzmaske, Default-Gateway
- Name-Server (DNS), Time-Server
- WINS, Proxy-Server
- Bootimages, Bootserver
- u. v. m.
#### DHCP Relay
- DHCP arbeitet über **Broadcast** → funktioniert nur im lokalen Subnetz
- Ohne Relay bräuchte man **pro Subnetz einen DHCP-Server**
- Ein **Router als DHCP Relay Agent** kann DHCP-Pakete in andere Subnetze weiterleiten
- DHCP-Pakete bekommen zusätzliche Optionen:
- **DHCP Relay-Agent** Information
- **Option 82** (Switchport-Information)
**Ablauf mit Relay:**
```
Client (Port 68) ──→ Relay (Port 67 & 68) ──→ Server (Port 67)
DHCP Discover → DHCP Discover →
← DHCP Offer ← DHCP Offer
DHCP Request → DHCP Request →
← DHCP Acknowledge ← DHCP Acknowledge
```
---
## 10. Weitverkehrsnetze (WAN)
### Überblick
- **WANs verbinden LANs** über große Entfernungen
- Die Bereitstellung hängt von den **Benutzeranforderungen** ab
- WANs werden auf den **drei unteren OSI-Schichten** (Layer 1–3) betrieben
### WAN-Übergangspunkt (Kunde ↔ Service Provider)
|Komponente|Beschreibung|
|---|---|
|**CPE** (Customer Premises Equipment)|Geräte beim Kunden (Router, Modem)|
|**Hausanschluss**|Physische Verbindung ins Gebäude|
|**Teilnehmeranschluss**|Letzte Meile zum Provider|
|**Netzabschluss SP**|Übergabepunkt zum Provider-Netz|
|**Trunk-Leitungen und Switches**|Backbone des Providers|
### WAN-Verbindungsarten
```
WAN
/ \
Dediziert Switching
| / \
Mietleitungen Leitungs- Paketvermittelt
(Synchron E1, vermittelt
über Ethernet) (ISDN/DSL) (Ethernet, IP)
```
### Layer-1-Zugangstechnologien
**Heutige Technologien (IP-basiert, paketvermittelt):**
- Glasfaseranschlüsse (FTTH, FTTB)
- Kupferkabel (ehemaliges Telefonnetz, aktuell DSL)
- Kabel-Internet über DOCSIS (Coaxialkabel, ursprünglich für TV)
- Satelliten
- LTE/5G Mobilfunk
**Frühere Technologien:**
- Plesiochrone Digitale Hierarchie (PDH)
- Synchrone Digitale Hierarchie (SDH)
- Frame Relay
- Asynchronous Transfer Mode (ATM)
### WAN-Protokolle (Paketvermittelt)
|Protokoll|Beschreibung|
|---|---|
|**MPLS** (Multiprotocol Label Switching)|Label-basiertes Forwarding für Unternehmen und SPs. Ermöglicht effiziente Datenübertragung und QoS.|
|**Segment Routing** (SR-MPLS und SRv6)|Vereinfachte Netzwerkverwaltung – intermediate Router brauchen keine Pfadinfos. Ingress Router legt den Weg als Liste von Segmenten fest (im IPv6 als Routing Extension Header / SRH, bei MPLS als Label Stack). Form von Source Routing.|
|**Carrier Ethernet**|Ethernet-Protokolle für Hochgeschwindigkeitsverbindungen zwischen Standorten. Von Carriern/SPs bereitgestellt.|
|**SD-WAN**|Software-Defined WAN – dynamische Verwaltung von Netzwerkverbindungen über verschiedene Transportmittel (MPLS, LTE, Internet).|
|**PPPoE**|Point-to-Point Protocol over Ethernet – nutzt DSL als Zugangstechnologie zum WAN des SPs.|
---
## 11. PPPoE & DSL
### PPPoE (Point-to-Point Protocol over Ethernet)
PPPoE ermöglicht die Übertragung unterschiedlicher Protokolle (z. B. IP) über eine Leitung (Modem/xDSL). Es ist standardisiert in **RFC 2516** und bietet:
- Kontrollierten Verbindungsaufbau über **LCP** (Link Control Protocol)
- **Authentifizierung** (für Abrechnung beim Provider)
- **Autokonfiguration**
### PPPoE-Verbindungsphasen
```
┌─────────────────────────────────────────────────┐
│ │
▼ │
┌──────┐ Physik. Verbindung ┌──────┐ │
│ Down │ ───────────────────→ │ Auth │ │
└──────┘ └──┬───┘ │
▲ │ │
│ Anmeldung gescheitert │ Anmeldung │
│ │ erfolgreich │
│ ▼ │
│ ┌──────────┐ │
│ │ Network │ │
│ │ Config │ │
│ └────┬─────┘ │
│ │ Austausch │
│ │ erfolgreich │
│ ▼ │
│ Abbauwunsch/Fehler ┌─────────────┐ │
└────────────────────── │ Operational │ ─────────┘
└─────────────┘
```
### Phase 1: Discovery & Verbindungsaufbau
1. **PADI** (PPPoE Active Discovery Initiation) – Client sendet Broadcast, sucht PPPoE-Server
2. **PADO** (PPPoE Active Discovery Offer) – Server antwortet mit Angebot und Infos über sich
3. **PADR** (PPPoE Active Discovery Request) – Client wählt einen Server und sendet Anfrage
4. **PADS** (PPPoE Active Discovery Session Confirm) – Server bestätigt und weist **Session-ID** zu
### Phase 2: Authentifizierung
Nach erfolgreichem Verbindungsaufbau wird ein PPPoE-Sitzungstunnel aufgebaut. Alle Daten werden in PPP-Pakete eingekapselt.
**PAP (Password Authentication Protocol):**
- **Einfaches, unverschlüsseltes** Verfahren (unsicher!)
- **2-Way Handshake:** Client sendet LoginID + Passwort → Server akzeptiert oder verwirft
- Passwort wird **im Klartext** übertragen
- **Nicht mehr verwendet** für Anschlüsse zum SP
**CHAP (Challenge Handshake Authentication Protocol):**
- **Verschlüsseltes**, sichereres Verfahren
- **3-Way Handshake:**
1. Server sendet eine **zufällige Challenge** an den Client
2. Client kombiniert Challenge mit seinem Passwort und sendet einen **Hash-Wert** zurück (SHA-1, SHA-256 oder SHA-384)
3. Server führt **dieselbe Berechnung** durch und vergleicht die Ergebnisse
- **Keine Übertragung von Passwörtern** über die Leitung
- Authentifizierung durch lokalen Router oder externen Authentifizierungsserver
### Phase 3: Netzkonfiguration
Nach erfolgreicher Authentifizierung werden Netzwerkparameter ausgetauscht:
- IP-Adresse, Subnetzmaske, Standard-Gateway
- DNS-Server-Adressen
- MTU (Maximum Transmission Unit für Ethernet)
- Session-ID
- QoS-Parameter
### Phase 4: Operational (Betrieb)
- **Session Timer / Idle Timer** zur Verwaltung der Sitzung
- **Keepalive-Nachrichten** – bei Ausbleiben wird Session ungültig markiert
- **Timeouts** – Session-ID wird nach Timer-Ablauf für ungültig erklärt (Ressourcen freigeben)
- **Fehlerüberprüfung** – Server kann erneute Authentifizierung anfordern
### DSL (Digital Subscriber Line)
Bereitstellung von Internet über **herkömmliche Telefonleitungen** (Kupfer).
**Aufbau:**
```
Kunde/Teilnehmer │ Vermittlungsstelle
│
Telefon ─── NTBA ──┐ │ ┌── Digitale Vermittlung ── Telefonnetz
├─ TAL ┤ │
PC ─── DSL-Router ──┘ │ ├── DSLAM ── BRAS ── Internet
│ │
Splitter│ Splitter
```
- **TAL** = Teilnehmeranschlussleitung (letzte Meile, Kupfer)
- **DSLAM** = Digital Subscriber Line Access Multiplexer – sammelt und aggregiert Daten der Teilnehmer
- **BRAS/BNG** = Broadband Remote Access Server / Broadband Network Gateway – terminiert PPPoE
### DSL-Varianten
|Variante|Typ|Max. Datenrate|Besonderheit|
|---|---|---|---|
|**ADSL**|Asymmetrisch|Bis 8 Mbit/s|Download > Upload|
|**ADSL2+**|Asymmetrisch|Bis 24 Mbit/s|Zusätzliche Frequenzbänder|
|**SDSL**|Symmetrisch|2,36 Mbit/s|Upload = Download|
|**VDSL**|Asymmetrisch|Bis 100 Mbit/s|Optimiert für kurze Entfernungen|
|**VDSL2-Vectoring**|Hybrid|Bis 250 Mbit/s|Kupfer letzte Meile + Glasfaser zum ISP. Crosstalk-Kompensation.|
Höhere Raten als VDSL2-Vectoring sind nur über **FTTH** (Fiber to the Home) oder **Kabelinternet** (DOCSIS) möglich.
### Abschaltung von DSL in Deutschland
- **Ziel:** Glasfaserausbau komplett bis **2030**
- DSL-Abschaltung bei einzelnen Service Providern kann **ab 2026** beginnen
- **Bundesnetzagentur** reguliert den Telekommunikationsmarkt
- Stand Juni 2025: **42,9%** aller Haushalte verfügen über einen Glasfaseranschluss (FTTB/FTTH)
- **Gigabitversorgung** (1000 Mbit/s) über alle Technologien hinweg: **knapp 79%**
---
## Zusammenfassung der Kernthemen
|Thema|Kernaussage|
|---|---|
|**OSPF Areas**|Hierarchische Strukturierung reduziert Routing-Overhead. ABR/ASBR fassen Routen zusammen.|
|**Route Summarization**|Binärvergleich der Netzadressen → gemeinsame Bits = neues Präfix. Spart Ressourcen, beschleunigt Konvergenz.|
|**IPv6 Motivation**|128-Bit-Adressen, vereinfachter Header, Autokonfiguration, integrierte Sicherheit.|
|**IPv6 Header**|40 Byte fest, Extension Headers für Erweiterungen. Next Header verkettet die Header.|
|**IPv6 Adresstypen**|Global Unicast (2000::/3), Link-Local (fe80::/10), Multicast (ff00::/8), Anycast. Kein Broadcast!|
|**NDP/ICMPv6**|Ersetzt ARP (NS/NA), ermöglicht Router Discovery (RS/RA), SLAAC und DAD.|
|**IPv4→IPv6 Migration**|Dual Stack bevorzugt. Tunnel (6in4, 6rd) als Übergangslösung.|
|**DHCP**|DORA-Prozess, Lease-Erneuerung bei 50% und 7/8, Relay für subnetzübergreifende Vergabe.|
|**WAN**|Dediziert vs. Switching (leitungs-/paketvermittelt). MPLS, Segment Routing, Carrier Ethernet, SD-WAN.|
|**PPPoE**|Discovery → Auth (PAP/CHAP) → Network Config → Operational. Verbindungsprotokoll für DSL.|
|**DSL**|ADSL, VDSL, Vectoring. DSLAM aggregiert Teilnehmer. Ablösung durch Glasfaser bis 2030.|

752
Netzwerke/zusammenfassungen/nw5 - zusammenfassung.md Normal file
View file

@ -0,0 +1,752 @@
# Netzwerktechnik – Vorlesung 5: Layer 4 (TCP/UDP), Layer 3 (NAT), Layer 7 (DNS)
**Modul:** IT2221 – Netwerktechnik
**Dozentin:** Gabriele Schrenk (e_schrenk@doz.hwr-berlin.de)
**Datum:** 20.03.2026
-----
## LAYER 4 – Transport Layer (Transportschicht)
### Wiederholung TCP/IP Referenzmodell – Schicht 4
Schicht 4 (Transport) ist zuständig für die Verbindung zwischen Endsystemen. Die Dateneinheit auf dieser Schicht heißt **Segment**. Die Transportschicht stellt Dienstgüte (Quality of Service) und Zuverlässigkeit sicher.
Das OSI-Modell von oben nach unten: Application → Presentation → Session → **Transport** → Network → Data Link → Physical.
-----
### TCP – Transmission Control Protocol
TCP ist Teil der Protokollfamilie TCP/IP und ermöglicht **Ende-zu-Ende-Kommunikation**. Der Datenstrom wird auf verschiedene Anwendungen aufgeteilt. Daten werden mit einem TCP-Header versehen und anschließend an das IP-Protokoll übergeben. Datenpakete werden beim Sender sortiert und an adressierte Anwendungen (identifiziert über **Portnummern**) geschickt.
#### Wichtigste Eigenschaften von TCP
- **Verbindungsmanagement:** TCP ist verbindungsorientiert und stellt die richtige Reihenfolge der Daten sicher.
- **Flusskontrolle (Flow Control):** Schützt gegen Pufferüberlauf beim Empfänger.
- **Zeitüberwachung (Timer):** Überwacht, ob Bestätigungen rechtzeitig eintreffen.
- **Fehlerbehandlung (Retransmission):** Verlorene oder fehlerhafte Pakete werden durch Neuübertragung korrigiert.
-----
### Aufbau des TCP-Headers
Der TCP-Header besteht aus folgenden Feldern:
|Feld |Beschreibung |
|--------------------------|---------------------------------------------------------------------|
|**Quell-Port / Ziel-Port**|Identifizieren die sendende und empfangende Anwendung |
|**Sequenz-Nummer** |Nummer des ersten Bytes im aktuellen Segment |
|**Acknowledgement-Nummer**|Nummer des nächsten erwarteten Datenpakets |
|**Data-Offset** |Anzahl der 32-bit-Blöcke im TCP-Header (entspricht der Header Length)|
|**Flags** |SYN, ACK, FIN, RST, URG, PSH, ECE, CWR |
|**Window-Größe** |Größe des Empfangs-Puffers (für Flusskontrolle) |
|**Check-Summe** |Prüfsumme zur Fehlererkennung |
|**Urgent-Pointer** |Zeigt auf das Ende dringender Daten (schnelle Zustellung) |
|**Options** |Optionale Felder wie Max. Segment Size (MSS), Window Scale, Timestamp|
Aufbau als Tabellenstruktur:
```
| Quell-Port | Ziel-Port |
| Sequenz-Nummer |
| Acknowledgement-Nummer |
| Data-Offset | Reserviert | Flags | Window |
| Check-Summe | Urgent-Pointer |
| Option / Füllbits |
| Daten... |
```
-----
### TCP – Portnummern
Ports werden von der **Internet Assigned Numbers Authority (IANA)** für alle Transportprotokolle vergeben. Es gibt drei Bereiche:
|Bereich |Portnummern|Beschreibung |
|-------------------------------|-----------|-------------------------------------------|
|**Well-Known Ports** |0–1023 |Standardisierte, allgemein bekannte Dienste|
|**Registered Ports** |1024–49151 |Registrierte Dienste und Anwendungen |
|**Dynamically Allocated Ports**|49152–65535|Dynamisch zugewiesene (ephemere) Ports |
#### Beispiele für TCP-Ports
|Port|Protokoll|Anwendung |
|----|---------|--------------------------------------------|
|21 |FTP |Dateitransfer |
|22 |SSH |Secure Shell Service |
|23 |Telnet |Konsole |
|25 |SMTP |Simple Mail Transfer Protocol |
|80 |HTTP |Hypertext Transfer Protocol (World Wide Web)|
|110 |POP3 |Post Office Protocol v3 für E-Mail |
|123 |NTP |Dienst zur Zeitsynchronisierung |
|179 |BGP |Border Gateway Protocol |
|220 |IMAP3 |Internet Message Access Protocol für E-Mail |
|443 |HTTPS |HTTP Secure |
-----
### TCP – Acknowledgement-Mechanismus
TCP verwendet Sequenz- und Acknowledgement-Nummern zur zuverlässigen Datenübertragung.
**Ablauf-Beispiel:**
1. Sender schickt Paket mit Seq=10 (Source-Port 1028, Dest-Port 23, Ack=1).
2. Empfänger empfängt Paket #10 und antwortet mit Ack=11 (Source-Port 23, Dest-Port 1028, Seq=1, Ack=11). Die Ack-Nummer 11 bedeutet: „Ich erwarte als nächstes Paket #11.”
3. Sender sendet nächstes Paket mit Seq=11 (Ack=2).
Die **Acknowledgement-Nummer** gibt immer die Sequenznummer des **nächsten erwarteten** Pakets an.
-----
### TCP – Verbindungsaufbau (Three-Way-Handshake)
Der TCP-Verbindungsaufbau erfolgt in drei Schritten:
**Schritt 1:** Client (Host A) sendet ein **SYN**-Paket an den Server (Host B).
- `seq=100, ctl=SYN`
**Schritt 2:** Server empfängt das SYN und antwortet mit **SYN+ACK**.
- `seq=300, ack=101, ctl=SYN,ACK`
- Der Server bestätigt den Empfang (ACK) und schickt gleichzeitig seinen eigenen Verbindungswunsch (SYN). Die ack=101 bestätigt, dass seq=100 empfangen wurde und als nächstes seq=101 erwartet wird.
**Schritt 3:** Client bestätigt mit **ACK**. Die Verbindung ist hergestellt.
- `seq=101, ack=301, ctl=ACK`
Zusammenfassung: Client sendet SYN → Server antwortet SYN+ACK → Client bestätigt ACK → Datenaustausch möglich.
-----
### TCP – Verbindungsabbau (4-Way-Handshake)
Der Verbindungsabbau ist dem Aufbau ähnlich, aber umgekehrt und benötigt **vier Schritte**:
**Schritt 1:** Host A sendet **FIN** (Verbindungsabbauwunsch).
- `seq=101, ctl=FIN`
**Schritt 2:** Host B empfängt FIN und bestätigt mit **ACK**.
- `seq=300, ack=101, ctl=ACK`
**Schritt 3:** Host B sendet seinerseits **FIN** (eigener Abbauwunsch).
- `seq=301, ack=101, ctl=FIN`
**Schritt 4:** Host A bestätigt mit **ACK**. Die Verbindung ist beendet.
- `seq=102, ack=302, ctl=ACK`
-----
### TCP – Sliding Window
#### Motivation
- TCP muss die Menge an gleichzeitig übertragenen Bytes verarbeiten.
- Es gibt Methoden zur Bestätigung der Pakete und Flusskontrolle.
- Bei **Paketverlust** wird ab dem verlorenen Paket erneut übertragen (erkannt durch ausbleibende ACKs oder Timeout) → Garantie, dass alle Pakete ankommen.
- Pakete werden in der richtigen Reihenfolge an die Anwendungsschicht übergeben und müssen daher zwischengepuffert werden → Risiko eines **Pufferüberlaufs**.
#### Sliding Window Mechanismus
- Das Sliding Window regelt die **Senderate** in Bezug auf den Buffer des Empfängers.
- Der TCP-Stack hat unterschiedlich viel Speicher.
- Wird Verlust festgestellt, wird der Sender informiert.
- Der Sender **reduziert** daraufhin die Anzahl der zu sendenden Pakete pro Zeiteinheit.
#### Fenster-Größe = 1 (Stop-and-Wait)
Bei Fenstergröße 1 wird jeweils nur ein Paket gesendet und auf dessen ACK gewartet, bevor das nächste Paket gesendet wird. Bei Paketverlust: der **Retransmission-Timer** läuft ab und das Paket wird erneut gesendet.
**Beispiel mit Paketverlust (Fenstergröße 1):**
- Sender sendet Paket 1 → Empfänger bestätigt mit ACK 2.
- Sender sendet Paket 2 → Paket geht verloren.
- Retransmission-Timer läuft ab → Sender sendet Paket 2 erneut.
- Empfänger empfängt Paket 2 → Sendet ACK 3.
**Variante:** Das ACK geht verloren statt des Datenpakets. Der Sender sendet Paket 2 erneut, der Empfänger empfängt es doppelt (verwirft das Duplikat dank Sequenznummer) und sendet erneut ACK 3.
#### Fenster-Größe = 3
Mit einer größeren Fenstergröße können **mehrere Pakete** gleichzeitig gesendet werden, ohne auf einzelne ACKs zu warten.
- Das Fenster (Sliding Window) liegt über den zu sendenden Paketen.
- Alle Pakete innerhalb des Fensters werden verschickt.
- Beispiel mit Fenstergröße 3: Die ersten 3 Pakete werden verschickt. Paket 4 geht erst raus, wenn das ACK für Paket 1 eingetroffen ist.
- Pakete, für die kein ACK vorliegt, werden **nochmals verschickt**.
**Beispiel mit Paketverlust (Fenstergröße 3):**
- Sender sendet Pakete 1, 2, 3.
- Paket 2 geht verloren. Empfänger empfängt 1 und 3, sendet ACK 2 (fordert Paket 2 erneut an).
- Nach Empfang von ACK 2 sendet der Sender erneut Pakete 2, 3, 4.
- Empfänger empfängt 2, 3, 4 → Sendet ACK 5.
**Beispiel mit ACK-Verlust (Fenstergröße 3):**
- Sender sendet Pakete 1, 2, 3 → Empfänger empfängt alle, sendet ACK 4.
- ACK 4 geht verloren → Retransmission-Timer läuft ab.
- Sender sendet Paket 1 erneut → Empfänger empfängt 1 erneut, sendet ACK 4.
- Sender empfängt ACK 4 → Sendet Paket 4.
#### Gruppenaufgaben
**Aufgabe 1:** Sender sendet drei Pakete (seq=100, 101, 102; alle mit ack=5). Alle drei kommen beim Empfänger an.
**Lösung:** Empfänger antwortet mit `seq=5, ack=103, ctl=ACK` (erwartet als nächstes Paket 103).
**Aufgabe 2:** Sender sendet drei Pakete (seq=100, 101, 102; alle mit ack=5). Paket 101 geht verloren (nur 100 und 102 kommen an).
**Lösung:** Empfänger antwortet mit `seq=5, ack=101, ctl=ACK` (fordert Paket 101 erneut an, da es fehlt).
-----
### TCP – Flusskontrolle
- Pakete und Meldungen werden mit **Sequenznummern** versehen.
- Mögliche Übertragungsprobleme: doppelte Datenpakete, doppelte Quittierungen.
- Durch Nummern ist Reihenfolge und Zuordnung bekannt.
- Es folgen erst wieder Datenpakete, wenn das erste ACK kommt.
- Die **Fenstergröße wird während der Übertragung angepasst** durch:
- **Slow Start:** Exponentielles Wachstum der Fenstergröße bis zum Threshold.
- **Fast Retransmit:** Sofortige Neuübertragung ohne Warten auf den Timer, wenn **3 doppelte ACKs** empfangen werden.
- **Additive Erhöhung (Congestion Avoidance):** Lineares Wachstum der Fenstergröße nach dem Threshold für faire und effiziente Zuteilung der Bandbreite.
#### CWND (Congestion Window) zur Vermeidung von Überlast
Das CWND beschreibt die Menge der unbestätigten Pakete. Der Verlauf über die Zeit:
1. **Slow-Start-Phase:** CWND wächst exponentiell (Verdopplung pro RTT).
2. Ab dem **Threshold** wechselt es in die **Congestion Avoidance** Phase: CWND wächst linear.
3. Bei **Fast Retransmit** (3 doppelte ACKs): CWND wird halbiert, neuer Threshold wird gesetzt, dann wieder lineares Wachstum.
-----
### UDP – User Datagram Protocol
#### Eigenschaften von UDP
- **Kein** Verbindungs-Aufbau / -Management (verbindungslos).
- **Ungesicherter Dienst** (keine Garantie für Zustellung).
- Verzichtet auf den bei TCP notwendigen Overhead.
- Für **Multicast** und **Broadcast** nutzbar.
#### UDP – Funktionsweise
UDP hat im Vergleich zu TCP die gleichen grundlegenden Funktionen (Port-Zuordnung, Datenweiterleitung), aber **keine**:
- Kontrollfunktion
- Sicherstellung von Datenempfang
- Nummerierung der Datenpakete
UDP ist **schlanker und einfacher** zu verarbeiten. Daten werden direkt an die Anwendungen weitergeleitet. Die Anwendung trägt selbst die Verantwortung für die Sicherstellung der Übertragung, zum Beispiel durch einen **Jitterbuffer**, der Laufzeitvarianzen ausgleicht.
Typische Einsatzgebiete: DNS-Anfragen, Echtzeit Audio-/Video-Streaming, VPN.
#### UDP-Header
Der UDP-Header ist mit nur **8 Byte** sehr schlank:
|Feld |Größe |Beschreibung |
|-----------|------|---------------------------------------|
|Quell-Port |2 Byte|Source Port |
|Ziel-Port |2 Byte|Destination Port |
|Länge |2 Byte|Gesamtlänge von Header und Datenbereich|
|Check-Summe|2 Byte|CRC zur Fehlererkennung |
Danach folgen die Daten.
#### Beispiele für UDP-Ports
|Port|Protokoll|Anwendung |
|----|---------|--------------------------------------------|
|53 |DNS |Domain Name Server |
|67 |DHCP |Dynamic Host Configuration Protocol (Server)|
|68 |DHCP |Dynamic Host Configuration Protocol (Client)|
|69 |TFTP |Trivial File Transfer Protocol |
|161 |SNMP |Simple Network Management Protocol |
-----
### SCTP – Stream Control Transmission Protocol
SCTP wurde im Jahr 2000 von der IETF als Transportprotokoll standardisiert. Eigenschaften:
- **Zuverlässig und verbindungsorientiert** (wie TCP).
- Unterstützt das Konzept von **Assoziationen** (logische Verbindungen).
- **Multistreaming:** Mehrere Datenströme gleichzeitig über eine einzige Assoziation möglich.
- **Multihoming:** Unterstützt mehrere IP-Adressen pro Endpunkt für Ausfallsicherheit.
- Dienstgüte ähnlich wie TCP (Fluss-/Überlastkontrolle).
Einsatzgebiete:
- Signalübertragung zwischen RAN und EPC in **LTE**.
- Transportprotokoll für das **Diameter-Protokoll** (AAA: Authentifizierung, Autorisierung, Abrechnung) in LTE.
- Control Plane Protokoll im **5G Core Netz**.
- Robuste **IoT-Anwendungen** (Internet of Things).
-----
## LAYER 3 – Network Layer (Vermittlungsschicht) – NAT
### Konzept von NAT in IPv4
**NAT (Network Address Translation)** wird in IPv4-Netzwerken verwendet, um die Anzahl benötigter öffentlicher IP-Adressen zu **minimieren** und gleichzeitig **Sicherheit** und **Flexibilität** des Netzwerks zu erhöhen.
NAT ermöglicht, dass mehrere Systeme in einem privaten Netzwerk über eine **einzige öffentliche IP-Adresse** auf das Internet zugreifen.
Hauptfunktionen:
- **Adressübersetzung:** Private IP-Adressen der internen Systeme werden in eine öffentliche IP-Adresse übersetzt.
- **Verstecken der internen Struktur:** Interne IP-Adressen sind von außen nicht sichtbar → erhöht die Sicherheit.
- **Verwaltung von IP-Adressen:** Organisationen können ihre internen Netzwerke unabhängig von den öffentlichen IP-Adressen verwalten.
-----
### Arten von NAT
|NAT-Typ |Beschreibung |
|-------------------------------------------------|---------------------------------------------------------------------------------------------------------------|
|**Static NAT** |Feste 1:1-Zuordnung zwischen einer privaten und einer öffentlichen IP-Adresse |
|**Dynamic NAT** |Zuordnung von mehreren privaten IP-Adressen zu einer Gruppe (Pool) von öffentlichen IP-Adressen |
|**PAT (Port Address Translation) / NAT Overload**|Mehrere private IP-Adressen teilen sich **eine einzige** öffentliche IP-Adresse, unterschieden über Portnummern|
-----
### Prozess der NAT-Umsetzung (PAT-Beispiel)
Szenario: Internes Netzwerk mit PC1 (192.168.1.2), PC2 (192.168.1.3), PC3 (192.168.1.4). Router hat die öffentliche IP-Adresse 203.0.113.5 und verwendet PAT.
**Ausgehender Verkehr (PC1 → Webserver 93.184.216.34):**
1. PC1 sendet ein Paket an 93.184.216.34. Das Paket hat Quell-IP 192.168.1.2.
2. Der Router empfängt das Paket und erkennt die private Quelladresse.
3. Er ändert die Quell-IP-Adresse auf seine öffentliche Adresse **203.0.113.5** und weist eine eindeutige L4-Portnummer zu (z.B. **10001**).
4. Das Paket wird mit der neuen Quelladresse 203.0.113.5:10001 ins Internet gesendet.
**Eingehender Verkehr (Antwort vom Webserver):**
1. Der Webserver antwortet an 203.0.113.5:10001.
2. Der Router empfängt die Antwort und schaut in seiner **NAT-Tabelle** nach.
3. Er übersetzt die Zieladresse zurück zu 192.168.1.2, indem er die Portnummer 10001 verwendet, um den richtigen internen PC zu identifizieren.
PC2 und PC3 erhalten eigene Portnummern (z.B. 10002, 10003). Der Router verwendet die **gleiche** öffentliche IP-Adresse, aber **verschiedene Ports** für die Zuordnung.
-----
### Zuweisung der Portnummer im Detail
- Die Portnummer wird vom **Router** während des NAT-Prozesses zugewiesen, wenn ein internes System eine Verbindung zu einem externen Server initiiert.
- Der Router führt eine Übersetzung der **Quell-IP-Adresse** und der **Quell-Portnummer** durch.
- Ein Eintrag in einer **NAT-Tabelle** wird erstellt, der die Zuordnung von interner IP:Port zu externer IP:Port speichert.
- Portnummern werden auf der **Transport-Schicht (Schicht 4)** des OSI-Modells zugewiesen und sind im **Transport-Header** (TCP oder UDP) des IP-Pakets kodiert.
**Konkretes Beispiel:**
- PC mit IP 192.168.1.2 und Quellport 50000 möchte zu Webserver 93.184.216.34 (Port 80 HTTP).
- IP-Paket enthält: IP-Header (Quell-IP 192.168.1.2, Ziel-IP 93.184.216.34) + TCP-Header (Quellport 50000, Zielport 80).
- Router ändert Quell-IP auf 203.0.113.5 und weist neuen Quellport 10001 zu.
- NAT-Tabelle: 192.168.1.2:50000 ↔ 203.0.113.5:10001.
- Paket wird gesendet mit Quell-IP 203.0.113.5, Quellport 10001. Die **Zielportnummer bleibt unverändert** (80).
-----
### Sicherheitskonzept hinter NAT
#### 1. Verstecken interner IP-Adressen
- NAT verbirgt die internen IP-Adressen der Systeme (**Anonymität**).
- Alle Systeme greifen mit der öffentlichen IP-Adresse des Routers auf das Internet zu.
- Angreifer können nicht direkt auf interne Systeme zugreifen, da die IP-Adressen nicht bekannt sind.
- Für mehrere Systeme (PCs, Smartphones etc.) sieht ein externer Server nur die öffentliche IP-Adresse des Routers.
- Interne Adressen (z.B. 192.168.1.2, 192.168.1.3) sind für den externen Server **unsichtbar**.
#### 2. Einschränkung eingehender Verbindungen
- NAT erlaubt standardmäßig **keine eingehenden Verbindungen** von externen Quellen.
- Nur **intern initiierte** Verbindungen erhalten eine Rückantwort.
- Ein Angreifer kann keine Verbindung nach intern herstellen, **außer** eine spezifische **Portweiterleitung** oder Regel wurde konfiguriert.
- Ein Webserver im Internet kann seine Antwort nur an die öffentliche IP-Adresse des Routers senden.
#### 3. Port Address Translation (PAT)
- Bei PAT (NAT Overload) nutzen alle Systeme dieselbe öffentliche IP-Adresse mit **verschiedenen Portnummern**.
- Erhöht die Sicherheit durch **Verringerung der Angriffsvektoren**.
- Ein Angreifer, der eine Verbindung zu 203.0.113.5 versucht, hat keine Information darüber, welches interne Gerät auf welchem Port aktiv ist.
#### 4. Einfachheit der Konfiguration
- NAT-Implementierungen bieten oft eine **eingebaute Firewall-Funktionalität**.
- Der NAT-Router blockiert automatisch unerwünschte eingehende Verbindungen.
- Viele Angriffsarten (z.B. Port-Scanning-Versuche) werden erschwert.
**Wichtig:** NAT ist **kein vollständiger Ersatz** für Sicherheitslösungen wie Firewalls oder Intrusion Detection Systems, sondern nur eine **weitere Ergänzung** der Sicherheitsarchitektur.
-----
### NAT in IPv6
Bei IPv6 wird die Notwendigkeit für NAT oft in Frage gestellt, da IPv6 einen nahezu **unbegrenzten Adressraum** bietet. NAT bleibt jedoch in bestimmten Szenarien relevant. Die relevanten Konzepte sind **NAT64** und **NPTv6**.
#### NAT64
NAT64 ermöglicht **IPv6-Clients den Zugriff auf IPv4-Ressourcen**.
Funktionsweise:
1. Ein IPv6-Client möchte auf einen IPv4-Webserver zugreifen (z.B. 203.0.113.10).
2. Der NAT64-Router übersetzt die Ziel-IPv4-Adresse in ein IPv6-Format. Die IPv4-Adresse 203.0.113.10 wird in das Well-Known IPv6-Präfix **64:ff9b::** eingebettet (Ergebnis z.B. 64:ff9b::cb00:710a).
3. Der Webserver sendet die Antwort zurück an die IPv4-Adresse des NAT64-Routers.
4. Der NAT64-Router übersetzt die Antwort von IPv4 zurück zu IPv6 und leitet sie an den Client weiter.
Vorteile von NAT64:
- **Interoperabilität:** IPv6-Clients erhalten Zugriff auf IPv4-Ressourcen.
- **Keine Änderungen an IPv4-Servern** nötig.
- **Erleichtert den Übergang** von IPv4 zu IPv6, da bestehende IPv4-Dienste weiterhin nutzbar bleiben.
#### NPTv6 (Network Prefix Translation)
NPTv6 ist eine Art NAT, die **nur das Präfix** einer IPv6-Adresse ändert (der Interface-Identifier bleibt gleich).
Anwendungsfall: Ein Netzwerk wechselt den ISP. Der neue ISP vergibt ein neues IPv6-Präfix (z.B. 2001:0db8:1234::/48 statt des alten 2001:0db8:abcd::/48). Der NPTv6-Router wird so konfiguriert, dass er eingehende/ausgehende Pakete mit dem alten Präfix in das neue Präfix übersetzt.
Beispiel: Quelladresse 2001:0db8:abcd:0001::1 wird zu 2001:0db8:1234:0001::1 übersetzt.
Vorteile von NPTv6:
- **Einfache Migration:** Internes Adressschema kann trotz ISP- oder Präfix-Wechsel beibehalten werden.
- **Minimale Änderungen:** Keine Neukonfiguration aller internen Geräte nötig.
- **Transparente Übersetzung:** Geschieht transparent für die internen Geräte, keine Änderungen an Anwendungen oder Diensten.
#### Warum NAT auch bei IPv6 noch relevant ist
- **Transition IPv4→IPv6:** In der Übergangsphase existieren noch viele IPv4-Ressourcen → NAT64 nötig.
- **Sicherheitsaspekte:** NAT verbirgt die interne Netzwerkstruktur. Auch wenn IPv6 Sicherheit durch IPsec bietet, möchten Organisationen möglicherweise zusätzliche Schutzmaßnahmen.
- **Routenmanagement:** NPTv6 ermöglicht präfixbasierte Strategien, die Routing und Netzwerkinfrastruktur vereinfachen.
- **Flexibles Adressmanagement:** Organisationen können Adressierungssysteme anpassen, ohne interne Strukturen zu beeinträchtigen → NPTv6.
- **Legacy-Systeme:** Viele bestehende Systeme sind noch auf IPv4 konfiguriert → NAT64 ermöglicht den gleichzeitigen Betrieb.
-----
## LAYER 7 – Application Layer (Anwendungsschicht) – DNS
### Domain Name Service (DNS) – Grundlagen
DNS ist ein **hierarchisches System** zur Namensauflösung. Es wandelt **Domainnamen** (z.B. www.example.com) in **IP-Adressen** (z.B. 192.0.2.1) um. Der Zweck ist die Verwendung leicht merkbarer Domainnamen statt numerischer IP-Adressen, was eine benutzerfreundliche Navigation im Internet ermöglicht.
Zwei Kernkomponenten:
- **Name-Server:** Software/Server zum Beantworten von DNS-Anfragen. Pro Zone gibt es einen primären Server.
- **Resolver:** Software zum Auflösen von Rechnernamen. Ergebnisse werden im Cache gespeichert (Caching).
-----
### DNS-Struktur (Hierarchien)
Das DNS ist hierarchisch aufgebaut:
- **Root-Domain:** Höchste Ebene, dargestellt als Punkt (.). Umfasst alle TLDs. Der Root-Server ist der Ausgangspunkt für alle DNS-Abfragen.
- **Top-Level-Domains (TLD):** z.B. .com, .net, .edu, .org, .gov, .de. Umfassen verschiedene Kategorien von Domains.
- **Second-Level-Domains:** z.B. example.com. Typischerweise der Name einer Organisation oder eines Unternehmens.
- **Subdomains:** z.B. www.example.com, mail.example.com. Befinden sich unter der Second-Level-Domain und dienen zur Strukturierung von Inhalten.
```
Root-Domain (.)
├── Top-Level-Domain (TLD)
│ ├── .com
│ ├── .org
│ └── .net
└── Second-Level-Domain
├── example.com
└── test.org
└── sub.test.org
```
-----
### FQDN – Fully Qualified Domain Name
- Besteht aus **Hostname** und **Domain-Name**.
- Domain-Name besteht aus Subdomain(s) und Toplevel-Domain.
- Trennung durch Punkte, der absolute Pfad endet mit einem **Punkt**.
- Format: `Hostname.Subdomain.Toplevel-Domain.` → Beispiel: `mail.example.com.`
- **Maximale Länge:** 255 Zeichen.
- Jede **Subdomain** ist 1 bis 63 Zeichen lang.
- **Protokoll:** UDP-Port 53 für normale Anfragen, TCP-Port 53 für Zonentransfer.
-----
### Root-DNS-Server
- Es gibt **13 Gruppen** von Root-DNS-Servern weltweit verteilt, bezeichnet mit Buchstaben **A bis M** (z.B. a.root-servers.net, b.root-servers.net usw.).
- Diese Root-Server sind **nicht speziell** für .com zuständig, sondern sind die erste Anlaufstelle für alle TLD-Anfragen.
- Aktuell bestehen die 13 Gruppen aus **1.907 Instanzen**, verwaltet von **12 Organisationen**.
- Die Verwaltung wird von der **ICANN** (Internet Corporation for Assigned Names and Numbers) koordiniert – einer gemeinnützigen Organisation, zuständig für die Koordination von IP-Adressen und Domainnamen.
- Website: root-servers.org
- **RIPE** (Réseaux IP Européens): 1989 gegründeter gemeinnütziger Verein als Forum zur technischen Koordination des Internets. **RIPE NCC** (RIPE Network Coordination Centre) hat seinen Sitz in Amsterdam.
-----
### DNS-Record-Typen
#### A-Record (Address Record)
- Verknüpft einen Domainnamen mit einer **IPv4-Adresse**.
- Eintrag: `example.com. IN A 192.0.2.1`
- Wenn jemand example.com eingibt, wird er zur IP-Adresse 192.0.2.1 geleitet.
#### AAAA-Record (IPv6 Address Record)
- Verknüpft einen Domainnamen mit einer **IPv6-Adresse**.
- Eintrag: `example.com. IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334`
#### CNAME-Record (Canonical Name Record)
- Erstellt einen **Alias** für einen anderen Domainnamen.
- Eintrag: `www.example.com. IN CNAME example.com.`
- Zugriff auf www.example.com wird auf example.com umgeleitet. Alle Anfragen werden an die IP-Adresse von example.com weitergeleitet.
#### MX-Record (Mail Exchange Record)
- Gibt den **Mailserver** für die Domain an.
- Eintrag: `example.com. IN MX 10 mail.example.com.`
- E-Mails an example.com werden an mail.example.com weitergeleitet.
- Die Zahl (10) gibt die **Priorität** an: niedrigere Zahlen = höhere Priorität.
#### NS-Record (Name Server Record)
- Zeigt, welche DNS-Server **autoritativ** für die Domain sind.
- Eintrag: `example.com. IN NS ns1.exampledns.com.`
#### PTR-Record (Pointer Record)
- Auflösung einer **IP-Adresse zu einem Domainnamen** (Reverse DNS).
- Eintrag: `1.2.0.192.in-addr.arpa. IN PTR example.com.`
- IP-Adresse 192.0.2.1 wird auf example.com aufgelöst.
#### SOA-Record (Start of Authority Record)
- Enthält **administrative Informationen** über die Domain, einschließlich des primären DNS-Servers und der Kontaktinformationen.
- Eintrag: `example.com. IN SOA ns1.exampledns.com. hostmaster.example.com. (2023010101 ; Serial 3600 ; Refresh 1800 ; Retry 604800 ; Expire 86400 ; Minimum TTL)`
Felder des SOA-Records:
- **Name:** Domainname
- **TTL bei Antwort:** Wie lange Informationen gespeichert werden
- **Zonen-Klasse (IN):** Steht für Internet
- **Primärer Server:** Domain Name des primären DNS-Servers (Master)
- **Verantwortlicher:** E-Mail-Adresse des Administrators (mit `.` statt `@`)
- **Seriennummer:** Nummer der Zonendatei, anhand derer Secondary-Server erkennen, ob eine Aktualisierung nötig ist
- **Refresh-Zeit:** Zeit in Sekunden, die ein Secondary Server wartet, bevor er erneut die Seriennummer abfragt (typisch 1–12h)
- **Retry-Zeit:** Erneuter Versuch, wenn Refresh nicht erfolgreich war
- **Expire-Zeit:** Gültigkeitsdauer in Sekunden. Nach Ablauf gibt der Secondary keine Antworten mehr
- **TTL bei keiner Antwort (Minimum):** Dauer der Speicherung von „Domain existiert nicht”-Antworten. Verhindert Überlastungen
Beispiel SOA-Record für google.com (abfragbar mit `nslookup –type=SOA google.com`):
```
google.com. 21599 IN SOA ns1.google.com. dns-admin.google.com.
2023032701 ; serial
7200 ; refresh (2 hours)
1800 ; retry (30 minutes)
604800 ; expire (1 week)
60 ; minimum (1 minute)
```
-----
### DNS-Server und Resolver
#### Aufgaben eines DNS-Servers
- Hostet die DNS-**Zonendateien**.
- Ist **autoritativ** für bestimmte Domains.
- Liefert Informationen über Domainnamen und deren zugehörige IP-Adressen.
#### Aufgaben eines DNS-Resolvers
- Ist **nicht autoritativ**, bearbeitet Anfragen von Clients.
- Liefert IP-Adressen an den Client.
- Fungiert als **Vermittler** zwischen dem Client und den DNS-Servern.
#### DNS-Resolver Installation
- Kann ein öffentlicher DNS-Resolver eines ISPs sein.
- Kann ein separater, lokaler Server in einem Unternehmensnetzwerk sein.
- Cloud Provider bieten DNS-Resolver als Teil ihres Services an.
-----
### DNS-Namensauflösung – Zwei Methoden
#### 1. Rekursive Anfrage (Verantwortung beim DNS-Resolver)
Der Resolver übernimmt die **komplette Auflösung** im Auftrag des Clients:
1. Benutzer fragt im Browser nach www.example.com → Client fragt den lokalen DNS-Resolver.
2. Resolver prüft seinen **Cache**. Falls vorhanden: IP-Adresse direkt zurückgeben.
3. Falls nicht im Cache: Resolver fragt einen **Root-DNS-Server** → dieser gibt den TLD-Server für .com zurück.
4. Resolver fragt den **TLD-Server** → dieser gibt den autoritativen DNS-Server für example.com zurück.
5. Resolver fragt den **autoritativen DNS-Server** → dieser gibt die IP-Adresse zurück.
6. Resolver gibt die IP-Adresse an den Client und **speichert sie im Cache**.
#### 2. Iterative Anfrage (Anfrage an andere Server)
Der Resolver fragt nur **einmal** den bekannten DNS-Server. Hat der Server die Antwort nicht, gibt er entweder die IP-Adresse eines anderen Servers zurück oder einen Fehler.
Ablauf:
1. Client-Anfrage geht ein, Resolver prüft den Cache.
2. Sendet Abfrage an den **Root-DNS-Server**.
3. Root-Server liefert die Adresse des **TLD-Servers** (nicht die finale Antwort).
4. Resolver muss dann **separat** den TLD-Server anfragen.
5. Falls der TLD-Server die Antwort nicht hat, verweist er auf den autoritativen Server → Resolver stellt **erneute Anfrage**.
6. IP-Adresse wird an den Client geliefert, nachdem alle Anfragen durchgeführt sind.
**Vergleich:**
- **Rekursiv** wird verwendet, wenn eine vollständige Auflösung gewünscht ist → Standardkonfiguration der meisten DNS-Resolver der ISPs.
- **Iterativ** wird in bestimmten Architekturen verwendet, mit eventuellen Vorteilen bei Ressourcennutzung, Kontrolle, Sicherheit und Performance.
-----
### DNS – Root Zone Management
Die **IANA** (Internet Assigned Numbers Authority) ist verantwortlich für das Management der DNS Root Zone. Sie weist Operators zu Top-Level Domains zu und verwaltet die administrativen Details → **Root Zone Database**.
IANA-Whois-Service zeigt Informationen zu TLDs:
- **.com** (USA): Registriert 1985, Organisation: VeriSign Global Registry Services, Reston VA.
- **.cn** (China): Registriert 1990, Organisation: China Internet Network Information Center (CNNIC), Beijing.
- **.de** (Deutschland): Registriert 1986, Organisation: DENIC eG, Frankfurt am Main.
-----
### DNS-Zone
- Eine Zone ist der **Teil des Domain-Baumes**, für den ein Server zuständig ist.
- Ein Server kann **primäre und sekundäre** Zonen verwalten.
- Daten werden in der **primären Zone** gepflegt.
- Übertragung an Secondary DNS-Server erfolgt über **Zonentransfer** (Backup-Server).
**Zwei Mechanismen für Zonentransfer:**
1. **Benachrichtigung durch Master (Push):** Der Master (Primary) unterrichtet die Slaves (Secondaries) über Änderungen. Der Slave fordert dann die geänderten Daten oder die komplette Zone an.
2. **Daten werden vom Slave angefordert (Pull):** Der Secondary DNS-Server fordert regelmäßig den **SOA-Record** an und vergleicht die **Seriennummer**. Falls die Seriennummer des Secondary kleiner ist als die des Servers → Zonentransfer wird eingeleitet.
-----
### DNS – Reverse Lookup
Reverse Lookup ist die Umsetzung einer **IP-Adresse in einen Namen** (umgekehrte Richtung zur normalen Namensauflösung).
- Zone: `in-addr.arpa.` für IPv4, `ip6.arpa.` für IPv6.
- IP-Oktette werden **von rechts nach links** aufgelöst.
- IP: 134.30.15.41 → Reverse: `41.15.30.134.in-addr.arpa.`
- Jedes Oktett der IP-Adresse bildet eine **Ebene** in der DNS-Hierarchie.
- Adressen können in höheren Ebenen eingetragen sein.
- Feinere Unterteilungen als **/24** sind nicht möglich.
-----
### Dynamisches DNS (DDNS ≠ DynDNS)
#### Dynamische Client-Konfiguration
- Name wird vom DHCP-Server zugeordnet.
- Client behält seinen Namen und nimmt nur die IP vom DHCP-Server.
#### DynDNS
- Konstante Aktualisierung der IP-Adresse für ein Domainame
- Aktualisierung über **Web-Interface** oder **Client-Software**.
- Die letzte Zuordnung bleibt bestehen.
- Verwendet **sehr kurze TTL**, damit Änderungen schnell wirksam werden.
#### DDNS
- Aktualisierung **direkt beim Name-Server** (standardisiertes DNS-Update-Protokoll).
- Aktualisierungen werden an andere Server der Zone **weitergereicht**.
- Erfordert **Authentifizierung**.
-----
### DNS – Service Record (SRV)
SRV-Records ermöglichen es, **Dienste dynamisch zu lokalisieren**. Sie sind ein spezieller Typ von DNS-Eintrag, der Informationen über Dienste bereitstellt. Clients können den Standort eines bestimmten Dienstes (z.B. VoIP, Instant Messaging) finden, ohne im Voraus zu wissen, auf welchem Server der Dienst läuft.
#### Struktur eines SRV-Records
|Feld |Beschreibung |
|------------|---------------------------------------------------------------|
|**Service** |Name des Dienstes (z.B. `_sip` für SIP) |
|**Protocol**|Verwendetes Protokoll (z.B. `_tcp`, `_udp`) |
|**Name** |Domainname, für den der SRV-Record gilt |
|**Priority**|Priorität des Dienstes (niedrigere Werte = höhere Priorität) |
|**Weight** |Gewicht für Lastenausgleich zwischen Servern gleicher Priorität|
|**Port** |Port, über den der Dienst erreichbar ist |
|**Target** |Zielhost, der den Dienst bereitstellt |
#### Beispiel: SRV-Record für VoIP über UDP
```
_sip._udp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.
```
Erklärung der Felder:
- `_sip._udp`: SIP-Dienst über UDP-Protokoll. Der Unterstrich `_` kennzeichnet einen speziellen Dienst.
- `example.com.`: Domain, die den VoIP-Dienst bereitstellt.
- `3600`: TTL in Sekunden (1 Stunde).
- `IN`: Klasse Internet.
- `SRV`: Record-Typ.
- `10`: Priorität (höhere Priorität als z.B. ein Eintrag mit 20).
- `60`: Gewicht für Lastverteilung (höherer Wert = höhere Wahrscheinlichkeit, ausgewählt zu werden).
- `5060`: Port für SIP über UDP.
- `sipserver.example.com.`: Hostname des SIP-Servers.
SRV-Records sind besonders nützlich für VoIP-Dienste, da sie Clients ermöglichen, dynamisch den richtigen Server zu finden.
-----
### Sicherheitsaspekte von DNS
#### 1. DNS Spoofing (Cache Poisoning)
- **Angriff:** Angreifer sendet **gefälschte DNS-Antworten** an einen DNS-Resolver, um dessen Cache zu manipulieren.
- **Auswirkung:** Benutzer werden auf gefälschte oder schadhafte Websites umgeleitet.
- **Schutzmaßnahmen:**
- **DNSSEC** (Domain Name System Security Extensions): Fügt **digitale Signaturen** zu DNS-Daten hinzu, um deren Authentizität zu überprüfen. Stellt sicher, dass die Daten nicht manipuliert wurden.
#### 2. DDoS-Angriffe (Distributed Denial of Service)
- **Angriff:** DNS-Server werden mit einer großen Anzahl von Anfragen **überflutet**. Richtige Anfragen erhalten keinen Zugriff auf den Dienst.
- **Schutzmaßnahmen:**
- **Lastverteilung** auf mehrere Server (Minimierung der Auswirkung).
- **Rate-Limiting:** Begrenzt die erlaubte Anzahl der Anfragen einer IP-Adresse in einem bestimmten Zeitraum.
- Spezialisierte **DDoS-Schutzlösungen** (z.B. Cloudflare, Akamai, AWS Shield), die Traffic in Echtzeit analysieren und Angriffe abwehren.
#### 3. DNS-Tunneling
- **Angriff:** Angreifer installiert Malware, die **Daten über DNS-Anfragen und -Antworten** sendet. Daten werden in kleinen DNS-Paketen übertragen (Datenexfiltration oder Command-and-Control-Kommunikation).
- **Schutzmaßnahmen:**
- Überwachung des DNS-Verkehrs auf **ungewöhnliche Muster**.
- Mittels **Firewall-Regeln** DNS-Anfragen auf autorisierte Server begrenzen.
#### 4. Man-in-the-Middle-Angriffe
- **Angriff:** Abfangen der Kommunikation zwischen Client und DNS-Server. **Manipulation** der DNS-Anfragen oder Weiterleiten auf schädliche Webseiten.
- **Schutzmaßnahmen:**
- Verwendung von **DNSSEC** stellt sicher, dass DNS-Antworten authentisch sind.
- **Verschlüsselung** der DNS-Kommunikation durch DNS-over-HTTPS (DoH) oder DNS-over-TLS (DoT).
#### 5. Phishing über DNS
- **Angriff:** Nutzung gefälschter DNS-Einträge (z.B. A-Record oder SRV-Record), um Benutzer auf **bösartige Websites** umzuleiten (z.B. gefälschte Bank-Website). Benutzer werden dazu gebracht, Anmeldedaten einzugeben.
- **Schutzmaßnahmen:**
- **Bewusstsein und Schulung:** Benutzer sollten über die Risiken von Phishing informiert und geschult werden, um verdächtige Links zu erkennen.
- **DNS-Filtering:** Technologien, die den Zugriff auf bekannte bösartige Domains blockieren.

658
Netzwerke/zusammenfassungen/nw6 - zusammenfassung.md Normal file
View file

@ -0,0 +1,658 @@
# IT2221 – Netzwerktechnik: Vorlesung 6
## Zusammenfassung: Troubleshooting, BGP, MPLS & Ausfallsicherheit
---
## 1. Troubleshooting
### 1.1 Troubleshooting-Methodik (7 Schritte)
|Schritt|Beschreibung|Beispiel|
|---|---|---|
|1|**Problem definieren**|„Was funktioniert nicht?" – PC bekommt keine IP|
|2|**Informationen sammeln**|Show-Befehle ausführen, Logs prüfen|
|3|**Daten analysieren**|Routingtabellen, Nachbarzustände auswerten|
|4|**Hypothese formulieren**|Welche OSI-Schicht ist betroffen?|
|5|**Hypothese testen**|Paketmitschnitte (PCAPs), gezielte Pings|
|6|**Korrektur planen/implementieren**|Konfiguration ändern|
|7|**Überprüfen, testen, dokumentieren**|Funktioniert es jetzt? Änderung festhalten|
### 1.2 Grundlegende Werkzeuge
**Statusinformationen auf Routern/Switches:**
- `show ip route` – Routing-Tabelle anzeigen
- `show ip interface` / `show interface` – Interface-Status und IP-Konfiguration
- `show ip ospf neighbor` / `show ip ospf database` – OSPF-Nachbarschaften und Link-State-Datenbank
- `show dhcp server leases` – Vergebene DHCP-Adressen
**Netzwerk-Diagnose-Tools:**
- **Ping** – Erreichbarkeit testen (ICMP Echo Request/Reply)
- **Traceroute** – Pfad zum Ziel Hop für Hop nachverfolgen
- **Packet Capture (PCAP)** – Paketmitschnitte zur detaillierten Analyse (z. B. mit Wireshark)
### 1.3 Troubleshooting-Szenarien aus dem Labor
**Szenario 1: PC München bekommt keine IP-Adresse**
- **Fehler A – Helper-Adresse auf falschem Interface:** Der Router München hat die `ip helper-address` auf dem falschen Interface konfiguriert. DHCP-Discover-Pakete kommen zwar vom Switch an, werden aber nicht Richtung Nürnberg (wo der DHCP-Server erreichbar ist) weitergeleitet.
- **Fehler B – Helper-Adresse verweist auf falsche IP:** Die `ip helper-address` zeigt auf eine falsche Ziel-IP. Das Relayed-Discover-Paket erreicht den DHCP-Server nicht, weil die Ziel-IP nicht stimmt → kein DHCP-Offer kommt zurück.
**Szenario 2: PC München kann PC Düsseldorf nicht erreichen**
- **Fehler A – OSPF-Area Mismatch:** München und Nürnberg haben unterschiedliche OSPF-Area-IDs auf ihrem gemeinsamen Link konfiguriert → keine OSPF-Nachbarschaft → keine Routen werden ausgetauscht. Erkennbar in den OSPF-Hello-Paketen, wo die Area-ID nicht übereinstimmt.
- **Fehler B – Fehlende OSPF-Aktivierung auf einem Interface:** Auf dem Interface Richtung Magdeburg wurde OSPF nicht aktiviert (`network`-Statement fehlt) → keine OSPF-Hello-Pakete auf diesem Link → Magdeburg/Düsseldorf sind nicht erreichbar.
**Szenario 3: Magdeburg und Düsseldorf bauen keine OSPF-Nachbarschaft auf**
- **Fehler A – Hello/Dead Timer Mismatch:** Beide Router senden OSPF-Hellos, aber mit unterschiedlichen Timer-Werten (z. B. Hello 10s vs. 30s). OSPF verlangt identische Hello- und Dead-Timer auf beiden Seiten eines Links → keine Nachbarschaft.
- **Fehler B – Falsche Subnetzmaske auf dem Link:** Die Router haben unterschiedliche Subnetzmasken auf dem gemeinsamen Link konfiguriert. OSPF prüft im Hello-Paket, ob die Subnetzmaske übereinstimmt → Mismatch → keine Nachbarschaft.
### 1.4 Troubleshooting-Ansätze (aus Referenzdokument)
**Bottom-Up (L1 → L7):** Für Totalausfälle oder neue Netze. Von der physischen Schicht nach oben arbeiten – erst Kabel, dann IP, dann Routing-Protokolle.
**Top-Down (L7 → L1):** Wenn bestimmte Dienste ausfallen, aber andere funktionieren. Z. B. Webseite geht nicht, aber Teams läuft → L1–L3 sind okay, Problem liegt höher (DNS? Firewall? Port 443 blockiert?).
**Divide and Conquer:** Erfahrener Ansatz. Man springt direkt auf Layer 3 (Ping/Traceroute). Ping geht? → Fehler liegt auf L4–L7. Ping geht nicht? → Fehler liegt auf L1–L2.
### 1.5 Wichtige Troubleshooting-Befehle (Zusammenfassung)
**Endgeräte (Windows):**
- `ipconfig /all` – IP, Subnetzmaske, Gateway, DNS
- `tracert <IP>` – Pfadverfolgung
- `arp -a` – ARP-Cache
- `route print` – Lokale Routing-Tabelle
- `nslookup <Domain>` – DNS-Test
**Endgeräte (Linux):**
- `ip a` – Interface-Status und IPs
- `traceroute <IP>` oder `mtr <IP>` – Pfadverfolgung
- `ip neigh` – ARP-Tabelle
- `ip route` – Routing-Tabelle
- `dig <Domain>` – DNS-Abfrage
**Cisco Router/Switch – Interfaces (L1/L2):**
- `show ip interface brief` – Übersicht aller Interfaces mit Status (Up/Down)
- `show interfaces <Interface>` – Detailinfos inkl. Fehler (CRC, Drops, Duplex)
- `show lldp neighbors` / `show cdp neighbors` – Direkt verbundene Nachbarn
- `show mac address-table` – MAC-Adressen an Switchports
- `show spanning-tree` – STP-Status (blockierte Ports?)
**Cisco Router – Routing (L3):**
- `show ip route` – Komplette Routing-Tabelle (O = OSPF, B = BGP, C = Connected, S* = Default)
- `show ip route <IP>` – Welches Interface wird für ein bestimmtes Ziel benutzt?
- `ping <Ziel> source <Quell-IP>` – Ping mit definierter Quell-IP (simuliert Traffic aus einem bestimmten Netz)
- `show ip arp` – ARP-Tabelle des Routers
- `show ip dhcp binding` – Vergebene DHCP-Leases
- `show ip nat translations` – Aktive NAT-Übersetzungen
**OSPF-spezifisch:**
- `show ip ospf neighbor` – Nachbarn und Status (muss FULL oder 2WAY sein; EXSTART/INIT/DOWN = Fehler)
- `show ip ospf interface brief` – Auf welchen Interfaces läuft OSPF, in welcher Area?
- `show ip route ospf` – Nur OSPF-gelernte Routen
- `show ip ospf database` – LSA-Datenbank
- `clear ip ospf process` – OSPF-Prozess neu starten (Achtung: kurze Unterbrechung)
**BGP-spezifisch:**
- `show ip bgp summary` – BGP-Nachbarn und Status (Zahl = Up; Idle/Active = Fehler)
- `show ip bgp` – BGP-Tabelle (`*>` = Valid and Best)
- `show ip bgp neighbors <IP> advertised-routes` – Was sende ich dem Nachbarn?
- `show ip bgp neighbors <IP> received-routes` – Was empfange ich vom Nachbarn?
- `clear ip bgp * soft` – Route Refresh ohne Session-Abbruch
---
## 2. Border Gateway Protocol (BGP)
### 2.1 Internet in Zahlen (Stand 20.03.2026, Vergleichswerte 2024)
|Metrik|2026|2024|
|---|---|---|
|Anzahl Prefixes (Netze)|1.064.462|947.805|
|Routing-Tabellen-Einträge|600.307|530.557|
|Autonome Systeme|78.423|75.746|
|Größtes AS (Prefixes)|16.509 (Amazon-02, US)|–|
|Größter Adressraum|227.731.200 /32 – AS749 DNIC (US DoD)|–|
Ein **Prefix** ist ein IP-Adressbereich, den ein AS über BGP ankündigt. Tagesaktuelle Zahlen: https://www.cidr-report.org
### 2.2 Grundlagen
BGP ist **das** Routing-Protokoll des Internets. Es verbindet Autonome Systeme (AS) miteinander.
**Kernmerkmale:**
- Standardisiert in **IETF RFC 4271** (Januar 2006)
- **Path-Vector-Protokoll** – Router kennen den vollständigen AS-Pfad zu jedem Ziel, nicht nur den nächsten Hop
- Kommuniziert über **TCP Port 179** (Anwendungsschicht, nutzt Transportschicht)
- Überträgt **Netzmasken** (Classless – CIDR)
- Nachbarschaften müssen **manuell konfiguriert** werden (kein Auto-Discovery wie bei OSPF)
- **Kein Load Balancing** – BGP wählt immer genau einen besten Pfad
- Routen müssen **stabil** sein (Flapping wird bestraft)
- **Authentifizierung** der Nachbarn ist möglich (MD5)
- Ein Router gehört immer zu **genau einem AS**
### 2.3 Path-Vector-Protokoll
Im Gegensatz zu Distance-Vector (z. B. RIP) oder Link-State (z. B. OSPF) speichert BGP den **kompletten Pfad** (Folge von AS-Nummern) zu jedem Ziel.
**Vorteile:**
- **Schleifenerkennung:** Wenn ein Router seine eigene AS-Nummer im AS_PATH eines empfangenen Updates sieht, verwirft er die Route sofort.
- **Routingtabelle klein halten:** Pro Interface wird nur der kürzeste Pfad weitergegeben.
### 2.4 BGP-Nachrichtentypen (RFC 4271)
|Typ|Name|Funktion|
|---|---|---|
|1|**OPEN**|Erste Nachricht nach TCP-Verbindungsaufbau. Enthält AS-Nummer, Hold-Timer, Router-ID. Antwort ist ein KEEPALIVE.|
|2|**UPDATE**|Enthält die eigentlichen Routing-Informationen. Kann neue Routen ankündigen und veraltete zurückziehen. Ermöglicht Sicht auf die gesamte AS-Topologie und Erkennung von Routing-Schleifen.|
|3|**NOTIFICATION**|Meldet Fehlersituationen (z. B. Timer Expiry, ungültige Nachrichten). Führt zum **Abbruch** der BGP-Verbindung.|
|4|**KEEPALIVE**|Periodische Nachrichten zum Erhalt der Verbindung. Wird regelmäßig gesendet, damit der Nachbar weiß, dass die Session noch aktiv ist.|
### 2.5 BGP-Wegewahl: Pfadauswahl über Attribute
BGP wählt den besten Pfad in einem **9-stufigen Verfahren**. Die drei wichtigsten Attribute:
**LOCAL_PREF (Local Preference):**
- Bestimmt den bevorzugten Ausgangsweg aus dem eigenen AS
- **Höchster Wert gewinnt**
- Wird nur innerhalb eines AS (iBGP) ausgetauscht
- Beispiel: Zwei Uplinks zu verschiedenen Providern → LOCAL_PREF 200 auf dem bevorzugten, 100 auf dem Backup
**AS_PATH:**
- Liste aller AS-Nummern, die ein Update durchlaufen hat
- **Kürzester Pfad (wenigste AS-Hops) gewinnt**
- Manipulation möglich durch **AS-Path-Prepending**: Eigene AS-Nummer mehrfach anhängen, um einen Pfad länger (und damit unattraktiver) erscheinen zu lassen
- Dient gleichzeitig der Schleifenvermeidung
**Multi_Exit_Disc (MED – Multi Exit Discriminator):**
- Wird benutzt, wenn es **mehrere Verbindungen zum selben Nachbar-AS** gibt
- Teilt dem Nachbar-AS mit, über welchen Eingang Traffic bevorzugt empfangen werden soll
- **Niedrigster Wert gewinnt**
### 2.6 BGP-Wegewahl: Vollständige Reihenfolge
|Prio|Kriterium|Auswahl|
|---|---|---|
|1|**LOCAL_PREF**|Höchster Wert|
|2|Lokal erzeugte Routen|Eigene Routen bevorzugt|
|3|**AS_PATH**|Kürzester Pfad|
|4|**ORIGIN**|IGP (i) vor EGP (e) vor Incomplete (?)|
|5|**MED**|Niedrigster Wert|
|6|**eBGP vor iBGP**|Extern gelernte Routen bevorzugt|
|7|Kürzester IGP-Weg zum Nachbarn|Nächstliegender BGP-Nachbar|
|8|Kleinste Router-ID|Tiebreaker|
|9|Kleinste Nachbar-IP|Letzter Tiebreaker|
**Konvergenzzeit:** BGP benötigt **mehrere Minuten** zur Konvergenz (deutlich langsamer als OSPF). BGP trägt immer nur **eine Route pro Netz** in die allgemeine Routing-Tabelle ein.
### 2.7 Verbindung zwischen Providern: Transit und Peering
**Transit:**
- Übermittlung von Daten zwischen einem AS und dem Internet **gegen Bezahlung**
- Der Transit-Provider leitet Traffic an alle Ziele im Internet weiter
- Typisch: Kleiner Provider kauft Transit bei größerem Provider
**Peering:**
- Vereinbarung zum **gegenseitigen Datenaustausch** zwischen zwei AS und deren angeschlossenen Netzen
- In der Regel **ohne Bezahlung** (Settlement-free Peering)
- **Privates Peering:** Direkte Verbindung zwischen zwei AS
- **Öffentliches Peering:** Über einen Internet Exchange Point (IXP, z. B. DE-CIX in Frankfurt)
### 2.8 Provider-Hierarchie (ISP-Tiers)
|Tier|Beispiele|Reichweite|Verbindungsart|
|---|---|---|---|
|**Tier 1**|Deutsche Telekom, AT&T, Orange, NTT|International/landesweit|**Nur Peering** (kaufen keinen Transit)|
|**Tier 2**|Vodafone, Swisscom, 1&1, DFN|Landesweit|**Peering und Transit**|
|**Tier 3**|wilhelm.tel, M-Net, EWE TEL|Regional/lokal|**Hauptsächlich Transit**, selten Peering|
### 2.9 BGP-Anbindung an Provider
**Single Homed:**
- Eine Verbindung zu einem Provider
- Optionen: Statische Routen oder BGP (bei häufigen Änderungen im eigenen Netz)
- **Private AS-Nummer** ausreichend (64512–65534)
**Dual Homed:**
- **Mehrere Verbindungen** zu **einem** Provider (Redundanz)
- BGP oder statische Routen
- **Private AS-Nummer** ausreichend
**(Dual) Multi Homed:**
- Verbindungen zu **mehreren Providern**
- **BGP-Routing erforderlich** (um optimale Pfadwahl zwischen den Providern zu ermöglichen)
- **Öffentliche AS-Nummer** erforderlich (wird bei einer RIR wie RIPE beantragt)
### 2.10 iBGP vs. eBGP
|Eigenschaft|iBGP|eBGP|
|---|---|---|
|Definition|Beide Nachbarn im **gleichen** AS|Beide Nachbarn in **unterschiedlichen** AS|
|Verbindung|Nicht direkt verbunden nötig, Erreichbarkeit über **IGP** (OSPF/IS-IS)|Nachbarn sind **direkt verbunden**|
|Einsatz|Innerhalb eines ISP-Netzes|Zwischen verschiedenen ISPs|
**Problem bei iBGP:** Alle BGP-Router innerhalb eines AS müssen eine **Vollvermaschung** (Full Mesh) aufbauen. Bei n Routern sind das **n × (n-1) / 2** Sessions. Das skaliert schlecht.
### 2.11 iBGP Route-Reflector
**Problem:** Vollvermaschung bei vielen BGP-Routern (z. B. 100 Router → 4.950 Sessions).
**Lösung:** Ein Router wird zum **Route-Reflector (RR)** bestimmt. Alle anderen Router (Route-Reflector Clients) bauen nur eine Nachbarschaft zum RR auf. Der RR leitet empfangene BGP-Updates an alle Clients weiter.
- Reduziert die Anzahl der Sessions auf **n - 1**
- Beispiel: 4 Router → statt 6 Sessions (Full Mesh) nur 3 Sessions (Stern-Topologie mit RR)
### 2.12 Administrative Distanz
Die Administrative Distanz (AD) bestimmt, welches Routing-Protokoll bevorzugt wird, wenn **mehrere Protokolle Routen zum gleichen Ziel** anbieten. Niedrigerer Wert = höheres Vertrauen.
|Quelle|AD|
|---|---|
|Connected Interface|0|
|Static Route|1|
|EIGRP Summary|5|
|**External BGP**|**20**|
|Internal EIGRP|90|
|IGRP|100|
|**OSPF**|**110**|
|IS-IS|115|
|RIP|120|
|EGP|140|
|External EIGRP|170|
|**Internal BGP**|**200**|
|Unknown|255|
**Wichtig:** eBGP (AD 20) wird gegenüber OSPF (AD 110) bevorzugt. iBGP (AD 200) verliert aber gegen OSPF – das verhindert Routing-Schleifen innerhalb eines AS.
Die AD hat **lokale Bedeutung** und wird nicht in Routing-Updates übertragen. Eine Umrechnung zwischen den Metriken verschiedener Protokolle ist nicht möglich.
### 2.13 Redistribution (Umverteilung)
Redistribution verbindet verschiedene Routing-Protokolle miteinander, z. B. OSPF-Routen nach BGP weiterleiten und umgekehrt.
- Befehl: `redistribute <Protokoll>` (z. B. `redistribute connected`, `redistribute ospf`)
- **Beide Richtungen müssen konfiguriert werden!** Nur OSPF → BGP ohne BGP → OSPF bedeutet, dass der Rückweg fehlt.
- Findet typischerweise auf dem **ASBR** (Autonomous System Boundary Router) statt
---
## 3. MPLS (Multiprotocol Label Switching)
### 3.1 Überblick und Einsatz
MPLS wird primär in **Service-Provider-Netzen** (Carrier-Netze) eingesetzt. Endkunden (Unternehmen, Privathaushalte) sehen in der Regel keinen MPLS-Verkehr.
**Hauptfunktion:** MPLS bietet Mechanismen für Ethernet- und IP-basierte **Virtual Private Networks (VPNs)** auf Layer 2 und Layer 3. Damit können Provider über eine gemeinsame Infrastruktur isolierte Kundennetze bereitstellen.
### 3.2 Grundkonzept: Labels statt IP-Lookup
Bei klassischem IP-Routing muss **jeder Router** für jedes Paket einen Longest-Prefix-Match in der Routing-Tabelle durchführen. MPLS ersetzt diesen aufwändigen Vorgang durch ein **Label-basiertes Switching:**
1. Die Routing-Entscheidung wird **einmalig am Eintrittspunkt** (Ingress-Router/LER) getroffen
2. Dort wird dem Paket ein **Label** zugewiesen
3. Alle weiteren Router im MPLS-Netz (LSR) leiten das Paket nur noch anhand des Labels weiter – **kein IP-Lookup mehr nötig**
4. Am Austrittspunkt (Egress-Router/LER) wird das Label wieder entfernt
### 3.3 MPLS-Terminologie
|Begriff|Bedeutung|
|---|---|
|**LSR** (Label Switch Router)|Router im MPLS-Kern, der Pakete anhand von Labels weiterleitet|
|**LER** (Label Edge Router)|Router am Rand des MPLS-Netzes (Ingress = Eingang, Egress = Ausgang)|
|**LSP** (Label Switched Path)|Der vordefinierte Pfad, den gelabelte Pakete durch das MPLS-Netz nehmen|
|**FEC** (Forwarding Equivalence Class)|Gruppe von Paketen, die identisch behandelt werden (z. B. alle Pakete zum selben Zielpräfix)|
|**CE** (Customer Edge)|Kundenrouter am Rand des Kundennetzes|
|**PE** (Provider Edge)|Provider-Router am Rand des Provider-Netzes (= LER)|
|**P** (Provider)|Router im Kern des Provider-Netzes (= LSR)|
### 3.4 MPLS im OSI-/TCP-IP-Modell
Das MPLS-Label (der sog. **MPLS Shim Header**) wird **zwischen Layer 2 (Data Link) und Layer 3 (Network)** eingefügt. MPLS wird deshalb oft als „Layer 2.5"-Protokoll bezeichnet.
Die Signalisierung der Labels erfolgt über verschiedene Protokolle auf unterschiedlichen Schichten (LDP auf L7/TCP, RSVP-TE auf L3/IP, BGP auf L7/TCP).
### 3.5 IP vs. MPLS – Gegenüberstellung
|Ebene|IP|MPLS|
|---|---|---|
|**Data Plane**|Routing-Tabelle, Longest-Prefix-Match für jedes Paket|Label Push, Swap, Pop – kein IP-Lookup im Kern|
|**Control Plane**|Routing-Protokolle (OSPF, BGP)|Erweiterte Routing-Protokolle (OSPF-TE, IS-IS-TE), Label-Verteilungsprotokolle (LDP, RSVP-TE), Discovery-Protokolle (BGP)|
MPLS ist in diversen IETF-RFCs standardisiert: https://datatracker.ietf.org/wg/mpls/documents/
### 3.6 MPLS Label Format (RFC 3032)
Das MPLS-Label ist **32 Bit** lang und besteht aus 4 Feldern:
```
|<-------------- 32 Bits ----------------->|
| Label Value (20 Bit) | TC (3 Bit) | S (1 Bit) | TTL (8 Bit) |
```
**Label Value (20 Bit):** Der eigentliche Label-Wert. Ermöglicht 2²⁰ = 1.048.576 verschiedene Labels.
**TC – Traffic Class (3 Bit):** Ehemals „EXP" (Experimental). Wird für MPLS DiffServ (Quality of Service) genutzt, um die Class of Service (CoS) oder Drop Precedence zu speichern. Wenn DiffServ deaktiviert ist, hat das Feld keine Bedeutung.
**S – Bottom of Stack (1 Bit):** Zeigt an, ob dies das **letzte (unterste) Label** im Label Stack ist. S = 1 → letztes Label. S = 0 → weitere Labels folgen darunter.
**TTL – Time To Live (8 Bit):** Verhindert Endlosschleifen, wird wie beim IP-TTL bei jedem Hop dekrementiert.
### 3.7 Reservierte Label-Werte
|Wert|Bezeichnung|Funktion|
|---|---|---|
|0|**Explicit Null (IPv4)**|Signalisiert, dass nach dem Label ein IPv4-Header folgt. Muss am Penultimate Hop entfernt werden.|
|1|**Router Alert**|Paket wird an die lokale Software-Instanz des Routers übergeben|
|2|**Explicit Null (IPv6)**|Wie Label 0, aber für IPv6-Header|
|3|**Implicit Null**|Signalisiert dem vorletzten Router, das Label zu entfernen (Penultimate Hop Popping)|
|4–15|Reserviert|Für zukünftige Nutzung (RFC 3032), davon 13 = GAL (RFC 5586), 14 = OAM Alert (RFC 3429)|
|16–2²⁰|**Normal Labels**|Normaler Label-Swap-Betrieb|
### 3.8 MPLS Label Stack
Ein MPLS-Paket kann **mehrere Labels übereinander gestapelt** tragen (Label Stack). Das ermöglicht LSP-Hierarchien (z. B. Transport-Label + VPN-Label).
**Beispiel eines Label Stacks:**
```
Top Label: Label = 40, TC = 000, S = 0, TTL = 22
Intermediate Label: Label = 3343, TC = 000, S = 0, TTL = 60
Bottom Label: Label = 202, TC = 000, S = 1, TTL = 64 ← S-Bit = 1!
[IP-Paket]
```
Regeln:
- Alle Labels außer dem letzten haben **S = 0**
- Nur das unterste Label hat **S = 1**
- Der LSR prüft das S-Bit, bevor er ein Label entfernt
### 3.9 Label-Operationen
|Operation|Wo|Beschreibung|
|---|---|---|
|**Push**|Ingress LER|Label wird auf das Paket aufgesetzt (Paket betritt MPLS-Netz)|
|**Swap**|LSR (Kern)|Eingehendes Label wird durch ausgehendes Label ersetzt|
|**Pop**|Egress LER|Label wird entfernt, darunter liegt das IP-Paket (oder nächstes Label)|
### 3.10 MPLS Forwarding Matrix (Label Switching)
Jeder LSR pflegt eine **MPLS Forwarding Matrix** mit den Spalten: FEC, In Label, Out Label, Next Hop, Action.
**Ingress LER (Push):** Kein Incoming Label, nur Outgoing Label.
|FEC|In Label|Out Label|Next Hop|Action|
|---|---|---|---|---|
|10.1.1/24|–|20|LSR2|Push|
**Transit LSR (Swap):** Incoming und Outgoing Label.
|FEC|In Label|Out Label|Next Hop|Action|
|---|---|---|---|---|
|10.1.1/24|50|40|LSR4|Swap|
**Egress LER (Pop):** Incoming Label, kein Outgoing Label.
|FEC|In Label|Out Label|Next Hop|Action|
|---|---|---|---|---|
|10.1.1/24|40|–|CE2|Pop/Route|
### 3.11 Label-Zuweisung und -Verteilung
**Bidirektionale Kommunikation:** Für jede Richtung wird ein **separater LSP** aufgebaut. Der Hinweg (Forwarding Path) wird vom Ingress-LER angefragt, der Rückweg (Reverse Path) vom gegenüberliegenden LER. Hin- und Rückweg können **unterschiedliche Pfade** nehmen.
**Ablauf der Label-Verteilung (Beispiel):**
1. CE2 kündigt neues Netz 10.1.1/24 an → LSR4 (Egress) erstellt FEC A
2. LSR4 bindet Label 40 an FEC A und verteilt dieses Binding an seine Nachbarn (LSR3, LSR5)
3. Jeder Downstream-LSR lernt das Binding, erstellt sein eigenes lokales Label und verteilt es weiter (LSR5: Label 50, LSR3: Label 30)
4. Prozess setzt sich fort bis zum Ingress-LER (LSR1), der das Netz 10.1.1/24 nun über den kompletten LSP erreichen kann
### 3.12 Signalisierungsprotokolle
MPLS benötigt Signalisierungsprotokolle, um Labels zu verteilen und LSPs aufzubauen. Es gibt drei Hauptprotokolle:
#### 3.12.1 LDP (Label Distribution Protocol)
- **Einsatz:** Einfache MPLS-Topologien ohne Traffic Engineering oder QoS-Anforderungen. Am weitesten verbreitet für grundlegende Label-Verteilung.
- **OSI-Schicht:** Layer 7 (Anwendungsschicht), nutzt **TCP Port 646**
- **Nachbarschaftserkennung:** Über **Hello-Nachrichten** (UDP, Multicast). Nach Erkennung wird eine TCP-Sitzung aufgebaut.
- **Zuverlässige Übertragung:** Über TCP gesichert
- **Eine Sitzung pro Nachbar**, kein kontinuierlicher Austausch von Statusinformationen
**Zwei Betriebsmodi:**
|Modus|Beschreibung|
|---|---|
|**L-LDP (Link-LDP)**|Sitzung zwischen **direkt benachbarten** Routern (gleicher L2/L3-Link)|
|**T-LDP (Targeted-LDP)**|Sitzung zwischen **nicht direkt benachbarten** Routern (mehrere IP-Hops dazwischen). Sitzung wird über IP-Routing aufgebaut, nicht über physische Verbindung.|
**Label-Verteilung über LDP:**
1. LSR A sendet **Label Request** an LSR B
2. LSR B sendet **Label Mapping** (z. B. Label 37) zurück an LSR A
3. Prozess wiederholt sich Hop für Hop bis zum Egress
**Label Mapping enthält:** Label-Wert, FEC (Forwarding Equivalence Class) und Next Hop.
**LSP-Aufbau:** Topology-Driven – LSPs basieren auf der Netzwerk-Topologie.
#### 3.12.2 RSVP-TE (Resource Reservation Protocol – Traffic Engineering)
- **Einsatz:** Netzwerke mit **Traffic Engineering** und **QoS-Anforderungen**. Große Unternehmens- und SP-Netze. Ermöglicht Reservierung von Ressourcen (Bandbreite) für Echtzeitanwendungen.
- **OSI-Schicht:** Layer 3 (Network), wird über **IP übertragen (Protokollnummer 46)**
- **Standardisiert:** RSVP in RFC 2205/2209 (1997), RSVP-TE-Erweiterungen in RFC 3209
- Signalisierungsnachrichten werden **regelmäßig erneut gesendet**, um Reservierungen aktiv zu halten (Soft State)
- Da RSVP-TE die Traffic-Zuordnung zu einem LSP lokal am Ingress-LSR vornimmt, spricht man bei RSVP-TE-LSPs von **„Tunneln"**
**Pfadaufbau mit RSVP-TE:**
1. **PATH-Nachricht:** Vom Ingress-LSR zum Egress-LSR. Fordert Erstellung eines LSP mit bestimmten QoS-Parametern an. Kann eine **explizite Route (ERO)** vorgeben.
2. **RESV-Nachricht:** Vom Egress zurück zum Ingress (Hop für Hop). Bestätigt erfolgreiche Ressourcenreservierung. Enthält das zugewiesene Label. Der LSP ist aktiv, wenn der Ingress-LSR ein gültiges RESV erhält.
**LSP-Aufbau:** Data-Driven – LSPs werden dynamisch basierend auf aktuellen Datenströmen angepasst.
#### 3.12.3 MP-BGP (Multiprotocol BGP)
- **Einsatz:** MPLS-L3-VPNs, Inter-Domain-Routing zwischen autonomen Systemen. Skaliert über große Netze.
- **OSI-Schicht:** Layer 7 (Anwendungsschicht), nutzt **TCP Port 179**
- Erweiterung des BGP-Protokolls für **IPv4, IPv6 und MPLS**
- **Nachbarschaftsbildung:** Über TCP-Handshake – **keine Hello-Pakete** (anders als OSPF/LDP)
- Tauscht **VPN-Labels** und Kundenstandort-Routen über das MPLS-Netz aus
**Wichtige Attribute und Elemente:**
|Element|Beschreibung|
|---|---|
|**AFI** (Address Family Identifier, 16 Bit)|1 = IPv4, 2 = IPv6, 25 = MPLS (VPNs)|
|**SAFI** (Subsequent AFI, 8 Bit)|1 = Unicast, 128 = VPNv4, 132 = VPNv6|
|**VPN-Label**|Label in den Update-Nachrichten für MPLS-VPNs|
|**Route Distinguisher (RD)**|Wird als Präfix zu IP-Adressen hinzugefügt, um Eindeutigkeit in verschiedenen VPNs sicherzustellen|
### 3.13 Vergleich der Signalisierungsprotokolle
|Eigenschaft|LDP|RSVP-TE|MP-BGP|
|---|---|---|---|
|**Haupteinsatz**|Einfache Label-Verteilung|Traffic Engineering, QoS|MPLS-VPNs, Inter-Domain|
|**Transport**|TCP Port 646|IP Protokoll 46|TCP Port 179|
|**OSI-Schicht**|Layer 7|Layer 3|Layer 7|
|**Nachbarerkennung**|Hello-Nachrichten (UDP)|Über IGP|TCP-Handshake|
|**QoS-Unterstützung**|Nein|Ja (Ressourcenreservierung)|Indirekt (über VPN-Zuordnung)|
|**LSP-Aufbau**|Topology-Driven|Data-Driven|VPN-spezifisch|
### 3.14 Layer 2/3 Services – MPLS-Signalisierung
Für Kunden-VPN-Services werden **zwei Signalisierungsprotokolle** eingesetzt:
- **Targeted-LDP (T-LDP)** – für L2-VPNs (Pseudowires)
- **Multiprotocol-BGP (MP-BGP)** – für L3-VPNs (IP-VPNs)
Beide sind in der Forwarding Plane identisch (gleiche Label-Operationen) und **unabhängig** von der Signalisierung des darunterliegenden Transport-LSPs (der z. B. über RSVP-TE aufgebaut sein kann).
Die Signalisierungssession besteht zwischen den **LERs/PEs** (Provider Edge Routern) – die Transit-Router (P-Router/LSRs) im Kern sind nicht beteiligt.
---
## 4. Ausfallsicherheit in Netzen
### 4.1 Grundprinzipien
Drei Säulen der Ausfallsicherheit:
1. **Fehlererkennung** – Ausfall schnell bemerken
2. **Schnelle Konvergenz** – Routing-Protokolle müssen schnell reagieren
3. **Umschalten auf alternative Wege** – Backup-Pfade müssen vorbereitet sein
Schlüsseltechnologien: **BFD** (Bidirectional Forwarding Detection) und **FRR** (Fast Reroute).
### 4.2 BFD (Bidirectional Forwarding Detection)
BFD ist ein **protokollunabhängiges** Netzwerkprotokoll zur **schnellen Erkennung von Verbindungsausfällen**. Es arbeitet deutlich schneller als die eingebauten Mechanismen von OSPF oder BGP.
**Standardisiert in:**
- **RFC 5880** – Grundlegende BFD-Mechanismen und Protokolle (August 2010)
- **RFC 5881** – BFD für IPv4 und IPv6 (August 2010)
**OSI-Einordnung:**
- **Layer 4 (Transport):** BFD nutzt **UDP Port 3784** für Hello-Pakete
- **Layer 3 (Netzwerk):** BFD interagiert mit IP-Adressen und Routing-Protokollen
**Funktionsweise:**
1. **Heartbeat-Mechanismus:** BFD sendet regelmäßig Hello-Pakete mit sehr kurzen Intervallen (typisch **50 ms**)
2. **Timeout-Mechanismus:** Wenn innerhalb des konfigurierten Timeouts keine BFD-Nachricht empfangen wird, gilt die Verbindung als ausgefallen
3. **Schnelle Reaktion:** Ermöglicht sofortige Aktivierung alternativer Pfade
**Zustandsmaschine:**
|Zustand|Bedeutung|
|---|---|
|**Down**|Verbindung ist nicht aktiv oder nicht erreichbar|
|**Init**|Verbindung hat gerade begonnen, Nachrichten auszutauschen|
|**Up**|Verbindung ist aktiv und funktionsfähig|
Nach einem Timeout wechselt der Zustand auf **Down**.
**Fehlermeldung und Reaktion:**
- BFD **benachrichtigt die Routing-Protokolle** (OSPF, BGP), damit diese Routen aktualisieren oder entfernen
- Bei vorhandener Redundanz: **Automatische Umschaltung** auf Backup-LSP oder alternativen Pfad
- Benutzer bemerken idealerweise **keine Unterbrechung**
**BFD in L2- und L3-MPLS:**
|Kontext|Funktion|
|---|---|
|**L2 MPLS**|Überwacht Verbindung zwischen PE-Routern und CE. Schnelle Erkennung ermöglicht sofortige Nutzung alternativer Pfade.|
|**L3 MPLS**|Überwacht IP-basierte Dienste und Verbindungen zwischen Routern mit OSPF/BGP. Beschleunigt die Konvergenz der Routing-Protokolle.|
**BFD-Anwendungsfälle:**
- **IP Routing Protocols:** Schnellerer Trigger für Rerouting als die IGPs selbst liefern können
- **Multi-Hop BFD:** Überwachung von nicht direkt verbundenen Systemen
- **MPLS LSP und Pseudowire:** Health Monitoring, Trigger für Umschaltung auf Backup-LSP (MPLS FRR) oder Backup-Pseudowire
### 4.3 MPLS Fast Reroute (FRR)
FRR schützt **Transport-LSPs** gegen Verbindungs- oder Knotenausfälle und ermöglicht eine Umschaltung im **unter 50 ms-Bereich** (vergleichbar mit SDH-Netzen).
**Voraussetzungen:**
- Traffic-Engineering-Erweiterungen (TE) für IGPs: **OSPF-TE (RFC 3630)** oder **IS-IS-TE (RFC 5305)** – verteilen zusätzliche Verbindungsinformationen (z. B. verfügbare Bandbreite)
- **RSVP-TE (RFC 3209)** für die LSP-Signalisierung mit Label-Informationen
- **CSPF** (Constrained Shortest Path First) für die Pfadberechnung unter Berücksichtigung von Constraints
**RSVP-TE-Erweiterungen für FRR:**
Zwei **neue Objekte:**
|Objekt|Funktion|
|---|---|
|**FAST_REROUTE**|In der PATH-Nachricht. Steuert den Backup-Pfad: Prioritäten, Sitzungsattribute, Bandbreite. Ermöglicht Anforderung von Link- oder Node-Protection.|
|**DETOUR**|Für One-to-One-Backups. Identifiziert den Detour-LSP mit dem Knotenpaar {PLR, MP}.|
Zwei **erweiterte Objekte:**
|Objekt|Funktion|
|---|---|
|**SESSION_ATTRIBUTE**|Gibt gewünschte Bandbreite und Schutzart an|
|**RRO** (Record Route Object)|Informationen über LSPs am Ausfallpunkt und Aufbau neuer End-to-End-LSPs|
**PLR** = Point of Local Repair (Router, der den Ausfall erkennt und umschaltet) **MP** = Merge Point (Router, an dem der Backup-Pfad wieder auf den ursprünglichen Pfad trifft)
### 4.4 FRR Protection Types
#### One-to-One Backup
Jeder geschützte LSP-Pfad verfügt über einen **eigenen, individuellen Backup-LSP** (Detour).
- **Link Protection:** Backup-Pfad umgeht den ausgefallenen Link
- **Node Protection:** Backup-Pfad umgeht den ausgefallenen Knoten (Router) komplett
Vorteil: Granulare Kontrolle pro LSP. Nachteil: Mehr Signalisierungsaufwand.
#### Facility Backup
Alle geschützten LSPs, die das **gleiche Netzwerksegment** durchlaufen, teilen sich **denselben Bypass-Tunnel**.
- **Link Protection:** Ein gemeinsamer Bypass-Tunnel umgeht den ausgefallenen Link für alle betroffenen LSPs
- **Node Protection:** Ein gemeinsamer Bypass-Tunnel umgeht den ausgefallenen Knoten
Vorteil: Effizienter, weniger Bypass-Tunnel nötig. Nachteil: Weniger granulare Kontrolle.
### 4.5 FRR Recovery Methods
|Methode|Ablauf|
|---|---|
|**Local Repair**|1. PLR erkennt Ausfall und schaltet auf Backup-LSP um. 2. Traffic nutzt weiterhin denselben End-to-End-LSP-Pfad (über den lokalen Umweg). Kein Re-Setup des gesamten LSP.|
|**Global Repair**|1. Zuerst Local Repair (sofortige Umschaltung). 2. PLR sendet **PATH ERROR** an den Ingress-LSR. 3. Ingress-LSR berechnet und signalisiert einen **neuen optimalen End-to-End-LSP**. Der lokale Umweg wird dann durch den neuen optimalen Pfad ersetzt.|
### 4.6 Funktionale Komponenten von FRR (Übersicht)
```
MPLS-TE Fast Reroute besteht aus:
├── Path Signaling: RSVP-TE (RFC 3209)
├── IGP (TE-Erweiterungen):
│ ├── IS-IS TE (RFC 5305)
│ └── OSPF TE (RFC 3630)
├── Path Calculation: CSPF (Constrained SPF)
├── Failure Detection:
│ ├── Loss of Signal (L1)
│ └── BFD (L3/L4)
├── Protection Types:
│ ├── One-to-One Backup
│ └── Facility Backup
└── Revertive Behavior:
├── Local Revertive (zurück zum lokalen Pfad)
└── Global Revertive (neuer optimaler E2E-Pfad)
```
---
## Prüfungsrelevante Kernpunkte
1. **Troubleshooting:** 7-Schritte-Methodik, Bottom-Up/Top-Down/Divide-and-Conquer, wichtigste Show-Befehle je Schicht
2. **BGP:** Path-Vector, TCP Port 179, 4 Nachrichtentypen (OPEN, UPDATE, NOTIFICATION, KEEPALIVE), 9-stufige Wegewahl (LOCAL_PREF → AS_PATH → MED), Transit vs. Peering, Tier 1/2/3, iBGP vs. eBGP, Route-Reflector, Administrative Distanz
3. **MPLS:** Label-Format (32 Bit: Label/TC/S/TTL), Push/Swap/Pop, FEC, LSP, reservierte Labels (0–3), Label Stack mit S-Bit, Forwarding Matrix
4. **MPLS-Signalisierung:** LDP (TCP 646, L7), RSVP-TE (IP Prot. 46, L3, PATH/RESV), MP-BGP (TCP 179, L7, AFI/SAFI/RD), Link-LDP vs. Targeted-LDP
5. **Ausfallsicherheit:** BFD (UDP 3784, Zustände Down/Init/Up, Heartbeat 50ms), FRR (unter 50ms Umschaltung), One-to-One vs. Facility Backup, Link vs. Node Protection, Local vs. Global Repair

404
Netzwerke/zusammenfassungen/nw7 - zusammenfassung.md Normal file
View file

@ -0,0 +1,404 @@
# IT2221 Netzwerktechnik – Vorlesung 7: MPLS VPNs & Segment Routing
> **Dozentin:** Gabriele Schrenk | **Datum:** 01.04.2026
> **Klausur:** Mo., 4. Mai 2026, 14:00–16:00 Uhr, Räume 6B.369 und 6B.371
---
## 0. Fehlerszenarien nächste Woche Labor
- PC bekommt keine IP Adresse
- PC erreicht einen bestimmten anderen PC nicht
- Mögliche Fehler:
- OSPF-Nachbarschaft/Routing
- BGP Redistribution
- Interfaces falsch eingestellt (MTU Size, Adressen....)
- Und verschiedene andere Fehler
<img src="Troubleshooting_Netz.png"
alt="Troubleshooting_Netz"
style="float: left; margin-right: 10px;" />
## 1. Troubleshooting Methodology
Strukturiertes Vorgehen bei Netzwerkproblemen (z.B. PC bekommt keine IP, PC erreicht anderes Gerät nicht):
1. **Problem definieren** – Was genau funktioniert nicht?
2. **Informationen sammeln** – `show`-Befehle ausführen
3. **Daten analysieren** – Routingtabellen, Nachbarzustände prüfen
4. **Hypothese formulieren** – Welche OSI-Schicht ist betroffen?
5. **Hypothese testen** – Paketmitschnitte (PCAPs) auswerten
6. **Korrektur implementieren**
7. **Überprüfen & dokumentieren**
Typische Fehlerquellen im Labor: OSPF-Nachbarschaft, BGP-Redistribution, falsche MTU/Adressen an Interfaces.
---
## 2. VPNs über MPLS – Grundidee
**Ziel:** Mehrere Unternehmensstandorte über einen gemeinsamen Provider-Backbone verbinden, dabei aber voneinander isoliert halten.
**Anforderungen (Wunschliste):**
- Nutzung des bestehenden SP-Backbones
- Überlappende Adressräume erlaubt (verschiedene Kunden dürfen gleiche IPs nutzen)
- Datentrennung zwischen VPNs
- Skalierung, QoS, einfache Verwaltung
---
## 3. VPN-Klassifizierung (RFC 4026 – PPVPN)
```
PPVPN
├── Layer 2
│ ├── P2P → VPWS (Virtual Private Wire Service)
│ └── M2M → VPLS (Virtual Private LAN Service)
└── Layer 3
├── PE-based
│ ├── BGP/MPLS IP VPNs
│ └── Virtual Router
└── CE-based
└── IPsec
```
---
## 4. Grundbegriffe: AC, Pseudowire, Tunnel LSP
### Attachment Circuit (AC)
Physischer oder logischer Anschluss zwischen Kundengerät (**CE**) und Provider-Edge-Router (**PE**). Kann sein: Ethernet-Port, VLAN, PPP, MPLS LSP, etc.
```
[CE-Gerät] ---AC--- [PE-Gerät] --- Service Provider Network
```
### Pseudowire (PW)
Ein virtueller „Draht" durch das Provider-Netz, der L2-Daten von einem AC zu einem anderen transportiert.
- Nur den beiden **Endpunkt-PEs** bekannt
- Wird über einen **Tunnel (LSP)** transportiert, der allen Routern (LSRs) dazwischen bekannt ist
- Pro Richtung ein unidirektionaler Tunnel → ein PW = 2 LSPs
### Tunnel LSP – Label Stacking
Mehrere Pseudowires zwischen zwei PEs werden in einem Tunnel aggregiert:
- **Äußeres Label** = Tunnel LSP (für P-Router sichtbar, sorgt für Transport)
- **Inneres Label** = Pseudowire LSP (nur PEs kennen es)
> P-Router schauen **nur auf das äußere Label** und leiten entsprechend weiter – sie kennen die VPN-Details nicht.
---
## 5. Layer-2-Dienste: VPWS und VPLS
### VPWS – Virtual Private Wire Service
- **Point-to-Point**: genau ein AC ↔ genau ein PW
- Transparente L2-Verbindung zwischen zwei Standorten
- MPLS definiert Labelverteilung und Kapselung
- Einsatz von **LDP (Targeted Mode)** oder **MP-BGP** zur Signalisierung
**Forwarding-Beispiel (VPWS):**
Ein PE empfängt einen VLAN1-Frame vom Kunden. Er schlägt in seiner FEC-Tabelle nach und findet: `VLAN1 → Out-Label 24, Next-Hop 1.1.1.1`. Zusätzlich drückt er ein Transport-Label (z.B. 16) obendrauf. Der Transit-Router (LSR) sieht nur das Transport-Label und leitet weiter. Der Egress-PE entfernt das äußere Label, erkennt anhand des inneren Labels (24) die Ziel-Schnittstelle und sendet den Frame an den Kunden.
**VPWS Protection – Auslöser für Umschaltung auf Standby-PW:**
- Manueller Eingriff (Precedence-Wert ändern)
- Statusänderung des PW
- Ausfall des aktiven PW
- Benachrichtigung vom Remote-Peer (via T-LDP Notification Message)
---
### VPLS – Virtual Private LAN Service
- **Multipoint-to-Multipoint**: mehrere Standorte agieren wie in einem gemeinsamen Ethernet-LAN
- Jeder PE enthält ein **Switch-Modul** mit einem emulierten LAN (MAC-Learning, Flooding)
- Standorte tauschen Ethernet-Frames direkt aus, als wären sie physisch im selben LAN
**Architektur:**
```
[Kunde CE] --AC--> [PE: VPLS Forwarder + Emulated LAN Interface]
<------ VPLS PW ------>
[PE] --AC--> [Kunde CE]
```
**Skalierungsproblem:** Bei N Standorten braucht man **N*(N-1)/2 Pseudowires** (Vollvermaschung). Bei vielen Standorten entstehen viele States und viel Broadcast-Traffic.
**Lösung: Hierarchisches VPLS (H-VPLS)**
PE-Router werden in zwei Ebenen aufgeteilt:
| Ebene | Gerät | Aufgabe |
|-------|-------|---------|
| Kern | **Hub-PE** | Vollvermaschung zwischen Hubs |
| Rand | **Spoke-PE / MTU-s** | Aggregiert Kundenports zu einer einzigen Spoke-PW zum Hub |
- Neue Verbindung nur zwischen Spoke und Hub, kein direktes Mesh zwischen allen Spokes
- **Vorteile:** Weniger PWs, weniger Broadcast-Replikation, bessere Skalierbarkeit
**Multi-Tenant Unit (MTU-s):** Gerät (Router, Switch oder Gateway), das viele Kundenports aggregiert und eine einzige Spoke-PW zum nächsten PE aufbaut.
**Dual Homed MTUs:** MTU ist an zwei PEs angebunden → Redundanz bei Ausfall einer Verbindung.
**VPLS Auto-Discovery (RFC 4761):** PE-Router erkennen automatisch andere PEs derselben VPLS-Domäne via MP-BGP, ohne manuelle Konfiguration jedes einzelnen Pseudowires.
**VPLS Protection:** Backup-LSPs werden über T-LDP aufgebaut; Überwachung via BFD (Bidirectional Forwarding Detection).
**VPLS und MTU-Größen:**
| Pakettyp | L2 MTU |
|----------|--------|
| Normales MPLS-Paket | 1504 |
| Ethernet over VPLS | 1508 |
| VLAN over VPLS | 1526 |
> VPLS fügt zusätzliche Header ein (MPLS-Label + VPLS-Label), was die MTU erhöht. Alle Geräte im Pfad müssen diese größeren Frames unterstützen.
---
## 6. Layer-3-VPNs: BGP/MPLS IP VPNs (RFC 4364)
### Motivation
- Kunden nutzen **private IP-Adressen** (RFC 1918) → können sich überschneiden
- Provider übernimmt das Routing → Kunde muss sich nicht darum kümmern
- MPLS-Backbone ist für den Kunden **transparent**
### Beteiligte Geräte
| Gerät | Aufgabe |
|-------|---------|
| **CE** (Customer Edge) | Kundenrouter, kennt nur seine eigene Seite |
| **PE** (Provider Edge) | Kennt VPN-Routen; verwaltet VRFs; stellt MPLS-Pfade auf |
| **P** (Provider Core) | Reine Transitknoten; kennen keine VPNs, nur MPLS-Labels |
### VRF – VPN Routing and Forwarding Table
Jeder PE führt **separate Routing-Tabellen pro Kunde** (VRF). Diese werden via **MP-BGP** zwischen den PEs ausgetauscht.
**Problem:** BGP kann normalerweise nur eine Route pro IP-Präfix installieren – aber verschiedene Kunden können dieselben Adressen haben.
**Lösung: Route Distinguisher (RD)**
---
### Route Distinguisher (RD)
Ein **8-Byte-Präfix**, der jeder VPN-Route vorangestellt wird, um sie global eindeutig zu machen:
```
[Type 2B] [Administrator 2-4B] [Assigned Number 2-4B] + [IPv4-Adresse 8B] = 12 Bytes
```
**Beispiele:**
```
RD: 65000:101 (AS-Nummer : zugewiesene Nummer)
RD: 10.0.0.1:1001 (IP-Adresse : zugewiesene Nummer)
RD: 1000000:10
```
**Ergebnis:** Aus `192.168.1.10` wird die **VPNv4-Adresse** `65000:1:192.168.1.10` → global eindeutig, kein Konflikt trotz Adressüberlappung.
> **Wichtig:** Der RD macht Adressen nur **eindeutig**. Er steuert *nicht*, welche Routen wohin verteilt werden – das macht der Route Target.
---
### Route Target (RT)
Ein **BGP Extended Community Attribut** (RFC 4360), das steuert, welche Routen in welches VRF importiert/exportiert werden.
Jede VRF hat:
- **Export Target**: welcher RT wird angefügt, wenn eine Route exportiert wird
- **Import Target**: welche eingehenden Routen werden in diese VRF installiert
**Ablauf – 3-Schritt-Beispiel:**
**Schritt 1 – Export:**
PE an VPN1-Site1 empfängt eine IPv4-Route vom CE. Er konvertiert sie zu VPN-IPv4 und hängt RT1 und RT4 an (laut Export-Policy: `VRF VPN1 Export = RT1, RT4`). Die Route wird an alle PEs verteilt.
**Schritt 2 – Import rechts:**
Der rechte PE empfängt die Route mit RT1 und RT4 und vergleicht sie mit seinen VRF-Import-Listen:
| VRF | Import-Liste | RT1 Match? | RT4 Match? | Ergebnis |
|-----|-------------|------------|------------|----------|
| VPN1 | RT1, RT4 | ✓ | ✓ | Route installiert → weiter zu Sites 4, 5 |
| VPN2 | RT1, RT2 | ✓ | – | Route installiert → weiter zu Site 3 |
**Schritt 3 – Import links:**
Der linke PE vergleicht ebenfalls:
| VRF | Import-Liste | Ergebnis |
|-----|-------------|----------|
| VPN2 | RT1, RT2 | RT1 matcht → Route zu Site 2 |
| VPN3 | RT3 | kein Match → Route ignoriert |
> **Merkhilfe:** RD = macht Adressen **eindeutig**. RT = steuert **Routenverteilung** (wer darf was sehen).
---
### Site of Origin (SoO)
Optionales Attribut, das die CE-PE-Verbindung identifiziert. Verhindert **Routing-Schleifen** bei Multi-Homed CEs (CE an mehrere PEs angebunden).
---
### Datenweiterleitnung: Label Stacking
```
CE1 ---> PE1 ---> P1 ---> P2 ---> PE2 ---> CE2
```
**Schritt 1 – PE1 (Ingress):**
Empfängt normales IP-Paket von CE1, sucht in der VRF (Longest Prefix Match), findet iBGP-Next-Hop PE2 und drückt **zwei Labels** auf das Paket:
```
[ Transport-Label | VPN-Label | IP-Paket ]
```
- **VPN-Label** (innen): identifiziert die Ziel-VRF bei PE2
- **Transport-Label** (außen): für den Weg durch den Core zu PE2
**Schritt 2 – P-Router:**
Leiten nur anhand des **Transport-Labels** weiter – kein VPN-Wissen nötig.
**Schritt 3 – PE2 (Egress):**
Entfernt das Transport-Label, liest das VPN-Label, findet die richtige VRF, leitet das IP-Paket an CE2 weiter.
### Penultimate Hop Popping (PHP)
**Optimierung:** Der **vorletzte Router (P2)** entfernt bereits das Transport-Label, sodass PE2 nur noch das VPN-Label sieht und nur **einen einzigen Lookup** machen muss statt zwei. PE2 hat dies vorher via LDP beim vorherigen Hop angefordert.
```
PE1 P1 P2 PE2
[TL|VL|IP] --> [TL|VL|IP] --> [VL|IP] --> [IP]
^ PHP: TL wird hier entfernt
```
---
### Inter-AS VPN
Wenn VPN-Standorte über mehrere Autonomous Systems (verschiedene Provider) verbunden sind:
| Option | Beschreibung | Label-Austausch |
|--------|-------------|-----------------|
| **A** | ASBRs führen VRFs; behandeln sich gegenseitig als CE | Kein Label-Austausch zwischen ASBRs |
| **B** | ASBRs tauschen VPN-Routen via MP-eBGP aus | MP-eBGP + Label zwischen ASBRs |
| **C** | Nur PE-Loopback-Adressen und Label-Bindings via eBGP; PEs kommunizieren direkt | eBGP + Label für Transport; MP-iBGP PE ↔ ASBR |
---
### BGP/MPLS L3 VPN – Vor- und Nachteile
| Vorteile | Nachteile |
|----------|-----------|
| Skalierbare VPN-Architektur | Komplex für Provider zu betreiben |
| SP oder Kunde kann VPN verwalten | Kunde hat keine vollständige WAN-Routing-Kontrolle |
| Vereinfachtes WAN-Routing für Kunden | Nur IP-Verkehr unterstützt |
| QoS/SLA pro VPN möglich (mit MPLS TE) | BGP konvergiert langsam (Abhilfe: BFD) |
| Hohe Verfügbarkeit via MPLS FRR | |
---
## 7. Segment Routing (SR)
### Grundprinzip: Source Routing
Beim klassischen MPLS berechnet jeder Router Hop-by-Hop den Weg. Bei **Segment Routing** legt der **Ingress-Router** (erster Router) den gesamten Pfad fest und codiert ihn als **geordnete Liste von Segmenten** im Paket.
**Segment:** Eine Anweisung für den Router, z.B. „Sende zu Knoten X über den kürzesten Pfad". Segmente werden als **SIDs (Segment Identifiers)** dargestellt.
SR ist **Data Plane Agnostic**: funktioniert über MPLS oder IPv6, kombiniert mit IGP (IS-IS, OSPF) oder BGP.
---
### Vergleich Classic MPLS vs. Segment Routing
| | Classic MPLS | Segment Routing |
|--|--|--|
| **Pfadaufbau** | LDP / RSVP-TE (separates Protokoll) | IGP/BGP (integriert) |
| **Control Plane** | Komplex (IGP + LDP + RSVP-TE) | Vereinfacht (nur IGP/BGP) |
| **State im Core** | Pro LSP/Flow | Nur am Ingress |
| **Traffic Engineering** | Manuelle TE-LSPs via RSVP-TE | Automatisch über Segmentlisten |
---
### IGP Segment-Typen
#### Node/Prefix SID (global)
- **Global gültig** in der gesamten SR-Domäne – jeder Router versteht dieselbe SID gleich
- Pakete werden zum Zielknoten über den **kürzesten IGP-Pfad** weitergeleitet (normales SPF-Routing)
- Wird als **Index** angekündigt → tatsächliches Label = SRGB-Basiswert + Index
```
Beispiel:
SRGB = 16000–23999
Node-SID Index = 41
→ Verwendetes MPLS-Label = 16041
```
#### Adjacency SID (lokal)
- Nur auf dem **vergebenden Knoten lokal gültig** – andere Router verwenden diese SID nicht
- Leitet das Paket **explizit über eine bestimmte Nachbarverbindung** weiter (echtes Source Routing)
- Wird als **absoluter Wert** angekündigt (kein Index, direkt das Label)
```
Beispiel:
Adjacency SID = 9107
→ Paket wird zwingend über genau diesen Link weitergeleitet
```
---
### SR Vorteile
**Control Plane Vereinfachung:**
- Weniger Protokolle, weniger Abhängigkeiten
- Automatischer Traffic-Schutz ohne per-Flow-Signalisierung
**Traffic Engineering:**
- Kein manuelles Konfigurieren von TE-LSPs nötig
- Pfade werden automatisch berechnet oder von einem Controller (z.B. via PCEP) vorgegeben
- Kein State pro Flow im Kernnetz
**Software-Defined Networking:**
- Hybrider Ansatz zwischen zentralisierter und verteilter Control Plane
- Controller kann Pfade/Policies über Southbound-Schnittstellen (z.B. PCEP) vorgeben
- Keine komplette Neukonstruktion des Netzes nötig
---
### IETF Standards für Segment Routing
| Standard | Beschreibung |
|----------|-------------|
| RFC 8402 | SR Architektur |
| RFC 9256 | SR Use Cases |
| RFC 8660 | SR über MPLS (SR-MPLS) |
| RFC 9886 | SR über IPv6 (SRv6) |
Relevante IETF Working Groups: SPRING, PCE, IDR, 6MAN
---
## Prüfungsinfo
| | |
|--|--|
| **Termin** | Mo., 4. Mai 2026, 14:00–16:00 Uhr |
| **Räume** | 6B.369 (inkl. Nachteilsausgleich) und 6B.371 |
| **Betreuer** | Schrenk und Albaradie |
| **Format** | Klausur (keine praktische Prüfung, außer IT25-Jahrgang) |
| **IT25** | Kombinierte Prüfung: Klausur (K) + Laborausarbeitung (L) |