01.08.2011

8737

Server 2008 R2 - DHCP IP Vergabe für verschiedene Subnetze

Hallo zusammen,

Im Rahmen einer Projektarbeit sollen wir u.a. einen WDS aufsetzen, der für drei Standorte funktioniert.
Die IP Ranges sind:
10.0.8.1 – 10.0.9.254 (/23) (Standort A)
10.0.0.1 – 10.0.7.254 (/21) (Standort B)
10.0.10.1 – 10.0.10.126 (/25) (Standort C)

Die drei o.g. Netze sind geroutet und die Rechner finden sich auch untereinander ohne Probleme .
Der Server (DHCP und WDS) ist ein physikalischer Server mit der IP 10.0.8.3, der dazugehörige DC hat die IP Adresse 10.0.9.254 (intern), und nach draußen 172.0.0.1 über den Gateway-Server 172.0.0.254 [Standort A]

Es soll nun das ganze WDS so laufen, dass jeder zum einen durch den DHCP eine eigene IP in seinem EIGENEN Subnetz erhält; also PCs in Standort A sollen auch nur durch den DHCP IP Adressen erhalten die aus dem Subnetz des selben Standortes stammen (die jeweiligen Ranges sind bereits im DHCP schon konfiguriert, und können vernachlässigt werden).

Für das Subnetz/Standort wo der DHCP und WDS sich selber drinne befinden funktioniert das wunderbar. D.h. Rechner aus Standort A erhalten eine 10.0.8.xxx Adresse vom DHCP für den WDS, ABER kommt nun ein PC von Standort B oder C, erhalten sie ebenfalls IP Adressen für Standort A, was eine schlechte Idee ist ;)

Welche Einstellungen habe ich zu machen/beachten, damit die o.g. Vorgabe erfüllt wird? Kann mir da irgendjemand einen Schubs in die richtige Richtung geben?

Gruß,
Andy

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 170743

Url: https://administrator.de/forum/server-2008-r2-dhcp-ip-vergabe-fuer-verschiedene-subnetze-170743.html

Ausgedruckt am: 24.04.2025 um 09:04 Uhr

29 Kommentare

Neuester Kommentar

Hi,

da im Rahmen einer Projektarbeit mal folgende Stichpunkte:

VLAN
Relay Agent

Was für Hardware wird verwendet? Switche, Router?

Wieso wurden Routen eingerichtet? War das beabsichtigt, dass die sich untereinander finden?

VG

Halli Hallo

VLAN steht NICHT zur Verfügung, kann daher nicht genommen werden,
Relay Agent war auch einer meiner Ideen, aber mir fehlt die Inspiration wie die Konfiguartion sein muss.

Wir verwenden einen Server 2008 R2 PC als reinen Router (das 172er Netz soll das Internet und die große weite Welt darstellen), ein Switch ist ebenfalls vorhhanden, da wir nicht genug Netzwerkkaarten im Router haben

Ja, es war Absicht, dass die sich finden sollen. Die einzelnen Zweigstellen bzw. DCs (ich ergänze noch die Informationen, dass das Ganze unter einem Forest mit 3 Subdomänen läuft) müssen sich ja irgendwie finden. Ergo wurden Routen eingerichtet, damit eine Kommunikation mit dem "wirklichen Internet", sowie untereinander funktioniert.

Wichtig ist, dass es die o.g. Subnetze gibt, die praktisch die drei Standorte trennen sollen.

Hi Albysan,

es gibt eine Einstellung beim DHCP-Server, das man sagen kann, wenn der Router mit einer best. IP eine DHCP-Anfrage weiterleitet zum DHCP-Server, dann bekommt DHCP-CLient nur die IP_Adressen aus einem best. Bereich und keine anderen.
Und wie Xaero1982 schon richtig schreibt: VLAN und Relay-Agent konfigurieren.

Gruss

Holli

VLAN steht nicht zur Verfügung ;)
und mit dem Relay-Agent ist mir im Grunde klar das dieser wichtig ist, da er ja anfragen aus einem anderen Subnetz zum DHCP Server weiterleitet.

Aber ich wüßte zu gerne welche Einstellung das sein soll: eine MAC Reservierung kann es nicht sein, es sei denn ich würde den Router dort eintragen (also die MAC Adresse).

Es ist übrigens nichts wofür es Noten gibt, mache hier meine 70-647 Prüfung und haben als Aufgabe ein kleines Szenario erhalten! ;)

Keine VLANs?

Ok, dann hast du ja sicher in jedem Netz einen Router?

Auf diesem Router bzw. auch auf Switchen steht der Relay Agent zur Verfügung. Da musst du die entsprechende IP (bei Cisco IP-Helper-Address) des DHCP konfigurieren.

Dann läuft der Rest von selbst.... Daher noch mal die Frage: Welche Hardware habt ihr zur Verfügung.

VG

Sämtliche Router, auch innerhalb der einzelnen Domänen, werden durch Win Server 2008 R2 dargestellt/übernommen.
Also läuft hier nix über CISCO Hardware ;)

Der Router PC hat die IP 172.0.0.254, und dann gibt es (so die weitere Voraussetzung) für jede Domäne nochmal einen eigenen Router (alles Server 2008 R2 Maschienen, macht ja auch Sinn, sonst ist eine Kommunikation der Standorte untereinander ggf. etwas Kompliziert)..

Na da gibt es doch den Relay Agent Dienst für den Server.

Den installierst du und da gibst du die IP vom DHCP Server an ...

http://technet.microsoft.com/de-de/library/dd469685.aspx

Natürlich darf dann eine Kommunikation zwischen Clients und Servern der anderen Subnetze nicht gehen. Quasi ja nur "Pseudo-Vlans"

Also muss der DHCP Relay Dienst auf dem Zentralen "Router" installiert werden, der praktisch die "externen" IP-Adressen (nennen wir sie mal 172.0.0.1 - 3, der einzelnen Router der DCs) zusammenführt.

Hallo,

wenn du mir eine Projektarbeit ablieferst in der ein Server in einem LAN die IP Adresse 172.0.0.254 hat, bist du ohne weitere Kontrolle des Rest deiner Arbeit durchgefallen!

RFC 1918

brammer

@brammer: Dein Kommentar ist ziemlich kontraproduktiv, und ich weiß selber was private und öffentliche bzw. nach routbare und nicht routbare IP Adressen sind, da brauche ich keinen der hier von der Antwort abweicht (bin selber FISI).

ob das Ding nun 172.0.0.1 oder 192.168.1.50 oder supercagefragelisticexplidaioducios heißt, ist Jacke wie Hose, die IP Adressen konnten und durften wir frei wählen, da es sich um ein isoliertes Netz nach außen hin handelt, bzw. dieses durch einen weiteren Router im Büro abgetrennt wird.

Es muss aber immer noch jemand geben, der Subnetze mit Taschenrechner, 1en und =en berechnet :D, Junge, es gibt einfachere Wege ;)

außerdem gebe ich nicht bei Dir oder irgendwem anderes was ab, ondern es dient rein zu demonstrativen Zwecken und die IP Adressen sind hier Jacke wie Hose -

Danke für die Aufmerksamkeit

Zitat von @Albysan:

Also muss der DHCP Relay Dienst auf dem Zentralen "Router" installiert werden, der praktisch die "externen"
IP-Adressen (nennen wir sie mal 172.0.0.1 - 3, der einzelnen Router der DCs) zusammenführt.

Der Relay Agent muss auf jedem "Router" im jeweiligen Subnet installiert werden.

Netz x (Relay Agent) - Netz y (DHCP) - Netz z (Relay Agent)

VG
PS: @ Brammers Kommentar und deine Erwiderung: Brammer hat da gar nicht so Unrecht und es ist um so schlimmer, dass ihr euch die IP Adressen selbst aussuchen konntet, aber das soll nicht das Problem sein - das entscheidet dein Lehrer!

Danke Dir, werd ich mal morgen früh versuchen und Dir dann die Ergebnisse mitteilen!

Hallo,

Im Rahmen einer Projektarbeit sollen wir u.a. einen WDS aufsetzen

ondern es dient rein zu demonstrativen Zwecken und die IP Adressen sind hier Jacke wie Hose

Was denn nu?

Eine Projektarbeit oder rein demonstrativ?

Wenn du meinen Kommentar als kontrproduktiv ansiehst ist das deine Sache, nur rege dich nicht auf wenn die Arbeit den Bach runtergeht.
Ich arbeite, unter anderem, selber als Dozent und Trainer für Netzwerk Themen, und lege aus Erfahrung Wert darauf, das bei den Grundlagen genau gearbeitet wird.
Wenn du anderer Meinung bist, dein Bier.

Was dir allerdings passieren kann das die public IP von deinem Server 2008 R2 PC den ihr als Router missbraucht von einem Router

einen weiteren Router im Büro

redistributed wird und ihr auf einmal Effekte habt die ihr euch nicht erklären könnt
Nur mal so als Erinnerung, vor etwa 2 Jahren hat die Pakistanische Regierung entschieden Youtube in Pakistan zu sperren, der Provider hat es umgesetzt und Stunden SPäter war Youtube weltweit nichtoder kaum erreichbar.
Hier wurden Route bzw. Autonoem Systeme falsch redistributed.
Es habe schon ein paar Amerikanishce Studenten für ein Testaufbau geschafft die IP Adressen der NSA zu benutzen, die liegen dummer weise direkt neben einem RFC 1918 Bereich und bieten sich daher an, die Herren von der NSA waren nicht davon begeistert und die Studenten durften einige Tage lang dem FBI erklären das sie nur "ausversehen" einen Angriff auf ein Netz das für die nationale Sicherheit benutzt wird ausgelöst haben.

Ansonsten dürfte dir das hier evtl auch weiterhelfen.
Oder das hier
Oder das hier

brammer

Jeder Dozent hat eigene Arten zu unterrichten, und in diesem Falle sind die IPs ausnahmsweise nicht zu beachten ;)

Es wurde schon alles in die Wege geleitet, dass ich hier nix beißt was die IP Adressen betrifft, also kann dieser Aspekt ausgeklammert werden

Es ist durchwegs eine Mischung aus beiden: demonstrative Projektarbeit , ich könnte ggf. die Rahmenbedingungen mal hier hinein posten.

Nur es gibt immer noch Menschen, die alles zu penibel sehen ;) (Ich will Dich da nicht in eine Schublade stecken, sorry wenn es so klang. Aber wenn Du jemanden Fragst, was eine virtuelle Maschiene ist, erzählen die Dir ellenlange Stories über verschiedene Virtualisierungsebenen etc. Die Antwort hingegen ist jedoch einfach: es ist eine Datei) *g*

Ich poste mal die Bedingungen morgen früh

Alby,

du verstehst da was nicht und ich stimme Brammer da vollkommen zu:

Wenn ich so ein Projekt auf die Beine stellen muss, dann fängt man bei dem kleinsten an. Dazu gehören nun mal die Grundlagen wie korrekte IP-Adressen und Subnetzmasken.
Das wird auch dein Dozent nicht anders sehen, oder er hat einfach keinen blassen Schimmer.
Wenn man sich schon Dinge von vornherein falsch anlernt, wird es erheblich schwerer diese Fehler wieder zu beheben.

VG

Die Frage die sich meinem Dozenten gestellt hat: Warum soll es mit diesen IP Adressen nicht funktionieren?

Es funktioniert!

Unser Dozent hat sicherlich mehr Erfahrung als manch anderer hier (aber ist auch kein fehlerfreier Mensch, wie ich immer weider erkenne)

Und es funktioniert mit den IP Adressen, warum sollten wir nun etwas ändern? Solange es keine Argumente gibt, die deutlich dafür sprechen, dass wir andere IP Adressen nutzen sollen (natürlich würden wir das nachher im Produktivsystem mit anderen IPs machen), lassen wir es so wie es ist.

Darüber hinaus ist unser Netzwerk derzeit nach außen isoliert.

Zitat von @Albysan:

Die Frage die sich meinem Dozenten gestellt hat: Warum soll es mit diesen IP Adressen nicht funktionieren?

Es funktioniert!

Unser Dozent hat sicherlich mehr Erfahrung als manch anderer hier (aber ist auch kein fehlerfreier Mensch, wie ich immer weider
erkenne)

Und es funktioniert mit den IP Adressen, warum sollten wir nun etwas ändern? Solange es keine Argumente gibt, die deutlich
dafür sprechen, dass wir andere IP Adressen nutzen sollen (natürlich würden wir das nachher im Produktivsystem mit
anderen IPs machen), lassen wir es so wie es ist.

Dann, so leid es mir tut, ist dieser Dozent auch nur einer von vielen Pseudo-ITlern, die es mit Richtlinien in der IT nicht so ernst nimmt ... Ich bezeichne solche Leute gerne als "Hobby-ITler".

Aber hey was solls, ohne die hätten die richtigen ITler viel weniger Arbeit und daher: Danke!

Zurück zum Thema - gehts mit den Relay Agents?

VG

Ganz einfach: Wenn Du es so lernst, wirst Du es später im Erntfall auch so machen und Dir wird nicht auffallen, daß es falsch ist, weil "es funktioniert ja."

Auch ich bin (externer) Dozent an Dualen Hochschulen und bei mir würde das mindestens Punktabzug geben, wenn nicht schlimmeres.

lks

Im realen Umfeld würde ich es persönlich anders machen, ich habe ja anfangs auch gefragt warum gerade dieses Netz, aber die Antwort ist einfach: Warum nicht? Es klappt auch damit. Also sprach (anscheinend) nix dagegen, und wenn es Probleme gibt, so lernt man daraus.

Das man/frau nun hier so einen Reihbach um die IP Adressen macht hätte ich nicht gedacht, ich hatte eine Frage gestellt und nicht mit Antworten gerechnet, die hier alles und jeden Kritisieren, und um ehrlich zu sein, hat bislang leider keine der o.g. Antworten zum Erfolg geführt, die Clients im anderen Standort bekommen immer noch IPs vom falschen Subnetz zugewiesen *seufz*

Ich habe mich dem Schicksal schon ergeben, und arbeite gerade an der Zeichnung - egal ob es Punktabzug in der A oder B Note gibt.
Mag noch etwas dauern, bis ich fertig bin, da ich nebenher noch einiges hier koordiniere.

...to be continued!

Zitat von @Albysan:

Bei Deiner Projektarbeit wird es vermutlich keine Probleme mit den IP-Adressen geben (außer dem DHCP

). Aber meine Erfahrung zeigt, wenn man sich von Anfang an nicht an bestimmte Regeln gewöhnt, holt einen das im späteren Leben wieder ein, nach dem Motto:

"Wir haben die Kofiguration 4 Wochen bei uns getestet und sie lief einwandfrei aber seit wir sie heute morgen dem Kunden ausgeliefert haben, läuft gar nichts mehr."

Das man/frau nun hier so einen Reihbach um die IP Adressen macht hätte ich nicht gedacht, ich hatte eine Frage gestellt und
nicht mit Antworten gerechnet, die hier alles und jeden Kritisieren, und um ehrlich zu sein, hat bislang leider keine der o.g.

Du solltest nicht damit hadern. Die Kritik war durchaus konstruktiv.

Antworten zum Erfolg geführt, die Clients im anderen Standort bekommen immer noch IPs vom falschen Subnetz zugewiesen
*seufz*

Nun, nicht immer können hier die Admins hellsehen, um zu wissen, was da bei Dir gerade falschläuft. Hast Du mal mit wireshark geschaut, ob die DHCP-requests vom DHCP-proxy korrekt verarbeitet werden? Wer antwortet auf die requests? Wenn die Clients immer noch die falschen Adressen bekommen, ist entweder der proxy falsch konfiguriert oder die requests werden über layer 2 an der Server geswitcht, statt über den proxy zu laufen.

So nun die große Auflösung - zum Erstaunen aller:

zu allerallerallererst: Es hatte ABSOLUT nix mit IP Adressen zu tun, die hätten auch sonst wie sein können q.e.d

Das Problem war, dass mein Kollege hinten mir verschwiegen hat, dass er unfreiwillig sämtliche Router umgangen hat in dem er einen Switch so geschaltet hat, dass dieser dafür gesorgt hat, dass alles am Router vorbeigeht statt durch den ROuter geleitet wird. Das Ergebnis: Keiner der Router konnte so natürlich mittels DHCP Relay Agent eine korrekte Anfrage setzen, weil das gesamte Netz nicht getrennt ist. Der einzige Router, der derzeit tatsächlich genutzt wird ist der , der dafür sorgt, dass wir eine Kommunikation mit dem Provider haben.

Lange Rede, kurzer Sinn: Die Lösung, die ich zu Anfang selbst erarbeitet habe (DHCP-Relay-Agent) und wo ich mir unsicher war, hätte tatsächlich geklappt, wenn man mir o.g. Kleinigkeit mitgeteilt hätte.

Wie dem auch sei: Danke für die Hilfe und Denkanstöße ;)

Hi,

dann kannst du uns hier aber nicht sagen, dass keine der oben genannten Tipps, insbesondere der von mir via Relay-Agent, nicht funktionieren. Denn es lag ja nun an der Inkompetenz eurer Gruppe und nicht an uns.

Zum Thema IP-Adressen: Wir haben auch NIE gesagt, dass es mit denen nicht funktioniert! Wir sagten einfach, dass es falsch ist und das sind zwei Sachen. Wenn man bereits die Grundlagen falsch umsetzt, dann möchte man idR auch nicht korrekt arbeiten

Inkonti..ehm inkompetent ist hier keiner ;) es lag an der mangelnden Kommunikation innerhalb der Gruppe (wir sind da ja auch nur Anfänger und lernen)

Aber um auf dem Boden der Tatsachen zu bleiben: der DHCP Relay Agent Tip, hatte ich schon vorher umgesetzt, konnte aber wegen des Switch Problemes nicht effizient funktionieren ;)

Das es DHCP Relaying gibt und dass es funktioniert war mit auch ekannt, habe bis lang schon ein paar MS Zertifikate (auch welche die sich um Zertifikate selber drehen *kotz*), es gab halt nur das Problem des Switches ;)

Zitat von @Albysan:

Inkonti..ehm inkompetent ist hier keiner ;) es lag an der mangelnden Kommunikation innerhalb der Gruppe (wir sind da ja auch nur
Anfänger und lernen)

Aber um auf dem Boden der Tatsachen zu bleiben: der DHCP Relay Agent Tip, hatte ich schon vorher umgesetzt, konnte aber wegen des
Switch Problemes nicht effizient funktionieren ;)

Das es DHCP Relaying gibt und dass es funktioniert war mit auch ekannt, habe bis lang schon ein paar MS Zertifikate (auch welche
die sich um Zertifikate selber drehen *kotz*), es gab halt nur das Problem des Switches ;)

Zitat:

Zitat von @Albysan:

Relay Agent war auch einer meiner Ideen, aber mir fehlt die Inspiration wie die Konfiguartion sein muss.

Vielleicht gibst du in Zukunft korrekte Informationen und erzählst nicht erst das und dann dies.

Mit Zertifikaten kann man sich den ... abwischen, denn in der Praxis siehts doch immer wieder so aus, dass die Leute keinen Schimmer haben. Gilt natürlich nicht generell, aber viel zu oft

kwT

VG

Hallo,

dann trainiert eure Kommunikation.

Und, ein einfacher Trace auf die Router hätte gezeigt das die Pakete vollkommen falsch laufen.
Soviel zum deiner Ausssage

da es sich um ein isoliertes Netz nach außen hin handelt, bzw. dieses durch einen weiteren Router im Büro abgetrennt wird.

Wenn schon bei der Verkabelung solche Fallstricke warten und die Vorgaben nicht richtig umgesetzt werden, dann solltest du überprüfen ob nicht noch irgendwo eine Kabel falsch liegt...
Oder die IP Adressierung auf Vordermann bringen.

brammer

Zitat von @Albysan:

... dass er unfreiwillig sämtliche Router umgangen hat in dem er
einen Switch so geschaltet hat, dass dieser dafür gesorgt hat, dass alles am Router vorbeigeht statt durch den ROuter
geleitet wird.

Ich glaube, ich muß mal meiner Kristallkugel ein paar besondere Streicheleinheiten geben.

lks

PS: Wie hier schon öfte rgesagt wurde: Ihr soltlet Euch sorgfältiges Arbeiten (und ggf. Dokumentieren) angewöhnen. Hilft ungemein, wenn man später echte Projekte durchführt. Un ddas mit den IP-Adressen ist auch nicht bös gemeint. Wenn Ihr durch Eure Verkableung Euer und druch geschickte IP-Adressenwahl Firmennetz lhmgelegt hättet, war das auch nicht gut gewesen. Deswegen die ganzen Hinweise auf die Ip-Adressenwahl.

Ich nehme es ja auch nicht persönlich, aber es gab bislang keine Antwort auf meine Frage: Warum andere IP-Adressen (aus dem privaten, nicht routbaren Bereich)? Es funktioniert, und dass es nun nicht an den IP Adressen lag, ist ja nu bewiesen worden :o)

Es ist hier auch alles ordentlich dokumentiert, aber jemand hinten, der das ganze Routing macht, ist etwas still, und da scheint das ganze unter zu gehen - haben wir aber auch schon geöndert (um mal dem Herrn bremm oder bramm hier den Wind aus den Segeln zu nehmen: Wir haben es auch mit anderen IP-Adressen versucht und es hat NIX geändert, GAR NIX, also lass die dusseligen IP Adressen endlich außen vor!)
Wie gesagt, ob die Dinger nun 10.0.8.1, 192.168.1.40 oder sonstwie heißen ist hier sowas von egal gewesen: Fakt ist, dass der Switch hier das Chaos verursacht hat.

Nun funktioniert ja auch alles wie es soll, bis halt auf meine andere offene Frage, aber das ist eine andere Baustelle!

Zitat von @Albysan:

Doch sie wurde mehrmals beantwortet: Solange Du dein Netz sauber von anderen trennst, ist das unkritisch udn funktioniert auch. Aber sobald, und sei es nur aus Versehen wie z.B. bei euch per switch, dieses Testnetz "entfleucht", kannst Du Probleme bekomen, insbesondere bei größeren Firmennetzen, ganz zu schweigen, wenn Du mal bei einem Provider tätig sein solltest.

Daher ist es eine gute Idee, sich die Netze auch unter diesem Aspekt zu wählen, weil dann irgendwann das in "Fleisch und Blut" übergeht und Du dann automatisch eine Fehlerquelle weniger hast.

Nachtrag: ein weiteres Beispiel

dann muss ich ergänzen:

Der Switch hier war innerhalb des eigenen Netzwerkes, das Netz ist IMMER noch sauber nach Außen hin durch einen Router getrennt, dieser Router nach draußen wurde nicht übergangen, sondern lediglich der, der innerhalb der "Firmenstruktur" die einzelnen Netzwerke miteinander verbindet/trennt

[Firmen Netz A] ---- [Router A] [Firmen Netz B] ---- [Router B] [Firmen Netz C] ---- [Router C]

[Router für externes Netz] === [FritzBox] <--> Internet

[Router A,B und C sind an dem Router für das extern. Netz angeschlossen - SOLLZUSTAND]

So sollte es sein bei uns, nur dass hier durch Hardware (die wir nicht ändern dürfen) die DCs bzw. der einzelnen Firmennetzwerke zusätzlich alle an ein und dem selben Switch angeschlossen sind!!!! - ISTZUSTAND

Das ist das Problem gewesen!

gelöstFrage Microsoft Windows Server

Mehr von Albysan

Server 2008 R2 - Failover Druckercluster mit PDFCreatorAlbysan

Heiß diskutiert