Zusammenfassung

  • RFC 3074 ließ kooperierende DHCP-Server anhand einer Client-Kennung und einer vorab konfigurierten 256-Bucket-Zuordnung lokal dieselbe Antwortentscheidung treffen.
  • Der Hash verteilte die Antwortberechtigung, nicht die gemessene Arbeit. Leere Buckets konnten Stille erzeugen; auch ein späteres Antworten bewies keine Lease-Zustellung.

Antwortverteilung ist kein Lastmesser

Ein DHCP-Broadcast kann mehrere Server zugleich erreichen. RFC 3074 schlug 2001 vor, doppelte Antworten zu verringern, ohne Clients zu ändern: Jeder Server berechnet denselben Hash für eine Diensttransaktion und antwortet nur, wenn der Wert seiner Hash Bucket Assignment (HBA) zugeordnet ist.

Als Eingabe dient die DHCP-Option Client Identifier, sofern vorhanden. Andernfalls werden die Hardwarelänge und die Hardwareadresse des Clients verwendet, höchstens die ersten sechzehn Bytes. Pearsons Hash ordnet die Eingabe einem von 256 Werten zu. Eine 32-Oktett-Bitmap weist einem Server seine Buckets zu; ein BOOTP-Relay kann Bucketbereiche stattdessen Server-IDs zuordnen und Anfragen gezielt weiterleiten.

Damit ersetzte eine Konfiguration zu Beginn den wiederkehrenden Abstimmungsbedarf. Die Idee entstand als Optimierung für den damals noch in Arbeit befindlichen DHCP-Failover-Entwurf und wurde anschließend auf kooperierende Server und BOOTP-Relays ausgeweitet. Der Effizienzgewinn war konkret: kein Austausch zwischen Servern bei jeder Anfrage und keine notwendige Änderung auf Clientseite.

Der konfigurierte Prozentsatz war jedoch keine Messung von CPU-Last, Pooldruck, Antwortzeit oder erfolgreichen Zuweisungen. Laut RFC kann der tatsächliche Anteil kurzfristig vom Ziel abweichen und sich mit steigender Anfragezahl dem konfigurierten Wert annähern. Das beschreibt die Verteilung von Client-Transaktionen über die Zeit, nicht identische Kosten pro Transaktion oder gleich viel Arbeit für jeden Server.

Ein Bucket ohne Besitzer konnte Stille bedeuten

Die entscheidende Grenze steckt in der Bitmap. RFC 3074 sagt, dass eine Transaktion mit einem nicht zugewiesenen Hashwert vollständig ignoriert werden kann; in manchen Szenarien könne das erwünscht sein. Stille war damit nicht zwingend Paketverlust, sondern konnte aus der Zuweisungspolitik folgen.

Der optionale Parameter Delayed Service erlaubt einem nicht ausgewählten Server, nach einer Wartezeit zu antworten. Das ist ein zeitgesteuerter Ausweg, kein laufendes Quorum und kein Beleg, dass der vorgesehene Server ausgefallen ist. Die RFC überlässt es Implementierungen außerdem, einen nicht verfügbaren ausgewählten Server oder einen leeren passenden Adresspool zu behandeln.

Beim Relay werden die Schritte sichtbar: Es kann einen Bucket an einen Server oder an ein primär-sekundäres Paar mit einem separaten Failover-Verfahren weiterleiten. Auswahl, Weiterleitung, Lease-Zustand und spätere Nutzung der Adresse sind verschiedene Vorgänge. RFC 3074 standardisiert eine Auswahlregel, keinen gemeinsamen Lease-Zustand und keinen Ende-zu-Ende-Nachweis.

Der Datatracker führt RFC 3074 weiterhin als Proposed Standard des IETF. Das ist der Status des Dokuments, kein Beleg für heutige Verbreitung. RFC 8156 definiert 2017 DHCPv6-Failover und die Übernahme von Leases nach Serverausfall oder Netzpartition. Das ist ein begrenzter Vergleich, aber kein Nachweis, dass RFC 3074 aktualisiert oder eingesetzt wurde.

Heng Lus spätere Notiz über „Reality Layers“ dient nur als redaktionelle Linse, nicht als DHCP-Quelle: Regeltext, Betreiberkonfiguration, beobachtete Ausführung und Client-Ergebnis sind getrennt zu prüfen. Der historische Beitrag von RFC 3074 war genau umrissen: Antwortberechtigung berechenbar machen. Den Erfolg des Dienstes machte sie nicht selbstbeweisend.

Quellen