diff --git a/Brainstorming.md b/Brainstorming.md
index fa97be4..95e230d 100644
--- a/Brainstorming.md
+++ b/Brainstorming.md
@@ -47,4 +47,29 @@ Nutzen bei Hochverfügbarkeit
 Geplante Änderungen können zuerst auf passives System angewendet werden, bevor es aktiv geschaltet wird.
 * Bei Problemen kann auf das zweite System zurückgeschwenkt werden, sodass unerwartete Probleme nur zu wenigen Minuten Downtime führen. Das dann kaputte, passive System kann in der Zeit untersucht und repariert werden.
 
-Ja, an dieser Stelle wäre ein Testsystem die erste Instanz, aber auch danach können produktiv menschliche Fehler passieren. Ich bin da recht gut drin.
\ No newline at end of file
+Ja, an dieser Stelle wäre ein Testsystem die erste Instanz, aber auch danach können produktiv menschliche Fehler passieren. Ich bin da recht gut drin.
+
+
+## Benötigte Funktionalität
+
+Damit sich die Konzipierung und Umsetzung auch lohnt, soll hier geklärt werden, welche Anforderungen an eine hochverfügbare Firewall aus zwei Maschinen gestellt werden.
+
+
+### Failover bei Ausfall einer Maschine
+
+Wenn die aktive Maschine für die passive Maschine nicht mehr erreichbar ist, muss die passive Maschine aktiv werden.
+Diese Funktion kann mit `keepalived` erreicht werden.
+
+
+### Automatische Updates mit Sanity-Check
+
+Sobald eine passive Maschine mit ihrem Update dran ist, muss die aktive Maschine darauf achten, dass die passive Maschine das Update erfolgreich übersteht:
+
+* :1
+* Update durchführen
+* Neustart durchführen
+* Automatische Tests?
+* "Gesundmeldung" an der aktiven Firewall
+* Failover
+* GOTO 1
+