Meine FRITZ!Box 7530 vergibt einem Debian bullseye mit isc-dhcp-client bei jedem Boot eine neue Adresse. Und nicht einmal fortlaufend, aber auch nicht zufällig: 55, 56, 24, 25, 26. MAC-Adresse und Hostname sind konstant, also, wozu ist das gut und wie stellt man das ab? Und warum bin ich anscheinend der einzige, dem das passiert?
Kann der dhcp-client das provozieren, auch wenn anscheinend alles konstant ist?
Natürlich würde Debian auch ohne dhcp funktionieren und natürlich könnte ich in der Fritzbox "immer die gleiche Adresse" ankreuzen. Aber ich mag dhcp und finde das Verhalten nicht normal.
Natürlich würde Debian auch ohne dhcp funktionieren und natürlich könnte
ich in der Fritzbox "immer die gleiche Adresse" ankreuzen. Aber ich mag
dhcp und finde das Verhalten nicht normal.
Das ist doch weiterhin DHCP. Du sagst deiner FritzBox nur, dass du diesen Eintrag fixieren möchtest. Quasi wie der fixed Eintrag bei der Server Version deines DHCP Dienstes...
Hast du vielleicht ein paar Smartphones im Netz? Die würfeln seit einiger Zeit eine Mac Adresse aus und bekommen dann eine neue IP.
Dadurch könnte die IP deines Linux belegt sein.
Grundsätzlich darf sich der Client auch eine Adresse "wünschen" (Request ohne vorheriges Discover/Offer). Hab ich schon oft gesehen, dass Geräte das tun um ihre "letzte" Adresse wieder zu bekommen.
Würde daher vermuten, dass der Server eine gewünschte, freie und gültige Adresse auch bestätigen würde.
Ob es wirklich so ist, sieht man in der Paketaufzeichnung.
Natürlich würde Debian auch ohne dhcp funktionieren und natürlich könnte
ich in der Fritzbox "immer die gleiche Adresse" ankreuzen.
Ist das nicht genau das was du willst? DHCP funktioniert wie gewohnt, aber wenn die Fritzbox einen Client wiedererkennt und sich erinnert (Anzahl Speicherplätze begrenzt auf ein paar Duzend) dann bekommt der Client die gleiche Adresse wie beim letzten mal, ansonsten bekommt er irgendeine.
Innerhalb der Lease-Time erhält ein Gerät über DHCP üblicherweise von alleine stets die gleiche IPv4 Adresse. Ist die (konfigurierbare) Lease-Time abgelaufen, gibts irgendeine. Das ist das gewohnte Verhalten - sofern die im DHCP genutzte MAC-Adresse nicht jedes Mal neu ausgewürfelt wird.
Wie vorhin schon erwähnt wurde, gibt es immer mehr Clients, die besonders im WLAN eine zufällige MAC-Adresse verwenden, um nicht wiedererkannt zu werden, um nicht darüber verfolgt werden zu können. Von stationären Geräten im Ethernet habe ich das so nicht in Erinnerung, aber es kann durchaus sein, dass es da mittlerweile auch verwendet wird. Ist ja die gleiche Basis.
In solchen Fällen hat das Gerät zwar irgendwo eine feste MAC-Adresse, verwendet sie aber nicht, sondern die verwendete Adresse ist zufällig. Deshalb meine Frage nach der MAC-Adresse, die Fritz sieht. Steht dort ja drin.
Bei Android kann man beispielsweise für jedes WLAN einzeln wählen, ob die feste oder eine zufällige MAC-Adresse genutzt wird. Im eigenen Netz wird man gerne die feste nehmen, in Fremdnetzen eher die zufällige.
natürlich könnte
ich in der Fritzbox "immer die gleiche Adresse" ankreuzen. Aber ich mag
dhcp und finde das Verhalten nicht normal.
Der dhcpd in der Fritte ist seit Jahren buggy, nur fällt das nicht immer auf. Der Haken geht i.O., es bleibt ja dhcp. Stelle zusätzlich die lease time auf den kleinsten Wert, damit verschwinden viele Merkwürdigkeiten.
Kann der dhcp-client das provozieren, auch wenn anscheinend alles
konstant ist?
Er kann sich eine bestimmte IP-Adresse wünschen, das muss nicht zwingend
die angebotene sein.
aber gerade dann wäre die ja konstant. Hier gibt es zwei PCs und ein Telefon, also ist auch reichlich Platz in den Tabellen. Also erstmal vielen Dank miteinander.
Innerhalb der Lease-Time erhält ein Gerät über DHCP üblicherweise von
alleine stets die gleiche IPv4 Adresse. Ist die (konfigurierbare)
Lease-Time abgelaufen, gibts irgendeine. Das ist das gewohnte Verhalten
sofern die im DHCP genutzte MAC-Adresse nicht jedes Mal neu
ausgewürfelt wird.
Der dhcpd in der Fritte ist seit Jahren buggy, nur fällt das nicht immer
auf. Der Haken geht i.O., es bleibt ja dhcp. Stelle zusätzlich die lease
time auf den kleinsten Wert, damit verschwinden viele Merkwürdigkeiten.
In der Firma mache ich das genau so, aber das ist auch keine Fritzbox. Ich hatte gehofft, es gibt einen vernünftigen Grund, aber "buggy" muss heutzutage wohl als Erklärung reichen ;)
Im privaten LAN - außer für iPhone oder iPad - DHCP zu nutzen, ist in
meinen Augen vollkommen sinnfrei!
Eher umgekehrt ;) Sobald das iPhone anfängt, zufällige MAC-Adressen zu erzeugen, bekommt es eine feste (falls das dann noch möglich ist). DHCP ist doch praktisch überall Default und funktioniert (normalerweise). Von älteren Windows-Versionen weiß ich noch, dass die mit DHCP sofort problemlos liefen und feste Adressen immer irgendwo hakelig waren.
Desktoptechner, Drucker etc. bekommen eine statische IP und fertig …
dann muss man sich auch keine Gedanken um eine viel zu kurze lease-Time
machen
Normalerweise bekommen die auch per DHCP eine feste Adresse und normalerweise ist die lease-Time ziemlich egal, weil sich der Rechner die letzte Adresse merkt und wünscht. Gerade im privaten LAN funktioniert das -- nur bei meiner Fritzbox nicht :(
Im privaten LAN - außer für iPhone oder iPad - DHCP zu nutzen, ist in
meinen Augen vollkommen sinnfrei!
Und in meinen Augen kann es sehr wohl Sinn ergeben. Spätestens dann, wenn darin installierte Geräte nicht vor Ort festgeklebt oder -geschraubt sind, ist DHCP mit ggf fixierter Adresse recht praktisch. Ebenso wenn Kleingeräte und Blackboxes nur umständlich auf eine feste IP-Adresse konfiguriert werden können, etwa IoT-Kram oder NAS-Devices.
Ich hatte gehofft, es gibt einen vernünftigen Grund, aber "buggy" muss
heutzutage wohl als Erklärung reichen ;)
Ich habe das nicht näher untersucht und bin eigentlich zufällig drüber gestolpert. Ich mache doch nicht AVMs Hausaufgaben, insofern muss "buggy" hier in der Tat reichen ;)
In der Grundkonfiguration steht die leasetime auf IIRC 10 Tage. Das in Kombination mit dem von dir beobachteten Verhalten und vielen Clients sorgte dafür, dass der dhcpd irgendwann ausstieg, weil er wohl seine Tabelle nicht weiterschreiben konnte. Das ging bis zum eigenständigem Neustart der Box. Stellt man die leasetime auf den kleinsten Wert, verschwindet der eigentlich unnötige Spuk und sämtliches seltsames dhcp- Verhalten.
Im privaten LAN - außer für iPhone oder iPad - DHCP zu nutzen, ist in
meinen Augen vollkommen sinnfrei!
Diese Art von Geräten ist bei modernen Haushalten die Mehrheit.
Desktoptechner, Drucker etc. bekommen eine statische IP und fertig
Bei modernen Druckern hat man oft keine Möglichkeit mehr die IP Adresse von Hand einzugeben, die haben nur noch einen Knopf und den Ein/Ausschalter.
Bei IPv6 ist die dynamische Adressvergabe ohnehin Pflicht.
Mit vernünftigem DHCP Server (wie etwa in einer FritzBox) kann man aber immer noch quasi statische IP Addresszuweisunge machen, d.h. einfach Adressen fest zuweisen.
Das ist in meinen Augen erheblich besser als das manuelle Gefummel an jedem Device einzeln.
Um im Fritz nicht mit einer endlosen Liste von Eintagsadressen der immer gleichen Smartphones konfrontiert zu werden, kann es sinnvoll sein, diese Geräte innerhalb des Heimnetzes mit ihrer echten MAC arbeiten zu lassen. Mindestens in Android ist das für jede SSID konfigurierbar. Das schont die Ressourcen vom Fritz und die eigenen Nerven.
Um den Verdacht auszuräumen, dem Fritz seien irgendwelche Ressourcen ausgegangen, kann man darin die Leichen verbrennen. Also alle toten Geräte in der Liste löschen (gibt wohl einen Knopf eigens dafür). Und ihn dann durchstarten.
kann man darin die Leichen verbrennen. Also alle toten
Geräte in der Liste löschen (gibt wohl einen Knopf eigens dafür).
Ja, gibt es. In dem von mir beobachteten Fall hat das am Verhalten nichts geändert, die so frei gewordenen IPs wurden nicht erneut vergeben. Noch aktive Clients wurden weiter mit Daten versorgt, bis sich wohl irgendwann zuviele dhcp-Requests gestapelt hatten. Darauf folgte der selbstständige Neustart der Box.
Und ihn dann durchstarten.
Witzigerweise (naja) reichte der manuelle Neustart, um die Box auch wieder IPs vergeben zu lassen, die noch in der Liste der ungenutzten Verbindungen standen. Gaga.
Also ein Software-Problem, kann man nichts machen :)
So in der Art :)
Ich will gar nicht behaupten, dass das hier das Problem ist. Das oben beschriebene Verhalten konnte ich seinerzeit auf der 7390, 7490 und 7590 nachstellen. Bei allen waren alle Merkwürdigkeiten mit kürzest möglicher Leasetime verschwunden. Da ich glücklicherweise nicht so wirklich viel mit Fritten zu tun habe, habe ich das nicht weiter untersucht. In diesem Sinne: Versuch macht kluch.
Ich habe einiger ältere Geräte die eine Feste IP brauchen.
Also habe ich in meiner Fritzbox ein Festen IP-Block angelegt.
Sobald ich ein Gerät benutze, was eine Zwangs-IP (die ich in den Block lege) braucht, vergebe ich diese im Gerät, in der Fritzbox anmelde, sage ich der Fritzbox bei den Gerät, "Dieses Gerät immer mit der selben IP anmelden".
Und schon ist alles o.k. Mir ist es dann egal ob der DHCP ihm die richtige IP gibt, oder es die Anforderung des Gerätes nimmt. In der Box bekommt es IMMER die richtige IP.
Vielleicht redet ihr auch aneinander vorbei. Der Client kann beim DHCP seine früher per DHCP erhaltene Adresse mitschicken, in der Hoffnung, sie zu behalten. Verlass ist darauf aber nicht, es ist kein Ersatz für eine feste Adresse, oder eine im DHCP-Server festgenagelte.
"The DHCP client broadcasts a DHCPDISCOVER message on the network subnet using the destination address 255.255.255.255 (limited broadcast) or the specific subnet broadcast address (directed broadcast). A DHCP client may also request its last known IP address. If the client remains connected to the same network, the server may grant the request."
Also entweder geräteseitig fixe IP, dann natürlich außerhalb des
dhcp-Adressraumes, oder dhcp. Aber nicht beides.
Auch wenn die Fritzbox das anders handhabt, weder clientseitig noch durch den DHCP-Server vergebene feste IP-Adressen gehören in den Pool-Bereich.
Ich trage auch lokal eingetragene IPs oft zusätzlich im DHCP-Server ein. Hat den Vorteil, dass a) auch nach einem Factory Reset mit DHCP als Default die IP stimmt und b) man in der Config an das Vorhandensein solcher Clients erinnert wird.
Auch wenn die Fritzbox das anders handhabt, weder clientseitig noch
durch den DHCP-Server vergebene feste IP-Adressen gehören in den
Pool-Bereich.
Wie man das organisiert, wie es zum eigenen Ordnungssinn passt, kann jeder für sich entscheiden. Aber eine IP-Adresse auf den vergebenen Stand festzunageln ist von Verfahren her problemlos. Die liegt dann im normalen DHCP-Bereich, denn so wurde sie ja vorher vergeben, ist aber ab der Festlegung für die betreffende MAC-Adresse reserviert. DHCP ist es immer noch.
Lokal im Gerät festgelegte IP-Adressen sind dort essentiell, wo man die Adresse auch ohne DHCP benötigt, beispielsweise um im Problemfall ran zu kommen. Weshalb es sich empfiehlt, die Adresse des DHCP-Server nicht per DHCP zu vergeben.
Auch wenn die Fritzbox das anders handhabt, weder clientseitig noch
durch den DHCP-Server vergebene feste IP-Adressen gehören in den
Pool-Bereich.
Das ist wirr. Eine am Client fest eingestellte IP gehört außerhalb des Pools. Eine vom dhcp-Server für einen Client festgenagelte IP ist selbstverständlich innerhalb des Pools, wird dann aber natürlich nicht mehr an andere Clients vergeben.
Beim Microsoft DHCP-Server ist es der Unterschied zwischen Kontextmenu "Zur Reservierung hinzufügen" und umständlichem Neueintrag einer MAC-Adresse, die man freundlicherweise nicht aus dem bestehenden Lease rauskopieren kann.
Eine vom dhcp-Server für einen Client festgenagelte IP ist
selbstverständlich innerhalb des Pools
Das mag in Deiner Fritzbox-Welt so sein, beim ISC dhcpd sind die Ranges explizit für dynamische Zuweisungen gedacht, Haken bei Nichtbeachtung siehe oben.
Ich blockiere den Bereich von 192.168.0.1 - 192.168.0.30 für DHCP.
Damit das nicht wieder aneinander vorbei geht: Du schliesst diesen Bereich für die Nutzung durch DHCP aus. Man könnte auch sagen, du definiert einen anderen Bereich für DHCP, denn das ist die gängigere Konfigurationsmethode.
Ich blockiere den Bereich von 192.168.0.1 - 192.168.0.30 für DHCP.
Damit das nicht wieder aneinander vorbei geht: Du schliesst diesen
Bereich für die Nutzung durch DHCP aus. Man könnte auch sagen, du
definiert einen anderen Bereich für DHCP, denn das ist die gängigere
Konfigurationsmethode.
sage
ich der Fritzbox bei den Gerät, "Dieses Gerät immer mit der selben IP
anmelden".
Beides geht nicht, und genau das ist der Widerspruch! Bei Geräten außerhalb des Pools kannst du dem dhcp-Server nicht sagen, er solle dem Gerät immer die geräteeigene IP geben, denn er gibt ihm ja gar keine IP.
Beides geht nicht, und genau das ist der Widerspruch! Bei Geräten
außerhalb des Pools kannst du dem dhcp-Server nicht sagen, er solle dem
Gerät immer die geräteeigene IP geben, denn er gibt ihm ja gar keine IP.
Kein Widerspruch, lediglich sondern technisch überflüssig.
Man kann es trotzdem reinschreiben. Wenn man sonst gerade nichts zur Hand hat, um sein Netz zu dokumentieren.
beim ISC dhcpd sind die Ranges
explizit für dynamische Zuweisungen gedacht
Das ist mir alles bekannt. Du ignorierst aber geflissentlich den von dir
selbst genannten Haken
Ganz im Gegenteil. Ich begründe mit dem Haken, warum feste Zuweisungen - auch im DHCP-Server vorgenommene - nicht in den dynamischen Poolbereich gehören.
Das Problem ist auch kein rein hypothetisches: Wenn so ein Client mal eine Weile offline ist (Laptop ausser Haus, Drucker abgeschaltet etc.), kann dessen Adresse anderweitig dynamisch vergeben werden.
Das Problem ist auch kein rein hypothetisches: Wenn so ein Client mal
eine Weile offline ist (Laptop ausser Haus, Drucker abgeschaltet etc.),
kann dessen Adresse anderweitig dynamisch vergeben werden.
Eine Adresse, die im DHCP-Server explizit als reserviert gekennzeichnet ist, wird von ihm nicht anderweitig vergeben. Auch nicht nach 2 Jahren. So ist es jedenfalls üblich.
Obacht: Eine solche Reservierung findet im DHCP-Server statt, nicht im Client und hat nichts mit einer manuell im Client definierten Adresse zu tun.
"While ISC dhcpd will allow a static mapping to be defined inside the
DHCP range/pool, it can result in unexpected behavior."
Der Satz kann missverstanden werden. Vielleicht bedeutet das nur, dass eine manuelle IP-Konfiguration im Client nicht innerhalb der vom DHCP-Server verwalteten IP-Range liegen darf. Und es nicht um reservierte IP/MAC-Zuordnungen seitens des DHCP-Servers geht.
Die Umstände sind weiter oben beschrieben. Nimm dir eine Fritte und 50
Clients und probiere es aus.
Was soll da besonderes passieren? So lange der DHCP-Bereich der Fritzbox groß genug ist (also mindestens 50+<ein paar> Adressen umfaßt), passiert da nix abnormales. Und wenn der DHCP-Bereich zu klein für die Clientzahl ist, passiert dieselbe Scheiße wie bei jedem anderen DHCP-Server mit zu kleinem DHCP-Bereich auch. Naja, eine der beiden möglichen Varianten: die Fritzbox zieht es vor, das älteste inaktive (und nicht reservierte) Lease zu löschen und die dadurch frei werdende IP an den neuen Client zu vergeben. Die andere wäre: das inaktive Lease beizubehalten und den neuen Client leer ausgehen zu lassen.
Ich halte das Fritzbox-Verhalten da noch für die bessere Wahl. Aber egal: die einzig richtige Lösung wäre natürlich, ihr genug DHCP-Space für die zu erwartende Zahl von Clients zu geben. Alles andere ist eine Fehlkonfiguration des Volltrottels von Admin, nicht die Schuld der Fritzbox.
Wobei es in einer grossen Familie mit jeweils einem Handy und einem Tab pro Nase schon knapp werden kann. 200 DHCP-Adressen reichen bei einer Lease-Time von 10 Tagen und täglich wechselnder MAC-Adresse für 10 Personen. ;-)
Wobei es in einer grossen Familie mit jeweils einem Handy und einem Tab
pro Nase schon knapp werden kann. 200 DHCP-Adressen reichen bei einer
Lease-Time von 10 Tagen und täglich wechselnder MAC-Adresse für 10
Personen. ;-)
Weshalb man ja in der Fritzbox die Lebenszeit einer IP-Adresse im DHCP-Raum einstellen kann.
Ohne Änderung (nie gemacht) liegt die bei meiner Box bei 10 Tagen. Die des DHCP-Gastraum bei 6 Std.
Wobei es in einer grossen Familie mit jeweils einem Handy und einem Tab
pro Nase schon knapp werden kann. 200 DHCP-Adressen reichen bei einer
Lease-Time von 10 Tagen und täglich wechselnder MAC-Adresse für 10
Personen. ;-)
Die Fritzbox kann nicht nur "Klasse-C"-Netze, sondern auch größere. Ob aber auch der DHCP-Server das kann, da bin ich mir nicht sicher. Habe ich nie probiert. Ich sehe allerdings auch keine prinzipiellen Probleme.
Wenn es zu Problemen, kommt, dann höchstens durch's (dafür möglicherweise nicht geeignete) GUI oder schlicht durch Speichermangel. Die FB hängt an die Leases einen Rattenschwanz von Sekundärinformationen. Da könnte es im Speicher schon mal etwas eng werden.
Wobei es in einer grossen Familie mit jeweils einem Handy und einem Tab
pro Nase schon knapp werden kann. 200 DHCP-Adressen reichen bei einer
Lease-Time von 10 Tagen und täglich wechselnder MAC-Adresse für 10
Personen. ;-)
Danke, wenigstens einer denkt mit. Und nun nehmen wir dein beschriebenes Szenario und stellen mit Erschrecken fest, dass die Fritte nicht das älteste Lease verwirft und wieder neu vergibt, sobald ihr die Range ausgeht, sondern einfach gar keine Leases mehr raushaut. Kommen in diesem Zustand trotzdem noch ordentlich Anfragen, startet sie stumpf neu.
Jetzt gehen wir zurück zum Urspungsproblem des OP: Die Fritte gibt demselben Client (also identische MAC!) trotz langer Leasetime eben nicht wieder dieselbe IP, sondern immer wieder eine neue. Der Pool wird also Ruck-Zuck verbraucht, und dann sind wir wieder oben:
"und stellen mit Erschrecken fest, dass die Fritte nicht das älteste Lease verwirft und wieder neu vergibt, sobald ihr die Range ausgeht, sondern einfach gar keine Leases mehr raushaut."
Der Satz kann missverstanden werden. Vielleicht bedeutet das nur, dass
eine manuelle IP-Konfiguration im Client nicht innerhalb der vom
DHCP-Server verwalteten IP-Range liegen darf. Und es nicht um
reservierte IP/MAC-Zuordnungen seitens des DHCP-Servers geht.
Einfach noch den nächsten Absatz lesen:
"Making a static mapping does not “reserve” that IP out of the pool. The static mapping in this case merely represents a preference for an IP and others are not prevented from taking the IP if it is not in use."
Heisst also, wenn ein Client eine feste IP innerhalb des Pools hat, bekommt er sie nur dann, wenn sie nicht zufälligerweise schon anderweitig vergeben wurde.
Und die pfSense-Leute meinen es auch ernst damit, dass das keine gute Idee ist:
"If assignments absolutely must be made inside the pool, and the risks involved are worth taking and want to do so anyway, the input validation check may be removed from the PHP file that drives the DHCP editor page. The details of this unsupported change are left out as an exercise for the reader."
Wenn man "range" und "pool" unterscheidet, gibt es doch drei getrennte Adressbereiche: 1. den Pool, 2. feste Adressen, die per DHCP vergeben werden und 3. Adressen, die nicht per DHCP vergeben werden. So gesehen sind die Warnungen doch normal und verständlich?
Jetzt gehen wir zurück zum Urspungsproblem des OP: Die Fritte gibt
demselben Client (also identische MAC!) trotz langer Leasetime eben
nicht wieder dieselbe IP, sondern immer wieder eine neue.
Das ist bei mir noch niemals passiert. Ich sorge aber halt auch für einen ausreichend großen DHCP-Bereich, bezogen auf die erwartete Clientzahl.
Jetzt gehen wir zurück zum Urspungsproblem des OP: Die Fritte gibt
demselben Client (also identische MAC!) trotz langer Leasetime eben
nicht wieder dieselbe IP, sondern immer wieder eine neue.
Das ist bei mir noch niemals passiert. Ich sorge aber halt auch für
einen ausreichend großen DHCP-Bereich, bezogen auf die erwartete
Clientzahl.
das dürfte bei mir garkein Problem sein, per Default stehen ca. 180 Adressen zu Verfügung und es gibt nur 2 Telefone und in den letzten Monaten insgesamt 5 oder 6 verschiedene PCs.
So gesehen sind die Warnungen doch normal und verständlich?
Natürlich. Dem hat Hmmm weiter oben jedoch widersprochen, als ich anmerkte, sowas sei kaputt.
Ich bleibe dabei (und so ist es auch best practice): Clientseitig fix eingestellte IPs gehören nicht in die Range des DHCP. Niemals.
Was ich durchaus manchmal mache, um im Falle z.B. eines Werksresets eines Clients nicht suchen zu müssen: Fixe IP außerhalb der Range für den normalen Betrieb und zusätzlich eine dhcp-seitige Reservierung innerhalb der Range.
Beim OP schon, das war Ausgangspunkt dieses Threads.
Ich sorge aber halt auch für
einen ausreichend großen DHCP-Bereich, bezogen auf die erwartete
Clientzahl.
Die Range war beim OP groß genug und in dem von mir geschilderten Fall auch. Problematisch wirds eben durch das kaputte Verhalten der Fritte, am Ende der IPs nicht das älteste Lease zu verwerfen und neu zu vergeben.
Auf die Gefahr hin, mich zu wiederholen: Stellt man die Leasetime in der Fritte auf die kürzeste Zeit, IIRC ein paar Stunden, macht sie es richtig, auch wenn die Zeit noch nicht abgelaufen ist.
Ich bleibe dabei (und so ist es auch best practice): Clientseitig fix
eingestellte IPs gehören nicht in die Range des DHCP. Niemals.
Da stimme ich zu. Aber das hat nix mit der Fritzbox zu schaffen. Die erlaubt es, so einen Client korrekt zu behandeln. D.h.: man kann ihm einen im DNS der FB sichtbaren Namen zuweisen.
Ja, es mag für Idioten verwirrend sein, dass man das im selben GUI tut, der sonst überwiegend für die DHCP-Verwaltung vorgesehen ist. Aber macht nix, das funktioniert schon. So wie es soll und wie es sinnvoll ist.
Ich bleibe dabei (und so ist es auch best practice): Clientseitig fix
eingestellte IPs gehören nicht in die Range des DHCP. Niemals.
In dem Punkt habe ich Dir nicht widersprochen, das ist völlig korrekt. Aber auch serverseitig vergebene feste IPs gehören eigentlich nicht in die Range, aus der dynamisch vergeben wird.
Einige DHCP-Server machen es trotzdem so (z.B. Fritzbox), einige verzeihen es (z.B. dnsmasq, so liest sich zumindest die Man-Page), einige mögen es gar nicht (z.B. ISC).
Aber vielleicht reden wir auch aneinander vorbei, was die Begriffe angeht. Der ISC dhcpd kann prinzipiell sämtliche Adressen aus dem jeweiligen Subnet zuteilen, entweder aus Host-Einträgen (für statische IPs) oder aus Ranges (für dynamische IPs). Es ist auch kein Problem, ein Subnet zu konfigurieren, in dem es ausschliesslich feste Zuteilungen gibt, indem man keine Range konfiguriert. Aber Hosts sollten eben tunlichst ausserhalb von Ranges liegen.
Problematisch wirds eben durch das kaputte Verhalten der Fritte,
am Ende der IPs nicht das älteste Lease zu verwerfen und neu zu
vergeben.
Das ist aber genau, was sie tut. Und eigentlich ist genau das das einzig standardwidrige. Denn lt. Standard hätte der neue Client das Nachsehen, d.h.: er würde keine IP bekommen.
Aber wie schon mehrfach gesagt: das ganze Problem entsteht überhaupt nur, wenn man den DHCP-Bereich zu klein wählt. Es ist allein Sache des Admin, dafür zu sorgen, das er groß genug ist. Leute, die zu doof dazu sind und dann angeblich "buggy"-DHCP-Server der Fritzbox dafür verantwortlich machen, sind einfach nur armselig.
"Making a static mapping does not “reserve” that IP out of the pool. The
static mapping in this case merely represents a preference for an IP and
others are not prevented from taking the IP if it is not in use."
Was ist dann das hier? (ISC DHCP 4.4)
RESERVED LEASES
[...]
If a standard dynamic lease, as from any range statement, is marked ´reserved´, then the server will only allocate this lease to the client it is identified by (be that by client identifier or hardware address).
Aber auch serverseitig vergebene feste IPs gehören eigentlich nicht in
die Range, aus der dynamisch vergeben wird.
Da bin ich ganz bei dir, aber das braucht eben auch die Möglichkeit der Konfiguration. ISC und dnsmasq können es, die Fritte nicht. Da kannst du einem Host außerhalb der Range nur noch einen DNS-namen aufdrücken, mehr nicht.
Aber vielleicht reden wir auch aneinander vorbei, was die Begriffe
angeht.
Bintec findet auch nichts dabei, bei einer dynamisch vergebenen Lease aus dem dynamischen Pool ganz schlicht per Web-GUI den Schalter "Statische Bindung" zu aktivieren, um eine feste und reservierte Bindung herzustellen.
Sieht eher nach einem spezielleren Anwendungsfall aus:
"Leases may be set ´reserved´ either through OMAPI, or through the ´infinite-is-reserved´ configuration option (if this is applicable to your environment and mixture of clients)."
Also wohl nicht per Config nutzbar, sondern nur per API, denn "infinite-is-reserved" ist auch wieder spezieller:
"If this flag is on, the server will automatically reserve leases allocated to clients which requested an infinite (0xffffffff) lease-time."
Von der GUI aus betrachtet ist es sehr elegant. Formale Ästhetik ist allerdings Ansichtssache.
Reservierungen verwende ich routinemässig, nicht nur privat auf dem Bintec. Mitunter auch bei Geräten mit Serverfunktion. Es ist nämlich sehr angenehm, Geräte ohne Konsole problemlos in ein anderes Netz verfrachten zu können. Und bei manchen Clients, um sie anderswo per IP eindeutig identifizieren zu können. Bei Clients stört mich auch nicht, wenn die Adresse im normalen Pool liegt.
Meine FRITZ!Box 7530 vergibt einem Debian bullseye mit isc-dhcp-client
bei jedem Boot eine neue Adresse.
Da fehlte noch die FritzOS-Version: 7.29. Nach einem Update auf 7.50 hat Debian jetzt zum 3. Mal die gleiche Adresse bekommen (die letzte von vor dem Update). So weit so gut.
Dafür kann ich jetzt die Adress-Listen nicht mehr anschauen. Von wegen "mach halt ein Update". Was täte ich, wenn ich Einstellungen ändern müsste, damit ich einen anderen Browser downloaden kann? Vollkommen krank, diese HMI-Designer.
Vielleicht kann deine Version noch kein wirkliches HTML5?!
Das muss sie auch nicht, HTML konnte schon immer alles, was man für so eine Konfiguration braucht. Das sollte eigentlich per telnet oder seriell möglich sein. Oder meinetwegen per w3m. Gerade bei so lebenswichtigen Geräten ;)
Das muss sie auch nicht, HTML konnte schon immer alles, was man für so
eine Konfiguration braucht. Das sollte eigentlich per telnet oder
seriell möglich sein. Oder meinetwegen per w3m. Gerade bei so
lebenswichtigen Geräten ;)
Hatten die damals mit der Kutsche auch gesagt als sie das erste Auto gesehen haben.
