# 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