# 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.