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.
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!
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.
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.
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.
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.
Ich glaube an die Deutsche Bank. Ein neuer, identisch konfigurierter Server wird wohl genau so gut funktionieren wie der aktuelle. Aber gut …
Neue Beschlußvorlage:
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. Dazu nehmen wir einen anderen Server.
You may be wondering whether we recommend you migrate from ISC DHCP to Kea at this time.
Use Kea if you need higher performance
Use Kea if you are modernizing your infrastructure
Use Kea if you want a stateless DHCP architecture tied to your own provisioning system for device-specific information
Use Kea for your DHCP server needs
Continue to use ISC DHCP if
You need DHCPv4 failover (note that HA implementations of Kea are possible today using a HA database back end)
If you are using legacy interfaces
Da fällt die Entscheidung ja einfach (Use Kea if you need higher performance). Hoffentlich stimmt die Aussage mit der Performance noch, wenn die Software nicht auf dezidierter Hardware läuft, sondern mit einer gesunden Anzahl von anderen Anwendungen (insb. collectd, bind, …) um die Resource der Maschine kämpfen muss. Migration ist auch ein Klacks: apt-get install kea-dhcp4-server (zumindest unter ubuntu 16.04 wird dann 1.0.0-1build1 installiert.)
Passende Konfiguration müsste in 5min gemacht sein. In einer Testdomäne testen, und los!
Der ISC kea scheint schon das zu sein, was wir wollen. Aktuelles Stück Software, was wohl performt und relativ flexibel ist. Und falls das nicht reicht, kann man sich eigene Hooks bauen.
Das schöne an Kea: Man kann die Konfiguration umbauen ohne das Teil neustarten zu müssen.
Ein Beispiel für die Leistungsfähigkeit von Kea gibt Facebook, das vom ISC-DHCPD auf Kea umgestellt hat, um der dynamischen Natur der eigenen Infrastruktur gerecht zu werden. Damit betreibt das soziale Netzwerk einen Cluster virtueller DHCP-Server, die ihre Daten aus einem gemeinsamen IP-Adressenpool beziehen und ansonsten zustandslos arbeiten. […]
Kann Spuren von Fehlern enthalten, insb. weil es nur eine 1zu1 Übertragung ist, und nicht die möglichen Korrekturen (NAK für nicht verwaltete Adressen innerhalb des subnetzes. Vielleicht verhält sich der kea abe anders.) von oben enthält.
Folgendes läuft (Hab mir zwei kvm-guests gebastelt und ausprobiert…):
# This is a basic configuration for the Kea DHCPv4 sever.
# Subnet declarations are commented out and no interfaces are listed.
# Therefore, the servers will not listen or respond to any queries.
# The basic configuration must be extended to specify interfaces on
# which the servers should listen. Also, subnets and options must be
# declared.
{
# DHCPv4 configuration starts here.
"Dhcp4":
{
# Add names of interfaces to listen on.
"interfaces-config": {
"interfaces": [ "ens9" ]
},
# Use Memfile lease database backend to store leases in a CSV file.
"lease-database": {
"type": "memfile"
},
# Setup reclamation of the expired leases and leases affinity.
# Expired leases will be reclaimed every 10 seconds. Every 25
# seconds reclaimed leases, which have expired more than 3600
# seconds ago, will be removed. The limits for leases reclamation
# are 100 leases or 250 ms for a single cycle. A warning message
# will be logged if there are still expired leases in the
# database after 5 consecutive reclamation cycles.
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
# Global (inherited by all subnets) lease lifetime is mandatory parameter.
"valid-lifetime": 4000,
# Below an example of the simple subnet declaration. Uncomment to
# enable it. This is a list, denoted with [ ], of structure, denoted
# with { }. Each structure describes a single subnet and may have
# several parameters. One of those parameters is "pools" that is
# also a list of structures.
"subnet4": [
{ "subnet": "10.43.80.0/21",
"option-data": [
{ "name": "routers",
"code": 3,
"space": "dhcp4",
"csv-format": true,
"data": "10.43.80.4" },
{ "name": "domain-name-servers",
"code": 6,
"space": "dhcp4",
"csv-format": true,
"data": "10.43.80.4" }
],
"pools": [ { "pool": "10.43.85.0 - 10.43.87.254" } ] }
]
},
# Logging configuration starts here. It tells Kea servers to store
# all log messages (on severity INFO or more) in a file.
# debuglevel variable is used on DEBUG level only.
"Logging":
{
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/var/log/kea-dhcp4.log",
"maxver": 4,
"maxsize": 204800,
"flush": true
}
],
"severity": "DEBUG",
"debuglevel": 99
},
{
"name": "kea-dhcp4.leases",
"output_options": [
{
"destination": "syslog",
"output": "syslog"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
]
}
}
Und, hihi, NAK für nicht verwaltete Adressen innerhalb des subnetzes. Wird bestimmt besser klappen, weil hier was default ist, was im isc-dhcp-server configuriert werden muss… Jetzt wird alles gut…
Geile Sache. Für meinen Geschmack können wir das gerne real auf einem Gateway testen. Ich würde direkt auf einem Gateway alle Domänen darüber abwickeln. Zurück können wir jederzeit.
Ist Datenbank schneller? Also ich würde mich auch noch länger mit dem Ding beschäftigen. Insbesondere was Debuggen und Loggging angeht. Im Ubuntu ist keactrl nicht paketirt. Ihr wollt also lieber ein Ding einsetzen, mit dem ihr euch noch nie beschäftigt habt, als das Problem in der Konfiguration zu fixen? Dann mal los! Bei Problemen gibt es bestimmt Hilfe im großen Forum.
Robuster und schneller, zumindest bei größeren Leasefiles. das ist doch eine der (vermuteten) Ursachen für die Probleme beim ISC-DHCPd.
Wenn gewünscht: Postgres kann ich in 5 Minuten aufsetzen, da habe ich viel Übung.
KEA Doku „Larger deployments may elect to store leases in a database. Section 7.2.2.2, “Lease Database Configuration” describes this option. In typical smaller deployments though, the server will use a CSV file rather than a database to store lease information.“
Dann wäre es ja schon zu sehen, ob das beim kea auch eine Ursache werden könnte. Ich glaube nicht, dass es sich hier um ein „Larger deployment“ handelt.
