Hallo zusammen,
heute habe ich einen neuen PC ins Netz integriert. Dazu habe ich
in der /etc/linuxmuster/subnets.csv die Einträge:
...
# Schulnetz - vlan18 (mit freier Range zur Rechneraufnahme);;;;;;
10.18.0.0/16;10.18.255.254;10.18.230.0;10.18.230.10;Schulnetz;;
...
vorgenommen
und mit linuxmuster-import-subnets die freie Range übernommen.
Dann habe ich den Client per pxe gebootet. Leider gab es in der /var/log/syslog folgende Fehlermeldungen:
Aug 29 20:29:23 server dhcpd[726022]: DHCPDISCOVER from 52:91:13:88:35:85 via 10.18.255.254: network 10.18.0.0/16: no free leases
Aug 29 20:29:26 server dhcpd[726022]: message repeated 2 times: [ DHCPDISCOVER from 52:91:13:88:35:85 via 10.18.255.254: network 10.18.0.0/16: no free leases]
Eigentlich hätte ich erwartet, dass der Client eine IP aus dem Bereich
10.18.230.0 bis 10.18.230.10 erhält. Statt dessen erhalte ich no free leases.
modified by linuxmuster-setup at 20200801174905;;;;;;
/etc/linuxmuster/subnets.csv;;;;;; # thomas@linuxmuster.net;;;;;; #
15.12.2013;;;;;; # Beispiele für Subnetzdeklarationen;;;;;; #
Network/Prefix;Router-IP (last IP in network);1.
Range-IP;Last-Range-IP;Intranet Access 0/1;Internet Access 0/1; # Server
vlan16;;;;;; 10.16.0.0/16;10.16.1.253;;;Server;; # Lehrernetz - vlan17
(ohne freier Range zur Rechneraufnahme);;;;;;
10.17.0.0/16;10.17.255.254;;;Lehrernetz;; # Schulnetz - vlan18 (ohne
freier Range zur Rechneraufnahme);;;;;;
10.18.0.0/16;10.18.255.254;10.18.230.0;10.18.230.10;Schulnetz;; #
Servicenetz - vlan19 (mit freier Range zur Rechneraufnahme);;;;;;
10.19.0.0/16;10.19.255.254;;;Service;; # WLANnetz - vlan20 (ohne freier
Range zur Rechneraufnahme);;;;;; 10.20.0.0/16;10.20.255.254;;;WLAN;; |
… deine Subnets sind ja riesig.
Willst du das so?
Da sind jeweils 65534 Hosts möglich pro Subnet.
Sinn der Subnets ist doch, dass die Segmente klein sind …
Meine sind alle /24 … also nur 254 Hosts pro Subnet.
… und ich hätte ja das Lehrernetz mit 10.17.x.y auf vlan 17 gelegt und
nicht auf VLAN 18.
Ebenso hätte ich das Schulnetz mit 10.18.x.y auf VLAN 18 gelegt …
Naja, Ich habe ein Subnet für Schüler, eins für den Lehrerarbeitsraum, eins für Switche, APs, Beamer, … (Servicenetz), eins für WLAN-Geräte des Schulnetzes und natürlich das Servernetz. Gut die Netze sind riesig. Warum nicht? Stärker wollte ich eben nicht unterteilen…
Wenn man sich /etc/dhcp/subnets.conf anschaut, sieht man kein range ....
Naja, Ich habe ein Subnet für Schüler, eins für den Lehrerarbeitsraum,
eins für Switche, APs, Beamer, … (Servicenetz), eins für WLAN-Geräte des
Schulnetzes und natürlich das Servernetz. Gut die Netze sind riesig.
Warum nicht? Stärker wollte ich eben nicht unterteilen…
ein Sinn des Unterteilens ist ja, dass die Broadcasts nicht so groß sind …
Wenn man sich |/etc/dhcp/subnets.conf| anschaut, sieht man kein |range …|.
ich hab’s:
Der Bereich 10.18.230.0 bius 10.18.230.10 wird wegen der 0 von linuxmuster-import-subnets nicht als gültiger Bereich angesehen. mit 10.18.230.1 bius 10.18.230.10 läuft alles.
Hallo Thomas,
ist nicht auch nicht so wichtig. Wie Holger schon bemerkte, sind die Subnets üblicherweise wesentlich kleiner und bei mir. Bei einem 24-er Netz darf hinten keine 0 stehen. Bei einem 16-er Netz, also wie bei mir, darf hinten nicht 0.0 stehen.
Da ich weiß, dass linuxmuster-import-subnets checkt ob hinten eine 0 steht, werde ich das einfach vermeiden
Vielen Dank an alle, die mit mir überlegt haben.
Gruß,
Mathias
Hallo Matthias, einen ähnlichen Verdacht hatte ich auch schon mal, als ich ein großes Netz für die Geräte im WLAN definiert habe und dann bemerkt habe, dass die Adressen mit einer .0 oder .255 am Ende sich irgendwie merkwürdig verhalten haben. Guck mal hier — es ist selbstverständlich weiterhin sehr gut möglich, dass das alles Quatsch ist:
nach einigem Grübeln: Die Netzwerkadresse endet IMMER auf „0“ - aber binär ! Denn wenn die Subnetmaskenlänge über das 24. Bit hinausgeht, gibt es natürlich Kombinationen, wo die unterste mögliche Adresse im Netzwerk minus 1 auf einer Zahl endet, die im 32-Bit-System, das ipv4 benutzt, als letztes Oktett keine „vollständige“ 0 mehr hat - aber sicherlich ist die letzte Binärstelle dann 0 - oft noch mehr.
Beispiele:
10.0.0.253/25 → Netzwerkadresse 10.0.0.128 (7 letzte Bit im letzten Oktett sind 0)
10.0.0.126/26 → Netzwerkadresse 10.0.0.64 (hier sind die letzten 6 Bit des letzten Oktetts 0)
10.0.0.125/27 → netzwerkadresse 10.0.0.96 (hier sind es die letzten 5 Bit).
Es ging aber umgekehrt darum, ob jede auf .0 endende IP eine Netzwerkadresse ist und dieser Umkehrschluss gilt eben nicht und dazu reicht ein einziges Gegenbeispiel (siehe zuvor).
Außerdem müsste man genau betrachtet ab /24 in Richtung /16 sich dann das 3. statt dem 4. Oktett anschauen und dann stimmt deine Aussage auch wieder nicht. Zum Beispiel IPcalc 10.0.0.0/16 in /23 aufteilen, hier findest du 127 Netze gelistet, die im 3. Oktett keine .0 haben. Und jedes der /23er Subnetze hat eine IP X.Y.Z.255 und X.Y.Z+1.0 als gültige Hostadresse, nämlich genau dort wo jeweils zwei /24er Netze (Z = gerade und Z+1) aneinander liegen, wenn man die /23er Netze nochmal zu /24er halbieren würde.
Ach so - da hab ich mich nicht deutlich genug ausgedrückt: Ich meinte lediglich das allerletzte (!) Oktett natürlich ! (Das .0 sollte die abschließende Null sein !)
Und doch, es ging mir um die Frage:
die ich dadurch mit einem klaren Nein beantworte - so, wie bereits Till oben - nur eben halt begründet.
