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.
Das wird noch ein paar Tage dauern; der Plan ist, die auf github abzulegen (inkl. poll-Skript), die Key-Files – nachvollziehbarerweise – allerdings rauszufiltern. Das Ganze soll dann auch als Config-Archiv für uns dienen. Wobei die Config-Files ohne das puppet-Geraffel nicht viel nützen werden, fürchte ich.
nochmal eine Rückmeldung und einen Tipp für alle: @descilla hatte die Idee, das DHCP-Leasefile in eine Ramdisk zu legen, da wir unerwarteter Weise doch teilweise viel ioload hatten.
Das hat die Load auf dem ganzen System deutlich gesenkt und DHCP läuft jetzt richtig gut. Der Durchsatz in der großen Münsterlanddomäne ist zwar nicht optimal, aber wenigstens bekommt man jetzt ziemlich zuverlässig eine IP.
Wir haben in Kiel (gluon mit 7 Debian Gateways) unsere Zeiten jetzt viel kürzer gesetzt:
default-lease-time 60;
max-lease-time 300;
Ausserdem schalten unsere gateways mit einem watchdog den batman-gatewaymode aus, wenn der openvpn abstürzt, damit sie keine neuen IPs mehr rausgeben.
Dann braucht man nicht mehr 1h warten, wenn ein GW mal der openvpn ausfällt oder sonst der gw Mode mal aus geht, z.b. Wenn man maintenance machen will.
Es war sonst oft so, daß man mir einer zugewiesenen IP nicht mehr ins Internet kam, wenn das gw, das die zugewiesen hat, keinen Pfad ins Internet mehr anbot
Also nach 300s wird einem dann die IP, die man hat erneut zugeteilt, wenn alles beim alten ist, Ich glaube: nach 150s fragt der client nach, ob er die behalten soll, und falls er zwischendurch das GW gewechselt hat, dann nach 300s kriegt er dann ne neue IP vom neuen gatewaydadurch ist man bei openvpn-absturz max. 2,5 minuten ohne gültige IP.
bisher ist man dann bis zu 60 min. ohne gültige IP, bis sich das wieder klärt. daher kamen viele Beschwerden, wenn mal ein openvpn nicht funzte.
Ausserdem verbessert das das Roaming zwischen Knoten, die beide einen Uplink aber zu verschiedenen Gateways haben.
Ich habe den verddacht, dass das ein Problem in allen communities ist, das dadurch verbessert wird., oder?
In der Theorie klingt das gut. Wir hatten mit dem ISC immer das Problem, dass der davon völlig überlastet ist. Allerdings sehe ich keinen Vorteil darin, wenn ein Gerät bei einem Gatewayausfall nur wenige Minuten statt einer Stunde offline ist. In so einem Fall hilft nur kurz das WLAN auszuschalten.
Der Grund für diesen Beitrag: Wir haben inzwischen auf Kea umgestellt. Der läuft stabiler und liefert die Adressen zuverlässig aus.
pro Broadcastdomäne (max. 600 Clients oder so) 2 - 4 Gateways, Router bauen zu jedem Gateway eine fastd oder l2tp Verbindung auf (das GW bestimmt was es annimmt, l2tp ist erst ab einer späteren Firmware möglich, fastd ist fallback wenn entweder Router zu alt oder GW kein l2tp spricht). Gateways announce eine Bandbreite per batctl gw_mode server xxMbit. Router wählen damit das Gateway aus das am meisten Bandbreite announced, damit ist im gewissen Maße auch ein Loadbalancing möglich (wenn Server ausgelastet announced er kaum mehr Bandbreite, dann gehen die Clients zu einem anderen). Auf fast allen GWs läuft der isc (mir ist zumindest nichts anderes bekannt).
Klappt ganz gut erst wenn die Leasefile riesig wird (wächst nach und nach an mit uralten Einträgen) wird das ganze immer zäher, daher lösche ich auf meinen Gateways regelmäßig die Leasefile um sie klein zu halten dann gibt es keine Probleme. IPs bekommt man eigentlich immer <10s.
seitdem funktioniert es einwandfrei, man muss nur bedenken das auch die Metrik mit einfliest da aber bei einer fastd/l2tp Verbindung die Metrikt eh fast immer 255 ist, fällt das nicht ins Gewicht (obwohl es berechnungstechnisch sehr wohl stark mit einfliest, siehe Patch oben da ist die Formel ersichtlich wie sich das berechnet) und es wird zuverlässig das GW ausgewählt das die höchste Bandbreite announced.
Bisher nicht. Wir sind am Überlegen, das zu tun. Aber wir wollen auch eine gewisse Ausfallsicherheit. Bisher ist es einfacher, wenn einfach zwei getrennte Bereiche hat, für jedes Gateway einen. Eine ausfallsichere SQL-Datenbank, die synchronisiert auf zwei Servern läuft, haben wir noch nicht.
Soweit ich weiß nicht.
Ich glaub @descilla hat da was für unsere Statistik gebaut.
Insgesamt haben wir knapp 2800 Knoten (davon mehr als 2000 mit VPN/l2tp), in der Tagesspitze. Und typischerweise Nachmittags/Abends mehr als 8000 Clients, die gleichzeitig online sind. Teilweise sogar bis zu 9500 Clients, die gleichzeitig online sind. Diese Teilen sich auf 8 Gateways bzw. 63 Layer2-Broadcastdomänen auf.
Im inserem Grafana-Frontend findest du Clients und Knoten nach Domänen aufgeschlüsselt: Maximal sind also knapp 300 Knoten in einer Domäne (diese müssen wir noch unterteilen, bzw. neu strukturieren) und bis zu 1000 Clients in einer Domäne gleichzeitig online.
Wir hatten diese Probleme damals auch, allgemein die Load auf den Gateways ging durch die Decke. Wir haben dann das Leasefile in eine tmpfs („ramdisk“) gelegt. Das hat eine signifikante Besserung gebracht. Die Konfiguration findest du in unserem Ansible-Repo. (Anmerkung: Unsere isc-dhcp-server Konfiguration ist an einer stelle nicht gut. Es wird nicht mit einem NAK geantwortet (sondern gar nicht), wenn ein Client einen DHCPREQUEST startet mit einer Adresse, die zwar im subnet range ist aber nicht im Pool der isc-dhcp instanz. Die erforderlichen Anpassungen findest du hier. Wir haben das nicht gefixt, weil wir auf isc-kea umgestiegen sind und es dort das standardmäßige Verhalten ist.
1.1.0 (selbst gebaut, da Debian, da dort die Version etwas hinterher)
Noch nicht. Um bei dem Umstieg von isc-dhcp-server auf isc-kea das Debuggen etwas zu vereinfachen, habe ich mich erstmal für die Variante „memfile“ entschieden. Es ist aber angedacht sich zumindest mal damit auseinanderzusetzen.
Nein. Aber ich habe schon mal ein wenig durch die Section der Dokumentation gelesen. Es ist echt unfassbar krass, was da alles geht. KEA ist echt eine eierlegende Wollmilchsau.
Wir hatten einige Probleme mit unserer isc-dhcp-server Konfiguration. Die hätten wir sicherlich auch in den Griff bekommen, wenn wir uns da reingefuchst hätten. Wir wollten aber keine weitere Energie in ein „totes Pferd“ stecken und haben uns daher dazu entschieden auf KEA zu setzen. Überraschenderweise lief alles bereits nach der ersten Konfigurations-Iteration, dass wir bisher noch gar keine weiteren Reviews unserer Konfiguration gemacht haben. Die Konfiguration (via ansible) findet ihr im Übrigen hier. Falls ihr Verbesserungsvorschläge habt: immer her damit.
PS: Und hier findest du unsere Ansible rolle, mit der wir das Teil bauen (du siehst, wir haben das PostgreSQL feature direkt mit eingebaut).
Du musst in der Konfiguration einen „control-socket“ definieren (siehe hier, bzw. KEA Doku Section 7.8). Ich habe mir ein kleines Python-Script gebaut, mit dem ich mir eine „schönere“ Ausgabe erstelle als wenn ich direkt auf den Socket gehe. Ich habe das mal nach gist geschoben: klick Es könnte aber sein, dass das zu einem gewissen Teil konfigurationsspezifisch ist. Wir haben auch ein Script, dass uns das mittels collectd ins graphite/grafana (unterste Reihe) schiebt. Leider ist da noch etwas komisch: Der „assigned-addresses“ value wächst einige Zeit an, fällt dann wieder ab, wird dann negativ und immer weiter negativ. Entweder ich habe diesen Wert bisher falsch interpretiert oder dieser Bug wurde doch nicht mit KEA 1.0.0 gefixt. Leider habe ich derzeit akuten Zeitmangel und konnte dem noch nicht nachgehen.
– allerdings rauszufiltern. Das Ganze soll dann auch als Config-Archiv für uns dienen. Wobei die Config-Files ohne das puppet-Geraffel nicht viel nützen werden, fürchte ich.
