Der Klassiker im Rechenzentrum: Zwei Bleche hängen im selben VLAN, die Link-LEDs blinken brav, aber der Ping verreckt mit Destination Host Unreachable. Auf dem einen Server steht ein /24, auf dem anderen hat jemand hastig ein /23 in die Netplan- oder NetworkManager-Konfiguration geklopft. Für den ersten Rechner existiert der Nachbar schlicht nicht im lokalen L2-Segment – er schiebt das Paket stumpf ans Default Gateway, und wenn dort kein Proxy-ARP aktiv ist, landet der Traffic im Nirwana.
Subnetting wird in Schulungen gern wie eine theoretische Mathematik-Vorlesung gelehrt. Da malt man Nullen und Einsen auf Karopapier, rechnet logische Bit-Operationen von Hand durch und hat am Ende doch keinen Plan, was auf dem Switch oder im Linux-Kernel eigentlich passiert.
Dabei interessiert das Betriebssystem kein akademischer Unterbau. Dem Kernel ist völlig egal, ob eine Adresse historisch mal „Class C“ hieß. Seit RFC 4632 CIDR vor über dreißig Jahren eingeführt hat, gibt es nur noch zwei Parameter:
Eine Bitfolge und eine Schnittkante.
Eine IP-Adresse ist nichts weiter als eine fortlaufende Zahl, die an einer definierten Stelle durchgeschnitten wird. Vorne liegt das Netz, hinten der Host.
Das Präfix – die Zahl hinter dem Schrägstrich – markiert lediglich das Messer:
/24bedeutet: 24 Bits Netz, 8 Bits für Geräte./25schiebt die Kante um ein Bit weiter: doppelt so viele Netze, aber nur noch halb so viele Hosts pro Segment.
Wer das Prinzip einmal verinnerlicht hat, braucht für die tägliche Arbeit weder Binärtabellen noch IP-Rechner. Man muss nur wissen, wie die Kante durch das jeweilige Byte läuft.
Das 2er-Potenz-Diktat
Das eigentliche Missverständnis bei IPv4 ist nicht die Mathematik, sondern die Geometrie. Ein Subnetz ist keine flexible Wurst, von der man sich beliebig zwanzig Adressen abschneidet. Es ist ein starrer Block, der sich ausschließlich an Zweierpotenzen ausrichtet.
Wenn du ein /24 in kleinere Netze teilst, kannst du nicht festlegen, dass das Server-VLAN bei .10 anfängt und bei .40 aufhört. Die Bits erzwingen das Raster: Entweder du nimmst einen 32er-Block (/27), der stur bei 0, 32, 64 oder 96 beginnt, oder der Kernel ignoriert deine Absicht. Ein Netz, das nicht auf seiner eigenen Bitgrenze startet, existiert im Routing schlicht nicht.
Im Alltag läuft das auf eine Handvoll fester Schnittmuster hinaus:
Wer Point-to-Point-Links baut – etwa für Transfernetze zwischen zwei Routern oder Firewalls –, greift heute nicht mehr zum historischen /30. Zwei nutzbare Adressen bei vier verbrauchten IPs war pure Verschwendung. Linux und gängige Router-Betriebssysteme nutzen seit Ewigkeiten RFC 3021: Ein /31 liefert exakt zwei Adressen, ganz ohne Netz- und Broadcast-Ballast.
Für Host-Routen und isolierte VPN-Endpunkte bleibt das /32. WireGuard macht das vor: AllowedIPs = 10.200.0.4/32 bindet die Route knallhart an ein einzelnes Device. Kein ARP-Rauschen, kein Subnetz-Overhead.
Brauchst du tatsächliche Segmente mit mehreren Blechen, fängt die sinnvolle Dimensionierung meist erst bei /29 (sechs nutzbare Adressen) an – klassisch für kleine DMZs oder öffentliche Provider-Transfernetze. Alles darüber verdoppelt sich schlicht: /28 gibt 14 Hosts, /27 liefert 30.
Die Denkweise im Kopf muss dabei gar nicht binär sein. Entscheidend ist nur, den Adressraum wie ein Dateisystem zu sehen: Du kannst einen Ordner in zwei Hälften splitten, aber du kannst keine Datei quer über zwei Partitionen legen. Wer versucht, ein /26 ab .32 zu routen, merkt spätestens beim ip route add, dass der Kernel die Maske eiskalt auf die nächste valide Netzgrenze zurücksetzt.
IPv6: Schluss mit der Knauserei
Wer bei IPv6 versucht, dieselben Geiz-Reflexe wie bei IPv4 anzuwenden, baut sich sofort Probleme ein. Der größte Denkfehler beim Umstieg: Man fängt wieder an, Hosts zu zählen. Da werden Transfernetze als /126 oder Server-Segmente als /120 geplant, um ja keine Adressen zu verschwenden.
Lass es. Bei IPv6 zählst du keine Hosts mehr, du verteilst Netze.
Im LAN und Server-VLAN gibt es genau eine funktionierende Größe: /64. Die vorderen 64 Bit gehören dem Routing, die hinteren 64 Bit sind die Interface-ID. Wer dieses Präfix künstlich verkleinert, bricht SLAAC RFC 4862, hebelt Router Advertisements aus und baut sich Fehlerbilder, die im Syslog kaum zu greifen sind. RFC 7421 listet seitenweise auf, warum alles jenseits von /64 im lokalen Segment Murks ist. Die einzige Ausnahme im echten Leben sind Point-to-Point-Links im Backbone, wo man nach RFC 6164 ein /127 setzt, um Ping-Pong-Routing zwischen zwei Routern zu unterbinden. Überall sonst bleibt es beim /64.
Nibble-Grenzen statt Kopfrechnen
Bei IPv6 rechnet man nicht mehr – vorausgesetzt, man hält sich an Nibble-Grenzen.
Jede Hexadezimal-Ziffer bildet exakt 4 Bit ab. Wer seine Netzgrenzen entlang dieser 4-Bit-Schritte plant (/48, /52, /56, /60, /64), muss weder Potenzen wälzen noch Masken subtrahieren. Du zählst einfach die entsprechende Hex-Stelle hoch.
Ein Business-Uplink kommt meist als /48. Damit hast du 16 Bit frei, um eigene Netze zu bauen: genau 65.536 vollwertige /64-Segmente. Beim typischen /56-Präfix am Glasfaser- oder DSL-Anschluss bleiben 8 Bit für eigene Netze – 256 Stück, durchnummeriert von 00 bis ff.
In der Praxis sieht das Subnetting aus einem /56 schlicht so aus:
Präfix vom Provider: 2001:db8:beef:1200::/56
VLAN 10 (Management): 2001:db8:beef:1210::/64
VLAN 20 (Server): 2001:db8:beef:1220::/64
VLAN 30 (DMZ): 2001:db8:beef:1230::/64
VLAN 40 (Gäste): 2001:db8:beef:1240::/64
Zusätzlicher Vorteil: Es gibt keinen Broadcast mehr. Wo IPv4 in jedem noch so kleinen Subnetz zwei Adressen für Netz-ID und Broadcast verbrennt, existiert bei IPv6 kein Broadcast-Verschnitt. Die Auflösung von IP zu MAC übernimmt Neighbor Discovery RFC 4861 per Multicast. Selbst die ::0 an der Schnittstelle wäre technisch ein regulärer Host, auch wenn man sie aus Gewohnheit meist meidet.
Werkzeuge fürs Terminal
Kein Mensch rechnet im laufenden Betrieb Netzmasken im Kopf nach, wenn es schnell gehen muss. Es geht um Verifikation im Terminal und verlässliche Werte für Skripte.
Für IPv4 reicht der Griff zu ipcalc:
$ ipcalc 10.20.30.70/26
Address: 10.20.30.70 00001010.00010100.00011110.01 000110
Netmask: 255.255.255.192 = 26 11111111.11111111.11111111.11 000000
Wildcard: 0.0.0.63 00000000.00000000.00000000.00 111111
=>
Network: 10.20.30.64/26 00001010.00010100.00011110.01 000000
HostMin: 10.20.30.65 00001010.00010100.00011110.01 000001
HostMax: 10.20.30.126 00001010.00010100.00011110.01 111110
Broadcast: 10.20.30.127 00001010.00010100.00011110.01 111111
Hosts/Net: 62 (Class A, Private Internet)
Dass das Tool ganz unten immer noch von „Class A“ faselt, ignoriert man am besten – alte Gewohnheiten sterben in Open-Source-Tools langsam. Wichtig sind Network, HostMin, HostMax und der Broadcast. Wer Bash-Skripte für Provisionierung baut, wirft Parameter wie -n oder --json an, um die Werte sauber in Variablen zu parsen, statt mit awk durch den Text zu sägen.
Bei IPv6 stößt ipcalc je nach Distributionsstand schnell an Grenzen. Da greift man besser zu sipcalc. Das Tool expandiert die Adressen und zeigt die Grenzen ohne Raten:
$ sipcalc 2001:db8:beef:1200::/56
-[ipv6 : 2001:db8:beef:1200::/56] - 0
[IPV6 INFO]
Expanded Address - 2001:0db8:beef:1200:0000:0000:0000:0000
Compressed address - 2001:db8:beef:1200::
Subnet prefix (masked) - 2001:db8:beef:1200:0:0:0:0/56
Prefix length - 56
Network range - 2001:0db8:beef:1200:0000:0000:0000:0000 -
2001:0db8:beef:12ff:ffff:ffff:ffff:ffff
Die Nibble-Grenze liegt offen: Von 1200 bis 12ff läuft der Block. Exakt 256 Netze à /64.
Der wichtigste Befehl beim Debuggen bleibt trotzdem der Kernel selbst. Wenn eine Maschine die Kiste nebenan nicht erreicht, hilft kein Starren auf Interface-Konfigurationen, sondern der direkte Blick in die FIB:
$ ip route get 10.20.30.130
10.20.30.130 via 10.20.30.1 dev eth0 src 10.20.30.70 uid 1000
cache
ip route get fragt den Kernel-Stack: Wohin geht dieses Paket wirklich?
Taucht dort für eine eigentlich lokale IP plötzlich via 10.20.30.1 auf, hat das Präfix auf dem eigenen Interface das Ziel aus dem Layer-2-Segment herausgeschnitten. Der Kernel tut genau das, was die Maske ihm befiehlt. Nicht mehr und nicht weniger.
Das Prinzip im Direktvergleich
Wer beide Protokolle im selben Netz betreibt, schaltet im Kopf um:
| Kriterium | IPv4 | IPv6 |
|---|---|---|
| Denkweise | Adressen sparen, Hosts zählen | Netze verteilen, Segmente zuweisen |
| Schnittkanten | Starre 2er-Potenzen (/24, /27, /29, /31) |
Nibble-Grenzen in 4-Bit-Schritten (/48, /56, /64) |
| Standard-Segment | Meist /24 (254 Hosts) |
Immer /64 (SLAAC-Standard) |
| Point-to-Point | /31 (RFC 3021) oder alt /30 |
/127 (RFC 6164) nur im Core, sonst /64 |
| Host-Route | /32 |
/128 |
| Verschnitt | 2 Adressen pro Netz (Netz-ID + Broadcast) | Kein Broadcast-Verschnitt |
| L2-Auflösung | ARP (Broadcast weckt jedes Interface) | Neighbor Discovery (Multicast via Solicited-Node) |
Am Routing ändert sich zwischen beiden Welten nichts: Der Kernel vergleicht Bits gegen die Maske. Wer die Kanten sauber an die Potenzen und Nibbles legt, muss weder rechnen noch im Dunkeln debuggen.