DHCP Bezug VM

[Gast Blub666]

Hallo zusammen,

ich komme gerade aus irgendeinem Grund nicht weiter... vielleicht hat einer von euch eine Idee.

Ich habe einen VM Windows 2008 r2 Server (statische IP: z.B. 10.33.31.3 ) aufgesetzt mit dem DHCP Dienst. Das Ganze mit der Domäne abgeglichen. Soweit alles gut. Einen Adressbereich von 10.66.66.1 - 10.66.66.100 /24 vergeben.

Jetzt habe ich einen VM Windows 7 Rechner aufgesetzt und möchte mit diesem Rechner eine IP Adresse aus dem oberen Bereich bekommen.

Beide sind im gleichen VM Netzwerk, sodass keine Switche o. Ä. dazwischen hängt.

Firewall ist bei beidem aus. Der IP Bezug funktioniert aber nicht... wenn ich den Windows 7 Rechner manuell die IP 10.33.31.4 vergebe kann ich auch den DHCP Server anpingen. (10.33.31.3)

Wo ist mein Denkfehler? :confused:

[flashpixx]

Schau Dir bitte einmal die Subnetzmasken der von der IANA definierten Adressbereiche an Private IP-Adresse

[Crash2001]

Also wenn ich das richtig sehe, könnte es ein fehlender IP Helper sein.

@flashpixx:

Also ist dein Tipp der gleiche wie meiner - verstehe ich dich da richtig? Da es Subnetzübergreifend ist.

[flashpixx]

Wenn Du eh nur 24iger Netz hast, warum nimmst Du dann das 10er, das wäre 8er Netz. DHCP ist immer beschränkt auf das Subnetz, d.h. ein Switch macht keinen Unterschied.

[Gast Blub666]

Sorry Jungs,

eure Tipps bringen mich momentan nicht weiter. Was genau meint Ihr?

Der PC sucht doch per Broadcast einen DHCP-Server, sprich: Er müsste somit auch den DHCP finden, oder nicht? (Beide sind ja im selben VM Netzwerk)

[Eye-Q]

Was meine Vorredner damit sagen wollen: wenn der Server die IP-Adresse 10.33.31.3 mit der Subnetzmaske 255.255.255.0 (24er-Subnetz) hat, kann der nie und nimmer einen DHCP-Bereich von 10.66.66.x vergeben, weil das einfach nicht im selben Subnetz liegt.

Der DHCP-Dienst muss IP-Adressen aus dem selben Subnetz vergeben, also z.B. von 10.33.31.100 bis 10.33.31.200.

[Crash2001]

Oder aber es muss ein entsprechendes Gateway existieren, das den Broadcast an den DHCP-Server weiterreicht und die Antworten wieder an den Client zurücksendet. Dann wird der Multicast vom Gateway jeweils in einen Unicast umgewandelt und der DHCP-Request funktioniert auch wieder.

Dafür benötigt man sogenannte IP Helper oder DHCP Relay Agents.

[Gast Blub666]

Hallo und danke.

Habe jetzt den DHCP mit 10.33.33.3 / 24 (statisch) und ein Scope im Bereich von 10.33.33.0 - 10.33.33.254 /24 , wobei 10.33.33.0 - 10.33.33.5 nicht vergeben werden.

Jetzt habe ich noch ein paar Sachen, die ich nicht ganz verstehe.

1) Unseren DHCP Server, der z. B. die IP 10.20.20.3 hat, vergibt unter anderem Adressen im Bereich 10.20.30.x ... und das wohl ohne irgendwelchen Helper... wie kann man das realisieren?

2) Anhand welcher Info entscheidet der DHCP welchen Scope er vergeben soll?

[DerMarcus]

1) Unseren DHCP Server, der z. B. die IP 10.20.20.3 hat, vergibt unter anderem Adressen im Bereich 10.20.30.x ... und das wohl ohne irgendwelchen Helper... wie kann man das realisieren?

Wie ist denn die IP-Konfiguration in dessen Netz?

Prinzipiell könnte er im Netz 10.20.16.0 mit einer /20er Maske sein. Das beinhaltet die IP-Adressen von 10.20.16.0 bis 10.20.31.255.

Dann wären die Adressen 10.20.20.3 und 10.20.30.x auch im selben IP-Adressbereich.

2) Anhand welcher Info entscheidet der DHCP welchen Scope er vergeben soll?

Ich würde mal stark sagen, dass das davon abhängig ist, was du konfigurierst. Du hast doch geschrieben, dass du bei deinem DHCP auch einen Scope eingerichtet hast. Genau da holt er das her.

[Eye-Q]

1) Unseren DHCP Server, der z. B. die IP 10.20.20.3 hat, vergibt unter anderem Adressen im Bereich 10.20.30.x ... und das wohl ohne irgendwelchen Helper... wie kann man das realisieren?

Hat der auch ein 24er-Subnetz, vielleicht doch ein 16er (255.255.0.0) oder irgendwas dazwischen?

2) Anhand welcher Info entscheidet der DHCP welchen Scope er vergeben soll?

Der DHCP-Dienst läuft ja auf einem Gerät, welches schon eine IP-Adresse und Subnetzmaske besitzt. Anhand dieser beiden Informationen, die das Subnetz bestimmen, mit dem der Server kommunizieren kann, muss der DHCP-Bereich konfiguriert werden. Die Clients, die sich eine IP-Adresse von dem Server beziehen, müssen im Nachhinein wieder mit ihm kommunizieren können, um z.B. bei einem Neustart nachzufragen, ob die IP-Adresse, die sie erhalten haben, immer noch gültig ist oder ob sie eine neue IP-Adresse erhalten.

[Gast Blub666]

Hat der auch ein 24er-Subnetz, vielleicht doch ein 16er (255.255.0.0) oder irgendwas dazwischen?

Nein, da wir VLAN benutzen kann es nur ein 24er-Netz sein. Sonst würde da nichts laufen... Habe es aber auch schon nachgeguckt.

2) Anhand welcher Info entscheidet der DHCP welchen Scope er vergeben soll?

Die Frage hat sich erledigt. Wird scheinbar durch Vendor ID's realisiert.

[Crash2001]

Was bitte hat die Verwendung von vlans mit der Netzgrösse zu tun bzw. wieso bedingt die Nutzung von vlans die Nutzung von /24 Netzen? :confused:

Davon abgesehen hat die Verwendung von vlans rein technisch noch nicht einmal etwas damit zu tun, welche Netze man benutzt.

Meist wird zwar für jedes vlan ein separates Subnetz genutzt - zwingend ist dies jedoch nicht.

Man kann genauso auch verschiedene Subnetze in einem vlan nutzen oder aber ein Subnetz auf mehreren vlans. Man muss halt nur die entsprechenden L3-Interface haben, falls es kein reines L2-vlan ist.

[Gast Blub666]

Was bitte hat die Verwendung von vlans mit der Netzgrösse zu tun bzw. wieso bedingt die Nutzung von vlans die Nutzung von /24 Netzen? :confused:

Davon abgesehen hat die Verwendung von vlans rein technisch noch nicht einmal etwas damit zu tun, welche Netze man benutzt.

Meist wird zwar für jedes vlan ein separates Subnetz genutzt - zwingend ist dies jedoch nicht.

Man kann genauso auch verschiedene Subnetze in einem vlan nutzen oder aber ein Subnetz auf mehreren vlans. Man muss halt nur die entsprechenden L3-Interface haben, falls es kein reines L2-vlan ist.

Okay, das Problem bzw. die Funktion habe ich jetzt raus...

Nun habe ich eine weitere Frage...

kann man die DHCP-Datenbank auf ein gemappted Laufwerk legen bzw. es von dort aus beziehen? - Ich bekomme dabei immer eine Fehlermeldung.

Mache ich was falsch, oder kann man den Pfad der DHCP-Datenbank nicht auf ein gemapptes Laufwerk legen?

Gruß

[Crash2001]

Fragen wir mal so: Wieso willst du das so machen?

In meinen Augen macht es auf den ersten Blick nicht wirklich Sinn. Vielleicht hast du aber ja ein Szenario, bei dem es Sinn machen könnte.

Du stellst meiner Ansicht nach die Fragen falsch, bzw. hälst viel zu viele Informationen zurück. Zu solch einer Frage gehört z.B. auch der Grund, wieso man so etwas überhaupt probieren sollte. In meinen Augen gibt es eigentlich keinen Grund dafür, denn soooooooo megagross wird die Datenbank wohl vermutlich eher nicht werden, solange es nicht ewig lange Leasezeiten sind o.ä..

Vielleicht gibt es aber auch ganz andere und vielleicht viel effektivere Lösungen für dein Problem. Die können wir dir aber natürlich nur mitteilen, wenn wir wissen, was du eigentlich machen willst.

Vielleicht sind es auch einfach nur so Kleinigkeiten wie Laufwerksbuchstaben statt Netzwerkpfad angeben oder SAN Speicher nutzen oder oder oder ...

[Gast Blub666]

Okay, sorry.

Also es geht darum alle DHCP-Datenbanken in eine DB zu packen, mit allen Scopes und so weiter. Anschließend soll diese DB zentral gespeichert werden. Auf diese DB sollen mehrer Server zeitgleich zugreifen (Muss ich noch testen, ob es geht) ... da ich von "zentraler Speicherung" spreche, müssen die Server den Pfad dazu haben.

Jetzt habe ich eine TestDB auf einem zentralen Server gespeichert und probiere darauf zu kommen. Also mappe ich das Laufwerk auf dem DHCP Server 1 und DHCP Server 2. Lese und Schreibrechte habe ich auf dem Server. Sobald ich nun den Pfad zur DB bei der DHCP-Rolle ändern möchte, kommt ein Fehler.

Nun frage ich mich: Geht es nicht, da es ein gemapptes Laufwerk ist ODER wo ist mein Fehler?

Gruß und Danke

[Crash2001]

[...]Sobald ich nun den Pfad zur DB bei der DHCP-Rolle ändern möchte, kommt ein Fehler.[...]

Was für ein Fehler kommt denn? :confused:

Oftmals enthält die Fehlermeldung ja schon Hinweise darauf, was nicht funktioniert bzw. nicht unterstützt wird.

Soweit ich weiß, können zwei Windows DHCP-Server (zumindest bis 2008 - was danach ist keine Ahnung) nicht gemeinsam die gleiche Datenbank nutzen, sondern man kann sie höchstens replizieren und dann auf dem zweiten Server importieren. Das kann auch automatisiert werden, denn er macht ja standardmässig afaik eh jede Stunde eine Sicherung.

Was versuchst du denn damit zu bezwecken, dass sich mehrere Server eine Datenbank teilen sollen?

[Gast Blub666]

Fehlermeldung ist in dem Falle "Access is denied" - Stimmt aber nicht, da ich manuell auf dem Laufwerk lesen/schreiben kann. (getestet)

Ich denke die Fehlermeldung kommt, da es ein gemapptes Laufwerk ist... dies ist dann wahrscheinlich nicht möglich.

Ich möchte gerne unterschiedliche Standorte und Server auf eine zentrale DHCP-Datenbank zugreifen (lesen/schreiben) lassen... die wohl einzige Möglichkeit die mir da so einfällt ist eine SAN-Anbindung.

Gibt es da vielleicht andere Wege...?

[Crash2001]

"Access denied" kann nicht nur aufgrund von Berechtigungsproblemen sein, sondern eventuell auch, wenn eine Datei bereits geöffnet und in Benutzung ist und sie daher nicht noch einmal geöffnet werden kann. Heisst ja nur "Zugriff verweigert".

Wie schon geschrieben - es geht afaik nicht, sie auf eine gemeinsame Datenbank zugreifen zu lassen. Du könntest höchstens den Speicherort zentral auf einem Server oder SAN ablegen, dort jedoch dann pro Server eine Datenbank nutzen.

Sinnvoller wäre da denke ich dann jedoch, die regelmässig erstellte Sicherung der Datenbank auf einen zentralen Ort zu sichern und die Datenbank, mit der gearbeitet wird, lokal zu halten. Das spart Zeit für die Antwortzeiten.

Ansonsten halt einen "grossen" DHCP-Server aufbauen und die anderen Lokationen auf diesen zugreifen lassen. Dafür werden dann vermutlich wieder IP-Helper Adressen benötigt. So kenne ich es aus diversen grösseren Firmen.

[Gast Blub666]

Hi,

hab es gerade nochmal probiert. Ergebnis siehe Anhang...

Bei einer SAN Anbindung, kann ich jeder SAN Anbindung nur ein Server zuordnen. (Laut Techniker...)

So nun die Frage...

wenn ich ein großen DHCP Server aufbau mit allen DHCP Scopes... und anschließend jemand in z.B. Amerika eine IP Beziehen will (DHCP Server steht in DE) , dann sind die Antwortzeiten doch viel zu hoch, oder nicht?!

Gruß

[Crash2001]

Selbst nach Amerika sind Ping-Zeiten von <200ms problemlos möglich (Westeuropa bis Ostküste USA sind auch schon mit 90ms problemlos möglich) - also mit anderen Worten <1/5 s Verzögerung.

Ich glaube nicht, dass es einen großen Unterschied macht, ob der Bezug der IP-Adresse nun sagen wir mal eine gute Sekunde länger (oder selbst 5 Sekunden würden denke ich nicht wirklich auffallen dabei) dauert (da ja ping pong gespielt wird beim Bezug). Das merkt eigentlich niemand.

Ab dann geht ja eh wieder alles über den lokalen Gateway und DNS-Server - ist also wirklich nur der Bezug der IP-Adresse und dann vielleicht noch die Erneuerung des Lease bei der Hälfte der Leasezeit, falls man nicht eh vorher neu startet.

[flashpixx]

Selbst nach Amerika sind Ping-Zeiten von <200ms problemlos möglich (Westeuropa bis Ostküste USA sind auch schon mit 90ms problemlos möglich) - also mit anderen Worten <1/5 s Verzögerung.

Was hat DHCP mit einem Ping (ICMP) zu tun und vor allem welche Aussage willst Du hier geben?

[Crash2001]

Was hat DHCP mit einem Ping (ICMP) zu tun [...]

Die Pingzeit von Deutschland nach Amerika entspricht ungefähr der Laufzeit des Paketes von Deutschland nach Amerika.

Anders habe ich jetzt auf Anhieb nichts gefunden, wie lange die Laufzeiten nach Amerika im Schnitt so sind. Durchaus möglich, dass es sogar noch schnellere Anbindungen (von der Laufzeit her) gibt, genauso wie es auch mit Sicherheit langsamere Wege geben wird.

[...]und vor allem welche Aussage willst Du hier geben?

Lies meinen Text - dort steht drin, welche Aussage ich damit tätige. :confused:

[...]Ich glaube nicht, dass es einen großen Unterschied macht, ob der Bezug der IP-Adresse nun sagen wir mal eine gute Sekunde länger [...] dauert [...] Das merkt eigentlich niemand.[...]