17 KiB
IT2221 – Prüfungsvorbereitung: Kernthemen mit Erklärungen & Beispielen
1. Troubleshooting
Die 7-Schritte-Methodik
| Schritt | Was tun? |
|---|---|
| 1 | Problem definieren – Was genau geht nicht? Seit wann? Wer ist betroffen? |
| 2 | Informationen sammeln – Show-Befehle, Logs, Topology prüfen |
| 3 | Daten analysieren – Routingtabellen, Nachbarzustände vergleichen |
| 4 | Hypothese formulieren – Welche OSI-Schicht ist schuld? |
| 5 | Hypothese testen – PCAPs, Ping, Traceroute |
| 6 | Korrektur implementieren |
| 7 | Verifizieren & dokumentieren |
Vorgehensstrategien
Bottom-Up – Fange bei Layer 1 an, arbeite dich hoch:
Kabel ok? → Link up? → IP ok? → Routing ok? → App ok? Gut wenn: Das Problem unbekannt ist und man systematisch vorgehen will.
Top-Down – Fange bei Layer 7 an, arbeite dich runter:
App geht nicht? → DNS ok? → TCP-Verbindung ok? → Route ok? → Link ok? Gut wenn: Der User ein konkretes App-Problem meldet.
Divide & Conquer – Fang in der Mitte an (z.B. Layer 3) und entscheide dann ob du rauf oder runter gehst:
Ping zum nächsten Router ok? → Problem ist oben (L4–L7). Ping nicht ok? → Problem ist unten (L1–L2). Gut wenn: Das Netz groß ist und du Zeit sparen willst.
Wichtigste Show-Befehle je Schicht
| OSI-Schicht | Befehl | Was zeigt er? |
|---|---|---|
| L1 (Physical) | show interfaces |
Link up/down, Fehler, Kabelfehler |
| L2 (Data Link) | show mac address-table |
MAC-Tabelle des Switches |
| L2 (Data Link) | show spanning-tree |
STP-Zustand |
| L3 (Network) | show ip route |
Routingtabelle |
| L3 (Network) | show ip ospf neighbor |
OSPF-Nachbarn und deren Zustand |
| L3 (Network) | show bgp summary |
BGP-Nachbarn, Status, Routen |
| L3 MPLS | show mpls forwarding-table |
MPLS Label-Tabelle (FIB) |
| L3 MPLS | show mpls ldp neighbor |
LDP-Nachbarn |
| L4 (Transport) | show ip sockets |
Offene TCP/UDP-Verbindungen |
Beispiel-Szenario: PC bekommt keine IP-Adresse.
Schritt 1: Problem klar → DHCP funktioniert nicht
Schritt 2: show ip interface brief → Interface up?
show ip dhcp pool → DHCP-Pool konfiguriert?
show ip dhcp binding → Gibt es Zuweisungen?
Schritt 3: Kein Pool vorhanden → Hypothese: DHCP falsch konfiguriert
Schritt 4: ip dhcp pool MEIN_POOL konfiguriert? Nein!
Schritt 5: Pool anlegen, PC neu verbinden → IP erhalten ✓
Schritt 7: Dokumentieren
2. BGP – Border Gateway Protocol
Grundidee: Path-Vector
BGP ist ein Path-Vector-Protokoll. Das bedeutet: BGP teilt nicht nur mit „ich kann Netz X erreichen", sondern auch über welchen Weg (AS-Pfad). So können Schleifen erkannt werden – wenn meine eigene AS-Nummer im Pfad steht, nehme ich die Route nicht an.
Verbindung: BGP läuft über TCP Port 179 (zuverlässige Übertragung, kein eigenes Reliability-Protokoll nötig).
Die 4 Nachrichtentypen
| Typ | Wann? | Was macht er? |
|---|---|---|
| OPEN | Beim Verbindungsaufbau | Stellt sich vor: AS-Nummer, BGP-Version, Router-ID, Hold-Time |
| UPDATE | Wenn sich Routen ändern | Teilt neue Routen mit oder zieht alte zurück |
| KEEPALIVE | Alle ~60 Sekunden | „Ich lebe noch" – verhindert Timeout |
| NOTIFICATION | Bei Fehlern | Meldet Fehler und bricht die Session ab |
Beispiel OPEN:
Router A öffnet TCP-Verbindung zu Router B auf Port 179.
Schickt OPEN: „Ich bin AS 65000, meine Router-ID ist 1.1.1.1, Hold-Time 90s"
Router B antwortet mit eigenem OPEN + KEEPALIVE → Session steht.
9-stufige Wegewahl (vereinfacht auf die wichtigsten)
Wenn BGP mehrere Routen zum gleichen Ziel kennt, wählt er nach dieser Reihenfolge:
| Priorität | Attribut | Merkhilfe |
|---|---|---|
| 1 | LOCAL_PREF (höher = besser) | „Welchen Ausgang bevorzuge ich?" |
| 2 | AS_PATH (kürzer = besser) | „Welcher Weg hat weniger Hops?" |
| 3 | MED (niedriger = besser) | „Welchen Eingang bevorzugt mein Nachbar?" |
| ... | weitere Kriterien | Router-ID, Neighbor-IP, etc. |
Beispiel:
Router A kennt zwei Wege zu 8.8.8.0/24:
Weg 1: LOCAL_PREF=200, AS_PATH: 65001 65002
Weg 2: LOCAL_PREF=100, AS_PATH: 65003
→ Weg 1 gewinnt, weil LOCAL_PREF höher (200 > 100).
AS_PATH wird gar nicht mehr verglichen.
Transit vs. Peering
Peering: Zwei Provider tauschen gegenseitig ihre eigenen Routen aus – kostenlos, aber nur das eigene Netz, keine Weiterleitung fremder Pakete.
Telekom ←→ Vodafone: „Ich leite deine Kunden-Pakete weiter, du meine."
Aber: Telekom leitet keine Pakete von Vodafone an einen dritten Provider weiter.
Transit: Ein Provider kauft beim anderen die Weiterleitung aller Pakete – auch zu Dritten. Kostet Geld.
Kleiner ISP → bezahlt Telekom → Telekom leitet Pakete ans gesamte Internet weiter.
Tier 1 / Tier 2 / Tier 3
| Tier | Wer? | Beispiel |
|---|---|---|
| Tier 1 | Große Provider, die das Internet-Backbone bilden. Haben Peering mit allen anderen Tier-1. Kaufen keinen Transit. | Deutsche Telekom, AT&T, Level3 |
| Tier 2 | Mittelgroße Provider. Haben Peering mit manchen, kaufen Transit von Tier-1. | Regionaler ISP |
| Tier 3 | Kleine Provider, kaufen Transit von Tier-2. Kein eigenes Peering. | Dein lokaler Kabel-Anbieter |
iBGP vs. eBGP
| iBGP | eBGP | |
|---|---|---|
| Wo? | Innerhalb eines AS | Zwischen verschiedenen AS |
| TTL | 255 (muss nicht direkt verbunden sein) | 1 (muss direkt verbunden sein) |
| Routen weitergeben? | iBGP-Routen werden nicht an andere iBGP-Nachbarn weitergegeben | eBGP-Routen werden weitergegeben |
| Problem iBGP | Alle iBGP-Router müssen sich kennen (Full Mesh) → bei n Routern: n*(n-1)/2 Sessions |
Warum darf iBGP keine Routen an iBGP-Nachbarn weitergeben? → Schleifenvermeidung! iBGP hat kein AS_PATH innerhalb eines AS, daher könnte eine Route endlos weitergegeben werden.
Route Reflector
Problem: Bei 10 iBGP-Routern braucht man 45 Sessions. Bei 100 Routern: 4950. Nicht skalierbar.
Lösung: Ein Router wird zum Route Reflector (RR). Er darf iBGP-Routen an andere iBGP-Nachbarn weitergeben – aber nur, wenn er als RR konfiguriert ist.
Ohne RR (Full Mesh, 4 Router):
A ←→ B, A ←→ C, A ←→ D, B ←→ C, B ←→ D, C ←→ D → 6 Sessions
Mit RR (A ist Route Reflector):
B → A → C
B → A → D
C → A → D → nur 3 Sessions nötig
Administrative Distanz (AD)
Wenn eine Route sowohl von BGP als auch von z.B. OSPF gelernt wird, entscheidet die AD welche genommen wird (niedrigere AD = bevorzugt):
| Protokoll | AD |
|---|---|
| Connected | 0 |
| Static | 1 |
| OSPF | 110 |
| iBGP | 200 |
| eBGP | 20 |
eBGP (AD 20) wird fast immer gegenüber anderen Protokollen bevorzugt. iBGP (AD 200) fast nie.
3. MPLS – Label-Format und Forwarding
Das Label-Format (32 Bit)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label (20 Bit) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feld | Bits | Bedeutung |
|---|---|---|
| Label | 20 | Der eigentliche Label-Wert (0 – 1.048.575) |
| TC | 3 | Traffic Class – früher „EXP", für QoS/Priorisierung |
| S | 1 | Bottom-of-Stack – ist dies das unterste Label im Stack? |
| TTL | 8 | Time to Live – verhindert Schleifen |
Reservierte Labels (0–15)
| Label | Name | Bedeutung |
|---|---|---|
| 0 | IPv4 Explicit Null | Pop Label, dann normales IPv4-Forwarding |
| 1 | Router Alert | Paket soll speziell behandelt werden |
| 2 | IPv6 Explicit Null | Pop Label, dann normales IPv6-Forwarding |
| 3 | Implicit Null | PHP – vorletzter Router soll Label entfernen |
| 4–15 | Reserviert | Noch nicht vergeben |
Push / Swap / Pop
| Operation | Wer macht es? | Was passiert? |
|---|---|---|
| PUSH | Ingress-Router (erster LER) | Label wird auf das Paket gedrückt |
| SWAP | Transit-Router (LSR) | Altes Label wird durch neues ersetzt |
| POP | Egress-Router (letzter LER) oder vorletzter (PHP) | Label wird entfernt |
Beispiel:
Paket kommt an Router A (IP: 10.2.0.1):
Router A (PUSH): [IP-Paket] → [Label 200][IP-Paket]
Router B (SWAP): [Label 200] → [Label 350] (tauscht aus, leitet weiter)
Router C (POP): [Label 350] → [IP-Paket] (entfernt, liefert aus)
FEC – Forwarding Equivalence Class
Eine FEC ist eine Gruppe von Paketen, die gleich behandelt werden – gleicher Label, gleicher Weg, gleiche Behandlung.
Beispiel:
Alle Pakete mit Ziel 192.168.10.0/24 → FEC „Richtung Standort Berlin"
→ alle bekommen Label 200, alle gehen über den gleichen Pfad
Pakete werden am Ingress-Router in FECs eingeteilt – danach nur noch Label-Switching, keine IP-Entscheidungen mehr.
LSP – Label Switched Path
Der vorher festgelegte Pfad durch das MPLS-Netz von Ingress bis Egress. Wie eine Schiene.
CE1 → [PE1: Label 200 PUSH] → [P1: Label SWAP] → [P2: Label SWAP] → [PE2: POP] → CE2
←————————————————— LSP ————————————————————→
Label Stack und S-Bit
Labels können gestapelt werden (z.B. VPN-Label + Transport-Label). Das S-Bit zeigt an, ob ein Label das unterste im Stack ist:
[ Transport-Label S=0 ] ← nicht unterstes Label
[ VPN-Label S=1 ] ← unterstes Label (Bottom of Stack)
[ IP-Paket ]
Router schauen immer nur auf das oberste Label. Erst wenn S=1 ist wissen sie: nach dem Pop kommt direkt das IP-Paket.
Forwarding Matrix (LFIB)
Die Tabelle, die jeder MPLS-Router führt:
Eingehendes Label | Operation | Ausgehendes Label | Next Hop
------------------|-----------|--------------------|----------
200 | SWAP | 350 | 10.0.0.2
350 | POP | - | 10.0.0.5
- | PUSH 200 | 200 | 10.0.0.1 (für FEC 192.168.10.0/24)
4. MPLS-Signalisierung
Drei Protokolle verteilen die Labels – je nach Anwendungsfall:
LDP – Label Distribution Protocol
- Port: TCP 646
- Schicht: L7 (Application)
- Zweck: Automatische Label-Verteilung für normales MPLS-Forwarding
Wie funktioniert es?
Router C sagt zu B (via LDP): „Für FEC 10.2.0.0/24 → gib mir Label 42"
Router B sagt zu A (via LDP): „Für FEC 10.2.0.0/24 → gib mir Label 17"
→ LSP ist aufgebaut, Pakete können fließen.
Link-LDP vs. Targeted-LDP:
| Link-LDP | Targeted-LDP | |
|---|---|---|
| Nachbarn | Nur direkt verbundene Router | Auch nicht-direkt verbundene Router |
| Einsatz | Normales MPLS | Pseudowires (VPWS, VPLS) |
| Discovery | Multicast Hello | Unicast Hello |
RSVP-TE – Resource Reservation Protocol – Traffic Engineering
- Protokoll: IP Protokoll 46
- Schicht: L3 (Network)
- Zweck: LSPs mit Bandbreitenreservierung und expliziten Pfaden (Traffic Engineering)
Zwei Nachrichten:
| Nachricht | Richtung | Zweck |
|---|---|---|
| PATH | Ingress → Egress | „Ich will einen LSP aufbauen, reserviere Ressourcen" |
| RESV | Egress → Ingress | „Ok, Ressourcen reserviert, hier ist dein Label" |
Beispiel:
PE1 schickt PATH-Nachricht: „Ich will 100 Mbit/s von PE1 nach PE2, über P1 und P2"
PATH wandert: PE1 → P1 → P2 → PE2
PE2 antwortet mit RESV: „Ok, Label 500 zugeteilt"
RESV wandert zurück: PE2 → P2 → P1 → PE1
→ LSP steht, Bandbreite ist reserviert.
Unterschied zu LDP: LDP nimmt den kürzesten IGP-Pfad. RSVP-TE kann explizite Pfade erzwingen und Bandbreite reservieren – daher für Traffic Engineering geeignet.
MP-BGP – Multiprotocol BGP
- Port: TCP 179
- Schicht: L7 (Application)
- Zweck: Labels und VPN-Routen verteilen (für L3 VPNs, VPLS Auto-Discovery)
Erweiterungen gegenüber normalem BGP:
| Feld | Bedeutung |
|---|---|
| AFI (Address Family Identifier) | Welche Adressfamilie? (IPv4=1, IPv6=2, L2VPN=25) |
| SAFI (Subsequent AFI) | Welcher Subtyp? (Unicast=1, VPN=128, EVPN=70) |
| RD (Route Distinguisher) | Macht VPN-Routen global eindeutig (8 Byte Präfix) |
Beispiel:
Normale BGP-Route: 192.168.1.0/24
MP-BGP VPNv4-Route: 65000:1:192.168.1.0/24
←RD→ ←————IP————→
→ Gleiche IP-Adresse kann bei verschiedenen Kunden existieren, weil der RD sie unterscheidbar macht.
5. Ausfallsicherheit: BFD und FRR
BFD – Bidirectional Forwarding Detection
- Port: UDP 3784
- Zweck: Sehr schnelle Erkennung von Link-/Nachbar-Ausfällen (viel schneller als BGP/OSPF-Timer)
Die 3 Zustände:
DOWN ──────→ INIT ──────→ UP
(Hello (Antwort
gesendet) erhalten)
| Zustand | Bedeutung |
|---|---|
| Down | Keine Verbindung, oder gerade gestartet |
| Init | Ich sende Hellos, habe aber noch keine Antwort |
| Up | Beidseitige Verbindung bestätigt, alles ok |
Heartbeat: BFD schickt alle 50ms ein Hello-Paket. Kommen 3 aus, gilt der Nachbar als ausgefallen → 150ms bis zur Fehlererkennung.
Zum Vergleich: OSPF-Dead-Interval ist standardmäßig 40 Sekunden. BFD ist also ~267x schneller.
Beispiel:
Router A und B laufen, BFD-Session ist im Zustand UP.
Link zwischen A und B fällt aus.
Nach 150ms: Kein BFD-Hello mehr empfangen → BFD meldet „Nachbar down"
→ OSPF/BGP bekommt sofort Bescheid → Router wechselt auf Backup-Route.
Ohne BFD: OSPF würde erst nach 40 Sekunden reagieren.
FRR – Fast ReRoute
- Ziel: Umschaltung auf Backup-Pfad in unter 50ms (nicht wahrnehmbar für Telefonie/Video)
- Funktioniert mit: RSVP-TE, Segment Routing
Zwei Backup-Strategien:
One-to-One Backup
Für jeden primären LSP wird ein eigener Backup-LSP vorbereitet.
Primär-LSP: PE1 → P1 → P2 → PE2
Backup-LSP: PE1 → P3 → P4 → PE2 (vorbereitet, aber inaktiv)
P1 fällt aus → sofort auf Backup-LSP umschalten
- Vorteil: Sehr schnell, dedizierter Pfad
- Nachteil: Viele Ressourcen (für jeden LSP ein Backup)
Facility Backup (auch: Bypass Tunnel)
Ein einziger Bypass-Tunnel schützt viele LSPs gleichzeitig.
Primär-LSPs: LSP1, LSP2, LSP3 laufen alle über Link P1→P2
Bypass: Ein Tunnel P1 → P3 → P2 schützt alle drei auf einmal
P1→P2 fällt aus → alle drei LSPs werden automatisch in den Bypass umgeleitet
- Vorteil: Effizient, ein Bypass für viele LSPs
- Nachteil: Weniger präzise Kontrolle
Link Protection vs. Node Protection
| Link Protection | Node Protection | |
|---|---|---|
| Schützt gegen | Ausfall eines Links | Ausfall eines ganzen Routers |
| Bypass geht | Um den ausgefallenen Link herum | Um den ausgefallenen Knoten herum |
| Beispiel | P1 → P2 fällt aus → Bypass P1 → P3 → P2 | P2 fällt komplett aus → Bypass P1 → P3 → PE2 |
Link Protection:
PE1 → P1 → [X] → P2 → PE2
↓
PE1 → P1 → P3 → P2 → PE2 (umgeht nur den ausgefallenen Link)
Node Protection:
PE1 → P1 → [P2 komplett ausgefallen] → PE2
↓
PE1 → P1 → P3 → PE2 (umgeht den ganzen Router P2)
Local Repair vs. Global Repair
| Local Repair | Global Repair | |
|---|---|---|
| Wer handelt? | Der Router direkt am Ausfall | Der Ingress-Router (PE1) |
| Wie schnell? | Sofort (< 50ms) – Bypass bereits vorbereitet | Langsamer – neuer LSP muss erst berechnet werden |
| Qualität | Suboptimaler Pfad möglich | Optimaler neuer Pfad |
| Typischer Ablauf | Zuerst Local Repair → Verkehr fließt wieder | Dann Global Repair → Pfad wird optimiert |
Beispiel:
1. Link P1→P2 fällt aus.
2. P1 erkennt Ausfall sofort (via BFD, 150ms).
3. LOCAL REPAIR: P1 leitet Pakete sofort über vorbereiteten Bypass (< 50ms).
→ Verkehr fließt wieder, User merkt (fast) nichts.
4. GLOBAL REPAIR: PE1 berechnet neuen optimalen LSP via RSVP-TE.
→ Neuer LSP wird aufgebaut, Bypass wird freigegeben.
Zusammenspiel BFD + FRR: BFD erkennt den Ausfall in ~150ms. FRR schaltet in <50ms um (Bypass war bereits vorbereitet). Zusammen ist die Unterbrechung für den Nutzer minimal.