# IT2221 – Netzwerktechnik: Vorlesung 6

## Zusammenfassung: Troubleshooting, BGP, MPLS & Ausfallsicherheit

---
## 1. Troubleshooting
### 1.1 Troubleshooting-Methodik (7 Schritte)

|Schritt|Beschreibung|Beispiel|
|---|---|---|
|1|**Problem definieren**|„Was funktioniert nicht?" – PC bekommt keine IP|
|2|**Informationen sammeln**|Show-Befehle ausführen, Logs prüfen|
|3|**Daten analysieren**|Routingtabellen, Nachbarzustände auswerten|
|4|**Hypothese formulieren**|Welche OSI-Schicht ist betroffen?|
|5|**Hypothese testen**|Paketmitschnitte (PCAPs), gezielte Pings|
|6|**Korrektur planen/implementieren**|Konfiguration ändern|
|7|**Überprüfen, testen, dokumentieren**|Funktioniert es jetzt? Änderung festhalten|

### 1.2 Grundlegende Werkzeuge

**Statusinformationen auf Routern/Switches:**

- `show ip route` – Routing-Tabelle anzeigen
- `show ip interface` / `show interface` – Interface-Status und IP-Konfiguration
- `show ip ospf neighbor` / `show ip ospf database` – OSPF-Nachbarschaften und Link-State-Datenbank
- `show dhcp server leases` – Vergebene DHCP-Adressen

**Netzwerk-Diagnose-Tools:**

- **Ping** – Erreichbarkeit testen (ICMP Echo Request/Reply)
- **Traceroute** – Pfad zum Ziel Hop für Hop nachverfolgen
- **Packet Capture (PCAP)** – Paketmitschnitte zur detaillierten Analyse (z. B. mit Wireshark)

### 1.3 Troubleshooting-Szenarien aus dem Labor

**Szenario 1: PC München bekommt keine IP-Adresse**

- **Fehler A – Helper-Adresse auf falschem Interface:** Der Router München hat die `ip helper-address` auf dem falschen Interface konfiguriert. DHCP-Discover-Pakete kommen zwar vom Switch an, werden aber nicht Richtung Nürnberg (wo der DHCP-Server erreichbar ist) weitergeleitet.
- **Fehler B – Helper-Adresse verweist auf falsche IP:** Die `ip helper-address` zeigt auf eine falsche Ziel-IP. Das Relayed-Discover-Paket erreicht den DHCP-Server nicht, weil die Ziel-IP nicht stimmt → kein DHCP-Offer kommt zurück.

**Szenario 2: PC München kann PC Düsseldorf nicht erreichen**

- **Fehler A – OSPF-Area Mismatch:** München und Nürnberg haben unterschiedliche OSPF-Area-IDs auf ihrem gemeinsamen Link konfiguriert → keine OSPF-Nachbarschaft → keine Routen werden ausgetauscht. Erkennbar in den OSPF-Hello-Paketen, wo die Area-ID nicht übereinstimmt.
- **Fehler B – Fehlende OSPF-Aktivierung auf einem Interface:** Auf dem Interface Richtung Magdeburg wurde OSPF nicht aktiviert (`network`-Statement fehlt) → keine OSPF-Hello-Pakete auf diesem Link → Magdeburg/Düsseldorf sind nicht erreichbar.

**Szenario 3: Magdeburg und Düsseldorf bauen keine OSPF-Nachbarschaft auf**

- **Fehler A – Hello/Dead Timer Mismatch:** Beide Router senden OSPF-Hellos, aber mit unterschiedlichen Timer-Werten (z. B. Hello 10s vs. 30s). OSPF verlangt identische Hello- und Dead-Timer auf beiden Seiten eines Links → keine Nachbarschaft.
- **Fehler B – Falsche Subnetzmaske auf dem Link:** Die Router haben unterschiedliche Subnetzmasken auf dem gemeinsamen Link konfiguriert. OSPF prüft im Hello-Paket, ob die Subnetzmaske übereinstimmt → Mismatch → keine Nachbarschaft.

### 1.4 Troubleshooting-Ansätze (aus Referenzdokument)

**Bottom-Up (L1 → L7):** Für Totalausfälle oder neue Netze. Von der physischen Schicht nach oben arbeiten – erst Kabel, dann IP, dann Routing-Protokolle.

**Top-Down (L7 → L1):** Wenn bestimmte Dienste ausfallen, aber andere funktionieren. Z. B. Webseite geht nicht, aber Teams läuft → L1–L3 sind okay, Problem liegt höher (DNS? Firewall? Port 443 blockiert?).

**Divide and Conquer:** Erfahrener Ansatz. Man springt direkt auf Layer 3 (Ping/Traceroute). Ping geht? → Fehler liegt auf L4–L7. Ping geht nicht? → Fehler liegt auf L1–L2.

### 1.5 Wichtige Troubleshooting-Befehle (Zusammenfassung)

**Endgeräte (Windows):**

- `ipconfig /all` – IP, Subnetzmaske, Gateway, DNS
- `tracert <IP>` – Pfadverfolgung
- `arp -a` – ARP-Cache
- `route print` – Lokale Routing-Tabelle
- `nslookup <Domain>` – DNS-Test

**Endgeräte (Linux):**

- `ip a` – Interface-Status und IPs
- `traceroute <IP>` oder `mtr <IP>` – Pfadverfolgung
- `ip neigh` – ARP-Tabelle
- `ip route` – Routing-Tabelle
- `dig <Domain>` – DNS-Abfrage

**Cisco Router/Switch – Interfaces (L1/L2):**

- `show ip interface brief` – Übersicht aller Interfaces mit Status (Up/Down)
- `show interfaces <Interface>` – Detailinfos inkl. Fehler (CRC, Drops, Duplex)
- `show lldp neighbors` / `show cdp neighbors` – Direkt verbundene Nachbarn
- `show mac address-table` – MAC-Adressen an Switchports
- `show spanning-tree` – STP-Status (blockierte Ports?)

**Cisco Router – Routing (L3):**

- `show ip route` – Komplette Routing-Tabelle (O = OSPF, B = BGP, C = Connected, S* = Default)
- `show ip route <IP>` – Welches Interface wird für ein bestimmtes Ziel benutzt?
- `ping <Ziel> source <Quell-IP>` – Ping mit definierter Quell-IP (simuliert Traffic aus einem bestimmten Netz)
- `show ip arp` – ARP-Tabelle des Routers
- `show ip dhcp binding` – Vergebene DHCP-Leases
- `show ip nat translations` – Aktive NAT-Übersetzungen

**OSPF-spezifisch:**

- `show ip ospf neighbor` – Nachbarn und Status (muss FULL oder 2WAY sein; EXSTART/INIT/DOWN = Fehler)
- `show ip ospf interface brief` – Auf welchen Interfaces läuft OSPF, in welcher Area?
- `show ip route ospf` – Nur OSPF-gelernte Routen
- `show ip ospf database` – LSA-Datenbank
- `clear ip ospf process` – OSPF-Prozess neu starten (Achtung: kurze Unterbrechung)

**BGP-spezifisch:**

- `show ip bgp summary` – BGP-Nachbarn und Status (Zahl = Up; Idle/Active = Fehler)
- `show ip bgp` – BGP-Tabelle (`*>` = Valid and Best)
- `show ip bgp neighbors <IP> advertised-routes` – Was sende ich dem Nachbarn?
- `show ip bgp neighbors <IP> received-routes` – Was empfange ich vom Nachbarn?
- `clear ip bgp * soft` – Route Refresh ohne Session-Abbruch

---

## 2. Border Gateway Protocol (BGP)

### 2.1 Internet in Zahlen (Stand 20.03.2026, Vergleichswerte 2024)

|Metrik|2026|2024|
|---|---|---|
|Anzahl Prefixes (Netze)|1.064.462|947.805|
|Routing-Tabellen-Einträge|600.307|530.557|
|Autonome Systeme|78.423|75.746|
|Größtes AS (Prefixes)|16.509 (Amazon-02, US)|–|
|Größter Adressraum|227.731.200 /32 – AS749 DNIC (US DoD)|–|

Ein **Prefix** ist ein IP-Adressbereich, den ein AS über BGP ankündigt. Tagesaktuelle Zahlen: https://www.cidr-report.org

### 2.2 Grundlagen

BGP ist **das** Routing-Protokoll des Internets. Es verbindet Autonome Systeme (AS) miteinander.

**Kernmerkmale:**

- Standardisiert in **IETF RFC 4271** (Januar 2006)
- **Path-Vector-Protokoll** – Router kennen den vollständigen AS-Pfad zu jedem Ziel, nicht nur den nächsten Hop
- Kommuniziert über **TCP Port 179** (Anwendungsschicht, nutzt Transportschicht)
- Überträgt **Netzmasken** (Classless – CIDR)
- Nachbarschaften müssen **manuell konfiguriert** werden (kein Auto-Discovery wie bei OSPF)
- **Kein Load Balancing** – BGP wählt immer genau einen besten Pfad
- Routen müssen **stabil** sein (Flapping wird bestraft)
- **Authentifizierung** der Nachbarn ist möglich (MD5)
- Ein Router gehört immer zu **genau einem AS**

### 2.3 Path-Vector-Protokoll

Im Gegensatz zu Distance-Vector (z. B. RIP) oder Link-State (z. B. OSPF) speichert BGP den **kompletten Pfad** (Folge von AS-Nummern) zu jedem Ziel.

**Vorteile:**

- **Schleifenerkennung:** Wenn ein Router seine eigene AS-Nummer im AS_PATH eines empfangenen Updates sieht, verwirft er die Route sofort.
- **Routingtabelle klein halten:** Pro Interface wird nur der kürzeste Pfad weitergegeben.

### 2.4 BGP-Nachrichtentypen (RFC 4271)

|Typ|Name|Funktion|
|---|---|---|
|1|**OPEN**|Erste Nachricht nach TCP-Verbindungsaufbau. Enthält AS-Nummer, Hold-Timer, Router-ID. Antwort ist ein KEEPALIVE.|
|2|**UPDATE**|Enthält die eigentlichen Routing-Informationen. Kann neue Routen ankündigen und veraltete zurückziehen. Ermöglicht Sicht auf die gesamte AS-Topologie und Erkennung von Routing-Schleifen.|
|3|**NOTIFICATION**|Meldet Fehlersituationen (z. B. Timer Expiry, ungültige Nachrichten). Führt zum **Abbruch** der BGP-Verbindung.|
|4|**KEEPALIVE**|Periodische Nachrichten zum Erhalt der Verbindung. Wird regelmäßig gesendet, damit der Nachbar weiß, dass die Session noch aktiv ist.|

### 2.5 BGP-Wegewahl: Pfadauswahl über Attribute

BGP wählt den besten Pfad in einem **9-stufigen Verfahren**. Die drei wichtigsten Attribute:

**LOCAL_PREF (Local Preference):**

- Bestimmt den bevorzugten Ausgangsweg aus dem eigenen AS
- **Höchster Wert gewinnt**
- Wird nur innerhalb eines AS (iBGP) ausgetauscht
- Beispiel: Zwei Uplinks zu verschiedenen Providern → LOCAL_PREF 200 auf dem bevorzugten, 100 auf dem Backup

**AS_PATH:**

- Liste aller AS-Nummern, die ein Update durchlaufen hat
- **Kürzester Pfad (wenigste AS-Hops) gewinnt**
- Manipulation möglich durch **AS-Path-Prepending**: Eigene AS-Nummer mehrfach anhängen, um einen Pfad länger (und damit unattraktiver) erscheinen zu lassen
- Dient gleichzeitig der Schleifenvermeidung

**Multi_Exit_Disc (MED – Multi Exit Discriminator):**

- Wird benutzt, wenn es **mehrere Verbindungen zum selben Nachbar-AS** gibt
- Teilt dem Nachbar-AS mit, über welchen Eingang Traffic bevorzugt empfangen werden soll
- **Niedrigster Wert gewinnt**

### 2.6 BGP-Wegewahl: Vollständige Reihenfolge

|Prio|Kriterium|Auswahl|
|---|---|---|
|1|**LOCAL_PREF**|Höchster Wert|
|2|Lokal erzeugte Routen|Eigene Routen bevorzugt|
|3|**AS_PATH**|Kürzester Pfad|
|4|**ORIGIN**|IGP (i) vor EGP (e) vor Incomplete (?)|
|5|**MED**|Niedrigster Wert|
|6|**eBGP vor iBGP**|Extern gelernte Routen bevorzugt|
|7|Kürzester IGP-Weg zum Nachbarn|Nächstliegender BGP-Nachbar|
|8|Kleinste Router-ID|Tiebreaker|
|9|Kleinste Nachbar-IP|Letzter Tiebreaker|

**Konvergenzzeit:** BGP benötigt **mehrere Minuten** zur Konvergenz (deutlich langsamer als OSPF). BGP trägt immer nur **eine Route pro Netz** in die allgemeine Routing-Tabelle ein.

### 2.7 Verbindung zwischen Providern: Transit und Peering

**Transit:**

- Übermittlung von Daten zwischen einem AS und dem Internet **gegen Bezahlung**
- Der Transit-Provider leitet Traffic an alle Ziele im Internet weiter
- Typisch: Kleiner Provider kauft Transit bei größerem Provider

**Peering:**

- Vereinbarung zum **gegenseitigen Datenaustausch** zwischen zwei AS und deren angeschlossenen Netzen
- In der Regel **ohne Bezahlung** (Settlement-free Peering)
- **Privates Peering:** Direkte Verbindung zwischen zwei AS
- **Öffentliches Peering:** Über einen Internet Exchange Point (IXP, z. B. DE-CIX in Frankfurt)

### 2.8 Provider-Hierarchie (ISP-Tiers)

|Tier|Beispiele|Reichweite|Verbindungsart|
|---|---|---|---|
|**Tier 1**|Deutsche Telekom, AT&T, Orange, NTT|International/landesweit|**Nur Peering** (kaufen keinen Transit)|
|**Tier 2**|Vodafone, Swisscom, 1&1, DFN|Landesweit|**Peering und Transit**|
|**Tier 3**|wilhelm.tel, M-Net, EWE TEL|Regional/lokal|**Hauptsächlich Transit**, selten Peering|

### 2.9 BGP-Anbindung an Provider

**Single Homed:**

- Eine Verbindung zu einem Provider
- Optionen: Statische Routen oder BGP (bei häufigen Änderungen im eigenen Netz)
- **Private AS-Nummer** ausreichend (64512–65534)

**Dual Homed:**

- **Mehrere Verbindungen** zu **einem** Provider (Redundanz)
- BGP oder statische Routen
- **Private AS-Nummer** ausreichend

**(Dual) Multi Homed:**

- Verbindungen zu **mehreren Providern**
- **BGP-Routing erforderlich** (um optimale Pfadwahl zwischen den Providern zu ermöglichen)
- **Öffentliche AS-Nummer** erforderlich (wird bei einer RIR wie RIPE beantragt)

### 2.10 iBGP vs. eBGP

|Eigenschaft|iBGP|eBGP|
|---|---|---|
|Definition|Beide Nachbarn im **gleichen** AS|Beide Nachbarn in **unterschiedlichen** AS|
|Verbindung|Nicht direkt verbunden nötig, Erreichbarkeit über **IGP** (OSPF/IS-IS)|Nachbarn sind **direkt verbunden**|
|Einsatz|Innerhalb eines ISP-Netzes|Zwischen verschiedenen ISPs|

**Problem bei iBGP:** Alle BGP-Router innerhalb eines AS müssen eine **Vollvermaschung** (Full Mesh) aufbauen. Bei n Routern sind das **n × (n-1) / 2** Sessions. Das skaliert schlecht.

### 2.11 iBGP Route-Reflector

**Problem:** Vollvermaschung bei vielen BGP-Routern (z. B. 100 Router → 4.950 Sessions).

**Lösung:** Ein Router wird zum **Route-Reflector (RR)** bestimmt. Alle anderen Router (Route-Reflector Clients) bauen nur eine Nachbarschaft zum RR auf. Der RR leitet empfangene BGP-Updates an alle Clients weiter.

- Reduziert die Anzahl der Sessions auf **n - 1**
- Beispiel: 4 Router → statt 6 Sessions (Full Mesh) nur 3 Sessions (Stern-Topologie mit RR)

### 2.12 Administrative Distanz

Die Administrative Distanz (AD) bestimmt, welches Routing-Protokoll bevorzugt wird, wenn **mehrere Protokolle Routen zum gleichen Ziel** anbieten. Niedrigerer Wert = höheres Vertrauen.

|Quelle|AD|
|---|---|
|Connected Interface|0|
|Static Route|1|
|EIGRP Summary|5|
|**External BGP**|**20**|
|Internal EIGRP|90|
|IGRP|100|
|**OSPF**|**110**|
|IS-IS|115|
|RIP|120|
|EGP|140|
|External EIGRP|170|
|**Internal BGP**|**200**|
|Unknown|255|

**Wichtig:** eBGP (AD 20) wird gegenüber OSPF (AD 110) bevorzugt. iBGP (AD 200) verliert aber gegen OSPF – das verhindert Routing-Schleifen innerhalb eines AS.

Die AD hat **lokale Bedeutung** und wird nicht in Routing-Updates übertragen. Eine Umrechnung zwischen den Metriken verschiedener Protokolle ist nicht möglich.

### 2.13 Redistribution (Umverteilung)

Redistribution verbindet verschiedene Routing-Protokolle miteinander, z. B. OSPF-Routen nach BGP weiterleiten und umgekehrt.

- Befehl: `redistribute <Protokoll>` (z. B. `redistribute connected`, `redistribute ospf`)
- **Beide Richtungen müssen konfiguriert werden!** Nur OSPF → BGP ohne BGP → OSPF bedeutet, dass der Rückweg fehlt.
- Findet typischerweise auf dem **ASBR** (Autonomous System Boundary Router) statt

---

## 3. MPLS (Multiprotocol Label Switching)

### 3.1 Überblick und Einsatz

MPLS wird primär in **Service-Provider-Netzen** (Carrier-Netze) eingesetzt. Endkunden (Unternehmen, Privathaushalte) sehen in der Regel keinen MPLS-Verkehr.

**Hauptfunktion:** MPLS bietet Mechanismen für Ethernet- und IP-basierte **Virtual Private Networks (VPNs)** auf Layer 2 und Layer 3. Damit können Provider über eine gemeinsame Infrastruktur isolierte Kundennetze bereitstellen.

### 3.2 Grundkonzept: Labels statt IP-Lookup

Bei klassischem IP-Routing muss **jeder Router** für jedes Paket einen Longest-Prefix-Match in der Routing-Tabelle durchführen. MPLS ersetzt diesen aufwändigen Vorgang durch ein **Label-basiertes Switching:**

1. Die Routing-Entscheidung wird **einmalig am Eintrittspunkt** (Ingress-Router/LER) getroffen
2. Dort wird dem Paket ein **Label** zugewiesen
3. Alle weiteren Router im MPLS-Netz (LSR) leiten das Paket nur noch anhand des Labels weiter – **kein IP-Lookup mehr nötig**
4. Am Austrittspunkt (Egress-Router/LER) wird das Label wieder entfernt

### 3.3 MPLS-Terminologie

|Begriff|Bedeutung|
|---|---|
|**LSR** (Label Switch Router)|Router im MPLS-Kern, der Pakete anhand von Labels weiterleitet|
|**LER** (Label Edge Router)|Router am Rand des MPLS-Netzes (Ingress = Eingang, Egress = Ausgang)|
|**LSP** (Label Switched Path)|Der vordefinierte Pfad, den gelabelte Pakete durch das MPLS-Netz nehmen|
|**FEC** (Forwarding Equivalence Class)|Gruppe von Paketen, die identisch behandelt werden (z. B. alle Pakete zum selben Zielpräfix)|
|**CE** (Customer Edge)|Kundenrouter am Rand des Kundennetzes|
|**PE** (Provider Edge)|Provider-Router am Rand des Provider-Netzes (= LER)|
|**P** (Provider)|Router im Kern des Provider-Netzes (= LSR)|

### 3.4 MPLS im OSI-/TCP-IP-Modell

Das MPLS-Label (der sog. **MPLS Shim Header**) wird **zwischen Layer 2 (Data Link) und Layer 3 (Network)** eingefügt. MPLS wird deshalb oft als „Layer 2.5"-Protokoll bezeichnet.

Die Signalisierung der Labels erfolgt über verschiedene Protokolle auf unterschiedlichen Schichten (LDP auf L7/TCP, RSVP-TE auf L3/IP, BGP auf L7/TCP).

### 3.5 IP vs. MPLS – Gegenüberstellung

|Ebene|IP|MPLS|
|---|---|---|
|**Data Plane**|Routing-Tabelle, Longest-Prefix-Match für jedes Paket|Label Push, Swap, Pop – kein IP-Lookup im Kern|
|**Control Plane**|Routing-Protokolle (OSPF, BGP)|Erweiterte Routing-Protokolle (OSPF-TE, IS-IS-TE), Label-Verteilungsprotokolle (LDP, RSVP-TE), Discovery-Protokolle (BGP)|

MPLS ist in diversen IETF-RFCs standardisiert: https://datatracker.ietf.org/wg/mpls/documents/

### 3.6 MPLS Label Format (RFC 3032)

Das MPLS-Label ist **32 Bit** lang und besteht aus 4 Feldern:

```
|<-------------- 32 Bits ----------------->|
| Label Value (20 Bit) | TC (3 Bit) | S (1 Bit) | TTL (8 Bit) |
```

**Label Value (20 Bit):** Der eigentliche Label-Wert. Ermöglicht 2²⁰ = 1.048.576 verschiedene Labels.

**TC – Traffic Class (3 Bit):** Ehemals „EXP" (Experimental). Wird für MPLS DiffServ (Quality of Service) genutzt, um die Class of Service (CoS) oder Drop Precedence zu speichern. Wenn DiffServ deaktiviert ist, hat das Feld keine Bedeutung.

**S – Bottom of Stack (1 Bit):** Zeigt an, ob dies das **letzte (unterste) Label** im Label Stack ist. S = 1 → letztes Label. S = 0 → weitere Labels folgen darunter.

**TTL – Time To Live (8 Bit):** Verhindert Endlosschleifen, wird wie beim IP-TTL bei jedem Hop dekrementiert.

### 3.7 Reservierte Label-Werte

|Wert|Bezeichnung|Funktion|
|---|---|---|
|0|**Explicit Null (IPv4)**|Signalisiert, dass nach dem Label ein IPv4-Header folgt. Muss am Penultimate Hop entfernt werden.|
|1|**Router Alert**|Paket wird an die lokale Software-Instanz des Routers übergeben|
|2|**Explicit Null (IPv6)**|Wie Label 0, aber für IPv6-Header|
|3|**Implicit Null**|Signalisiert dem vorletzten Router, das Label zu entfernen (Penultimate Hop Popping)|
|4–15|Reserviert|Für zukünftige Nutzung (RFC 3032), davon 13 = GAL (RFC 5586), 14 = OAM Alert (RFC 3429)|
|16–2²⁰|**Normal Labels**|Normaler Label-Swap-Betrieb|

### 3.8 MPLS Label Stack

Ein MPLS-Paket kann **mehrere Labels übereinander gestapelt** tragen (Label Stack). Das ermöglicht LSP-Hierarchien (z. B. Transport-Label + VPN-Label).

**Beispiel eines Label Stacks:**

```
Top Label:          Label = 40,   TC = 000, S = 0, TTL = 22
Intermediate Label: Label = 3343, TC = 000, S = 0, TTL = 60
Bottom Label:       Label = 202,  TC = 000, S = 1, TTL = 64   ← S-Bit = 1!
                    [IP-Paket]
```

Regeln:

- Alle Labels außer dem letzten haben **S = 0**
- Nur das unterste Label hat **S = 1**
- Der LSR prüft das S-Bit, bevor er ein Label entfernt

### 3.9 Label-Operationen

|Operation|Wo|Beschreibung|
|---|---|---|
|**Push**|Ingress LER|Label wird auf das Paket aufgesetzt (Paket betritt MPLS-Netz)|
|**Swap**|LSR (Kern)|Eingehendes Label wird durch ausgehendes Label ersetzt|
|**Pop**|Egress LER|Label wird entfernt, darunter liegt das IP-Paket (oder nächstes Label)|

### 3.10 MPLS Forwarding Matrix (Label Switching)

Jeder LSR pflegt eine **MPLS Forwarding Matrix** mit den Spalten: FEC, In Label, Out Label, Next Hop, Action.

**Ingress LER (Push):** Kein Incoming Label, nur Outgoing Label.

|FEC|In Label|Out Label|Next Hop|Action|
|---|---|---|---|---|
|10.1.1/24|–|20|LSR2|Push|

**Transit LSR (Swap):** Incoming und Outgoing Label.

|FEC|In Label|Out Label|Next Hop|Action|
|---|---|---|---|---|
|10.1.1/24|50|40|LSR4|Swap|

**Egress LER (Pop):** Incoming Label, kein Outgoing Label.

|FEC|In Label|Out Label|Next Hop|Action|
|---|---|---|---|---|
|10.1.1/24|40|–|CE2|Pop/Route|

### 3.11 Label-Zuweisung und -Verteilung

**Bidirektionale Kommunikation:** Für jede Richtung wird ein **separater LSP** aufgebaut. Der Hinweg (Forwarding Path) wird vom Ingress-LER angefragt, der Rückweg (Reverse Path) vom gegenüberliegenden LER. Hin- und Rückweg können **unterschiedliche Pfade** nehmen.

**Ablauf der Label-Verteilung (Beispiel):**

1. CE2 kündigt neues Netz 10.1.1/24 an → LSR4 (Egress) erstellt FEC A
2. LSR4 bindet Label 40 an FEC A und verteilt dieses Binding an seine Nachbarn (LSR3, LSR5)
3. Jeder Downstream-LSR lernt das Binding, erstellt sein eigenes lokales Label und verteilt es weiter (LSR5: Label 50, LSR3: Label 30)
4. Prozess setzt sich fort bis zum Ingress-LER (LSR1), der das Netz 10.1.1/24 nun über den kompletten LSP erreichen kann

### 3.12 Signalisierungsprotokolle

MPLS benötigt Signalisierungsprotokolle, um Labels zu verteilen und LSPs aufzubauen. Es gibt drei Hauptprotokolle:

#### 3.12.1 LDP (Label Distribution Protocol)

- **Einsatz:** Einfache MPLS-Topologien ohne Traffic Engineering oder QoS-Anforderungen. Am weitesten verbreitet für grundlegende Label-Verteilung.
- **OSI-Schicht:** Layer 7 (Anwendungsschicht), nutzt **TCP Port 646**
- **Nachbarschaftserkennung:** Über **Hello-Nachrichten** (UDP, Multicast). Nach Erkennung wird eine TCP-Sitzung aufgebaut.
- **Zuverlässige Übertragung:** Über TCP gesichert
- **Eine Sitzung pro Nachbar**, kein kontinuierlicher Austausch von Statusinformationen

**Zwei Betriebsmodi:**

|Modus|Beschreibung|
|---|---|
|**L-LDP (Link-LDP)**|Sitzung zwischen **direkt benachbarten** Routern (gleicher L2/L3-Link)|
|**T-LDP (Targeted-LDP)**|Sitzung zwischen **nicht direkt benachbarten** Routern (mehrere IP-Hops dazwischen). Sitzung wird über IP-Routing aufgebaut, nicht über physische Verbindung.|

**Label-Verteilung über LDP:**

1. LSR A sendet **Label Request** an LSR B
2. LSR B sendet **Label Mapping** (z. B. Label 37) zurück an LSR A
3. Prozess wiederholt sich Hop für Hop bis zum Egress

**Label Mapping enthält:** Label-Wert, FEC (Forwarding Equivalence Class) und Next Hop.

**LSP-Aufbau:** Topology-Driven – LSPs basieren auf der Netzwerk-Topologie.

#### 3.12.2 RSVP-TE (Resource Reservation Protocol – Traffic Engineering)

- **Einsatz:** Netzwerke mit **Traffic Engineering** und **QoS-Anforderungen**. Große Unternehmens- und SP-Netze. Ermöglicht Reservierung von Ressourcen (Bandbreite) für Echtzeitanwendungen.
- **OSI-Schicht:** Layer 3 (Network), wird über **IP übertragen (Protokollnummer 46)**
- **Standardisiert:** RSVP in RFC 2205/2209 (1997), RSVP-TE-Erweiterungen in RFC 3209
- Signalisierungsnachrichten werden **regelmäßig erneut gesendet**, um Reservierungen aktiv zu halten (Soft State)
- Da RSVP-TE die Traffic-Zuordnung zu einem LSP lokal am Ingress-LSR vornimmt, spricht man bei RSVP-TE-LSPs von **„Tunneln"**

**Pfadaufbau mit RSVP-TE:**

1. **PATH-Nachricht:** Vom Ingress-LSR zum Egress-LSR. Fordert Erstellung eines LSP mit bestimmten QoS-Parametern an. Kann eine **explizite Route (ERO)** vorgeben.
2. **RESV-Nachricht:** Vom Egress zurück zum Ingress (Hop für Hop). Bestätigt erfolgreiche Ressourcenreservierung. Enthält das zugewiesene Label. Der LSP ist aktiv, wenn der Ingress-LSR ein gültiges RESV erhält.

**LSP-Aufbau:** Data-Driven – LSPs werden dynamisch basierend auf aktuellen Datenströmen angepasst.

#### 3.12.3 MP-BGP (Multiprotocol BGP)

- **Einsatz:** MPLS-L3-VPNs, Inter-Domain-Routing zwischen autonomen Systemen. Skaliert über große Netze.
- **OSI-Schicht:** Layer 7 (Anwendungsschicht), nutzt **TCP Port 179**
- Erweiterung des BGP-Protokolls für **IPv4, IPv6 und MPLS**
- **Nachbarschaftsbildung:** Über TCP-Handshake – **keine Hello-Pakete** (anders als OSPF/LDP)
- Tauscht **VPN-Labels** und Kundenstandort-Routen über das MPLS-Netz aus

**Wichtige Attribute und Elemente:**

|Element|Beschreibung|
|---|---|
|**AFI** (Address Family Identifier, 16 Bit)|1 = IPv4, 2 = IPv6, 25 = MPLS (VPNs)|
|**SAFI** (Subsequent AFI, 8 Bit)|1 = Unicast, 128 = VPNv4, 132 = VPNv6|
|**VPN-Label**|Label in den Update-Nachrichten für MPLS-VPNs|
|**Route Distinguisher (RD)**|Wird als Präfix zu IP-Adressen hinzugefügt, um Eindeutigkeit in verschiedenen VPNs sicherzustellen|

### 3.13 Vergleich der Signalisierungsprotokolle

|Eigenschaft|LDP|RSVP-TE|MP-BGP|
|---|---|---|---|
|**Haupteinsatz**|Einfache Label-Verteilung|Traffic Engineering, QoS|MPLS-VPNs, Inter-Domain|
|**Transport**|TCP Port 646|IP Protokoll 46|TCP Port 179|
|**OSI-Schicht**|Layer 7|Layer 3|Layer 7|
|**Nachbarerkennung**|Hello-Nachrichten (UDP)|Über IGP|TCP-Handshake|
|**QoS-Unterstützung**|Nein|Ja (Ressourcenreservierung)|Indirekt (über VPN-Zuordnung)|
|**LSP-Aufbau**|Topology-Driven|Data-Driven|VPN-spezifisch|

### 3.14 Layer 2/3 Services – MPLS-Signalisierung

Für Kunden-VPN-Services werden **zwei Signalisierungsprotokolle** eingesetzt:

- **Targeted-LDP (T-LDP)** – für L2-VPNs (Pseudowires)
- **Multiprotocol-BGP (MP-BGP)** – für L3-VPNs (IP-VPNs)

Beide sind in der Forwarding Plane identisch (gleiche Label-Operationen) und **unabhängig** von der Signalisierung des darunterliegenden Transport-LSPs (der z. B. über RSVP-TE aufgebaut sein kann).

Die Signalisierungssession besteht zwischen den **LERs/PEs** (Provider Edge Routern) – die Transit-Router (P-Router/LSRs) im Kern sind nicht beteiligt.

---

## 4. Ausfallsicherheit in Netzen

### 4.1 Grundprinzipien

Drei Säulen der Ausfallsicherheit:

1. **Fehlererkennung** – Ausfall schnell bemerken
2. **Schnelle Konvergenz** – Routing-Protokolle müssen schnell reagieren
3. **Umschalten auf alternative Wege** – Backup-Pfade müssen vorbereitet sein

Schlüsseltechnologien: **BFD** (Bidirectional Forwarding Detection) und **FRR** (Fast Reroute).

### 4.2 BFD (Bidirectional Forwarding Detection)

BFD ist ein **protokollunabhängiges** Netzwerkprotokoll zur **schnellen Erkennung von Verbindungsausfällen**. Es arbeitet deutlich schneller als die eingebauten Mechanismen von OSPF oder BGP.

**Standardisiert in:**

- **RFC 5880** – Grundlegende BFD-Mechanismen und Protokolle (August 2010)
- **RFC 5881** – BFD für IPv4 und IPv6 (August 2010)

**OSI-Einordnung:**

- **Layer 4 (Transport):** BFD nutzt **UDP Port 3784** für Hello-Pakete
- **Layer 3 (Netzwerk):** BFD interagiert mit IP-Adressen und Routing-Protokollen

**Funktionsweise:**

1. **Heartbeat-Mechanismus:** BFD sendet regelmäßig Hello-Pakete mit sehr kurzen Intervallen (typisch **50 ms**)
2. **Timeout-Mechanismus:** Wenn innerhalb des konfigurierten Timeouts keine BFD-Nachricht empfangen wird, gilt die Verbindung als ausgefallen
3. **Schnelle Reaktion:** Ermöglicht sofortige Aktivierung alternativer Pfade

**Zustandsmaschine:**

|Zustand|Bedeutung|
|---|---|
|**Down**|Verbindung ist nicht aktiv oder nicht erreichbar|
|**Init**|Verbindung hat gerade begonnen, Nachrichten auszutauschen|
|**Up**|Verbindung ist aktiv und funktionsfähig|

Nach einem Timeout wechselt der Zustand auf **Down**.

**Fehlermeldung und Reaktion:**

- BFD **benachrichtigt die Routing-Protokolle** (OSPF, BGP), damit diese Routen aktualisieren oder entfernen
- Bei vorhandener Redundanz: **Automatische Umschaltung** auf Backup-LSP oder alternativen Pfad
- Benutzer bemerken idealerweise **keine Unterbrechung**

**BFD in L2- und L3-MPLS:**

|Kontext|Funktion|
|---|---|
|**L2 MPLS**|Überwacht Verbindung zwischen PE-Routern und CE. Schnelle Erkennung ermöglicht sofortige Nutzung alternativer Pfade.|
|**L3 MPLS**|Überwacht IP-basierte Dienste und Verbindungen zwischen Routern mit OSPF/BGP. Beschleunigt die Konvergenz der Routing-Protokolle.|

**BFD-Anwendungsfälle:**

- **IP Routing Protocols:** Schnellerer Trigger für Rerouting als die IGPs selbst liefern können
- **Multi-Hop BFD:** Überwachung von nicht direkt verbundenen Systemen
- **MPLS LSP und Pseudowire:** Health Monitoring, Trigger für Umschaltung auf Backup-LSP (MPLS FRR) oder Backup-Pseudowire

### 4.3 MPLS Fast Reroute (FRR)

FRR schützt **Transport-LSPs** gegen Verbindungs- oder Knotenausfälle und ermöglicht eine Umschaltung im **unter 50 ms-Bereich** (vergleichbar mit SDH-Netzen).

**Voraussetzungen:**

- Traffic-Engineering-Erweiterungen (TE) für IGPs: **OSPF-TE (RFC 3630)** oder **IS-IS-TE (RFC 5305)** – verteilen zusätzliche Verbindungsinformationen (z. B. verfügbare Bandbreite)
- **RSVP-TE (RFC 3209)** für die LSP-Signalisierung mit Label-Informationen
- **CSPF** (Constrained Shortest Path First) für die Pfadberechnung unter Berücksichtigung von Constraints

**RSVP-TE-Erweiterungen für FRR:**

Zwei **neue Objekte:**

|Objekt|Funktion|
|---|---|
|**FAST_REROUTE**|In der PATH-Nachricht. Steuert den Backup-Pfad: Prioritäten, Sitzungsattribute, Bandbreite. Ermöglicht Anforderung von Link- oder Node-Protection.|
|**DETOUR**|Für One-to-One-Backups. Identifiziert den Detour-LSP mit dem Knotenpaar {PLR, MP}.|

Zwei **erweiterte Objekte:**

|Objekt|Funktion|
|---|---|
|**SESSION_ATTRIBUTE**|Gibt gewünschte Bandbreite und Schutzart an|
|**RRO** (Record Route Object)|Informationen über LSPs am Ausfallpunkt und Aufbau neuer End-to-End-LSPs|

**PLR** = Point of Local Repair (Router, der den Ausfall erkennt und umschaltet) **MP** = Merge Point (Router, an dem der Backup-Pfad wieder auf den ursprünglichen Pfad trifft)

### 4.4 FRR Protection Types

#### One-to-One Backup

Jeder geschützte LSP-Pfad verfügt über einen **eigenen, individuellen Backup-LSP** (Detour).

- **Link Protection:** Backup-Pfad umgeht den ausgefallenen Link
- **Node Protection:** Backup-Pfad umgeht den ausgefallenen Knoten (Router) komplett

Vorteil: Granulare Kontrolle pro LSP. Nachteil: Mehr Signalisierungsaufwand.

#### Facility Backup

Alle geschützten LSPs, die das **gleiche Netzwerksegment** durchlaufen, teilen sich **denselben Bypass-Tunnel**.

- **Link Protection:** Ein gemeinsamer Bypass-Tunnel umgeht den ausgefallenen Link für alle betroffenen LSPs
- **Node Protection:** Ein gemeinsamer Bypass-Tunnel umgeht den ausgefallenen Knoten

Vorteil: Effizienter, weniger Bypass-Tunnel nötig. Nachteil: Weniger granulare Kontrolle.

### 4.5 FRR Recovery Methods

|Methode|Ablauf|
|---|---|
|**Local Repair**|1. PLR erkennt Ausfall und schaltet auf Backup-LSP um. 2. Traffic nutzt weiterhin denselben End-to-End-LSP-Pfad (über den lokalen Umweg). Kein Re-Setup des gesamten LSP.|
|**Global Repair**|1. Zuerst Local Repair (sofortige Umschaltung). 2. PLR sendet **PATH ERROR** an den Ingress-LSR. 3. Ingress-LSR berechnet und signalisiert einen **neuen optimalen End-to-End-LSP**. Der lokale Umweg wird dann durch den neuen optimalen Pfad ersetzt.|

### 4.6 Funktionale Komponenten von FRR (Übersicht)

```
MPLS-TE Fast Reroute besteht aus:

├── Path Signaling:       RSVP-TE (RFC 3209)
├── IGP (TE-Erweiterungen):
│   ├── IS-IS TE (RFC 5305)
│   └── OSPF TE (RFC 3630)
├── Path Calculation:     CSPF (Constrained SPF)
├── Failure Detection:
│   ├── Loss of Signal (L1)
│   └── BFD (L3/L4)
├── Protection Types:
│   ├── One-to-One Backup
│   └── Facility Backup
└── Revertive Behavior:
    ├── Local Revertive (zurück zum lokalen Pfad)
    └── Global Revertive (neuer optimaler E2E-Pfad)
```

---

## Prüfungsrelevante Kernpunkte

1. **Troubleshooting:** 7-Schritte-Methodik, Bottom-Up/Top-Down/Divide-and-Conquer, wichtigste Show-Befehle je Schicht
2. **BGP:** Path-Vector, TCP Port 179, 4 Nachrichtentypen (OPEN, UPDATE, NOTIFICATION, KEEPALIVE), 9-stufige Wegewahl (LOCAL_PREF → AS_PATH → MED), Transit vs. Peering, Tier 1/2/3, iBGP vs. eBGP, Route-Reflector, Administrative Distanz
3. **MPLS:** Label-Format (32 Bit: Label/TC/S/TTL), Push/Swap/Pop, FEC, LSP, reservierte Labels (0–3), Label Stack mit S-Bit, Forwarding Matrix
4. **MPLS-Signalisierung:** LDP (TCP 646, L7), RSVP-TE (IP Prot. 46, L3, PATH/RESV), MP-BGP (TCP 179, L7, AFI/SAFI/RD), Link-LDP vs. Targeted-LDP
5. **Ausfallsicherheit:** BFD (UDP 3784, Zustände Down/Init/Up, Heartbeat 50ms), FRR (unter 50ms Umschaltung), One-to-One vs. Facility Backup, Link vs. Node Protection, Local vs. Global Repair