Subnetz der Fritzbox mit größerem Subnetz (CIDR weitergefasst als 24 ,z.B.16) möglich?

[Streifix]

Problem:

Mein Heimnetz ist immer weiter gewachsen u.a. durch IoT-Komponenten. Jetzt suche ich nach einer einfachen Lösung, das Subnetz zu erweitern, in dem die Gräte untereinander, aber auch mit der Fritzbox kommunizieren können (und auch das Internet erreichen können).

Eine naheliegende Lösung wäre ja, einfach die Subnetmaske in der FB auf z.B. 255.255.0.0 zu setzen, auch denn wenn ich kein10.x.x.x Netz verwende. Ich verwende derzeit 192.168.0.x und möchte nun 192.168.x.x verwenden.

Wenn ich in der FB einfach die "weitere" Subnetzmaske einstelle, können dann Geräte, die selber eine 192.168.2.x haben, mit der FB und auch mit anderen Geräten, die z.B. die 192.168.1.x haben, kommunizieren? Muss ich dazu dann auch die Subnetzmaske der einzelnen Teilnehmer unbedingt auf /16 bzw. 255.255.0.0 setzen?

Ich habe im Forum einige Beiträge gelesen, dass man nach Einstellen der erweiterten Maske in der FB nicht mehr mit der FB kommunizieren kann. Auch wenn ich die Notfall IP der FB kenn, wollte ich vor dem Ausprobieren diese Frage mal im Forum stellen.

 

[Ic3HanDs]

Normalerweise können die weiterhin untereinander kommunizieren ohne die SNM anzupassen. Aber eben nur im entsprechend verkleinertem Kreis weil alles andere für die Geräte ein anderes Netz ist. Und andere Netze werden immer über SGW erreicht.

Generell empfehle ich aber eher die ganzen IOT Geräte etc in ein eigenen Netz zu packen statt alles in eins. Vor allem direkt auf /16 ist maßlos übertrieben. Wenn du auf /23 gehst hast schon 510 IP Adressen nutzbar. Kann mir eh kaum vorstellen das jemand ~250 Geräte selbst zuhause hat..

 

[Yuuri]

Ja dann stell sie auf 192.168.0.0/16. Die Subnetzmaske wird automatisch per DHCP verteilt.

 

[DeusoftheWired]

Bei einem 192.168.-Netz hast du eben nicht mehr 254 Hosts, sondern 254 × 254 Hosts, also 64.516 Hosts 256 × 256 − 2 Hosts, also 65.534 Hosts.

192.168. ist dabei der Netzanteil, alles danach der Anteil für IPs von Hosts. Ein Host mit der IP 192.168.1.85 kann deshalb ohne weiteres einen Host mit der IP 192.168.2.89 erreichen, weil 1. und 2. nicht mehr Subnetze sind, sondern eben im Hostteil stecken. Die 65.534 möglichen Host-IPs werden auf die hinteren beiden Oktette verteilt.

255.255.0.0-Subnetzmaske natürlich vorausgesetzt.

 

[evilhunter]

@DeusoftheWired

Auch wenn es hierfür keine Rolle spielt, hierbei hast du falsch gerechnet.
Du musst die 2 Adressen für Broadcast und Netz erst am Ende rausrechnen also 256*256-2.
Dann kommt man sogar auf 65534 Adressen die man belegen kann

 

[Rome1981]

Eigentlich setzt man die SN immer so, dass man den kleinstmöglichen Bereich abdeckt. In deinem Fall wäre das die 255.255.254.0, womit du den IP-Bereich von 192.168.0.0 bis 192.168.1.255 abdeckst. Dann können alle Geräte auch direkt miteinander sprechen und müssen nicht geroutet werden.

 

[Streifix]

Vielen Dank für die schnellen Antworten.

Immer noch nicht klar ist mir, ob alle nicht per DHCP konfigurierten Geräte auf die größere Subnetzmaske, als /16 oder auch /20 eingestellt werden müssen, um untereinander kommunizieren zu können. Wenn die FB als Router/WLAN-Access-Point dazwischen liegt, muss diese doch eigentlich nur wissen, dass die Hosts zum erweiterten Subnetz gehören?

 

[Rome1981]

Da musst du vorsichtig sein. ENTWEDER Subnetting ODER Routing. Wenn die SN sagt, dass alle miteinander sprechen können, dann routet die FB nicht und die Geräte mit "falschem" SN können mit denen außerhalb ihres eigenen SN nicht sprechen!

Also alle Geräte mit der passenden SN versehen und los geht's. Routing ist in solchen Fällen immer nur zweite Wahl.

 

[Streifix]

@Rome1981
Das leuchtet mir ein. Ich denke ich sehe jetzt klarer. Zwar ist mir noch nicht ganz klar, ob bei "unterschiedlichen" Subnetzen nur über das WLAN und die FB nicht kommuniziert werden kann oder ob das auch für Geräte gilt, die z.B. am selben Hub oder Switch hängen. Solange sie nicht auf ein Broadcast reagieren müssen und nicht geroutet werden müssen, sollte die Kommunikation doch trotzdem möglich sein, solange kein IP-Filter die Pakete im Switch ausfiltert?

 

[Rome1981]

Letztlich ist der Netzwerkaufbau irrelevant. Das Gerät selbst sendet und empfängt nur Pakete von Geräte, die in seinem eigenen SN hängen. Deswegen muss ein Router ja auch in allen Subnetzen/Netzen sein, zwischen denen er vermittelt. Du kannst also auch generell das SN mit /23 verwenden und innerhalb dieses dann Rechner mit einem /24 oder von mir aus auch /31 einrichten... sie können dann aber immer nur mit Geräten im gleichen SN reden.

 

[h00bi]

Zwar ist mir noch nicht ganz klar, ob bei "unterschiedlichen" Subnetzen nur über das WLAN und die FB nicht kommuniziert werden

Die FB kann nur in einem Subnetz sein (mit Gastnetz zwei). Consumer Device halt.
Alle Geräte nicht im gleichen Subnetz wie die FB sind, können nicht mit der Fritzbox kommunizieren und daher auch nicht in andere Subnetze oder ins WAN/Internet geroutet werden.
Untereinander können die Clients beliebig kommunizieren, die Fritzbox kann das in einem Netz was sie nicht kennt auch nicht unterbinden.

Wenn du die Subnetzmaske an der Fritzbox anpasst, wird diese auch per DHCP an die Clients verteilt.

 

[Raijin]

Grundsätzlich müssen alle Geräte die geänderte Subnetzmaske haben, um miteinander kommunizieren zu können. Zwar geht es innerhalb der Überschneidung von altem zu neuem Subnetz auch ohne neue Subnetzmaske, zum Teil. Da sich die Broadcast-Adresse mit der Subnetzmaske ändert, werden Verbindungen, die mit Broadcasts arbeiten - zB UPnP bzw. DLNA, aber auch zahlreiche IoT-Protokolle - nicht funktionieren.
Wenn ein IoT-Protokoll zum Einsatz kommt, das mittels Broadcasts IoT-Devices oder einen Master findet, wird das kläglich scheitern, wenn nicht alle beteiligten (Device und Master, etc) dieselbe Subnetzmaske haben.




Grundsätzlich rate ich dir dringend davon ab, an deinem Subnetz rumzuspielen, wenn du nicht weißt was du da tust - was offensichtlich ist. Zum einen ist es vollkommen unsinnig, auf ein /20 oder gar /16 Subnetz zu erweitern und zum anderen macht man dies dann um Himmels willen nicht mit 192.168.0.0 als Start. Wenn du viel IoT hast, wirst du zwangsläufig eher früher als später auch eine VPN-Verbindung von unterwegs nach Hause einrichten wollen. Wenn es soweit ist, garantiere ich dir, dass du dir bei einem - sorry - schwachsinnigen 192.168.0.0 /20 oder gar /16 Subnetz voll gegen die Wand fahren wirst, weil du gefühlt von 98% der privaten Netzwerke (Freunde, Familie, etc), aber auch von zahlreichen Hotels, Cafés und dergleichen keine funktionierende VPN-Verbindung zustande bringen wirst, weil sich die Subnetze von beiden Standorten überschneiden.

Wieviele Geräte hast du denn im Netzwerk, wenn du meinst, ein /16er Netz zu benötigen? Kommst du tatsächlich an 254 Geräte heran oder was ist genau dein Problem?

Hat man wirklich so viele Geräte und ein /24er Subnetz reicht tatsächlich nicht aus, erweitert man auf /23 oder von mir aus /22. Wirklich zielführend ist das jedoch nicht, weil man an dieser Stelle besser damit bedient wäre, die Geräte in jeweils eigene Subnetze zu packen und über VLANs zu trennen. Dazu ein kleiner Router, der die zusätzlichen Netzwerke handhaben kann (zB ein EdgeRouter-X) und VLAN-fähige Switches damit man die Netzwerke auch auf derselben Infrastruktur laufen lassen kann.
Auch da muss man sich allerdings um Broadcasts Gedanken machen, da selbige nicht geroutet werden, aber das ist eine Frage der sinnvollen Aufteilung in die Netzwerke bzw. VLANs - im worst case gibt es auch die Möglichkeit eines Broadcast-Relays.

Fakt ist aber, dass dein Wunsch nach einem größeren .. .. nein, gigantischem Subnetz auf Basis der gegebenen Informationen nicht nachvollziehbar und auch nicht zu empfehlen ist. Du meinst gelesen zu haben, dass du irgendwas tun musst oder irgendjemand, der das selbst irgendwo gehört und auch keine Ahnung hat, hat dir einen Floh ins Ohr gesetzt. Das erste Wort in diesem Thread ist "Problem", aber es wird kein Problem geschildert, sondern nur, dass du meinst ein Problem zu haben, aus Gründen, die du nicht nennst. Ich behaupte einfach mal, dass du eigentlich gar kein Problem hast, weil du nicht mal ansatzweise an 254 Geräte im Netzwerk herankommst und das bisherige /24 Subnetz wunderbar auch noch die nächsten Jahre ausreichen würde - wenngleich ich dir dringend zu einem anderen Subnetz als 192.168.0.0 rate (ungeachtet ob's /24 oder /16 ist), wenn du dir irgendwann mal einen VPN-Zugang von außen einrichten willst.

 

[Raijin]

Immer noch nicht klar ist mir, ob alle nicht per DHCP konfigurierten Geräte auf die größere Subnetzmaske, als /16 oder auch /20 eingestellt werden müssen, um untereinander kommunizieren zu können.

Zwar ist mir noch nicht ganz klar, ob bei "unterschiedlichen" Subnetzen nur über das WLAN und die FB nicht kommuniziert werden kann oder ob das auch für Geräte gilt, die z.B. am selben Hub oder Switch hängen.

Beispiel:

Gerät A = 192.168.0.11 /24
Gerät B = 192.168.0.22 /23
Gerät C = 192.168.1.33 /23
Gerät D = 192.168.2.33 /23

A kann nach wie vor mit B sprechen, da beide davon ausgehen, dass die jeweilige Ziel-IP 192.168.0.x immer noch ihrem eigenen, lokalen Subnetz liegt. Zwar ist der lokale Subnetzbereich für B größer als für A, aber sie überschneiden sich im relevanten Teil (192.168.0.x).

B kann mit C reden, da sie ebenfalls davon ausgehen, dass das jeweilige Ziel im eigenen, lokalen Subnetz liegt. Da sie auch dieselbe Subnetzmaske verwenden, "überschneiden" sich die Subnetze vollständig, es ist also ein und dasselbe Subnetz

A kann aber nicht direkt mit C reden, da C zwar A's IP 192.168.0.11 ebenfalls als lokal definiert und somit direkt anspricht, aber für A liegt die IP von C 192.168.1.33 außerhalb des lokalen Subnetzes und somit würde die Antwort nicht direkt an C gehen, sondern an A's Standardgateway (, welches potentiell weiterleitet, aber das lassen wir mal außen vor).

D kann mit niemandem reden, da dessen IP-Adresse zu einem Subnetz gehört (192.168.2.0/23), das keinerlei Überschneidungen mit den Subnetzen von A (192.168.0.0/24) oder B/C (192.168.0.0/23) hat.

Nu könnte man denken, dass man sich das zunutze macht, um beispielsweise IoT-Geräte "wegzukapseln", indem man sie mit einer engeren Subnetzmaske nur auf einen fiktiven Hauptteil des Subnetzes beschränkt, oder? Theoretisch ja, praktisch handelt man sich dann aber deutlich mehr Probleme ein als man dadurch meint zu lösen.

Wie ich oben aber bereits andeutete, werden Verbindungen, die auf Broadcasts basieren bzw. selbige zum Verbindungsaufbau nutzen (zB Server-Suche), scheitern. Ich kann mich daher nur wiederholen, dass man an der Subnetzmaske nicht ohne Grund rumspielt und wenn man es tut, dann sollte man es auch richtig machen. Dazu zählt eine sinnvolle Größe des Subnetzes - ich bin immer noch davon überzeugt, dass dir 254 IP-Adressen reichen, solange du nicht tatsächlich 200+ Geräte hast - sowie eine sorgfältig ausgewählte Subnetzadresse. 192.168.0.0 / 192.168.1.0 / 192.168.2.0 / 192.168.178.0 und noch ein paar mehr für etwaige sonstige Ab-Werk-Subnetze verschiedener Hersteller (zB 192.168.8.0 von gli-net) decken ca. 99,9% sämtlicher privater Netzwerke auf diesem Erdball ab. Dazu noch eine nicht zu vernachlässigende Anzahl von laienhaft eingerichteter geschäftlicher Netzwerke (zB Hotels, etc). Sobald man über VPN nachdenkt, wird man damit schnell gegen die Wand laufen.

 

[Datax]

Auch da muss man sich allerdings um Broadcasts Gedanken machen, da selbige nicht geroutet werden, aber das ist eine Frage der sinnvollen Aufteilung in die Netzwerke bzw. VLANs - im worst case gibt es auch die Möglichkeit eines Broadcast-Relays.

Kannst du mir näher erläutern wie du das meinst?

Beziehst du dich dabei auf das Problem, das du zuvor bezogen auf IoT-Geräte angesprochen hast?
Also, dass IoT-Geräte, die sich in unterschiedlichen Subnetzen befinden und sich untereinander per Broadcast "suchen", dann nicht mehr finden können?

Stehe da gerade auf dem Schlauch ^^.

Gruß, Datax

 

[Raijin]

Ganz genau. Die letzte IP-Adresse in einem Subnetz ist die Broadcast-Adresse. Alles was dahin geschickt wird, taucht bei allen Teilnehmern des Subnetzes im Eingangskorb auf. Wenn nun also ein Server eines beliebigen Protokolls, das mit Broadcasts arbeitet, via Broadcast ins Netzwerk ruft, dass er da ist, können das alle lesen, die sich im selben Subnetz befinden. Andersherum kann auch ein Client mal via Broadcast nach einem Server suchen.

Beispiel 1 : Gemischte Subnetzmaske wie im Thread thematisiert wurde

Gerät A : 192.168.0.123 /24 --> Broadcast-Adresse: 192.168.0.255
Gerät B : 192.168.0.234 /23 --> Broadcast-Adresse: 192.168.1.255

Läuft auf A ein Server, den B via Broadcast sucht, wird kein Server zu finden sein, weil die Broadcast-Adressen unterschiedlich sind. Für A ist der Broadcast von B einfach nur ein eingehendes Datenpaket, das ignoriert wird, weil nicht-eigener-broadcast und auch nicht direkt an A addressiert. Andersherum würde B den Broadcast von A ignorieren, weil er wie ein 08/15 Datenpaket behandelt wird, das einfach nur für einen anderen Teilnehmer des Subnetzes bestimmt ist - für B ist 192.168.0.255 nämlich eine stinknormale IP-Adresse wie 192.168.0.254 auch (trotzdem werden die .255er IPs oftmals trotzdem aus Prinzip nicht an Endgeräte vergeben).
Dennoch könnten sie sich A und B gegenseitig pingen, weil sich die Subnetze überschneiden und beide in der Schnittmenge liegen.


Beispiel 2 : Verschiedene Subnetze (mit oder ohne VLANs) wie oben angesprochen, über einen Router verbunden

Gerät A : 192.168.0.123 /24 --> Broadcast-Adresse: 192.168.0.255
Gerät B : 172.17.23.45 /24 --> Broadcast-Adresse: 172.17.23.255

Erneut, die Broadcast-Adressen sind unterschiedlich. Auch wenn der Router einen Ping von A nach B routen würde und B auch antworten könnte, wird ein Broadcast nur innerhalb des jeweiligen Subnetzes Bestand haben. Selbst wenn B einen Broadcast an 192.168.0.255 schicken würde, sollte der Router diesen Broadcast schlucken und nicht routen, obwohl er den Ping zuvor geroutet hat.


Das bezieht sich in diesem Fall auf directed Broadcasts, die an ein Subnetz gerichtet sind (sei es lokal oder ggfs entfernt). Solche Broadcasts werden aus sicherheitsgründen von Routern nicht geroutet. Ein Ethernet-Broadcast ist etwas anderes, weil der an 255.255.255.255 gerichtet ist und somit Subnetz-unabhängig. Darüber holt sich zB ein DHCP-Client die Adresse des DHCP-Servers und bezieht von ihm dann die IP-Adresse, weil der DHCP-Client zu dem Zeitpunkt ja noch gar nicht weiß in welchem Subnetz er sich bewegen soll.

 

[Datax]

Danke, sehr gute Erläuterung.

Wie funktioniert eigentlich die Verteilung von Broadcasts durch einen Switch?

Wenn ein Switch ein Paket empfängt, dann schaut er sich ja erstmal die Ziel-MAC-Adresse an,
die in dem zuzustellenden Paket eingetragen ist.

Die MAC-Adresse hat der Quell-Client (Client A) ja zuvor per ARP ermittelt und dann entsprechend in das
zu versendende Paket eingetragen.

Wenn der Switch die Ziel-MAC-Adresse (von Client B) nicht kennt, dann gibt er das zuzustellende Paket ja immer auf allen Ports aus.

Er hat ja auch keine andere Möglichkeit, weil er ja erst noch "lernen" muss,
an welchem Port der Ziel-Client (B) mit der betreffenden Ziel-MAC angeschlossen ist.

Bis dahin kennt der Switch den Port des Ziel-Clients also immer noch nicht.

Wenn der Ziel-Client (B) dann später aber ggf. noch an den Quell-Client (A) antwortet (Quelle und Ziel sind dann natürlich vertauscht), dann würde der Switch den Port lernen, wo der vorherige Ziel-Client (B) angeschlossen ist.

Jetzt tritt der vorherige Ziel-Client (B) als Quell-Client auf und trägt seine MAC-Adresse als Quell-MAC-Adresse in das zu versendende Paket ein. Wenn der Switch das Paket dann empfängt "liest" er die Quell-MAC-Adresse des Clients (B) und trägt sich in seiner Tabelle die Zuordnung "Port X - MAC-Adresse XYZ" ein.

Das Gleiche hat er ja am Anfang bei Client A auch gemacht,
wo er genauso die Quell-MAC-Adresse gelesen und sich dann in seine Tabelle eingetragen hat.

So zumindest mein aktuelles Verständnis.

 

[Raijin]

Bei einem Broadcast ist die Destination-MAC stets ff:ff:ff:ff:ff:ff. Dadurch ist es für den Switch offensichtlich, dass es sich um einen Broadcast handelt.

Man kann sich das übrigens mit WireShark bzw. tcpdump schön angucken, wenn man innerhalb des Netzwerks mal einen Host-Namen anpingt. Als erstes wird - zumindest bei Windows - die Namensauflösung über einen Query mittels NBNS (NetBIOS name service @ UDP 137) versucht, der als Broadcast an die Broadcast-IP : 137 udp geschickt und dann kommt - falls vorhanden - vom gesuchten Gerät, das ja den Broadcast auch bekommen hat und sich angesprochen fühlt, eine Antwort zurück.

Dadurch dass sich ein Gerät im Netzwerk oftmals gleich beim Start zB beim DNS mit dem Namen registriert bzw. auch Windows selbst ganz einfach einen Verbindungs-Check auf microsoft.com oder so durchführt, lernt ein Switch die MAC relativ schnell. Und das ist ja nicht das einzige was ständig im Netzwerk durch die Gegend rennt. Mach einmal WireShark ohne Filter an und du siehst binnen weniger Sekunden Tausende von Paketen durch deine Netzwerkschnittstelle flitzen - einem Switch reicht es, wenn eins davon bei ihm vorbeikommt

 

[Datax]

Ja, okay.

Habe bisher bezüglich Broadcasts nicht verstanden, wann "Limited Broadcasts",
also Broadcasts an die 255.255.255.255 verwendet werden und wann Broadcasts an die
Broadcastadresse des lokalen Netz (z.B. 192.168.1.255 beim Netz 192.168.1.0/24).

 

[Raijin]

Das wird jetzt aber etwas zu OffTopic, daher der Vollständigkeit halber nur ein kurzes Beispiel:

Wenn ein DHCP-Client eine IP haben möchte, schickt er einen Broadcast an die 255.255.255.255 (Absender=0.0.0.0), weil er weder eine IP hat noch etwas vom Subnetz weiß. Das ist der DHCP Discover.

 

[Wilhelm14]

Huhu, ich frage auch mal quer rein. Beim IoT-Fuhrpark, muss der wirklich im selben Subnetz sein? Man könnte ihn auch billig mit einem zweiten Router in eine Routerkaskade packen.
https://heise.de/-1825801
https://heise.de/-2099453
Und noch eine Frage als Laie, könnte man nicht mit IPv6 statt IPv4 hantieren, um das Netz größer zu machen?