UDM-SE Wie richtig statische IP-Adressen konfigurieren

Wenn die statischen Adressen der Devices außerhalb des Pools des DHCP-Servers liegen, brauchen sie m.E. nicht mehr in der SE eingestellt werden.

Vielleicht werden die Devices mitunter als offline angezeigt, weil sie sich die feste IP eben nicht von der SE holen.

Den fremden Switch hätte ich aber als Ursache auch im Verdacht. Bevor ich alle Komponenten auf unifi gewechselt hatte, wurden mir manchmal auch seltsame Werte angezeigt, insbesondere bei der Topologie.

Zitat von hippeland

Vielleicht werden die Devices mitunter als offline angezeigt, weil sie sich die feste IP eben nicht von der SE holen

Das wird eher das Problem sein.

Ich würde generell drauf verzichten, die IP fest am Gerät einzutragen sondern das ausschliesslich per DHCP-Reservation zu machen und dort auch die statischen IP nicht aus dem Bereich des DHCP-Pool zu nehmen, sondern ausserhalb davon, z.b.
.11 - .128 DHCP Reservation
.129 - .250 DHCP dynamisch
( .1 - .11 dann für Netzwerkgeräte fest )

Das Problem ist glaub ich der Unterschied zwischen statischen und festen IP-Adressen.

Von einer statischen (oder manuellen) IP spricht man, wenn man dem Gerät selbst (und eben nicht im Controller!) sagt, welche IP es verwenden soll. Das nimmt dann auf Gedeih und Verderb eben diese Adressen und fragt erst gar nicht beim DHCP nach. Deshalb muss man händisch dafür Sorge tragen, dass man keine IP doppelt vergibt und dass die manuell vergebenen IPs in einem Bereich liegen, der vom DHCP nicht verwendet wird.

Eine feste IP ist dagegen "nur" eine besondere Konfiguration des DHCP im Controller, dieser wird angewiesen, einem anfragenden Gerät stets die gleiche IP zuzuweisen.

Wenn ich deine Beschreibung richtig verstehe gelaf16 , hast du jetzt beides gemacht: Sowohl eine manuelle IP vergeben, als auch den DHCP angewiesen, diesem Gerät (das aber nie nachfragen wird, weil es ja bereits eine IP hat) diese IP zuzuweisen. Das macht zwar erstmal nichts kaputt, ist aber langfristig gesehen eine potentielle Fehlerquelle.

Zitat von noexpand

Das Problem ist glaub ich der Unterschied zwischen statischen und festen IP-Adressen.

Für mich ist das das selbe - ne feste IP ist immer statisch, weil die nun mal nicht ändert.

Die statische / feste IP kann sowohl am Geräte selber eingetragen werden ( mit allen anderen notwendigen Daten wie Gateway, DNS., NTP-server, Netzmaske ) - das ist in großen Netzwerk aber eher ein ziemlich schlechte Idee, weil ein große Fehlerquelle und das Verwalten der IP-Netz massiv erschwert.

Alternativ kann der DHCP-Server eine feste IP-Adresse einem Geräte zuweisen - dann spricht man eben von DHCP-Reservation, also ich reserviere einem Client immer die selbe IP-Adressen und diese wieder niemals an andere Geräte im Netz vergeben, auch nicht wenn der Client nicht mehr existiert, da ist es eben eine DHCP-Leiche.
In der Regel basiert die Vergaben auf der MAC-Adresse der Netzwerkkarte.

Der Client schickt nen DHCP-Request, der DCHP-Server sieht die MAC-Adresse, schaut in seine Liste - sieht, oh "Tom-MacBook mit der MAC blalbla bekommt immer die IP 10.0.100.20" und schickt ihm diese zur Nutzung inkl. aller anderen Daten ( Gateway, Netzmaske, DNS, NTP usw. )

Unterschied ist dann eben "Dynamisch IP-Adresse"

Dabei vergibt der DHCP-Server jedem anfragenden Client, der keine Reservation hat, eine IP-Adresse aus dem konfigurierten DHCP-Pool.
Und wenn der Client am nächsten Tag wieder kommt, bekommt er wieder ne IP aus dem Pool, kann die selbe sein oder ne anderen.

Wenn der Pool jetzt 100 IP's hat und 100 Client sind online, alles gut, kommt Client 101 an, guckt der in die Röhre.
Selbst wenn Clients offline gehen, bleibt die IP denen noch zugewiesen bis die Leasetime abläuft, normalerweise sagt mal im Firmennetzen 8h oder 12h, so das am nächsten Arbeitsat die DHCP-Pools wieder leer sind, in privaten Netzen sind 24h ein guter Werte.
Daher DHCP-Pools immer größer machen als die max. Anzahl gleichzeitig aktiver Clients - +50% immer ne guter Wert.

Das Problem bei festen im Client konfigurierten IP-Adressen ist, das der DHCP-Server die nicht sieht und somit nicht kennt - liegen deren IP's im DHCP-Pool drin, ist das ganz schlecht, das kann und wird zu doppelten IPs im Netz führen und das macht sehr interessante Fehlerbilder.

Nächste Problem ist dann auch, das eine Namensauflösung der lokalen Hostnamen bei feste vergeben IPs im Client meist nicht funktioniert, weil der interne DNS-Server nicht am DHCP nachfragen kann, wenn man z.b. wie ich einen Unbound auf der Firewall nutzt. Der holt sich nämlich die lokalen IP-Adressen vom DHCP-Server und löst damit interne Hostname auf.

Daher mein Rat immer wieder:
- konfiguriert keine IP-Adresse fest in Clients, einzige Ausnahme, wo das in Ordnung, sind Netzwerkgeräte wie Switch, APs, Router (sowieso wg. Gateway ) usw.

- bei Server kann man sich drüber streiten, wir machen es in der Firma nicht, sondern nutzen auch DHCP-Reservation.
- alles anderen wenn Clients statische IP's bekomme sollen, macht es per DHCP-Reservation, das macht das Leben sehr viel leichter.
Dabei einen Teil des IP-Bereich für DHCP-Reservation nutzen und den anderen Teil für dynamische und die ersten 10 Adressen für Netzwerkgeräte ( oder mehr wenn notwendig )

Es gibt zwar Router - Unifi gehört meines Wissen auch dazu, die haben keine Probleme damit, DHCP-Reservations aus dem DHCP-Pool zu nehmen, aber es gibt einige Hersteller von Firewalls, die raten da dringend von ab, dies zu machen, weil es Probleme machen kann.
Es macht die Sache am Ende auch übersichtlicher.

Zitat von Tomcat

Für mich ist das das selbe - ne feste IP ist immer statisch, weil die nun mal nicht ändert.

Die statische / feste IP kann sowohl am Geräte selber eingetragen werden ( mit allen anderen notwendigen Daten wie Gateway, DNS., NTP-server, Netzmaske ) - das ist in großen Netzwerk aber eher ein ziemlich schlechte Idee, weil ein große Fehlerquelle und das Verwalten der IP-Netz massiv erschwert.

Alternativ kann der DHCP-Server eine feste IP-Adresse einem Geräte zuweisen - dann spricht man eben von DHCP-Reservation, also ich reserviere einem Client immer die selbe IP-Adressen und diese wieder niemals an andere Geräte im Netz vergeben, auch nicht wenn der Client nicht mehr existiert, da ist es eben eine DHCP-Leiche.

Dies ist nicht dasselbe.

Wenn du einer Netzwerkschnittstelle sagst, sie soll DHCP machen, hast du nur bedingte Eingriffsmöglichkeiten über den DHCP-Server. Und gerade bei Servern ist es umständlich.

Wenn du der Schnittstelle die Informationen manuell gibts, kannst du z.B. dieser auch mehrere IP-Adressen aus verschiedene Netzwerksegmenten geben.

So habe ich im PC eine 2 Netzwerkschnittstelle mit IP-Adressen aus allen VLANs gegeben, somit habe ich direkten Zugriff in diesen Netzen. Aber auch andere Bereiche wie 192.168.178.x, die sonst gar nicht im Heimnetz existiert, um einfach mal Fritz!Boxen neu einzurichten.

Außerdem würde ich bei wichtigen Geräten (Server, NAS, Telefon, Dienste) diesen immer die IP im Gerät konfigurieren. Somit weiß ich auch diese anzusprechen, wenn z.B. der Router/DHCP-Server nicht zur Verfügung steht.

Gerade bei Unifi ist es schwierig den Überblick zu behalten, welche Geräte eine vorgegebene IP-Adresse haben, wenn diese Offline sind.

Zitat von Tomcat

Es gibt zwar Router - Unifi gehört meines Wissen auch dazu, die haben keine Probleme damit, DHCP-Reservations aus dem DHCP-Pool zu nehmen, aber es gibt einige Hersteller von Firewalls, die raten da dringend von ab, dies zu machen, weil es Probleme machen kann.
Es macht die Sache am Ende auch übersichtlicher.

Interessante Aussagen werden hier so gemacht...

Übrigens hat DHCP erstmal gar nichts mit Router zu tun ... Und Hersteller die über ihre eigenen Firewalls solche Aussagen treffen, sollten evtl. mal ihre Produkte in Ordnung bringen.Eine Reservierte IP wird nur an die dazugehörige MAC verteilt und ansonsten gar nicht. Es kann also nur ein Problem entstehen wenn der DHCP Server in besagten Firewalls nicht korrekt arbeitet.

Wo die Sache jetzt übersichtlicher ist wenn man einen Bereich für echte statische IPs hat, dazu dann einen DHCP Pool ohne Reservierungen und dann dazu noch einen Bereich der eigentlich nicht im DHCP Pool liegt (somit eigentlich in Geräten statisch konfiguriert werden könnte) aber dann doch per DHCP an explizit festgelegte Geräte verteilt wird? Letzten Endes kann man alles machen, da hilft dann oft eine geeignete Dokumentation.

Ach ja, es gibt hier kein richtig und kein falsch. Einfach der Situation anpassen. Da gibt es z.B. auch so Dinge wie Lizenzierung ... Ich werfe mal das Stichwort Microsoft Server Device CALs in die Runde. Da ist es ggf. kostentechnisch bei einem Audit ungünstig, wenn man dutzende Geräte wie Telefone per DHCP von Windows Server konfiguriert.

Zitat von phino

So habe ich im PC eine 2 Netzwerkschnittstelle mit IP-Adressen aus allen VLANs gegeben, somit habe ich direkten Zugriff in diesen Netzen.

Ich hab einen virtuellen Server, der hat in jedem VLAN eine Netzwerkkarte und alle per DHCP-Reservation.

Tomcat dann Drücke ich Dir die Daumen, dass dein DHCP Server nicht mal verreckt.

Zitat von Tomcat

Ich hab einen virtuellen Server, der hat in jedem VLAN eine Netzwerkkarte und alle per DHCP-Reservation.

Welches System ist es den. Nach meinem Kenntnisstand wird so etwas bei VM so realisiert, dass es für jedes VLAN eine virtuelle Karte in der Maschine gibt die DHCP macht, was natürlich dann über eine physikalische herausgehen kann.
Da mir im der häuslichen Umgebung die Ressourcen fehlen, um es sicher zu betreiben sind VM/Docker bei mir nur zum Spielen, Dienste laufen bei mir auf Blech.

DHCP auf eine Netzwerkschnittstelle bedeute ja, sie fährt hoch und schaut, welcher DHCP-Server ihr welche Informationen liefert. Und die UDM & Co. sagen dann eine IP bekommst du für dieses Netz, an dessen Port/Vlan du hängst. Der DHCP-Server vergibt an dieselbe MAC-Adresse aber keine weiteren IP-Adressen aus anderen VLANs, er und der Client wissen doch gar nicht was gut für die Situation ist, dies geht nur manuell und dann geht aber kein DHCP.

Ihr redet beide von Unterschiedlichen Dingen

So wie phino mache ich das auch oft mal zum Konfigurieren von irgendwelchen Gerätschaften, die default nur eine bestimmte IP haben. Dann kann ich die gleich umändern in den entsprechenden Bereich der genutzt werden soll, dann über die neue IP den Rest konfigurieren und dann das nächste Gerät und REPEAT. Dann brauche ich auch nicht permanent die IP meines Notebooks hin und her stellen. Und ein DHCP würde da auch nicht helfen

Zitat von DoPe

Tomcat dann Drücke ich Dir die Daumen, dass dein DHCP Server nicht mal verreckt.

Ich nutze ja kein Unifi

Zudem was soll dann passieren - die Clients funktionieren weiter und wenn der wirklich ausfällt, ist eh das Internet weg und der DHCP das absolut unwichtigste Problem.

Muss nur im richtigen Moment ausfallen. Dann hat dein Server im Zweifel auch keine IP mehr

Aber schussendlich muss das Ganze einfach nur laufen, egal ob statisch, dynamisch oder irgendwas semifestes

Zitat von DoPe

Muss nur im richtigen Moment ausfallen. Dann hat dein Server im Zweifel auch keine IP mehr

Ja und, wenn DHCP ausfällt ich vermuttlich meine Firewall ausgestiegen und da interessiert mich der Server in dem Moment nicht im geringsten.

Moin und die Nachfrage von mir als absoluten Anfänger:

Zitat von Tomcat

Ich würde generell drauf verzichten, die IP fest am Gerät einzutragen sondern das ausschliesslich per DHCP-Reservation zu machen und dort auch die statischen IP nicht aus dem Bereich des DHCP-Pool zu nehmen, sondern ausserhalb davon, z.b.
.11 - .128 DHCP Reservation
.129 - .250 DHCP dynamisch
( .1 - .11 dann für Netzwerkgeräte fest )

DHCP Bereich/ Pool wird unter "Einstellung/ Netzwerk" von bis definiert? (in dem Beispiel also .11 - .128) womit der Bereich dahinter (in dem Beispiel also .129 - .250) also den dynamischen/ verwendbaren Bereich darstellt?

Auf das Beispiel bezogen sollten dann die einzelnen Unifi Geräte statische IPs von .1 -.11 bekommen, bzw. .2 - .11, da die .1 ja den Gateway/ UDM-SE abbildet.

Die erforderlichen Eintragungen zu den DNS-Servern sollten, müssen oder dürfen den Eintragungen des primären und/ oder sekundären DNS-Servers entsprechen, die man unter "Einstellungen/Internet/Primary" (WAN1) macht?

Ich habe dort 1.1.1.1 und 1.0.0.1 eingetragen und trage dasselbe bei der Einrichtung von statischen IP-Adressen für die Unifi-Geräte mit den IPs .2 - .11 ein. Gateway und Subnet entsprechen ebenfalls der UDM-SE.

Sehe und mache ich das alles so richtig?

Bei den DNS IP würde ich eher zu 1.1.1.1 und 8.8.8.8 tendieren. Damit hast du zwei verschiedene Anbieter am Start.

Ansonsten ist natürlich zu überlegen wofür dein Default Netz steht. Bei mir sind da alles nur Geräte drin die irgendeine Art von Dienst anbieten. Und die haben bei mir alle eine feste IP im Gerät. Mein DHCP Range in diesem Netz umfasst nur 16 IP Adresse.

Du siehst es gibt da viele Lösungen.

Zitat von phino

Bei den DNS IP würde ich eher zu 1.1.1.1 und 8.8.8.8 tendieren. Damit hast du zwei verschiedene Anbieter am Start.

Da ist etwas dran...werde ich mal umsetzen!

Zitat von phino

Ansonsten ist natürlich zu überlegen wofür dein Default Netz steht. Bei mir sind da alles nur Geräte drin die irgendeine Art von Dienst anbieten. Und die haben bei mir alle eine feste IP im Gerät. Mein DHCP Range in diesem Netz umfasst nur 16 IP Adresse.

Welche Art Dienst meinst du?

Feste IP im Gerät heißt bei dir, dass du z.B. in deinem Telefon die IP einträgst, die es sich ziehen soll und nicht über den Unifi-Controller, der dem Gerät dann die IP zuweist, oder verstehe ich dich da falsch?

Bei mir sind es UDM SE, alle APs, LTE Modem, 2x HUE-Bridge, Homematic CCU3, 2x NAS, Fritz!Box, Wallbox, Wechselrichter/PV, VoIP GSM Gateway, 4x Strom-Leistungsmesser, USV, Laserdrucker/Scanner, Kühlschrank, Waschmaschine, Herd, Dunstabzug,

Die sind bei mir in verschiedene VLAN.

Aber für mich sinnvoll ist es allen im Netzwerkverkehr notwendigen Komponenten feste IPs zu geben. Den anderen kann man natürlich auch die IPs per DHCP fix zuzuweisen.

Der Vorteil der festen IPs ist, das man sich die gut merken kann und damit schnell die Webseiten ansprechen kann. Natürlich ist auch noch gut möglich in der UDM den Geräten Namen zu geben wie nas.rilke.lan oder HUE-Out.rilke.lan.