ISC-DHCP Bug Leasefile löschen

Technik Infrastruktur / Backbone
1

Moin,

ich weiß, dass solche Lösungen hier nicht gerne gesehen sind, aber ich halte es einfach für einen Bug, dass der dumme isc-dhcp-Server solche Einträge ewig aufbewahrt. Daher schlage ich hiermit vor, die Leasefiles um 5 Uhr morgens zu löschen und die Server durchzustarten. Es kann einfach nicht sein, dass man teilweise 30 bis 50 Sekunden auf eine IP warten muss, nur weil wir keinen vernünftigen DHCP-Server am Start haben. Beispiel

lease 10.43.248.251 {
  starts 0 2016/08/28 18:24:01;
  ends 0 2016/08/28 18:26:01;
  tstp 0 2016/08/28 18:26:01;
  cltt 0 2016/08/28 18:24:01;
  binding state free;
  hardware ethernet [Datenschutz];
  uid "\001\366\362m\"9\225";
  client-hostname "android-248bf518561479af";
}

Der Eintrag ist jetzt fast elf Tage alt. Es ist einfach nutzlos, das aufzubewahren. @descilla hat zwar recht, dass die Lease-Dateien relativ schnell wieder auf 32k anschwellen, aber das ist immer noch besser als teilweise 170k, also nur noch gut ein Sechstel.

root@remue-ansible ~/ansible-ffms # ansible -i hosts gateways -m shell -a 'cat /var/lib/dhcp/dhcpd.leases|wc -l'
c1024 | SUCCESS | rc=0 >>
109512

remue-08 | SUCCESS | rc=0 >>
54368

parad0x | SUCCESS | rc=0 >>
173828

greyworm-06 | SUCCESS | rc=0 >>
41587

fanlin | SUCCESS | rc=0 >>
91866

rhe | SUCCESS | rc=0 >>
39790

des1 | SUCCESS | rc=0 >>
91334

ausrufer | SUCCESS | rc=0 >>
174618

barristan | SUCCESS | rc=0 >>
812

Vorschlag:

0 5 * * * systemctl stop isc-dhcp.server; rm /var/lib/dhcp/dhcpd.leases*; systemctl start isc-dhcp.server

Zu der Zeit haben wir meist relativ wenige Clients und die Vergabe mehrfacher IPs ist relativ unwarscheinlich.

@Adminteam

Diese Maßnahme hab ich vorhin auf den Gateways der Domäne 01 mal gemacht und da hab ich sofort wieder richtig eine IP bekommen. Nicht erst nach knapp einer Minute.

Grüße
Matthias

1 „Gefällt mir“
2

Google hat mir gerade noch das ausgespuckt, das sollten wir mal aufnehmen: https://ffm.freifunk.net/2015/05/12/dauer-bis-zum-erhalts-eines-dhcp-leases/

3

Angeblich soll das Ding das Leasefile stündlich aufräumen, tut er aber nicht: http://serverfault.com/questions/625619/isc-dhcp-leases-file-never-cleaned

Man findet mega viele Einträge zu exakt diesem Problem.

4

Ich denke oftmals in Domäne01 dass es ein DHCP Problem gibt. Im Hinterkopf weiss ich aber dass es u.u oft recht lange dauert und andersrum die IP Adressen für Münster auch knapp sind und es dann manchmal auch gar nichts mit IPs wird.
Letzteres lässt sich ja nur durch größere IP Bereiche lösen…

Stehe auch dazu dass die IP vergabe ein paar Sek. Schneller sein dürfte :slight_smile: da bin ich gleicher Meinung

5

Mein Vorschlag ist weiterhin den DHCP Server zu wechseln.

2 „Gefällt mir“
6

Von mir aus gerne. Bin da echt für Experimente offen. Von @stefan6 höre ich mir seit ein paar Tagen an, wie scheiße dnsmasq ist. Der hat zwar immerhin theoretisch einen Relais-Modus, aber so richtig redundant ist das nicht.

Ich hätte total gerne den D-DHCP-Server, aber der ist noch nicht einsatzbereit.

Du hattest mal einen vorgeschlagen. Den könnten wir mal auf ein Gateway werfen?

Grüße
Matthias

7

Hört mir bloß mit dem Ganzen DHCP Kram auf. Dnsmasq idt wohl seit Jahren buggy. Ich hab mir die Nacht um die Ohren gehauen und nun kommt ihr mit sowas hier… spass, bislang läuft die IP Vergabe bei uns wesentlich schneller.

Ist das Problem mit dem Leasefile auf jedem Gateway bei euch?

8

Ja, oben ist die Übersicht. Bei uns laufen auf den Gateways aber auch immer sehr viele Domänen.

Grüße
Matthias

9

Ja, KEA

https://www.isc.org/kea/

10

Ohh sogar mit “vernünftiger” Database (also besser als Textfile). habenwill

11

Wow, da schreibt jemand echt 2016 noch concurrent networking Kram in C. Offenbar ein Masochist. :slight_smile:

Ich habe irgendwie Zweifel das die Verwendung von link local multicasts eine weise Entscheidung ist.

12

Vernünftige DB für den Zweck wäre IMHO Redis gewesen. :slight_smile:

Wenn ich einen Wunsch habe: Bitte Postgres und nicht mysql wg. Sanity.

1 „Gefällt mir“
13

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“
14

Daher in Anführungszeichen. :wink: 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“
15

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… :stuck_out_tongue:

16

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.

17

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“
18

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?

19

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“
20

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“