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