hwr-notes/Netzwerke/zusammenfassungen/nw7 - zusammenfassung.md

# 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

<img src="Troubleshooting_Netz.png"  
     alt="Troubleshooting_Netz"  
     style="float: left; margin-right: 10px;" />
     
## 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) |