Moin,
»auflösen« ist so eine Sache; jedes Gateway hat ja einen anderen Schlüssel. Wenn man die mit dem Schlüssel für “gw04-neu” ändert, kommen in der Zeit, in der DNS & Konfiguration nicht übereinstimmen, ggf. Knoten mit falschem Schlüssel an und werden somit nicht verbunden. Denke, ich ziehe eine neue VM hoch, die dann die drei “toten” fastds beinhaltet und dann schauen wir mal, was passiert.
Ciao,
-kai
Hallo,
das verstehe ich nicht. Hinter gw04.4830.org verbergen sich derzeit 4 IPs/GWs. Wenn man drei davon auf die ungenutzten DNS-Namen umhängt, was passt dann nicht?
und noch ein Bericht aus dem Feld: Ich war heute in der Concurens, der Router dort strahlte unsere SSID aus, und hat sogar IPs verteilt, man ist aber nach wenigen Sekunden wieder rausgeflogen. Das Dings war der Meinung an gw04 zu hängen (siehe Screenshots). Ich habe den Router dann restarted, und es hat sich an gw02 gehängt, nun war alles gut, ich konnte sogar einen speedtest machen.
fastd arbeitet ähnlich wie gpg oder ssh mit öffentlichen und privaten Schlüsseln. Jedes Gateway hat ein anderes Schlüsselpaar. Daher haben die 4 GWs hinter gw04[-neu].4830.org alle den Schlüssel für gw04 laut site.conf. Und somit ist es mit Umbiegen des FQDN nicht getan, die GWs müßten umkonfiguriert werden auf die Parameter der Zielgateways.
Hinzu kommt: das Setup ist, mit dem Wissen von heute, nicht zweckdienlich: es sind zwei Gruppen von GWs definiert, zu jeder Gruppe soll genau eine Verbindung gehalten werden. Heißt: zu jedem Knoten hätten wir dann in batman im optimalen Fall zwei Pfade, die Anzahl der Routen verdoppelt sich also. Wir hatten vor Jahren schon von 2 auf 1 Verbindung ins Mesh umgestellt, weil es a) viel Overhead mit sich brachte und b) der Failover nicht wirklich funktionierte. Ich habe daher die DNS-Einträge für die »Event-GWs« gerade deaktiviert, TTL ist 1h, mal gucken, ob das was bringt. Es wird nun wieder das Log vollgemüllt (das zu vermeiden war der Grund vor ein paar Monden, da Dummy-Einträge zu machen), aber hoffentlich erkennt fastd, daß mit der Gruppe kein Blumentopf zu holen ist (da kein FQDN aufgelöst werden kann).
Sollte sich die Situation nicht verbessern, würde ich als nächstes die Anzahl der GWs wieder verringern, sodaß hinter jedem FQDN nur noch 1 GW liegt. Die Performance im Netz wird dann aber wieder unterirdisch sein, da die 4 fastd-Prozesse die ~400 Knoten tagsüber nicht bedienen können. Es müßte dann schnell eine aktualisierte FW hinterhergeschoben werden, die für jedes GW 1 FQDN hat.
Nachtrag: Sinn der »Event«-Gruppe war es, bei bestimmten »Events« einfach Knoten z. B. an eine privates Netz klemmen zu können, in denen ein lokales GW werkelt. Das hat sich aber alles überlebt, die Crux an fastd ist seine Userspace-Existenz, selbst von einer Gluon-VM im RZ, die per virtiuellem Kabel über fastd mit einem unserer GWs kommuniziert, sind keine 100 MBit/sec drin:
Gluon-VM:
Mem: 19660K used, 883916K free, 108K shrd, 764K buff, 5224K cached
CPU: 12% usr 25% sys 0% nic 22% idle 0% io 0% irq 37% sirq
Load average: 0.33 0.10 0.03 3/48 26299
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
1713 1 root R 2996 0% 74% /usr/bin/fastd --config - --daemon --
Speedtest hinter der Gluon-VM:
root@33334-Wardialer:~# speedtest
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from PlusServer GmbH (192.251.226.69)...
Selecting best server based on latency...
Hosted by KamaTera INC (Amsterdam) [2.18 km]: 17.681 ms
Testing download speed........................................
Download: 87.43 Mbit/s
Testing upload speed..................................................
Upload: 74.20 Mbit/s
root@33334-Wardialer:~#
Man könnte meinen, jedes MBit/sec braucht 1% CPU … Und das ist nur 1 Client hinter dem virtuellen Knoten. Das tote Pferd hier ist fastd und es ist Zeit, abzusteigen.
Das verdichtet dann den Pointer auf »fastd & mehrere IPs pro FQDN kann man machen, ist dann aber scheiße« 
Ich habe also die Anzahl der IPs pro FQDN auf 1 reduziert:
wusel@ysabell:~$ for i in 1 2 3 4 ; do host gw0$i-neu.4830.org ; done
gw01-neu.4830.org has address 192.251.226.5
gw02-neu.4830.org has address 192.251.226.101
gw03-neu.4830.org has address 192.251.226.18
gw04-neu.4830.org has address 192.251.226.26
Dann mal Daumen drücken, die Entwicklung ist unschön
Hmm, interessant
Ich musss gerade fastd neustarten weil es scheinbar keinen Tunnel aufgebaut hat.
Vorfall:
Stromausfall -> Danach Start des Knotens, keone Verbindung -> Reboot -> immer noch keine Verbindung -> fastd restart; Verbindung wurde hergestellt.
komisch 
Dieses Thema wurde automatisch 10 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.
