Experimenteller Server für verteiltes DHCP

Moin,

ich habe in den letzten Tagen angefangen einen Server für verteiltes DHCP in Python zu schreiben. Den Code habe ich gerade auf GitHub gepusht: GitHub - tcatm/pyddhcpd: Distributed DHCP Server

Die Software ist alles anderes als vollständig und bisher nur für grobe Tests geeignet. Sie kann jedoch schon:

  • eine Subnetz zwischen verschiedenen Instanzen aufteilen
  • Konflikte bei Netsplits/joins erkennen und auflösen
  • IPs und Leases an Clients verteilen und verwalten

Zum Ausprobieren passt man config.py seinen Vorstellungen an (bitte keine Supportanfragen, wie man das genau macht. Das wird noch einfacher, aber im Moment muss man alles manuell einstellen.). Das hier kann helfen offene Fragen zu beantworten: Packet types · GitHub

Starten tut man es (als root, wegen Port 68) mit sudo ./pyddhcpd.py.

20 Likes

Huhu,

Könntest du vielleicht erläutern was die Hintergründe dafür sind?
Hat das evtl mit der zukünfitigen Gluon Version zu tun?

D & G T

Ich (bzw. auch einige Gluonentwickler und Nutzer) wollen DHCP nicht auf wenige Server zentralisieren sondern die IPs direkt von den Knoten an die Clients vergeben lassen. Dazu ist es nötig, ein IPv4 Subnetz auf die Knoten aufzuteilen, damit es keine Konflikte gibt. pyddhcpd ist der Proof-of-Concept für ein in den letzten zwei Jahren erarbeitetes Konzept. Sobald der gut läuft, wird ein dazu kompatibler Server in C geschrieben, der dann auf den Knoten selber laufen kann. Das Projekt ist völlig unabhängig von Gluon und kann (hoffentlich!) auch in OLSR Netzen sinnvoll eingesetzt werden.

6 Likes

Hauptsache ihr schließt die räumlich nebeneinander stehenden Router zusammen jeweils bestehend aus 1 DHCP Server und daneben stehenden DHCP Forwardern. Ansonsten bekommt ihr Probleme mit dem Roaming von Clients wie z.B. Adressüberschneidungen wenn sie sich von einem zum anderem Router bewegen, da dann iin der Regel keine neue IP gezogen wird. Es sollte entweder einen Automatismus geben, der das z.B. aus Alfred ableitet oder in der Config Oberfläche eine Option für Forwarder und Server geben.

Aber ist auch geplant, das dann auch in Gluon einzubauen? Bin jedenfalls jetzt schon gespannt :slight_smile:

@christian1980nrw Das ist genau der Anwendungsfall für den ddhcp konzipiert wurde. Roamende Clients behalten ihre IP und Konflikte werden vermieden oder schnell aufgelöst. Das funktioniert auch schon fast. Den dazu noch fehlenden Code implementiere ich morgen.

@yayachiken Ja, das geplante OpenWrt Paket soll auch von Gluon verwendet werden.

2 Likes

Das sieht durchaus spanned aus.

Mir bereitet die Kommunikation zwischen den Servern Kopfzerbrechen.
Wie soetwas mit UDP passiert sehen wir beim Alfred.
In einem Netz „an der Saturationsgrenze“ (egal wo nun der viele Traffic herkommt, könnte ja auch mal echte Nutzlast von vielen Clients sein, Festival-Szenario…) besteht die Gefahr Netsplits (als false-positive), einfach weil niemand das Announce/Claim gehört hat.
Man wird also alles doppelt und dreifach broadcasten wollen.
Und trotzdem noch periodisch retransmitten… was dann auch für Traffic sorgt wenn das zu viele Nodes machen.

Vielleicht wird man dann um eine Hierachie von selbsternannten Supernodes in der Wolke (die mit der größten Uptime, dem besten Netz) nicht herumkommen, die dann mit den normalen Nodes per TCP kommunizieren. (nur so als Vorschlag, um den Broadcast-Traffic zu reduzieren und die Zuverlässigkeit zu erhöhen.)

Gut finde ich das Konzept (wenn ich’s richtig verstanden habe), bei mangel an Leases die neuen AP-Clients ein lokales RFC1918er per NAT zu sperren. (wieder: Festival-Szenario)

Die Claims sollten später sowieso für länger gelten (Tage bis Wochen), so dass auch ein temporärer Netsplit nicht zu split-brain führt.

Der einzig riskante Vorgang ist das Inbesitznehmen eines Blockes, von dem man glaubt er sei frei. Dort sind aktuell bereits drei Broadcasts im Abstand einiger Sekunden vorgesehen um sicherzugehen, dass ihn aktuell niemand belegt.

Alfred’s UDP Probleme sind anders gelagert und werden hierbei nicht so auftreten. Die Pakete werden bewusst klein gehalten, so dass sie auf jeden Fall in einen Frame passen.

1 Like

@tcatm das hört sich doch gut an.
Wichtig wäre dann auch noch bei lokalem DHCP, sobald kein Netz mehr da ist die SSID umzubenennen oder abzuschalten, damit sich die Smartphones dann wieder vom Accesspoint lösen und 3G verwenden.

Das Script ist glaub ich auch kurz vor der Fertigstellung.
https://forum.freifunk.net/t/wer-arbeitet-an-dem-script-wlan-abschalten-bei-internetausfall

@christian1980nrw Die SSID hat nichts mit DHCP zu tun. Smartphones sind mitlerweile intelligent genug 3G und WLAN gleichzeitig, je nach Verfügbarkeit, gerne auch für IPv6 und IPv4 unterschiedlich, zu verwenden. Alles weitere aber bitte außerhalb dieses Threads.

2 Likes

Hallo,

ziemlich cool, dass du das anpackst!

Frage: Wenn das ein reiner Mesh-Knoten ist und er gerade keine Verbindung zum Netz hat. Vergibt er dann trotzdem IPs? Denn dann hängt der Client in der Luft. Bisher bekommt er einfach keine IP und kann sich nicht anmelden.

Grüße
MPW

Jetzt driften wir ja doch ab… erstmal geht es nur darum überhaupt IPs ohne zentrale Vergabestelle zu verteilen. Sobald die Funktion in Gluon verfügbar wird (optional, damit die Abwärtskompatibelität erhalten bleibt), wird es allerdings so laufen, dass Knoten auch ohne jegliche Nachbarn bereits IPs an Clients verteilen um diesen die Kommunikation untereinander zu ermöglichen. Eines der Designziele hinter Gluon ist es, dass ein Einzelknoten bereits ein möglichst nützliches Netz bereitstellt und zusätzliche Knoten es nur erweitern. Dazu gehören IP Adressen und später nach Möglichkeit auch DNS Auflösung.

7 Likes

Ich habe nun noch einige Features eingebaut:

  • Blöcke werden nun selbständig verwaltet
  • „Roaming“ von Clients wird nun unterstützt

Probiert das doch mal alles aus. Einige Features fehlen noch, aber es sollte eigentlich schon gut funktionieren.

1 Like

Ich werde wenn ich die Zeit finde (vielleicht schon morgen) das manuell auf Server und Knoten im lokalen Mesh (5 in der Zahl) aufsetzen. Dann sehen wir ja was es hergibt.

Mit der Fragmentierung des Address-Bereich wachsen die Routing-Tabellen…

Ich frag mich, wie das ausserhalb des Layer 2 funktionieren soll…

Garbage-Collection dürfte bei DHCP eher schwierig werden…

Ist das ein Trollversuch oder kommt da noch was? :wink:

Nö!
Das war ne ernst gemeinte Frage!

Aber die Reaktion ist leider nur überheblich und arrogant…leider hier nichts besonderes…sehr schade!

Sorry, das sollte nicht arrogant rüberkommen. Ich hab da nur drei unvollendete Gedanken gelesen, die sich eigentlich durch Lesen des im Eingangspost verlinkten Gists klären sollten. Was ist deine Frage?

Wie verhinderst du die totale Fragmentierung des Address-Raum, wenn die sich nicht im selben L2-Netz befinden?

Dabei unterstelle ich, daß ein globaler L2-Adress-Space nicht funktioniren wird.

Was genau meinst du mit Fragmentierung und was mit „globalen Layer2“? Das zu verteilende Prefix wird in kleinen Blöcken zu aktuell je 4 IPs verwaltet. Wie die Blöcke auf die DHCP Server verteilt sind, ist dabei unerheblich. Selbst ein /16 wird bei der späteren C Implementierung weit unter einem Megabyte RAM belegen.

Die DHCP Server selber sollen eine zu starke Fragmentierung ihrer Blöcke vermeiden indem sie Leases mit ähnlichen Timeouts in einem Block verwalten. Blöcke können auch zwischen Servern verschoben werden (wenn z.B. der einzige Client den Server wechselt). Außerdem wird davon ausgegangen, dass das Prefix nie vollständig belegt wird sondern immer etwas Luft bleibt.

1 Like