hwr-notes/Netzwerke/zusammenfassungen/nw8 - zusammenfassung.md

# NW8 – Zusammenfassung
**IT2221 Netwerktechnik | Dozentin: Gabriele Schrenk | 10.04.2026**

Themen: Segment Routing (Fortsetzung), Flex Algo, Ausfallsichere Netze, Verfügbarkeit in Netzen

---
## 1. Segment Routing
### 1.1 Was ist Segment Routing?

**Source Routing:**
- Der **Ingress-Knoten** (Eingangsrouter) wählt den gesamten Pfad durch das Netz
- Der Weg wird **nicht** „Hop by Hop" von jedem Router neu berechnet, sondern vom ersten Router festgelegt
- Der Pfad wird als **geordnete Liste von Segmenten** dargestellt

**Segment:**
- Eine Anweisung für den Router, z.B. „Sende zum Knoten X über den kürzesten Pfad"
- IGP-Segment: **Prefix-/Node-SID** (global), **Adjacency-SID** (lokal)

**Data Plane Agnostic:**
- Nutzt vorhandene Data Planes (MPLS oder IPv6) und Routing-Protokolle (IS-IS, OSPF)

---

### 1.2 Segment Routing Vorteile

| Bereich | Vorteil |
|---|---|
| **Control Plane Vereinfachung** | Weniger Protokolle, weniger Abhängigkeiten, automatischer Traffic-Schutz ohne Flow-Signalisierung |
| **Traffic Engineering** | Keine zustandsbehafteten Einträge pro Flow im Kernnetz; Pfade werden automatisch berechnet oder durch Controller vorgegeben |
| **Software-Defined Networking** | Weiterentwicklung bestehender Technik; hybrider Ansatz (zentralisiert + verteilt); Netzprogrammierbarkeit über Southbound-Schnittstellen (z.B. **PCEP**) |

**PCEP** = Path Computation Element Communication Protocol – standardisiertes IETF-Protokoll, genutzt vom SDN-Controller (PCE) zur Pfadberechnung.

---

### 1.3 Standardisierung

- IETF Working Group: **SPRING** (Source Packet Routing in Networking)
  - Architektur: RFC 8402, RFC 9256
- **SR-MPLS**: RFC 8660
- **SRv6**: RFC 9886
- Protokollerweiterungen in weiteren Working Groups: SPRING, PCE, IDR, 6MAN

---

### 1.4 Building Blocks: IGP Segments – SR-MPLS

#### Prefix/Node Segment (global)
- Global gültig in der gesamten SR-Domäne – jeder Router versteht die SID gleich
- Routing zum Prefix/Knoten über den **kürzesten IGP-Pfad** (SPF)
- Wird als **relativer Wert (Index)** angekündigt → Offset vom SRGB-Basiswert
- SID-Bereich: **SRGB ab 16.000** (Segment Routing Global Block)
- Beispiel: SRGB [16.000–23.900] + Index 41 = Label **16.041**

#### Adjacency Segment (lokal)
- Nur lokal auf dem vergebenden Knoten gültig
- Leitet das Paket **explizit über eine bestimmte Nachbarverbindung** weiter (Source Routing)
- Wird als **absoluter Wert** angekündigt (direkt die Label-/SID-Nummer, kein Index)
- Beispiel: Adj-SID = 9107

**Zusammenfassung SID-Berechnung:**
- Prefix-SID: `SRGB-Basis + Index` (z.B. 16.000 + 41 = **16.041**)
- Adj-SID: absoluter Wert direkt = Label-Nummer (z.B. **9107**)

---

### 1.5 Building Blocks: IGP Segments – SRv6

- Kein SRGB mehr – stattdessen **128-Bit-IPv6-Adressen** als SIDs
- IPv6-Adressen sind global eindeutig und im gesamten Netz routbar → kein reservierter Label-Block nötig
- SID-Typen in SRv6:
  - **Adjacency-SID**: `End.X-SID`
  - **Node-SID**: `End-SID`
  - **Prefix-SID**: `End.DT4` / `End.DT6`

---

### 1.6 SR-MPLS Data Plane

- SR-MPLS nutzt die **MPLS-Weiterleitungsebene** (gemäß RFC 8660), Standard-MPLS-Header
- Segmente werden als **MPLS-Labels** kodiert
  - Jede SID ist ein MPLS-Label aus dem SRGB
  - Die Segmentliste = **MPLS-Label-Stack**
- **Forwarding:**
  - Headend-Router schreibt den vollständigen SR-Label-Stack aufs Paket
  - Ausgangsrouter entfernt das letzte SR-Label
- **Koexistenz mit klassischem MPLS:** SR- und LDP-Tunnel können koexistieren

---

### 1.7 SRv6: Segment Routing über IPv6

- SRv6 = Segment Routing over IPv6 (RFC 8986)
- Nutzt Standard-IPv6-Forwarding-Plane mit optionalem **Segment Routing Header (SRH)**
- Jede SID wird als IPv6-Adresse kodiert (nicht als MPLS-Label)
- **SID-Struktur:** `Locator :: Funktion :: Argumente`
  - Locator: identifiziert den Knoten/Standort
  - Funktion: definiert das auszuführende Verhalten
- **„Network Programming":** Jede SID repräsentiert ein Verhalten, nicht nur den nächsten Hop

---

### 1.8 Klassisches MPLS vs. Segment Routing

| Aspekt | Classic MPLS | Segment Routing |
|---|---|---|
| Pfadaufbau | LSPs über LDP/RSVP-TE | Segmentliste am Ingress-Router |
| Control Plane | IGP + LDP + RSVP-TE | IGP/BGP (kein separates LDP nötig) |
| State im Core | Pro Flow (viel State) | Nur am Ingress (generische SIDs) |
| Traffic Engineering | Separate TE-LSPs via RSVP-TE | Integriert über Segmentlisten |

---

### 1.9 Segmenttypen und SID-Verteilung

| SID-Typ | Beschreibung |
|---|---|
| **Node/Prefix-SID** | Shortest-Path-Route zu einem Knoten oder Prefix |
| **Adjacency-SID** | Spezifischer ausgehender Link zwischen Knoten |
| **Binding-SID** | Repräsentiert einen kompletten vorberechneten Pfad oder eine Policy mit einer einzigen SID |

**SID-Verteilung:**
- IGPs (IS-IS, OSPF) und BGP weisen SIDs zu (über standardisierte Erweiterungen)
- SR-MPLS: SIDs sind MPLS-Labels im SRGB
- SRv6: SIDs sind IPv6-Adressen

---

### 1.10 Building Blocks: Node-SID, Adjacency-SID, Explicit Path

**Node-SID:**
- Weiterleitung entlang des **kürzesten IGP-Pfades**
- Nutzung des ECMP-Lastausgleichs
- Swap-Operation im Core; vorletzte Hop: Pop-Operation (PHP)

**Adjacency-SID:**
- Weiterleitung entlang der **IGP-Nachbarschaft**
- Pop-Operation; vorletzte Hop entfernt immer die letzte Adjacency-ID

**Explicit Path:**
- Weiterleitung basierend auf dem **Label-Stack**
- Per-Flow-Status nur am Eingangs-SR-Knoten
- Kombination aus Node-SIDs und Adj-SIDs im Stack

---

### 1.11 SRGB (Segment Routing Global Block)

- Node-SID wird als **relativer Index-Wert** angegeben
- Index = Offset vom SRGB-Basiswert → global eindeutig
- SRGB-Wert kann zwischen Knoten variieren
- Beispiel: Knoten A: SRGB [30.000–30.900], Knoten B: SRGB [16.000–23.900]
  - Node-SID-Index 41 → bei A: Label 30.041, bei B: Label 16.041

---

### 1.12 Vergleich SR-MPLS vs. SRv6

| Beschreibung | SR-MPLS | SRv6 |
|---|---|---|
| Identifier | 20-Bit MPLS Label | 128-Bit IPv6-Adresse (SID) |
| Kompletter Pfad | MPLS Label Stack | IPv6 Header + Segment Routing Header |
| Mapping | Label zeigt auf IP-Adresse | Adresse enthält die Anweisungen selbst |
| Protokoll/Hardware | MPLS mit Labelzuweisung | Plain IPv6 |
| Use Case | Upgrade bestehender Netze | Neue Netze komplett auf IPv6 |

**SRv6 IPv6-Adressstruktur:**
- **Locator**: routbarer Teil der Adresse
- **Function**: z.B. Paket an Interface A senden oder in VRF A weiterleiten
- **Arguments**: Zusatzinfos wie Flow-Parameter, Multicast-Infos

---

## 2. Flex Algo (Flexible Algorithm)

### 2.1 Einführung

- Schlüsseltechnologie für moderne **WAN** und **Rechenzentren**
- Erlaubt dem Routing-Protokoll (OSPF/IS-IS) automatisch mehrere **„logische Topologien"** auf derselben physischen Infrastruktur zu berechnen (Network Slicing)
- Kein zentraler Controller für Pfadberechnung nötig (im Gegensatz zu RSVP-TE)

**Warum Flex Algo?**
- **Automatisches Traffic Engineering:** Pfadberechnung basierend auf Latenz statt nur Bandbreite (wichtig für Cloud-Gaming, autonomes Fahren)
- **Network Slicing für 5G & AI:** Dedizierte virtuelle Netzwerke (Low-Latency-Slice, High-Throughput-Slice)
- Intelligenz liegt direkt in den Routern

---

### 2.2 Flex Algo – Funktion & Ablauf

- **Flexible Algorithm Definition (FAD):**
  - Betreiber definiert einen oder mehrere Flex-Algorithmen (IDs 128–255)
  - Parameter: Metriktyp (IGP, TE, Latenz), ein-/ausgeschlossene Linkfarben (Colors)
- Ausgewählte Knoten veröffentlichen FADs im IGP → führen separate **SPF-Berechnungen** pro Flex-Algo durch
- Jeder Knoten berechnet Pfad mit Berücksichtigung der Einschränkung
- Knoten veröffentlichen **Präfix-SIDs/SRv6-Locators** pro Flex-Algorithmus
  - Ein Knoten kann mehrere SIDs haben (z.B. Standard + Low Latency)
- IGP stellt automatisch TE-optimierte Pfade für jeden Flex-Algo bereit → Weiterleitung durch Segment Routing

**Verbindung zu SR:** Flex Algo integriert sich in SR-MPLS und SRv6 durch Algorithm-Specific SIDs/Locators.

---

### 2.3 Flex Algo – Typische Use Cases

- **Algo 0:** Default best-effort (Standard IGP Metrik)
- **Algo X:** Low-Latency oder Low-Delay Slice
- **Algo Y:** Pfad zur Vermeidung spezifischer Links oder Knoten
- Einfaches Traffic Engineering ohne vollständigen SR-TE-Controller
- Verwendung von Flex-Algo-spezifischen SIDs in SR-Richtlinien und TI-LFA-Backup-Pfaden

---

## 3. Ausfallsichere Netze

### 3.1 UPA – Unreachable Prefix Announcement

- **Was ist UPA?** Eine IGP-Funktion, die den Verlust der Erreichbarkeit eines Präfixes explizit ankündigt
- **Ziel:** Remote-Router sollen den Traffic schnell von einem ausgefallenen Ausgangspunkt umleiten – auch wenn eine Präfix-/Locator-Zusammenfassung verwendet wird

**Funktionsweise auf IGP-Ebene:**
- Wenn ein ABR/ASBR feststellt, dass ein Präfix nicht mehr erreichbar ist → erzeugt eine UPA für dieses Präfix
- UPA wird wie eine normale IGP-Ankündigung über alle Bereiche verteilt
- Zwischenrouter leiten UPA weiter; nur ABRs und Ingress-PEs müssen reagieren

**Warum UPA notwendig ist:**
- Ingress-PEs empfangen UPA → markieren das Ausgangspräfix als nicht erreichbar
- Löst schnelles **BGP FRR** (Fast ReRoute) für Routen aus, die diesen Ausgangspunkt nutzen
- Verhindert langes **Blackholing** bei SR-Ausgang hinter Route Summarization

---

### 3.2 Baseline Fast Convergence: BFD und BGP PIC

**BFD (Bidirectional Forwarding Detection):**
- Schnelle Fehlererkennung, oft unter **50 ms**, unabhängig von IGP/BGP-Hello-Timern
- BFD-Sitzungen sind an IGP-Nachbarschaften, BGP-Sitzungen und SR-Tunnel gebunden

**BGP PIC (Prefix Independent Convergence):**
- Berechnet **Backup-Next-Hops** im RIB/FIB vor
- Bei Next-Hop- oder Egress-Fehler: nur kleine Zeigeränderung (Pointer auf die Route) → nicht alle Präfixe neu verarbeiten
- Core-/Edge-PE-Fehler oder Next-Hop-Verlust → schnelle Umschaltung auf Backup-Pfad
- Unerlässlich für Hochverfügbarkeit von **L3VPN-, EVPN- und Internetdiensten** über SR-Pfade

---

### 3.3 IGP Fast Reroute: LFA und Remote-LFA

**Ziel von IGP Fast Reroute (FRR):**
- Lokaler Schutz: Umleitung bei Ausfall innerhalb von **Millisekunden**, vor vollständiger IGP-Konvergenz
- Schutz wird pro primärem Next-Hop vorab berechnet

**Loop-Free Alternates (LFA):**
- LFA wählt einen **Nachbarn als Backup-Next-Hop**, sofern die Schleifenfreiheitsbedingung erfüllt ist
- **Remote-LFA** erweitert LFA: Datenverkehr über Backuptunnel zu einem **PQ-Knoten**
  - P-Space = Source Side
  - Q-Space = Destination Side

**Interaktion mit Segment Routing:**
- SR-SIDs/Labels können als Backup-Tunnel verwendet werden
- **TI-LFA** (Topology-Independent LFA) verallgemeinert dies für SR

---

### 3.4 TI-LFA: Topology-Independent LFA

- Fast-Reroute-Mechanismus für IS-IS/OSPF
- Berechnet **SR-Backuppfade** (Segmentlisten) vorab
- Lokale Reparatur in SR-MPLS- und SRv6-Netzwerken **unter 50 ms**

**Funktionsweise:**
- Für jeden primären Next-Hop: Router berechnet Shortest Path Tree, der die geschützte Ressource (Link/Knoten) ausschließt
- Backuppfad wird als **SR-Segmentliste** (MPLS-Labels oder SRv6-SIDs) kodiert und vorab in die FIB eingetragen
- Im Fehlerfall: Router greift auf vorinstallierte SR-Backupliste zurück

**Vorteile gegenüber klassischem LFA/Remote-LFA:**
- Einheitlicher Mechanismus
- Integration mit Traffic Engineering (TE) & Flex Algo

---

### 3.5 Koexistenz von MPLS und Segment Routing

- Viele SP- und DC-Backbones nutzen LDP/RSVP-TE über MPLS mit VPN/EVPN-Diensten → stabil, aber betrieblich komplex
- Betreiber wünschen SR-MPLS/SRv6 für einfacheres TE, Automatisierung, bessere Hochverfügbarkeit
- **Koexistenz** ist der erste Schritt:
  - MPLS-Architektur ermöglicht gleichzeitigen Betrieb mehrerer Label-Control-Planes
  - Interworking-Mechanismen für Datenverkehr zwischen SR- und Legacy-MPLS-Tunneln

---

### 3.6 MPLS LFIB mit Segment Routing

- **LFIB** (Label Forwarding Information Base) wird über IGP (IS-IS/OSPF) zugewiesen
- Forwarding-Tabelle bleibt konstant (Nodes + Adjacencies), unabhängig von der Pfadanzahl
- Alle MPLS-Dienste (IPv4, IPv6, VPWS, VPLS, IPv4 VPN, IPv6 VPN) können ohne Änderungen an Control/Forwarding-Plane genutzt werden

---

### 3.7 SRv6–MPLS Service Interworking Gateway

- Ein **Gateway-Router**, der sowohl BGP-SRv6-basierte als auch BGP-MPLS-basierte L2/L3-Dienste für dieselbe Serviceinstanz unterstützt
- Grenze zwischen SRv6-Domäne und MPLS/SR-MPLS-Domäne
- Genutzt für L3VPN, EVPN-L3, EVPN VPWS während der Migration
- Das Gateway baut BGP-Sitzungen zu beiden Seiten auf und installiert/kündigt Präfixe mit dem jeweils anderen Kapselungstyp an

---

## 4. Verfügbarkeit in Netzen – Berechnung

### 4.1 Steigerung der Verfügbarkeit

**Ausfallsicherheit der Komponenten erhöhen:**
- Redundante Komponenten und Spannungsversorgung
- USV (Unterbrechungsfreie Stromversorgung)
- Regelmäßige Wartung, Hot-Plugging, kontrollierte Umgebungsbedingungen

**Ausfallzeit reduzieren:**
- Ersatzteile bevorraten, Überwachung, Wartungsverträge

**Netztopologie:**
- Logische Funktionsblöcke (Cluster), redundante Netzwerkpfade, Layer 2 oder Layer 3 Anbindung

**First Hop Redundancy:**
- Redundanz im Access Layer, Kombination mit redundanten Netzwerkpfaden

**Routing-Protokolle:**
- Protokollauswahl mit Berücksichtigung der Wiederherstellungszeiten

---

### 4.2 Hochverfügbarkeit – Tabelle der „Nines"

| Anzahl 9s | Verfügbarkeit (%) | Ausfallzeit/Jahr | Ausfallzeit/Monat |
|---|---|---|---|
| 1 | 90% | 36,5 Tage | 72 Stunden |
| 2 | 99% | 3,65 Tage | 7,2 Stunden |
| 3 | 99,9% | 8,76 Stunden | 43,8 Minuten |
| 4 | 99,99% | 52,56 Minuten | 4,38 Minuten |
| 5 | 99,999% | 5,26 Minuten | 26,3 Sekunden |
| 6 | 99,9999% | 31,5 Sekunden | 2,59 Sekunden |

**Formel:** Maximale Ausfallzeit pro Jahr = **(1 – Verfügbarkeit) × Gesamtzeit**

---

### 4.3 Berechnung der Hochverfügbarkeit

**Gesamtzeit:**
- 365 Tage = 8.760 Std. = 525.600 Min. = 31.536.000 Sek.

**Beispiel: 99,9% Verfügbarkeit**
- Ausfallzeit/Jahr: (1 – 0,999) × 8.760 Std. = **8,76 Stunden**
- Ausfallzeit/Monat: (1 – 0,999) × 730 Std. = 0,73 Std. = **43,8 Minuten**

---

### 4.4 Wartungsfenster

- Geplante Zeiträume, in denen Systeme offline sind (Wartung, Upgrades)
- Perioden sind geplant und im Voraus angekündigt
- Unternehmen rechnen Verfügbarkeit inkl. Wartung
- **SLA-Beispiel:**
  - Wartung: 2 Std./Monat = 24 Std./Jahr
  - Ungeplante Ausfallzeit: 10 Std./Jahr
  - Gesamte Ausfallzeit: **34 Stunden/Jahr**
  - Verfügbarkeit: (1 – (34/8760)) × 100 = **99,61%**

---

### 4.5 MTBF und MTTR

| Begriff | Bedeutung |
|---|---|
| **MTBF** (Mean Time Between Failures) | Durchschnittliche Zeit zwischen zwei aufeinanderfolgenden Ausfällen; Maß für Zuverlässigkeit |
| **MTTR** (Mean Time to Repair) | Durchschnittliche Zeit zur Reparatur und Wiederinbetriebnahme nach einem Ausfall |
| **Ausfallzeit** | Zeit, in der ein System nicht betriebsbereit ist (setzt sich aus MTBF und MTTR zusammen) |
| **Gesamte Ausfallzeit** | Anzahl der Ausfälle × MTTR |

**Verfügbarkeitsformel:**
```
V (%) = (1 – (Gesamte Ausfallzeit / Gesamtzeit)) × 100
```

**Beispielrechnung:**
- MTBF: 200 Std., MTTR: 2 Std., Ausfälle/Jahr: 10
- Gesamte Ausfallzeit: 10 × 2 = **20 Stunden**
- V (%) = (1 – (20 / 8760)) × 100 = **≈ 99,77%**

---

### 4.6 Aufgabe: Berechnung Verfügbarkeit

**Vorgabe:** Netz darf maximal 8 Std./Jahr ausfallen
- 8 Std. = 28.800 Sek.
- 28.800 / 31.536.000 = 0,00091 → maximale Ausfallzeit = **0,09%**
- Erforderliche Verfügbarkeit: **≥ 99,91%**

**Bestandteile der Gesamtausfallzeit (Total Service Downtime):**
- Failure Detection Time
- Notification Time
- Diagnosis Time
- Dispatch Time
- Arrival Time
- Repair Time
- Up Time

---

### 4.7 Realisierung von Verfügbarkeit durch Redundanz

Durch mehr Redundanz im Netz steigt die Verfügbarkeit stark:
- **Einfache Topologie** (1 Core-Router): 99,938% → 325 Min/Jahr Ausfallzeit (bei MTTR 4 Std.)
- **Doppelte Core-Router**: 99,961% → 204 Min/Jahr
- **Vollredundante Topologie** (2 Core + 2 Distribution): 99,9999% → 30 Sek/Jahr

---

### 4.8 Redundante Netzwerkpfade

- Analyse der Netztopologie: Welche Redundanzen, auf welcher OSI-Schicht?
- Vermeidung von **Single Points of Failure**
- Einsatz auf Layer 2 (Switches) und Layer 3 (Router)

**Logische Funktionsblöcke (3-Layer-Modell):**
- **Access Layer:** Endgeräte-Anbindung
- **Distribution Layer:** Aggregation, Richtlinien
- **Core Layer:** Hochgeschwindigkeits-Backbone

---

### 4.9 Ausfallsicherheit: Link Aggregation

- **Standard:** IEEE 802.3ad → 802.1AX-2008
- Sub-Layer in **OSI-Schicht 2**
- Statisch oder dynamisch (mittels **LACP**) konfiguriert

**Funktionen:**
- Aggregation (Bündelung) mehrerer Ports zu einer logischen Verbindung
  - Erhöhung der Bandbreite
  - Redundanz durch mehrere Ports
  - Loadbalancing zwischen physikalischen Ports
- Für gestackte Switches auch über Ports auf mehreren Switches

---

### 4.10 LACP – Link Aggregation Control Protocol

- Bildung einer **LACP-Gruppe** durch Linkzuordnung
- Maximale Anzahl LAG-Ports im Portchannel: **1–8**
- **LACPDUs** (Link Aggregation Control Protocol Data Units):
  - Versendet an Multicast-Gruppe `01:80:C2:00:00:02`
  - Für Statusinformationen (Link aktiv?, Prioritäten)
- LACP-Pakete werden jede Sekunde gesendet (Keepalive; default: 30s, schnell: 1s)

**Loadbalancing-Methoden:**
- **Quell- und Ziel-IP-Hash:** Hash basierend auf Quell-/Ziel-IP-Adresse
- **Layer 4 (TCP/UDP)-Hash:** Hash basierend auf Quell-/Ziel-IP + Quell-/Ziel-Port

---

### 4.11 VRRP – Virtual Router Redundancy Protocol

- **Standard:** IETF RFC 2338
- Gruppe von Routern fungiert als **ein virtueller Router** (gemeinsame virtuelle IP + MAC)
- **Master-Router:** führt Paketweiterleitung durch
- **Backup-Router:** übernehmen bei Ausfall des Masters

**Funktionsprinzip:**
- Virtuelle IP-Adresse (VIP) wird von VRRP genutzt → Switch leitet Verkehr an Master
- Virtuelle MAC-Adresse ist dem Master zugeordnet
- Fällt der Master aus: VIP wird auf Backup übertragen
- Switch erfährt Ausfall indirekt: erhält ARP-Nachricht des neuen Masters → aktualisiert MAC-Adresstabelle

---

## 5. Prüfungsinfo

- **Klausur:** Mo., 4. Mai 2026 | 14:00–16:00 Uhr
- **Räume:** 6B.369 und 6B.371
  - Raum 6B.369: länger reserviert für Nachteilsausgleich
  - Betreuer: Schrenk und Albaradie