Rating: 5.0/5. (20 Stimmen) Details
Bitte warten...

  • Page 1: Installation
  • Page 2: Konfiguration
  • Page 3: IPv6, Multicastbereich, Superscope, Failover-Techniken
  • Page 4: DHCP-Relay-Agent, NAP, IPAM, Netsh, Powershell

IPv6

Lange schon ist bekannt, dass die IP-Adressen (v4) erschöpft sind. Daher befinden wir uns in der Umstellung auf die nächste Generation. IPv6 ist ein eigenes Thema für sich, daher gehe ich nicht weiter darauf ein. Mit Windows Server 2008 erschien der erste IPv6-DHCP-Server von Microsoft. IPv6-Bereiche werden ähnlich den IPv4-Scopes eingerichtet. In den meisten internen Netzwerken wird IPv6 noch nicht eingesetzt, doch werfen wir zumindest einen kurzen Blick darauf.

Das Pedant zu den Class C-Netzen sind die Site Local Unicast-Netze (fec0::/10) und Unique Local Unicast-Netze (fc00::/7). Ich verwende letzteren Range für den neuen Bereich.

 

Angabe des IP-Ranges unter IPv6.

Wie bei IPv4 können unter IPv6 Ausschlüsse definiert werden.

 

Sowohl Ausschlüsse als auch Leasedauer wird wie bei IPv4 eingestellt.

 

Man unterscheidet zwischen bevorzugter und gültiger Leasedauer.

 

Wie gewohnt werden die Optionen eingestellt, in diesem Fall der DNS-Server.

Die aktuell verfügbaren Optionen sind noch recht übersichtlich.

Multicastbereich

DHCP erstellt für IPv4 standardmäßig reine Unicastbereiche. Multicast wird in speziellen Szenarien genutzt, bspw. für Installationsnetzwerke oder Multimediadienste. Um einen entsprechenden Scope einzurichten, wählt man im Kontextmenü den Punkt “Neuer Multicastbereich…”.

Weitere Informationen finden sich im Technet.

 

 

Superscope

Bereichsgruppierungen helfen beim Verwalten.

Bereichsgruppierungen stellen eine Verwaltungseinheit auf dem DHCP-Server dar. Mit ihrer Hilfe kann man mehrere Netzwerke zu einem Superscope zusammenschließen.

Weitere Informationen finden sich im Technet.

Failover-Techniken

Der DHCP-Betrieb ist durchaus ein wichtiger Bestandteil der zentralen Infrastruktur. Zwar lässt sich ein Ausfall kurzzeitig kompensieren, jedoch ist das in großen Umgebungen nicht praktikabel. Daher wurden früher aus Redundanzgründen zwei DHCP-Server aufgesetzt und die Netze 70% zu 30% aufgeteilt. Fällt ein Server aus, übernimmt der zweite und kann für kurze Zeit aus dem IP-Pool Clients versorgen. Scope-Splitting ist unbefriedigend, da 30% der IP-Adressen im besten Falle nie zum Einsatz kommen.

Eine andere Möglichkeit stellt DHCP in einem Windows Failover Cluster dar. Zwei oder mehr Server hosten den DHCP-Dienst (Aktiv-Passiv). Fällt ein Knoten aus, übernimmt ein anderer Knoten den Dienst. Vorteilhaft, da der IP-Bereich nicht aufgeteilt werden muss. Jedoch werden Shared Disks und eine recht komplexe Failover Cluster-Infrastruktur benötigt. SAN ist teuer, nicht jeder kann es sich leisten.

Microsoft geht nun einen Schritt weiter und führt mit Windows Server 2012 DHCP-Failover ein. Zwei Server verwalten die IP-Adressen gemeinsam, Leases werden repliziert. Fällt ein DHCP-Server aus, übernimmt der zweite Server. DHCP-Failover lässt sich im Hot Standby- oder im Load Sharing-Modus betreiben. Zur Zeit ist die Funktion auf maximal zwei Server und IPv4-Netze beschränkt.

Zur Konfiguration wechselt man ins DHCP-Management und wählt im Kontextmenü des IPv4-Knoten die Aktion “Failover konfigurieren…” aus.

Eine einfache Art der Redundanz ist der DHCP-Failover. Er ist einfach zu konfigurieren.

Welche IP-Bereiche durch den Failover-Mechanismus geschützt werden sollen, wird an dieser Stelle angegeben.

Maximal zwei Server können sich gegenseitig absichern.

Nach der Einrichtung wurden sämtliche Bereiche dem Partnerserver hinzugefügt. Es handelt sich um eine unidirektionale Installation. Befinden sich auf den Partnerservern unterschiedliche Netze, muss auf beiden Servern der Failover konfiguriert werden.

  • Page 1: Installation
  • Page 2: Konfiguration
  • Page 3: IPv6, Multicastbereich, Superscope, Failover-Techniken
  • Page 4: DHCP-Relay-Agent, NAP, IPAM, Netsh, Powershell


Mac

Mac

Seit über 20 Jahren beschäftige ich mich mit Themen aus dem Bereich IT. Mein Schwerpunkt liegt dabei auf Produkte aus dem Hause Microsoft. Dazu gehören neben Active Directory und Windows Server insbesondere Netzwerkdienste wie DNS, DFS und DHCP. Zudem bin ich ein großer Verfechter des Internet Information Service, also dem Windows Webserver. Berührungspunkte im Bereich Citrix XenApp sowie XenDesktop, als auch VMware runden meinen Erfahrungsschatz ab.

2 Kommentare

Ingo Baitinger · 7. April 2014 um 12:53

Hallo Herr Schmidt,

erst mal: Vielen Dank für den Genialen Web-Auftritt!
Sehr schön, sehr informativ – viel Bild und wenig Text – genau richtig ! 🙂

Leider vermisse ich auch hier (wie schon lange bei vielen Seiten, die sich mit DHCP befassen) einen Hinweis darauf, wie man das auch ohne großartige Cluster-Lösungen hinbekommt.

Durch Aufsetzen zweier DHCP Server, die den selben Range mit gegenseitig ausgegrenzten aktiven Bereichen ist doch alles erledigt.
Klar, man hat doppelten administrativer Aufwand – dafür aber auch keine Scherereien mit ausfallenden Hardbeats und sonstigen Cluster-Krankheiten.:)

Vielleicht findet Sich ja noch irgendwo ein Plätzchen für so einen Hinweis? 🙂

Falls ich zu schnell war und besser hätte weiterlesen sollen (weil`s doch irgendwo steht) bitte ich um Entschuldigung – ich habe nur die Seite 3 gelesen!

Gruß
Baitinger

    Mac

    Mac · 8. April 2014 um 16:14

    Hallo Ingo!

    Danke für deinen Kommentar. Tatsächlich gibt es einen kurzen Hinweis auf Seite 3 zu dem früheren Verfahren “70:30-Split”, Microsoft empfiehlt sogar nur “80:20-Split” (siehe https://blogs.technet.microsoft.com/b/teamdhcp/archive/2007/06/23/thumb-rule-for-determining-the-ratio-in-a-dhcp-split-scope-deployment.aspx). Da beim Split-Verfahren im normalen Betrieb IP’s ungenutzt brach liegen und Microsoft ab Windows Server 2012 mit dem “DHCP-Failover”-Feature eine kostengünstige Alternative geschaffen hat, gibt es keinen Grund tiefer darauf einzugehen.

    Durch die neue Funktion “DHCP-Failover” wird auch keine teure Cluster-Infrastruktur benötigt, da zwei DHCP-Server direkt miteinander kommunizieren und ihre Informationen über IP-Adressen-Leases in beide Richtungen weiterreichen, ähnlich der AD-Replikation.

    Viele Grüße
    Mac

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.