docs: add obsidian hwr docs

Netzwerke/zusammenfassungen/nw7 - zusammenfassung.md

@@ -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) |