Fixe IP-Adresse (Client-seitig, nicht per DHCP-MAC-Bindung festgelegt) innerhalb des DHCP-Ranges - de facto ein Problem oder nicht?

  • Thread starter Thread starter jmar83
  • Start date Start date
J

jmar83

Guest
Hallo zusammen

Persönliche Meinung: NEIN!! Obwohl es (zumindest gemäss meinem aktuellen Wissensstand) in der DHCP-Server-RFC nicht zwingend vorgeschrieben ist, sind heute PRAKTISCH ALLE DHCP-Server (egal ob nun Windows Server, Linux Server oder NAT-Router) in der Lage dies abzufangen und vergeben die IPs, welche Client-Seitig "festgenagelt" wurden, kein zweites Mal - was dann natürlich dazu führen würde, dass 2 IP-Geräte im entsprechenden Subnetz die selben IPs hätten...

Habe seit 2-3 Jahren immer wieder die selbe Diskussion mit allen möglichen Leuten in meinem Umfeld... nun dachte ich, mal Klarheit zu schaffen und hier nachzufragen. Ich denke, wenn das jemand weiss, dann die Leute hier. :)

UND KLAR, es ist (rein organisatorisch betrachtet), eher "unsauber" innert einem DHCP-Range Geräte mit Client-seitiger fixer IP einzubinden - keine Frage. Aber daher ist dies meines Erachtens eher ein organisatorisches denn ein [wirkliches] technisches Problem...

Wie sieht ihr das? Vielen vielen Dank für die Feedbacks!! :)
 
Das ist ein Problem und wird es auch immer bleiben. Meist erkennen die DHCP-Server, dass die IP schon von einem anderen Gerät in Gebrauch ist, aber zuverlässig funktioniert das nicht. Das Gerät mit der festen IP muss ja nur gerade in dem Moment mal nicht erreichbar sein, wenn der DHCP-Server diese IP vergeben will (ausgeschaltet, Neustart, defekt, etc.). Die dynamischen IP-Bereiche verwaltet der DHCP-Server, davon ist keine IP auf einem Gerät statisch zu konfigurieren - der DHCP-Server bestimmt als einziger, wer die IPs verwenden darf. Entweder man reserviert sich in einem Subnet genug IPs, die man statisch vergeben kann oder man konfiguriert für eine IP eine Reservierung im DHCP-Server, damit dieser die nicht mehr an andere Geräte vergibt (danach kann die IP auch fest auf dem Gerät konfiguriert sein).
Ein zuverlässiges Netzwerk setzt Disziplin voraus, also muss man technisch wie organisatorisch sauber arbeiten. Und nein, ich sehe keinen Grund, warum man eine statisch IP nicht aus dem statischen Pool verwendet (bevorzugte Methode) oder im DHCP-Server eine Reservierung für eine IP aus dem dynamischen Bereich einträgt.
 
Also alles andere als ideal... Vielen Dank für dein kompetentes Feedback!!
 
Imho ist die feste Reservierung einer IP im DHCP Server die sauberste und beste Variante, denn nur so hat die RZseitige DHCP Verwaltung wirklich zentrale Kontrolle über die IP Vergabe. So kenne ich das in unserem riesigen Netzwerk, hier sind statische Vergaben schlicht inakzeptabel.
Ein weiterer Punkt der hierfür spricht: es gibt, je nach Netzwerk, auch verschiedene Netzwerksegmente, die per VLAN voneinander getrennt sind. Hier ist das so konfiguriert, dass stationäre Geräte nur in ihrem eigenen VLAN eine (dann immer feste, private) IP Adresse bekommen. Bei mobilen Geräten ist das in ihrem "Heimat"VLAN genauso (feste, private IP), in anderen VLANs roamen sie dann und bekommen aus einem dynamischen Pool für dieses VLAN eine wechselnde IP zugewiesen. Sowas wäre mit fix eingetragener IP Adresse unmöglich.

In großen Netzwerken: AUSSCHLIESSLICH DHCP Vergabe von IP Adressen. Im kleinen Heim- oder SoHo Netz kann man das anders machen (z.B. DHCP Range von 192.168.0.20 bis 200 und darüber und darunter dann fixe IPs für Server. Aber mit einem vernünftigen DHCP Server ist das auch für solche Umgebungen absolut nicht nötig.
 
Ja, für alles was geht, sollte man die Verwaltung dem DHCP-Server überlassen und dort ggfl. durch Reservierungen "DHCP-statische IPs" vergeben. Es gibt aber einige Szenarien, in denen man die IP unabhängig von der Verfügbarkeit eines DHCP-Servers eingestellt haben will/muss - dann sollten diese aus einem Pool kommen, der nicht vom DHCP-Server verwendet wird.
Aber um noch mal auf die Kernfrage des TE zurückzukommen: Der DHCP-Server bekommt vom Admin vorgegeben, wie er IPs vergeben soll, z.B. von 20 bis 200. Wenn ich jetzt die 42 auf einem Gerät unbedingt manuell einstellen will, muss ich dem DHCP-Server sagen: Die 42 darfst du aber nicht an andere verteilen, die verwendet der Server dahinten (Reservierung).
 
Hm. Das einzige Szenario für feste, manuelle IPs, das mir einfallen will, ist ein kleines Labornetz, das als Insel, ohne jeden Uplink und DHCP Server betrieben wird und in dem sich zwei oder mehr Rechner gegenseitig finden müssen. Z.B. ein Speichergerät und ein Gerät das die Daten produziert. Da hat man aber auch kein Problem mit dem DHCP.
Alles andere sollte m.E. durch den DHCP erledigt werden, denn dann ist man flexibel. Bei Deinem Beispiel gibts eigentlich keinen Grund, wieso nicht das 42er Gerät seine reservierte IP vom DHCP bekommen sollte.

Daher sollte die richtige Antwort auf die o.g. Frage lauten:
- Erste Prio beim Bedarf an fixen IPs sollte die Reservierung der IP im DHCP Server haben.
- Falls unbedingt eine fixe IP vergeben werden soll, ist diese aus einem Bereich zu wählen, der nicht von einem DHCP Server vergeben wird.
Punkt.

Alles andere, also insbesondere die Verwendung von fixen IPs in einem DHCP Bereich KANN funktionieren.... ODER Probleme verursachen. In einem großen Business- / Hochschulnetz wird man bei der unabgestimmten Verwendung von fixen IPs gejagt und beseitigt. ;)
 
Danke für die Feedbacks! :-)

Das einzige, was wohl client-seitig gesetzte IPs rechtfertigt ist dass ein DHCP-Server ausfallen kann. Dabei bleibt es aber. Persönlich verwende ich auch lieber DHCP-MAC-Bindungen...
 
Das sollte man mit dem Disaster-Recovery-Szenario planen.

Wenn man ein Netz "von Null" an wieder hochfahren muß (die Flut hat gezeigt, daß das nicht ganz so extrem unwahrscheinlich ist) sollten neben Gateways, Routern und wichtigen Servern (DNS, DHCP, Radius, NPS) auch deren Management-IPs (z.B. iLO der Server) fixiert sein bevor der DHCP-Server wieder oben bzw. seine Config restauriert ist.
Wir handhaben es so, daß wichtige Server statische IPs haben, aber trotzdem mit dieser in der DHCP-Datenbank stehen.

Client-Netzwerke ähnlich Thunderbyte (PC bekommt beim Kommissionieren eine definierte IP zugeteilt, diese wird aber trotzdem per DHCP bezogen). In vielen Umgebungen kann man den PC über seine MAC gleich ins richtige VLAN schieben, bevor dann 802.1x greift.
Es gibt sicherheitshalber kleine Pools von "freien" DHCP-Adressen, die dort gefangenen Clients landen aber erst mal in Quarantäne.
 
jmar83 said:
Das einzige, was wohl client-seitig gesetzte IPs rechtfertigt ist dass ein DHCP-Server ausfallen kann. Dabei bleibt es aber. Persönlich verwende ich auch lieber DHCP-MAC-Bindungen...
Click to expand...
Naja, in einem professionellen und großen Netzwerk ist das keine wahrscheinliche Sache. Denn natürlich zählt der DHCP Server zur kritischsten Infrastruktur, die man haben kann und wird i.d.R. entsprechend abgesichert sein. Selbst bei kleineren Installationen gibt es semiprofessionelle, zentral gemanagte Netzwerke (z.B. Unifi), die zumindest ein Backup der Konfig (und damit auch der DHCP Reservierungen) macht.

Wenn der DHCP Server down ist, dann brennt normalerweise die Hütte lichterloh und man hat ganz andere Probleme...
 
You must log in or register to reply here.
Back
Top