docs: exam stuff

Datenbanken/Klausur/Zimmi Hinweise.md

@@ -1,4 +1,13 @@
 # Klausurhinweise
+Grundsätzlich alles was wir im 1. Semester als direkte Wissensabfrage hatten, wird dieses Semester vorausgesetzt und eher Fragen zu einem konkreten Anwendungsfall gefragt.
 
 - Views und Inline-Views in SQL Code erkennen und unterscheiden können
-- Constraints kommen 100%
+- Constraints kommen 100% - nennen können
+- Konzeptioneller Entwurf:
+	- eher Tabellen gegeben und Fragen dazu anstatt selbst erstellen müssen
+	- **keine Definitionen, mehr Verständnis**
+	- (min,max)-Notation anwenden können (andere Notation als Peter-Chen-Notation)
+	- Regeln können, aber keine direkte Abfrage
+- Mengenlehre kommt nicht ran
+- Anfragebearbeitung Tools auflisten können
+- 

Kryptografie/klausur/gesamtzusammenfassung.md

@@ -1421,11 +1421,11 @@ Bestimmt die Stärke des Rauschens.
 
 ### 24.4 Mechanismen
 
-| Mechanismus | Beschreibung | Anwendung |
-|---|---|---|
-| **Laplace-Mechanismus** | Addiert Rauschen ~ Laplace(0, Δf/ε) | Numerische Abfragen |
-| **Gaußscher Mechanismus** | Addiert Gaußsches Rauschen; benötigt (ε, δ)-DP | Wenn etwas Lockerung akzeptabel |
-| **Exponentieller Mechanismus** | Wählt Ergebnis mit exp-gewichteter Wahrscheinlichkeit | Nicht-numerische Ausgaben |
+| Mechanismus                    | Beschreibung                                          | Anwendung                       |
+| ------------------------------ | ----------------------------------------------------- | ------------------------------- |
+| **Laplace-Mechanismus**        | Addiert Rauschen ~ Laplace(0, Δf/ε)                   | Numerische Abfragen             |
+| **Gaußscher Mechanismus**      | Addiert Gaußsches Rauschen; benötigt (ε, δ)-DP        | Wenn etwas Lockerung akzeptabel |
+| **Exponentieller Mechanismus** | Wählt Ergebnis mit exp-gewichteter Wahrscheinlichkeit | Nicht-numerische Ausgaben       |
 
 ---
 
@@ -1467,11 +1467,11 @@ Externe Partei  →  Verschlüsselte Daten  →  Enklave
 
 ### 26.1 Drei Dimensionen von Datenschutz
 
-| Zustand | Schutzziel | Beispiel |
-|---|---|---|
-| **Data at Rest** | Vertraulichkeit, Integrität | Verschlüsselte Festplatte |
-| **Data in Transit** | Vertraulichkeit, Integrität, Authentizität | TLS |
-| **Data in Use** | Vertraulichkeit während Verarbeitung | HE, MPC, TEE |
+| Zustand             | Schutzziel                                 | Beispiel                  |
+| ------------------- | ------------------------------------------ | ------------------------- |
+| **Data at Rest**    | Vertraulichkeit, Integrität                | Verschlüsselte Festplatte |
+| **Data in Transit** | Vertraulichkeit, Integrität, Authentizität | TLS                       |
+| **Data in Use**     | Vertraulichkeit während Verarbeitung       | HE, MPC, TEE              |
 
 ### 26.2 Erweiterte Privacy-Ziele
 
@@ -1497,59 +1497,59 @@ Externe Partei  →  Verschlüsselte Daten  →  Enklave
 
 ## Schnellreferenz: Wichtige Formeln
 
-| Konzept | Formel |
-|---|---|
-| Caesar | E(x) = (x+n) mod 26 |
-| Vigenère | C_i = (M_i + K_i) mod 26 |
-| OTP | E = P ⊕ K |
-| Shannon Perfect Secrecy | H(M\|E) = H(M) |
-| Entropie | H(X) = -Σ p_x · log₂(p_x) |
-| RSA Verschlüsselung | c = m^e mod n |
-| RSA Entschlüsselung | m = c^d mod n |
-| RSA Signatur | s = m^d mod n |
-| DH gemeinsames Geheimnis | K = g^(ab) mod p |
-| HMAC | H((k⊕opad) \|\| H((k⊕ipad)\|\|m)) |
-| Beaver Triple Multiplikation | xy = de + d[b] + e[a] + [c] |
-| Fiat-Shamir Challenge | ch = H(Commitment, Nachricht) |
-| DP Formel | Pr[M(D)∈S] ≤ e^ε · Pr[M(D')∈S] |
-| DP Rückrechnung | Echter Anteil = 2×(gemessen - 0,25) |
-| AES irreduzibles Polynom | m(x) = x⁸ + x⁴ + x³ + x + 1 |
-| Paillier Verschlüsselung | c = g^m · r^n mod n² |
-| Paillier Homomorphie | D(E(m₁)·E(m₂)) = m₁+m₂ mod n |
+| Konzept                      | Formel                              |
+| ---------------------------- | ----------------------------------- |
+| Caesar                       | E(x) = (x+n) mod 26                 |
+| Vigenère                     | C_i = (M_i + K_i) mod 26            |
+| OTP                          | E = P ⊕ K                           |
+| Shannon Perfect Secrecy      | H(M\|E) = H(M)                      |
+| Entropie                     | H(X) = -Σ p_x · log₂(p_x)           |
+| RSA Verschlüsselung          | c = m^e mod n                       |
+| RSA Entschlüsselung          | m = c^d mod n                       |
+| RSA Signatur                 | s = m^d mod n                       |
+| DH gemeinsames Geheimnis     | K = g^(ab) mod p                    |
+| HMAC                         | H((k⊕opad) \|\| H((k⊕ipad)\|\|m))   |
+| Beaver Triple Multiplikation | xy = de + d[b] + e[a] + [c]         |
+| Fiat-Shamir Challenge        | ch = H(Commitment, Nachricht)       |
+| DP Formel                    | Pr[M(D)∈S] ≤ e^ε · Pr[M(D')∈S]      |
+| DP Rückrechnung              | Echter Anteil = 2×(gemessen - 0,25) |
+| AES irreduzibles Polynom     | m(x) = x⁸ + x⁴ + x³ + x + 1         |
+| Paillier Verschlüsselung     | c = g^m · r^n mod n²                |
+| Paillier Homomorphie         | D(E(m₁)·E(m₂)) = m₁+m₂ mod n        |
 
 ---
 
 ## Schnellreferenz: Wichtige Definitionen
 
-| Begriff | Kurzdefinition |
-|---|---|
-| **Perfect Secrecy** | Geheimtext verrät keinerlei Information über Klartext (H(M\|E) = H(M)) |
-| **OWF** | Leicht zu berechnen, praktisch unmöglich umzukehren |
-| **PRG** | Streckt kurzen Seed zu ununterscheidbarem langen Pseudozufallsstring |
-| **Comp. Indistinguishability** | Kein effizienter Algorithmus kann zwei Verteilungen mit messbarem Vorteil unterscheiden |
-| **IND-CPA** | Angreifer kann bei Zugriff auf Verschlüsselungsorakel nicht unterscheiden, welche Nachricht verschlüsselt wurde |
-| **IND-CCA2** | Wie IND-CPA + adaptiver Zugriff auf Entschlüsselungsorakel (außer Challenge-CT) |
-| **MAC** | Kurzer Tag, der Integrität und Authentizität (nicht Vertraulichkeit) sichert |
-| **AEAD** | Kombiniert Verschlüsselung + Authentifizierung in einem Algorithmus |
-| **Feistel-Netzwerk** | Blockchiffre-Struktur: L_{i+1}=R_i, R_{i+1}=L_i⊕F(R_i,K_i); F muss nicht invertierbar sein |
-| **Padding Oracle Attack** | Angriff auf CBC: nutzt Unterscheidung zwischen Padding-Fehlern aus |
-| **Cipher Text Stealing** | Vermeidet Padding, indem letzter vollständiger + unvollständiger Block kombiniert werden |
-| **Shors Algorithmus** | Löst Faktorisierung und DLP in polynomialer Zeit → bricht RSA, DH, ECDH |
-| **Grovers Algorithmus** | Suche in O(√N) → halbiert effektive Schlüssellänge symmetrischer Verfahren |
-| **LWE** | Learning With Errors: schweres Gitterproblem, Basis für PQC |
-| **Oblivious Transfer** | Sender weiß nicht, welche seiner Nachrichten der Empfänger erhalten hat |
-| **Garbled Circuit** | Verschlüsselter Boole'scher Schaltkreis; ermöglicht sichere Zweikparteienberechnung |
-| **Beaver Triple** | Vorberechnetes (a, b, c=ab)-Tripel für effiziente MPC-Multiplikation |
-| **ZK-Proof (Zero Knowledge)** | Beweis der Wahrheit einer Aussage ohne Preisgabe weiterer Informationen |
-| **Fiat-Shamir** | Macht interaktive ZK-Proofs nicht-interaktiv durch H(Commitment, Nachricht) als Challenge |
-| **Differential Privacy** | Statistischer Datenschutz: Pr[M(D)∈S] ≤ e^ε·Pr[M(D')∈S] für benachbarte D, D' |
-| **TEE/Enklave** | Hardware-geschützter Ausführungsbereich; auch kompromittiertes OS hat keinen Zugriff |
-| **Zertifikat (X.509)** | Digitale Bestätigung einer CA: bindet Public Key an Identität |
-| **Chain of Trust** | Hierarchische Vertrauenskette: Endnutzer-Zertifikat ← CA ← Root CA |
-| **CRL** | Liste widerrufener Zertifikate, periodisch veröffentlicht |
-| **OCSP** | Echtzeitabfrage des Zertifikatstatus bei einem Responder-Server |
-| **BB84** | Quantenschlüsselaustausch; sicher durch No-Cloning-Theorem; Eve-Abhören detektierbar |
-| **MPC in the Head** | ZK-Proofs durch Simulation eines MPC-Protokolls im Kopf des Provers |
+| Begriff                        | Kurzdefinition                                                                                                  |
+| ------------------------------ | --------------------------------------------------------------------------------------------------------------- |
+| **Perfect Secrecy**            | Geheimtext verrät keinerlei Information über Klartext (H(M\|E) = H(M))                                          |
+| **OWF**                        | Leicht zu berechnen, praktisch unmöglich umzukehren                                                             |
+| **PRG**                        | Streckt kurzen Seed zu ununterscheidbarem langen Pseudozufallsstring                                            |
+| **Comp. Indistinguishability** | Kein effizienter Algorithmus kann zwei Verteilungen mit messbarem Vorteil unterscheiden                         |
+| **IND-CPA**                    | Angreifer kann bei Zugriff auf Verschlüsselungsorakel nicht unterscheiden, welche Nachricht verschlüsselt wurde |
+| **IND-CCA2**                   | Wie IND-CPA + adaptiver Zugriff auf Entschlüsselungsorakel (außer Challenge-CT)                                 |
+| **MAC**                        | Kurzer Tag, der Integrität und Authentizität (nicht Vertraulichkeit) sichert                                    |
+| **AEAD**                       | Kombiniert Verschlüsselung + Authentifizierung in einem Algorithmus                                             |
+| **Feistel-Netzwerk**           | Blockchiffre-Struktur: L_{i+1}=R_i, R_{i+1}=L_i⊕F(R_i,K_i); F muss nicht invertierbar sein                      |
+| **Padding Oracle Attack**      | Angriff auf CBC: nutzt Unterscheidung zwischen Padding-Fehlern aus                                              |
+| **Cipher Text Stealing**       | Vermeidet Padding, indem letzter vollständiger + unvollständiger Block kombiniert werden                        |
+| **Shors Algorithmus**          | Löst Faktorisierung und DLP in polynomialer Zeit → bricht RSA, DH, ECDH                                         |
+| **Grovers Algorithmus**        | Suche in O(√N) → halbiert effektive Schlüssellänge symmetrischer Verfahren                                      |
+| **LWE**                        | Learning With Errors: schweres Gitterproblem, Basis für PQC                                                     |
+| **Oblivious Transfer**         | Sender weiß nicht, welche seiner Nachrichten der Empfänger erhalten hat                                         |
+| **Garbled Circuit**            | Verschlüsselter Boole'scher Schaltkreis; ermöglicht sichere Zweikparteienberechnung                             |
+| **Beaver Triple**              | Vorberechnetes (a, b, c=ab)-Tripel für effiziente MPC-Multiplikation                                            |
+| **ZK-Proof (Zero Knowledge)**  | Beweis der Wahrheit einer Aussage ohne Preisgabe weiterer Informationen                                         |
+| **Fiat-Shamir**                | Macht interaktive ZK-Proofs nicht-interaktiv durch H(Commitment, Nachricht) als Challenge                       |
+| **Differential Privacy**       | Statistischer Datenschutz: Pr[M(D)∈S] ≤ e^ε·Pr[M(D')∈S] für benachbarte D, D'                                   |
+| **TEE/Enklave**                | Hardware-geschützter Ausführungsbereich; auch kompromittiertes OS hat keinen Zugriff                            |
+| **Zertifikat (X.509)**         | Digitale Bestätigung einer CA: bindet Public Key an Identität                                                   |
+| **Chain of Trust**             | Hierarchische Vertrauenskette: Endnutzer-Zertifikat ← CA ← Root CA                                              |
+| **CRL**                        | Liste widerrufener Zertifikate, periodisch veröffentlicht                                                       |
+| **OCSP**                       | Echtzeitabfrage des Zertifikatstatus bei einem Responder-Server                                                 |
+| **BB84**                       | Quantenschlüsselaustausch; sicher durch No-Cloning-Theorem; Eve-Abhören detektierbar                            |
+| **MPC in the Head**            | ZK-Proofs durch Simulation eines MPC-Protokolls im Kopf des Provers                                             |
 
 ---
 

Netzwerke/.claude/worktrees/gifted-meninsky

@@ -0,0 +1 @@
+Subproject commit 578a16b1152a3bce9dfacd1fd577006cd224f477

Netzwerke/.claude/worktrees/vigorous-lamarr

@@ -0,0 +1 @@
+Subproject commit 578a16b1152a3bce9dfacd1fd577006cd224f477

Netzwerke/klausur/nw8 - klausurstuff.md

@@ -0,0 +1,3 @@
+# Themen in der Klausur
+
+Verfügbarkeit und Absicherungs-/Redundanzmethoden in Netzen

Netzwerke/klausur/themenliste.md

@@ -1,12 +1,9 @@
 # Themenliste – Klausurvorbereitung Netzwerktechnik IT2221
 **Klausur:** Mo., 4. Mai 2026 | 14:00–16:00 Uhr | Räume 6B.369 / 6B.371
 
-> Fokus auf NW1–NW4. Themen ab NW5 sind ergänzend aufgeführt.
-
+> **Fokus auf NW2–NW5. Themen ab NW6 sind ergänzend aufgeführt.**
 ---
-
 ## NW1 – Grundlagen, Layer 2 & 3 Basics
-
 ### Netzwerkgrundlagen
 - [ ] Definition Netzwerk & Netzwerkknoten
 - [ ] Netzwerk-Komponenten: Repeater, Hub, Bridge, Switch, Router, Gateway – Funktion & Unterschied

Netzwerke/zusammenfassungen/nw1 - zusammenfassung.md

@@ -188,16 +188,16 @@ Dezimal:  131   .  108   .  122   .  204
 
 ## 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 |
+| 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 |

Netzwerke/zusammenfassungen/nw8 - zusammenfassung.md

@@ -0,0 +1,482 @@
+# 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