Troubleshooting und Verwaltung

Subnetze sind die Grundlage jedes strukturierten Netzwerks.
Doch sobald etwas nicht funktioniert – etwa ein Host kein Gateway erreicht oder eine Route ins Leere führt – zeigt sich, ob das Konzept verstanden und sauber umgesetzt wurde.
Beim Troubleshooting geht es also weniger um „Klicks“ oder „Kommandos“, sondern darum, die Logik hinter dem Aufbau eines Subnetzes nachvollziehen zu können.

1. Verständnis vor Aktion

Bevor man mit Tools oder Pings beginnt, sollte man das Problem auf konzeptioneller Ebene verstehen.
Jedes Gerät im Netzwerk besitzt eine IP-Adresse und eine Subnetzmaske.
Diese Maske definiert, welche anderen Geräte sich im selben logischen Netzwerk befinden – und welche über ein Gateway erreicht werden müssen.

Wenn eine Verbindung nicht funktioniert, lautet die erste Frage also nicht:

„Ist der Ping blockiert?“
Sondern:
„Sind beide Geräte überhaupt im selben Netz – laut Adresslogik?“

Ein typischer Fehler ist, dass zwar eine IP-Adresse korrekt vergeben wurde, die Maske aber nicht stimmt.
Dann glaubt das Gerät, dass sich der Nachbar „außerhalb“ seines Netzes befindet und schickt die Pakete fälschlicherweise ans Gateway – oder umgekehrt.

Darum: Maske prüfen, nicht nur IP.

2. Systematische Fehlersuche

Ein erfahrener Administrator geht in klaren Schichten vor:

a) Layer 1 – Physikalische Verbindung

Ist der Link überhaupt aktiv?
Leuchten die Ports? Kabel intakt?
Bei Glasfaser: richtige Wellenlänge? Bei Kupfer: korrekt gesteckt, Auto-Negotiation an beiden Seiten gleich?
Wenn schon hier ein Problem besteht, kann alles Weitere ignoriert werden – das Subnetz „existiert“ dann praktisch nicht.

b) Layer 2 – VLAN und MAC-Ebene

Sind die Ports im richtigen VLAN?
Ist ein Access-Port wirklich untagged im VLAN des Subnetzes?
Ist ein Trunk-Port korrekt konfiguriert, also erlaubt das VLAN in seiner Trunk-Liste?
Viele vermeintliche IP-Probleme sind in Wahrheit VLAN-Fehler.

Ein häufiger Denkfehler:

„Ich habe die richtige IP, also muss es das Subnetz sein.“
Aber VLAN ≠ Subnetz. Ein Subnetz kann auf beliebig vielen VLANs liegen – oder auch gar nicht, wenn die VLAN-Zuordnung falsch ist.

c) Layer 3 – IP-Ebene

Wenn physikalisch und VLAN-seitig alles stimmt, geht es um die IP-Logik selbst:

• Passt IP-Adresse und Subnetzmaske?

• Liegt das Gateway wirklich innerhalb desselben Netzes?

• Gibt es vielleicht überlappende Netze, die sich gegenseitig stören?

Dazu lohnt sich immer ein kurzer Blick auf die binäre Logik:
Stimmen Netzadresse und Broadcastbereich mit dem zusammen, was der Rechner glaubt?

3. Typische Fehlerbilder im Alltag

Falsche Maske oder Gateway

Ein Host bekommt z. B. 192.168.10.12/25 als Adresse, der Gateway aber ist 192.168.10.1.
Das funktioniert nicht, weil 192.168.10.1 in einem anderen Netzbereich liegt (/25 = 192.168.10.0–127).
Der Host müsste 192.168.10.129/25 bekommen – oder die Maske auf /24 korrigiert werden.

Die Lösung:
Maske und Gateway müssen im selben Netzbereich liegen.

Überlappende Subnetze

Wenn zwei Bereiche sich überschneiden (z. B. 192.168.0.0/23 und 192.168.1.0/24), entstehen Routing-Konflikte.
Der Router weiß dann nicht eindeutig, welche Route für bestimmte IPs gilt.
Das führt zu zufälliger Erreichbarkeit oder asymmetrischem Routing – Pakete gehen raus, aber nicht zurück.

Das ist einer der gefährlichsten Fehler in größeren VLSM-Netzen.
Darum immer prüfen, ob Netze auf Blockgrenzen liegen und sich nicht überlappen.

Falsche DHCP-Bereiche

Ein Scope, der .0 oder .255 enthält, funktioniert zwar manchmal, erzeugt aber Konflikte, weil diese Adressen Netz- und Broadcastadresse sind.
Ein DHCP-Pool muss immer innerhalb des Hostbereichs liegen.

Routing- oder ACL-Fehler

Wenn Pings aus einem Netz funktionieren, aus einem anderen aber nicht, ist oft eine falsche Route oder Access-Control-List (ACL) schuld.
Hier hilft die Regel des Longest Prefix Match:
Je länger der Präfix, desto spezifischer die Route.
Eine /25 hat Vorrang vor einer /24, selbst wenn beide theoretisch passen.

ACLs sind ähnlich tückisch:
In Cisco-Syntax ist die Wildcardmaske die Inverse der Subnetzmaske – ein klassischer Anfängerfehler ist hier die Verwechslung.
Beispiel:
Subnetz 255.255.255.0 → Wildcard 0.0.0.255

4. Werkzeuge zur Überprüfung

Windows

• ipconfig /all → zeigt IP, Maske, Gateway, DNS

• route print → zeigt Routing-Tabelle und Standardgateway

• arp -a → zeigt MAC-Adressen und Nachbarn auf Layer 2

• ping, tracert → einfache Connectivity-Tests

• PowerShell: Test-NetConnection -ComputerName 8.8.8.8 -TraceRoute

Linux / macOS

• ip addr show oder ifconfig → Interface-Infos

• ip route show → Routing-Tabelle

• ping, traceroute, arp -n → Diagnose

• tcpdump → zeigt, ob Pakete das Gerät überhaupt verlassen

Mit diesen Befehlen lässt sich jeder Verbindungsfehler schrittweise eingrenzen.

5. Verwaltung & Pflege

Subnetze sind keine statischen Gebilde.
Mit der Zeit kommen Geräte hinzu, alte fallen weg, neue VLANs werden erstellt.
Damit das Netzwerk langfristig stabil bleibt, muss man Subnetze dokumentieren und pflegen:

• Subnetzplan führen: Welche Netze existieren, wo liegen sie, welche VLANs gehören dazu?

• Reservierungen & DHCP-Scopes sauber festhalten.

• Wachstum berücksichtigen – lieber eine Reserve /24 ungenutzt lassen als später mühsam umnummerieren.

• Änderungen sofort dokumentieren, sonst verliert man bei vielen Standorten schnell den Überblick.

Große Unternehmen verwenden dazu IP-Adressverwaltungssysteme (IPAM).
Im kleineren Umfeld reicht oft eine einfache Excel- oder Markdown-Tabelle mit folgenden Spalten:

Standort | Netz | Maske | Verwendung | VLAN | Gateway | DHCP | Notizen