Welche DHCP-Konzepte gibt es?

Technik
1

Hallo,

wir Admins aus Münster möchten gerne mal in die Runde fragen, wie in anderen Domänen DHCP abgewickelt wird.

Wir haben derzeit auf den VMs, die am Rheinland hängen nicht authorative DHCP-Server. Also irgendwie vier Stück oder so. Das läuft beschissen. Man bekommt sehr oft keine IP, obwohl der Knoten eine Fastd-Verbindung hat.

Der Plan ist jetzt zwei völlig separate DHCP-Server zu machen, einen primären, authorative und noch eine Ersatzlösung (failover).

Leider ist es @paulinsche bisher nur gelungen das über Mac-Ebene zu realisieren, also das Relay nicht über IP angebunden. Getestet mit isc-dhcpd.

Was für DHCP-Konzepte werden so in anderen Communities gefahren? Habt ihr da elegante Lösungen?

Grüße
Matthias

1 „Gefällt mir“
2

[quote=„MPW, post:1, topic:9129“]
Wir haben derzeit auf den VMs […] nicht authorative DHCP-Server. Also irgendwie vier Stück oder so. Das läuft beschissen. Man bekommt sehr oft keine IP, obwohl der Knoten eine Fastd-Verbindung hat.[/quote]

Yepp, das Problem hatten wir auch, dank ungleicher fastd- und batman_adv-Verteilung gingen einigen GWs die IPs aus, während andere sich mit Suizidgedanken plagten ob der massiven Nichtnutzung :frowning: Mesh-Erweiterung geht nur mit FW-Update, und den Range zu erweitern, weil man DHCP nicht auf die Reihe bekommt, ist auch irgendwie doof.

Wir haben unser Netz jüngst umgebaut, und machen nun zentrales DHCP. Das tut leider an zwei Stellen nicht out-of-the-box, zum einen geht’s nur mit L2TP-, nicht mit GRE-Tunneln, zum anderen braucht isc-dhcp-relay einen Patch.

Die Idee ist natürlich, den DHCP-Server per IP zu erreichen (und nicht ins Mesh zu ziehen). Das gelingt aber leider nur mit broadcast-fähigen Interfaces, wozu die GRE-Familie nicht zählt, wohl aber L2TPETH. Ist IMHO ein Bug im isc-dhcpd (Relaying benötigt kein Broadcast, nur funktionales Routing), aber was nützt das? Ergo: Planmodifikation und statt GRE- eben L2TPETH-Tunnel.

Was noch nicht realisiert ist – die doofe Limitierung auf 24 Stunden pro Tag, Ihr kennt das –, ist der zweite dhcpd am zweiten Standort. Das dhcp-relay kann „parallel“ an >1 Server senden; im LAN klappt es mit dem Abgleich ganz gut (DHCP-Request geht per Broadcast raus, mal antwortet der dhcpd im OG schneller, mal der im UG, aber sie gleichen sich ab), im WAN (zwischen Standort 1 und Standort 2 liegen bei uns 15+ ms) bin ich noch skeptisch. Tendentiell könnten wir auch das alte Setup adaptieren: die Hälfte der Adressen für Standort 1, die andere für Standort 2; dhcp-relay an Standort 1 schickt nur zu dhcpd von Standort 1, analog für Standort 2 …

Ja, wir sinnieren noch ob der »besten« Lösung, nein, wir haben noch keine Ausfallsicherheit. Aber immerhin sind wir das Nadelöhr los, was die Clientanzahl bei ca. 1000 limitierte. Mit über 1400 Clients am Verkaufsoffenen Sonntag wurde mal wieder eine Marke gesetzt :wink:

3

Prinzipiell bin ich sehr an euren Erfahrungen hierzu interessiert. Was mir aber nicht gefällt: Zentralität.
Ok, Gateways sind eh schon zentral. Dahinter aber noch einen zentralen Dienst zu setzen, gefällt mir nicht sonderlich.
Bei uns hat jedes Gateway entsprechend ausreichend IPs zur Verfügung, dass behebt das Problem auch. Was ich mir als Ersatz anschauen wollte ist distributed dhcp von @tcatm. Damit sollte auch kein Problem mehr auftreten, dass zu wenig IPs zur Verfügung stehen.

4

Da prallen dann Theorie und Wirklichkeit aufeinander. Wir hatten /20 (4k v4-Adressen) je Mesh (=> 16 Meshes je /16 möglich; wir agieren in einem (Land-)Kreis, die Notwendigkeit, alles in ein Mesh zu zwängen, besteht nicht) vorgesehen.
Das ohne FW-Update zu erweitern geht technisch auf den GWs, ggf. tut dann aber eine Magie auf den Knoten nicht mehr? Ich muß gestehen, daß ich nicht geforscht habe, wozu die Knoten eigentlich die v4-Netzgröße wissen müssen, da sie am v4-Netz gar nicht partizipieren.
Anyway: Bei 4 GWs jedenfalls waren es noch 1000 IPs je GW, bei 6 dann nur noch 680. Zudem müssen bei Hinzufügen neuer GWs alle alten GWs angefaßt werden, auch nervig ohne Ende. »Verteilter DHCP« klingt interessant, wenn’s das gibt, guck’ ich mir das auch an — wir brauchten aber eine Lösung jetzt (lies: zum vergangenen Monatswechsel), und da ist zentraler DHCP unserer Ansicht nach das geringere Übel. Zumidnest im LAN kann man den dhcpd redundant betreiben, wie das im WAN aussieht, wird die Zukunft zeigen. Weiterer, erwünschter Nebeneffekt: die Einflußnahme von batman_adv sinkt, der dhcpd ist immer der gleiche, somit ändern sich auch nicht so häufig wie zuvor v4-Default-GW und damit NAT-Instanz.

Wünschenswert wäre, batman_adv beizubringen, die RTT zu den (batman_adv-) GWs kontinuierlich zu prüfen und das GW mit der geringsten RTT und dann dem geringsten Verlust zu wählen; den aktuellen Algorithmus kann ich jedenfalls nicht nachvollziehen: DISCOVERs kommen über (DHCP-) GWs rein, die gar nicht das (fastd-) GW des Knotens, an dem das Endgerät hängt, sind.
Im Grunde könnte man die Situation verbessern, indem der dhcpd Kenntnisse über das batman_adv-Netz erhält und entsprechend Entscheidungen trifft. Aber da wir noch auf v14 setzen (da keine Vorteile in v15 gesehen werden, wohl aber Stabilitätsprobleme in bestimmten Setups berichtet), lohnt es kaum, da Zeit zu investieren.

Schön wäre, wenn man dhcpd als verteilten Dienst mit zentraler Konfiguration betreiben könnte, jeder dhcpd krallt sich einen Bereich und vergibt daraus, bei Addressknappheit fragt der betreffende in die Runde und wer noch XX% Luft hat, verringert seinen Berich um XX/2 oder so. Bleibt Rattenschwanz an Problemem (u. a. Fragmentierung), und ist wohl eher eine sehr spezielle Anforderung …

BTW: wie macht Ihr da draußen die Adressvergabe bei v6? Bislang hatten wir ULA über die Knoten, public über die GWs, jeweils per RA announced. Damit ist es dann eher Zufall gewesen, welches GW für IPv6-Default genommen wurde. (Und die Logs wurden vollgemüllt mit „das announcen wir gar nicht!“.)
An sich wäre es praktisch, da den lokalen Knoten zu nehmen, also statt/neben ULA auch public v6 dort zu announcen. Außer, man bedenkt das Handover und erinnert sich, daß Knoten ggf. an 16/1er DSL-Leitungen (oder noch weniger) hängen (oder gar Kabelanschlüssen mit generell nur homöopathischer Upstreambandbreite). Und die nächste Netzebene nach den lokalen Knoten sind schon wieder die GWs …

5

Ein Knoten der roamt sollte eigentlich sein Default-Gateway behalten, da DHCP-Renews per Unicast erfolgen (korrigiert mich, wenn ich falsch liege) und damit das Gateway-Selection Feature in Batman nicht greift.

There you go: GitHub - tcatm/pyddhcpd: Distributed DHCP Server
Ideen: Packet types · GitHub
Es wäre wohl sehr willkommen, wenn Leute testen und weiterentwickeln.

Wir nutzen nur unser public IPv6 im Netz. Ja, Auswahl des Gateways geschieht clientseitig → viel Querlast.
Das Problem mit den Logs haben wir nicht, da wir nur ein Netz im Mesh benutzen.

Würde nur Sinn ergeben, wenn man eine IPv6 Gateway-Selection implementieren würde. Sprich: Knoten würde zu dem nächstgelegenen IPv6 Gateway routen. Interessantes Thema auf jeden Fall.

6

Wir haben 4 Gateways und somit 4 authorative ISC-DHCP-Server. Von IP Adressen Vergabe Problemen ist mir noch nix zu Ohren bekommen bzw. noch nicht selber erlebt. Aber mit rund 250 Knoten sind wir auch eher ein beschauliches Netzwerk. Bei uns machen viel mehr die günstigen VServer gerade Probleme. Netcup hatte unsere Maschinen wegen angeblich DDOS Angriff letzte Woche gedrosselt.

7

Bis etwa ~700 Knoten lief es auch problemlos bei uns und seit dem werden die Probleme immer schlimmer.

Frage an alle: Gibt es denn für Linux nicht noch andere DHCP-Server? Ein Freifunker hier aus Münster hat mir erzählt, dass es im professionellen Bereich Software für dieses BS aus Redmond gibt, dass DHCP-Relays über Layer3 steuern kann.

8

In Wupper sind auf vier GWs ISC-DHCP-Server aufgesetzt die jeder Broadcastdomäne (9-11 Stück) in Wupper DHCP-Anfragen beantworten. Pro GW und je Broadcastdomäne wird ein /22er Block zugewiesen. Die Leasetime beträgt 10 min. Insgesamt gibt es also /20, die per DHCP zugewiesen werden können. Es gibt bisher keine Probleme in diesem Aufbau.

Als Beispiel eine Broadcastdomäne auf einem der 4 GWs in Wupper

subnet 10.3.0.0 netmask 255.255.0.0 {
interface bat-wup;
range 10.3.252.0 10.3.255.254;
default-lease-time 600;
max-lease-time 1200;
option domain-search "ffw", "in.ffwtal.net";
option domain-name-servers 10.3.0.247;
option broadcast-address 10.3.255.255;
option subnet-mask 255.255.0.0;
option routers 10.3.0.240;
}

Probleme, die sich hierbei ergeben können, sind, dass ein DHCP-Server seine tausend Adressen verteilt hat und keine Anfragen mehr annimmt. Auf Batman-Ebene wird es glaube ich (ich weiß es nämlich nicht) nicht erkannt und die Anfragen laufen ins leere. Wenn dies der Fall ist, ist dieses Szenario empfehlenswert, welches bei uns in der Schublade liegt:

Anzahl der Nutzer > Anzahl der verfügbaren Adressen eines DHCP-GWs → erhöhe die Anzahl der verfügbaren Adressen auf dem GW

ist dies nicht mehr möglich, dann teile per bactl gw client mit, dass auf diesem GW keine DHCP-Anfragen mehr beantwortet werden* die anderen GWs springen in diesem Fall ein.

Anzahl der Nutzer > (Anzahl der verfügbaren Adressen der Broadcastdomäne — Anzahl der statischen Adressen) → Schicht im Schacht

*) obwohl bactl gw client die Batman-Einstellung batctl gw server x/y außer Kraft setzt, beantwortet dieser GW trotzdem immer noch DHCP-Renew-Anfragen, die an diesen explizit gestellt werden. Sie werden nicht von Batman umgebogen. Möchte man nach und nach Nutzer von einem GW wegbekommen, weil die Last zu hoch ist oder um z. B. Wartungsarbeiten durchführen zu können ohne die Verbindungen der dynamischen Nutzer zu trennen, muss der DHCP-Server deaktiviert werden. Die anderen Server übernehmen dann die Broadcast-Anfragen, da die gezielten DHCP-Renew-Anfragen ins leere laufen.

9

Hat jemand einen Tipp, was für Diagnosemittel es gibt, um die DHCP-Probleme bei uns einzugrenzen?

10

Was sagt denn die bisherige Fahlersuche?

Ist der IP Pool aufgebraucht oder kommen die Anfragen nicht bei den Servern an?

11

Statt mit L2TP habe ich ein GRETAP Inferface in eine Bridge gepackt (Mag kompliziert klingen, aber dafür reichen ein paar Einträge in /etc/network/interface weil es so ab Werk geht). Für isc-dhcp-relay ist dass dann ein Ethernet-Interface und alle funktioniert. Wozu der Patch gut ist, habe ich nicht verstanden.

12

Unterscheidbarkeit und damit korrekte Zuweisung des relayenden GWs.

13

Jein.

To inform clients possessing a valid DHCP release about a gateway change (the link quality to the gateway could have dropped or the client is roaming around) batman-adv will also inspect incoming DHCP renewal packets. If their destination is not the currently selected gateway and below a certain TQ threshold (currently defaulting to a TQ of 50), the DHCP renewal packet is not forwarded, thereby forcing the client to request a new DHCP lease from a better connected gateway.

Ganz raus hält sich batman_adv leider nicht; und ohne Gateway-Modus kamen hier zumindest (v14) gar keine DHCP-Pakete durch. Aus meiner Sicht wäre ein DHCP-transparenter batman_adv-Modus wünscheswert für Gluon-Netze, aber nunja. Vielleicht in v18 :wink:

D. h. Ihr announced nur ein /64 lokal von den Knoten per RA? Bekommen, und behalten, dann nicht alle Clients zumindest überwiegend (laufzeitbedingt) den initialen Knoten als v6-Default-GW bis zum Ende der v6-Adressen-Gültigkeit (die nur per FW-Update geändert werden kann)?
Inter-GW-Traffic ist zwar doof, aber verkraftbar (insbes. ohne künstliche Nadelöhre wie fastd). Inter-Knoten-Traffic (Client-Knoten-GW-GW-Knoten; Rückweg sollte dann direkter gehen?) ist doch aber bei VPN-Verbindungen eher richtig kacke?

Nach den Erfahrungen mit v4 bin ich eigentlich ganz froh, daß batman_adv (zumindest in v14) v6 ignoriert. Wie so oft, abschaltbare Features verbreitern das Anwendungsspektrum. Nur wie man public v6 »richtig« in ein Gluon-Mesh einführt, ist mir noch immer unklar.

14

Warum genau setzt ihr

ein und wundert euch über Probleme? Aus dhcpd.conf(5):

The authoritative statement
authoritative;
not authoritative;

The DHCP server will normally assume that the configuration information about a given network segment is not known to be correct and is not authoritative. This is so that if a naive user installs a DHCP server not fully understanding how to configure it, it does not send spurious DHCPNAK messages to clients that have obtained addresses from a legitimate DHCP server on the network.

Network administrators setting up authoritative DHCP servers for their networks should always write authoritative; at the top of their configuration file to indicate that the DHCP server should send DHCPNAK messages to misconfigured clients. If this is not done, clients will be unable to get a correct IP address after changing subnets until their old lease has expired, which could take quite a long time.

Usually, writing authoritative; at the top level of the file should be sufficient. However, if a DHCP server is to be set up so that it is aware of some networks for which it is authoritative and some networks for which it is not, it may be more appropriate to declare authority on a per-network-segment basis.

Note that the most specific scope for which the concept of authority makes any sense is the physical network segment - either a shared-network statement or a subnet statement that is not contained within a shared-network statement. It is not meaningful to specify that the server is authoritative for some subnets within a shared network, but not authoritative for others, nor is it meaningful to specify that the server is authoritative for some host declarations and not others.

15

[quote=„tcatm, post:14, topic:9129“]
Warum genau setzt ihr

ein und wundert euch über Probleme?[/quote]

»authoritative« Ja/Nein sollte nur bei ›externen‹ Anfragen relevant sein? Aus meinen Beobachtungen besteht der Unterschied in der Behandlung von Anfragen z. B. für 192.168.178.5: mit »authoritative« gibt’s ein DHCPNAK, ohne nüscht — d. h. der Client wartet und probiert dann irgendwan entnervt ein DHCPDISCOVER? Das hat aber genau nichts mit dem Aus-/Überlaufen der Pools je GW zu tun …

16

Geht das nicht mit diesem „giaddr“? Oder steht der Wert nicht zur Auswahl des richtigen GW im ISC-Server zur Verfügung? Dann vielleicht in der agent.circuit-id im Name den Inferfaces den des Gateways versenken: statt immer nur bat0 kann man das ding ja server1-bat0, server2-bat0 nennen.

17

Kann man sicherlich. Man kann sich auch ein Loch ins eine Knie bohren, weil man Knie links von Knie rechts nicht unterschieden kann. Genau dafür ist aber agent.remote-id da, und der Patch ermöglicht einfach das Setzen dieser Variablen. (bat0 umzubenennen hat lustige Seiteneffekte bei allen bat-Kommandos. Kann man machen, dann aber eher per Mesh.)

18

Also wenn ich @tcatm s Zitat der Manpage richtig verstanden habe, müsste man den DHCP-Servern nur beibringen, dass sie authorative über alles sind, was nicht 10.43.0.0/16 ist.

Dann aber nicht authorative, was in 10.43.0.0/16 aber nicht in ihrem Bereich liegt und dann wieder authorative in ihrem Bereich.

Hat jemand dafür ein Syntaxbeispiel?

19

Wieso so kompliziert? Alle DHCP auf authorative stellen und fertig ist. Oder verstehe ich gerade überhaupt nicht wo das Problem liegt? Andere IP Adressen außer 10.134.0.0/16 sollen in unserem Netz wenn möglich gar nicht rum geistern.

20

Das hatten wir vorher und das lief auch nicht besser, eher noch schlechter.

Man bräuchte mal ein Testtool, wo man die drei Fälle durchspielen kann.

  • DHCP-Client hat keine IP
  • DHCP-Client hat eine IP irgendwo aus dem FF-Netz
  • DHCP-Client versucht eine netzfremde IP