7
DHCP Superscope
Hallo,
ich habe bei uns in einem Außenbüro einen DHCP Superscope erstellt mit 2 verschiedenen Netzen (192.168.x.x und 10.150.x.x). Zum Test habe ich den Adress-Pool für eine IP-Adresse gesetzt. Solange ich keine Reservierung setze, wird die eine IP auch nicht vergeben. Setze ich eine Reservierung, funktioniert es. Deaktiviere ich eine Scope, funktioniert es auch ohne Reservierung.
Hat jemand eine Idee?
OS Windows Server 2012R2
Gruß
Peter
ich habe bei uns in einem Außenbüro einen DHCP Superscope erstellt mit 2 verschiedenen Netzen (192.168.x.x und 10.150.x.x). Zum Test habe ich den Adress-Pool für eine IP-Adresse gesetzt. Solange ich keine Reservierung setze, wird die eine IP auch nicht vergeben. Setze ich eine Reservierung, funktioniert es. Deaktiviere ich eine Scope, funktioniert es auch ohne Reservierung.
Hat jemand eine Idee?
OS Windows Server 2012R2
Gruß
Peter
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 417068
Url: https://administrator.de/contentid/417068
Printed on: April 27, 2024 at 05:04 o'clock
7 Comments
Latest comment
Was für einen Unsinn willst du denn damit treiben? Da hast du das Prinzip vom DCHP nicht verstanden. Soll allen Ernstes ein Endgerät zufällig mal eine 10.150.x.x und dann vielleicht später eine 192.168.x.x Addresse kriegen? Also nee, ist kein Wunder daß das dann nur ncoh über eine MAC-basierende manuelle Zuweisung geht. Da sich 10.150 und 192.168 mit keiner Netzmaske außer 212.190.0.0 überlappen würden,... 11001010.10111110
Netzmasken wie diese sind schon mal was um seinen eigenen Job zu sichern, oder um den Nachfolger in den Wahnsinn zu treiben. Ich erinnere mich mal an so ein Rechenbeispiel aus einer Grundlagenschulung so 35 Jahre früher als TCP-IP V4 so langsam mal anfing, das IPX SPX von Novell zu verdrängen.
1 Scope ist ok, 2 Scopes im selben Netzsegment aber vollkommen unterschiedlichen IP-Bereichen sind böse, das ist ein Wunder daß der MS DHCP SErver das überhaupt zuläßt. Vermutlich nur deshalb weil man vielleicht zwei Scopes erzeugen will die innerhalb DERSELBEN Netzmaske liegen. Weil man vielleicht nur einen Teil der in einem Class B möglichen Addressen auch tatsächlcih per DHCP vergeben möchte.
Aber eigentlich ist das totaler Unsinn. Das ist ganz so als ob ein Client per Zufall 2 DHCP Server erreichen könnte... da ist Chaos garantiert. Denk mal dran daß beide IP Ranges ja auch routbar sein müssen, bei einer /16 Netzmaske geh ich mal davon aus daß es eine größere Anzahl von Endgeräten geben wird.
Normalerweise sorgt man dafür daß über einen physischen Verbreitungsweg auch nur ein einziger DHCP Server erreicht wird... z.B. einen im WLan Hotspot und einen fürs LAN. Und man sorgt normalerweise mit einer Firewall dafür daß der DHCP Broadcast in einem Netzsegment isoliert wird.
Netzmasken wie diese sind schon mal was um seinen eigenen Job zu sichern, oder um den Nachfolger in den Wahnsinn zu treiben. Ich erinnere mich mal an so ein Rechenbeispiel aus einer Grundlagenschulung so 35 Jahre früher als TCP-IP V4 so langsam mal anfing, das IPX SPX von Novell zu verdrängen.
1 Scope ist ok, 2 Scopes im selben Netzsegment aber vollkommen unterschiedlichen IP-Bereichen sind böse, das ist ein Wunder daß der MS DHCP SErver das überhaupt zuläßt. Vermutlich nur deshalb weil man vielleicht zwei Scopes erzeugen will die innerhalb DERSELBEN Netzmaske liegen. Weil man vielleicht nur einen Teil der in einem Class B möglichen Addressen auch tatsächlcih per DHCP vergeben möchte.
Aber eigentlich ist das totaler Unsinn. Das ist ganz so als ob ein Client per Zufall 2 DHCP Server erreichen könnte... da ist Chaos garantiert. Denk mal dran daß beide IP Ranges ja auch routbar sein müssen, bei einer /16 Netzmaske geh ich mal davon aus daß es eine größere Anzahl von Endgeräten geben wird.
Normalerweise sorgt man dafür daß über einen physischen Verbreitungsweg auch nur ein einziger DHCP Server erreicht wird... z.B. einen im WLan Hotspot und einen fürs LAN. Und man sorgt normalerweise mit einer Firewall dafür daß der DHCP Broadcast in einem Netzsegment isoliert wird.
Ein SuperScope ist dafür da, um IP-Adressen unabhängig von dem Subnetz bzw. bestimmten Relayagent-Informationen zu verteilen. Das wird dafür benutzt, wenn man die sehr unschöne Variante laufen hat, in der in einer Broadcast-Domäne zwei verschiedene IP-Subnetze verwendet werden. Damit erhält der Client immer unabhängig davon, über welches Subnetz die DHCP-Anfrage hereinkommt, immer die Zuweisung auf dem Subnetz, in dem der Client zuletzt eine Zuweisung hatte, solange diese noch gültig ist.
SuperScopes dienen NICHT als Ordner, um sich die DHCP-Bereiche schön anzeigen zu lassen.
SuperScope auflösen und laufen lassen!
SuperScopes dienen NICHT als Ordner, um sich die DHCP-Bereiche schön anzeigen zu lassen.
SuperScope auflösen und laufen lassen!
Moin,
Dem kann ich nur zustimmen (aufgrund eigener "schmerzlicher" Erfahrungen).
Vergiss die Superscopes.
Wir wollten es auch der übersichtlichkeit wegen einsetzen, stellten aber irgendwann fest, dass wenn ein Client das VLAN (und damit das Subnetz) wechselt, erhält er trotzdem eine IP aus dem alten Subnetz. Warum? Die MAC/ Reservierung der MAC ist ja in dem Superscope noch enthalten und daher hat der Client die selbe, aber nicht zum Subnetzpassende IP erhalten.
Schaue dir das hier einmal an:
https://www.tecchannel.de/a/netzwerkpraxis-dhcp-server-in-windows-server ...
https://msdn.microsoft.com/en-us/library/dd891486.aspx
Mein Fazit:
Eine wirklich sinnvolle Verwendung von Scopes ist mir nicht eingefallen...
Gruß
em-pie
Zitat von @tikayevent:
Ein SuperScope ist dafür da, um IP-Adressen unabhängig von dem Subnetz bzw. bestimmten Relayagent-Informationen zu verteilen. Das wird dafür benutzt, wenn man die sehr unschöne Variante laufen hat, in der in einer Broadcast-Domäne zwei verschiedene IP-Subnetze verwendet werden. Damit erhält der Client immer unabhängig davon, über welches Subnetz die DHCP-Anfrage hereinkommt, immer die Zuweisung auf dem Subnetz, in dem der Client zuletzt eine Zuweisung hatte, solange diese noch gültig ist.
SuperScopes dienen NICHT als Ordner, um sich die DHCP-Bereiche schön anzeigen zu lassen.
SuperScope auflösen und laufen lassen!
Ein SuperScope ist dafür da, um IP-Adressen unabhängig von dem Subnetz bzw. bestimmten Relayagent-Informationen zu verteilen. Das wird dafür benutzt, wenn man die sehr unschöne Variante laufen hat, in der in einer Broadcast-Domäne zwei verschiedene IP-Subnetze verwendet werden. Damit erhält der Client immer unabhängig davon, über welches Subnetz die DHCP-Anfrage hereinkommt, immer die Zuweisung auf dem Subnetz, in dem der Client zuletzt eine Zuweisung hatte, solange diese noch gültig ist.
SuperScopes dienen NICHT als Ordner, um sich die DHCP-Bereiche schön anzeigen zu lassen.
SuperScope auflösen und laufen lassen!
Dem kann ich nur zustimmen (aufgrund eigener "schmerzlicher" Erfahrungen).
Vergiss die Superscopes.
Wir wollten es auch der übersichtlichkeit wegen einsetzen, stellten aber irgendwann fest, dass wenn ein Client das VLAN (und damit das Subnetz) wechselt, erhält er trotzdem eine IP aus dem alten Subnetz. Warum? Die MAC/ Reservierung der MAC ist ja in dem Superscope noch enthalten und daher hat der Client die selbe, aber nicht zum Subnetzpassende IP erhalten.
Schaue dir das hier einmal an:
https://www.tecchannel.de/a/netzwerkpraxis-dhcp-server-in-windows-server ...
https://msdn.microsoft.com/en-us/library/dd891486.aspx
Mein Fazit:
Eine wirklich sinnvolle Verwendung von Scopes ist mir nicht eingefallen...
Gruß
em-pie
Zitat von @GrueneSosseMitSpeck:
Was für einen Unsinn willst du denn damit treiben? Da hast du das Prinzip vom DCHP nicht verstanden. Soll allen Ernstes ein Endgerät zufällig mal eine 10.150.x.x und dann vielleicht später eine 192.168.x.x Addresse kriegen? Also nee, ist kein Wunder daß das dann nur ncoh über eine MAC-basierende manuelle Zuweisung geht. Da sich 10.150 und 192.168 mit keiner Netzmaske außer 212.190.0.0 überlappen würden,... 11001010.10111110
Netzmasken wie diese sind schon mal was um seinen eigenen Job zu sichern, oder um den Nachfolger in den Wahnsinn zu treiben. Ich erinnere mich mal an so ein Rechenbeispiel aus einer Grundlagenschulung so 35 Jahre früher als TCP-IP V4 so langsam mal anfing, das IPX SPX von Novell zu verdrängen.
1 Scope ist ok, 2 Scopes im selben Netzsegment aber vollkommen unterschiedlichen IP-Bereichen sind böse, das ist ein Wunder daß der MS DHCP SErver das überhaupt zuläßt. Vermutlich nur deshalb weil man vielleicht zwei Scopes erzeugen will die innerhalb DERSELBEN Netzmaske liegen. Weil man vielleicht nur einen Teil der in einem Class B möglichen Addressen auch tatsächlcih per DHCP vergeben möchte.
Aber eigentlich ist das totaler Unsinn. Das ist ganz so als ob ein Client per Zufall 2 DHCP Server erreichen könnte... da ist Chaos garantiert. Denk mal dran daß beide IP Ranges ja auch routbar sein müssen, bei einer /16 Netzmaske geh ich mal davon aus daß es eine größere Anzahl von Endgeräten geben wird.
Normalerweise sorgt man dafür daß über einen physischen Verbreitungsweg auch nur ein einziger DHCP Server erreicht wird... z.B. einen im WLan Hotspot und einen fürs LAN. Und man sorgt normalerweise mit einer Firewall dafür daß der DHCP Broadcast in einem Netzsegment isoliert wird.
Was für einen Unsinn willst du denn damit treiben? Da hast du das Prinzip vom DCHP nicht verstanden. Soll allen Ernstes ein Endgerät zufällig mal eine 10.150.x.x und dann vielleicht später eine 192.168.x.x Addresse kriegen? Also nee, ist kein Wunder daß das dann nur ncoh über eine MAC-basierende manuelle Zuweisung geht. Da sich 10.150 und 192.168 mit keiner Netzmaske außer 212.190.0.0 überlappen würden,... 11001010.10111110
Netzmasken wie diese sind schon mal was um seinen eigenen Job zu sichern, oder um den Nachfolger in den Wahnsinn zu treiben. Ich erinnere mich mal an so ein Rechenbeispiel aus einer Grundlagenschulung so 35 Jahre früher als TCP-IP V4 so langsam mal anfing, das IPX SPX von Novell zu verdrängen.
1 Scope ist ok, 2 Scopes im selben Netzsegment aber vollkommen unterschiedlichen IP-Bereichen sind böse, das ist ein Wunder daß der MS DHCP SErver das überhaupt zuläßt. Vermutlich nur deshalb weil man vielleicht zwei Scopes erzeugen will die innerhalb DERSELBEN Netzmaske liegen. Weil man vielleicht nur einen Teil der in einem Class B möglichen Addressen auch tatsächlcih per DHCP vergeben möchte.
Aber eigentlich ist das totaler Unsinn. Das ist ganz so als ob ein Client per Zufall 2 DHCP Server erreichen könnte... da ist Chaos garantiert. Denk mal dran daß beide IP Ranges ja auch routbar sein müssen, bei einer /16 Netzmaske geh ich mal davon aus daß es eine größere Anzahl von Endgeräten geben wird.
Normalerweise sorgt man dafür daß über einen physischen Verbreitungsweg auch nur ein einziger DHCP Server erreicht wird... z.B. einen im WLan Hotspot und einen fürs LAN. Und man sorgt normalerweise mit einer Firewall dafür daß der DHCP Broadcast in einem Netzsegment isoliert wird.
Das Problem ist, dass der 192.168.x.x/24 Bereich voll ist. Parallel haben wir einen 10.150.x.x/22 erstellt, der auch geroutet wird. Jetzt will ich die Clients langsam von einem Netz ins andere ziehen. Dafür habe ich DHCP-Policies (Vendor Class und MAC basiert) erstellt. Leider ist das den Clients egal. Dass die Clients ohne Policy oder Reservierung sich das richtige Netz nehmen sollen, ist eigentlich einleuchtend.
Nur warum die Policy nicht funktioniert, leuchtet mir nicht ein. Die Policy habe ich von einem anderen Büro kopiert, wo wir die gleichen EInstellungen haben. Eine Policy mit definierter MAC-Adresse hat auch nicht funktioniert.
Dann erstelle ein 192.168.y.x/ 24er Bereich
Beschäftigt euch mit VLANs und lasst mehrere 10.150.x.0/ 24er Netze parellel, aber in verschiedenen VLANs laufen.
Das ist die deutlich sauberere Variante, da so nicht nur die IP-Netze getrennt sind, sondern auch die L2-Domain, also alles, was sich auf MAC-Adress-Ebene abspielt. das ist dann so, als würdest du z.B. das Netz 192.168.x.x/0 über Switch 1 verkabeln und das 10.150.x.0/ 24er Netz über Switch zwei, ohne dass beide Switche direkt miteinander verbunden sind.
Denn somit kannst du z.B. Server und Clients trennen. Mit deinem jetzigen Konstrukt, kann ein Client auf Layer2-Ebene immer noch mit den Server sprechen, selbst wenn du in einer Firewall eine Regel hast, die es untersagt, dass das 192.168.x.y-Netz mit 10.150.x.y/22-Sprechen darf. Warum? weil beide Endgeräte immernoch in der selben Braodcastdomain "hocken"!
Lies dich mal am besten durch @aqui s hervorragenden Thread durch:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Parallel haben wir einen 10.150.x.x/22 erstellt, der auch geroutet wird.
Keine gute Idee, ein /22er Netz zu verwenden.Beschäftigt euch mit VLANs und lasst mehrere 10.150.x.0/ 24er Netze parellel, aber in verschiedenen VLANs laufen.
Das ist die deutlich sauberere Variante, da so nicht nur die IP-Netze getrennt sind, sondern auch die L2-Domain, also alles, was sich auf MAC-Adress-Ebene abspielt. das ist dann so, als würdest du z.B. das Netz 192.168.x.x/0 über Switch 1 verkabeln und das 10.150.x.0/ 24er Netz über Switch zwei, ohne dass beide Switche direkt miteinander verbunden sind.
Denn somit kannst du z.B. Server und Clients trennen. Mit deinem jetzigen Konstrukt, kann ein Client auf Layer2-Ebene immer noch mit den Server sprechen, selbst wenn du in einer Firewall eine Regel hast, die es untersagt, dass das 192.168.x.y-Netz mit 10.150.x.y/22-Sprechen darf. Warum? weil beide Endgeräte immernoch in der selben Braodcastdomain "hocken"!
Lies dich mal am besten durch @aqui s hervorragenden Thread durch:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Vlan's sind bei uns "noch" nicht gewünscht. Bitte nicht diskutieren warum.
Ob Superscope oder einzelne Scopes, das Verhalten ist das gleiche. Anbei ein Bild der Situation. Ich hatte gehofft, dass ich durch Policies die verschiedenen Geräte in verschiedene Ranges bekommen kann. In anderen Büros funktioniert dies.
Ob Superscope oder einzelne Scopes, das Verhalten ist das gleiche. Anbei ein Bild der Situation. Ich hatte gehofft, dass ich durch Policies die verschiedenen Geräte in verschiedene Ranges bekommen kann. In anderen Büros funktioniert dies.
Nachdem ich den DHCP-Server in die neue Range genommen habe, funktioniert alles. bin mal auf das nächste Büro gespannt.
Danke für eure Hilfe
Danke für eure Hilfe