TODOs:

* Metriken schaffen, die das Problem zeigen
    * Queues der Interface monitoren
        * netstat -nua zeigt ansteigende queue länge
        * siehe auch tc -s qdisc
        * https://collectd.org/wiki/index.php/Plugin:Netlink
    * anzahl der verbundenen clients monitoren?
        * in tabelle 104 aka. reverseroutes stehen Routen zu den VPN-Clients
            * Nach dem richtigen Netz greppen und wir haben alle VPN-Clients
* referenzclient pro vpn um latenz/jitter/loss zu ermitteln?
    * aus DC und hinter DSL XXX

# Problem definition
Der Datendurchsatz des VPN03-Service ist teilweise zu gering und es kommt zeitweise zu Paketverlust innerhalb der VPN-Verbindungen.
Die Ping-Zeiten sind relativ unterschiedlich (Jitter).

# Brain storming
* queuing policy ändern?
* profiling des openvpn prozesses
    * kernel profiling?
* rcv und snd buffer auf 0 reduzieren auf server+client seite
    * Kernel-Default-Buffer ev. anpassen?
    * patch für openvpn: https://community.openvpn.net/openvpn/changeset/f0b64e5dc00f35e3b0fe8c53a316ee74c9cbf15f/
* uebergabe kernelspace-userspace beschleunigen mit compile options?
    * Kontext-Switche?
* MSS-Clamping beim NAT auf einen Wert ~1280 DONE?
* OpenVPN mss-fix beim Plastikrouter auf ~1300
* OpenVPN UDP replay window deaktivieren ( --replay-window )
    * ev. nicht ohne weiteres möglich, da bei den Clients aktiv
        * aktiv <-> inaktiv ist inkompatibel?
        * könnte man vielleicht vom Server pushen?!
    * no-replay: vpn unbenutzbar [Bad LZO decompression header byte: 0]
    ** warum haben wir LZO aktiv? 98% des traffics ist HTTP, welches i.d.r. eh schon via mod-deflate komprimiert wird
        ** LZO ist nur für openvpn tcp konfiguration aktiv
    
* ACKs auf den Plastikroutern priorisieren ( siehe http://www.benzedrine.ch/ackpri.html )
*  net.netfilter.nf_conntrack_tcp_timeout_established
    * hoher timeout führt zu vollem conntrack table
* Virtualisierung und iptables saugen süße kleine Hamster durch enge Strohhalme - daran wird sich aber wohl so schnell nichts ändern.
* zu viele Clients pro Server - auch daran wird sich erstmal nicht viel ändern

* Optimierungen aus http://www.slideshare.net/denshikarasu/all-your-iops-are-belong-to-us-a-pinteresting-case-study-in-mysql-performance-optimization
** jemalloc
** aktueller Kernel
** Xen? irqbalance 1.0.6+ und Receive Packet Steering

* --fast-io Option, hört sich schon genial an 
    * testweise auf vpn03d aktiviert
* BSD vs Linux
** pfsense BSD basierend schmal lässt sich auch auf z.B. Raspberry Pi betreiben ohne Virtualisierung 
    ** warum pfsense und kein vanilla openbsd? Wir brauchen das fancy webfrontend nicht.

** Problem bei RasPi:  CPU und v.a. die besch... Netzkartenanbindung - intern über USB2, was CPU frisst und bei ~25MBit/s dichtmacht (reines IP-Forwarding, noch kein VPN, keine Crypto).
** ALIX Boards mit Intel Atom und 2 Netzwerkkarten http://www.pcengines.ch/alix.htm
   *** ALIX Boards nutzen AMD Geode aus dem jahr 2005/2007 -> sehr alte hardware
** Jetway boards bringen sogenannte Daughter Boards mit womit man seine Netzwerkkarten aufstocken kann auf bis zu 5 2x onBoard 3x extra http://www.jetwaycomputer.com/NF99.html
* SNAT --to-source anstatt kompliziertes HMARKing nutzen
    * https://github.com/freifunk-berlin/puppet-vpn03/blob/master/templates/roulette.erb#L28

# Metrics
 

## OpenVPN Konfiguration für Monitoring

ping -I <srcip> dst
mtr --address <srcip> dst

dev option sollte vpn03{a,b,c,d} sein
remote ebenfalls

client
dev vpn03a
dev-type tun
remote vpn03a.berlin.freifunk.net
nobind
persist-key
persist-tun
ca freifunk-ca.crt
cert freifunk-test.crt
key freifunk-test.key
ns-cert-type server
comp-lzo no
cipher none