Statische IP wird trotzdem per DHCP vergeben

Wie gesagt, die Funktionsweise von DHCP allgemein ist einfach so, dass eine IP-Adresse einem Client auch dann angeboten wird, wenn diese für eine bestimmte MAC-Adresse reserviert ist.

Eine Reservierung verhindert nicht, dass der DHCP-Server auch einem anderen Client diese IP-Adresse anbietet.

Um das zu erreichen muss die Reservierung außerhalb der DHCP-Range liegen.

Du vertauscht da einfach deine persönlichen logischen Vorstellungen mit der wirklichen Funktionsweise von DHCP.

Das Verhalten ist nicht UTM-spezifisch, sondern ein DHCP-konformes "normales" Verhalten.

DHCP funktioniert wie gesagt nicht so wie es sich viele Leute vorstellen,
es gibt spezielle Situationen, die berücksichtigt werden müssen.

Gruß, Datax

Und diese Aussagen beruhen auf ... was?

@K.N.

Hab' ich mir halt angelesen, konkrete Links kann ich dir dazu nicht nennen und ist teils auch Erfahrung.

Gruß, Datax

@tdthomas

Hast du eigentlich bezüglich der vom DHCP-Server doppelt vergebenen IP-Adressen auch schon mal geprüft, ob alle Clients in deinem Netzwerk auch Echo-Requests ( also Pings ) antworten?

Ein DHCP-Server pingt ja vor der Vergabe eine IP-Adresse erstmal die betreffende IP-Adresse an.

Wenn diese nicht antwortet geht er davon aus, dass diese nicht vergeben ist.

Wenn aber der Client, der diese IP-Adresse bereits hat, einfach nicht auf Pings antwortet, dann geht der DHCP-Server natürlich auch davon aus, dass die betreffende IP-Adresse noch frei ist.

Gruß, Datax

@tdthomas

Wie gesagt, die Funktionsweise von DHCP allgemein ist einfach so,
dass eine IP-Adresse einem Client auch dann angeboten wird,
wenn diese für eine bestimmte MAC-Adresse reserviert ist.

Genau das hattest du vorher nicht gesagt... ;-)
Würde ein Client genau die reservierte IP anfragen und ist der eigentliche Zielrechner nicht erreichbar, wäre das ja halbwegs geklärt mit der ungewollten Vergabe - auch wenn dann eine Reservierung recht unnütz wirkt.

Aber der DHCP-Server der Sophos hat die reservierte IP freiwillig & ungefragt vergeben, obwohl noch genügend andere im DHCP-Pool verfügbar waren und auch rein von der numerischen Reihenfolge her die reservierte IP weit am Ende des DHCP-Adressbereich lag.

Auch eine DHCP-Exclusion wäre für mich in diesem Fall keine Problemlösung - ich habe noch gelernt, dass man eine Exclusion eintragen sollte, wenn man eine statische IP aus dem DHCP-Pool vergeben möchte. Aber eine statische IP war bei meinem Problem ja nie im Spiel.

Im RFC zu DHCP steht zum Thema "manual allocation", also Reservierung einer IP, leider nicht viel.
Es wird aber nicht erwähnt, dass eine manuell zugeordnete IP ausserhalb des DHCP-Adresspool liegen muss:
"In "manual allocation", a client's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client."
[edit]
http://technet.microsoft.com/en-us/library/cc779507%28v=ws.10%29.aspx
"the scope for which you want to create a reservation."
[/edit]
[edit2]
Und aus man dhcpd.conf (http://linux.die.net/man/5/dhcpd.conf) zum Thema "Reserved Leases":
"In practice, this means that the lease follows the normal state engine, enters ACTIVE state when the client is bound to it, expires, or is released, and any events or services that would normally be supplied during these events are processed normally, as with any other dynamic lease. The only difference is that failover servers treat reserved leases as special when they enter the FREE or BACKUP states - each server applies the lease into the state it may allocate from - and the leases are not placed on the queue for allocation to other clients. Instead they may only be 'found' by client identity. The result is that the lease is only offered to the returning client."
[/edit2]

@tdthomas

Hast du eigentlich bezüglich der vom DHCP-Server doppelt vergebenen IP-Adressen auch schon mal geprüft, ob alle Clients in deinem Netzwerk auch Echo-Requests ( also Pings ) antworten?

Habe ich gerade getan. Sowohl der eigentliche Zielrechner als auch das Gerät, was immer noch die (ehemals) reservierte IP innehat, antworten auf Pings.

Die doppelte  Vergabe der IP ist mir also immer noch schleierhaft, denn der eigentliche Zielrechner fordert die reservierte IP ja immer noch per DHCP an. 

Der DHCP-Server hätte also feststellen können, dass die reservierte IP (aus noch ungeklärten/unverständlichen Gründen) bereits vergeben wurde und dem eigentlichen Zielrechner dann eine andere IP zuweisen müssen - oder irre ich mich?
Stattdessen wurde die reservierte IP ein zweites Mal vergeben.

Zur besseren Übersicht mache ich dieses Update in einem neuen Posting.

Direkt aus dem Sophos-UMT-Handbuch im Abschnitt "Add Static Mapping to New Host Definition":
"You can use an existing lease as template for a static MAC/IP mapping with a host to be defined.
[...]
IPv4 address: Change the IP address to an address outside the DHCP pool range."

Das hört sich sehr danach an, als ob bei der Sophos-Konfigurationsweise also tatsächlich statische, fixe IPs erstellt werden, die sich natürlich nicht im DHCP-Adresspool befinden sollten - und es sich also nicht um ein Umwandeln des normalen Lease in ein "reserved lease" handelt.
Deshalb war die Vergabe der "reservierten IP" per DHCP also an das fremde Gerät völlig in Ordnung.

Aber:
1) Wieso kam es zum Adresskonflikt, also der doppelten Vergabe?
- Die IP war per DHCP dem fremden Gerät zugeordnet --> ok
- Die IP war in der Sophos zusätzlich als statische IP eingetragen --> meinetwegen
- Der Zielrechner erbittet per DHCP (!) eine IP und bekommt per DHCP (!) eine bereits vergebene (und dazu noch statische IP) zugeteilt --> nicht ok


2) Wie oder wo bastel ich mir in der UTM denn jetzt meine gewünschte "reserved lease"? 
Ich möchte dem Zielrechner ja KEINE statische IP zuweisen, sondern DHCP mit "manual allocation" bzw. eine "reserved lease" nutzen.
Der Rechner bekommt auf seine DHCP-Anfrage zwar momentan die neue statische IP zugeordnet (oO), aber aus Sicht der Sophos nutze ich doch eine statische IP - was ich vermeiden möchte.

[...] aber aus Sicht der Sophos nutze ich doch eine statische IP - was ich vermeiden möchte.

Warum?
Das ist doch der UTM wurscht, ob die IP z.B. 192.168.0.15 oder 192.168.0.55 ist...
Wenn es dir so wichtig ist, dass das Gerät eine IP aus deinem derzeit definierten DHCP-Pool bekommt, dann verkleinere diesen und vergib dem Gerät eine der dadurch freigewordenen IPs...

Wenn es dir so wichtig ist, dass das Gerät eine IP aus deinem derzeit definierten DHCP-Pool bekommt, dann verkleinere diesen und vergib dem Gerät eine der dadurch freigewordenen IPs...

Mir geht es nicht darum, dass die IP aus dem bisherigen Pool genommen wird, ich hab noch genug freie Adressen.

Ich möchte aus administrativen Gründen den Zielrechner per DHCP mit "reserved lease" versorgen, nicht per statischer IP -> kein Rumgefummel für mich, wenn sich Gateway, DNS oder sonstwas ändern. Für den Anwender gibt es da natürlich keinen Unterschied.

Momentan fragt der Zielrechner per DHCP eine Adresse an und bekommt von der Sophos die statische IP ausserhalb des DHCP-Adresspool zugeteilt - auch, wenn ich manuell den Lease erneuere.
Das kann doch auch nicht richtig sein...

Ich glaub hier gibt's noch ein kleines Verständnis-Problem...

Wenn du den Client auf DHCP stellst und eine Reservierung in der UTM vornimmst, dann zieht sich der Client automatisch alle Einstellungen (DNS, Gateway, etc.) so wie im DHCP-Server eingestellt. Nur bekommt er anstatt einer IP aus dem DHCP-Pool eine außerhalb dieses Bereich zugewiesen. Es ist also nicht nötig, am Client irgendwelche IP-Einstellungen fix vorzunehmen!

Momentan fragt der Zielrechner per DHCP eine Adresse an und bekommt von der Sophos die statische IP ausserhalb des DHCP-Adresspool zugeteilt - auch, wenn ich manuell den Lease erneuere.
Das kann doch auch nicht richtig sein...

Doch, genau so ist es richtig. Denn im DHCP-Server der UTM ist eingestellt: "Wenn das Gerät mit der MAC-Adresse 00:11:aa:bb:22:cc anfragt, dann gib ihm IMMER die IP 192.168.0.55, egal, wie oft es nach einer neuen IP fragt."
So funktionieren DHCP-Reservierungen.

Wenn du den Client auf DHCP stellst und eine Reservierung in der UTM vornimmst...

Was verstehst du denn jetzt unter der "Reservierung", die in der UTM aus einem normalen Lease zu einer "statische Zuordnung" umgewandelt wird? 
Eine statische IP oder ein "reserved lease" bzw. "manual allocation" via DHCP? Das UTM-Handbuch deutet auf eine statische IP hin, da eine IP ausserhalb des Adresspool gefordert wird.

Bei einer statischen IP muss die IP ausserhalb des Adresspool liegen.
Bei einer DHCP-Adressvergabe via "manual allocation" bzw. "reserved lease" darf/soll/muss die IP innerhalb des Adresspool liegen. So steht es im MS Technet und in den Manpages für dhcpd.conf.

So funktionieren DHCP-Reservierungen.

"DHCP-Reservierungen" sind dann aber keine statischen IPs und dürften/sollten im Adresspool liegen. 
Dokumente, die zu DHCP-Reservierungen (also nicht zu statischen IP) eine Adresse ausserhalb des Pool verlangen, habe ich keine gefunden.

Was verstehst du denn jetzt unter der "Reservierung", die in der UTM aus einem normalen Lease zu einer "statische Zuordnung" umgewandelt wird?

Darunter verstehe ich den Button "Make static" in der Lease-Tabelle bzw. das Eintragen der MAC-Adresse/DUID im entsprechenden Host Object.

Generell:

Es spielt keine Rolle, was Technet oder andere Quellen sagen:
Beim DHCP-Server der UTM müssen Reservierungen (d.h. ein Client mit einer bestimmten MAC-Adresse bekommt bei jeder Lease-Anfrage die selbe IP zugewiesen) außerhalb des DHCP Scope liegen. Andernfalls kann es zu doppelter IP-Adress-Vergabe kommen.
So steht's auch in der Online Hilfe der UTM.

Da es anscheinend keine eindeutigen Regeln in den RFCs zu DHCP gibt, ist dieses Verhalten auch völlig OK so.
Blöd ist halt, dass sich dadurch verschiedene DHCP-Server unterschiedlich verhalten...

Dokumente, die zu DHCP-Reservierungen (also nicht zu statischen IP) eine Adresse ausserhalb des Pool verlangen, habe ich keine gefunden.

Aber auch keine, die das für alle DHCP-Server-Implementationen explizit verbieten, oder? [;)]