Auf ICVPN-V4 verzichten und IP-Bereiche größer machen

paulinsche · 20. August 2016 um 11:18

Ich hatte schon mal wo geäußert, dass IPv4 für mich tot ist und nur noch lokal sinnvoll ist.

FanLin · 20. August 2016 um 14:01

ICVPN (derzeit auch noch v4) halte ich genauso erstrebenswert, wie ein Routing unserer Domänen untereinander (über die privaten IPs).
Alles andere ist, in meinen Augen, nicht mehr wirklich der Freifunkgedanke. (Jaja, ich weiß; der alte Fundi …)

descilla · 20. August 2016 um 14:23

Ich denke, dass selbst Twitter eher IPv6 macht, als das wir den ICVPN wieder aufbauen. Außerdem ist IPv4 für mich eine tote Technologie, in die ich möglichst keine Zeit mehr investieren möchte. Von daher bin ich dafür einfach die IP Bereiche zu vergrößern und damit auf die Möglichkeit zu verzichten sich an den ICVPNv4 anzuschließen, anstatt viel Energie und Zeit darin zu investieren es doch noch irgendwie mit einem beschränkten IPv4 Bereich hinzubekommen.

kgbvax · 20. August 2016 um 16:38

ICVPN ja aber warum das dann v4 sein muss verstehe ich nicht und halte es daher für überflüssig. Also +1 für @mpw s Vorschlag

void · 20. August 2016 um 21:56

Dass wir kein ICVPN machen liegt lediglich daran dass wir es bei früheren Anläufen nicht hinbekommen haben und es in letzter Zeit nicht angegangen wurde.

Ich bin klar dafür die Möglichkeit für das ICVPN auch für IPv4 zu erhalten da das immer noch ein integraler Bestandteil der Freifunk Gemeinschaft ist.
Überflüssig ist IPv4 dort nur wenn auch die anderen Teilnehmer des ICVPN kein IPv4 mehr verwenden.

kgbvax · 21. August 2016 um 08:40

Stimmt das wirklich?
Ich habe ICVPN nie erlebt und es auch nie vermisst.
Ich weiss auch nicht wofür man es bei v6 braucht.

FanLin · 21. August 2016 um 19:53

Kann sich ja ändern, wenn es mal funktioniert.

Meinst Du die globalen v6-Adressen? Die haben mit Freifunk recht wenig zu tun; die sind nur Teil eines unserer Services.

kgbvax · 21. August 2016 um 20:09

Ich sehe nicht warum ich noch ein Tunnel durch das öffentliche Internet bauen soll wenn ich die Dinge auch direkt im öffentlichen Internet erreichen kann. Du sagst das wäre nur ein Dienst. Genau, ist ICVPN auch. Und Internet ist weiterhin die Killer App

Vielleicht habe ich den Sinn von ICVPN nicht verstanden.
Ich dachte immer das dient dazu das man Dinge in einem FF Netz aus einem anderen FF Netz erreichen kann. Mit v6 braucht man dazu kein VPN/Router/BGP Sessions.
Kann man machen, ist aber nicht besser.

Irgendwas an Resourcen - die wir gerade gut gebrauchen können - daher zurückzuhalten da vielleicht irgendwann jemand was damit machen will finde ich nicht gut.
Wenn jemand v4 ICVPN machen will kann man die Adressen ja zurückholen, wir strukturieren das Zeug ja eh laufend um.

Ach so, Freifunk ist nur kaputtes v4 auf nicht routbaren Adressen? Hmm.

FanLin · 21. August 2016 um 20:12

Genau Das; zuzüglich kaputtem v6 …
Aber wir können den Schrunz ja auch abschalten und einfach Internetprovider werden.

kgbvax · 21. August 2016 um 20:18

Ich glaube diese Diskussion hat für uns beide das Ende des Machbaren erreicht

FanLin · 21. August 2016 um 20:20

descilla · 21. August 2016 um 21:26

Wir können es uns ja jetzt auch leisten ständig mal was umzubauen, um Vor- und Nachteile zu testen (dank Automatisierungen). Ein weiteres Argument gegen das ICVPNv4 Veto.

void · 21. August 2016 um 21:42

Das ICVPN ist ein direkter Interconnect zwischne den Freifunk Cummunities.
Hierzu gehört unter anderem auch die aüflösuung der internen TopLevel domains wie .ffms, .ffpb, …

Selbst bei verwendung von öffentlichen IPv6-Adressen auf beiden Seiten ist immernoch konsens dass dieser Interconnect direkt erfolgen soll.
Und längst nicht alle FF Communities haben öffentliche IPv6 Adressen aus den verschiedensten Gründen.

MPW · 22. August 2016 um 07:23

Der Punkt, den ich halt nicht verstehe: Wenn das so toll ist oder euch beiden so wichtig ist, warum ist das nicht längst konfiguriert?

Ich habe von Anfang an ganz offen gesagt, dass ich nichts davon halte und da keine Zeit investieren werde. Ihr beide habt genauso Zugriff auf die Server, macht es, wenn ihr Bock habt. Testen, dann ins Ansible und dann ist es ein für alle mal einsatzbereit.

Derzeit sind mir keine internen Dienste in anderen Communities bekannt, auf die man dadurch Zugriff bekäme. Ich stelle einfach mal eine These auf:

Wenn es mal einen tollen, internen Dienst geben wird, wird dieser auch per IPV6 erreichbar sein.

Und, wenn wir die drei Pakete, die da im Monat von unserer Community zu einer anderen gehen, nicht durch das FFRL-Backbone, sondern direkt verschicken möchten, dann können wir das immer noch rein für V6 machen.

Zu bedenken wäre noch ICVPN als Exitbackup, wenn der FFRL mal komplett ausfallen sollte. Ich bezweifle einfach, dass es eine Community gibt, die die 4 Gbit/s, die da derzeit so anfallen, ansatzweise übernehmen könnte. Daher halte ich das nicht für eine praktikable Lösung. Ich glaube eher, dass die Communities dann anfangen sich schnell VPN-Tunnel zu kaufen.

descilla · 11. Dezember 2016 um 22:33

Wir haben derzeit den Zustand, dass wenn eines von zwei Gateways einer Domäne wegbricht nicht mehr ausreichend viele IPv4 Adressen für die Clients (eine Stunde Lease Dauer) zur Verfügung stehen.
Das heißt Freifunk ist für viele Nutzer nicht mehr nutzbar.

Ärgerlich: Bei einem Ausfall eines Gateways sind gleich mehrere Domänen betroffen. Besonders ärgerlich: Das andere Gateway könnte den Ausfall problemlos kompensieren, wenn es denn genügend IPv4 Adressen verteilen dürfte.

Da wir derzeit kein ICVPN machen und man die Address-Konfiguration sehr schnell wieder ändern kann, wenn wir irgendwann dann doch vielleicht gegebenenfalls eventuell womöglich ICVPN machen, sehe ich kein Problem darin den gesamten 10.0.0.0/8 Space für Freifunk Münsterland zu verwenden.

Ich gehe sogar so weit: Ich denke es wäre noch nicht mal eine Abstimmung darüber nötig, da Niemandem zu keiner Zeit auch nur der geringste Nachteil dadurch entsteht. Gegenreden? (Falls ja werde ich es doch noch am kommenden Mittwoch zur Abstimmung einreichen, falls nein wird es einfach umgesetzt).

MPW · 11. Dezember 2016 um 23:31

Moin,

ich bin dafür, aber bedenke zwei Dinge:

Es wäre noch eleganter, wenn sich die beiden Gateways einen DHCP-Bereich teilen würden. Kea sollte das können, soweit ich mal gehört hatte.
Wir brauchen dafür eine neue Firmware, die auch nicht ohne weiteres mit der alten kompatibel ist. Das sollten wir mit einer Umstellung auf 11s kombinieren. Derzeit werden alle domänen-fremden IPs weggefiltert:

Bridge chain: FFPB_NET_ONLY, entries: 7, policy: DROP
-p IPv4 --ip-proto udp --ip-dport 67 -j RETURN
-p IPv4 --ip-src 10.43.128.0/21 -j RETURN
-p ARP --arp-ip-src 10.43.128.0/21 --arp-ip-dst 10.43.128.0/21 -j RETURN
-p ARP --arp-ip-src 0.0.0.0 --arp-ip-dst 10.43.128.0/21 -j RETURN
-p IPv6 --ip6-src fe80::/ffc0:: -j RETURN
-p IPv6 --ip6-dst ff00::/ff00:: -j RETURN
-p IPv6 --ip6-src 2a03:2260:115:1600::/ffff:ffff:ffff:ffff:: -j RETURN
(Domäne 16)

Man könnte auch dieses FFPB-Filterpaket rausnehmen. Dann wäre ein fließender Übergang möglich. Das soll aber angeblich das Grundrauschen erhöhen.

Grüße
Matthias

descilla · 12. Dezember 2016 um 09:51

Jo, KEA kann das. Musste aber halt ne echte Datenbank dran hängen. Das wollen wir ja auch machen, aber habe ich jetzt im ersten Schritt aufgrund der höheren Komplexität nicht gemacht. Außerdem muss man sich überlegen, wo man die DB-Server hinstellen möchte. Außerdem muss sichergestellt werden, dass ein Client ein anderes Default-Gateway bekommt, wenn sein Knoten an einem anderen Gateway als zuvor hängt. Das geschieht ja derzeit einfach indem wir das Lease als ungültig erklären.

Für mich schließen sich die beiden Dinge aber auch nicht aus.

Klar, man kann jetzt nicht einfach ein Knöpfchen drücken. Wir sollten uns am Mittwoch mal überlegen, wie wir die Adressen aufteilen wollen.

corny456 · 12. Dezember 2016 um 10:25

Grundsätzlich bin ich auch dafür die Bereiche zu vergrößern, zumindest längerfristig.
Wenn die beiden KEA Instanzen sich jedoch einen DHCP-Bereich teilen dann stehen doch jeder Domäne rund 2048 Adressen zur Verfügung. Ich hab grad mal in Dom01 geguckt, die kommt auf max 1000 Clients in der Spitze (bislang) oder meint ihr das die Adressen dennoch knapp werden könnten wegen der Lease-time?

Mir ist gestern Abend aufgefallen das der IP bereich bei Des1 wesentlich kleiner ist als bei Parad0x. Welchen Grund hat das? Würde es nicht mehr sinn machen diese 50/50 aufzuteilen? Dann wäre das Problem der Knappheit zwar nicht gelöst aber zumindest ein wenig minimiert…

Gruß Marius

MPW · 12. Dezember 2016 um 15:37

@descilla, ich hab die DHCP-Bereiche in der host_vars/des1 korrigiert. Kannst du das bitte mit Kea ausrollen? Mir ist nicht klar, welche der drei Rollen für die Gateways ist. Die Benennung entspricht nicht dem bisherigen Schema gateways_dienst.

descilla · 2. April 2017 um 17:44

Nachdem ich gestern auf einigen Kisten (dort, wo kea bereits psql nutzt) das collectd script angepasst habe, sodass wir jetzt einen Überblick über die leases pool utilization bekommen, ist mir heute direkt folgendes aufgefallen:

Über weite Strecken des Tages war der IPv4 Pool für Domäne-01 auf remue-09 aufgebraucht. Im kea log waren entsprechende Meldungen zu finden:

...
2017-04-02 15:06:45.260 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 f8:84:f2:xx:xx:xx], cid=[01:f8:84:f2:xx:xx:xx], tid=0x8eb1xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:08.721 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 e0:b5:2d:xx:xx:xx], cid=[01:e0:b5:2d:xx:xx:xx], tid=0xdcf7xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:44.595 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 9c:fc:01:xx:xx:xx], cid=[01:9c:fc:01:xx:xx:xx], tid=0x4998xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:45.852 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 dc:2b:2a:xx:xx:xx], cid=[01:dc:2b:2a:xx:xx:xx], tid=0xc7bexxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:47.473 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 9c:fc:01:xx:xx:xx], cid=[01:9c:fc:01:xx:xx:xx], tid=0x4998xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:47.806 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 dc:2b:2a:xx:xx:xx], cid=[01:dc:2b:2a:xx:xx:xx], tid=0xc7bexxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:52.980 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 9c:fc:01:xx:xx:xx], cid=[01:9c:fc:01:xx:xx:xx], tid=0x4998xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:53.537 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 a4:f1:e8:xx:xx:xx], cid=[01:a4:f1:e8:xx:xx:xx], tid=0xfbebxxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:54.315 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 24:f0:94:xx:xx:xx], cid=[01:24:f0:94:xx:xx:xx], tid=0xdf41xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:55.975 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 5c:2e:59:xx:xx:xx], cid=[01:5c:2e:59:xx:xx:xx], tid=0x3c92xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:56.275 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 b4:ef:39:xx:xx:xx], cid=[01:b4:ef:39:xx:xx:xx], tid=0xb71exxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:56.460 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 24:f0:94:xx:xx:xx], cid=[01:24:f0:94:xx:xx:xx], tid=0xdf41xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:56.582 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 fc:19:10:xx:xx:xx], cid=[01:fc:19:10:xx:xx:xx], tid=0xdfb9xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:57.735 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 a4:f1:e8:xx:xx:xx], cid=[01:a4:f1:e8:xx:xx:xx], tid=0xfbebxxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:59.726 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 b4:ef:39:xx:xx:xx], cid=[01:b4:ef:39:xx:xx:xx], tid=0xb71exxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:07:59.919 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 68:76:4f:xx:xx:xx], cid=[no info], tid=0x285bxxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:00.891 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 5c:2e:59:xx:xx:xx], cid=[01:5c:2e:59:xx:xx:xx], tid=0x3c92xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:01.016 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 e8:93:09:xx:xx:xx], cid=[01:e8:93:09:xx:xx:xx], tid=0x6793xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:04.837 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 68:76:4f:xx:xx:xx], cid=[no info], tid=0x285bxxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:08.471 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 5c:2e:59:xx:xx:xx], cid=[01:5c:2e:59:xx:xx:xx], tid=0x3c92xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:08.853 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 0c:77:1a:xx:xx:xx], cid=[01:0c:77:1a:xx:xx:xx], tid=0xade2xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:10.160 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 0c:77:1a:xx:xx:xx], cid=[01:0c:77:1a:xx:xx:xx], tid=0xade2xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:10.749 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 98:fe:94:xx:xx:xx], cid=[01:98:fe:94:xx:xx:xx], tid=0x8645xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:11.827 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 a4:f1:e8:xx:xx:xx], cid=[01:a4:f1:e8:xx:xx:xx], tid=0xfbebxxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:13.631 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 e8:93:09:xx:xx:xx], cid=[01:e8:93:09:xx:xx:xx], tid=0x6793xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:14.400 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 98:fe:94:xx:xx:xx], cid=[01:98:fe:94:xx:xx:xx], tid=0x8645xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:17.004 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 34:bb:26:xx:xx:xx], cid=[01:34:bb:26:xx:xx:xx], tid=0x903axxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:17.213 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 98:fe:94:xx:xx:xx], cid=[01:98:fe:94:xx:xx:xx], tid=0x8645xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:18.511 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 ac:ee:9e:xx:xx:xx], cid=[01:ac:ee:9e:xx:xx:xx], tid=0x41c2xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:20.225 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 a4:f1:e8:xx:xx:xx], cid=[01:a4:f1:e8:xx:xx:xx], tid=0xfbebxxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:20.837 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 34:bb:26:xx:xx:xx], cid=[01:34:bb:26:xx:xx:xx], tid=0x903axxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:22.036 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 b0:70:2d:xx:xx:xx], cid=[01:b0:70:2d:xx:xx:xx], tid=0xc214xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:23.704 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 b0:70:2d:xx:xx:xx], cid=[01:b0:70:2d:xx:xx:xx], tid=0xc214xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:26.881 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 b0:70:2d:xx:xx:xx], cid=[01:b0:70:2d:xx:xx:xx], tid=0xc214xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:27.162 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 a4:f1:e8:xx:xx:xx], cid=[01:a4:f1:e8:xx:xx:xx], tid=0xfbebxxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:28.005 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 dc:09:4c:xx:xx:xx], cid=[no info], tid=0x1baexxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:30.060 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 b0:70:2d:xx:xx:xx], cid=[01:b0:70:2d:xx:xx:xx], tid=0xc214xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:31.034 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 8c:f5:a3:xx:xx:xx], cid=[01:8c:f5:a3:xx:xx:xx], tid=0xa35dxxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:31.667 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 e8:93:09:xx:xx:xx], cid=[01:e8:93:09:xx:xx:xx], tid=0xdc38xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:32.148 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 b4:8b:19:xx:xx:xx], cid=[01:b4:8b:19:xx:xx:xx], tid=0x56acxxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:32.519 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 bc:44:86:xx:xx:xx], cid=[01:bc:44:86:xx:xx:xx], tid=0x1ff5xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:34.542 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 b4:8b:19:xx:xx:xx], cid=[01:b4:8b:19:xx:xx:xx], tid=0x56acxxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:35.799 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 bc:6c:21:xx:xx:xx], cid=[01:bc:6c:21:xx:xx:xx], tid=0xe141xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:36.699 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 a4:f1:e8:xx:xx:xx], cid=[01:a4:f1:e8:xx:xx:xx], tid=0xfbebxxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:36.887 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 e8:93:09:xx:xx:xx], cid=[01:e8:93:09:xx:xx:xx], tid=0xdc38xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:37.094 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 2c:ae:2b:xx:xx:xx], cid=[01:2c:ae:2b:xx:xx:xx], tid=0xc708xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:38.919 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 b0:70:2d:xx:xx:xx], cid=[01:b0:70:2d:xx:xx:xx], tid=0xc214xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:42.498 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 f8:23:b2:xx:xx:xx], cid=[no info], tid=0xb867xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:08:55.804 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 b0:70:2d:xx:xx:xx], cid=[01:b0:70:2d:xx:xx:xx], tid=0xc214xxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:09:24.855 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 84:38:38:xx:xx:xx], cid=[01:84:38:38:xx:xx:xx], tid=0x37acxxxx: failed to allocate an IPv4 address after 998 attempt(s)
2017-04-02 15:09:28.834 WARN  [kea-dhcp4.alloc-engine/7072] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 8c:f5:a3:xx:xx:xx], cid=[01:8c:f5:a3:xx:xx:xx], tid=0x472fxxxx: failed to allocate an IPv4 address after 998 attempt(s)
...

Zwar waren die l2tp connections nicht ganz gleichmäßig verteilt, aber auch auf des-2 waren für dom-01 nicht mehr so viele Leases verfügbar (etwa 300 von 1k).

Daher möchte ich dieses Thema erneut aufgreifen: Was wollen wir machen?

PS: Ich werde später die KEA Aktualisierungen auf alle verbleibenden Gateways ebenfalls ausrollen. Ich denke, dass das hier beobachtete kein Einzelfall ist.