[WLANtalk] Netcup als möglicher Host Provider für Freifunk Exit Nodes?

[Kai 'wusel' Siering]

Moin,

on 06/05/15 10:20, Ole Dreessen wrote:
> Leider hat es sich aber herausgestellt, dass die Netcup Kisten nicht
> besonders performant sind. Zumindest bei allen kleinen VMs (einen
> vCore; RAM spielt keine so große Rolle) sind kaum mehr wie 50 Knoten
> mit fastd-Tunneln sinnvoll möglich.

Hmm, welche Werte habt Ihr denn bei anderen (v)Servern? Da fastd
singlethreaded ist, hilft eine etwaige 2. CPU ja "nur" beim Weiterleiten
des Mesh-Verkehrs gen Exit; Stand heute würde ich aus dem Grund
auch 2 (v)CPU und 1 GB als sinnvolles Minimum ansetzen (bislang haben
wir 1/1 benutzt).

50 Tunnel zu je 8 MBit/sec (841er fastd-Maximum) sind ja schon satte
400 MBit/sec; also 800 MBit/sec, die durch die Kiste geschleust werden
müssen (bei nicht-lokalem Exit): 400 rein in den fastd-, 400 raus in den
OpenVPN-Tunnel. Wie haben bei 70 Tunneln, die bei weitem nicht ausge-
lastet waren, die Reißleine ziehen müssen (lies: fastd-Zugang limitiert),
da fastd bei 90+% CPU lag. Das sowohl auf eigenen KVM-VMs auf
eigener HW (2,5 GHz QC-Xeons) als auch auf extern gehosteten VMs
(3,3 GHz lt. cpuinfo).

Tückisch ist dabei ja, daß es eine ganze Zeit gut geht -- bis mehrere
Tunnel mehr Traffic machen und damit mehr CPU-Zeit fordern.


> Am 06.05.2015 um 07:54 schrieb Marc-Andre Alpers:
>
> [...]
> > Wir beschränken uns auch nur auf unseren Bereich, sprich Stadt und
> > Kreis. Zudem verwenden wir die klassische Schweden VPN Lösung die
> > bei uns auch aus einem 1043v2 den maximalen Durchsatz ermöglicht.
>
> > Wir haben auch nicht vor in nächster Zeit uns von dieser Lösung zu
> > trennen weil wir noch keinen Grund sehen.
>
> > Ich bin auch dafür das man keine großen Meta Communitys machen
> > sollte, sondern jede Stadt, maximal jeder Landkreis seine eigene
> > Infrastruktur. Aber das ist ein anderes Thema.

Ja und nein; die Abhängigkeit von zentralen fastd-Möhren ist bei Gluon etwas
nervig, die dezentral zu betreiben geboten. Was die v4- und v6-Exit betrifft,
das kann man eigentlich gut zentralisieren, wobei die Kür natürlich auch hier die
Dezentralisierung wäre, sprich lokaler Exit mit der Sicherheit, die sie »Schweden-
VPN« oder eben FfN e. V./FFRL e. V. bieten. Und hier kommt dann Netcup als
Provider ins Spiel (zumindest bei v4, was ja eh' nur geNATet wird).

> > Am 6. Mai 2015 07:19:11 MESZ, schrieb Bernd Kalbfuss-Zimmermann
> > <kalbfuss at gmx.net>:
>
> >> Weiterhin sollte man nicht vergessen, dass eine Freifunk Exit
> >> Node den Providern wenig Geld, aber potenziell eine Menge Ärger
> >> bringt. Von daher sollten wir nicht zu wählerisch sein. Ich bin
> >> sehr froh, dass Herr Preuß nach den geschilderten Erfahrungen mit
> >> TOR Exit Nodes überhaupt bereit ist uns eine Angebot zu machen.

Nunja, was immer sie da gemacht haben, fit waren sie imho nicht, was das
Handling bzgl. TOR-Exit-Nodes anging. Bei einem ehem. Arbeitgeber (ISP) haben
wir das Spiel auch gehabt, Kollege betrieb TOR-Exit-Node im Mitarbeiterhousing.
Dank der RIPE-Einträge auf die Firma stand die Grüne Minna immer mal wieder
vor der Tür, mitgenommen wurde der Server nie. Aber es nervte die GL dann
doch, und so haben wir dem Kollegen ein Subnetz aus einem PI-Bereich gegeben,
auf ihn selbst eingetragen, seit dem war die Firma außen vor und der Kollege
bekam den Besuch (und die Faxe), nicht mehr die Firma ;) Daß KVM-/OpenVZ-
Hosts beschlagnamt werden, hielte ich doch für unverhältnismäßig, da es ein
Dump der VM ja auch täte. Das sollte doch wohl einem Provider möglich sein,
nach dem ersten Vorfall gerichtlich klären zu lassen?

Anyway, zum Thema:

> >> Es wäre mir bereits sehr geholfen, wenn der ein oder andere Exit
> >> Node Betreiber Richtwerte für die seiner Meinung nach notwendige
> >> Server-Leistung zukommen lassen könnte.

Wie plant der Herr Preuß denn die Durchführung? Träte Netcup als ISP in
Erscheinung (=> Providerprivileg)?

Als Exit-Node fiele OpenVPN ja weg. Ich würde auch (setzen wir derzeit um)
fastd und den Rest (tinc für IC-VPN, externes Peering) trennen, ferner gehört
auf ein Gateway kein anderes Geraffel (und grade rrdtool ist ggf. ziemlich CPU-
und I/O-lastig).

Heute würde ich 2 (v)CPUs und 2 GB als sinnvoll ansehen, sodaß 1 CPU quasi
dediziert für fastd da ist, die andere für Routing, NAT, Statistik. Anschlußband-
breite ist dann spannend: 100 MBit/sec entspricht 12 "fullspeed"-841er Tunneln,
oder ca. 5  für 1043er ... Hardwareanforderungen sind in der Tat weniger das
Problem, aber GBit-Anbindung sollte es schon ein, und entsprechend ein Viel-
faches davon die Anbindung des ISP an das Internet. Lt. vnstat macht unser
gw04, extern gehostet, ca. 8 MBit/sec im Monatsmittel auf bat0, aber ca. 30
MBit/sec im Mittel auf eth0 (8 TB im April), Tendenz steigend. (Damit eigentlich
über dem Trafficlimit des Hosters für diese kleine VM => Zeit, das gute Stück
umzuziehen).

Evtl. wäre es also zweckmäßiger, Netcup böte Althardware für schmales Geld
als Freifunk-Root-Server an, dann kann jeder selber entscheiden, ob er mit KVM
sich VMs schnitzen will oder mehrere fastd-Instanzen (1 je Core) laufen lassen.
Fragt sich halt nur, wie sich ins Geschäftsmodell einpassen läßt, denn Anschluß-
bandbreiten sind in der Regel endlich, und reguläre Kunden sollten wohl Vorrang
haben ;)
Für echten Exit bei Netcup wäre es wichtig, daß Netcup als "Freifunk-ISP" auf-
träte; ob sie das wollen? Am Traffic ändert das imho erst einmal nix, die Anfragen
kommen über fastd rein (Internet -> Netcup), gehen dann ins Netz (Netcup ->
Internet, ggf. in OpenVPN-Tunnel), die Antworten kommen dann über entweder
Netcup oder OpenVPN (Internet -> Netcup) und via fastd zurück ins Mesh (Net-
cup -> Internet) -- der Traffic ist, modulo Tunneloverhead, identisch.

MfG,
-kai

-- 
Freifunk-Initiative Gütersloh
℅ Kai Siering
Schalückstraße 107
33332 Gütersloh
 
info at guetersloh.freifunk.net
Tel.: (05241) 96 46 269