diff --git a/Datenbanken/Klausur/Zimmi Hinweise.md b/Datenbanken/Klausur/Zimmi Hinweise.md index 30ce0e5..e99bcfb 100644 --- a/Datenbanken/Klausur/Zimmi Hinweise.md +++ b/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% \ No newline at end of file +- 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 +- \ No newline at end of file diff --git a/Kryptografie/klausur/gesamtzusammenfassung.md b/Kryptografie/klausur/gesamtzusammenfassung.md index bf3b936..98bb411 100644 --- a/Kryptografie/klausur/gesamtzusammenfassung.md +++ b/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 | --- diff --git a/Netzwerke/.claude/worktrees/gifted-meninsky b/Netzwerke/.claude/worktrees/gifted-meninsky new file mode 160000 index 0000000..578a16b --- /dev/null +++ b/Netzwerke/.claude/worktrees/gifted-meninsky @@ -0,0 +1 @@ +Subproject commit 578a16b1152a3bce9dfacd1fd577006cd224f477 diff --git a/Netzwerke/.claude/worktrees/vigorous-lamarr b/Netzwerke/.claude/worktrees/vigorous-lamarr new file mode 160000 index 0000000..578a16b --- /dev/null +++ b/Netzwerke/.claude/worktrees/vigorous-lamarr @@ -0,0 +1 @@ +Subproject commit 578a16b1152a3bce9dfacd1fd577006cd224f477 diff --git a/Netzwerke/folien/nw8 - folien.pdf b/Netzwerke/folien/nw8 - folien.pdf new file mode 100644 index 0000000..4af8976 Binary files /dev/null and b/Netzwerke/folien/nw8 - folien.pdf differ diff --git a/Netzwerke/klausur/nw8 - klausurstuff.md b/Netzwerke/klausur/nw8 - klausurstuff.md new file mode 100644 index 0000000..b48d69c --- /dev/null +++ b/Netzwerke/klausur/nw8 - klausurstuff.md @@ -0,0 +1,3 @@ +# Themen in der Klausur + +Verfügbarkeit und Absicherungs-/Redundanzmethoden in Netzen \ No newline at end of file diff --git a/Netzwerke/klausur/themenliste.md b/Netzwerke/klausur/themenliste.md index bd611bc..41bc95e 100644 --- a/Netzwerke/klausur/themenliste.md +++ b/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 diff --git a/Netzwerke/labor/MPLS Commands.pdf b/Netzwerke/labor/MPLS Commands.pdf new file mode 100644 index 0000000..15d0b28 Binary files /dev/null and b/Netzwerke/labor/MPLS Commands.pdf differ diff --git a/Netzwerke/zusammenfassungen/nw1 - zusammenfassung.md b/Netzwerke/zusammenfassungen/nw1 - zusammenfassung.md index 960460f..b871e9c 100644 --- a/Netzwerke/zusammenfassungen/nw1 - zusammenfassung.md +++ b/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 | diff --git a/Netzwerke/zusammenfassungen/nw8 - zusammenfassung.md b/Netzwerke/zusammenfassungen/nw8 - zusammenfassung.md new file mode 100644 index 0000000..089b9f6 --- /dev/null +++ b/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