Performance Thread Ruhrgebiet

klar doch, nimm die App „ping tools“ und mach nen tracert ins Internet…der erste Hop ist die Supernode über die Du aktuell raus gehst…

1 „Gefällt mir“

Moin. Wo meldet man am besten Störungen?

Aktuell ganz fiese Laufzeiten zu mesh_vpn_backbone_peer_ruhrgebiet2 …

Hier, hab Dich mal mitgenommen :wink:

ffrg2 ist ne Maschine bei Tilaa, zwar abgekündigt, aber aktuell noch an…

Ich kann den Server mal neustarten, in der Hoffnung, dass die Performance sich bessert.

Sieht nicht besser aus.

— 2a02:f98:0:26::12 ping statistics —
16 packets transmitted, 12 received, 25% packet loss, time 15015ms
rtt min/avg/max/mdev = 18.936/435.942/1267.312/436.075 ms, pipe 2

Hab von der Firma aus gepingt…

Hast du mal die ipv6 Adressen der anderen Kisten? Ich würde die gern in einen Smokeping reinnehmen.

Performance kurz vor 0!

Fast keine Verbindungen möglich.

traceroute to freifunk.net (2a01:488:66:1000:b01c:b5d:0:1), 30 hops max
1 *
2 *
3 *
4 *
5 2001:4dd0:a2b:45:dc40::c 1078.499 ms
6 2001:4dd0:a2b:1d:dc10::1 1079.070 ms
7 2001:4dd0:a2b:3a:dc10::b 1078.450 ms
8 2001:4dd0:a2b:3c::773 1078.414 ms
9 2a01:488:fade:fefe::283 1078.374 ms
10 2a01:488:66:1000:b01c:b5d:0:1 1077.705 ms
Traceroute complete: 10 hops, time: 5598 ms

15% Paketverlust zu 10.53.40.1.

mesh_vpn_backbone_peer_ruhrgebiet0: connected for 9602.808 seconds
mesh_vpn_backbone_peer_ruhrgebiet2: connected for 154095.876 seconds

Genauer:

root@ffwaf-psi8:~# batctl gwl
Gateway (#/255) Nexthop [outgoingIF]: gw_class … [B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: mesh-vpn/ea:98:f6:68:1a:a4 (bat0)]
04:bf:ef:ca:fe:4a (221) 04:bf:ef:ca:fe:04 [ mesh-vpn]: 207 - 48MBit/48MBit
02:bf:ef:ca:fe:4d (194) 04:bf:ef:ca:fe:04 [ mesh-vpn]: 207 - 48MBit/48MBit
04:bf:ef:ca:fe:05 (209) 04:bf:ef:ca:fe:04 [ mesh-vpn]: 207 - 48MBit/48MBit
02:bf:ef:ca:fe:4c (194) 04:bf:ef:ca:fe:04 [ mesh-vpn]: 207 - 48MBit/48MBit
02:bf:ef:ca:fe:01 (194) 04:bf:ef:ca:fe:04 [ mesh-vpn]: 207 - 48MBit/48MBit
02:bf:ef:ca:fe:12 (207) 04:bf:ef:ca:fe:04 [ mesh-vpn]: 207 - 48MBit/48MBit
02:bf:ef:ca:fe:4b (191) 04:bf:ef:ca:fe:04 [ mesh-vpn]: 207 - 48MBit/48MBit
02:bf:ef:ca:fe:11 (216) 04:bf:ef:ca:fe:11 [ mesh-vpn]: 207 - 48MBit/48MBit
=> 02:bf:ef:ca:fe:04 (252) 04:bf:ef:ca:fe:04 [ mesh-vpn]: 207 - 48MBit/48MBit

Und:

batctl p 02:bf:ef:ca:fe:04

27 packets transmitted, 11 received, 59% packet loss
rtt min/avg/max/mdev = 43.504/71.969/154.713/31.088 ms

Bitte um Intervention!

Hmpf…IN-Berlin…ich sehe mal eben drauf…

Läuft wieder: http://www.speedtest.net/my-result/4048394463

Wie schneller bemerken, wie schneller reagieren, wie in Zukunft vermeiden?

ich kann nicht nachvollziehen woran das nun gelegen haben könnte…möglicherweise allgemeine Auslastung des vServers auf dem die Maschine liegt?

Spricht an Ende für Server statt vServer? Und in der Folge höhere Kosten.

Im Ruhrgebiet sind alle listen leer. Liste graph map Alfred.

läuft alles ganz normal, auch mit stabilen Zahlen, vielleicht kurzzeitiger Schluckauf?

1 „Gefällt mir“

Ich sehe auch keine Nodes mehr in der Liste.

Edit: Refresh - Liste wieder da …

Das sollte nun gelöst sein, eine Node hat die Domänen Ruhrgebiet und Rheinufer gekoppelt, dadurch ist es zu Störungen der Daten gekommen…

EDIT: noch nicht gelöst, es gibt weitere Kopplungen…

Lässt sich die Prüfung evtl. irgendwie automatisieren, um die bestreffenen Nodes automatisch blackzulisten?
(Und wann greift das Blacklisting dann? Doch erst beim restart des fastd auf dem Server, oder beendet der bestehende Verbidnungen dann schon automatisch?)

Erst mit dem Restarten des richtigen fastd Prozess.

Es muss genau der fastd des Servers restartet werden wo die Verbindung drauf liegt.

Schwierig zu automatisieren, ggfs. könnte man dafür die alte mit der neuen blacklist.json jeweils vergleichen, bei Änderung 5 Minuten warten und dann auf dem richtigen Server den fastd restarten.

Dafür müsste dann in die Blacklist noch die Info auf welchem Server die Verbindung ist. Aber das ist insgesamt schon sehr tricky, da die Server gerne auch mal hängen bleiben beim Neustart des fastd.

Mir ging es jetzt auch im ersten Schritt darum, die „Domain-Kurzschlüsse“ durch Amok-Nodes per cronjob zu erkennen. Damit die Blacklist sich dann automatisch füllt.

Startscripte, die mit unzuverlässig startenden Diensten umgehen, und ggf. noch eine Zombiebekämpfung mit an Bord haben (bis zum Reboot der ganzen Maschine, selbst ein kill -9 nicht mehr hilft und irgendwelche Resourcen/Locks schicht nicht zu entfernen sind): Ja, so ein Unfug war früher mal mein tägliches Brot.
Geht manchmal nicht anders… zumindest bei closed source…

Da es das Phänomen im Ruhrgebiet nicht zu geben scheint würde ich auf das neue Rheinland Backbone tippen…

Hier kann vielleicht der @thomasDOTwtf weiter helfen?

Die IPv6 Konnektivität von Rheinufer und Möhne hängt noch an dem bb0-System vom Ruhrgebiet dran.