Eine falsch gesetzte Subnetzmaske trennt Geräte logisch, obwohl sie physisch im selben Netz hängen. Beheben Sie das Problem, indem Sie die aktuelle Maske per ipconfig oder ip a prüfen, sie an den geplanten CIDR-Bereich anpassen, DHCP-Scope und Router-Interface korrigieren und anschließend Konnektivität mit ping und tracert verifizieren.
Symptome
- Geräte im gleichen VLAN können sich gegenseitig nicht anpingen, obwohl Kabel und Switch funktionieren.
- Zugriff auf Fileserver, Drucker oder Gateway schlägt fehl, DNS-Auflösung bleibt aber teilweise aktiv.
- ipconfig zeigt eine Maske wie 255.255.0.0 statt der geplanten 255.255.255.0.
- tracert bricht schon am ersten Hop ab oder springt sofort ins Internet-Gateway.
- Nur ein Teil des Subnetzes ist erreichbar, ab einer bestimmten Host-IP endet die Kommunikation.
Häufige Ursachen
Manuell gesetzte falsche Maske am Client
Ein Administrator hat statt /24 versehentlich /16 oder /25 eingetragen. Das Gerät hält dann Hosts für lokal, die es eigentlich über das Gateway erreichen müsste.
DHCP-Scope mit falscher Option 1
Der DHCP-Server verteilt eine Subnetzmaske, die nicht zum konfigurierten Scope-Bereich passt. Alle neuen Clients erben die Fehlkonfiguration automatisch.
Uneinheitliche Masken im selben Segment
Server nutzen /24, Clients hingegen /23 oder /25. Kommunikation funktioniert nur in eine Richtung, weil ARP-Broadcasts unterschiedlich interpretiert werden.
Falsches Router- oder SVI-Interface
Das Gateway-Interface am Router oder Layer-3-Switch ist mit einer anderen Maske konfiguriert als die Clients. Routing-Entscheidungen greifen dadurch nicht wie erwartet.
IP-Plan und CIDR passen nicht zusammen
Der zugewiesene IP-Bereich liegt außerhalb der berechneten Netz- und Broadcast-Adresse. Einzelne Hosts fallen in ein Nachbarnetz und sind nicht ansprechbar.
Schritt-für-Schritt-Lösung
- Aktuelle IP-Konfiguration auf dem betroffenen Gerät auslesen
Öffnen Sie die Eingabeaufforderung und führen Sie ipconfig /all aus, unter Linux ip a oder ip -4 addr show, unter macOS ifconfig. Notieren Sie IP-Adresse, Subnetzmaske, Standardgateway und ob die Werte per DHCP oder statisch gesetzt wurden. - Soll-Werte aus der IP-Dokumentation abgleichen
Prüfen Sie den IP-Plan: Welches CIDR gilt für dieses VLAN? Rechnen Sie kurz nach, ob die aktuelle IP innerhalb des gültigen Host-Bereichs liegt (nicht Netz- oder Broadcast-Adresse). Nutzen Sie einen Subnetz-Rechner, wenn die Berechnung unklar ist. - Erreichbarkeit strukturiert testen
Pingen Sie zuerst 127.0.0.1, dann die eigene IP, dann einen Nachbarhost im selben Subnetz, danach das Gateway und zuletzt eine externe Adresse. Bricht der Ping ab dem Nachbarhost oder Gateway ab, ist die Maske der wahrscheinlichste Verursacher. - Falsche Maske am Client korrigieren
Bei statischer Konfiguration: Adaptereinstellungen öffnen, IPv4-Eigenschaften anpassen und die korrekte Maske eintragen. Alternativ per netsh: netsh interface ipv4 set address name="Ethernet" static <IP> <Maske> <Gateway>. Anschließend ipconfig /release und /renew ausführen. - DHCP-Scope und Optionen prüfen
Öffnen Sie die DHCP-Konsole, wählen Sie den betroffenen Scope und kontrollieren Sie Adressbereich, Subnetzmaske sowie Option 003 (Router). Korrigieren Sie fehlerhafte Werte, erneuern Sie danach auf Clients die Lease und stellen Sie sicher, dass keine Reservierung eine alte Maske erzwingt. - Router- und Switch-Interfaces angleichen
Am Layer-3-Gerät die Interface-Konfiguration prüfen (show ip interface brief bzw. show running-config interface). Die Maske am SVI oder Router-Port muss identisch zum Client-Subnetz sein. Passen Sie sie an und speichern Sie die Konfiguration. - Ergebnis verifizieren und dokumentieren
Wiederholen Sie ping und tracert zu Gateway, internem Server und externem Ziel. Prüfen Sie die Routingtabelle mit route print oder ip route. Aktualisieren Sie danach den IP-Plan, damit die korrekte Maske auch zukünftig als Referenz gilt.
Typische CIDR-Werte, dezimale Maske und nutzbare Hosts
| CIDR | Subnetzmaske | Nutzbare Hosts | Typischer Einsatz |
|---|---|---|---|
| /30 | 255.255.255.252 | 2 | Point-to-Point-Link zwischen Routern |
| /29 | 255.255.255.248 | 6 | Kleines Management-Segment |
| /28 | 255.255.255.240 | 14 | DMZ mit wenigen Servern |
| /27 | 255.255.255.224 | 30 | Kleines Büro-VLAN |
| /24 | 255.255.255.0 | 254 | Standard-Client-LAN |
| /23 | 255.255.254.0 | 510 | Größeres Client-Segment |
| /22 | 255.255.252.0 | 1022 | Campus-Etage oder Standort |
So beugen Sie vor
- Zentrale IP- und CIDR-Dokumentation pflegen und bei jeder Änderung sofort nachziehen.
- IP-Vergabe möglichst über DHCP mit sauber definierten Scopes statt statisch am Client.
- Monitoring auf ARP- und Ping-Fehler pro VLAN aktivieren, um Maskenkonflikte früh zu sehen.
- Änderungen an Router- und DHCP-Konfigurationen ausschließlich über Change-Prozess und Backup.
Häufige Fragen
Woran erkenne ich, dass wirklich die Subnetzmaske schuld ist und nicht DNS oder Firewall?
Wenn ein Ping per IP-Adresse zu einem Nachbarhost im selben Segment scheitert, DNS und Firewall aber gleichzeitig auf anderen Geräten funktionieren, deutet das stark auf ein Maskenproblem hin. Prüfen Sie zusätzlich mit arp -a, ob die MAC-Adresse des Ziels überhaupt gelernt wurde. Fehlt sie, hält Ihr Gerät den Ziel-Host für nicht lokal.
Kann ich die Subnetzmaske im laufenden Betrieb ändern?
Technisch ja, es kommt aber kurzzeitig zu Verbindungsabbrüchen, weil ARP-Tabellen und Routing-Einträge neu aufgebaut werden. Planen Sie die Änderung außerhalb kritischer Zeiten und passen Sie Client, DHCP-Scope und Router-Interface möglichst zeitnah an, damit kein Mischbetrieb entsteht.
Was passiert, wenn zwei Geräte unterschiedliche Masken im gleichen Segment haben?
Die Kommunikation wird asymmetrisch: Ein Gerät hält den Partner für lokal und sendet direkt per ARP, das andere schickt die Antwort über das Gateway. Je nach Routing scheitert das komplett oder nur teilweise. Das Verhalten wirkt oft sporadisch und ist deshalb tückisch zu diagnostizieren.