mirror of
https://github.com/theoleuthardt/hwr-notes.git
synced 2026-06-06 01:51:07 +00:00
16 KiB
16 KiB
OSPF-BGP Lab – Komplette Referenz
Inhaltsverzeichnis
- Lab-Übersicht & Ziel
- Netzwerktopologie
- Konfigurationen der Geräte
- NAT-Konfiguration – Erklärung
- Troubleshooting – Befehle & 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.
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).
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 die192.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- und100.0.0.0/16-Netz.
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-addressauf den jeweiligen Edge-Routern.
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).
! --- 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?
ip access-list standard 1
10 permit 192.168.0.0 0.0.255.255
Die Wildcard
0.0.255.255bedeutet: Erste zwei Oktette (192.168) müssen exakt passen, die letzten zwei sind beliebig → alle IPs von192.168.0.0bis192.168.255.255sind erlaubt.
Schritt 2: NAT Overload (PAT) aktivieren
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. Ohneoverloadkönnte nur ein Host gleichzeitig die externe IP nutzen.
Schritt 3: NAT-Rollen der Interfaces festlegen
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
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
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
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
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)
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.
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).
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