theo/hwr-notes
1
0
Fork 0
mirror of https://github.com/theoleuthardt/hwr-notes.git synced 2026-06-05 23:51:09 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
hwr-notes/Netzwerke/zusammenfassungen/nw7 - zusammenfassung.md
theoleuthardt 850aa3455d docs: add obsidian hwr docs
2026-04-09 11:24:56 +02:00

14 KiB
Raw Permalink Blame History

IT2221 Netzwerktechnik – Vorlesung 7: MPLS VPNs & Segment Routing

Dozentin: Gabriele Schrenk | Datum: 01.04.2026
Klausur: Mo., 4. Mai 2026, 14:00–16:00 Uhr, Räume 6B.369 und 6B.371

0. Fehlerszenarien nächste Woche Labor

  • PC bekommt keine IP Adresse
  • PC erreicht einen bestimmten anderen PC nicht
  • Mögliche Fehler:
    • OSPF-Nachbarschaft/Routing
    • BGP Redistribution
    • Interfaces falsch eingestellt (MTU Size, Adressen....)
    • Und verschiedene andere Fehler

Troubleshooting_Netz

1. Troubleshooting Methodology

Strukturiertes Vorgehen bei Netzwerkproblemen (z.B. PC bekommt keine IP, PC erreicht anderes Gerät nicht):

  1. Problem definieren – Was genau funktioniert nicht?
  2. Informationen sammeln – show-Befehle ausführen
  3. Daten analysieren – Routingtabellen, Nachbarzustände prüfen
  4. Hypothese formulieren – Welche OSI-Schicht ist betroffen?
  5. Hypothese testen – Paketmitschnitte (PCAPs) auswerten
  6. Korrektur implementieren
  7. Überprüfen & dokumentieren

Typische Fehlerquellen im Labor: OSPF-Nachbarschaft, BGP-Redistribution, falsche MTU/Adressen an Interfaces.

2. VPNs über MPLS – Grundidee

Ziel: Mehrere Unternehmensstandorte über einen gemeinsamen Provider-Backbone verbinden, dabei aber voneinander isoliert halten.

Anforderungen (Wunschliste):

  • Nutzung des bestehenden SP-Backbones
  • Überlappende Adressräume erlaubt (verschiedene Kunden dürfen gleiche IPs nutzen)
  • Datentrennung zwischen VPNs
  • Skalierung, QoS, einfache Verwaltung

3. VPN-Klassifizierung (RFC 4026 – PPVPN)

PPVPN
├── Layer 2
│   ├── P2P → VPWS (Virtual Private Wire Service)
│   └── M2M → VPLS (Virtual Private LAN Service)
└── Layer 3
    ├── PE-based
    │   ├── BGP/MPLS IP VPNs
    │   └── Virtual Router
    └── CE-based
        └── IPsec

4. Grundbegriffe: AC, Pseudowire, Tunnel LSP

Attachment Circuit (AC)

Physischer oder logischer Anschluss zwischen Kundengerät (CE) und Provider-Edge-Router (PE). Kann sein: Ethernet-Port, VLAN, PPP, MPLS LSP, etc.

[CE-Gerät] ---AC--- [PE-Gerät] --- Service Provider Network

Pseudowire (PW)

Ein virtueller „Draht" durch das Provider-Netz, der L2-Daten von einem AC zu einem anderen transportiert.

  • Nur den beiden Endpunkt-PEs bekannt
  • Wird über einen Tunnel (LSP) transportiert, der allen Routern (LSRs) dazwischen bekannt ist
  • Pro Richtung ein unidirektionaler Tunnel → ein PW = 2 LSPs

Tunnel LSP – Label Stacking

Mehrere Pseudowires zwischen zwei PEs werden in einem Tunnel aggregiert:

  • Äußeres Label = Tunnel LSP (für P-Router sichtbar, sorgt für Transport)
  • Inneres Label = Pseudowire LSP (nur PEs kennen es)

P-Router schauen nur auf das äußere Label und leiten entsprechend weiter – sie kennen die VPN-Details nicht.

5. Layer-2-Dienste: VPWS und VPLS

VPWS – Virtual Private Wire Service

  • Point-to-Point: genau ein AC ↔ genau ein PW
  • Transparente L2-Verbindung zwischen zwei Standorten
  • MPLS definiert Labelverteilung und Kapselung
  • Einsatz von LDP (Targeted Mode) oder MP-BGP zur Signalisierung

Forwarding-Beispiel (VPWS):

Ein PE empfängt einen VLAN1-Frame vom Kunden. Er schlägt in seiner FEC-Tabelle nach und findet: VLAN1 → Out-Label 24, Next-Hop 1.1.1.1. Zusätzlich drückt er ein Transport-Label (z.B. 16) obendrauf. Der Transit-Router (LSR) sieht nur das Transport-Label und leitet weiter. Der Egress-PE entfernt das äußere Label, erkennt anhand des inneren Labels (24) die Ziel-Schnittstelle und sendet den Frame an den Kunden.

VPWS Protection – Auslöser für Umschaltung auf Standby-PW:

  • Manueller Eingriff (Precedence-Wert ändern)
  • Statusänderung des PW
  • Ausfall des aktiven PW
  • Benachrichtigung vom Remote-Peer (via T-LDP Notification Message)

VPLS – Virtual Private LAN Service

  • Multipoint-to-Multipoint: mehrere Standorte agieren wie in einem gemeinsamen Ethernet-LAN
  • Jeder PE enthält ein Switch-Modul mit einem emulierten LAN (MAC-Learning, Flooding)
  • Standorte tauschen Ethernet-Frames direkt aus, als wären sie physisch im selben LAN

Architektur:

[Kunde CE] --AC--> [PE: VPLS Forwarder + Emulated LAN Interface]
                         <------ VPLS PW ------>
                                              [PE] --AC--> [Kunde CE]

Skalierungsproblem: Bei N Standorten braucht man N(N-1)/2 Pseudowires* (Vollvermaschung). Bei vielen Standorten entstehen viele States und viel Broadcast-Traffic.

Lösung: Hierarchisches VPLS (H-VPLS)

PE-Router werden in zwei Ebenen aufgeteilt:

Ebene Gerät Aufgabe
Kern Hub-PE Vollvermaschung zwischen Hubs
Rand Spoke-PE / MTU-s Aggregiert Kundenports zu einer einzigen Spoke-PW zum Hub
  • Neue Verbindung nur zwischen Spoke und Hub, kein direktes Mesh zwischen allen Spokes
  • Vorteile: Weniger PWs, weniger Broadcast-Replikation, bessere Skalierbarkeit

Multi-Tenant Unit (MTU-s): Gerät (Router, Switch oder Gateway), das viele Kundenports aggregiert und eine einzige Spoke-PW zum nächsten PE aufbaut.

Dual Homed MTUs: MTU ist an zwei PEs angebunden → Redundanz bei Ausfall einer Verbindung.

VPLS Auto-Discovery (RFC 4761): PE-Router erkennen automatisch andere PEs derselben VPLS-Domäne via MP-BGP, ohne manuelle Konfiguration jedes einzelnen Pseudowires.

VPLS Protection: Backup-LSPs werden über T-LDP aufgebaut; Überwachung via BFD (Bidirectional Forwarding Detection).

VPLS und MTU-Größen:

Pakettyp L2 MTU
Normales MPLS-Paket 1504
Ethernet over VPLS 1508
VLAN over VPLS 1526

VPLS fügt zusätzliche Header ein (MPLS-Label + VPLS-Label), was die MTU erhöht. Alle Geräte im Pfad müssen diese größeren Frames unterstützen.

6. Layer-3-VPNs: BGP/MPLS IP VPNs (RFC 4364)

Motivation

  • Kunden nutzen private IP-Adressen (RFC 1918) → können sich überschneiden
  • Provider übernimmt das Routing → Kunde muss sich nicht darum kümmern
  • MPLS-Backbone ist für den Kunden transparent

Beteiligte Geräte

Gerät Aufgabe
CE (Customer Edge) Kundenrouter, kennt nur seine eigene Seite
PE (Provider Edge) Kennt VPN-Routen; verwaltet VRFs; stellt MPLS-Pfade auf
P (Provider Core) Reine Transitknoten; kennen keine VPNs, nur MPLS-Labels

VRF – VPN Routing and Forwarding Table

Jeder PE führt separate Routing-Tabellen pro Kunde (VRF). Diese werden via MP-BGP zwischen den PEs ausgetauscht.

Problem: BGP kann normalerweise nur eine Route pro IP-Präfix installieren – aber verschiedene Kunden können dieselben Adressen haben.

Lösung: Route Distinguisher (RD)

Route Distinguisher (RD)

Ein 8-Byte-Präfix, der jeder VPN-Route vorangestellt wird, um sie global eindeutig zu machen:

[Type 2B] [Administrator 2-4B] [Assigned Number 2-4B] + [IPv4-Adresse 8B] = 12 Bytes

Beispiele:

RD: 65000:101       (AS-Nummer : zugewiesene Nummer)
RD: 10.0.0.1:1001  (IP-Adresse : zugewiesene Nummer)
RD: 1000000:10

Ergebnis: Aus 192.168.1.10 wird die VPNv4-Adresse 65000:1:192.168.1.10 → global eindeutig, kein Konflikt trotz Adressüberlappung.

Wichtig: Der RD macht Adressen nur eindeutig. Er steuert nicht, welche Routen wohin verteilt werden – das macht der Route Target.

Route Target (RT)

Ein BGP Extended Community Attribut (RFC 4360), das steuert, welche Routen in welches VRF importiert/exportiert werden.

Jede VRF hat:

  • Export Target: welcher RT wird angefügt, wenn eine Route exportiert wird
  • Import Target: welche eingehenden Routen werden in diese VRF installiert

Ablauf – 3-Schritt-Beispiel:

Schritt 1 – Export:

PE an VPN1-Site1 empfängt eine IPv4-Route vom CE. Er konvertiert sie zu VPN-IPv4 und hängt RT1 und RT4 an (laut Export-Policy: VRF VPN1 Export = RT1, RT4). Die Route wird an alle PEs verteilt.

Schritt 2 – Import rechts:

Der rechte PE empfängt die Route mit RT1 und RT4 und vergleicht sie mit seinen VRF-Import-Listen:

VRF Import-Liste RT1 Match? RT4 Match? Ergebnis
VPN1 RT1, RT4 ✓ ✓ Route installiert → weiter zu Sites 4, 5
VPN2 RT1, RT2 ✓ – Route installiert → weiter zu Site 3

Schritt 3 – Import links:

Der linke PE vergleicht ebenfalls:

VRF Import-Liste Ergebnis
VPN2 RT1, RT2 RT1 matcht → Route zu Site 2
VPN3 RT3 kein Match → Route ignoriert

Merkhilfe: RD = macht Adressen eindeutig. RT = steuert Routenverteilung (wer darf was sehen).

Site of Origin (SoO)

Optionales Attribut, das die CE-PE-Verbindung identifiziert. Verhindert Routing-Schleifen bei Multi-Homed CEs (CE an mehrere PEs angebunden).

Datenweiterleitnung: Label Stacking

CE1 ---> PE1 ---> P1 ---> P2 ---> PE2 ---> CE2

Schritt 1 – PE1 (Ingress): Empfängt normales IP-Paket von CE1, sucht in der VRF (Longest Prefix Match), findet iBGP-Next-Hop PE2 und drückt zwei Labels auf das Paket:

[ Transport-Label | VPN-Label | IP-Paket ]
  • VPN-Label (innen): identifiziert die Ziel-VRF bei PE2
  • Transport-Label (außen): für den Weg durch den Core zu PE2

Schritt 2 – P-Router: Leiten nur anhand des Transport-Labels weiter – kein VPN-Wissen nötig.

Schritt 3 – PE2 (Egress): Entfernt das Transport-Label, liest das VPN-Label, findet die richtige VRF, leitet das IP-Paket an CE2 weiter.

Penultimate Hop Popping (PHP)

Optimierung: Der vorletzte Router (P2) entfernt bereits das Transport-Label, sodass PE2 nur noch das VPN-Label sieht und nur einen einzigen Lookup machen muss statt zwei. PE2 hat dies vorher via LDP beim vorherigen Hop angefordert.

PE1      P1          P2           PE2
[TL|VL|IP] --> [TL|VL|IP] --> [VL|IP] --> [IP]
                         ^ PHP: TL wird hier entfernt

Inter-AS VPN

Wenn VPN-Standorte über mehrere Autonomous Systems (verschiedene Provider) verbunden sind:

Option Beschreibung Label-Austausch
A ASBRs führen VRFs; behandeln sich gegenseitig als CE Kein Label-Austausch zwischen ASBRs
B ASBRs tauschen VPN-Routen via MP-eBGP aus MP-eBGP + Label zwischen ASBRs
C Nur PE-Loopback-Adressen und Label-Bindings via eBGP; PEs kommunizieren direkt eBGP + Label für Transport; MP-iBGP PE ↔ ASBR

BGP/MPLS L3 VPN – Vor- und Nachteile

Vorteile Nachteile
Skalierbare VPN-Architektur Komplex für Provider zu betreiben
SP oder Kunde kann VPN verwalten Kunde hat keine vollständige WAN-Routing-Kontrolle
Vereinfachtes WAN-Routing für Kunden Nur IP-Verkehr unterstützt
QoS/SLA pro VPN möglich (mit MPLS TE) BGP konvergiert langsam (Abhilfe: BFD)
Hohe Verfügbarkeit via MPLS FRR

7. Segment Routing (SR)

Grundprinzip: Source Routing

Beim klassischen MPLS berechnet jeder Router Hop-by-Hop den Weg. Bei Segment Routing legt der Ingress-Router (erster Router) den gesamten Pfad fest und codiert ihn als geordnete Liste von Segmenten im Paket.

Segment: Eine Anweisung für den Router, z.B. „Sende zu Knoten X über den kürzesten Pfad". Segmente werden als SIDs (Segment Identifiers) dargestellt.

SR ist Data Plane Agnostic: funktioniert über MPLS oder IPv6, kombiniert mit IGP (IS-IS, OSPF) oder BGP.

Vergleich Classic MPLS vs. Segment Routing

Classic MPLS Segment Routing
Pfadaufbau LDP / RSVP-TE (separates Protokoll) IGP/BGP (integriert)
Control Plane Komplex (IGP + LDP + RSVP-TE) Vereinfacht (nur IGP/BGP)
State im Core Pro LSP/Flow Nur am Ingress
Traffic Engineering Manuelle TE-LSPs via RSVP-TE Automatisch über Segmentlisten

IGP Segment-Typen

Node/Prefix SID (global)

  • Global gültig in der gesamten SR-Domäne – jeder Router versteht dieselbe SID gleich
  • Pakete werden zum Zielknoten über den kürzesten IGP-Pfad weitergeleitet (normales SPF-Routing)
  • Wird als Index angekündigt → tatsächliches Label = SRGB-Basiswert + Index
Beispiel:
  SRGB = 16000–23999
  Node-SID Index = 41
  → Verwendetes MPLS-Label = 16041

Adjacency SID (lokal)

  • Nur auf dem vergebenden Knoten lokal gültig – andere Router verwenden diese SID nicht
  • Leitet das Paket explizit über eine bestimmte Nachbarverbindung weiter (echtes Source Routing)
  • Wird als absoluter Wert angekündigt (kein Index, direkt das Label)
Beispiel:
  Adjacency SID = 9107
  → Paket wird zwingend über genau diesen Link weitergeleitet

SR Vorteile

Control Plane Vereinfachung:

  • Weniger Protokolle, weniger Abhängigkeiten
  • Automatischer Traffic-Schutz ohne per-Flow-Signalisierung

Traffic Engineering:

  • Kein manuelles Konfigurieren von TE-LSPs nötig
  • Pfade werden automatisch berechnet oder von einem Controller (z.B. via PCEP) vorgegeben
  • Kein State pro Flow im Kernnetz

Software-Defined Networking:

  • Hybrider Ansatz zwischen zentralisierter und verteilter Control Plane
  • Controller kann Pfade/Policies über Southbound-Schnittstellen (z.B. PCEP) vorgeben
  • Keine komplette Neukonstruktion des Netzes nötig

IETF Standards für Segment Routing

Standard Beschreibung
RFC 8402 SR Architektur
RFC 9256 SR Use Cases
RFC 8660 SR über MPLS (SR-MPLS)
RFC 9886 SR über IPv6 (SRv6)

Relevante IETF Working Groups: SPRING, PCE, IDR, 6MAN

Prüfungsinfo
Termin Mo., 4. Mai 2026, 14:00–16:00 Uhr
Räume 6B.369 (inkl. Nachteilsausgleich) und 6B.371
Betreuer Schrenk und Albaradie
Format Klausur (keine praktische Prüfung, außer IT25-Jahrgang)
IT25 Kombinierte Prüfung: Klausur (K) + Laborausarbeitung (L)