mirror of
https://github.com/theoleuthardt/hwr-notes.git
synced 2026-06-06 01:11:08 +00:00
517 lines
16 KiB
Markdown
517 lines
16 KiB
Markdown
# 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
|
||
```
|