Hmm. Sonstige Parameter parallel geändert? Authoritativ sollte er sein, weil sonst der Fall „Client kommt mit netzfremder IP“ (sei es ein neuer Client oder Client war zuletzt mit anderem GW verbunden) erst nach Tiemouts bearbeitet wird. Das äußert sich dann in seeeeehr langen Zeiten, bis das Endgerät eine Verbindung meldet.
[quote]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
[/quote]
Hmm, wie meinst Du das? dhcpd deckt doch genau diese Fälle ab und loggt sie? Also zumindest 2 & 3, die im Falle getrennter Ranges pro GW letztlich identisch sind. Den ersten Fall kannst Du simulieren, indem Du den dhcpd killst, Resultat ist i. d. R. bei Android, daß die Verbindung nach laaaanger Zeit als fehlgeschlagen abgelehnt und eine andere versucht wird. Falls (public) v6 per RA verteilt wird, meldet mein Linux (Laptop oder RPi) in dem Fall i. d. R. eine funktionale Verbindung über den Network Manager, wirklich nutzbar war’s aber nur bedingt (keine v4-Ziele erreichbar).
Das Problem im Münster war, wenn ich es richtig verstanden habe, dass in einem Netz zwei DHCP-Server standen, die nichts von einander wussten, aber beide „authorative“ waren. Von einem kam ein OFFER vom anderen ein NACK. Wenn ich mich richtig erinnere…
Möglicherweise sollten wir auch mal schauen, ob wir die lease-time etwas hochsetzen.
Wenn ich richtig informiert bin, ist das momentan bei uns wie folgt konfiguriert:
default-lease-time 240;
max-lease-time 1200;
Was in praktisch dazu führt, dass die Clients nach ~ 2 1/2 Minuten einen DHCPREQUEST senden.
IIRC fragen die Clients nach Leasetime/2 nach ihrer aktuellen Adresse; bin mir nur nicht im Klaren, welche der Leastimes hier zählt, ich meine, die default-lease-time
An und für sich muß in einem batman_adv-Netz auf jedem GW, welches auf „batctl gw server“ läuft, auch lokal ein DHCP-Server (ob Daemon oder Relay ist erstmal egal) laufen. Dieser sollte tunlichst authoritativ sein (um Anfragen aus anderen Bereichen direkt zu NACKen), der Range darf sich aber nicht mit denen anderer DHCP-Server im gleichen Mesh überschneiden. (Wobei doppelte/nicht freigegebene IPs zumindest vom ISC-Server angepingt und aus der Verteilung genommen werden scheinen.) Authoritativ sollten sie wie gesagt alle sein, Anfragen bekommen sie ja eben nicht per Broadcast, wie in einem normalen Netz; die DHCPDISCOVERs filtert/kanalisiert batman_adv ja auf ein (zufälliges) GW aus der Liste (batctl gwl), folgende Anfragen gehen eh’ per Unicast.
Aufgrund dieses Threads laufen in Münster wieder zwei, vermutlich identisch konfigurierte DHCP-Server in einem LAN, ohne von einander zu wissen und fühlen sich dort beide autoritativ.
GW1: 10.134.10.1 mit DHCP Range 10.134.10.2 - 10.134.19.255
GW2: 10.134.20.1 mit DHCP Range 10.134.20.2 - 10.134.29.255
GW3: 10.134.30.1 mit DHCP Range 10.134.30.2 - 10.134.39.255
GW4: 10.134.40.1 mit DHCP Range 10.134.40.2 - 10.134.49.255
Alle autoritativ. Leasetime und Default Leasetime jeweils 300 Sekunden.
Dies gilt nur für den eigentlichen Broadcast (DHCPDISCOVER), in die Unicast-Kommunikation (DHCPOFFER, DHCPREQUEST, DHCPACK, DHCPNAK) greift batman_adv »meistens« nicht ein, siehe oben.
Siehe u. a. #8 und #2 und letztlich #21. Anders als in einem »normalen« LAN melden sich die Clients im Freifunk-Mesh ja nicht ab; ihre Besitzer wandern einfach aus dem abgedeckten Bereich raus, d. h. der jeweilige Lease bleibt belegt, ergo muß, worst case, der dem GW zugeordnete Bereich so groß sein, wie Ihr in der default-lease-time unterschiedliche Clients erwartet. Je GW, denn batman_adv verteilt nur auf Basis der gwl und dies, zumindest bei uns, nicht symmetrisch. Bei uns waren insgesamt 2000 IPs (/21) für 1000 parallele Clients über 4 GWs (=> 500 IPs/GW) zu wenig, dank zentralem DHCP reichen die jetzt locker aus, bei einer default-lease-time von nun wieder 1800 (vorher 300). Größere default-lease-time => weniger DHCP-Verkehr (Nachfrage nach Verlängerung bei lease-time/2), dafür aber höherer Anteil an nicht genutzten Adressen.
Kann man denn auch mehrere secondary DHCP-Server haben? Denn dort ist nur von zwei DHCP-Servern die Rede, die miteinander sprechen.
Wenn wir, wie oben bereits besprochen, aber an jedem Gateway einen authorativen DHCP-Server brauchen, dann bräuchten wir ja mehrere secondary DHCP-Server. Oder wie macht man das dann?
@MPW Unsere Idee war ja an jeden batman „endpunkt“ einen DHCP Relay setzen, der dann mit einem zentralen DHCP spricht, das ist imo erstmal unabhängig von failover.
Da das dhcp relay aber primär gedacht ist, mehrere subnetze mit einem DHCP sprechen zu lassen, kam bei mir die Frage auf, ob das überhaupt vernünftig läuft, wenn mehrere relays in einem subnet sind und ob uns nicht letztendlich batman einen knüppel zwischen die Beine wirft.
Hat da jemand Erfahrung/Mutmaßungen?
PS: In meinem Script bedeuten Aktive Leases, Leases deren startzeit kleiner und endzeit größer als die aktuelle utc zeit sind. Touched leases sind alle adressen, die jemals herausgegeben wurden, aber gerade nicht aktiv sind. Dieser wert ist daher imo (für unser problem) recht uninteressant. Ich habe ihn aber in diversen anderen auswerte tools ( z.B. Dhcpd-pool) gesehen und daher mit aufgenommen. Ggf. Interessant wäre noch, in erfahrung zu bringen, ob es rine dauer gibt, ab der ein inaktives lease erst wirder vergeben wird.
Das ist das, was wir umgesetzt haben derzeit. „Man“ „will“ an sich natürlich diesen DHCP-Server redundant aufgesetzt, bei uns steht das noch aus. Wahrscheinlich wird zum Wochenende auf einer 2. VM ein 2. DHCP-Server gestartet, der sich ganz normal im LAN mit dem 1. abgleicht und von dern DHCP-Relays entsprechend quasi-parallen angesprochen wird.
Für das DHCP-Relay ist das mit den verschiedenen Subnetzen relativ; faktisch hat man „vorher“ verschiedene Subnetze in einem L2-Netz gefahren, denn jedes GW hatte einen eigenen IP-Bereich. Statt nun auch 4x 512 IPs wird dank Relay nun aus 1x 2048 vergeben – es sollte einleuchten, daß, und warum daß. sinnvoller, besser ist.
