[Berlin-wireless] Freifunk-Traffic

Sa Aug 29 02:24:36 CEST 2015

Moin,

On 28/08/15 23:41, Bastian wrote:
> On 08/28/2015 04:12 PM, Faustus wrote:
>> On Thu, Aug 27, 2015 at 09:47:39PM +0200, Philipp Borgers wrote:
>>> On Wed, Aug 26, 2015 at 10:45:14PM +0200, Bastian wrote:
>>>> On 08/25/2015 02:33 PM, Philipp Borgers wrote:
>>>>> Ich fände es relativ sinnvoll, wenn wir einen dedizierten Server für das VPN03
>>>>> aufsetzen und so das Problem erstmal kurzfristig lösen. Nach meinem
>>>>> Kenntnisstand liegen min. zwei Server ungenutzt im Lager. Eine Spendenkampagne
>>>>> für die Stromkosten, sollte ja auch nicht so das Ding sein. Arbeit kann ich
>>>>> übernehmen.
> Bitte erwähnt in der Spendenkampagne auch das wir Fähigkeiten in der
> Administration, dauerhaften Wartung und (Weiter-)Entwicklung von
> skalierenden VPN-Lösungen als Spende annehmen.
> SCNR

Naja, mehr als melden kann ich mich nicht (s. 20.07.) ;) Nein, ich denke nicht, daß ein Ortsfremder/Pendler Euch wirklich auf Dauer weiterbringt, aber da keine weitere Rückmeldung kam, ging' ich mal davon aus, Du hättest auf Deinen letzten Aufruf (»Weiterer ICVPN Maintainer gesucht«) was Passenderes gefunden ;)

> Apropos low hanging fruits:
>
> *) Communites auf ICVPN oder zum FFRL schieben

ICVPN halte ich für trivial machbar und sinnvoll, wobei das eine Verschlüsselung durch die andere ersetzt. Gezielte BGP-GRE-Tunnel nach Modell FFRL halte ich da für sinnvoller (auch weil für die Community puppet-Scripte existieren/es auch händisch eher simpel ist), zudem es a) die CPU-Last senkt (Traffic zwischen RZ-Systemen braucht keine Verschlüsselung; gre läuft eigentlich im Kernel) und b) den Verkehr noch immer regelt. Da derzeit jede Community via ICVPN mind. an berlin2 ihren Traffic abkippen kann, ist die Frage der Überlastung der icvpn-Kisten bei Euch imho nur eine Frage der Zeit. Außerdem, wenn man mehrere, lokal getrennte Systeme fährt, ist der Rückweg ggf. nicht gleich dem Hinweg:

root at gw01:~# traceroute -s 10.255.1.1 ns.uu.net
traceroute to ns.uu.net (137.39.1.3), 30 hops max, 60 byte packets
 1  bgp4-gw01.ospf.ffgt (10.255.145.38)  10.759 ms  10.762 ms  10.751 ms
 2  icvpn02.berlin.freifunk.net (77.87.49.67)  55.761 ms  56.049 ms  56.429 ms
 3  bgp02.berlin.freifunk.net (77.87.49.65)  58.236 ms  59.934 ms  60.613 ms
 4  syseleven-k15.bcix.de (193.178.185.48)  60.706 ms  62.093 ms  62.110 ms

root at bgp4:~# ping -c 5 10.207.0.6
PING 10.207.0.6 (10.207.0.6) 56(84) bytes of data.
64 bytes from 10.207.0.6: icmp_seq=1 ttl=64 time=17.5 ms
64 bytes from 10.207.0.6: icmp_seq=2 ttl=64 time=16.6 ms
^C

root at mueritz_bgp1:~# birdc show route primary | grep guet
10.255.0.0/21      via 10.207.0.136 on icvpn [gueterslohbgp1 2015-08-28] * (100) [AS65533?]

root at bgp1:~# ping -c 5 10.207.0.6
PING 10.207.0.6 (10.207.0.6) 56(84) bytes of data.
64 bytes from 10.207.0.6: icmp_seq=1 ttl=64 time=15.4 ms
64 bytes from 10.207.0.6: icmp_seq=2 ttl=64 time=15.7 ms
^C
root at bgp1:~# traceroute 10.255.1.1
traceroute to 10.255.1.1 (10.255.1.1), 30 hops max, 60 byte packets
 1  bgp3-bgp1.ospf.ffgt (10.255.145.66)  14.877 ms  14.909 ms  14.871 ms
 2  gw01.ffgt (10.255.1.1)  15.138 ms  15.210 ms  15.181 ms

(gw01, bgp3, mueritz_bgp1 stehen in F, bgp4 in N, bgp1 in GT. Die RTT ist somit erkärbar: F-N: 10 ms, N-B 17 ms, B-GT 15 ms, GT-F 15 ms => 57 ms. Mit direkten GRE-Tunneln wären es 17 ms N-B plus die 10 ms F-N => 27 ms. DIsclaimer: keines der System führt derzeit FFGT-Live-Traffic.)

Communities anzuregen, parallel den FFRL zu nutzen, ist sicher sinnvoll (statt VPNs zu bezahlen kann man auch Spenden ...); jedoch, aber vielleicht bin ich ja der bedauerliche Einzelfall, die Antwortzeiten über das FFRL-Ticketsystem sind eher zum abgewöhnen. Die Anfrage der Erweiterung um 2 weitere Tunnel (für die Systeme außerhalb GTs; für die in GT macht der lokale Exit mehr Sinn, FFRL war da nur als Fallback weil whatever gedacht) vom 5.08. hängt da noch ohne Antwort rum. Die initiale Einrichtung der ersten beiden Tunnel hat 3 Monate gedauert -- lies: ich sähe das nicht als Kurzfriststrategie. (Und ja, auch die Kollegen kochen da nur mit Wasser und haben Ehrenamtliche, die »nebenbei« noch die Butter auf's eigene Brot verdienen müssen. Dennoch sehe ich die Antwortzeiten als Problem, so ein GRE-Tunnel ist per Skript eigentlich in 5 Minuten konfiguriert, und ohne Kommunikation fragt man sich, warum binnen 3 Wochen nicht mal eine Info kommt, wann man damit rechnen kann ...
Aber, wie gesagt, evtl. bin ich der bedauerliche Einzelfall.)

> *) VPN03 Instanz beim FFRL, FFHH

Hmm, was löste das? Da würde ich ernsthaft eher die ICVPN/BGP-Geschichte forcieren ...

>>>> Wie haben z.Z. zwei DC-Standorte. Der eine ist günstig, aber ob weitere
>>>> Hardware auch bessere Performance liefert ist fraglich.
>>> Ich nehme an wir reden von den VPN03-Servern:
>>>
>>> Das weitere Hardware eine bessere Gesamt-Performance bewirkt, sollte doch
>>> eigentlich klar sein. Wir können gerne diskutieren, ob wir unsere Resource
>>> optimal ausnutzen.
>> Optimieren ist natürlich immer gut, aber das Thema läuft jetzt
>> schon zu lange. Wenn die Leute wo es fordern, es nicht selbst tun
>> und die anderen es nicht können oder dafür keine Zeit haben,
>> müssen wir halt erstmal in den sauren Apfel beißen. So war das
>> doch schon immer bei Freifunk.
> IMHO steht Freifunk auch für Nachhaltigkeit. Hardware auf Probleme
> werfen ist nicht nachhaltig...

Dann fällt "vpn03 Instanz sonstwo" irgendwie raus, oder?

MfG,
-kai