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!