Blog, default, Diverses, Network, Restliche Hersteller/Partner, Technologien

 1    DHCPv6 Ausfallsicherheit

Die Dienste DNS und DHCP werden nicht ohne Grund als Core Network Services (Netzwerkkerndienste) bezeichnet. Ob mittelständischer Familienbetrieb oder Großkonzern ohne diese rudimentären Dienste kann kein Unternehmensnetzwerk funktionieren. Speziell im Zeitalter von computergesteuerten Fertigungsanlagen, Smart Metering und IP-basierter Gebäudeüberwachung gewinnen DNS und DHCP noch stärker an Bedeutung. Aber auch ein stätiges Wachstum der IP-fähigen Systeme im Netz und deren steigende Mobilität machen Netzwerkkerndienste unabdingbar.

 

1.1        DHCPv4 Failover

Ein bewährtes Mittel, die Verfügbarkeit des DHCP Dienstes in einer IPv4-Umgebung  zu erhöhen, ist der Aufbau einer sog. „Failover Association“. Im von der Internet Engineering Task Force (IETF) beschriebenen Entwurf „draft-ietf-dhc-failover-12“ handelt es sich um eine Protokoll-basierte Geo-Redundanz zwischen zwei aktiven DHCP Servern. Die geographische Trennung bezieht sich hierbei auf die dritte Schicht des OSI-Modells (Netzwerkschicht). Eine DHCP Failover Association erlaubt damit eine Ausfallsicherheit des Dienstes über Netzwerkgrenzen hinaus.

Technisch handelt es sich um zwei DHCP Server in unterschiedlichen IP-Netzen, die für den gleichen dynamischen Adressraum zuständig sind. Eine stätige Kommunikation der beiden Systeme erlaubt es dem verbleibenden DHCP Server im Fehlerfall den Adressraum des anderen zu übernehmen (vgl. Abbildung 1).

 

 

1.2        DHCPv6 Failover

Ebenso wie in der IPv4-Welt handelt es sich bei DHCPv6 Failover um einen IETF Entwurf (draft-ietf-dhc-dhcpv6-failover-design-04), der im März 2014 auslief. Zum Zeitpunkt der Erstellung dieses Artikels verfügten die beiden den Markt beherrschenden Systeme Microsoft DHCP und ISC DHCP über keine Implementierung des IEFT Entwurfs für DHCPv6 Failover. Nach einer Präsentation zu diesem Thema auf Deutschlands einschlägiger IPv6 Konferenz, wurde darüber diskutiert, dass es nicht-kommerzielle Entwicklungen in dieser Richtung gibt, die aber nur für den Eigenbedarf verfügbar seien.

Dies bedeutet jedoch nicht, dass keine Redundanz des DHCP Dienstes unter IPv6 möglich ist. Der „Request for Comments“ (RFC) mit der Nummer 6853 betrachtet mögliche Ansätze, die mit verfügbaren Implementierungen umgesetzt werden können.

Ggf. hinterlegt man diese beiden Links für MS & ISC

https://technet.microsoft.com/de-de/windowsserver/dd448608.aspx

https://www.isc.org/downloads/dhcp/

 

1.3        Betrachtung der heute verfügbaren Redundanz von DHCPv6

Mit dem RFC 6853 „DHCPv6 Redundancy Deployment Considerations“ beschreibt die IETF drei semi-redundante Modelle, um die Ausfallsicherheit eines DHCPv6 Dienstes mit heutigen Mitteln zu realisieren.

 

1.3.1        Voraussetzungen der Modelle

Zunächst sind verschiedene Rahmenbedingungen bezüglich der beteiligten Systeme und deren Kommunikation untereinander zu klären (vgl. Abbildung 2).

 

  1. Zwei oder mehr Server stellen DHCPv6 Dienste für die gleiche Gruppe von Clients bereit.
  2. Die Implementierung aller beteiligten DHCP Server folgt strickt dem RFC 3315 „Dynamic Host Configuration Protocol for IPv6“.
  3. Die Implementierung aller beteiligten DHCP Relays (ugs. IP Helper) folgt ebenfalls strickt dem RFC 3315.
  4. Es gibt keine direkte Kommunikation zwischen den beteiligten DHCP Servern.
  5. Die von den DHCP Servern bedienten Clients nutzen „stateful DHCPv6“.
  6. Die von den DHCP Servern bedienten Clients müssen die sog. „Preference Option“, die im DHCP Paket enthalten ist, verarbeiten.

 

1.3.2        Getrennte DHCP Bereiche

Im Modell der „Split Scopes“ werden eindeutige, sich nicht überlappende DHCPv6 Bereiche für das gleiche Netzwerk definiert. Die DHCP Pools sind parallel aktiv, aber senden unterschiedliche Werte in ihrer „Preference Option“. Dies ist eine Art Priorisierung des Servers für den Client (vgl. Abbildung 3).

 

 

1.3.3        Mehrere, eindeutige DHCP Bereiche

Die Verteilung mehrerer IPv6-Präfixe ist das Prinzip des „Multiple Unique Prefixes” Modells. Hierbei wird der verfügbare DHCP Bereich nicht zwischen einer beliebigen Anzahl DHCP Servern aufgeteilt. Jedes System nutzt seinen eigenen Adressbereich. Wie auch beim Modell der „Split Scopes“ werden die DHCPv6 Server mit unterschiedlichen Priorisierungen konfiguriert (vgl. Abbildung 4).

 

 

1.3.4        Identische DHCP Bereiche

Das Modell der „Identical Prefixes“ basiert auf dem Prinzip der Wahrscheinlichkeit. Alle beteiligten DHCP Server bieten hierbei dynamische Adressen aus identischen DHCP Pools des gleichen Netzsegments an. Da der Adressraum bei IPv6 im Vergleich zu IPv4 viel umfangreicher ist, ist die Wahrscheinlichkeit von Adresskonflikten verhältnismäßig gering und akzeptabel (vgl. Abbildung 5).

 

 

1.3.5        Bewertung der drei Modelle

Alle drei zuvor beschriebenen Modelle scheinen das Problem der fehlenden Ausfallsicherheit eines DHCPv6 Servers lösen zu können. Allerdings ergeben sich durch die verschieden Ansätze unterschiedliche Vor- und Nachteile.

Die Aufteilung der verfügbaren DHCP Adressen auf zwei (oder mehrere) Systeme ist ein bekanntes Prinzip in IPv4-Netzwerken. Ein erheblicher Nachteil entsteht bei dieser Methode durch den Verlust eines Systems. Hierdurch reduziert sich die Anzahl der verfügbaren Adressen drastisch. In IPv4-Netzen kann es zum Ausfall des Dienstes kommen, wenn der DHCP Bereich des verbleibenden Systems nicht ausreichend Adressen für alle Clients bietet.  In IPv6-Netzen kann dieses Risiko stark reduziert werden, indem die aufgeteilten Adressbereiche hinreichend groß dimensioniert werden. Von einer Verschwendung der Adressen, wie sie bei diesem Szenario unter IPv4 bekannt ist, muss unter IPv6 nicht ausgegangen werden. Die allgemein empfohlene Größe von 64bit im Hostanteil der Netzwerkadresse erlaubt einen sehr großzügigen Umgang mit DHCP Bereichen. Das tatsächliche Problem beim „Split Scopes“ Modell liegt in der Administrierbarkeit – speziell bei mehreren DHCPv6 Serverpaaren. Ohne ein geeignetes Verwaltungswerkzeug können sich rasch Fehlkonfigurationen einschleichen, die unter Umständen zum Verlust des Dienstes führen können.

Das „Multiple Unique Prefixes” Modell hingegen weißt jedem DHCPv6 Server ein eindeutiges Netzwerk mit eindeutigem, dynamischen Pool zu. Ähnlich wie beim zuvor beschriebenen Ansatz sind lediglich die DHCP Bereiche innerhalb der 64er Netzwerke hinreichend groß zu wählen, um nicht in die Verlegenheit der Adressknappheit zu geraten. Die Komplexität bei der Administration ist wesentlich geringer als bei der „Split Scopes“ Methode. Es kann hier leicht mit Templates gearbeitet werden. Zu berücksichtigen ist jedoch, dass mehrere IPv6-Präfixe im gleichen Netzwerksegment verteilt werden. Unter IPv4 ist dieses Verfahren als „Superscoping“ bekannt. Dies beeinflusst wiederrum die Definition von „Access Control Lists“ (ACL) und deren Verwaltung.

Die Verwaltbarkeit der „Identical Prefixes“ Methode gestaltet sich simpel, da jedes DHCP System die identische Konfiguration erhält. Ein Mangel an verfügbaren, dynamischen Adressen kann im Falle des Defekts eines der Systeme nicht eintreten. Unter der Voraussetzung, dass die DHCP Adressen den Clients zufällig als Lease angeboten werden, ist die Wahrscheinlichkeit einer Doppelbelegung bei der Adressvergabe äußerst gering. Die Praxis zeigt jedoch, dass die aktuellen DHCPv6 Implementierungen einen dynamischen Pool oft nach dem gleichen Prinzip füllen, z.B. beginnend mit der letzten verfügfahren Adresse des Bereichs. Dadurch kommt es durchaus zu Adresskonflikten.

Zusammenfassend lässt sich feststellen, dass alle drei Modelle eher eine Übergangslösung als ein tatsächlicher Ansatz für die Ausfallsicherheit einer DHCPv6 Umgebung sind. Zum Einen berücksichtig keines der Modelle Vorkehrungen für den Fall, dass ein ausgefallenes System wieder aktiv Adressen bereitstellt. Zum Anderen ergibt sich bei manchen Modellen die Möglichkeit von Überschneidungen bei der Adressvergabe – auch wenn die Wahrscheinlichkeit gering ist.

Des weiteren muss die dynamische Aktualisierung von DNS Einträgen durch die DHCP Server betrachtet werden. Dieses Prinzip ist üblich in IPv4 und wurde auch für IPv6 übernommen. Es kann zu Unstimmigkeiten im dynamischen DNS (DDNS) kommen, wenn mehrere DHCP Server identisch konfiguriert sind. Das Problem besteht ebenfalls, wenn DHCPv4 und DHCPv6 Server gleichzeitig die selbe DNS Zone aktualisieren. Speziell beim ISC DHCP hilft an dieser Stelle die „update-conflict-detection“ Anweisung.

 

1.4        Warum es (noch) kein DHCPv6 Failover gibt

Nachdem zwei Server eine Failover Association aufgebaut haben, werden die Adressen des Pools aufgeteilt. RFC 3074 beschreibt den „DHC Load Balancing Algorithm“, der vom ISC im DHCP Daemon implementiert ist. Standardmäßig wird ein DHCP Pool zwischen zwei „Peers“ zu 50/50 aufgeteilt (aktiv-aktiv-Modus).

Dieses Konstrukt weißt jedoch in der Praxis seine Tücken auf. Speziell das sog. „Rebalancing“ kann zu einem unerwarteten Verhalten im DHCP führen. Dieser Abgleich der verfügbaren IP Adressen erfolgt regelmäßig für jeden einzelnen DHCP Pool, für den Failover aktiv ist.

 

code_1_bluecat

 

Hierbei wird allerdings nicht das Delta übertragen, sondern eine Liste aller freien und belegten Adressen. Abgelegt werden die Details im sog. „Leases File“ (dhcpd.leases).

 

code-2_bluecat

 

In Umgebungen mit vielen Failover Pools und besonders bei großen Netzen beeinträchtigt das Rebalancing den DHCP Dienst erheblich. In der Regel wird mit DHCP Failover eine geografische Redundanz erzielt, wodurch die Kombination aus Rebalancing und Latenzzeit zu berücksichtigen ist.

Aus dem Projekt einer international tätigen Finanzdienstleistungsgesellschaft ist bekannt, dass zwei geografisch nicht(!) getrennte DHCP Server im Failover Modus konfiguriert für 500.000 Clients in etwa 3 Minuten für die Synchronisation ihrer Leases benötigen. Hier kann von einer Latenzzeit gegen Null ausgegangen werden. Würde man die Systeme auf dem Campus verteilen, ist eine Latenzzeit von 55ms anzunehmen. In diesem Fall ist mit einer Synchronisationsdauer von bis zu 45min. zu rechnen. Dies kann die Vergabe von IP Adressen durch den DHCP Dienst stark beeinträchtigen.

Betrachtet man nun die immense Masse der IP Adressen eines IPv6 Netzwerks und des darin enthaltenen Pools, wird klar, dass der bisher genutzte Rebalancing Algorithmus den DHCP Dienst rasch zum erliegen bringen kann.

 

1.5        Referenzen

Titel

Referenz

DHCPv6 Redundancy Considerations

DHC Load Balancing Algorithm

RFC 3074

Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

RFC 3315

IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6

RFC 3633

A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)

RFC 4701

Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients

RFC 4703

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option

RFC 4704

DHCPv6 Leasequery

RFC 5007

DHCPv6 Bulk Leasequery

RFC 5460

DHCPv6 Options for Network Boot

RFC 5970

DHCPv6 Redundancy Considerations

RFC 6853

 

Seit 2009 beschäftigt sich Andreas Taudte tiefergehend mit den Themen DNS und DHCP. Zunächst tätig als technischer Berater im deutschsprachigen Raum, übernahm er ab 2013 die Rolle des Sales Engineers beim IPAM-Hersteller BlueCat für das Gebiet Zentraleuropa und den Mittleren Osten. Neben vertrieblichen Themen nimmt die Konzeption und Migration komplexer DNS/DHCP Umgebung einen Großteil seiner Zeit in Anspruch.

Xing: xing.com/profile/Andreas_Taudte
LinkedIn: de.linkedin.com/in/ataudte/

 

Ramazan Oruc

Über Ramazan Oruc

Mehr über den Autor: siehe Team Seite

Kommentare sind abgeschaltet.