docs: add obsidian hwr docs

Netzwerke/klausur/nw6 - klausurstuff.md

@@ -0,0 +1,496 @@
+# IT2221 – Prüfungsvorbereitung: Kernthemen mit Erklärungen & Beispielen
+
+---
+
+## 1. Troubleshooting
+
+### Die 7-Schritte-Methodik
+
+| Schritt | Was tun? |
+|---------|----------|
+| 1 | **Problem definieren** – Was genau geht nicht? Seit wann? Wer ist betroffen? |
+| 2 | **Informationen sammeln** – Show-Befehle, Logs, Topology prüfen |
+| 3 | **Daten analysieren** – Routingtabellen, Nachbarzustände vergleichen |
+| 4 | **Hypothese formulieren** – Welche OSI-Schicht ist schuld? |
+| 5 | **Hypothese testen** – PCAPs, Ping, Traceroute |
+| 6 | **Korrektur implementieren** |
+| 7 | **Verifizieren & dokumentieren** |
+
+---
+
+### Vorgehensstrategien
+
+**Bottom-Up** – Fange bei Layer 1 an, arbeite dich hoch:
+> Kabel ok? → Link up? → IP ok? → Routing ok? → App ok?
+> Gut wenn: Das Problem unbekannt ist und man systematisch vorgehen will.
+
+**Top-Down** – Fange bei Layer 7 an, arbeite dich runter:
+> App geht nicht? → DNS ok? → TCP-Verbindung ok? → Route ok? → Link ok?
+> Gut wenn: Der User ein konkretes App-Problem meldet.
+
+**Divide & Conquer** – Fang in der Mitte an (z.B. Layer 3) und entscheide dann ob du rauf oder runter gehst:
+> Ping zum nächsten Router ok? → Problem ist oben (L4–L7). Ping nicht ok? → Problem ist unten (L1–L2).
+> Gut wenn: Das Netz groß ist und du Zeit sparen willst.
+
+---
+
+### Wichtigste Show-Befehle je Schicht
+
+| OSI-Schicht | Befehl | Was zeigt er? |
+|-------------|--------|---------------|
+| L1 (Physical) | `show interfaces` | Link up/down, Fehler, Kabelfehler |
+| L2 (Data Link) | `show mac address-table` | MAC-Tabelle des Switches |
+| L2 (Data Link) | `show spanning-tree` | STP-Zustand |
+| L3 (Network) | `show ip route` | Routingtabelle |
+| L3 (Network) | `show ip ospf neighbor` | OSPF-Nachbarn und deren Zustand |
+| L3 (Network) | `show bgp summary` | BGP-Nachbarn, Status, Routen |
+| L3 MPLS | `show mpls forwarding-table` | MPLS Label-Tabelle (FIB) |
+| L3 MPLS | `show mpls ldp neighbor` | LDP-Nachbarn |
+| L4 (Transport) | `show ip sockets` | Offene TCP/UDP-Verbindungen |
+
+**Beispiel-Szenario:** PC bekommt keine IP-Adresse.
+
+```
+Schritt 1: Problem klar → DHCP funktioniert nicht
+Schritt 2: show ip interface brief → Interface up?
+           show ip dhcp pool       → DHCP-Pool konfiguriert?
+           show ip dhcp binding    → Gibt es Zuweisungen?
+Schritt 3: Kein Pool vorhanden → Hypothese: DHCP falsch konfiguriert
+Schritt 4: ip dhcp pool MEIN_POOL konfiguriert? Nein!
+Schritt 5: Pool anlegen, PC neu verbinden → IP erhalten ✓
+Schritt 7: Dokumentieren
+```
+
+---
+
+## 2. BGP – Border Gateway Protocol
+
+### Grundidee: Path-Vector
+
+BGP ist ein **Path-Vector-Protokoll**. Das bedeutet: BGP teilt nicht nur mit „ich kann Netz X erreichen", sondern auch **über welchen Weg** (AS-Pfad). So können Schleifen erkannt werden – wenn meine eigene AS-Nummer im Pfad steht, nehme ich die Route nicht an.
+
+**Verbindung:** BGP läuft über **TCP Port 179** (zuverlässige Übertragung, kein eigenes Reliability-Protokoll nötig).
+
+---
+
+### Die 4 Nachrichtentypen
+
+| Typ | Wann? | Was macht er? |
+|-----|-------|---------------|
+| **OPEN** | Beim Verbindungsaufbau | Stellt sich vor: AS-Nummer, BGP-Version, Router-ID, Hold-Time |
+| **UPDATE** | Wenn sich Routen ändern | Teilt neue Routen mit oder zieht alte zurück |
+| **KEEPALIVE** | Alle ~60 Sekunden | „Ich lebe noch" – verhindert Timeout |
+| **NOTIFICATION** | Bei Fehlern | Meldet Fehler und bricht die Session ab |
+
+**Beispiel OPEN:**
+```
+Router A öffnet TCP-Verbindung zu Router B auf Port 179.
+Schickt OPEN: „Ich bin AS 65000, meine Router-ID ist 1.1.1.1, Hold-Time 90s"
+Router B antwortet mit eigenem OPEN + KEEPALIVE → Session steht.
+```
+
+---
+
+### 9-stufige Wegewahl (vereinfacht auf die wichtigsten)
+
+Wenn BGP mehrere Routen zum gleichen Ziel kennt, wählt er nach dieser Reihenfolge:
+
+| Priorität | Attribut | Merkhilfe |
+|-----------|----------|-----------|
+| 1 | **LOCAL_PREF** (höher = besser) | „Welchen Ausgang bevorzuge ich?" |
+| 2 | **AS_PATH** (kürzer = besser) | „Welcher Weg hat weniger Hops?" |
+| 3 | **MED** (niedriger = besser) | „Welchen Eingang bevorzugt mein Nachbar?" |
+| ... | weitere Kriterien | Router-ID, Neighbor-IP, etc. |
+
+**Beispiel:**
+```
+Router A kennt zwei Wege zu 8.8.8.0/24:
+
+Weg 1: LOCAL_PREF=200, AS_PATH: 65001 65002
+Weg 2: LOCAL_PREF=100, AS_PATH: 65003
+
+→ Weg 1 gewinnt, weil LOCAL_PREF höher (200 > 100).
+  AS_PATH wird gar nicht mehr verglichen.
+```
+
+---
+
+### Transit vs. Peering
+
+**Peering:** Zwei Provider tauschen gegenseitig ihre eigenen Routen aus – kostenlos, aber nur das eigene Netz, keine Weiterleitung fremder Pakete.
+
+```
+Telekom ←→ Vodafone: „Ich leite deine Kunden-Pakete weiter, du meine."
+Aber: Telekom leitet keine Pakete von Vodafone an einen dritten Provider weiter.
+```
+
+**Transit:** Ein Provider kauft beim anderen die Weiterleitung aller Pakete – auch zu Dritten. Kostet Geld.
+
+```
+Kleiner ISP → bezahlt Telekom → Telekom leitet Pakete ans gesamte Internet weiter.
+```
+
+---
+
+### Tier 1 / Tier 2 / Tier 3
+
+| Tier | Wer? | Beispiel |
+|------|------|---------|
+| **Tier 1** | Große Provider, die das Internet-Backbone bilden. Haben Peering mit allen anderen Tier-1. Kaufen keinen Transit. | Deutsche Telekom, AT&T, Level3 |
+| **Tier 2** | Mittelgroße Provider. Haben Peering mit manchen, kaufen Transit von Tier-1. | Regionaler ISP |
+| **Tier 3** | Kleine Provider, kaufen Transit von Tier-2. Kein eigenes Peering. | Dein lokaler Kabel-Anbieter |
+
+---
+
+### iBGP vs. eBGP
+
+| | iBGP | eBGP |
+|--|------|------|
+| **Wo?** | Innerhalb eines AS | Zwischen verschiedenen AS |
+| **TTL** | 255 (muss nicht direkt verbunden sein) | 1 (muss direkt verbunden sein) |
+| **Routen weitergeben?** | iBGP-Routen werden **nicht** an andere iBGP-Nachbarn weitergegeben | eBGP-Routen werden weitergegeben |
+| **Problem iBGP** | Alle iBGP-Router müssen sich kennen (Full Mesh) → bei n Routern: n*(n-1)/2 Sessions |
+
+**Warum darf iBGP keine Routen an iBGP-Nachbarn weitergeben?**
+→ Schleifenvermeidung! iBGP hat kein AS_PATH innerhalb eines AS, daher könnte eine Route endlos weitergegeben werden.
+
+---
+
+### Route Reflector
+
+**Problem:** Bei 10 iBGP-Routern braucht man 45 Sessions. Bei 100 Routern: 4950. Nicht skalierbar.
+
+**Lösung:** Ein Router wird zum **Route Reflector (RR)**. Er darf iBGP-Routen an andere iBGP-Nachbarn weitergeben – aber nur, wenn er als RR konfiguriert ist.
+
+```
+Ohne RR (Full Mesh, 4 Router):
+A ←→ B, A ←→ C, A ←→ D, B ←→ C, B ←→ D, C ←→ D → 6 Sessions
+
+Mit RR (A ist Route Reflector):
+B → A → C
+B → A → D
+C → A → D    → nur 3 Sessions nötig
+```
+
+---
+
+### Administrative Distanz (AD)
+
+Wenn eine Route sowohl von BGP als auch von z.B. OSPF gelernt wird, entscheidet die AD welche genommen wird (niedrigere AD = bevorzugt):
+
+| Protokoll | AD |
+|-----------|----|
+| Connected | 0 |
+| Static | 1 |
+| OSPF | 110 |
+| iBGP | 200 |
+| eBGP | 20 |
+
+> eBGP (AD 20) wird fast immer gegenüber anderen Protokollen bevorzugt. iBGP (AD 200) fast nie.
+
+---
+
+## 3. MPLS – Label-Format und Forwarding
+
+### Das Label-Format (32 Bit)
+
+```
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                Label (20 Bit)                 | TC  |S|  TTL  |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+```
+
+| Feld | Bits | Bedeutung |
+|------|------|-----------|
+| **Label** | 20 | Der eigentliche Label-Wert (0 – 1.048.575) |
+| **TC** | 3 | Traffic Class – früher „EXP", für QoS/Priorisierung |
+| **S** | 1 | Bottom-of-Stack – ist dies das unterste Label im Stack? |
+| **TTL** | 8 | Time to Live – verhindert Schleifen |
+
+---
+
+### Reservierte Labels (0–15)
+
+| Label | Name | Bedeutung |
+|-------|------|-----------|
+| **0** | IPv4 Explicit Null | Pop Label, dann normales IPv4-Forwarding |
+| **1** | Router Alert | Paket soll speziell behandelt werden |
+| **2** | IPv6 Explicit Null | Pop Label, dann normales IPv6-Forwarding |
+| **3** | Implicit Null | PHP – vorletzter Router soll Label entfernen |
+| 4–15 | Reserviert | Noch nicht vergeben |
+
+---
+
+### Push / Swap / Pop
+
+| Operation | Wer macht es? | Was passiert? |
+|-----------|--------------|---------------|
+| **PUSH** | Ingress-Router (erster LER) | Label wird auf das Paket gedrückt |
+| **SWAP** | Transit-Router (LSR) | Altes Label wird durch neues ersetzt |
+| **POP** | Egress-Router (letzter LER) oder vorletzter (PHP) | Label wird entfernt |
+
+**Beispiel:**
+
+```
+Paket kommt an Router A (IP: 10.2.0.1):
+
+Router A (PUSH):  [IP-Paket] → [Label 200][IP-Paket]
+Router B (SWAP):  [Label 200] → [Label 350]  (tauscht aus, leitet weiter)
+Router C (POP):   [Label 350] → [IP-Paket]  (entfernt, liefert aus)
+```
+
+---
+
+### FEC – Forwarding Equivalence Class
+
+Eine FEC ist eine **Gruppe von Paketen, die gleich behandelt werden** – gleicher Label, gleicher Weg, gleiche Behandlung.
+
+**Beispiel:**
+```
+Alle Pakete mit Ziel 192.168.10.0/24 → FEC „Richtung Standort Berlin"
+→ alle bekommen Label 200, alle gehen über den gleichen Pfad
+```
+
+Pakete werden am Ingress-Router in FECs eingeteilt – danach nur noch Label-Switching, keine IP-Entscheidungen mehr.
+
+---
+
+### LSP – Label Switched Path
+
+Der vorher festgelegte **Pfad durch das MPLS-Netz** von Ingress bis Egress. Wie eine Schiene.
+
+```
+CE1 → [PE1: Label 200 PUSH] → [P1: Label SWAP] → [P2: Label SWAP] → [PE2: POP] → CE2
+       ←————————————————— LSP ————————————————————→
+```
+
+---
+
+### Label Stack und S-Bit
+
+Labels können gestapelt werden (z.B. VPN-Label + Transport-Label). Das **S-Bit** zeigt an, ob ein Label das unterste im Stack ist:
+
+```
+[ Transport-Label S=0 ]   ← nicht unterstes Label
+[ VPN-Label       S=1 ]   ← unterstes Label (Bottom of Stack)
+[ IP-Paket              ]
+```
+
+Router schauen immer nur auf das **oberste Label**. Erst wenn S=1 ist wissen sie: nach dem Pop kommt direkt das IP-Paket.
+
+---
+
+### Forwarding Matrix (LFIB)
+
+Die Tabelle, die jeder MPLS-Router führt:
+
+```
+Eingehendes Label | Operation | Ausgehendes Label | Next Hop
+------------------|-----------|--------------------|----------
+200               | SWAP      | 350                | 10.0.0.2
+350               | POP       | -                  | 10.0.0.5
+-                 | PUSH 200  | 200                | 10.0.0.1  (für FEC 192.168.10.0/24)
+```
+
+---
+
+## 4. MPLS-Signalisierung
+
+Drei Protokolle verteilen die Labels – je nach Anwendungsfall:
+
+### LDP – Label Distribution Protocol
+
+- **Port:** TCP 646
+- **Schicht:** L7 (Application)
+- **Zweck:** Automatische Label-Verteilung für normales MPLS-Forwarding
+
+**Wie funktioniert es?**
+
+```
+Router C sagt zu B (via LDP): „Für FEC 10.2.0.0/24 → gib mir Label 42"
+Router B sagt zu A (via LDP): „Für FEC 10.2.0.0/24 → gib mir Label 17"
+→ LSP ist aufgebaut, Pakete können fließen.
+```
+
+**Link-LDP vs. Targeted-LDP:**
+
+| | Link-LDP | Targeted-LDP |
+|--|---------|--------------|
+| **Nachbarn** | Nur direkt verbundene Router | Auch nicht-direkt verbundene Router |
+| **Einsatz** | Normales MPLS | Pseudowires (VPWS, VPLS) |
+| **Discovery** | Multicast Hello | Unicast Hello |
+
+---
+
+### RSVP-TE – Resource Reservation Protocol – Traffic Engineering
+
+- **Protokoll:** IP Protokoll 46
+- **Schicht:** L3 (Network)
+- **Zweck:** LSPs mit Bandbreitenreservierung und expliziten Pfaden (Traffic Engineering)
+
+**Zwei Nachrichten:**
+
+| Nachricht | Richtung | Zweck |
+|-----------|----------|-------|
+| **PATH** | Ingress → Egress | „Ich will einen LSP aufbauen, reserviere Ressourcen" |
+| **RESV** | Egress → Ingress | „Ok, Ressourcen reserviert, hier ist dein Label" |
+
+**Beispiel:**
+
+```
+PE1 schickt PATH-Nachricht: „Ich will 100 Mbit/s von PE1 nach PE2, über P1 und P2"
+PATH wandert: PE1 → P1 → P2 → PE2
+PE2 antwortet mit RESV: „Ok, Label 500 zugeteilt"
+RESV wandert zurück: PE2 → P2 → P1 → PE1
+→ LSP steht, Bandbreite ist reserviert.
+```
+
+> **Unterschied zu LDP:** LDP nimmt den kürzesten IGP-Pfad. RSVP-TE kann **explizite Pfade** erzwingen und **Bandbreite reservieren** – daher für Traffic Engineering geeignet.
+
+---
+
+### MP-BGP – Multiprotocol BGP
+
+- **Port:** TCP 179
+- **Schicht:** L7 (Application)
+- **Zweck:** Labels und VPN-Routen verteilen (für L3 VPNs, VPLS Auto-Discovery)
+
+**Erweiterungen gegenüber normalem BGP:**
+
+| Feld | Bedeutung |
+|------|-----------|
+| **AFI** (Address Family Identifier) | Welche Adressfamilie? (IPv4=1, IPv6=2, L2VPN=25) |
+| **SAFI** (Subsequent AFI) | Welcher Subtyp? (Unicast=1, VPN=128, EVPN=70) |
+| **RD** (Route Distinguisher) | Macht VPN-Routen global eindeutig (8 Byte Präfix) |
+
+**Beispiel:**
+
+```
+Normale BGP-Route:       192.168.1.0/24
+MP-BGP VPNv4-Route:      65000:1:192.168.1.0/24
+                         ←RD→ ←————IP————→
+```
+
+→ Gleiche IP-Adresse kann bei verschiedenen Kunden existieren, weil der RD sie unterscheidbar macht.
+
+---
+
+## 5. Ausfallsicherheit: BFD und FRR
+
+### BFD – Bidirectional Forwarding Detection
+
+- **Port:** UDP 3784
+- **Zweck:** Sehr schnelle Erkennung von Link-/Nachbar-Ausfällen (viel schneller als BGP/OSPF-Timer)
+
+**Die 3 Zustände:**
+
+```
+DOWN ──────→ INIT ──────→ UP
+      (Hello      (Antwort
+      gesendet)   erhalten)
+```
+
+| Zustand | Bedeutung |
+|---------|-----------|
+| **Down** | Keine Verbindung, oder gerade gestartet |
+| **Init** | Ich sende Hellos, habe aber noch keine Antwort |
+| **Up** | Beidseitige Verbindung bestätigt, alles ok |
+
+**Heartbeat:** BFD schickt alle **50ms** ein Hello-Paket. Kommen 3 aus, gilt der Nachbar als ausgefallen → **150ms** bis zur Fehlererkennung.
+
+> **Zum Vergleich:** OSPF-Dead-Interval ist standardmäßig 40 Sekunden. BFD ist also ~267x schneller.
+
+**Beispiel:**
+
+```
+Router A und B laufen, BFD-Session ist im Zustand UP.
+Link zwischen A und B fällt aus.
+Nach 150ms: Kein BFD-Hello mehr empfangen → BFD meldet „Nachbar down"
+→ OSPF/BGP bekommt sofort Bescheid → Router wechselt auf Backup-Route.
+Ohne BFD: OSPF würde erst nach 40 Sekunden reagieren.
+```
+
+---
+
+### FRR – Fast ReRoute
+
+- **Ziel:** Umschaltung auf Backup-Pfad in **unter 50ms** (nicht wahrnehmbar für Telefonie/Video)
+- **Funktioniert mit:** RSVP-TE, Segment Routing
+
+**Zwei Backup-Strategien:**
+
+#### One-to-One Backup
+
+Für jeden primären LSP wird ein **eigener Backup-LSP** vorbereitet.
+
+```
+Primär-LSP:  PE1 → P1 → P2 → PE2
+Backup-LSP:  PE1 → P3 → P4 → PE2  (vorbereitet, aber inaktiv)
+
+P1 fällt aus → sofort auf Backup-LSP umschalten
+```
+
+- **Vorteil:** Sehr schnell, dedizierter Pfad
+- **Nachteil:** Viele Ressourcen (für jeden LSP ein Backup)
+
+#### Facility Backup (auch: Bypass Tunnel)
+
+Ein einziger Bypass-Tunnel schützt **viele LSPs gleichzeitig**.
+
+```
+Primär-LSPs: LSP1, LSP2, LSP3 laufen alle über Link P1→P2
+Bypass:      Ein Tunnel P1 → P3 → P2 schützt alle drei auf einmal
+
+P1→P2 fällt aus → alle drei LSPs werden automatisch in den Bypass umgeleitet
+```
+
+- **Vorteil:** Effizient, ein Bypass für viele LSPs
+- **Nachteil:** Weniger präzise Kontrolle
+
+---
+
+### Link Protection vs. Node Protection
+
+| | Link Protection | Node Protection |
+|--|-----------------|-----------------|
+| **Schützt gegen** | Ausfall eines Links | Ausfall eines ganzen Routers |
+| **Bypass geht** | Um den ausgefallenen Link herum | Um den ausgefallenen Knoten herum |
+| **Beispiel** | P1 → P2 fällt aus → Bypass P1 → P3 → P2 | P2 fällt komplett aus → Bypass P1 → P3 → PE2 |
+
+```
+Link Protection:
+PE1 → P1 → [X] → P2 → PE2
+              ↓
+PE1 → P1 → P3 → P2 → PE2   (umgeht nur den ausgefallenen Link)
+
+Node Protection:
+PE1 → P1 → [P2 komplett ausgefallen] → PE2
+              ↓
+PE1 → P1 → P3 → PE2         (umgeht den ganzen Router P2)
+```
+
+---
+
+### Local Repair vs. Global Repair
+
+| | Local Repair | Global Repair |
+|--|-------------|---------------|
+| **Wer handelt?** | Der Router direkt am Ausfall | Der Ingress-Router (PE1) |
+| **Wie schnell?** | Sofort (< 50ms) – Bypass bereits vorbereitet | Langsamer – neuer LSP muss erst berechnet werden |
+| **Qualität** | Suboptimaler Pfad möglich | Optimaler neuer Pfad |
+| **Typischer Ablauf** | Zuerst Local Repair → Verkehr fließt wieder | Dann Global Repair → Pfad wird optimiert |
+
+**Beispiel:**
+
+```
+1. Link P1→P2 fällt aus.
+2. P1 erkennt Ausfall sofort (via BFD, 150ms).
+3. LOCAL REPAIR: P1 leitet Pakete sofort über vorbereiteten Bypass (< 50ms).
+   → Verkehr fließt wieder, User merkt (fast) nichts.
+4. GLOBAL REPAIR: PE1 berechnet neuen optimalen LSP via RSVP-TE.
+   → Neuer LSP wird aufgebaut, Bypass wird freigegeben.
+```
+
+> **Zusammenspiel BFD + FRR:** BFD erkennt den Ausfall in ~150ms. FRR schaltet in <50ms um (Bypass war bereits vorbereitet). Zusammen ist die Unterbrechung für den Nutzer minimal.