unsere Clients sind in einem größeren /22-IP-Netz (mit Netzmaske 255.255.252.0). Das IP-Netz erstreckt sich somit von X.Y.Z.0 bis X.Y.[Z+3].255. Dadurch sind dies gültige Client-IP-Adressen:
X.Y.Z.255
X.Y.Z+1.0
X.Y.Z+1.255
X.Y.Z+2.0
X.Y.Z+2.255
X.Y.Z+3.0
Diese IP-Adressen lassen sich auch in der WebGUI eintragen, aber die Clients booten nicht, da sie keine IP-Adresse per DHCP erhalten. Beim Nachsehen in /etc/dhcp/ ließen sich dort in keiner Datei Einträge für meine zwei Testrechner mit X.Y.Z.255 und X.Y.Z+1.0 finden. Wird dies ggf. irgendwo noch gefiltert? Falls ja, wäre es schön, wenn dieser Filter Netzgrößen und Netzmasken beachtet.
Meine subnets.csv sieht so aus:
# modified by linuxmuster-setup at 20200625114504
# /etc/linuxmuster/subnets.csv
#
# thomas@linuxmuster.net
# 20181205
#
# Network/Prefix ; Router-IP (last available IP in network) ; 1. Range-IP ; Last-Range-IP ; SETUP-Flag
#
# server subnet definition
X.Y.Z.0/22;X.Y.Z.1;X.Y.Z.201;X.Y.Z.250;SETUP
# add your subnets below
#
und ich kann auch Clients mit IPs der Form X.Y.[Z+1].[1-254] verwenden, nur eben nicht das was bei einem /24-Netz üblicherweise Netz- und Broadcastadresse wäre.
was Du schreibst stimmt: Das sind gültige IP-Adressen. Trotzdem machen Adressen mit …0 und …255 bei allen möglichen Tools Probleme, man kann sich nie darauf verlassen, dass sie funktionieren. Ich würde sie einfach nicht verwenden - es gibt ja genügend andere.
das ist jetzt nicht die Antwort, die man erwarten würde, wenn man dem Hersteller sagt der Netzwerkstack „rechnet“ nicht richtig. Ich habe ja kein /22 weil ich so viele Adressen übrig habe, sondern weil ich sie brauche.
Da die meisten Programme auf die Bibliotheken des Betriebssystems zurückgreifen, kann man schon davon ausgehen, dass diese Netzmasken sauber behandeln. Wenn es eine Liste von Problemkandidaten unter den Tools gibt, kann ich die gerne mal einem Test unterziehen, ansonsten bestrachte ich das Argument als vorgeschoben. Sorry.
Du hast insofern Recht, dass diese Adressen funktionieren sollten und dass hier offenbar etwas im Argen ist, in das man reinschauen muss. Gut, dass Du dazu hier aufmerksam machst.
Jörg ist jedoch nicht der „Hersteller“ von dem Du sprichst und hat Dir nur als Community-Mitglied einen Tipp gegeben.
Den ich im Übrigen so auch wiederholen möchte: wenn Du doch weißt, dass sie nicht funktionieren, dann verwende sie doch einfach (vorerst) mal nicht, bis das Problem gefixt ist. Denn hey: es handelt sich um 6! IPs weniger, die Du verwenden kannst. Ich kann mir nicht vorstellen, dass das den Kohl wirklich fett machen sollte!? Und falls doch, und Du brauchst wirklich 6 IPs mehr, dann weißt Du ja offensichtlich, wie man das Netz auch noch größer machen kann
Hallo Buster,
Das erste Netzwerk ist X.Y.0.0 . Das nächste ist X.Y.4.0 und so weiter.
Dein Z ist also nich völlig beliebig, sondern ein Vielfaches von 4.
X.Y.Z.0 ist das Netzwerk, also keine IP-Adresse.
X.Y.Z+3.255 ist die Broadcast-Adresse für dein Netzwerk. Die kannst du auch nicht benutzen.
An sonnten sollte alles gehen.
Gruß,
Mathias
ich habe kein Problem mir auszurechnen, welche IPs ich nutzen kann und was Netz- und Broadcast-Adressen sind, sondern dass ich mittendrin unerwarteterweise etliche IPs eben nicht mit Linbo/DHCP nutzen kann.
@Jochen: Ja, es sind nur 6 IP-Adressen weniger und ich habe glücklicherweise aktuell noch die Möglichkeit auszuweichen. Was du dir nicht vorstellen kannst, ist hier aber leider Realität. Das Netz kann nicht ohne weiteres vergrößert werden, weil es „nebenan“ in beide Richtungen andere Netze gibt und weil es einen organisationsweiten IP-Adressplan gibt, der ziemlich voll ist. NAT ist durch diverse Anwendungen keine Option.
Ein weiterer Anwendungsfall: Wöllte man, um unerwartete Spielereien externer Lehrkräfte in Schulungen zu Netzwerkthemen oder Informationssicherheit vorzubeugen (selbst schon erlebt), die Netzwerksicherheit der Schulungsräume verbessen, indem man jeden Schulungsraum in einem eigenen VLAN und IP-Netz betreibt, dann würde man kleinere Subnetze bilden. Zum Beispiel 16x /28er Netze zu je 16 IPs. Zieht man ein /24 als Vergleich ran, wären darin 30 „ungültige“ Client-IP-Adressen enthalten (15 Netzadressen und 15 Broadcastadressen, siehe hier). Würden diese in der Konfigurationsdatei des DHCP-Servers landen? Falls ja, warum diese und meine aus dem ersten Beitrag nicht?
Ich habe einen Workaround. Danke für die Hinweise. Ich will mit meinem Beitrag nur unterstreichen, dass es beim Thema IP-Adressierung nicht damit getan ist zu sagen, wie filtern mal eben die .0 und .255 weg.
Nebenbei: Mich würde mal interessieren, ob sich jemand schonmal mit IPv6 bei der Imageverteilung mit Linbo beschäftigt hat. Wären die Tools IPv6-fähig und „nur“ etwas GUI-Pflege nötig? Das würde ja jegliche zukünftige Schmerzen bezüglich IPv4-Adressierung und Netzgrößen beseitigen.
Hallo Buster,
kannst du dein Netzwerk angeben. Das würde die Sache eventuell vereinfachen. So könnte man das Problem mal auf einer virtuellen Maschine nachvollziehen.
Bei meinem WLAN-Netz (10.20.0.0/16) tritt das Problem nicht auf. Da gibt es einen Client mit der IP 10.20.20.255?!?
Gruß,
Mathias
