[Freifunk-Bonn] Paul in panic

[Jan Lühr]

Hallo,

erstmal danke für Deine Mühe und die ausführliche Info. Kommentare siehe unten.

Am 20.06.2012 um 01:15 schrieb Daniel Meißner:

> nachdem wir wieder recht viel an unserem Exit umher gebaut hatten, kam
> ich heute auf die verwegene Idee, Paul mal neu zu starten. Immerhin
> hatten wir bereits eine Uptime von über 100 Tagen und es musste eh mal
> geguckt werden, ob unsere Änderungen reboot-fest sind. 
> 
> Mal wieder ist uns das testing auf die Füße gefallen [1]. Aber auch iLO
> und das selbst gebaute initramfs mochte wieder angepasst werden.
> 
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676360
> 
> Ich möchte daher noch mal an alle appellieren, wenn wir wieder
> Server Systeme irgendwo installieren, ist aus meiner Sicht alles außer
> oldstable und stable nicht für uns vertretbar. Ich weiß, dass Paul hier auch eine
> gewisse Sonderstellung hatte, da wir nicht wussten, wann die Hardware wo
> online geht und wann wir das nächste Mal wieder darauf Zugriff haben
> werden.

Sehe ich ähnlich. Was machen jetzt am besten mit Paul? Downgrade oder ausharren?


> Der weitere Plan sehe bei mir jetzt so aus, dass wir den Fallback zu
> VPN3 irgendwie finalisieren. Also DHCP und DNS so konfigurieren, dass
> die Gegenseite im Zweifel automatisch übernimmt und Felicitas
> priorisiert wird.

Das sollte aktuell geschehen. Auf VPN3 laufen DHCP und DNS. Einerseits ist DHCP "non-authoritive" so, dass Paul bevorzugt wird, andererseits liefert vpn3 sich selbst als DNS aus, so das alles weiterhin funktioniert.
Sind bei einem Ausfall von Paul Klienten mit dem KBU-Netz verbunden, so verlieren sie ihre Konnektivität bis zum nächste reconnect oder DHCP-Request. Grundsätzlich sind auch andere Strategien denkbar (z.B. Übernahme einelner IPs), aber dies ist relativ aufwendig.


> Thema IPv6 ist so umgesetzt wie wir das besprochen hatten, Jan. Das
> Routing innerhalb des FF-Netzens funktioniert allerdings noch nicht so
> wie es sollte. Extrem viel Packet-Loss und das Ganze ist auch noch
> nicht abgesichert in Bezug auf sysctl options. Wäre schön, wenn sich
> hiermit noch mal jemand beschäftigen könnte, der IPv6 schon mal öfter
> deployed hat als zum Beispiel ich.

Das Absichern der Sysctl-Optionen ist imho eher eine XEN-Problematik. Ich finde das - wie gesagt - aktuell aber auch kein wirkliches Problem.
Die Packet-Loss können wir auf jeden Fall debuggen - er sollte nicht IPv6-spezifisch sein - mglw. ein Seiteneffekt der Tinc-Config DirectOnly.

Alles Gute
Jan