14 KiB
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
1. Troubleshooting Methodology
Strukturiertes Vorgehen bei Netzwerkproblemen (z.B. PC bekommt keine IP, PC erreicht anderes Gerät nicht):
- Problem definieren – Was genau funktioniert nicht?
- Informationen sammeln –
show-Befehle ausführen - Daten analysieren – Routingtabellen, Nachbarzustände prüfen
- Hypothese formulieren – Welche OSI-Schicht ist betroffen?
- Hypothese testen – Paketmitschnitte (PCAPs) auswerten
- Korrektur implementieren
- Ü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) |