hwr-notes/Netzwerke/klausur/nw6 - klausurstuff.md

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