Ja, oben ist die Übersicht. Bei uns laufen auf den Gateways aber auch immer sehr viele Domänen.
Grüße
Matthias
Ohh sogar mit “vernünftiger” Database (also besser als Textfile). habenwill
Wow, da schreibt jemand echt 2016 noch concurrent networking Kram in C. Offenbar ein Masochist. 
Ich habe irgendwie Zweifel das die Verwendung von link local multicasts eine weise Entscheidung ist.
Vernünftige DB für den Zweck wäre IMHO Redis gewesen. 
Wenn ich einen Wunsch habe: Bitte Postgres und nicht mysql wg. Sanity.
1 „Gefällt mir“
Wenn man es analysieren will (in Warendorf lief das immer ohne Probleme) kann man das Setup ja auch mal vereinfachen. Der ISC läuft fast überall, und wenn er hier nicht tut, dann ist es ein Problem im setup.
Der Eintrag oben, mit dem elf Tage alten Eintrag hat kann seine Berechtigung haben. Da steht „binding state free;“. Wenn das der letzte Eintrag zu der IP ist, dann ist es wohl die Weise wie das Ding sich merkt, dass die IP frei für die Vergabe ist.
Wenn ich die Manpage zu dhcpd.conf lese, insb. den Teil unter Dynamic Address Allocation, dann kann ich mir denken, dass die IP-Vergabe schon mal länger dauert.
Ich bin in client. Ich komme in ein Netz Freifunk. Ich frage nach ein Adresse (DHCPDISCOVER) und bekomme Adresse A zugewiesen. Prima. Ich werde vom Netz getrennt, komme wieder in ein Netz Freifunk. Ich verlange nach der gleichen IP-Adresse (DHCPREQUEST). Dummerweise weiß der DHCP-Server den ich jetzt befrage nichts von dem Netz (wegen batman gw-mode uns so): er antwortet nicht. Er wartet auf ein DHCPDISCOVER, dass der Client dann schließlich auch schickt.
Würden beide DHCP-Server jeweils das ganz Netz kennen, dann würde ein DHCPREQUEST für eine nicht verfügbare Adresse gleich zu einem DHCPNAK führen, und niemand müsste auf ein Timeout warten.
Richtiges Setup wäre also:
Server A:
subnet 10.48.8.0 netmask 255.255.248.0 {
interface bat33;
option interface-mtu 1280;
option domain-name "ffms";
option domain-search "ffms";
pool {
range 10.48.8.16 10.48.11.255;
option routers 10.48.8.2;
option domain-name-servers 10.48.8.2;
allow unknown-clients;
}
pool {
range 10.48.12.0 10.48.15.254;
option routers 10.48.8.3;
option domain-name-servers 10.48.8.3;
deny unknown-clients;
}
}
Server B:
subnet 10.48.8.0 netmask 255.255.248.0 {
interface bat33;
option interface-mtu 1280;
option domain-name "ffms";
option domain-search "ffms";
pool {
range 10.48.8.16 10.48.11.255;
option routers 10.48.8.2;
option domain-name-servers 10.48.8.2;
deny unknown-clients;
}
pool {
range 10.48.12.0 10.48.15.254;
option routers 10.48.8.3;
option domain-name-servers 10.48.8.3;
allow unknown-clients;
}
}
Schätze ich zumindest. Aber dieses KEA schau ich mir auch mal an…
1 „Gefällt mir“
Daher in Anführungszeichen. 
Ohne genauer die Anforderungen zu Prüfen, scheint mir jedoch alles mit SQL im Namen performanter als dieses auf der Platte herum gekratze vom isc-dhcp.
Wenn ihr euch gedulden könnt, erkläre ich mich bereit das ab der Woche des 26.09. zu testen und deployen.
PS: Ich halte vom “irgendwelche Cronjobs löschen irgendwas, weil irgendwas sonst nicht korrekt funktioniert” mal so gar nichts (außer als kurzfristige, temporäre Lösung). Man tritt sich typischerweise irgendwelche anderen Probleme damit ein und das Debuggen ist dann auch fürn Arsch.
3 „Gefällt mir“
Der erste Kommentar auf:
PS: Ich dachte immer, dass ein NAK gesendet wird im Falle, dass DHCP authorativ und Request außerhalb von Range. Man lernt nie aus… 
Du hattest aber gelesen, dass das Ding auf den Gluonroutern laufen soll, oder? Das erste D steht für distributed. Da geht nichts anderes als C, höchstens noch Lua und Lua kann so niedrige Protokollschichten auch wieder nur durch C-Bibliotheken. Das geile daran wäre, dass die IP-Vergabe endlich so schnell wäre, wie bei normalen WLANs, weil sie nämlich vom Accesspoint bzw. dem Knoten direkt erfolgt. Und dann auch funktioniert, wenn das Gerät offline ist, also mal so richtig Freifunk und so.
Jein, ein anderes Freifunknetz wäre kein Problem. Wenn die angefragte IP außerhalb des Subnetzes liegt, fliegt sofort ein NACK zurück. Problematisch ist, wenn der Client in dasselbe kommt, aber beim anderen Gateway landet. Aufgrund der räumlichen Nähe der Knoten aus demselben Netz, ist das leider der deutlich wahrscheinlichere Fall.
Genau das wurde auch in dem Link in meinem zweiten Beitrag beschrieben, das sollten wir übernehmen, falls wir weiterhin ISC nehmen wollen.
Interessant finde ich dort in der Tabelle, dass laut deren Angaben ISC Failover können soll. Davon ist mir noch nichts über den Weg gelaufen.
Da würde ich immer über „zentrale“ DHCP-Server nachdenken, zu denen die Anfrage relayed werden. Klappt halt nur, wenn relay-Agent via ethernet angeschlossen ist. Aber wozu gibt es gre-tap … Dann hätte man immer noch das Thema mit dem „Quertraffik“, dass ich lösen würde, in dem die l2tp-clients sich bitte schön immer alle auf einen broker verbinden sollen, und ein zweiter nur das backup macht, aber das ist ein anderes Thema. Das mit der Redundanz ist halt eine schöne Idee, wenn es funktioniert…
1 „Gefällt mir“
Also dnsmasq kann das, aber der kann kein richtiges Failover. Denn ein zentraler Server wäre mir zu wenig, wenn würde ich zwei aufsetzen wollen, die gegenseitig für einander einspringen können und die vergebenen Leases austauschen. Wenn wir wieder nur die Bereiche aufteilen, verschieben wir das Problem nur.
Wir brauchen ein Programm, dass auf zwei Servern läuft und aus dem gesamten Bereich vergibt und sich aber mit dem Partner abspricht. Ein Relais brauchen wir eigentlich nicht, weil warum sollte das nicht einfach auf den Gateways laufen?
Die Wahrscheinlichkeit innerhalb einer Domäne des Münsterlandes liegt wohl in der Nähe von 50%.
Steht ganz fett in der dhcpd.conf manpage. Unter Dhcp Failover. Funktioniert natürlich nur, wenn die Anfragen der Clients vom batman duch gw-mode server nicht abgefangen werden. Frage ist, ob/warum man gw-mode server machen will, wenn das ganze bei ipv6 ganz offensichtlich auch prima ohne funktioniert …
1 „Gefällt mir“
Ja, deswegen schrieb ich ja auch, dass ich über zentrale DHCP-Server nachdenken würde, und nicht, dass ich über einen zentralen DHCP-Server nachdenke.
Das klappt aber mit gw-mode server nicht, denn selbst wenn die beiden Server sich prima austauschen: ein client fragt via unicast immer den Server an, von dem es den lease hat. batman filtert das ganze weg (der eigene Server liegt ja auf einem anderen Interface), und schon wartet man wieder auf einen Timeout und ein folgendes DHCPDISCOVER. Mit dem Relay kannst das gw-mode server behalten, denn dann liegt der wahre Server ja immer auf dem eigenen Interface.
Aufbau:
client — Relay — [virtuelles kabel, auf dem zwei dhcp-server lauschen (auch bridge genannt)] — dhcp-server A und B.
Ist aber eine gre-tap Schlacht. Und man müsste auch über spanning-tree nachdenken. Alles ganz schön kompliziert (und fragil). Je länger ich drüber nachdenke, desto mehr tendiere ich dazu den gw-mode server abzustellen. Aber was für Konsequnzen hätte das für das restliche Netz?
Ach, noch ein Grund für Timeouts: “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.“ – Quelle: Man kann das einfach nicht oft genug lesen.
1 „Gefällt mir“
Ich verstehe nicht, welchen Sinn du im Relais siehst. Wir brauchen zwei Server, da sind wir uns einig.
Aber warum sollen die irgendwo hinter irgendwelchen GRETAP-Tunneln hängen? Warum dürfen die nicht einfach auf den beiden Gateways laufen? Welchen Vorteil versprichst du dir davon?
Spielen wir es mal durch:
Client holt sich eine IP → roamt
Fall 1: selbes Gateway, alles gut
Fall 2: anderes Gateway, Client geht vorerst weiter über das andere Gateway ins Netz. Nach Ablauf der Lease-Zeit fragt es die IP neu an.
Was soll jetzt passieren?
Idee 1: Das Gerät kann die IP behalten, aber das Standardgateway wird getauscht. Wobei das bei externen Verbindungen auch nicht viel hilft, da sich trotzdem die NAT-IP ändern würde. Also externe Verbindungen reißen dann eh ab. Idee taugt nichts.
Idee 2: Anfrage würde - wie auch immer - bestätigt, alles bleibt beim alten. Taugt nichts, falls Gateway 2 inzwischen offline ist. Wobei eine abgelaufene Leasezeit als Failover für das Defaultgateway auch brutal langsam ist. Nicht ideal, aber besser als das kaputte Gateway nochmal zu bestätigen. Die Idee taugt auch nichts.
Idee 3: Einfach ein komplett neues Lease vergeben. Das geht am schnellsten, wenn die alte vorher ein NACK bekommt. Das könnte man konfigurieren.
Ein Relais brauchen wir nicht und mir wird gerade klar, dass es auch echt egal ist, ob die ihre IP behalten oder tauschen müssen, weil 99,99% der Verbindungen eh extern sind und somit vom Gateway abhängen, was ausgefallen sein könnte.
Schlussfolgerungen:
- Die reine Vergabe der IPs muss einfach beschleunigt werden. Ob durch einen anderes Programm oder durch aufräumen der Leasedatei ist egal. Hauptsache schneller.
- Beim roamen sollte für die alte IP falls notwendig kurz ein NACK verteilt werden.
- Statt einen DHCP-Failover und eine Kopie der Leasedatei, bräuchten wir eine Anycast-Adresse als Standardgateway.
- DHCP-Server, die die Leases austauschen und gegenseitig bestätigen könnten, brauchen wir nicht.
Coole Diskussion, mir wird die Suppe langsam klarer.
Zu der Idee mit dem Abschalten des GW-Modus:
Dann würde das Netz mit den DHCP-Broadcasts geflutet, die würden dann plötzlich überall hinverteilt. Es gibt inzwischen auch einen Patch, der das für V6 aktiviert.
Die Idee ist auch, den Querverkehr zu unterbinden, das macht das Netz langsam. Und das ist auch der Grund, warum im Freifunk V6 langsamer ist als V4, weil bei zwei Gateways die Wahrscheinlichkeit für einen zusätzlichen Hop bereits 50% beträgt.
Grüße
Matthias
Du schriebst, dass es dir neu ist, dass der isc-dhcpd Relay kann. Im Zusammenhang mit gw-mode server erklärte ich, das Relay ein Lösung sein könnte, weil bei gw-mode server ein roaming ja nicht so einfach funktioniert.
Fall 1: selbes Gateway A, alles gut
Fall 2: anderes Gateway B, DHCPREQUEST (unicast) läuft in ein timeout, weil gw-mode server das im Zweife wegfiltert. Dann DHCPDISCOVER.
Da die Gateways verschiedene Pools nutzen, kann die IP-Adresse nicht behalten werden. Der Wechsel des default-gateways führt zum Abbruch aller externen Verbindungen. Im Gateway A verbleiben alle NAT Einträge in den Tabellen, bis sie via Timeout dort raus fallen. ipv6 läuft weiter, als wäre nix gewesen.
Bei gemeinsam genutzten Pools weiß Gateway B von dem Lease den Gateway A vorher vergeben hat. In der Implementierung von des Failover ist aber auch hinterlegt, dass die IP-Adressen gleichmäßig von beiden Servern verteilt werden. Das heißt bei eingeschaltetem gw-mode server: Gateway B beantwortet einen DHCPDISCOVER gar nicht, weil er sich mit Gateway A einig ist, das Gateway A antworten wird. Gateway A sieht das Paket aber nie, weil batman das Paket weg filtert.
Denke, dass der gw-server mode gar nicht dafür gedacht ist, wozu es hier benutzt wird: mit dem Ergebnis von oben, kann man gleich zwei vollständig verschiedene Netze nutzen. Die Aufteilung eines pools in einen range für A und einen range B ist im Prinzip überflüssig: IP wird gewechselt. Ob innerhalb eines Pools ist unerheblich.
Ein RELAY-Setup löst nicht alle Probleme, aber wie ich schrieb: Alles ganz schön kompliziert (und fragil).
Erinnerung: Wir machen das mit dem Mesh, damit die Clients ihre IP behalten können. Surfen kann man in deinem neuen Netz (Stateless Verbindungen). Youtube kommt mit so einem Netz wahrscheinlich auch gut zurecht (Buffer). Peer-to-Peer Anwendungen und Skype und co wahrscheinlich eher nicht. Meine Lieblingsanwendungen (ssh/openvpn) überhaupt nicht. Mir ist das daher durchaus nicht egal
Zu deinen Schlussfolgerungen:
- Der Grund für die Größe der Leasedatei, und ob das die Ursache, oder nur ein Symptom ist, wurde nicht untersucht. Einen anderen DHCP-Server zu nutzen kann also helfen, muss aber nicht.
- ip-wechel habe ich schon oben was zu gesagt.
- Zu der Idee mit der Anycast-Adresse… Eine MAC-Adresse diese bringt ein IP-Device durch ARP in Erfahrung: DHCP-Server sagt, mein default-router ist a.b.c.d., mach ich also einen broadcast. Antwort von zwei Geräten. Egal, falls mich das nicht schon durcheinander bringt. Ich schicke Paket an die MAC. Zwei Geräte leiten mein Paket weiter. IPv4 Paket wird von Gateway A und B weitergeleitet und jeweils genattet. An einem Server kommen zwei TCP-Syn Pakete an, die jeweils beantwortet werden und mich auch erreichen. Ich denke jetzt komme ich als IP-Geräte langsam durcheinander.
- du hast eine Möglichkeit zur Problembehebung schon ausgeschlossen.
Nochmal was zu den Konsequnzen, das gw-mode server abzustellen:
Was macht ein Knoten im Client-Mode, der einen Knoten im Server-Mode kennt? „DHCP requests issued by non-mesh clients will not be broadcasted by batman-adv but only sent to the chosen batman-adv gateway via unicast.“
Der Broadcast eines ipv4 Clients (das alle Clients in der lokalen Wolke sehen), durchläuft den mesh als unicast Paket bis zum Gateway.
Client-mode aus: Der Broadcast eines ipv4 Clients (das alle Clients in der lokalen Wolke sehen), durchläuft den mesh als broadcast Paket bis zu einem oder mehreren Gateway. Andere Clients bekommen das dank gluon-ebtables-filter-ra-dhcp aber nie zu sehen: „DHCP requests, DHCPv6 requests and Router Solicitations may only be sent from clients to the mesh, but aren’t forwarded from the mesh to clients“. DHCP request anderer Clients sieht man also nur, falls eines der Gateways, bzw. dessen batman, das Paket an das andere Gateway weiterleitet (normal), und der das Paket wieder zu den clients rausschiebt (doof, weil die Server nie requests senden sollten, denn die werden im mesh, weil da ja kein DHCP-Server steht, ja nie beantwortet). Ein potentielles Fehlverhalten, dass man mit ebtables einfach fixen kann.
Ich denke also nicht, dass das „Fluten“ ein Problem ist. Allerdings kann ich mir vorstellen, dass ein vergleichbares Feature für ipv6 die Sachlage nicht verbessert.
Querverkehr im ipv6: Daten vom Client werden zu Gateways A (l2tp), von da nach Gateway B (ip), von da ins Internet geschoben (default via bgp), kommen über Gateway B wieder rein (bgp metric), werden nach Gateway A (batman) und von da zurück zum Client (l2tp). Das wahrscheinlich der Standard-Fall. Wenn das das Netz langsam macht, dann ist die Verbindung zwischen Gateway A und B wahrscheinlich langsam. Außerdem sind mehr Hops auch immer mehr Latenz.
Bekommt man nur weg, wenn man das Netzwerk grundsätzlich anders designt, die Gateways A und B sehr nahe beieinander stellt, oder ein bisschen hier und da fummelt.
Wenn der Client schon mal nicht Gateway B als default-gw nutzen würde, wäre das schon ganz schön. Sollte man hinbekommen, wenn man dem Gateway A sagen würde icmp-ra von B nicht weiter zu leiten. Dann hätte man im Zweifel wenigstens nur noch Client->GW A->Internet->GW B->GW A. Ich hab da mal gegoogel und das hier gefunden.
Querverkehr im ipv4 ist das gleiche in Grün, wird aber weitest gehend mit dem gw-mode server verhindert, da Gateway A als Gateways genutzt wird, und genatettet Pakete auch dahin zurück kommen müssen. Kann man mit NAT66 aber auch für ipv6 haben.
Und ich sage euch: deswegen wird ipv4 immer obsiegen! I want NATs!
1 „Gefällt mir“
Aber wenn du deine SSH-Verbindungen über IPV6 aufbaust, kannst du roamen ;).
Du nimmst oben an, dass DHCP-Request von geroamten Clients ggfs. gefiltert werden, unten steht aber, dass sie als Unicast an das ausgewählte Gateway geleitet werden. Und genau da setze ich an und bin der Meinung, dass wir für die Anfragen aus dem falschen Pool aber dem richtigen Netz NACKs verteilen müssen. Das hattest du auch schon vorgeschlagen.
Man könnte mit viel Aufwand auch die interne V4 behalten, aber es bringt meiner Meinung nach nichts.
Es geht hier um ipv4 und dhcp.
Ich nehme an, dass DHCP-Requests on roamenden Clients vom batman am server (gw-mode server) gefiltert werden. Das kann unter anderem daher kommen, dass Konten (gw-mode client) die DHCP-Paket als Unicast an „ihren“ Server weiterleiten, der die Pakete ignoriert.
Ich schrieb, dass dies die einzige Möglichkeit sei, bei roamen nicht auf ein Timeout warten zu müssen.
Es sind verschiedene Varianten ausgeführt worden, wie das funktionieren kann. Deine Beschlußvorlage lautet:
Roamen in IPv4 und IPv4 insgesamt ist tot. Wegen der „Außenwirkung“ ist es jedoch wichtig, dass dennoch (und vor allem möglichst schnell) IPv4 Adressen vergeben werden. Wie das umgesetzt werden kann, ist irrelevant. Die einfachste und schnellste Variante im aktuellen Setup wäre es, die Fehlkonfiguration im aktuellen Aufbau zu beseitigen und auf NAKs zu setzen. Änderungen sind via assibell auszurollen.
Dann los!
PS
Bei der Variante
0 5 * * * systemctl stop isc-dhcp.server; rm /var/lib/dhcp/dhcpd.leases*; systemctl start isc-dhcp.server
bleibt die Hoffnung, dass systemctl start isc-dhcp.server dafür sorgt, dass eine /var/lib/dhcp/dhcpd.leases vorhanden ist, weil der Server sonst ggfls. gar nicht startet.
Und wenn ich mich mal selber zitieren darf…
Wir haben ja schon „zentrale“ DHCP-Server. Wenn man auf den Host-Servern jeweils eine Bridge, sagen wir „dhcp-lan“ anlegen würde, die jeweils ein gre-tap zum anderen Host hat, dann ist man schon fast fertig, wenn man vom allen client-Bridges da hinein relayen würde. Noch ein bisschen ebtables, so dass keine Pakete von den client-port zu client-port kommt, fertig.
1 „Gefällt mir“
Was genau würde man damit erreichen bzw. was wäre dann besser?
Ipv4 werden schneller und zuverlässiger verteilt. Vielleicht.