Wie groß sind denn die Pools? Der Server muss zwingend authorative sein, da in batman-adv Gatewaynetzen nichts anderes funktionieren kann! Der Knoten sieht ja immer nur den einen DHCP Server per Broadcast und wenn der dann auch noch kein NAK schickt, kann der Client lange warten, dass mal wer anders antwortet.
Die Pools je Gateway müssen reichlich überdimensioniert sein. Sie sollten mindestens ein vielfaches der Gesamtzahl der erwarteten Clients alleine bedienen können.
Gilt das auch schon für Batman 2014.3?
Jeder DHCP-Server verteilt immer ein /21, also 2046. Die Gesamtanzahl der Clients liegt in der Spitze so bei ~1700.
Ja.
Und um auf die 20 Zeichen zu kommen: Wir sollten wirklich mal von v4 weg. Da ist soviel falsches Halbwissen verbreitet, dass es Freifunknetze viel zu kompliziert macht.
@void und @FanLin: Könnt ihr das bei uns wieder so umsetzen?
Danke für die Infos @tcatm!
Grüße
Matthias
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.
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…
Also müssten wir sie nicht nur wieder auf authorative stellen, sondern auch noch die Relays konfigurieren…
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.
Danke! Hoffen wir mal, dass es besser wird.
Zusammenfassung:
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.
Vielleicht ist unser Problem, dass sie nicht miteinander sprechen? Die sind doch in einem L2, also könnte man mit einem Relay arbeiten?
So wie ich es verstanden habe, macht das theoretisch nichts, weil Batman die Anfragen eh nicht durchlässt und nur zu einem leitet.
Viel interessanter ist, dass laut der neuen Auswertungen die Pools auf ungefähr N-100 voll sind. Das sieht mir eher nach einem Problem aus.
Genau identisch konfiguriert wäre schlecht, sie sollten jeweils einen eigenen Pool haben aus dem sie verteilen.
Da Batman DHCPv4 Anfragen ausschließlich zum gewählten gw durchläßt muss auf jedem Gateway auch ein solcher dhcp Server laufen.
Bei uns: 10.134.0.0/16
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.
Bei uns hat jedes Gateway ein /21.
@descilla hat ein Skript geschrieben, dass die Daten ins collectd schmeißt: https://github.com/FreiFunkMuenster/ansible-ffms/blob/master/roles/collectd/templates/dhcp.py.j2
Die Auswertung sieht man hier: https://freifunk-muensterland.de/grafana/dashboard/db/gateway-ubersicht
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.
Ich hab mal noch eine Frage dazu, wie man DHCP-Server richtig miteinander kommunizieren lassen kann.
Betrachten wir mal diese Anleitung: http://consultancy.edvoncken.net/index.php/HOWTO_Configure_DHCP_failover
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.