mirror of
https://github.com/theoleuthardt/hwr-notes.git
synced 2026-06-06 02:11:08 +00:00
docs: add obsidian hwr docs
This commit is contained in:
theoleuthardt
parent
b2636f4b92
commit
850aa3455d
245 changed files with 30757 additions and 0 deletions
517
Netzwerke/labor/Lab Support Document.md
Normal file
517
Netzwerke/labor/Lab Support Document.md
Normal file
|
|
@ -0,0 +1,517 @@
|
|||
# OSPF-BGP Lab – Komplette Referenz
|
||||
|
||||
## Inhaltsverzeichnis
|
||||
|
||||
1. [Lab-Übersicht & Ziel](#1-lab-%C3%BCbersicht--ziel)
|
||||
2. [Netzwerktopologie](#2-netzwerktopologie)
|
||||
3. [Konfigurationen der Geräte](#3-konfigurationen-der-ger%C3%A4te)
|
||||
- [München (Edge-Router, ABR)](#31-m%C3%BCnchen-edge-router-abr)
|
||||
- [Nürnberg (ABR)](#32-n%C3%BCrnberg-abr)
|
||||
- [Berlin (ASBR, NAT-Gateway, Core-Router)](#33-berlin-asbr-nat-gateway-core-router)
|
||||
- [DHCP-Server](#34-dhcp-server)
|
||||
- [ISP-Telekom (AS 65001)](#35-isp-telekom-as-65001)
|
||||
4. [NAT-Konfiguration – Erklärung](#4-nat-konfiguration--erkl%C3%A4rung)
|
||||
5. [Troubleshooting – Befehle & Methoden](#5-troubleshooting--befehle--methoden)
|
||||
- [Endgeräte (Windows / Linux)](#51-endger%C3%A4te-windows--linux)
|
||||
- [Interfaces & Layer 1/2](#52-interfaces--layer-12)
|
||||
- [Switching & Layer 2](#53-switching--layer-2)
|
||||
- [Routing, DHCP & NAT (Layer 3)](#54-routing-dhcp--nat-layer-3)
|
||||
- [OSPF Troubleshooting](#55-ospf-troubleshooting)
|
||||
- [BGP Troubleshooting](#56-bgp-troubleshooting)
|
||||
- [Troubleshooting-Methoden](#57-troubleshooting-methoden)
|
||||
|
||||
---
|
||||
|
||||
## 1. Lab-Übersicht & Ziel
|
||||
|
||||
Das Lab simuliert ein **großes Unternehmensnetzwerk (AS 65000)**, das über einen Internet Service Provider (**ISP-Telekom, AS 65001**) mit dem echten, physischen Internet (France-Orange / Google) verbunden ist.
|
||||
|
||||
### Was passiert bei `ping google.com` vom PC in München?
|
||||
|
||||
|Schritt|Layer|Was passiert|
|
||||
|---|---|---|
|
||||
|1|L7 (DNS/DHCP)|PC bekommt IP per DHCP (via `ip helper-address`). DNS löst `google.com` → 8.8.8.8 auf.|
|
||||
|2|L3 (OSPF)|München nutzt OSPF → Route über Nürnberg zum Core-Router Berlin. Area 0 (Backbone), Area 100/200 (Edge).|
|
||||
|3|L2|LLDP (`lldp run`) erkennt Nachbarn auf MAC-Ebene und verhindert Schleifen.|
|
||||
|4|L3 (NAT 1)|Berlin übersetzt private IP (`192.168.12.x`) → eigene externe IP (`88.1.1.1`).|
|
||||
|5|L3 (BGP)|Berlin schickt Paket per eBGP an ISP-Telekom.|
|
||||
|6|L3 (NAT 2)|ISP-Telekom übersetzt `88.1.1.1` → IP des Heimnetzwerks (France-Orange) → Double NAT.|
|
||||
|7|—|Paket erreicht Google. Rückweg läuft über NAT und OSPF/BGP wieder rückwärts.|
|
||||
|
||||
**Schlüsselkombination für Internet-Erreichbarkeit:**
|
||||
|
||||
- ISP sendet Default-Route via BGP: `neighbor 88.1.1.1 default-originate`
|
||||
- Berlin verteilt sie ins OSPF: `default-information originate`
|
||||
|
||||
---
|
||||
|
||||
## 2. Netzwerktopologie
|
||||
|
||||
```
|
||||
┌─────────────────────────────┐
|
||||
│ Area 0 (Backbone) │
|
||||
Area 100 │ │ Area 200
|
||||
┌──────────────┐ │ Nürnberg ──── Berlin ──── Magdeburg ┌──────────────┐
|
||||
│ München │ │ (ABR) (ASBR) (ABR) │ Düsseldorf │
|
||||
│ 192.168.12 │ │ │ │ 192.168.1 │
|
||||
└──────────────┘ │ DHCP-Server └──────────────┘
|
||||
└─────────────────────────────┘
|
||||
│
|
||||
ISP-Telekom
|
||||
(AS 65001)
|
||||
│
|
||||
France-Orange
|
||||
(echtes Internet)
|
||||
```
|
||||
|
||||
**Wichtige Netze:**
|
||||
|
||||
|Segment|Netz|Bereich|
|
||||
|---|---|---|
|
||||
|München–Nürnberg|`192.168.100.0/30`|Area 100|
|
||||
|Nürnberg–Berlin|`100.0.10.0/30`|Area 0|
|
||||
|Berlin–Magdeburg|`100.0.20.0/30`|Area 0|
|
||||
|Nürnberg–Magdeburg|`100.0.255.0/30`|Area 0|
|
||||
|Berlin–DHCP-Server|`192.168.10.0/30`|Area 0|
|
||||
|Berlin–ISP (BGP)|`88.1.1.0/30`|extern|
|
||||
|LAN München|`192.168.12.0/24`|Area 100|
|
||||
|LAN Düsseldorf|`192.168.1.0/24`|Area 200|
|
||||
|
||||
---
|
||||
|
||||
## 3. Konfigurationen der Geräte
|
||||
|
||||
### 3.1 München (Edge-Router, ABR)
|
||||
|
||||
> **Rolle:** Randrouter in Area 100. DHCP-Relay für das lokale LAN. Kein direkter Internet-Zugang – nutzt Default-Route via OSPF.
|
||||
|
||||
```cisco
|
||||
ip name-server 8.8.8.8 8.8.4.4
|
||||
|
||||
interface Loopback0
|
||||
ip address 217.217.217.217 255.255.255.255
|
||||
|
||||
interface Ethernet0/0
|
||||
description ##to-Nuernberg##
|
||||
ip address 192.168.100.2 255.255.255.252
|
||||
|
||||
interface Ethernet0/1
|
||||
description ##LAN-MUENCHEN##
|
||||
ip address 192.168.12.254 255.255.255.0
|
||||
ip helper-address 192.168.10.2 ! DHCP-Relay → zentraler DHCP-Server
|
||||
|
||||
interface Ethernet0/2
|
||||
no ip address
|
||||
shutdown
|
||||
|
||||
interface Ethernet0/3
|
||||
no ip address
|
||||
shutdown
|
||||
|
||||
router ospf 217
|
||||
passive-interface Ethernet0/1 ! Kein OSPF-Hello ins LAN (Sicherheit)
|
||||
passive-interface Loopback0
|
||||
network 192.168.12.0 0.0.0.255 area 100
|
||||
network 192.168.100.0 0.0.0.3 area 100
|
||||
network 217.217.217.217 0.0.0.0 area 100
|
||||
|
||||
ip route 0.0.0.0 0.0.0.0 192.168.100.1 ! Statische Default-Route → Nürnberg
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3.2 Nürnberg (ABR)
|
||||
|
||||
> **Rolle:** Area Border Router zwischen Area 100 (München) und Area 0 (Backbone). Verbindet auch Magdeburg (via `100.0.255.0/30`).
|
||||
|
||||
```cisco
|
||||
ip name-server 8.8.8.8 8.8.4.4
|
||||
|
||||
interface Loopback0
|
||||
ip address 219.219.219.219 255.255.255.255
|
||||
|
||||
interface Ethernet0/0
|
||||
description ##to-Muenchen##
|
||||
ip address 192.168.100.1 255.255.255.252
|
||||
|
||||
interface Ethernet0/1
|
||||
description ##to-Berlin##
|
||||
ip address 100.0.10.2 255.255.255.252
|
||||
|
||||
interface Ethernet0/2
|
||||
description ##to-Magdeburg##
|
||||
ip address 100.0.255.1 255.255.255.252
|
||||
|
||||
interface Ethernet0/3
|
||||
no ip address
|
||||
shutdown
|
||||
|
||||
router ospf 12
|
||||
network 100.0.10.0 0.0.0.3 area 0
|
||||
network 192.168.100.0 0.0.0.255 area 100 ! Inkludiert den /30-Link zu München
|
||||
network 219.219.219.219 0.0.0.0 area 0
|
||||
|
||||
ip route 0.0.0.0 0.0.0.0 100.0.10.1 ! Default-Route → Berlin
|
||||
```
|
||||
|
||||
> ⚠️ **Hinweis:** `network 192.168.100.0 0.0.0.255 area 100` (Wildcard `/24`) deckt die `192.168.100.0/30`-Verbindung zu München ab. Das ABR-Verhalten macht Nürnberg zum Übergang zwischen Area 100 und Area 0.
|
||||
|
||||
---
|
||||
|
||||
### 3.3 Berlin (ASBR, NAT-Gateway, Core-Router)
|
||||
|
||||
> **Rolle:** Herzstück des Netzes. Verbindet OSPF (intern) mit BGP (extern), macht NAT für das gesamte `192.168.0.0/16`- und `100.0.0.0/16`-Netz.
|
||||
|
||||
```cisco
|
||||
ip name-server 8.8.8.8 8.8.4.4
|
||||
|
||||
interface Loopback0
|
||||
ip address 220.220.220.220 255.255.255.255
|
||||
|
||||
interface Ethernet0/0
|
||||
description ##to-Nuernberg##
|
||||
ip address 100.0.10.1 255.255.255.252
|
||||
ip nat inside
|
||||
|
||||
interface Ethernet0/1
|
||||
description ##to-Magdeburg##
|
||||
ip address 100.0.20.1 255.255.255.252
|
||||
ip nat inside
|
||||
|
||||
interface Ethernet0/2
|
||||
description ##Internet##
|
||||
ip address dhcp ! Bekommt externe IP von ISP/France-Orange
|
||||
ip nat outside
|
||||
|
||||
interface Ethernet0/3
|
||||
description ##to-DHCP-SERVER##
|
||||
ip address 192.168.10.1 255.255.255.252
|
||||
ip nat inside
|
||||
|
||||
! --- OSPF ---
|
||||
router ospf 220
|
||||
router-id 220.220.220.220
|
||||
passive-interface Ethernet0/2 ! Kein OSPF ins Internet
|
||||
network 100.0.10.0 0.0.0.3 area 0
|
||||
network 100.0.20.0 0.0.0.3 area 0
|
||||
network 192.168.10.0 0.0.0.3 area 0
|
||||
network 220.220.220.220 0.0.0.0 area 0
|
||||
redistribute bgp 65000 metric 10 metric-type 1 ! BGP-Routen ins OSPF einbringen
|
||||
default-information originate ! Default-Route (0.0.0.0) ins OSPF verteilen
|
||||
|
||||
! --- BGP ---
|
||||
router bgp 65000
|
||||
network 192.168.0.0 mask 255.255.0.0 ! Eigenes Netz dem ISP ankündigen
|
||||
neighbor 88.1.1.2 remote-as 65001 ! eBGP-Nachbarschaft zum ISP
|
||||
|
||||
! --- NAT ---
|
||||
ip access-list standard 1
|
||||
10 permit 192.168.0.0 0.0.255.255 ! Alle privaten 192.168.x.x-Netze
|
||||
20 permit 100.0.0.0 0.0.255.255 ! Interne 100.0.x.x-Netze
|
||||
|
||||
ip nat inside source list 1 interface Ethernet0/2 overload ! PAT auf externe IP
|
||||
|
||||
ip route 0.0.0.0 0.0.0.0 dhcp ! Default-Route von DHCP (ISP)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3.4 DHCP-Server
|
||||
|
||||
> **Rolle:** Zentraler DHCP-Dienst für München und Düsseldorf. Erreichbar über `ip helper-address` auf den jeweiligen Edge-Routern.
|
||||
|
||||
```cisco
|
||||
hostname DHCP-SERVER
|
||||
|
||||
! --- Ausschluss statischer IPs (werden nicht per DHCP vergeben) ---
|
||||
ip dhcp excluded-address 192.168.12.254 ! Gateway München
|
||||
ip dhcp excluded-address 192.168.12.1 192.168.12.10
|
||||
ip dhcp excluded-address 192.168.1.1 192.168.1.10
|
||||
ip dhcp excluded-address 192.168.1.254 ! Gateway Düsseldorf
|
||||
|
||||
! --- DHCP-Pool München ---
|
||||
ip dhcp pool Muenchen
|
||||
network 192.168.12.0 255.255.255.0
|
||||
default-router 192.168.12.254
|
||||
dns-server 8.8.8.8 8.8.4.4
|
||||
lease 7 ! Lease-Zeit: 7 Tage
|
||||
|
||||
! --- DHCP-Pool Düsseldorf ---
|
||||
ip dhcp pool Duesseldorf
|
||||
network 192.168.1.0 255.255.255.0
|
||||
default-router 192.168.1.254
|
||||
dns-server 8.8.8.8 8.8.4.4
|
||||
lease 7
|
||||
|
||||
! --- Interface & Default-Route ---
|
||||
interface Ethernet0/0
|
||||
description ##to-BERLIN##
|
||||
ip address 192.168.10.2 255.255.255.252
|
||||
|
||||
ip route 0.0.0.0 0.0.0.0 192.168.10.1 ! Default-Route → Berlin
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3.5 ISP-Telekom (AS 65001)
|
||||
|
||||
> **Rolle:** Simuliert den Internet Service Provider. Baut eBGP-Nachbarschaft zu Berlin auf, verteilt Default-Route und macht Double NAT zum echten Heimnetzwerk (France-Orange).
|
||||
|
||||
```cisco
|
||||
! --- Interface zum echten Internet (France-Orange) ---
|
||||
interface Ethernet0/1
|
||||
ip address dhcp ! Echte IP vom Heimrouter
|
||||
ip nat outside
|
||||
|
||||
interface Ethernet0/0
|
||||
ip nat inside
|
||||
|
||||
! --- NAT (Double NAT für das Lab) ---
|
||||
ip access-list standard 10
|
||||
10 permit 88.1.1.0 0.0.0.3 ! Transfernetz Berlin↔ISP
|
||||
|
||||
ip nat inside source list 10 interface Ethernet0/1 overload
|
||||
|
||||
! --- BGP ---
|
||||
router bgp 65001
|
||||
neighbor 88.1.1.1 remote-as 65000 ! eBGP-Nachbarschaft zu Berlin
|
||||
neighbor 88.1.1.1 default-originate ! Gibt Berlin eine Default-Route (→ Internet)
|
||||
|
||||
! --- Default-Route ins echte Internet ---
|
||||
ip route 0.0.0.0 0.0.0.0 dhcp
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. NAT-Konfiguration – Erklärung
|
||||
|
||||
### Schritt 1: Access-List definieren – wer darf NAT nutzen?
|
||||
|
||||
```cisco
|
||||
ip access-list standard 1
|
||||
10 permit 192.168.0.0 0.0.255.255
|
||||
```
|
||||
|
||||
> Die Wildcard `0.0.255.255` bedeutet: Erste zwei Oktette (`192.168`) müssen exakt passen, die letzten zwei sind beliebig → alle IPs von `192.168.0.0` bis `192.168.255.255` sind erlaubt.
|
||||
|
||||
---
|
||||
|
||||
### Schritt 2: NAT Overload (PAT) aktivieren
|
||||
|
||||
```cisco
|
||||
ip nat inside source list 1 interface Ethernet0/2 overload
|
||||
```
|
||||
|
||||
> `overload` = **PAT (Port Address Translation)**. Mehrere interne Hosts teilen sich eine öffentliche IP – die Unterscheidung erfolgt über unterschiedliche Portnummern. Ohne `overload` könnte nur ein Host gleichzeitig die externe IP nutzen.
|
||||
|
||||
---
|
||||
|
||||
### Schritt 3: NAT-Rollen der Interfaces festlegen
|
||||
|
||||
```cisco
|
||||
interface Ethernet0/0
|
||||
ip nat inside ! Interne Seite (Richtung Nürnberg / LAN)
|
||||
|
||||
interface Ethernet0/2
|
||||
ip nat outside ! Externe Seite (Richtung ISP / Internet)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Troubleshooting – Befehle & Methoden
|
||||
|
||||
> 💡 **Goldene Regel:** Immer nach dem **OSI-Modell von unten nach oben** arbeiten (Bottom-Up): Kabel → Interfaces → Nachbarschaften → Routing-Tabelle → Anwendung.
|
||||
|
||||
---
|
||||
|
||||
### 5.1 Endgeräte (Windows / Linux)
|
||||
|
||||
#### Windows
|
||||
|
||||
```cmd
|
||||
ipconfig /all # IP, Subnetzmaske, Gateway, DNS – prüft ob DHCP funktioniert hat
|
||||
ping <IP> # Erreichbarkeit testen
|
||||
tracert <IP> # Jeden Hop (Router) auf dem Weg anzeigen – wo bleibt das Paket?
|
||||
arp -a # ARP-Cache – welche MAC-Adresse gehört zum Default-Gateway?
|
||||
route print # Lokale Routing-Tabelle des Windows-PCs
|
||||
nslookup google.com # DNS-Auflösung testen (Layer 7)
|
||||
```
|
||||
|
||||
#### Linux / Mac
|
||||
|
||||
```bash
|
||||
ip a # (oder ifconfig) – IP-Adressen & Interface-Status
|
||||
ping <IP> # Erreichbarkeit testen
|
||||
traceroute <IP> # Pfad des Pakets verfolgen
|
||||
mtr <IP> # Live-Traceroute (empfohlen!)
|
||||
ip neigh # (oder arp -n) – ARP-Tabelle anzeigen
|
||||
ip route # Default-Gateway & Routing-Tabelle
|
||||
dig google.com # Detailreiche DNS-Abfrage (Layer 7)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5.2 Interfaces & Layer 1/2
|
||||
|
||||
```cisco
|
||||
show ip interface brief
|
||||
! Der wichtigste Befehl! Zeigt IP und Status aller Interfaces (muss "Up/Up" sein)
|
||||
|
||||
show interfaces <Interface>
|
||||
! z.B.: show interfaces e0/0
|
||||
! Zeigt CRC-Errors, Drops, Duplex-Mismatches, MTU-Probleme
|
||||
|
||||
show interfaces description
|
||||
! Zeigt konfigurierte Beschreibungen (z.B. "##to-Nuernberg##")
|
||||
! Extrem hilfreich in großen Netzen
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5.3 Switching & Layer 2
|
||||
|
||||
```cisco
|
||||
show lldp neighbors
|
||||
show lldp neighbors detail ! IP des Nachbarn ebenfalls anzeigen
|
||||
show cdp neighbors ! Alternativ (Cisco-proprietär)
|
||||
|
||||
show mac address-table ! Welche MAC-Adresse wurde an welchem Port gelernt?
|
||||
|
||||
show spanning-tree ! Ist ein Port blockiert (Loop-Prevention)?
|
||||
show spanning-tree vlan <ID> ! Root-Bridge-Status für ein bestimmtes VLAN
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5.4 Routing, DHCP & NAT (Layer 3)
|
||||
|
||||
```cisco
|
||||
show ip route
|
||||
! Komplette Routing-Tabelle. Achte auf:
|
||||
! O = OSPF
|
||||
! B = BGP
|
||||
! C = Connected (direkt verbunden)
|
||||
! S* = Default-Route (statisch)
|
||||
|
||||
show ip route <IP>
|
||||
! z.B.: show ip route 8.8.8.8
|
||||
! Sagt exakt, welches Interface für dieses Ziel genutzt wird
|
||||
|
||||
ping <Ziel-IP> source <Quell-Interface/IP>
|
||||
! Extrem wichtig! Simuliert Traffic aus dem LAN heraus
|
||||
! Beispiel: ping 8.8.8.8 source 192.168.12.254
|
||||
|
||||
show ip arp ! IPs → MAC-Adressen auf dem Router
|
||||
|
||||
show ip dhcp binding ! Welchen PCs hat der DHCP-Server eine IP gegeben?
|
||||
|
||||
show ip nat translations ! Aktive NAT-Tabelle – werden interne IPs übersetzt?
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5.5 OSPF Troubleshooting
|
||||
|
||||
> **Häufige Fehlerursachen:** Falsche Timer, unterschiedliche Areas, fehlende `network`-Statements, passive-interface auf falschem Interface.
|
||||
|
||||
```cisco
|
||||
show ip ospf neighbor
|
||||
! Zeigt Nachbarn. Status MUSS sein:
|
||||
! FULL → alles OK
|
||||
! 2WAY → OK in Broadcast-Netzen
|
||||
! EXSTART / INIT / DOWN → Problem!
|
||||
|
||||
show ip ospf interface brief
|
||||
! Zeigt auf einen Blick:
|
||||
! - Auf welchen Interfaces OSPF läuft
|
||||
! - In welcher Area sie sind
|
||||
! - Ob sie auf "Passive" stehen
|
||||
|
||||
show ip route ospf
|
||||
! Nur OSPF-gelernte Routen anzeigen (gefilterte Sicht)
|
||||
|
||||
show ip ospf database
|
||||
! Fortgeschritten: Rohe LSAs (Link-State Advertisements) anzeigen
|
||||
|
||||
clear ip ospf process
|
||||
! OSPF-Prozess hart neu starten → Nachbarschaften werden neu aufgebaut
|
||||
! ⚠️ Achtung: Unterbricht kurzzeitig den Traffic!
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5.6 BGP Troubleshooting
|
||||
|
||||
> **Häufige Fehlerursachen:** Falsche AS-Nummern, Next-Hop nicht erreichbar, fehlende `network`-Statements, keine Route im BGP mit `>` (Best-Flag).
|
||||
|
||||
```cisco
|
||||
show ip bgp summary
|
||||
! Wichtigster BGP-Befehl! Spalte "State/PfxRcd" ganz rechts:
|
||||
! Zahl (0, 3, 10, ...) → BGP ist UP
|
||||
! "Idle" oder "Active" → BGP ist KAPUTT
|
||||
|
||||
show ip bgp
|
||||
! BGP-Tabelle anzeigen. Achte auf:
|
||||
! *> = Valid & Best → wird ins OSPF weitergegeben
|
||||
! Fehlt das ">" → Route wird NICHT weitergegeben!
|
||||
! Next-Hop muss erreichbar sein!
|
||||
|
||||
show ip bgp neighbors <IP> advertised-routes
|
||||
! Welche Netze schickt dein Router an den Nachbarn?
|
||||
|
||||
show ip bgp neighbors <IP> received-routes
|
||||
! Was schickt der Nachbar dir?
|
||||
! ⚠️ Erfordert "soft-reconfiguration inbound" in der Config
|
||||
|
||||
clear ip bgp * soft
|
||||
! "Route Refresh" ohne BGP-Session zu trennen
|
||||
! Zwingt Router, sich Routen neu zu schicken
|
||||
! Sehr nützlich nach Config-Änderungen
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5.7 Troubleshooting-Methoden
|
||||
|
||||
#### 1. Bottom-Up (Layer 1 → Layer 7) ⬆️
|
||||
|
||||
**Wann nutzen:** Netzwerk komplett neu aufgebaut, totaler Ausfall (Link Down), keine Anhaltspunkte vorhanden.
|
||||
|
||||
**Logik:** Bevor ich frage warum OSPF kaputt ist, prüfe ich ob das Interface überhaupt UP ist.
|
||||
|
||||
```
|
||||
L1: Kabel / Port up?
|
||||
L2: Nachbarn per LLDP/CDP sichtbar?
|
||||
L3: Direkte Nachbarn pingbar? Routing-Protokoll-Nachbarschaften (OSPF/BGP) stehen?
|
||||
L3: Routen bekannt (Routing-Tabelle)?
|
||||
L4-L7: Dienst / Applikation erreichbar?
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 2. Top-Down (Layer 7 → Layer 1) ⬇️
|
||||
|
||||
**Wann nutzen:** User sagt "Webseite geht nicht", aber Teams-Call läuft problemlos → L1–L3 funktioniert bereits.
|
||||
|
||||
**Logik:** Oben anfangen (Browser-Cache, DNS, Firewall Port 443?) und sich nach unten vorarbeiten. Oft muss man gar nicht bis zu Switches hinabsteigen.
|
||||
|
||||
```
|
||||
L7: Browser-Cache leer? DNS-Auflösung ok?
|
||||
L4: Firewall blockiert Port 443?
|
||||
L3: Routing stimmt?
|
||||
L2/L1: (oft gar nicht nötig)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 3. Divide and Conquer (Teile & Herrsche) ↕️
|
||||
|
||||
**Wann nutzen:** Der absolute Favorit erfahrener Admins im Alltag. Direkt in die Mitte des OSI-Modells springen (Layer 3: Ping / Traceroute).
|
||||
|
||||
```
|
||||
Ping geht durch?
|
||||
→ Fehler liegt OBEN (L4–L7): Port geblockt, Applikation abgestürzt, DNS kaputt
|
||||
|
||||
Ping schlägt fehl?
|
||||
→ Fehler liegt UNTEN (L1–L2): falsches VLAN, fehlende Route, kaputtes Kabel
|
||||
```
|
||||
Loading…
Add table
Add a link
Reference in a new issue